이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 새 기능 추가와 기술 부채 해소 중 하나를 선택해야 하는 상황이 있었습니다. 마감이 2주 남은 시점에 DB 쿼리 성능 문제가 드러났는데, 이를 먼저 고치려면 기능 개발이 1주일 이상 밀릴 상황이었습니다. 즉각 해결과 데모 이후로 미루기를 두고 팀과 논의했는데, 저는 성능 문제의 재현 조건과 사용자 영향 범위를 먼저 수치로 정리하는 방식을 제안했습니다. 조회 빈도가 낮은 경로였고 데모 환경에서 데이터 양도 적어 임시 인덱스로 우선 처리하고, 이후 스프린트에서 근본 개선을 예약했습니다.
트레이드오프 결정에서 가장 중요한 건 선택 기준을 팀이 공유하는 것이었는데, 근거 있게 미루는 것과 그냥 미루는 것은 이후 처리 확률에서 달랐습니다. 지금도 기술 결정 전에 영향 범위를 먼저 숫자로 정리하는 습관을 유지하고 있습니다.
트레이드오프를 판단해야 할 때 가장 어려운 상황은 결과를 예측하기 어려운 경우였습니다. 팀 프로젝트에서 기술 스택을 바꾸는 것이 일정에 어느 정도 영향을 줄지 제가 직접 판단하기 어려운 시점이 있었습니다.
팀장 역할을 맡고 있던 팀원에게 솔직하게 불확실한 부분을 전달하고, 유사한 전환 경험이 있는지 물었습니다. 그 팀원이 이전 프로젝트에서 비슷한 전환을 했을 때 예상보다 두 배 이상 시간이 걸렸다는 경험을 공유해줬고, 그 정보가 제 판단에 결정적인 기준이 됐습니다.
이 경험에서 배운 것은 내가 모르는 정보를 가진 사람에게 묻는 것이 판단 품질을 높이는 가장 빠른 방법이라는 점입니다. 혼자 판단하려는 욕구가 있었지만, 경험 없는 자리에서 혼자 판단하는 것보다 경험자에게 확인하는 것이 훨씬 빠르고 안전하다는 결이 남아 있습니다.
트레이드오프를 결정하고 나서 그 결정이 왜 그 시점에 그 방향으로 이뤄졌는지 기록해두는 것이 이후에 중요해지는 경험을 했습니다.
데모 이후 보강하기로 미뤄둔 기능이 있었는데, 두 스프린트가 지나자 팀 내에서 왜 그것을 미뤘는지 기억하는 사람이 없었습니다. 다시 꺼내야 할 시점에 그 기능을 미룬 이유와 당시 조건을 알 수 없으니, 우선순위를 정하는 논의가 처음부터 반복됐습니다.
이 경험 이후 트레이드오프 결정을 내릴 때 이유와 조건을 짧게 기록해두는 습관을 만들었습니다. '지금 미루는 이유와 다시 꺼낼 조건'을 한 줄씩 남겨두면, 나중에 우선순위를 재검토할 때 처음부터 논의를 반복하지 않아도 됩니다. 결정 자체보다 결정 맥락을 보존하는 것이 팀 운영에서 더 오래 남는 가치라는 생각이 이 경험에서 자리 잡혔습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.