이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 팀원과 페어 프로그래밍으로 플레이크한 E2E 테스트를 잡는 과제를 맡았습니다. 혼자 2시간을 뒤져도 안 보이던 타이밍 이슈를 페어로 진행하자 10분 만에 찾았는데, 제가 코드를 소리 내어 설명하다가 전제 가정의 허점을 스스로 발견한 순간이었습니다. 페어의 상대가 '저 부분은 왜 그렇게 설정했나요?'라고 묻는 것만으로도 숨겨진 가정이 드러났습니다. 이 경험으로 코드 리뷰와 달리 페어는 실시간 질문이 핵심 가치라는 것을 배웠고, 이후 막히는 문제가 30분 이상 지속되면 먼저 옆 사람에게 설명을 요청하는 습관이 생겼습니다. 페어 프로그래밍은 단순 생산성 도구가 아니라 사고 과정을 외부화하는 방법임을 이 경험에서 실감했습니다.
팀 프로젝트에서 모든 작업을 페어로 진행해보자는 시도를 했는데, 단순하고 반복적인 작업에서는 혼자 할 때보다 속도가 느려지는 것을 경험했습니다. 두 사람이 같은 화면을 보며 진행하다 보니 한 사람이 기다리는 시간이 생겼고, 집중도도 혼자 작업할 때보다 유지하기 어려운 경우가 있었습니다. 페어 프로그래밍이 효과적인 상황은 복잡한 문제를 풀거나 서로 모르는 부분을 함께 탐색할 때라는 것을 이 경험에서 배웠습니다. 단순 구현보다 판단이 필요하거나 막히는 문제에서 페어를 하는 것이 시간 비용과 효과의 균형이 맞다는 것을 알게 됐습니다. 좋은 방식도 모든 상황에 적용하면 오히려 비용이 되는 경우가 있고, 언제 쓸지를 판단하는 것이 방식을 잘 아는 것만큼 중요하다는 것을 이 경험에서 알게 됐습니다.
인턴 초반에 익숙하지 않은 코드베이스를 파악해야 했는데, 팀원과 함께 코드를 읽어가면서 이해하는 방식으로 시작했습니다. 혼자 코드를 읽을 때는 이 코드가 왜 이렇게 작성됐는지를 모르는 채 넘어가는 경우가 많았는데, 팀원이 맥락을 설명해주면서 읽으니 개별 코드의 의도를 파악하는 시간이 줄었습니다. 팀원도 코드를 설명하면서 오래전에 작성해서 잊고 있던 부분을 다시 확인하게 됐다는 말을 했습니다. 페어 프로그래밍은 새로운 코드를 작성하는 것만이 아니라 기존 코드를 이해하는 과정에도 효과적이라는 것을 이 경험에서 배웠습니다. 다만 팀원의 시간을 함께 쓰는 것이기 때문에, 혼자 시도해볼 수 있는 부분을 먼저 해보고 정말 막히는 부분에서 페어를 요청하는 균형이 필요하다는 것도 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.