아는 것과 설명할 수 있는 것은 다르다: 면접에서 다시 배운 차이
최근 면접을 지나며 가장 크게 배운 것 중 하나는, 무언가를 안다는 것과 그것을 상대에게 설명할 수 있다는 것이 전혀 같은 말이 아니라는 점이었다.
처음에는 이 차이를 잘 몰랐다.
- 구현해본 적이 있으면 아는 것이라고 생각했고
- 써본 적이 있으면 설명도 자연스럽게 될 거라고 생각했고
- 실제 프로젝트 경험이 있으면 면접에서도 충분히 전달될 거라고 믿었다
하지만 돌아보면 그렇지 않았다.
나는 분명히:
- 인증 토큰 흐름을 구현해본 적이 있었고
- 상태관리 라이브러리를 비교해본 적도 있었고
- 프레임워크와 아키텍처를 선택해본 경험도 있었다
그런데 막상 그 경험을 설명해야 하는 순간에는, 내가 알고 있는 것들이 상대에게 충분히 전달되지 않았다.
이 글은 특정 면접 상황을 복기하는 글은 아니다. 오히려 최근 받은 피드백을 계기로, 왜 아는 것과 설명하는 것 사이에 이렇게 큰 간극이 생기는지, 그리고 그 차이를 줄이기 위해 앞으로 무엇을 바꿔야 하는지를 반성적으로 정리해보는 글에 가깝다.
한눈에 보면
짧게 정리하면 이렇다.
- 기술을 안다는 것은 보통 문제를 실제로 다뤄본 경험이나 개념 이해를 뜻한다.
- 하지만 설명할 수 있다는 것은 그 경험을 문제, 기준, 선택, 트레이드오프, 결과의 구조로 꺼낼 수 있다는 뜻에 더 가깝다.
- 많은 경우 나는 기술을 몰라서 답을 못 한 것이 아니라, 알고 있는 것을 구조화하지 못해서 설명이 흐려졌다.
- 그래서 면접 준비는 지식을 더 쌓는 일만이 아니라, 이미 아는 것을 설명 가능한 형태로 정리하는 일이기도 하다.
즉, 면접에서 부족했던 것은 단순 암기량보다 지식을 말의 구조로 바꾸는 능력에 더 가까웠다.
나는 왜 "알고 있는데도" 잘 설명하지 못했을까
돌아보면 이유는 단순하지 않았다.
1. 알고 있는 내용이 머릿속에서 아직 정리된 언어가 아니었다
예전의 나는 "이 기술을 써봤다"는 사실이 곧 "이 기술을 설명할 수 있다"는 뜻이라고 생각할 때가 많았다.
예를 들어:
Zustand를 써봤다- 인증 재발급 로직을 구현해봤다
Vue에서React로 전환해봤다
이 경험들은 분명 실제 경험이었다. 하지만 경험이 있다는 것만으로는 설명이 되지 않았다.
설명하려면 적어도 아래가 필요했다.
- 어떤 문제였는가
- 어떤 대안이 있었는가
- 왜 그 선택을 했는가
- 무엇을 얻고 무엇을 포기했는가
즉, 경험이 있었던 것과 그 경험이 이미 언어로 정리돼 있었다는 것은 다른 문제였다.
2. 나는 종종 결론보다 배경을 더 많이 말했다
기술 질문을 받으면 빨리 많이 말해야 한다는 압박이 생겼다. 그래서 질문을 듣고 나면 결론보다 배경 설명을 길게 하는 경우가 많았다.
그런데 그러면 설명이 풍부해지는 것이 아니라 오히려 흐려질 때가 많았다.
예를 들어:
"상태관리는 여러 가지가 있는데 Redux도 있고 Zustand도 있고 Jotai도 있고, 각각 장단점이 있고, 저희 팀에서는..."
이렇게 시작하면 듣는 사람은 중간쯤에서 이런 생각을 하게 된다.
"그래서 결국 왜 그걸 선택했다는 거지?"
즉, 많이 말하는 것과 잘 설명하는 것은 같지 않았다.
3. 나는 결과를 말했지, 판단을 말하지는 못했다
면접에서 특히 자주 나왔던 문제는 이거였다.
예전의 나는 이런 식으로 말하곤 했다.
- "그 방식이 더 편했습니다."
- "구조가 더 깔끔해졌습니다."
- "팀이 쓰기 쉬웠습니다."
- "실무에서 많이 써서 선택했습니다."
이 문장들은 틀린 말은 아니다. 하지만 이건 판단의 근거라기보다 결과나 인상에 가깝다.
면접관이나 동료가 궁금한 것은 보통 아래 쪽이었다.
- 왜 더 편했는가
- 다른 대안보다 무엇이 단순했는가
- 어떤 비용을 감수했는가
- 왜 그 상황에서는 그 판단이 타당했는가
즉, 나는 종종 선택의 결과를 말했지, 선택의 논리를 말하지는 못했다.
기술을 안다는 것은 무엇일까
이 질문도 다시 보게 됐다.
예전의 나는 "구현해봤으면 안다"고 생각하는 편이었다. 물론 실제 구현 경험은 매우 중요하다. 하지만 지금은 그 기준만으로는 부족하다고 느낀다.
내 기준에서 어떤 기술을 정말 안다고 말하려면 적어도 아래 정도는 설명할 수 있어야 한다.
- 어떤 문제를 푸는 기술인가
- 어떤 상황에서 잘 맞는가
- 어떤 대안이 있는가
- 어떤 trade-off가 있는가
- 지금 다시 한다면 무엇을 유지하고 무엇을 바꿀 것인가
즉, 지식은 "해봤다"에서 끝나는 것이 아니라, 비교하고 해석할 수 있는 상태에 가까웠다.
설명할 수 있다는 것은 무엇이 다를까
설명할 수 있다는 것은 단순히 말을 유창하게 하는 것과는 다르다고 느꼈다.
오히려 설명 가능한 상태라는 것은:
- 문제를 짧게 정의할 수 있고
- 결론을 먼저 말할 수 있고
- 근거를 2~3개로 압축할 수 있고
- 사례와 기준을 연결할 수 있고
- 한계까지 말할 수 있다는 뜻에 더 가까웠다
즉, 설명은 표현력의 문제가 아니라 구조화의 문제인 경우가 많았다.
그래서 지금은 점점 이렇게 생각하게 된다.
"나는 이것을 아는가?"보다 먼저 "나는 이것을 한두 문장으로 설명할 수 있는가?"를 물어야 한다.
예시 1. 알고는 있지만 설명이 약한 경우
예를 들어 상태관리 라이브러리 선택을 떠올려보자.
약한 답변은 보통 이런 식이 된다.
"저는 Zustand를 선호합니다. 가볍고 쓰기 편해서 선택했습니다."
이 답변은 결론은 있지만, 여전히 많이 비어 있다.
- 왜 가벼운 것이 중요했는가
- 무엇과 비교했는가
- 어떤 문제에서 그 장점이 의미 있었는가
- 단점은 무엇이었는가
조금 더 설명 가능한 답변은 보통 이렇게 바뀐다.
"당시에는 서버 상태를 React Query로 분리하고 있었고, 클라이언트 전역 상태만 비교적 단순하게 관리하면 되는 상황이었습니다. 그래서 판단 기준은 팀 적응 속도, 보일러플레이트 비용, 현재 복잡도 대비 구조의 무게였습니다. Redux는 통제력은 좋지만 당시 요구사항에는 조금 무겁다고 봤고, Jotai는 더 세밀한 상태 분해에는 좋았지만 팀의 학습 비용이 상대적으로 더 필요하다고 봤습니다. 그래서 당시에는 Zustand를 선택했습니다. 대신 상태가 커질수록 규칙이 느슨해질 수 있다는 점은 트레이드오프로 보고 있었습니다."
둘의 차이는 단순 분량 차이가 아니다. 뒤의 답변은 판단 구조가 드러난다.
예시 2. 구현 경험은 있지만 설명이 흐린 경우
예를 들어 인증 토큰 재발급 로직을 구현한 경험이 있다고 해보자.
약한 답변은 이런 식이 되기 쉽다.
"액세스 토큰이 만료되면 재발급하고 다시 요청하도록 처리했습니다. 실무에서 구현해봐서 익숙합니다."
이 답변도 사실 자체는 맞다. 하지만 듣는 사람 입장에서는 아직 궁금한 게 많다.
- 왜 그 문제가 중요했는가
- 그냥 로그인 페이지로 보내는 방식과 무엇이 달랐는가
- 어떤 리스크가 있었는가
- 무한 재시도나 저장 방식은 어떻게 봤는가
조금 더 설명 가능한 답변은 이렇게 바뀔 수 있다.
"당시 문제는 액세스 토큰 만료 시 사용자의 작업 흐름이 자주 끊긴다는 점이었습니다. 그래서 단순 재로그인 유도와 자동 재발급 두 방식을 비교했는데, 사용자 경험을 더 중요하게 봐 자동 재발급 흐름을 선택했습니다. 대신 이 방식은 무한 재시도와 토큰 저장 방식 같은 리스크가 있었기 때문에, 실패 조건과 저장 전략을 함께 제한해야 했습니다. 결과적으로 흐름 끊김은 줄일 수 있었지만, 이후에는 전달 방식과 보안 모델을 더 깊게 검토해야겠다는 과제가 남았습니다."
여기서는 구현 사실보다 왜 그 구조를 선택했는가가 더 선명하게 들린다.
예시 3. 아는 것과 말할 수 있는 것의 차이는 프레임워크 선택에서도 드러난다
예를 들어 Vue에서 React로 전환한 경험을 떠올려보자.
약한 답변은 아래처럼 취향 중심으로 흐르기 쉽다.
"React가 더 유연하고 생태계가 좋아서 React로 갔습니다."
이 답변은 아주 틀린 말은 아니지만, 여전히 너무 넓다.
조금 더 설명 가능한 답변은 이렇게 바뀐다.
"당시에는 단순히 Vue 2에서 Vue 3로 버전 업그레이드하는 선택지도 있었습니다. 하지만 팀은 단순 마이그레이션보다, 앞으로 어떤 스택이 장기적으로 더 확장성 있는지를 같이 보고 있었습니다. 판단 기준은 중장기 생태계, 채용 확장성, TypeScript 기반 설계, 그리고 서버 렌더링 전략까지 포함한 확장 가능성이었습니다. 그 기준에서 React 전환이 더 정합적이라고 판단했습니다. 대신 학습 비용이 컸고, 기존 사고 방식을 바꾸는 부담도 있었습니다."
여기서는 "React가 더 좋다"가 아니라, 그 시점의 조직과 제품 기준에서 왜 그 선택이 타당했는가가 드러난다.
그래서 앞으로는 어떻게 해야 할까
이 질문이 가장 중요했다.
반성에서 멈추면 결국 또 비슷한 답변을 하게 되기 때문이다.
최근에는 아래 방식으로 바꾸려고 한다.
1. 프로젝트 경험을 "설명 가능한 기록"으로 다시 적는다
예전에는 프로젝트를 회고할 때 주로 이런 것만 적었다.
- 무엇을 만들었는가
- 어떤 기술을 썼는가
- 결과가 어땠는가
지금은 아래를 같이 적으려고 한다.
- 어떤 문제였는가
- 어떤 제약이 있었는가
- 어떤 대안이 있었는가
- 무엇을 선택했고 왜 그랬는가
- 어떤 trade-off가 있었는가
- 지금 다시 한다면 무엇을 바꿀 것인가
이렇게 적으면 경험이 단순 이력서 재료가 아니라, 설명 가능한 판단 기록이 된다.
2. 결론을 먼저 말하는 연습을 한다
나는 원래 배경 설명이 길어지는 편이었다. 그래서 지금은 가능한 한 아래 순서를 지키려고 한다.
- 결론을 먼저 말한다
- 판단 기준을 짧게 말한다
- 대안과 비교를 붙인다
- trade-off를 말한다
예를 들어:
"당시에는 Zustand를 선택했습니다. 이유는 전역 상태가 비교적 단순했고, 팀이 빠르게 적응할 수 있는 선택지가 더 중요했기 때문입니다. Redux와 Jotai도 비교했지만 당시 요구사항에는 각각 구조 무게와 학습 비용이 더 크다고 봤습니다. 대신 상태가 커질수록 규칙이 느슨해질 수 있다는 점은 감수해야 했습니다."
이 구조만으로도 답변은 훨씬 선명해진다.
3. 질문의 범위를 먼저 맞춘다
면접에서 느낀 건, 많은 경우 답변이 길어지는 이유가 내가 너무 많이 말해서가 아니라 질문의 범위를 제대로 맞추지 못해서라는 점이었다.
그래서 지금은 바로 답하기보다 짧게 이렇게 확인하려고 한다.
- "실무 적용 경험 중심으로 말씀드릴까요?"
- "대안 비교 관점에서 답드릴까요?"
- "당시 제약과 함께 설명드리겠습니다."
이 짧은 문장 하나가 설명의 밀도를 훨씬 높여준다.
아는 것을 잘 설명하려면 결국 무엇이 필요할까
지금 기준으로는 아래 세 가지가 가장 중요하다고 느낀다.
1. 기준
기술 선택은 취향이 아니라 기준으로 말해야 한다.
- 성능
- 유지보수성
- 팀 생산성
- 학습 비용
- 보안
- 운영 복잡도
이 중 무엇을 더 중요하게 봤는지가 먼저 나와야 한다.
2. 비교
내가 선택한 기술만 말하면 설명은 쉽게 얕아진다.
대안을 함께 말해야 한다.
- 무엇과 비교했는가
- 왜 그 대안을 선택하지 않았는가
이 비교가 있어야 현재 선택의 의미가 살아난다.
3. 한계 인식
좋은 설명은 내 선택을 정답처럼 포장하지 않는다.
오히려:
- 무엇을 얻었는가
- 무엇을 포기했는가
- 어떤 위험이 있었는가
- 지금 다시 한다면 무엇을 바꿀 것인가
를 같이 말할 수 있어야 깊이가 생긴다.
즉, 설명력은 말솜씨보다 기준, 비교, 한계 인식에서 더 많이 나온다.
앞으로 나를 점검하려는 질문들
이제는 기술을 공부하거나 프로젝트를 복기할 때 아래 질문을 같이 보려고 한다.
- 나는 이 기술을 정말 이해한 것인가, 아니면 단지 써본 것인가
- 이 선택이 해결한 문제를 한 문장으로 말할 수 있는가
- 다른 대안과 비교해 왜 이걸 골랐는지 설명할 수 있는가
- 내가 감수한 trade-off를 말할 수 있는가
- 지금 다시 한다면 무엇을 바꿀지 말할 수 있는가
- 이 경험을 30초, 1분, 3분 버전으로 각각 설명할 수 있는가
이 질문을 반복하다 보면, 지식이 단순한 사용 경험에서 설명 가능한 이해로 조금씩 바뀌는 것 같다.
마무리
최근 나는 면접을 준비하면서, 내가 부족했던 것이 단순한 말솜씨가 아니었다는 걸 다시 배웠다. 더 정확히는, 알고 있는 것을 설명 가능한 형태로 정리하지 못했던 것에 더 가까웠다.
지금의 나는 기술을 더 많이 아는 사람보다, 아는 것을 더 정확하게 설명할 수 있는 사람이 되고 싶다.
왜냐하면 실무에서도 결국 중요한 것은 "이 기술을 써봤다"는 사실보다, 왜 그 선택이 타당했고 무엇을 감수했는지를 함께 말할 수 있는가이기 때문이다.
그래서 앞으로의 공부는 지식을 더 쌓는 일만이 아니라, 이미 알고 있는 것을 더 잘 설명할 수 있도록 다시 정리하는 일이어야 한다고 생각한다.
