이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
코드 리뷰에서 제가 가장 먼저 보는 것은 의도가 코드에서 읽히는가입니다. 변수명, 함수명, 구조만 봤을 때 무엇을 하려는 코드인지 알 수 없다면, 기능이 정상 동작해도 유지보수 비용이 높아집니다.
그 다음으로는 엣지 케이스 처리 여부를 확인합니다. 경계값이나 예외 상황을 명시적으로 다루지 않은 경우, 운영에서 조용히 문제가 발생할 가능성이 있습니다. 팀 프로젝트에서 이 부분을 놓쳐 배포 후 에러가 난 경험이 있어서 더 신경 씁니다.
피드백 방식도 중요하게 생각합니다. 초기에는 이 부분이 잘못됐다는 식으로 짧게 코멘트했는데, 팀원이 의도를 오해하거나 불편해하는 경우가 있었습니다. 이후에는 제안 + 근거 형식으로 바꿨고, 리뷰 반영 속도도 빨라지고 대화도 자연스러워졌습니다. 리뷰는 코드를 고치는 과정이기도 하지만 팀 기준을 함께 만드는 과정이라고 생각합니다.
코드 리뷰에서 제가 중요하게 보는 또 다른 기준은 변경이 발생했을 때 영향 범위를 예측할 수 있는 구조인가입니다. 기능이 잘 돌아가도 어디를 바꾼면 어디가 깨지는지 알 수 없는 코드는 유지보수 비용이 높습니다. 특히 하나의 함수가 여러 곳에서 다른 목적으로 재사용되거나, 상태를 여러 곳에서 직접 수정하는 패턴이 있으면 리뷰에서 꼭 언급합니다. 리뷰에서 이 부분을 지적할 때는 지금 문제가 아니라 앞으로 어떤 상황에서 문제가 될 수 있는지를 함께 설명하면 더 낙득하기 쉽습니다.
좋은 코드는 현재 동작뿐 아니라 미래 변경을 견디는 구조로 설계됩니다.
코드 리뷰에서 중점을 두는 또 다른 상황은 테스트가 없는 코드가 PR로 올라왔을 때입니다. 기능 구현은 돼지만 검증 가능한 형태가 없으면 다음 사람이 수정할 때 어디까지 영향이 가는지 알 수 없습니다. 이 경우 직접 테스트를 작성하라고 요청하기보다, 이 함수의 어떤 조건이 변경될 가능성이 있는지를 먼저 같이 즧고, 그 부분이 테스트 가능한 구조인지를 확인하는 방식으로 접근합니다.
리뷰에서 테스트를 요구하는 것은 지금 속도보다 나중의 안정성을 선택하는 것입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오페이 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.