이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 기술 스택을 결정하기 전에 선행 기술 조사(기술 리서치)를 처음으로 체계적으로 진행한 경험이 있습니다. 처음엔 블로그 글 몇 개를 읽고 결정했는데, 나중에 실제 프로덕션 사례에서 발생하는 문제를 미리 파악하지 못해 후반에 설계를 바꾸는 경우가 생겼습니다. 이후 조사 순서를 공식 문서와 릴리스 노트 → 실제 사용 사례 → 대안 비교로 정하고, 결정 기록(ADR) 문서를 남겨 선택 근거를 기록하기 시작했습니다.
기술 조사에서 가장 중요한 건 찬성 의견만 모으는 게 아니라 알려진 한계와 실패 사례를 찾는 것이었는데, 이 관점이 기술 부채를 줄이는 데 도움이 됐습니다. 지금도 새 기술을 도입할 때 단점을 먼저 조사하는 순서를 지킵니다.
기술 조사를 할 때 처음엔 "이게 좋다"는 결론을 먼저 정해놓고 근거를 찾는 방식으로 접근했습니다. 장점만 나열하니 팀에서 "단점은 없나요?"라는 질문에 대답을 못하는 자리가 생겼습니다.
이후엔 조사 순서를 바꿔 단점과 한계를 먼저 찾는 방식으로 전환했습니다. GitHub Issues와 공식 문서의 Known Limitations 섹션을 먼저 읽고, 그걸 팀 상황에 적용했을 때 어느 정도 문제인지를 판단했습니다. 이 방식이 팀 설득에 훨씬 효과적이었습니다.
이 경험으로 기술 조사는 선택지를 지지하는 근거가 아니라 반박할 수 없는 약점을 찾는 것부터 시작된다고 생각합니다.
선행 기술 조사에서 논문과 공식 문서는 잘 됐을 때의 이야기를 주로 담는다는 한계를 느꼈습니다. 새 기술을 도입할 때 실제 운영 환경에서 겪는 문제는 논문에 잘 안 나옵니다.
그래서 GitHub Issues·커뮤니티 포럼·블로그 운영 후기를 함께 찾는 방식을 추가했습니다. "이걸 실제로 쓰다가 포기한 사람이 있는가"를 찾는 것이 도입 결정에서 가장 솔직한 신호가 됐습니다.
이 경험으로 선행 기술 조사의 완성도는 긍정 자료의 양이 아니라 실패 사례를 얼마나 찾았는가로 결정된다고 생각합니다. 정보가 없는 것과 잘 숨겨진 것은 다릅니다. 조사의 깊이는 얼마나 불편한 사실을 찾으려 했는가로 결정됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 경영기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.