이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
공식 팀 리더 역할을 맡은 적은 없지만, 4인 팀 프로젝트에서 팀장이 중간에 빠지면서 제가 자연스럽게 일정 조율을 맡게 되었습니다.
가장 어려웠던 것은 두 팀원이 기술 선택을 놓고 의견이 갈려서 진행이 멈춘 상황이었습니다. 한 명은 Vue, 다른 한 명은 React를 주장했는데, 서로 양보를 하지 않고 있었습니다.
각자 왜 그 기술을 선호하는지를 5분씩 설명하고, 팀 결정 기준(학습 시간, 팀 경험, 생태계)을 함께 정한 다음 투표를 진행하였습니다. 결론보다 기준을 먼저 합의하는 것이 더 중요하다는 것을 그때 배웠습니다. 이후에는 기술 논쟁이 발생하더라도 기준부터 정하는 습관이 생겼습니다.
인턴 때 팀 내 코드 리뷰 문화를 만드는 작업을 도왔는데, 처음엔 리뷰 피드백이 직접적이어서 받는 사람이 기분 나빠하는 문제가 있었어요. 두 팀원 사이에 감정이 상해서 리뷰를 서로 안 하는 상황까지 됐습니다.
따로 한 명씩 만나서 이야기를 들었어요. 알고 보니 한 명은 빠른 피드백을 선호하고, 다른 한 명은 설명이 있는 피드백을 원하고 있었는데, 스타일 차이를 서로 몰랐던 거였습니다.
코드에 대한 지적은 코드의 ~부분이 ~이유로 ~하면 좋을 것 같다는 형식으로 작성하는 리뷰 가이드라인 1페이지를 만들었어요. 이후 분위기가 나아졌습니다. 갈등은 나쁜 의도가 아니라 서로 다른 기대에서 오는 경우가 많다는 걸 배웠어요.
공식 팀 리더 경험은 없지만, 팀 프로젝트를 여러 번 하면서 리더가 어떤 상황에서 팀을 잘 이끄는지 옆에서 배운 것이 많아요.
가장 기억에 남는 건, 프로젝트 막바지에 일정이 빠듯해지면서 팀원들이 서로 눈치만 보던 상황이에요. 당시 비공식 리더 역할이던 팀원이 "각자 오늘 뭘 할 수 있는지 솔직하게 얘기하자"고 했고, 그 한 마디가 분위기를 바꿨어요. 숨기고 있던 블로커가 2개 나왔고, 다른 팀원이 30분 만에 해결해줬습니다.
그때 배운 건, 어려운 상황일수록 상태를 투명하게 공유하는 게 먼저라는 거예요. 저도 앞으로 팀 프로젝트에서 어려운 상황이 오면 숨기거나 혼자 해결하려 하기보다 먼저 상황을 열어두는 접근을 쓰고 싶습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 비즈테크아이 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.