이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
문제 중심으로 의사결정을 내린 사례는 기능 개발 중 예상보다 성능이 나오지 않는 상황에서였습니다. 해결 방향으로 캐시 추가와 쿼리 최적화 두 가지가 제안됐는데, 근본 원인이 어디인지를 먼저 파악하지 않으면 잘못된 방향에 시간을 쓸 수 있었습니다. 프로파일링으로 원인을 확인한 뒤 쿼리 최적화를 먼저 진행했습니다.
결정 과정에서 중요하게 생각한 것은 각 선택지가 문제를 얼마나 직접적으로 해결하는가였습니다. 구현이 간단하거나 익숙한 방법보다 실제 병목 원인에 가장 가까운 해결책을 선택하려 했고, 그 이유를 팀과 공유하면서 납득을 구했습니다.
결정 후에는 이유와 판단 근거를 PR이나 문서에 짧게 기록했습니다. 시간이 지나면 왜 그렇게 결정했는지 잊어버리는 경우가 많아, 나중에 코드를 보는 사람이 맥락을 파악할 수 있도록 하는 것이 팀 전체의 의사결정 비용을 줄이는 방법이었습니다.
의사결정에서 가장 어렵게 느낀 것은 기능을 줄이는 결정이었습니다. 팀이 기획한 기능 중 하나가 예상보다 복잡하다는 것을 중반에 알게 됐는데, 그 기능을 유지하면 다른 핵심 기능의 완성도가 낮아질 상황이었습니다. 원인을 분석하니 설계 방향을 바꿔야 했고, MVP 기준으로 핵심 기능과 보완 기능을 재분류해 보완 기능을 다음 스프린트로 미루는 제안을 팀에 했습니다.
팀원들이 처음에는 아쉬워했지만, 기준을 사용자에게 두고 설명하니 납득이 빠르게 됐습니다. 유연함은 처음 계획을 고집하지 않는 것이 아니라 기준을 명확히 하고 설명하는 것이라는 것을 배웠습니다.
팀 내 의사결정이 어려웠던 또 다른 상황은 두 팀원이 서로 다른 기술 선택을 강하게 주장하는 경우였습니다. 각자 경험이 달라서 선호가 달랐는데, 어느 쪽이 옳은지 기술적으로 판가름하기 어려운 상황이었습니다. 의견을 더 많이 주장하는 쪽이 이기는 방식을 피하고, 두 선택지를 각각 작은 PoC로 구현해보고 성능을 직접 비교하는 방식을 제안했습니다.
하루 만에 나온 PoC 결과로 방향이 결정됐고, 선택받지 못한 팀원도 데이터로 결정됐기 때문에 불만이 없었습니다. 이견이 클수록 의견이 아니라 근거를 만들어 비교하는 것이 가장 빠른 해결 방법이라는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.