안 해봤어요

면접관으로서 수많은 지원자를 만나며 가장 아쉬운 순간이 있다. 그 순간은 지원자가 답변을 잘 하지 못했을 때가 아니라, 함께 이어갈 수 있었던 대화가 갑자기 멈춰버릴 때이다. "이런 상황에서 트랜잭션 충돌을 방지하려면 어떻게 하면 좋을까요?" 이런 질문을 던질 때, 나는 정답을 요구하는 것이 아니다. 개발에는 정답이 없으니까. 그저 함께 생각해보자는 제안에 가깝다. 하지만 종종 이런 대답이 돌아온다. "그건 저희 회사에선 안 써봤습니다." "그건 DBA가 관리해서 잘 몰라요." "그건 필요 없어서 안 했어요." 그 순간 대화는 멈춘다. 면접관의 질문은 공격이 아니다. "당신의 생각을 들려주세요"라는 요청에 가깝다. "스케일링을 위해 어떤 전략을 사용하겠습니까?"라고 물을 때 교과서 같은 답변을 듣고 싶은 게 아니다. 그 질문의 진짜 의도는 문제 상황에 대한 이해와 분석, 요구사항에 대한 깊은 질문과 정리, 사용할 수 있는 여러 자원들 파악, 그리고 디버깅과 고찰의 과정을 보는 것이다. 하지만 많은 지원자들이 이를 시험 문제처럼 받아들인다. 틀릴까 봐, 감점될까 봐 "그건 제 업무 범위가 아니었습니다"라는 방패를 든다. "안 해봤어요." 이 한 문장은 단순한 경험 부족의 고백이 아니라, 때로는 "이 주제에 대해 더 이야기하고 싶지 않습니다"라는 선언처럼 들린다. 면접관이 정말 보고 싶은 건 지식의 깊이가 아니다. 낯선 문제를 마주했을 때의 태도다. "해본 적은 없지만, 만약 그런 상황이라면 이렇게 접근할 것 같아요." 이 한 문장은 화려한 기술 스택보다 훨씬 강력한 신호가 된다. 그 사람은 멈추지 않고 생각할 줄 아는 사람이기 때문이다. "안 해봤어요"는 벽을 세우고, "어떻게 할까요?"는 길을 만든다. 이 두 문장 사이에는 기술적 경험보다 훨씬 더 중요한 사고방식의 차이가 있다. 면접에서 가장 깊은 인상을 남기는 사람들은 '경험이 없다'고 솔직히 말하면서도 거기서 멈추지 않는 사람들이다. "정확히는 다뤄본 적이 없는데, 데이터 충돌을 막으려면 이런 접근이 필요하지 않을까요?" 이런 답변을 들으면 저절로 고개를 끄덕이게 된다. 나는 같이 일하고 싶은 사람이 많은 것을 알고 있는 사람이 아니라 같이 협업을 잘 할 수 있는 사람이다. 모르면 같이 공부하고 나눠주고, 다른 사람에게 잘 설명해주고 스스로 일어날 수 있게 도와주고 같이 고민하고 해결하며 성장하는 사람 말이다. 회사에서는 해본 것보다 안 해본 것을 하는 게 더 많을 텐데, 그런 것을 함께 도전하고 해결하며 성장하는 사람들을 찾는 것 아닌가. 좋은 개발자는 기술적 문제 앞에서 멈추지 않는다. 모르는 영역에 부딪혔을 때 어떻게 접근할 것인지, 누구에게 도움을 구할 것인지, 어떤 자료를 찾아볼 것인지 이미 알고 있다. 이것이 경험보다 중요한 메타 스킬이다. 결국 좋은 개발자의 조건은 모든 것을 알고 있는 것이 아니라, 모르는 것을 어떻게 알아가는지 아는 것이다. 그리고 그 과정을 혼자가 아닌 팀과 함께 해나갈 수 있는 것이다.