“그래서 직접 뭘 하셨나요?” 본인 기여를 분명하게 답하기

프로젝트 전체 구조를 잘 설명했는데도 “그래서 본인이 한 일은요?”라는 질문이 나오면 설명의 초점이 다른 곳에 있었을 수 있어요. 전체 배경은 짧게 두고 자신의 결정과 행동으로 넘어가야 합니다. 작지만 명확한 기여가 넓고 모호한 설명보다 이해하기 쉽습니다.

담당했습니다 뒤에 무엇을 붙일까요

분석했다, 설계했다, 구현했다, 리뷰했다, 테스트했다는 서로 다른 역할입니다. 실제 맡은 행위를 고르고 대상을 붙여 보세요. “최적화를 담당했다”보다 어떤 경로와 조건, 버퍼 또는 지표를 바꿨는지 말하면 범위가 드러납니다.

라이브러리의 기능을 수정했다면 기존 동작과 변경한 조건을 먼저 설명하세요. 전체 알고리즘을 개발한 것처럼 넓히지 않아도 됩니다. 기존 구조를 이해하고 재현 조건과 회귀 테스트를 마련한 일 자체를 구체적으로 설명할 수 있어요.

아이디어를 제안한 사람, 최종 결정한 사람, 구현한 사람이 다를 수 있습니다. 공동 작업이라면 함께 정한 내용과 본인이 실행한 부분을 나누세요. 공개 PR의 작성자라는 사실만으로 다른 사람의 후속 수정까지 자신의 일이라고 말하지 않습니다.

정확도, 처리량, 예약 메모리, 실제 메모리 사용은 서로 다른 지표입니다. 무엇이 달라졌는지와 어떻게 확인했는지를 붙이세요. 아직 측정하지 못한 속도 개선을 덧붙이는 것보다 확인한 변경의 의미를 설명하는 편이 일관됩니다.

내 말로 답하기

“설명하신 것 중 직접 하신 부분은 어디인가요?”

전체 [시스템] 중 제가 맡은 것은 [구체 범위]예요. 기존에는 [문제]가 있었고, 저는 [조건·구현]을 바꿔 [동작]하도록 했습니다. [테스트]로 확인했고, [다른 팀원·기존 라이브러리의 범위]와는 구분해서 말씀드릴 수 있어요.

답변 구성을 보여주기 위한 가상 예시예요. 대괄호 안의 내용은 본인의 경험과 실제 역할, 확인한 결과로 바꿔 주세요.

핵심 단어만 보고 소리 내어 답한 뒤, 같은 경험을 다른 질문으로 다시 설명해 보세요.

기여가 작아 보이면요?

범위를 부풀리기보다 문제의 영향과 판단, 재현·검증 과정을 설명하세요.

페어 프로그래밍은 누구의 기여인가요?

공동 구현이라고 설명하고 자신이 맡은 판단·코드·검토를 구분하면 됩니다.