이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
소스코드 점검에서 가장 먼저 보는 건 보안 취약점 패턴입니다. 입력값 검증 없이 외부 데이터를 직접 쿼리에 사용하는 SQL 인젝션 패턴, 사용자 입력을 그대로 HTML에 출력하는 XSS 패턴, 하드코딩된 비밀번호나 API 키 노출 등이 기본 점검 항목입니다. 기능 외에 코드 품질 기준도 함께 봅니다. 변수명과 함수명이 의도를 드러내는지, 예외 처리가 적절히 구성되어 있는지, 코드 중복이 과도하게 발생하지 않는지를 확인합니다. 코드 리뷰에서 중요한 건 지적이 아니라 대화입니다. 왜 이렇게 구현했는지를 먼저 물어보면 의도를 이해하고 더 적절한 피드백을 줄 수 있습니다.
정적 분석 도구를 코드 리뷰의 보조 수단으로 활용하면 반복적인 패턴 체크를 자동화하고 사람은 더 복잡한 로직 검토에 집중할 수 있습니다.
코드 리뷰를 경험에만 의존해서 하다가 인젝션 패턴을 놓친 경험이 있습니다. 익숙한 패턴에는 민감하게 반응하지만 처음 보는 방식으로 작성된 취약 코드는 눈에 안 들어오는 경우가 생겼습니다. 이후에는 OWASP Top 10이나 CWE 체크리스트를 점검 기준으로 옆에 두고 항목별로 확인하는 방식으로 바꿨습니다. 기준이 있으면 내가 익숙한 영역 외에도 확인해야 할 범위가 명시되고, 점검 커버리지가 높아졌습니다. 코드 점검은 경험이 쌓일수록 강해지는 부분이 있지만, 체계적 기준 없이는 맹점이 생긴다는 것을 배웠습니다.
이 경험이 이후 소스코드 점검 시 체계적 점검 기준을 경험 판단과 병행하는 기준이 됩니다. 소스코드 보안 점검의 커버리지는 경험 숙련도만이 아니라 체계화된 기준을 함께 사용하는지 여부에서 결정된다는 원칙을 지킵니다.
정적 분석 도구를 사용해 소스코드를 점검하고 경고 없음 결과를 안전하다고 판단했는데, 이후 수동 검토에서 인젝션 취약점이 발견된 경험이 있습니다. 도구가 커버하지 못하는 맞춤형 ORM 쿼리 구조가 있었고, 자동화 도구의 한계였습니다. 이후에는 자동화 도구 결과를 점검의 시작점으로 사용하고, 도구가 잘 다루지 못하는 영역(비즈니스 로직, 커스텀 프레임워크)은 수동으로 추가 점검하는 방식으로 바꿨습니다. 자동화 결과는 점검을 완료했다는 증거가 아니라 점검을 보조하는 입력이라는 것을 이해하게 됐습니다. 도구와 사람 점검의 강점이 다르기 때문에 두 방식을 상호 보완적으로 사용하는 체계가 필요합니다.
이 관점이 이후 소스코드 점검 시 자동화 도구와 수동 점검 대상 영역을 분리 설계하는 기준이 됩니다. 소스코드 점검에서 자동화 도구 결과를 신뢰하되, 도구가 커버 못 하는 영역을 수동으로 보완하는 이중 점검 체계가 실제 취약점 발견율을 높인다는 원칙을 지킵니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오모빌리티 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.