면접 피드백 이후 내가 다시 정리한 것들: 부족함을 공부 계획으로 바꾼 회고

최근 들어 면접 결과가 기대만큼 따라오지 않았다.

처음에는 "내가 준비가 부족했나?" 정도로만 생각했다. 그런데 몇 번의 결과를 지나고 나니, 막연한 자책보다 구체적인 문제를 정확히 짚는 일이 더 중요하다는 생각이 들었다. 다행히 한 면접에서 비교적 솔직하고 구체적인 피드백을 받을 수 있었고, 그 내용을 계기로 내 답변 방식과 기술 설명 방식을 다시 돌아보게 됐다.

이 글은 그 피드백을 그대로 옮기는 글은 아니다. 특정 회사나 면접 상황을 드러내기보다, 실제로 내가 받은 피드백을 익명화해서 정리하고, 그 안에서 반복적으로 드러난 부족함을 어떻게 공부 거리로 바꿨는지 남겨보려는 기록에 가깝다. 말하자면 이 글은 "무엇이 부족했는가"를 정리한 글이고, 다음 글인 면접 피드백 이후 다시 본 STAR 기법: 개발자 면접에서 경험을 더 잘 설명하려면은 "그 부족함을 어떤 방식으로 보완해볼 수 있을까"를 정리한 글에 가깝다.

면접에서 떨어졌다는 사실보다 더 중요했던 건, 그 결과가 앞으로 무엇을 고쳐야 하는지 알려주는 신호였다는 점이었다.

이 회고를 정리하면서 함께 다시 붙잡게 된 도구가 하나 있었는데, 바로 STAR 기법이다. 자세한 내용은 면접 피드백 이후 다시 본 STAR 기법: 개발자 면접에서 경험을 더 잘 설명하려면에서 따로 정리했지만, 돌아보면 이번 피드백에서 지적받은 문제 대부분은 STAR 구조로 답변을 정리했더라면 훨씬 나아졌을 가능성이 컸다.

내가 받은 피드백의 핵심

피드백을 한 문장으로 요약하면 이랬다.

"실무 경험과 학습 의지는 보이지만, 질문의 의도를 정확히 파악해 핵심만 전달하는 커뮤니케이션, 그리고 기술 선택의 근거를 논리적으로 설명하는 부분이 더 선명해질 필요가 있다."

조금 더 쪼개보면 크게 세 가지였다.

질문에 대한 답변이 길어질 때 핵심이 흐려진다.
기술 선택의 이유가 결과 중심으로만 말해져서 판단의 근거가 약하게 들린다.
생각한 방식과 실제 구현 방식 사이에 간극이 있을 때, 그 이유를 스스로 정리해서 설명하지 못한다.

돌이켜보면 셋 다 완전히 새로운 이야기는 아니었다. 다만 나는 그동안 이 문제를 "면접을 조금 더 잘 보면 되는 일" 정도로 가볍게 생각했다. 실제로는 면접만의 문제가 아니라, 개발자로서 의사결정을 설명하는 능력 자체의 문제에 가까웠다.

1. 질문의 의도를 확인하지 않고 답부터 시작했다

나는 기술 면접에서 질문을 들으면 빨리 답해야 한다는 압박을 자주 느꼈다. 그래서 질문이 나오면 곧바로 내가 아는 내용을 최대한 많이 말하려고 했다.

문제는 여기서 시작됐다.

면접관이 궁금한 것은 A인데, 나는 A와 관련된 B, C, D까지 한꺼번에 설명해버리는 경우가 많았다. 그러면 "많이 말한 사람"은 될 수 있어도, "정확히 답한 사람"이 되기는 어려웠다.

예를 들어 어떤 기술에 대해 질문을 받았을 때, 면접관은 보통 아래 중 하나를 묻고 있을 가능성이 높다.

실제로 써봤는지
왜 선택했는지
언제 쓰면 안 되는지
대안과 비교하면 어떤지
문제를 어떻게 해결했는지

그런데 나는 이 맥락을 분리하지 않고 한 번에 설명하려 했다. 그러다 보니 말은 길어지고, 정작 질문에 대한 직접적인 대답은 늦게 나왔다.

이걸 깨닫고 나서, 나는 답변하기 전에 질문의 범위를 짧게 확인하는 연습을 하기 시작했다.

"실무 적용 경험 중심으로 말씀드리면 될까요?"
"비교 관점에서 답드릴까요, 아니면 제가 선택한 이유 중심으로 말씀드릴까요?"
"구현 경험과 의사결정 근거를 나눠서 말씀드리겠습니다."

이 한 문장만 있어도 답변의 구조가 훨씬 선명해진다. 면접뿐 아니라 코드 리뷰나 협업 상황에서도 마찬가지였다. 상대가 듣고 싶은 범위를 먼저 맞춘 뒤 말해야 전달력이 생긴다.

2. 기술 선택의 근거를 "좋았다" 수준에서 멈췄다

피드백에서 가장 아프게 들어온 부분은 기술 판단의 근거였다.

나는 그동안 어떤 기술을 설명할 때 아래처럼 말하는 경우가 많았다.

"개발 속도가 빨랐습니다."
"팀에서 다루기 쉬웠습니다."
"구조가 깔끔해졌습니다."
"실무에서 많이 써서 선택했습니다."

이 말들이 틀린 것은 아니다. 하지만 면접에서는 이런 표현만으로는 부족하다. 중요한 것은 왜 그 판단이 그 상황에서 타당했는지다.

예를 들어 "개발 속도가 빨랐다"는 말도 아래 질문을 견뎌야 한다.

왜 빨랐는가
다른 대안보다 무엇이 단순했는가
단기 속도를 택하면서 포기한 것은 무엇인가
그 결정이 팀 생산성, 유지보수성, 성능, 보안 중 어디에 영향을 줬는가

그제야 나도 알게 됐다. 나는 기술을 "사용한 경험"은 있었지만, 그것을 "판단 가능한 문장"으로 정리하는 훈련은 충분히 하지 않았다.

그래서 최근에는 프로젝트를 복기할 때 아래 다섯 가지를 같이 적고 있다.

해결하려던 문제는 무엇이었는가
선택 가능한 대안은 무엇이었는가
내가 실제로 선택한 방식은 무엇이었는가
그 선택의 근거는 무엇이었는가
그 선택으로 감수한 트레이드오프는 무엇이었는가

예를 들면 예전에는 이렇게 말했을 것이다.

"상태 관리는 가볍게 쓰고 싶어서 Zustand를 선택했습니다."

지금은 최대한 이렇게 바꿔 말하려고 한다.

"전역 상태가 많지 않았고, Redux 수준의 보일러플레이트를 감수할 만큼 복잡한 요구사항은 아니었습니다. 팀원들이 빠르게 적응할 수 있고 번들 부담도 상대적으로 적은 선택지가 필요해서 Zustand를 택했습니다. 대신 미들웨어나 엄격한 패턴 강제는 약하기 때문에, 상태 경계가 커질 경우 구조가 흐트러질 수 있다는 점은 감수해야 했습니다."

같은 경험이라도, 근거와 트레이드오프가 들어가면 훨씬 설명 가능한 선택이 된다.

참고로 최근에는 여기서 한 단계 더 나아가, 사례보다 기준을 먼저 말하는 연습이 필요하다고 느끼고 있다.

예전의 나는 종종 실무 사례부터 꺼냈다. 그런데 그러면 듣는 사람 입장에서는 "그래서 이 사람의 기준이 무엇이었지?"가 뒤늦게 남고, 잘못하면 앞뒤가 어긋나 보이는 순간도 생긴다.

지금은 최대한 이런 순서를 의식하려고 한다.

먼저 판단 기준을 짧게 정의한다
그 기준에 맞는 사례를 꺼낸다
이상적이지 않았던 선택이 있었다면 왜 그렇게 갔는지 설명한다
그 선택의 한계와 더 나은 대안을 함께 말한다

예를 들어 URL에 상태를 두는 방식, 브라우저 히스토리 상태를 쓰는 방식, 전역 상태를 쓰는 방식은 모두 "써봤다/안 써봤다"의 문제가 아니다. 내가 지금은 아래처럼 먼저 기준을 설명해야 한다고 느낀다.

공유 가능성과 북마크 가능성이 필요한가
새로고침 이후에도 복원되어야 하는가
다루는 데이터가 민감한가
객체 구조가 단순한가, 아니면 직렬화 비용이 큰가

이 기준이 먼저 서야, 그 다음에 "그래서 이 상황에서는 query string이 아니라 다른 방식을 택했다"거나 "이상적이지 않지만 당시 스펙 제약 때문에 이렇게 갔다"는 설명도 정합성을 갖게 된다.

3. 생각한 방식과 구현한 방식의 간극을 설명하지 못했다

또 하나 크게 배운 건, 면접에서는 "정답 같은 이론"보다 내가 실제로 어떤 제약 속에서 무엇을 선택했는지를 더 정직하게 설명해야 한다는 점이다.

나는 과거 프로젝트에서 인증 관련 로직을 구현한 경험이 있었는데, 그 경험을 설명하는 과정에서 "이상적으로 생각하는 방식"과 "당시 실제로 구현한 방식" 사이의 차이를 충분히 정리하지 못했다.

돌이켜보면 이 간극을 숨기거나 흐리게 말할수록 오히려 더 어색해진다.

실무에서는 늘 제약이 있다.

기존 백엔드 스펙이 이미 정해져 있었을 수 있다.
짧은 일정 안에서 우선 동작하는 흐름을 먼저 만들어야 했을 수 있다.
팀 차원의 합의가 내 개인적 선호보다 우선했을 수 있다.
보안, 운영, DX 사이에서 완전한 해답이 아니라 상대적으로 나은 선택을 해야 했을 수 있다.

문제는 "제약이 있었다"는 사실 자체가 아니라, 그 제약이 결정에 어떤 영향을 줬는지 설명하지 못하는 것이었다.

더 정확히 말하면, 나는 한때 이런 순간을 "모순"처럼 느꼈다. 평소에는 보안이나 정합성 관점에서 지양해야 한다고 생각하던 방식이 있었는데, 실제 프로젝트에서는 이미 정해진 스펙이나 환경 제약 때문에 완전히 이상적이지 않은 구현을 택했던 적이 있었기 때문이다.

하지만 지금은 생각이 조금 달라졌다. 실무의 선택은 모순이라기보다, 대개 제약 속에서의 트레이드오프에 더 가깝다.

중요한 것은 "왜 그런 방식이 이상적이지 않았는지 알고 있었는가", "그럼에도 왜 그 선택을 했는가", "어떤 보완책을 같이 뒀는가", 그리고 "지금 다시 한다면 무엇을 다르게 할 것인가"를 설명할 수 있는가였다.

그래서 나는 최근 들어 기술 경험을 복기할 때 아래 질문을 함께 적고 있다.

내가 이상적으로 생각한 방식은 무엇이었는가
실제로 구현한 방식은 무엇이었는가
둘 사이의 차이가 생긴 이유는 무엇이었는가
지금 다시 한다면 무엇을 유지하고 무엇을 바꿀 것인가

이 질문을 적어보면, 단순히 "그때는 그렇게 했습니다"에서 끝나지 않는다. 경험이 반성문이 아니라 의사결정의 기록이 된다.

그래서 무엇을 바꿨는가

피드백을 받고 난 뒤 나는 면접 답변을 잘 포장하는 연습보다, 생각을 구조화하는 연습부터 다시 했다.

1. 답변 구조를 먼저 고정했다

지금은 가능한 한 아래 순서로 말하려고 한다.

질문의 범위를 짧게 확인한다
결론을 먼저 말한다
판단 근거를 2~3개로 압축한다
실제 사례를 붙인다
트레이드오프나 한계까지 말한다

예전의 나는 배경 설명을 길게 하다가 결론이 뒤늦게 나오는 편이었다. 지금은 오히려 결론이 먼저 나와야, 뒤의 설명이 모두 그 결론을 지지하는 문장으로 정리된다는 걸 느끼고 있다.

여기에 최근 하나를 더 붙였다. 바로 과제나 프로젝트의 맥락에서 먼저 답하고, 그 다음 일반론으로 확장하는 순서다.

면접에서는 종종 일반론을 잘 아는지보다, 지금 눈앞의 코드와 상황에서 왜 그런 선택을 했는지를 더 보고 싶어할 때가 많다. 그래서 지금은 먼저 "이 과제에서는 왜 이렇게 판단했는가"를 설명하고, 필요할 때만 "일반적으로는 이런 기준으로 본다"로 확장하는 편이 더 자연스럽다고 느낀다.

2. 프로젝트별 의사결정 로그를 만들었다

최근에는 주요 프로젝트를 다시 보면서 기술 선택 포인트를 따로 정리하고 있다.

왜 이 스택을 선택했는가
왜 이 상태관리 방식을 골랐는가
인증/권한 구조에서 무엇을 우선했는가
성능보다 개발 생산성을 우선한 순간은 언제였는가
반대로 생산성보다 안정성이나 보안을 우선한 순간은 언제였는가

면접은 새로운 이야기를 즉흥적으로 만들어내는 자리가 아니라, 이미 해본 경험을 정리된 언어로 꺼내는 자리에 더 가깝다. 그래서 이제는 경험을 "있다/없다"로만 보지 않고, "설명 가능한 상태인가"로 보고 있다.

3. 보안과 정합성 관점에서 구현 경험을 다시 공부했다

특히 인증과 토큰 흐름처럼 민감한 주제는, 예전에 구현해봤다는 사실만으로는 충분하지 않다고 느꼈다. 왜냐하면 이런 영역은 구현 자체보다 왜 그렇게 설계했는지가 더 중요하기 때문이다.

예를 들어 리프레시 토큰 전달 방식 같은 주제는 아래 관점에서 다시 공부했다.

URL 쿼리 파라미터에 실리는 값은 브라우저 히스토리, 로그, 분석 도구, 공유 링크 등에 남을 수 있다
보안상 민감한 값은 가능한 한 노출 범위를 최소화해야 한다
브라우저 환경에서는 HttpOnly, Secure, SameSite 설정이 포함된 쿠키 전략을 우선 검토해야 한다
헤더, 쿠키, 메모리, 스토리지 중 어디에 무엇을 둘지는 XSS, CSRF, 운영 편의성, 서버 구조까지 함께 봐야 한다

예전에는 "돌아가게 만들었다"는 사실에 만족했다면, 지금은 "이 방식이 어떤 리스크를 갖는가"까지 같이 말할 수 있어야 한다고 생각한다.

STAR로 다시 보면 무엇이 달라졌을까

회고를 쓰면서 가장 크게 느낀 건, 내가 부족했던 부분이 생각보다 STAR 구조와 잘 맞닿아 있었다는 점이다.

답변이 길어졌던 문제는 Situation을 짧게 압축하지 못했던 문제였다
내 역할이 흐려졌던 문제는 Task를 선명하게 설명하지 못했던 문제였다
기술 선택의 근거가 약했던 문제는 Action에서 선택과 이유를 충분히 설명하지 못했던 문제였다
배운 점이 흐릿했던 문제는 Result를 결과와 학습까지 연결하지 못했던 문제였다

즉, 나는 말을 많이 했지만 구조는 약했던 셈이다.

예를 들어 예전의 나는 인증 관련 경험을 아래처럼 설명했을 가능성이 높다.

"인증 토큰 갱신 로직을 구현해본 적이 있습니다. 만료되면 재발급하고 다시 요청하도록 처리했습니다. 실무에서 직접 구현해봐서 이런 부분은 익숙합니다."

이 답변은 경험이 있다는 사실은 전달하지만, 면접관 입장에서는 여전히 궁금한 것이 많다.

어떤 상황에서 그 문제가 중요했는가
내 역할이 정확히 무엇이었는가
왜 그런 구조를 선택했는가
어떤 제약과 리스크가 있었는가
결과적으로 무엇을 얻었고 무엇을 배웠는가

같은 경험도 STAR에 맞춰 다시 말하면 훨씬 다르게 들린다.

"당시 서비스에서는 액세스 토큰 만료 시 사용자가 작업 흐름을 자주 끊기고 있었고, 프론트엔드에서 이탈을 줄일 필요가 있었습니다. 제 역할은 인증 흐름을 정리하고, 만료 이후에도 사용자가 자연스럽게 작업을 이어갈 수 있게 만드는 것이었습니다. 단순히 로그인 페이지로 보내는 방식도 가능했지만 사용자 경험이 좋지 않았기 때문에, 토큰 재발급 후 원래 요청을 재시도하는 흐름을 선택했습니다. 다만 이 과정에서 무한 재시도와 토큰 노출 범위 같은 리스크가 있어 실패 조건과 저장 방식을 함께 검토했습니다. 그 결과 세션 만료로 흐름이 끊기는 문제를 줄일 수 있었지만, 이후에는 토큰 전달 방식과 보안 모델을 더 깊이 공부해야겠다는 과제도 분명해졌습니다."

이 차이를 보고 나니, 내가 왜 면접에서 경험이 있는데도 충분히 설득력 있게 전달하지 못했는지 조금 더 명확해졌다. 문제는 경험의 양이 아니라, 경험을 설명하는 구조의 부재에 더 가까웠다.

그래서 지금은 프로젝트를 복기할 때도 아래 순서로 메모해두려고 한다.

Situation: 어떤 문제와 제약이 있었는가
Task: 내 역할과 목표는 무엇이었는가
Action: 무엇을 왜 선택했고 어떻게 실행했는가
Result: 어떤 결과가 있었고 무엇을 배웠는가

이렇게 정리해두면 면접용 답변을 억지로 만들지 않아도 된다. 이미 회고가 답변의 재료가 된다.

이번 피드백을 통해 다시 배운 것

이번 경험을 지나면서 가장 크게 바뀐 생각은 하나다.

면접은 말을 잘하는 사람을 뽑는 자리가 아니라, 자신의 경험을 구조적으로 설명할 수 있는 사람을 확인하는 자리라는 점이다.

그리고 그 구조는 결국 실무와도 연결된다.

질문의 의도를 파악하는 능력은 협업 능력과 연결된다
기술 선택의 근거를 설명하는 능력은 설계 능력과 연결된다
구현의 한계를 솔직하게 말하는 태도는 신뢰와 연결된다

결국 내가 부족했던 것은 단순한 "면접 스킬"이 아니었다. 개발자로서 내가 무엇을 기준으로 판단하고, 그 판단을 어떻게 공유하는지에 대한 훈련이 더 필요했다.

다음 면접 전까지 점검하려는 체크리스트

앞으로는 아래 항목들을 반복적으로 점검하려고 한다.

질문을 듣고 바로 답하지 말고, 먼저 맥락을 짧게 확인했는가
결론을 먼저 말했는가
기준을 먼저 정의하고, 그 기준에 맞는 사례를 선택했는가
기술 선택의 이유를 문제, 대안, 근거, 트레이드오프로 설명할 수 있는가
이상적이지 않았던 구현이 있다면 모순처럼 숨기지 않고 트레이드오프로 설명할 수 있는가
과제나 프로젝트의 구체적인 맥락에서 먼저 답하고, 그 다음 일반론으로 확장했는가
실제 구현과 이상적인 설계가 달랐다면 그 이유를 솔직하게 설명할 수 있는가
"해봤다"에서 멈추지 않고, 그 경험을 통해 무엇을 배웠는지까지 말할 수 있는가

이 체크리스트는 면접을 위한 것처럼 보이지만, 사실은 좋은 회고를 위한 기준이기도 하다.

마무리

최근의 탈락들은 분명 아쉬웠다. 하지만 막연하게 자신감을 잃는 것보다, 구체적인 피드백을 근거로 내 부족함을 문장으로 정리할 수 있게 된 건 오히려 다행이었다.

좋은 피드백은 기분을 좋게 만들지 않을 때가 많다. 대신 다음 행동을 바꾸게 만든다.

지금의 나는 면접에서 더 유창하게 말하는 사람보다, 내 선택을 더 정확히 설명할 수 있는 개발자가 되고 싶다. 그리고 그 변화는 면접장에서 갑자기 생기지 않는다. 결국 평소 프로젝트를 어떻게 복기하고, 어떤 기준으로 기술을 바라보고, 얼마나 솔직하게 한계를 인정하는지에서 시작된다고 믿는다.

언젠가 같은 질문을 다시 받게 된다면, 이번에는 더 많은 말을 하는 대신 더 정확한 답을 하고 싶다.

카테고리

자주쓰는 태그