이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 Business Driven Development가 중요한 이유는 기술적 완성도와 비즈니스 가치가 항상 같은 방향이 아닐 수 있기 때문이라고 봅니다. 인턴 때 코드 품질만 보고 리팩터링에 2주를 썼는데, 정작 사용자가 원한 기능은 2일이면 만들 수 있는 다른 것이었던 경험이 있습니다. 이후로는 구현 전에 이 기능이 어떤 지표를 움직이는가를 먼저 정의하는 방식으로 바꿨습니다. 작업 카드에 비즈니스 목표와 성공 기준을 항상 적고, 기술 선택이 그 목표를 어떻게 뒷받침하는지 설명하는 습관을 만들었습니다. 다만 단기 성과 중심 사고가 과하면 기술 부채가 쌓이는 역효과가 있어서, 두 관점을 균형 잡는 것이 중요하다고 봅니다.
프로젝트에서 기능을 구현하기 전에 기획자에게 이 기능이 왜 필요한지를 먼저 물어보는 습관을 만들었습니다. 처음에는 요구사항 문서만 보고 구현했는데, 나중에 보니 문서에 없는 맥락이 있었고 그 맥락을 알았다면 다른 방식으로 구현했을 것들이 있었습니다. 기획 배경을 파악하고 나서 기술 결정을 하니 어떤 부분에 더 신경 써야 하는지가 명확해졌고, 불필요한 기능을 먼저 만드는 경우가 줄었습니다. Business Driven Development는 비즈니스 맥락을 먼저 이해하고 그것을 기준으로 기술 결정을 하는 것이고, 그 순서가 바뀌면 기술적으로 잘 만든 것이 비즈니스 문제를 해결하지 못하는 경우가 생긴다는 것을 이 경험에서 배웠습니다. 다만 기획 배경을 이해하는 데 시간을 너무 많이 쓰면 실행 속도가 느려질 수 있어서, 어느 정도 파악한 후 빠르게 만들어보는 것과 균형을 잡는 것이 필요하다는 것도 알게 됐습니다.
팀 프로젝트에서 각자 기능을 개발하다 보니 왜 이 기능이 필요한지를 팀원마다 다르게 이해하는 경우가 생겼습니다. 같은 기능을 만들면서 접근 방식이 달라지는 경우가 있었는데, 알고 보니 비즈니스 목표에 대한 이해가 달랐던 것이 원인이었습니다. 작업을 시작할 때 이 기능이 어떤 목표를 위한 것인지를 팀 전체가 같은 수준으로 이해하는 시간을 갖는 것이 필요하다는 것을 알게 됐습니다. Business Driven Development는 개인이 비즈니스 맥락을 이해하는 것만이 아니라 팀이 같은 목표를 공유하는 것이고, 그 공유 없이는 각자 다른 방향으로 좋은 기술적 결정을 하는 상황이 생긴다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.