본문으로 건너뛰기
  1. 포스트/

개발자 면접에서 STAR 방식을 쓰는 이유

· loading · loading ·
인재덕
작성자
인재덕
서울에 거주하는 리더 겸 소프트웨어 엔지니어

올해 엔지니어링 매니저가 되면서 채용하는 쪽 자리에 앉는 일이 부쩍 많아졌습니다. 그러면서 가장 크게 느낀 점은, 후보자에게 이력서를 자유롭게 설명하게 하는 것만으로는 알 수 있는 게 거의 없다는 겁니다. 이력서를 보면 “무엇을 했는지"는 알 수 있죠. 하지만 “어떻게 일하는 사람인지"는 좀처럼 보이지 않습니다.

그 간극을 메우는 데 제일 도움이 된 도구가 STAR 포맷 기반의 행동 면접입니다. STAR는 Situation(상황), Task(과제), Action(행동), Result(결과)의 약자로, 후보자에게 실제 겪은 이야기를 들으면서 이 네 가지를 차례로 짚어가는 방식입니다. 딱 봐도 HR 교육 자료 냄새가 나고, 실제로도 그렇습니다만, 구체성을 강제한다는 게 이 틀의 힘입니다. 시그널은 결국 구체적인 디테일 안에 있으니까요.

좋은 답변의 모양
#

“복잡한 버그를 해결했던 경험을 말씀해 주세요” 같은 질문을 예로 들면, 듣고 싶은 건 이렇습니다. 당시 상황(무슨 일이 있었고 왜 중요했는지), 후보자 본인이 맡았던 과제, 실제로 한 행동(“우리가"가 아니라 “제가”), 그리고 결과. 숫자가 붙어 있으면 더 좋습니다.

강한 답변은 대략 이런 느낌입니다(기술 부채 사례):

“배포 파이프라인이 45분씩 걸렸고, 불안정한 테스트 때문에 개발자들이 빌드를 여러 번 다시 돌려야 했습니다. 한 달치 손실 시간을 집계해 보니 1인당 약 15시간이더군요. 이 데이터를 경영진에 보여주고, 테스트 병렬화와 가장 불안정한 테스트 수정에 2개 스프린트를 투자하자고 제안했습니다. 그 결과 배포 시간은 12분으로 줄었고, 배포 빈도는 두 배가 됐습니다.”

상황, 과제, 행동, 결과가 다섯 문장 안에 다 들어 있고, 본인의 기여가 뭔지도 분명합니다. “파이프라인이 느려서 고쳤습니다"라는 답변 옆에 놓고 보면, 이 틀이 왜 쓸모 있는지 바로 보이죠.

자주 꺼내 쓰는 질문들
#

모든 걸 다 확인하려 하기보다, 지금 팀에 필요한 역량을 중심으로 질문을 정리해 둡니다:

역량질문
문제 해결“압박 속에서 프로덕션 이슈를 디버깅한 경험을 말씀해 주세요.”
협업“까다로운 이해관계자와 일해야 했던 프로젝트를 설명해 주세요.”
기술 리더십“직접적인 권한 없이 기술적 의사결정에 영향을 미친 경험을 말씀해 주세요.”
학습 민첩성“익숙하지 않은 기술을 빠르게 익혀야 했던 때를 설명해 주세요.”
오너십“본인이 만든 것이 실패했던 경험을 말씀해 주세요. 그때 어떻게 하셨나요?”

마지막 질문을 제일 좋아합니다. 실패를 어떻게 이야기하는지가 성공담 세 개보다 많은 걸 알려주고, 미리 대본을 준비하기도 어려운 질문이거든요.

면접의 본게임은 후속 질문
#

후보자가 처음부터 STAR 흐름대로 완벽하게 답하는 경우는 거의 없습니다. 그래도 괜찮습니다. 후속 질문이야말로 면접의 본게임이니까요. “성능을 개선했습니다"라고 하면 얼마나, 어떻게 측정했는지 물어봅니다. 계속 “우리"라고만 하면 본인은 정확히 뭘 했는지 물어봅니다. 이야기가 이상하리만치 깔끔하게 마무리되면, 다음에 같은 상황이 오면 뭘 다르게 할 건지 물어보고요.

시간이 꽤 걸려서 배운 교훈이 하나 더 있습니다. 모든 후보자에게 같은 질문을 하고, 단순한 기준표로 채점하는 겁니다. 기계적으로 느껴지긴 하지만, 공정하게 비교할 방법은 이것뿐입니다. 안 그러면 결국 가장 최근에 이야기한 사람의 인상에 끌려가게 되더군요.

물론 이걸로 기술 평가가 필요 없어지는 건 아닙니다. 실제로 뭔가를 만들 수 있는 사람인지는 따로 확인해야 하죠. 다만 가정형 질문은 말로 넘어갈 수 있어도, 과거의 행동은 꾸며내기 어렵습니다. 1년 가까이 면접을 진행해 보니, 잘 다듬어진 “장단점” 답변보다 꼼꼼히 파고든 실제 이야기가 훨씬 믿을 만하다는 걸 느낍니다.

참고 자료
#

이 사이트의 관련 글:

외부 리소스: