회사 첫 코드리뷰에서 막히는 웹개발 질문법

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

풀 리퀘스트를 올렸는데 리뷰 댓글이 열 개 넘게 달렸다면, 문제는 실력 부족만이 아닐 수 있습니다. 많은 주니어 개발자가 웹개발 코드리뷰에서 어려워하는 지점은 코드를 고치는 방법보다 “무엇을 먼저 묻고, 어디까지 설명해야 하는가”입니다.

이번 글은 현업 테크 리드와의 인터뷰 형식으로 구성했습니다. 코딩을 처음 배울 때는 정답을 찾는 일이 중요하지만, 팀 프로젝트에서는 맥락을 전달하고 근거를 남기는 프로그래밍 커뮤니케이션이 더 큰 차이를 만듭니다.

첫 리뷰 댓글을 받았을 때 바로 답하지 말아야 하는 이유

Q. 리뷰어가 지적하면 바로 수정하는 게 좋은 태도 아닌가요?

A. 빠른 수정은 좋지만, 곧바로 커밋부터 올리는 습관은 위험합니다. 리뷰 댓글에는 단순 오타 지적, 설계 방향 질문, 팀 컨벤션 확인, 잠재 버그 경고가 섞여 있습니다. 이를 구분하지 않고 모두 같은 무게로 처리하면 코드가 더 복잡해질 수 있습니다.

예를 들어 “이 로직을 컴포넌트 밖으로 빼는 게 어떨까요?”라는 댓글은 단순 이동 요청이 아닐 수 있습니다. 렌더링 성능, 테스트 가능성, 재사용 범위까지 함께 묻는 질문일 수 있죠. 프로그래밍의 기본 개념이 문제 해결 절차를 설계하는 활동에 가깝다는 점을 떠올리면, 리뷰 댓글도 코드 줄 하나가 아니라 문제 해결 방식에 대한 대화로 보는 편이 맞습니다.

• 오타·포맷 댓글: 바로 수정하고 “반영했습니다”라고 짧게 답합니다.
• 구현 방식 질문: 왜 현재 방식을 택했는지 먼저 설명한 뒤 대안을 검토합니다.
• 설계 변경 제안: 영향 범위, 수정 파일, 테스트 범위를 함께 확인합니다.
• 성능·보안 우려: 추측으로 답하지 말고 재현 조건이나 측정 기준을 묻습니다.

Q. 그럼 첫 답변은 어떻게 쓰는 게 좋나요?

A. 첫 답변은 방어문이 아니라 분류표처럼 쓰는 것이 좋습니다. “이 부분은 바로 수정하겠습니다”, “이 부분은 의도를 설명드리면”, “이 부분은 대안 A와 B 중 확인이 필요합니다”처럼 나누면 리뷰어도 다음 행동을 결정하기 쉬워집니다.

주니어 개발자가 자주 하는 실수는 모든 댓글에 “넵 수정하겠습니다”라고 답하는 것입니다. 겉으로는 성실해 보이지만, 실제로는 코딩 의사결정의 근거가 사라집니다. 특히 웹개발에서는 상태 관리, API 응답 구조, 접근성, 브라우저 동작처럼 한 줄 수정이 다른 화면에 영향을 줄 수 있으므로 질문을 생략하면 비용이 커집니다.

전문가 조언: “리뷰 댓글을 받으면 먼저 수정 난이도가 아니라 결정 유형을 분류하세요. 코드리뷰는 시험지가 아니라 팀의 판단 기록입니다.”

좋은 질문은 코드보다 먼저 재현 조건을 보여줍니다

Q. 질문할 때 코드를 얼마나 붙여야 하나요?

A. 코드 전체를 붙이는 것보다 “어떤 상황에서, 어떤 입력으로, 어떤 결과가 나왔는지”를 먼저 제시하는 편이 낫습니다. 리뷰어가 가장 빨리 이해하는 질문은 짧은 코드가 아니라 재현 가능한 맥락을 가진 질문입니다.

예를 들어 “버튼이 안 눌립니다”보다 “모바일 사파리에서 로그인 후 뒤로 가기를 누른 뒤 다시 CTA를 탭하면 onClick은 실행되지만 API 요청이 나가지 않습니다”가 훨씬 좋습니다. 이 문장에는 환경, 사용자 행동, 관찰 결과, 의심 지점이 들어 있습니다. 코딩이라는 용어가 컴퓨터가 이해할 명령을 작성하는 일로 설명되지만, 실무에서는 사람이 이해할 수 있게 상황을 번역하는 일도 함께 필요합니다.

1. 환경: 브라우저, 기기, 로컬·스테이징·운영 여부를 씁니다.
2. 행동: 사용자가 어떤 순서로 클릭하거나 입력했는지 적습니다.
3. 기대 결과: 원래 어떤 화면이나 응답이 나와야 하는지 설명합니다.
4. 실제 결과: 콘솔 오류, 네트워크 응답, 화면 상태를 구체적으로 남깁니다.
5. 시도한 것: 이미 확인한 가설을 적어 중복 조사를 줄입니다.

Q. 질문을 너무 자세히 쓰면 느려 보이지 않을까요?

A. 오히려 반대입니다. 좋은 질문은 팀의 시간을 아낍니다. 질문을 준비하면서 스스로 원인을 찾는 경우도 많고, 해결하지 못하더라도 리뷰어가 바로 핵심으로 들어갈 수 있습니다.

현업에서는 “도와주세요”보다 “A 방식과 B 방식 중 어느 쪽이 이 코드베이스의 방향에 맞을까요?”라는 질문이 더 강력합니다. 이 질문에는 이미 문제를 이해하려고 노력한 흔적이 있습니다. 특히 웹개발 튜토리얼만 따라 하던 단계에서 팀 코드로 넘어올 때는 정답보다 선택 기준을 묻는 연습이 중요합니다.

• 나쁜 질문: “이거 왜 안 될까요?”
• 나은 질문: “useEffect 의존성에 userId를 추가하면 중복 호출이 생기는데, 이 경우 캐싱으로 막는 게 맞을까요?”
• 좋은 질문: “현재 구조에서는 userId 변경 시 재요청이 필요하지만, 중복 호출을 막기 위해 요청 키를 분리하는 방식과 상위 컴포넌트에서 데이터를 주입하는 방식 중 어떤 방향이 유지보수에 맞을까요?”

질문의 품질을 높이고 싶다면 코드 블록보다 먼저 한 문장 요약을 붙여 보세요. “문제는 결제 버튼이 아니라 인증 토큰 갱신 타이밍입니다”처럼 초점을 좁히면 리뷰어의 시선이 바로 이동합니다.

전문가 조언: “질문은 길어도 괜찮습니다. 다만 길어야 하는 이유가 있어야 합니다. 환경, 재현, 기대값, 실제값이 빠진 긴 질문은 그냥 긴 혼란입니다.”

팀 기준을 묻는 질문이 개인 실력을 빠르게 끌어올립니다

Q. 코드 스타일은 그냥 팀 규칙을 따르면 되는 것 아닌가요?

A. 맞습니다. 하지만 팀 규칙을 따른다는 말은 단순히 ESLint 경고를 없애는 수준이 아닙니다. 어떤 로직을 훅으로 뺄지, 어떤 유틸을 공용화할지, API 에러 메시지를 어디에서 변환할지 같은 기준은 도구가 자동으로 알려주지 않습니다.

이때 좋은 질문은 “제 취향은 이렇습니다”가 아니라 “우리 서비스의 변경 주기를 고려하면 어느 쪽이 더 적합한가요?”입니다. 예를 들어 관리자 화면처럼 테이블 컬럼이 자주 바뀌는 영역이라면 추상화를 조금 늦추는 편이 나을 수 있고, 결제나 인증처럼 실수가 치명적인 영역이라면 중복이 있더라도 명시적인 코드가 더 안전할 수 있습니다. 프로그래밍 관련 서적 정보를 찾아보면 언어 문법뿐 아니라 사고 방식과 문제 분해가 반복해서 다뤄지는 이유도 여기에 있습니다.

• 변경이 잦은 화면: 재사용보다 읽기 쉬운 구조를 우선 검토합니다.
• 도메인 규칙이 중요한 화면: 함수명과 타입명에 업무 용어를 명확히 반영합니다.
• 여러 팀이 쓰는 모듈: 예외 처리와 문서화를 코드와 함께 남깁니다.
• 성능 영향이 큰 기능: 감이 아니라 측정값과 사용자 흐름을 기준으로 논의합니다.

Q. 전문가라면 리뷰 답변의 우선순위를 어떻게 세우나요?

A. 저는 리뷰 답변의 우선순위를 “버그 가능성, 사용자 영향, 팀 기준, 개인 선호” 순서로 둡니다. 이 순서가 흔들리면 사소한 네이밍 논쟁에 오래 머물고, 실제 장애 가능성이 있는 로직을 뒤로 미루게 됩니다.

예를 들어 버튼 컴포넌트 이름이 조금 아쉽다는 의견과, 결제 완료 후 중복 요청이 발생할 수 있다는 의견이 동시에 달렸다면 당연히 후자를 먼저 처리해야 합니다. 반대로 사용자 영향이 거의 없는 내부 변수명이라면 팀 컨벤션만 맞추고 빠르게 넘어가는 편이 좋습니다. 코딩 실력은 모든 의견을 크게 받아들이는 태도가 아니라, 중요한 의견을 먼저 처리하는 판단력에서 드러납니다.

1. 1순위: 실제 버그와 데이터 손상 가능성을 먼저 봅니다. 인증, 결제, 저장, 삭제, 권한 로직은 작은 의심도 재현해 봅니다.
2. 2순위: 사용자 경험에 보이는 문제를 확인합니다. 로딩, 빈 화면, 모바일 터치, 접근성 문구처럼 사용자가 바로 느끼는 부분입니다.
3. 3순위: 팀의 유지보수 기준을 맞춥니다. 파일 위치, 네이밍, 에러 처리, 테스트 방식은 다음 작업자의 시간을 줄입니다.
4. 4순위: 개인 취향에 가까운 제안은 근거를 묻고 필요하면 팀 규칙으로 남깁니다. 반복되는 취향 논쟁은 문서화가 답입니다.

다음 코드리뷰에서 막힌다면 “어떻게 고치죠?”보다 “이 댓글은 버그, 사용자 영향, 팀 기준, 개인 선호 중 어디에 가깝나요?”라고 먼저 물어보세요. 그 질문 하나가 웹개발 실무에서 가장 자주 쓰는 판단 순서를 만들어 줍니다.