우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›라인›백엔드›질문 상세
    問
    라라인백엔드협업·관계2026년 출제

    Git을 활용한 협업 경험에서, 코드 리뷰 시 가장 중요하다고 생각하는 요소는 무엇인가요?

    답변 미리보기

    코드 리뷰를 할 때는 왜 그렇게 짰는지를 먼저 이해하려는 방향으로 접근합니다. 로직이 낯설거나 방식이 달라도 "이건 왜 이렇게 했어요?"라고 묻는 걸 먼저…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    코드 리뷰 스타일은 어떤가?
    본인의 코드 리뷰 스타일에 대한 설명이 흔적이 있어야 합니다. 없으면 면접관이 '구체적으로 어떤 점을 중시하나요?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    의견 차이 대처 경험은 있었나?
    다른 개발자와 의견 차이가 있었던 경험에 대한 설명이 필요합니다. 이 부분이 부족하면 면접관이 '어떻게 해결했나요?' 같은 질문을 던지는 자리가 자주 보입니다.
    語
    03
    협업에서의 소통 방식은?
    협업 시 소통 방식에 대한 언급이 있어야 합니다. 없으면 면접관이 '팀원과의 소통은 어떻게 하나요?'를 추가로 묻는 경우가 흔하게 통합니다.
    本
    04
    피드백 수용 능력은 어떤가?
    피드백을 수용하는 태도에 대한 설명이 필요합니다. 이 부분이 결여되면 면접관이 '피드백을 받을 때 어떻게 하나요?'를 궁금해하는 자리가 자주 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    라인 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    의도 파악 먼저, 합의 방식으로 닫는 결약 86초컨벤션 충돌 → 문서화 합의 → 제안형 코멘트 습관약 78초상태 관리 충돌 → 상황 기준 합의 → 결정 근거 기록약 82초
    예시 답변 1
    약 86초

    의도 파악 먼저, 합의 방식으로 닫는 결

    코드 리뷰를 할 때는 왜 그렇게 짰는지를 먼저 이해하려는 방향으로 접근합니다. 로직이 낯설거나 방식이 달라도 "이건 왜 이렇게 했어요?"라고 묻는 걸 먼저 하고, 이해한 뒤에 제 생각을 얘기하는 편입니다. 팀 프로젝트에서 한 번은 예외 처리 방식을 두고 의견이 갈렸던 적이 있었습니다. 저는 try-except를 좁은 범위에만 쓰는 걸 선호했는데, 팀원은 전체를 감싸는 방식을 써왔습니다. 각자 이유를 설명하다 보니 팀원은 개발 속도를 우선했고 저는 디버깅 편의를 중시했다는 걸 알게 됐습니다. 결국 핵심 로직에는 좁게, 입출력 경계에는 넓게라는 방식으로 합의했습니다. 그 이후로 리뷰에서 의견 차이가 나면 코드 자체보다 상황과 우선순위를 먼저 맞추는 방식으로 접근하고 있습니다.

    이 결의 특징
    의견 차이를 옳고 그름의 문제가 아니라 우선순위 차이로 재해석하고, try-except 범위를 좁게/넓게 나누는 절충안으로 국면을 닫은 흔적이 있습니다. 코드보다 상황과 우선순위를 먼저 맞추는 순서가 반복해서 드러나는 결이 담겨 있습니다.
    이 결이 통하는 자리
    리뷰에서 왜 그렇게 짰는지를 먼저 묻는 태도가 구체적인 합의안으로 이어질 때 통합니다. 예외 처리처럼 사소해 보이는 지점에서 실제로 기준이 갈리는 순간을 보여주면 면접관이 협업 감각을 읽는 결이 보입니다.
    예시 답변 2
    약 78초

    컨벤션 충돌 → 문서화 합의 → 제안형 코멘트 습관

    코드 리뷰를 코드를 고치는 자리보다 서로 기준을 맞추는 과정으로 봅니다. PR 리뷰에서 네이밍 컨벤션을 두고 의견이 갈렸던 적이 있었습니다. 저는 함수명에 동사를 붙이는 방식을 선호했고, 팀원은 명사형 위주로 써왔습니다. 각자 써온 코드베이스 경험이 달랐기 때문이었습니다. 한쪽이 맞다고 설득하는 대신 팀 전체가 함께 쓸 컨벤션 문서를 짧게 만들자고 제안했고, 30분 논의 끝에 두 페이지짜리 기준이 나왔습니다. 그 이후로는 같은 이유로 리뷰가 길어지는 일이 줄었습니다. 코멘트를 쓸 때는 이 방식은 어떨까요?처럼 제안형을 의식합니다. 명령형 코멘트는 방어적 반응을 만들고, 제안형은 토론의 자리를 열었습니다. 의견 차이가 생길 때 어느 방식이 옳냐보다 지금 상황에 무엇이 맞냐로 질문을 바꾸면 방향이 빨리 잡히는 경험을 반복했습니다.

    이 결의 특징
    네이밍 컨벤션 충돌을 한쪽 설득이 아니라 팀 문서화로 풀고, 이후 코멘트를 제안형으로 바꾼 습관 변화까지 이어지는 흔적이 있습니다. 30분이라는 구체 시간과 두 페이지 문서라는 결과물이 결을 뒷받침합니다.
    이 결이 통하는 자리
    명령형 코멘트가 방어적 반응을 부른다는 관찰이 실제 행동 변화로 이어졌을 때 살아납니다. 어느 방식이 옳냐보다 지금 상황에 무엇이 맞냐로 질문을 바꾸는 장면이 또렷할 때 면접관의 추가 질문이 줄어드는 결이 보입니다.
    예시 답변 3
    약 82초

    상태 관리 충돌 → 상황 기준 합의 → 결정 근거 기록

    리뷰에서 상대 코드를 처음 볼 때 "내가 짰다면 어떻게 했을까"를 먼저 물어보는 습관이 있습니다. 그렇게 하면 차이가 보여도 의도를 더 잘 이해하게 됩니다. 한 번은 상태 관리 방식을 두고 방향이 달랐던 경험이 있습니다. 저는 전역 상태를 최소화하자는 입장이었고, 팀원은 공유 상태가 있어야 컴포넌트 간 데이터 흐름이 편하다는 입장이었습니다. 둘 다 틀리지 않았습니다.

    현재 기능 범위에서는 팀원 방식이 빠르고, 확장 시에는 제 접근이 안전하다는 데 합의했고, 현재 방식을 적용하되 결정 근거를 주석으로 남겼습니다. 이후에 그 주석이 실제로 도움이 됐습니다. 리뷰에서 의견이 엇갈릴 때 어느 방식이 맞냐를 논쟁하기보다 현재 상황에 더 맞는 쪽을 찾는 방향으로 접근하면, 대화가 더 빨리 닫히는 자리가 됩니다.

    이 결의 특징
    상태 관리 방향이 갈린 상황에서 둘 다 틀리지 않았다는 판단을 거쳐 현재 상황 기준으로 절충하고, 결정 근거를 주석으로 남긴 흔적이 있습니다. 그 주석이 나중에 실제로 도움이 됐다는 후일담이 결에 무게를 더합니다.
    이 결이 통하는 자리
    어느 방식이 맞냐는 논쟁 대신 현재 기능 범위와 확장 가능성을 나눠 판단하는 장면이 살아 있을 때 통합니다. 결정을 기록으로 남기는 습관이 구체적으로 드러나면 면접관이 협업 성숙도를 읽는 자리가 됩니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹코드 리뷰에서 가장 중요하다고 생각하는 점은 무엇인가요?
    貳의견 차이가 있었던 경험을 좀 더 구체적으로 말씀해 주실 수 있나요?
    參다른 개발자와의 갈등을 해결한 방법이 궁금합니다.
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 라인 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    라인 · 풀스택
    Git을 이용한 협업과 코드 리뷰 경험에 대해 구체적으로 설명해 주세요.
    이 질문 보기
    라인 · 프론트엔드
    Git을 이용한 협업 과정에서 어떤 역할을 했고, 코드 리뷰는 어떻게 진행했는지 사례를 들어 설명해 주세요.
    이 질문 보기
    배달의민족(우아한형제들) · 백엔드
    코드 리뷰에 참여한 경험과 그 과정에서 배운 점은 무엇인가요?
    이 질문 보기
    CJ올리브영 · 백엔드
    Git을 사용한 경험이 많으신가요? 코드 리뷰 과정에서 어떤 점을 중요하게 생각하나요?
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 라인 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기