면접 피드백 이후 다시 본 STAR 기법: 개발자 면접에서 경험을 더 잘 설명하려면

이 글은 면접 피드백 이후 내가 다시 정리한 것들: 부족함을 공부 계획으로 바꾼 회고에서 이어지는 글이다.

앞선 글에서 나는 최근 면접 피드백을 통해 무엇이 부족했는지 먼저 정리했다. 답변이 길어지는 문제, 기술 선택의 근거를 충분히 설명하지 못했던 문제, 그리고 생각한 방식과 실제 구현한 방식 사이의 간극을 정리하지 못했던 문제가 그것이었다.

그 글이 "무엇이 부족했는가"를 적어본 글이었다면, 이 글은 "그 부족함을 어떤 방식으로 보완해볼 수 있을까"를 고민하며 다시 보게 된 STAR 기법에 대한 기록이다.

면접을 준비하면서 새삼 느낀 게 하나 있다.

나는 경험이 아예 없는 편은 아니었는데, 그 경험을 면접에서 설명하는 방식은 생각보다 많이 정리되어 있지 않았다. 말이 길어지기도 했고, 기술 선택의 이유를 설명한다고 하면서도 결과만 말하는 경우가 많았다.

그 과정에서 다시 보게 된 것이 STAR 기법이었다.

사실 예전의 나는 STAR를 조금 뻔한 면접 프레임워크처럼 봤다. 이미 해본 경험이 있다면 그때그때 잘 설명하면 된다고 생각했고, 굳이 형식까지 빌려야 하나 싶었다.

그런데 최근 면접들을 지나며 생각이 달라졌다. 나는 분명 무언가를 해본 경험이 있었는데, 막상 질문을 받으면 그 경험이 상대에게 설득력 있게 전달되지 않았다. 그때부터 STAR가 단순한 답변 공식이 아니라, 내 경험을 빠뜨리지 않고 구조화하는 기준처럼 보이기 시작했다.

면접에서 경험을 설명할 때 가장 자주 생기는 문제는 두 가지다.

말이 길어지는데 핵심이 잘 안 남는다
경험은 있는데, 왜 그 선택을 했는지가 설득력 있게 들리지 않는다

이럴 때 가장 현실적으로 도움이 되는 프레임워크 중 하나가 STAR 기법이다.

많은 사람이 STAR를 인성 면접이나 일반적인 행동 질문에만 쓰는 방식으로 이해한다. 하지만 개발자 면접에서도 충분히 강력하다. 오히려 프로젝트 경험, 장애 대응, 성능 개선, 아키텍처 선택, 협업 갈등 같은 질문에서는 더 유용할 때가 많다.

이 글은 "내가 STAR를 완벽하게 적용했다"는 이야기가 아니다. 오히려 몇 번의 면접을 지나며 내 답변의 한계를 체감한 뒤, STAR를 공부하면서 내가 무엇을 놓치고 있었는지, 그리고 앞으로 개발자 면접에서 어떤 질문들에 어떻게 써볼 수 있을지 정리해보는 글에 가깝다.

STAR 기법이란 무엇인가

STAR는 아래 네 요소의 앞글자를 딴 답변 구조다.

Situation: 어떤 상황이었는가
Task: 그 상황에서 내가 맡은 과제는 무엇이었는가
Action: 내가 실제로 무엇을 했는가
Result: 그 결과는 어땠는가

이 구조가 좋은 이유는 단순하다. 면접관이 궁금한 순서와 크게 다르지 않기 때문이다.

대부분의 면접관은 어떤 경험을 들을 때 사실상 아래를 확인하고 있다.

맥락을 이해하고 있는가
본인의 역할이 분명한가
문제를 해결하는 방식이 논리적인가
결과를 해석할 수 있는가

STAR는 이 네 가지를 빠뜨리지 않도록 도와준다.

개발자 면접에서 STAR가 특히 중요한 이유

개발자 면접에서는 단순히 "이런 걸 해봤다"는 사실만으로는 부족한 경우가 많다. 구현 경험이 있는지보다, 그 경험을 구조적으로 설명할 수 있는지가 더 중요하게 평가되기 때문이다.

예를 들어 아래 질문들은 모두 STAR로 정리할 수 있다.

가장 어려웠던 버그를 어떻게 해결했나요?
상태 관리 라이브러리를 왜 그렇게 선택했나요?
성능 문제를 발견했을 때 어떤 방식으로 접근했나요?
팀 내 의견 충돌이 있었을 때 어떻게 풀었나요?
보안 이슈나 인증 구조를 어떻게 설계했나요?

즉, STAR는 단순한 답변 템플릿이 아니라 경험을 설명 가능한 단위로 압축하는 도구에 가깝다.

개발자 면접용으로 STAR를 조금 다르게 써야 하는 이유

다만 개발자 면접에서는 STAR를 그대로 기계적으로 쓰기보다, 약간 변형해서 쓰는 편이 좋다.

왜냐하면 개발자 면접은 보통 아래 요소를 더 중요하게 보기 때문이다.

기술 선택의 근거
대안 비교
제약 조건
트레이드오프
정량적 혹은 정성적 결과
회고와 학습

그래서 나는 개발자 면접에서는 사실상 아래처럼 확장해서 쓰는 것이 더 좋다고 생각한다.

Situation: 어떤 문제와 제약이 있었는가
Task: 내 책임 범위와 성공 기준은 무엇이었는가
Action: 어떤 대안 중 무엇을 왜 선택했고, 실제로 어떻게 실행했는가
Result: 결과는 어땠고, 무엇을 배웠으며, 지금 다시 하면 무엇을 바꿀 것인가

즉, 개발자 면접에서 중요한 것은 Action과 Result를 얇게 말하지 않는 것이다.

STAR를 공부하면서 내가 배운 것

STAR를 보면서 새롭게 배운 내용이 아주 대단한 것은 아니었다. 그런데 막상 내 답변에 대입해보니, 내가 자주 빠뜨리던 지점이 꽤 선명하게 보였다.

어쩌면 이게 내가 STAR를 다시 보게 된 가장 큰 이유였는지도 모르겠다. 새로운 비법을 배웠다기보다, 이미 알고 있던 경험들을 왜 면접에서 제대로 꺼내지 못했는지 설명해주는 언어를 찾은 느낌에 더 가까웠다.

1. 나는 보통 Situation보다 Action부터 말하려고 했다

면접에서 긴장하면 빨리 뭔가를 보여줘야 한다는 생각이 든다. 그래서 "제가 뭘 했는지"부터 먼저 말하게 된다.

그런데 그러면 듣는 사람 입장에서는 이런 궁금증이 바로 생긴다.

왜 그 문제가 중요했는가
어떤 제약이 있었는가
왜 그 선택이 필요했는가

즉, Situation이 약하면 Action도 설득력을 잃는다.

2. Task를 말하지 않으면 경험이 내 것이 아니게 된다

팀 프로젝트 경험을 말할 때는 특히 이 문제가 컸다. "우리 팀이 이렇게 했습니다"라고 말하면 얼핏 풍부해 보이지만, 정작 내 역할은 흐려진다.

Task를 분명히 적어보면서 알게 됐다. 면접관이 궁금한 것은 프로젝트 전체보다도, 그 안에서 내가 어떤 책임을 맡고 어떤 기준으로 움직였는가였다.

3. 개발자 면접에서 가장 중요한 건 결국 Action의 밀도였다

개발자 면접에서 Action은 단순히 "무엇을 했다"가 아니었다.

어떤 선택지를 봤는가
왜 그 선택을 했는가
무엇을 포기했는가
어떤 문제를 만나서 어떻게 조정했는가

이런 내용이 빠지면 기술 경험이 있어도 설명이 얕아진다. 나는 이 부분을 가장 많이 놓치고 있었다.

4. Result는 성과 자랑이 아니라 해석과 학습까지 포함해야 했다

예전에는 Result를 숫자나 성공 사례로만 생각했다. 그런데 실제로는 "그래서 무엇이 달라졌는가", "무엇이 한계였는가", "지금 다시 하면 무엇을 바꿀 것인가"까지 포함되어야 답변이 훨씬 살아난다.

이 부분에서 느낀 건, STAR는 면접 스킬이기도 하지만 동시에 회고 프레임워크이기도 하다는 점이다.

5. 기준을 먼저 말해야 사례가 흔들리지 않는다

이번에 특히 많이 배운 것은, 사례를 먼저 던지면 오히려 답변이 불안정해질 수 있다는 점이었다.

예를 들어 어떤 저장 전략이나 상태 전달 방식을 설명할 때, 실무에서 겪은 사례를 먼저 꺼내면 면접관은 곧바로 "그 선택의 기준이 뭐였나요?"를 떠올리게 된다. 이때 기준이 뒤늦게 나오면, 잘못하면 앞의 사례와 뒤의 설명이 어긋나 보일 수 있다.

그래서 지금은 STAR를 쓸 때도 아래 순서를 더 의식하려고 한다.

먼저 상황 속 판단 기준을 짧게 정의한다
그 기준에 맞는 선택지를 비교한다
실제 사례는 그 뒤에 붙인다
이상적이지 않았던 선택은 트레이드오프로 설명한다

결국 좋은 답변은 사례가 많은 답변이 아니라, 기준과 사례가 잘 연결된 답변이라는 걸 배웠다.

각 단계에서 무엇을 말해야 하나

1. Situation: 배경을 길게 말하지 말고 문제를 선명하게 말하기

많은 사람이 Situation에서 이미 말을 길게 해버린다. 프로젝트의 전체 배경, 팀 구성, 서비스 설명을 너무 오래 하다 보면 정작 본론에 들어가기 전에 집중력이 떨어진다.

개발자 면접에서 좋은 Situation은 아래를 빠르게 드러낸다.

어떤 제품/기능 맥락이었는가
무엇이 문제였는가
어떤 제약이 있었는가

예를 들면 아래처럼 말할 수 있다.

"사용자 인증이 필요한 서비스였는데, 액세스 토큰 만료 시 재로그인이 자주 발생해서 이탈이 생기고 있었습니다. 백엔드 API 스펙은 일부 고정되어 있었고, 프론트엔드에서 우선 사용자 경험을 개선해야 하는 상황이었습니다."

여기서 중요한 건 서비스 소개가 아니라, 문제와 제약을 짧게 보여주는 것이다.

2. Task: 내가 맡은 역할을 분명하게 말하기

면접에서 의외로 자주 놓치는 부분이 Task다.

특히 팀 프로젝트 경험을 말할 때 "우리 팀이 했습니다"만 반복하면, 면접관은 결국 "그래서 본인은 뭘 했나요?"를 다시 물을 수밖에 없다.

Task에서는 아래를 분명히 하는 것이 좋다.

내 책임 범위
내가 해결해야 했던 핵심 과제
성공 기준

예를 들면 이렇게 말할 수 있다.

"제 역할은 프론트엔드 인증 흐름을 설계하고, 토큰 갱신 시점과 예외 처리 로직을 정리하는 것이었습니다. 목표는 사용자가 작업 중 세션 만료로 흐름이 끊기지 않게 하면서도, 보안상 위험한 저장 방식을 피하는 것이었습니다."

이 단계가 분명해야 뒤의 Action이 본인 경험으로 받아들여진다.

3. Action: 개발자 면접의 핵심은 여기 있다

개발자 면접에서 가장 중요한 단계는 거의 항상 Action이다.

여기서는 "무엇을 했다"만 말하면 부족하다. 아래까지 포함되어야 답변의 밀도가 올라간다.

어떤 선택지가 있었는가
무엇을 선택했는가
왜 그렇게 선택했는가
구현하면서 어떤 문제를 만났는가
어떤 기준으로 조정했는가

예를 들면 이렇게 말할 수 있다.

"처음에는 단순히 토큰 만료 시 로그인 페이지로 보내는 방식도 가능했지만, 사용자 경험이 너무 나빠지는 문제가 있었습니다. 그래서 액세스 토큰 재발급 흐름을 별도로 두고, 요청 인터셉터에서 만료를 감지하면 갱신 후 원래 요청을 재시도하는 구조로 바꿨습니다. 다만 이 과정에서 무한 재시도와 동시 요청 경쟁 상태를 막기 위해 재발급 큐와 실패 시 로그아웃 처리 조건을 함께 뒀습니다."

이 문장은 단순 구현 설명이 아니라, 판단 과정이 드러나는 Action이다.

여기서 내가 특히 중요하게 느낀 건, Action은 "한 일"을 나열하는 칸이 아니라는 점이다.

오히려 이 단계에서는 아래 질문에 답할 수 있어야 한다.

무엇을 기준으로 선택했는가
왜 다른 선택지는 택하지 않았는가
이상적이지 않은 선택이었다면 무엇을 보완했는가

즉, 개발자 면접에서 좋은 Action은 구현 로그가 아니라 판단 로그에 가깝다.

4. Result: 결과 숫자만 말하지 말고 해석까지 붙이기

Result를 "그래서 잘 됐습니다" 수준으로 마무리하면 면접 답변이 금방 약해진다.

좋은 Result는 아래 중 일부라도 포함하면 좋다.

정량적 변화
사용자 경험 변화
팀 협업 측면의 개선
운영 안정성 변화
남은 한계
이후의 학습

예를 들면 이렇게 정리할 수 있다.

"그 결과 세션 만료로 인한 재로그인 빈도가 줄었고, 사용자가 작업 중 흐름이 끊기는 케이스를 완화할 수 있었습니다. 다만 당시 구현은 백엔드 스펙 제약 때문에 이상적인 구조는 아니었고, 이후에는 쿠키 기반 전략과 토큰 노출 범위에 대해 더 깊이 공부하게 됐습니다."

이렇게 말하면 성공 사례를 과장하지 않으면서도, 회고 능력까지 보여줄 수 있다.

앞으로 이런 질문들에 STAR를 써볼 수 있겠다고 느꼈다

STAR를 공부하면서 좋았던 점은, 막연히 "면접 답변을 잘해야지"가 아니라 "아, 이 질문에는 이렇게 써볼 수 있겠구나"가 보였다는 점이다.

특히 아래 질문들은 개발자 면접에서 자주 나오기도 하고, STAR로 정리했을 때 답변의 밀도가 높아질 가능성이 크다고 느꼈다.

1. 디자인 시스템 Form 요소와 제어/비제어 컴포넌트 질문

예를 들면 이런 질문이다.

디자인 시스템에서 Form 요소는 어떻게 설계하셨나요?
제어 컴포넌트와 비제어 컴포넌트를 어떤 기준으로 나눠 보시나요?

이런 질문은 단순 React 개념 설명으로 끝내기 쉽다. 하지만 사실은 개념보다 실무 기준을 보여주기 좋은 질문이다.

이 질문에서 나는 앞으로 아래를 중심으로 말해보면 좋겠다고 느꼈다.

Situation: 디자인 시스템 차원에서 Form API 일관성이 필요했던 상황
Task: 여러 서비스 팀이 쉽게 사용할 수 있는 공통 인터페이스를 만드는 역할
Action: 기본은 제어 컴포넌트 패턴으로 가져가되, 파일 입력 같은 예외 요소는 DOM 제약을 고려해 비제어 접근도 허용한 이유
Result: 사용성은 좋아졌는지, 복잡도는 줄었는지, 그리고 무조건 한 방식으로 통일하는 것이 왜 위험한지도 함께 설명

즉, 이 질문은 "정답이 무엇인가"보다 "어떤 기준으로 나눴는가"를 보여주는 사례가 된다.

2. 모노레포 관리 질문

예를 들면 이런 질문이 가능하다.

모노레포를 왜 도입했나요?
모노레포를 운영하면서 가장 어려웠던 점은 무엇이었나요?

이 질문은 도구 이름을 아는지보다, 운영 관점에서 무엇을 배웠는지를 보여주기 좋다.

내가 앞으로 이 질문에 답한다면 아래처럼 정리해볼 수 있겠다고 느꼈다.

Situation: 여러 앱과 공통 패키지를 함께 관리해야 했고, 중복 코드와 설정 관리 비용이 커졌던 상황
Task: 공통화 효율을 얻으면서도 레포 경계가 무너지지 않게 운영 기준을 만드는 역할
Action: pnpm workspace, Turborepo, shared package 분리 전략, cache 범위와 dependency 방향을 함께 고려했던 이유
Result: 초기 세팅 속도나 공통 코드 재사용은 좋아졌지만, shared package가 과도하면 오히려 영향 범위가 커진다는 운영 교훈까지 설명

이런 질문은 "모노레포 써봤습니다"보다 "모노레포의 이점과 비용을 같이 이해하고 있습니다"를 보여주기 좋다.

3. 상태관리 라이브러리 선택 질문

이건 이미 자주 나오는 질문이기도 하다.

왜 Zustand를 선택했나요?
Redux, Zustand, React Query의 역할을 어떻게 나눠 보시나요?

이 질문은 STAR를 쓰기 좋다는 걸 가장 직관적으로 보여준다. 왜냐하면 결국 핵심은 선택의 이유, 대안 비교, 트레이드오프이기 때문이다.

여기서는 아래를 빠뜨리지 않는 것이 중요하다고 느꼈다.

Situation: 상태 복잡도, 팀 숙련도, 제품 속도 같은 배경
Task: 지금 필요한 수준의 상태관리를 선택해야 했던 책임
Action: Redux Toolkit, Zustand, server state 분리 같은 대안 중 무엇을 어떤 기준으로 골랐는지
Result: 초기 개발 속도, 유지보수성, 이후 구조 개선 필요성까지 솔직하게 설명

이 질문은 앞으로도 가장 많이 연습해봐야 할 주제 중 하나라고 느꼈다.

4. 인증과 토큰 관리 질문

내가 최근 회고에서 가장 크게 반성했던 주제이기도 하다.

인증 토큰 저장 전략을 어떻게 봤나요?
리프레시 토큰 갱신 흐름을 어떻게 설계했나요?

이 질문은 이론 답변으로 흘러가기 쉽지만, 사실은 제약과 리스크를 설명하기 좋은 질문이다.

그래서 나는 이 질문에서 아래를 함께 말해야겠다고 느꼈다.

어떤 사용자 경험 문제를 해결하려 했는가
어떤 보안 리스크를 고려했는가
당시 시스템 제약은 무엇이었는가
지금 다시 한다면 어떤 구조를 더 우선할 것인가

이 질문은 경험을 숨기지 않고, 한계까지 같이 설명하는 연습에 특히 도움이 될 것 같다.

5. 성능 개선이나 장애 대응 질문

이런 질문도 STAR와 잘 맞는다.

성능 문제를 발견하고 개선한 경험이 있나요?
운영 중 장애를 대응했던 경험이 있나요?

이 질문에서는 기술보다도 문제 해결 방식이 잘 드러난다.

Situation: 어떤 현상이 문제였는가
Task: 내가 해결해야 했던 범위는 어디까지였는가
Action: 어떻게 원인을 좁혔고 무엇을 바꿨는가
Result: 무엇이 개선됐고, 재발 방지를 위해 무엇을 남겼는가

이런 유형은 단순히 "문제 해결 경험"이 아니라, 내가 문제를 다루는 태도까지 보여줄 수 있는 질문이라고 느꼈다.

STAR를 개발자 면접에 적용할 때 자주 하는 실수

1. Situation이 너무 길다

배경 설명이 길어지면 본론이 묻힌다. 문제와 제약만 압축해서 말하는 편이 좋다.

2. Task가 빠져 있다

내 역할이 분명하지 않으면 팀 경험을 내 경험으로 받아들이기 어렵다.

3. Action에 근거가 없다

"이렇게 했습니다"만 있고 "왜 그렇게 했는가"가 없으면 기술 면접에서는 설득력이 떨어진다.

4. Result가 모호하다

결과가 수치가 아니어도 괜찮다. 대신 무엇이 좋아졌고, 무엇이 한계였는지는 말할 수 있어야 한다.

5. 실패나 한계를 숨기려고 한다

실무 경험은 늘 제약 속에서 이뤄진다. 완벽한 정답처럼 말하는 것보다, 당시 제약과 이후 학습을 솔직하게 설명하는 편이 오히려 신뢰를 준다.

6. 기준보다 사례를 먼저 말한다

사례를 먼저 말하면 답변이 생생해 보일 수는 있다. 하지만 기준이 뒤늦게 나오면, 실무 경험이 오히려 우연한 선택처럼 들릴 수 있다.

특히 기술 선택 질문에서는 아래 순서가 더 안정적이었다.

먼저 어떤 기준으로 판단했는지 말한다
그 기준에 따라 대안을 어떻게 봤는지 말한다
마지막에 실제 사례를 붙인다

이 순서가 잡히면, 실무에서 완전히 이상적이지 않았던 선택도 모순이 아니라 트레이드오프로 설명할 수 있다.

바로 써먹을 수 있는 답변 템플릿

아래 템플릿은 기술 면접에서 경험을 설명할 때 바로 써먹기 좋다.

템플릿 1. 프로젝트 문제 해결형

"당시 [상황/문제]가 있었고, 제 역할은 [내 책임]이었습니다.
선택지는 [대안]들이 있었는데, [근거] 때문에 [선택한 방식]을 택했습니다.
구현 과정에서는 [문제/제약]이 있었고, 이를 [구체적 액션]으로 풀었습니다.
결과적으로 [결과]가 있었고, 지금 다시 한다면 [배운 점/개선점]을 반영할 것 같습니다."

템플릿 2. 기술 선택형

"그 상황에서 중요한 기준은 [기준]이었습니다.
대안으로는 [대안 A], [대안 B]가 있었고, 저는 [선택안]을 골랐습니다.
이유는 [근거 1], [근거 2], [근거 3] 때문입니다.
대신 [트레이드오프]는 감수해야 했고, 실제로는 [결과/회고]로 이어졌습니다."

템플릿 3. 이상적이지 않은 선택을 설명할 때

"이상적으로는 [더 나은 방식]이 더 적절하다고 생각합니다.
다만 당시에는 [제약]이 있었고, 그래서 [실제 선택]을 했습니다.
그 대신 [보완책]을 함께 두었고, 결과적으로 [영향]이 있었습니다.
지금 다시 한다면 [개선 방향]을 더 우선할 것 같습니다."

예시: STAR 없이 말했을 때와 STAR로 말했을 때의 차이

예를 들어 상태관리 선택에 대한 질문을 받았다고 해보자.

STAR 없이 답하면

"Zustand를 썼습니다. Redux보다 가볍고 쓰기 편해서 선택했습니다. 프로젝트 규모가 그렇게 크지 않아서 잘 맞았습니다."

이 답변은 틀리진 않지만, 면접관 입장에서는 더 듣고 싶은 것이 많다.

왜 Redux는 과하다고 판단했는가
어떤 상태 규모였는가
팀 적응 속도는 어땠는가
장기 유지보수성은 어떻게 봤는가

STAR로 답하면

"당시 프로젝트는 전역 상태가 일부 필요했지만, 복잡한 비동기 오케스트레이션이나 엄격한 액션 패턴까지 요구하진 않았습니다. 제 역할은 빠르게 기능을 개발하면서도 팀원이 쉽게 이해할 수 있는 상태 관리 방식을 정하는 것이었습니다. 대안으로 Redux Toolkit도 검토했지만, 현재 요구사항 대비 보일러플레이트가 크다고 판단했습니다. 그래서 학습 비용이 낮고 필요한 수준의 전역 상태를 빠르게 구성할 수 있는 Zustand를 선택했습니다. 그 결과 초기 개발 속도는 좋아졌지만, 상태 경계가 커질수록 구조가 느슨해질 수 있다는 점은 이후 리팩터링 포인트로 남았습니다."

같은 경험이지만, 후자가 훨씬 더 많은 정보를 담고 있다.

STAR는 면접 기술이 아니라 회고 기술이기도 하다

STAR를 계속 써보면 흥미로운 변화가 하나 생긴다.

면접 답변만 좋아지는 것이 아니라, 프로젝트 회고 자체가 더 또렷해진다.

어떤 상황에서
무엇을 맡았고
왜 그렇게 행동했고
무엇을 얻었는지

이 네 가지가 정리되면, 경험은 단순한 "한 일 목록"이 아니라 재사용 가능한 사례집이 된다.

그래서 나는 면접 직전에만 STAR를 외우는 것보다, 평소 프로젝트를 정리할 때부터 STAR 구조로 메모해두는 편이 훨씬 실용적이라고 생각한다.

마무리

지금의 내게 STAR는 면접에서 잘 보이기 위한 요령이라기보다, 내가 해온 경험을 더 정직하고 선명하게 꺼내기 위한 도구에 가깝다.

최근 면접들을 겪으며 가장 아쉬웠던 건 "할 말이 없었다"는 점이 아니라, 분명히 해본 일인데도 충분히 납득 가능하게 전달하지 못했다는 점이었다. 그래서 이제는 새로운 답변 스킬을 덧붙이는 것보다, 내가 이미 가진 경험을 더 설명 가능한 형태로 정리하는 일이 먼저라고 느끼고 있다.

개발자 면접에서 좋은 답변은 화려한 표현에서 나오지 않는다. 맥락을 짧게 설명하고, 내 책임을 분명히 하고, 선택의 근거를 말하고, 결과와 배움을 정리할 수 있을 때 답변의 밀도가 올라간다.

STAR는 그 구조를 가장 단순하게 잡아주는 도구다.

특히 프로젝트 경험이 많은데도 설명이 길어지거나, 기술 선택의 이유를 말할 때 자꾸 두루뭉술해진다면 STAR는 꽤 강력한 기준이 될 수 있다.

면접에서는 새로운 경험을 만드는 것이 아니라, 이미 가진 경험을 더 설명 가능하게 만드는 일이 중요하다. 적어도 지금의 나에게는, 그 출발점을 다시 잡게 해준 것이 STAR였다.

결국 이 글에서 정리한 내용도 특별한 비법이라기보다, 앞선 회고에서 드러났던 부족함을 조금 더 구조적으로 보완해보려는 시도에 가깝다. 면접에서 더 많은 말을 하는 것보다, 더 정확한 기준과 더 정리된 경험으로 답하는 쪽으로 가고 싶다는 마음은 이 글을 쓰면서도 더 분명해졌다.