기술 결정은 어떻게 설명해야 할까: 면접과 기술 토론에서 다시 배운 원칙들
최근 면접을 준비하고 지나오면서 가장 크게 느낀 점 중 하나는, 나는 기술을 실제로 사용해본 경험은 있었지만 그 경험을 설명 가능한 판단으로 정리하는 훈련은 생각보다 부족했다는 점이었다.
예전의 나는 이런 식으로 답하는 경우가 많았다.
- "그 방식이 더 편했습니다."
- "팀에서 쓰기 쉬웠습니다."
- "실무에서 많이 써서 선택했습니다."
- "구조가 깔끔해졌습니다."
틀린 말은 아니지만, 이런 답변만으로는 부족하다는 걸 여러 번 느꼈다. 면접에서도 그랬고, 기술 토론을 다시 떠올려봐도 마찬가지였다. 중요한 것은 "무엇을 썼는가"보다 왜 그 상황에서 그 선택이 타당했는가를 설명하는 일이었다.
이 글은 특정 면접 상황을 복기하는 글은 아니다. 오히려 최근 피드백을 바탕으로, 기술 결정을 설명할 때 무엇이 중요했는지, 그리고 기술 토론에서는 어떤 원칙을 놓치면 안 되는지를 내 기준으로 다시 정리해보는 글에 가깝다.
앞선 글인 면접 피드백 이후 내가 다시 정리한 것들: 부족함을 공부 계획으로 바꾼 회고가 "무엇이 부족했는가"를 돌아본 글이었다면, 이 글은 그 이후에 생긴 질문, 즉 "그럼 기술 결정은 어떻게 설명해야 하는가?" 를 붙잡아본 기록이다.
한눈에 보면
먼저 짧게 정리하면 이렇다.
- 기술 결정 설명의 핵심은 결론 자체보다 판단 기준을 먼저 선명하게 드러내는 것이다.
- 좋은 기술 토론은 취향 대결이 아니라 문제, 제약, 대안, 트레이드오프를 맞춰가는 과정에 가깝다.
- "왜 이 기술을 썼는가"는 보통 성능, 유지보수성, 팀 생산성, 보안, 운영 비용, 학습 비용 같은 기준 위에서 설명되어야 한다.
- 이상적인 선택과 실제 구현이 달랐다면, 그 차이를 숨기기보다 제약과 보완책까지 설명하는 편이 훨씬 낫다.
즉, 기술을 설명하는 힘은 아는 기술의 개수보다 의사결정을 문장으로 구조화하는 능력에 더 가까웠다.
왜 기술 결정 설명이 중요한가
돌이켜보면 면접에서든 협업에서든, 기술 질문의 핵심은 단순 지식 확인만이 아니었다.
- 이 사람은 문제를 어떻게 정의하는가
- 선택지를 어떤 기준으로 비교하는가
- 제약이 있을 때 얼마나 현실적으로 판단하는가
- 자기 선택의 한계를 알고 있는가
결국 기술 결정 설명은 "내가 기술을 써봤다"는 사실을 보여주는 일이 아니라, 내가 어떤 기준으로 판단하는 개발자인지 드러내는 일에 더 가까웠다.
이 점을 놓치면 경험이 있어도 답변이 얕아진다. 반대로 경험이 아주 화려하지 않아도, 문제와 기준과 트레이드오프를 명확히 설명하면 훨씬 설득력 있게 들린다.
예전의 나는 무엇을 놓쳤을까
가장 많이 놓쳤던 건 아래 세 가지였다.
1. 결론보다 배경 설명이 길었다
질문을 받으면 빨리 많이 설명해야 한다는 생각 때문에, 상황 설명과 배경을 길게 말하다가 정작 핵심 결론이 뒤로 밀리는 경우가 많았다.
2. 기준보다 사례를 먼저 꺼냈다
실무 사례를 먼저 말하면 풍부해 보일 것 같았다. 하지만 실제로는 "그래서 이 사람의 판단 기준이 무엇이었지?"라는 질문만 더 남길 때가 많았다.
3. 선택의 이유보다 결과만 말했다
"좋았다", "편했다", "빨랐다" 같은 표현은 결과에 가깝다. 그런데 면접관이나 동료가 궁금한 것은 보통 그 결과보다, 어떤 대안 중에서 왜 그 선택을 했는가다.
이걸 깨닫고 나서야, 기술 결정 설명은 경험담이 아니라 판단의 구조를 공유하는 일이라는 걸 조금 더 이해하게 됐다.
기술 결정을 설명할 때 먼저 말해야 하는 것
최근에는 가능하면 아래 순서를 지키려고 한다.
- 무엇이 문제였는가
- 무엇을 기준으로 판단했는가
- 어떤 대안이 있었는가
- 무엇을 선택했고 왜 그랬는가
- 무엇을 얻었고 무엇을 포기했는가
이 순서가 중요한 이유는, 듣는 사람이 가장 궁금해하는 흐름과 크게 다르지 않기 때문이다.
예를 들어 상태 관리 선택을 설명한다고 해보자.
예전에는 이렇게 말했을 가능성이 높다.
"Zustand를 사용했습니다. 가볍고 팀에서 쓰기 쉬웠습니다."
지금은 최소한 아래 정도는 말하려고 한다.
"당시에는 전역 상태의 수가 많지 않았고, 서버 상태는 이미 React Query로 분리하고 있었습니다. 그래서 클라이언트 전역 상태만 단순하게 다룰 필요가 있었고, Redux 수준의 보일러플레이트를 감수할 만큼 복잡한 요구사항은 아니었습니다. 팀이 빠르게 적응할 수 있고 상태 경계를 작게 유지할 수 있다는 점에서 Zustand를 선택했습니다. 대신 상태가 커질 경우 규칙이 느슨해질 수 있다는 점은 트레이드오프로 보고 있었습니다."
같은 경험이라도, 문제와 기준과 트레이드오프가 들어가면 훨씬 설명 가능한 선택이 된다.
기준을 먼저 말해야 하는 이유
내가 최근 가장 많이 의식하는 원칙은 이것이다.
사례보다 기준을 먼저 말하자.
기술 토론에서 사례를 먼저 꺼내면 두 가지 위험이 생긴다.
- 듣는 사람이 내 기준을 추측해야 한다
- 잘못하면 사례와 결론이 뒤늦게 어긋나 보인다
예를 들어 URL에 상태를 둘지, 전역 상태로 둘지, 브라우저 히스토리 상태를 쓸지를 설명한다고 해보자. 이때 곧바로 "예전에 query string을 썼습니다"부터 말하면, 상대는 그 선택의 기준을 다시 물을 수밖에 없다.
지금은 오히려 이렇게 먼저 말하려고 한다.
- 공유 가능성과 북마크 가능성이 필요한가
- 새로고침 이후에도 복원되어야 하는가
- 민감한 정보인가
- 데이터 구조가 단순한가
이 기준이 먼저 서면, 그 다음에 "그래서 이 경우에는 query string이 적합했다"거나 "이 경우는 민감한 정보라 URL에 두지 않았다"는 설명이 훨씬 자연스럽게 이어진다.
즉, 기술 결정 설명의 핵심은 사례가 아니라 판단 기준을 먼저 고정하는 것이다.
기술 토론에서 중요한 원칙 1. 질문의 맥락을 먼저 맞춘다
면접에서도 기술 토론에서도, 질문은 생각보다 여러 층을 가진다.
예를 들어 "왜 이 기술을 선택했나요?"라는 질문은 실제로 아래 중 하나일 수 있다.
- 성능 관점에서 왜 선택했는가
- 팀 생산성 관점에서 왜 선택했는가
- 대안과 비교하면 어떤 장단점이 있었는가
- 실무에서 어떤 제약 때문에 그랬는가
이걸 확인하지 않고 바로 답하면, 아는 말을 많이 해도 질문에 정확히 답하지 못할 수 있다.
그래서 최근에는 답하기 전에 짧게 범위를 맞추는 문장을 의식적으로 넣으려고 한다.
- "실무 적용 경험 중심으로 말씀드리겠습니다."
- "대안 비교 관점에서 말씀드리면."
- "당시 제약과 함께 설명드리겠습니다."
이 짧은 문장 하나만 있어도, 토론의 축이 훨씬 빨리 맞춰진다.
예를 들면 이런 차이다.
"왜 Zustand를 선택했나요?"라는 질문을 받았을 때 바로 상태관리 철학 전체를 설명하기 시작하면 질문이 빗나갈 수 있다.
이럴 때는:
- "실무에서 왜 그 선택을 했는지 중심으로 말씀드리겠습니다."
- "대안 비교 관점에서 말씀드리겠습니다."
처럼 먼저 범위를 맞춘 뒤 답하는 편이 훨씬 낫다.
기술 토론에서 중요한 원칙 2. 취향이 아니라 문제를 중심에 둔다
기술 토론이 어려워지는 순간은 보통 "내가 선호하는 방식"과 "현재 해결해야 하는 문제"가 섞일 때다.
예를 들어:
- "저는 Redux보다 Zustand가 더 좋다고 생각합니다"
- "저는 SSR보다 CSR이 더 편합니다"
- "저는 TypeScript가 무조건 맞다고 봅니다"
이런 문장은 개인 취향을 말할 수는 있지만, 토론을 진전시키기 어렵다.
반면 아래처럼 문제를 중심에 두면 대화가 훨씬 생산적으로 바뀐다.
- 현재 상태 규모가 어느 정도인가
- 서버 상태와 클라이언트 상태가 얼마나 분리되는가
- SEO가 중요한가
- 개인화와 초기 응답 중 무엇이 더 중요한가
- 팀의 학습 비용은 감당 가능한가
즉, 좋은 기술 토론은 "무엇이 더 좋은 기술인가"를 겨루는 자리가 아니라, 지금 문제에 어떤 선택이 더 적합한가를 함께 좁혀가는 과정에 가깝다.
예를 들면 이런 식이다.
약한 답변:
"저는 CSR보다 SSR이 더 좋다고 생각합니다."
조금 더 나은 답변:
"이 화면은 검색 유입이 중요하고, 첫 화면에서 주요 콘텐츠를 바로 보여줘야 했습니다. 그래서 CSR보다 SSR이 더 적합하다고 판단했습니다."
기술 토론에서 중요한 원칙 3. 대안을 함께 설명한다
좋은 기술 결정 설명은 보통 하나의 선택지만 말하지 않는다.
예를 들어 "왜 Next.js를 선택했나요?"라는 질문에 아래처럼만 답하면 약하다.
"SEO에 좋고 실무에서 많이 쓰여서 선택했습니다."
이보다는 최소한 대안과 비교가 보여야 한다.
"당시에는 공개 페이지의 검색 유입이 중요했고, 초기 렌더링 속도도 요구사항이었습니다. CSR만으로도 구현은 가능했지만, 초기 콘텐츠 전달과 SEO 측면에서 불리했습니다. 그래서 SSR/SSG 전략을 함께 가져갈 수 있는 Next.js를 선택했습니다. 대신 라우팅과 캐시 모델이 더 복잡해지는 점은 감수해야 했습니다."
이 답변이 더 나은 이유는 선택 그 자체보다, 선택하지 않은 대안까지 고려했다는 흔적이 보이기 때문이다.
비슷하게 이런 차이도 있다.
약한 답변:
"FSD가 구조적으로 더 좋아 보여서 선택했습니다."
조금 더 나은 답변:
"페이지 중심 구조는 진입은 쉬웠지만, 기능과 국가가 늘어나면서 도메인 로직이 여러 화면에 흩어졌습니다. 그래서 페이지 중심 구조와 FSD를 비교했고, 변경 영향 범위를 줄이는 쪽으로 FSD가 더 적합하다고 판단했습니다."
기술 토론에서 중요한 원칙 4. 트레이드오프를 숨기지 않는다
예전에는 내가 선택한 방식을 설명할 때, 그 선택의 약점을 같이 말하면 오히려 불리할 것처럼 느껴질 때가 있었다.
지금은 오히려 반대로 생각한다.
트레이드오프를 모르는 선택은 깊이가 얕아 보일 가능성이 크다.
예를 들어:
Promise.all은 빠르지만 실패 전파 범위를 함께 봐야 한다- 전역 상태는 편하지만 경계가 흐려질 수 있다
- SSR은 초기 노출에는 유리하지만 서버 비용과 캐시 전략이 따라온다
- 강한 추상화는 재사용성을 높이지만 복잡도도 함께 올릴 수 있다
즉, 기술 토론에서 중요한 것은 "내 선택이 완벽하다"를 증명하는 것이 아니라, 무엇을 얻고 무엇을 포기했는지 알고 있다는 점을 보여주는 것이다.
예를 들면 이렇게 말할 수 있다.
약한 답변:
"Promise.all을 써서 성능을 개선했습니다."
조금 더 나은 답변:
"서로 독립적인 API 호출은 Promise.all로 병렬화해서 응답 시간을 줄였습니다. 대신 하나의 요청이 실패하면 전체가 실패할 수 있어서, 실패 허용 범위가 필요한 곳은 allSettled 같은 대안을 같이 검토했습니다."
기술 토론에서 중요한 원칙 5. 이상적인 답과 실제 구현의 차이를 정직하게 말한다
최근 특히 많이 배운 부분이 이것이다.
실무에서는 늘 제약이 있다.
- 이미 정해진 백엔드 스펙
- 짧은 일정
- 팀 차원의 합의
- 운영 환경의 제약
- 보안과 DX 사이의 충돌
그래서 이상적으로 생각한 방식과 실제 구현 방식이 다를 수 있다. 예전의 나는 이 간극이 있으면 설명이 흔들렸다. 마치 모순처럼 느껴졌기 때문이다.
하지만 지금은 이 차이를 숨기기보다 아래 순서로 설명하는 편이 더 낫다고 느낀다.
- 이상적으로는 어떤 선택이 더 나았는가
- 실제로는 무엇을 구현했는가
- 왜 그 차이가 생겼는가
- 어떤 보완책을 같이 뒀는가
- 지금 다시 한다면 무엇을 바꿀 것인가
이렇게 설명하면 경험이 변명처럼 들리지 않고, 오히려 제약 속에서 판단한 기록처럼 들린다.
예를 들면 이런 차이다.
약한 답변:
"원래는 더 좋은 방식이 있었는데, 그냥 그렇게 구현했습니다."
조금 더 나은 답변:
"이상적으로는 더 안전한 저장 방식을 쓰는 게 맞다고 생각했습니다. 다만 당시에는 이미 정해진 백엔드 스펙과 일정 제약이 있어서 다른 방식을 택했고, 대신 노출 범위를 줄이기 위한 보완책을 같이 두었습니다. 지금 다시 한다면 저장 전략부터 다시 설계할 것 같습니다."
기술 토론에서 중요한 원칙 6. 기술 용어보다 비즈니스 맥락을 연결한다
토론이 추상적으로 흘러갈 때 가장 도움이 되는 질문은 보통 이것이다.
"이 선택이 실제로 어떤 문제를 해결하나요?"
예를 들어:
- SEO가 중요하다는 말은 결국 검색 유입과 연결된다
- 성능이 중요하다는 말은 이탈률과 작업 시간과 연결될 수 있다
- 유지보수성이 중요하다는 말은 변경 비용과 장애 위험과 연결된다
- 팀 생산성이 중요하다는 말은 온보딩 속도와 리뷰 비용과 연결된다
즉, 기술 토론은 기술 용어를 많이 쓰는 사람이 이기는 대화가 아니라, 기술 선택을 실제 문제와 연결하는 사람이 설득력을 얻는 대화에 더 가깝다.
예를 들면 이렇게 바뀔 수 있다.
약한 답변:
"SSR을 쓰면 SEO에 좋습니다."
조금 더 나은 답변:
"이 서비스는 검색 유입이 주요 유입 경로였고, 공개 페이지에서 콘텐츠가 바로 노출되는 것이 중요했습니다. 그래서 SEO와 초기 노출을 함께 고려해 SSR을 선택했습니다."
기술 결정을 설명할 때 내가 쓰려고 하는 기본 구조
요즘은 아래 구조를 일종의 기본 프레임처럼 두려고 한다.
- 문제를 한 문장으로 말한다
- 판단 기준을 2~3개로 제한한다
- 대안을 짧게 나열한다
- 선택과 이유를 말한다
- 트레이드오프를 덧붙인다
- 결과나 배운 점으로 마무리한다
예를 들면 이런 식이다.
"당시 문제는 인증 만료로 사용자의 작업 흐름이 자주 끊긴다는 점이었습니다. 판단 기준은 사용자 경험, 보안, 구현 복잡도였습니다. 단순 재로그인 유도와 자동 재발급 두 가지 선택지가 있었는데, 사용자 이탈을 줄이는 것이 더 중요하다고 판단해 자동 재발급 흐름을 선택했습니다. 대신 무한 재시도와 토큰 저장 방식의 리스크가 생겨 실패 조건과 저장 전략을 함께 제한했습니다. 결과적으로 흐름 끊김은 줄었지만, 이후에는 토큰 전달 방식과 보안 모델을 더 깊이 검토해야겠다는 과제를 분명히 남겼습니다."
이 구조가 완벽한 정답은 아니다. 다만 적어도 "많이 말했는데 핵심이 안 남는 상태"를 줄이는 데는 꽤 도움이 됐다.
실제로 이렇게 설명해보려 한다
원칙만으로는 조금 추상적일 수 있어서, 최근에는 실제 기술 결정도 아래 구조로 정리해보려고 한다.
- 문제는 무엇이었는가
- 판단 기준은 무엇이었는가
- 대안은 무엇이었는가
- 무엇을 선택했고 왜 그랬는가
- 어떤 트레이드오프가 있었는가
- 지금 다시 보면 무엇을 배웠는가
1. 상태관리 라이브러리 선택: Jotai vs Zustand vs Redux
이런 질문은 단순히 "무엇을 선호하나요?"로 답하면 약해지기 쉽다. 실제로는 현재 상태 규모, 서버 상태와의 분리 여부, 팀의 학습 비용, 패턴 강제 수준을 함께 설명해야 한다고 느낀다.
내가 지금이라면 아래처럼 답하려고 한다.
"당시에는 서버 상태는 이미 React Query로 분리하고 있었고, 프론트엔드에서 필요한 것은 비교적 제한적인 클라이언트 전역 상태였습니다. 그래서 판단 기준은 크게 세 가지였습니다. 첫째, 팀이 빠르게 적응할 수 있는가. 둘째, 보일러플레이트 없이 상태 경계를 단순하게 유지할 수 있는가. 셋째, 현재 복잡도에 비해 과한 구조를 강제하지 않는가였습니다. 대안으로는 Redux, Zustand, Jotai를 봤습니다. Redux는 패턴이 명확하고 큰 규모에서 통제력이 좋지만, 당시 요구사항에 비해 액션, 리듀서, 미들웨어 구조가 조금 무겁다고 느꼈습니다. Jotai는 원자 단위로 상태를 매우 세밀하게 쪼갤 수 있어서 유연했지만, 당시 팀이 익숙하게 받아들이기에는 사고 방식 전환이 조금 더 필요하다고 봤습니다. 그래서 당시에는 Zustand를 선택했습니다. API가 단순했고 팀이 빠르게 적응할 수 있었고, 필요한 전역 상태를 비교적 적은 비용으로 관리할 수 있었기 때문입니다. 대신 상태가 커질수록 규칙이 느슨해질 수 있고, 무분별하게 store를 늘리면 구조가 흐려질 수 있다는 점은 트레이드오프로 보고 있었습니다. 지금 다시 봐도, 당시 조건에서는 Zustand 선택이 적절했다고 생각하지만, 상태 의존성이 훨씬 복잡한 제품이라면 Redux 같은 더 강한 규칙 기반도 충분히 다시 검토할 수 있다고 생각합니다."
여기서 중요한 것은 "나는 Zustand를 좋아한다"가 아니라, 왜 그 시점과 팀 조건에서 Zustand가 더 적절했는가를 설명하는 것이다.
짧게 답하면 이렇게도 말할 수 있다.
"당시에는 서버 상태를 React Query로 분리하고 있었고, 클라이언트 전역 상태만 비교적 단순하게 관리하면 되는 상황이었습니다. Redux는 요구사항에 비해 구조가 무겁고, Jotai는 더 세밀한 상태 분해에는 좋지만 팀 적응 비용이 조금 더 있다고 봤습니다. 그래서 팀이 빠르게 적응하면서도 필요한 전역 상태를 가볍게 다룰 수 있는 Zustand를 선택했습니다. 대신 상태가 커질수록 규칙이 느슨해질 수 있다는 점은 트레이드오프로 보고 있었습니다."
2. 전통적인 구조와 FSD 아키텍처 선택
이 주제도 자주 느끼는 건, FSD를 선택했다고만 말하면 쉽게 유행 따라간 선택처럼 들릴 수 있다는 점이다. 실제로는 구조를 바꾸게 된 문제와 확장 방향이 먼저 설명되어야 한다.
지금이라면 이런 식으로 설명하는 편이 더 낫다고 생각한다.
"당시에는 페이지 중심으로 구조가 점점 커지면서, 같은 도메인 로직이 여러 화면에 흩어지고 있었습니다. 국가가 늘어나거나 기능이 확장될 때 어디를 수정해야 하는지가 점점 불명확해졌고, 특정 화면 단위로만 로직을 묶는 방식은 재사용성과 변경 영향 범위를 제어하는 데 한계가 있었습니다. 그래서 판단 기준은 첫째, 도메인 경계를 더 선명하게 만들 수 있는가. 둘째, 기능과 국가 확장에 따라 구조가 덜 흔들리는가. 셋째, 팀이 규칙을 공유하며 유지할 수 있는가였습니다. 전통적인 페이지 중심 구조는 처음엔 단순하고 진입이 쉽지만, 기능이 커질수록 중복과 결합도가 빠르게 높아지는 문제가 있었습니다. 반면 FSD는 처음엔 계층과 용어를 익혀야 해서 러닝 커브가 있지만, Entity와 Feature 단위로 책임을 나누면서 변경 범위를 더 잘 제어할 수 있다고 봤습니다. 그래서 결국 FSD 아키텍처를 선택했습니다. 특히 국가 확장과 서드파티 연동이 많은 상황에서, 페이지보다는 도메인과 기능 중심 구조가 더 오래 버틸 수 있다고 판단했습니다. 대신 초기 온보딩 비용과 규칙을 맞추는 비용은 분명히 있었고, 팀이 계층 의미를 제대로 합의하지 않으면 오히려 폴더만 복잡해질 수 있다는 점은 트레이드오프였습니다. 지금 다시 생각해봐도, 복잡도와 확장성이 높아지는 제품에서는 FSD가 더 적합했지만, 아주 작은 규모의 제품이라면 전통적인 구조를 더 오래 유지하는 편이 오히려 효율적일 수 있다고 생각합니다."
이 설명에서 핵심은 FSD가 "더 좋아 보여서"가 아니라, 도메인 경계와 확장 비용 문제를 풀기 위한 선택이었다는 점이다.
짧게 답하면 이렇게도 말할 수 있다.
"당시에는 페이지 중심 구조가 커지면서 같은 도메인 로직이 여러 화면에 흩어지고 있었고, 국가와 기능이 늘어날수록 수정 범위가 불명확해지는 문제가 있었습니다. 그래서 도메인 경계를 더 선명하게 만들고 확장 시 구조가 덜 흔들리는 방향이 필요했고, 그 기준에서 FSD를 선택했습니다. 대신 초기 온보딩 비용과 규칙 합의 비용은 있었지만, 장기적으로는 변경 영향 범위를 줄이는 데 더 적합하다고 판단했습니다."
3. Vue 2 -> Vue 3 전환 시기에 React로 전환한 경험
이 사례는 특히 조심해야 한다고 느낀다. 단순히 "React가 더 좋아서 바꿨다"처럼 들리면 기술 취향 이야기로 축소되기 쉽기 때문이다. 실제로는 전환 시점의 팀 상황, 생태계, 장기 전략, 학습 비용을 함께 설명해야 했다.
지금이라면 아래처럼 답하는 편이 더 정합적이라고 생각한다.
"당시에는 Vue 2 기반 서비스가 운영되고 있었고, 자연스럽게 Vue 3로의 전환도 선택지 중 하나였습니다. 그런데 그 시점에 팀은 단순 버전 업그레이드보다, 앞으로의 프론트엔드 스택을 어떤 기준으로 가져갈지를 같이 고민하고 있었습니다. 판단 기준은 첫째, 중장기 생태계와 채용 시장에서 팀 확장성이 있는가. 둘째, TypeScript와의 궁합을 포함해 설계 일관성을 높이기 쉬운가. 셋째, 공통 컴포넌트와 아키텍처를 더 확장성 있게 가져갈 수 있는가였습니다. Vue 3는 Vue 2에서 비교적 자연스럽게 넘어갈 수 있고 Composition API로 구조 개선도 가능하다는 장점이 있었습니다. 하지만 그 시점의 팀 경험, 향후 채용 풀, React 중심 생태계의 폭, 그리고 Next.js를 포함한 확장 가능성을 같이 봤을 때 React로 전환하는 편이 장기적으로 더 유리하다고 판단했습니다. 특히 타입 기반 설계, 합성 중심 패턴, 서버 렌더링 전략 확장까지 같이 고려하면 단순 마이그레이션보다 스택 전환의 가치가 더 크다고 봤습니다. 대신 이 선택은 단기적으로 학습 비용이 크고, 기존 Vue 코드와 사고 방식을 버리고 다시 맞춰야 하는 부담이 있었습니다. 그래서 이 결정은 기술 우열의 문제가 아니라, 팀의 다음 몇 년을 기준으로 한 선택에 더 가까웠습니다. 이 경험을 통해 배운 점은 프레임워크 전환은 API 차이를 비교하는 문제가 아니라, 팀의 학습 곡선, 채용, 아키텍처 방향, 생태계까지 함께 보는 결정이어야 한다는 것이었습니다."
이 주제에서는 특히 "어느 프레임워크가 더 낫다"는 식으로 말하지 않고, 그 시점의 조직과 제품에 어떤 선택이 더 정합적이었는가를 말하는 것이 중요하다고 느낀다.
짧게 답하면 이렇게도 말할 수 있다.
"당시에는 Vue 2에서 Vue 3로 자연스럽게 가는 선택지도 있었지만, 팀은 단순 버전 업그레이드보다 앞으로의 스택 방향을 같이 보고 있었습니다. 중장기 생태계, 채용 확장성, TypeScript 기반 설계, 그리고 Next.js까지 포함한 확장 가능성을 함께 봤을 때 React 전환이 더 유리하다고 판단했습니다. 대신 학습 비용은 컸지만, 단기 마이그레이션보다 장기 전략 측면에서 더 정합적인 선택이라고 봤습니다."
면접과 기술 토론은 결국 같은 능력을 본다
예전에는 면접 답변과 실무 토론을 조금 다르게 생각했다. 지금은 둘이 꽤 많이 닮아 있다고 느낀다.
- 질문의 의도를 파악하는 능력
- 기준을 먼저 세우는 능력
- 대안을 비교하는 능력
- 트레이드오프를 설명하는 능력
- 제약 속의 선택을 정직하게 말하는 능력
이건 면접 스킬만의 문제가 아니다. 결국 팀 협업, 코드 리뷰, 설계 논의, 장애 회고에서도 계속 필요한 능력이다.
그래서 요즘은 기술을 공부할 때도 "어떻게 쓰는가"만 보지 않고, "왜 이 선택이 타당한가를 한두 문장으로 설명할 수 있는가"를 같이 점검하려고 한다.
다음 면접이나 토론 전 체크리스트
앞으로는 아래 질문을 반복해서 보려고 한다.
- 나는 지금 문제보다 취향을 먼저 말하고 있지 않은가
- 결론보다 배경 설명이 길어지고 있지 않은가
- 기준 없이 사례만 나열하고 있지 않은가
- 대안과 비교 없이 현재 선택만 말하고 있지 않은가
- 트레이드오프를 빼고 장점만 말하고 있지 않은가
- 이상적인 방식과 실제 구현의 차이를 흐리지 않고 설명할 수 있는가
- 이 선택이 해결한 실제 문제를 한 문장으로 말할 수 있는가
이 체크리스트를 보면서 느낀 건, 좋은 답변은 유창한 답변이 아니라 구조가 있는 답변이라는 점이었다.
마무리
최근 나는 기술 결정에 대한 설명이 단순한 면접 준비 스킬이 아니라는 걸 다시 배웠다. 그것은 결국 내가 어떤 기준으로 판단하는 개발자인지, 그리고 그 판단을 얼마나 선명하게 공유할 수 있는지의 문제였다.
지금의 나는 더 화려한 답변보다, 더 정합적인 답변을 하고 싶다.
기술 토론에서 중요한 것은 내 선택을 정답처럼 포장하는 일이 아니라, 문제와 기준과 트레이드오프를 분명하게 공유하는 것이라고 믿게 됐다. 그리고 그 연습은 면접장에 들어가기 직전에 시작되는 것이 아니라, 평소 프로젝트를 어떻게 복기하고 어떤 기준으로 기술을 바라보는지에서부터 시작된다고 생각한다.
