스스로 바보가 되는 법 101 — AI 의존이 기술 면접에서 드러낸 것

본문

글쓴이는 Wasmer 기술 면접을 앞두고 전날 자정까지, 그리고 면접 당일 아침까지 준비했습니다. 자신이 만든 velocity MCP를 엣지에 배포하고 테스트했으며, 이를 보여주기 위한 대시보드도 만들었습니다. 또한 기존 durable workflows 시스템에서 일부를 분리해 Wasmer Cloud를 위한 durable state 시스템으로 바꾸고, 보기 좋고 설명하기 쉬운 IDE 환경까지 마련했습니다. 초반 면접 질문에는 잘 답했고, 준비한 데모를 보여주자 면접관도 매우 인상적으로 받아들였기 때문에 글쓴이는 면접을 잘 해냈다고 생각했습니다.

데모는 통과했지만 수동 코드 리뷰에서 막혔습니다

분위기가 바뀐 것은 면접관이 “필수는 아니라고 생각하지만, 완벽하게 하려면”이라며 수동 코드 리뷰를 요청하면서부터였습니다. 대상은 단순한 캐시를 구현한 작은 파일 하나였습니다. 글쓴이는 코드를 읽으며 문제가 있는 지점을 본능적으로 감지했고, 실제로 특정 부분에서 멈추며 “여기에 뭔가 있다”고 느꼈습니다. 그러나 그 문제가 정확히 무엇인지, 왜 문제가 되는지 말로 설명하지 못했습니다.

처음 지적한 내용은 SHA-256 해시와 16바이트 배열의 불일치였습니다. SHA-256 결과와 맞지 않는 크기의 배열이 사용된다는 점은 발견했지만, 면접관의 힌트 없이는 그 이상 진행하기 어려웠다고 합니다. 글쓴이는 평소 AI 보조 개발 과정에서는 잘못되어 보이는 코드 블록을 선택하고 AI가 수정하도록 하는 방식에 익숙해져 있었기 때문에, 문제를 인식하면서도 사람이 납득할 수 있는 언어로 분석하는 능력을 잃었다고 설명합니다.

그 밖에도 비동기 루프 안에서 파일을 생성하는 설계가 좋지 않다는 점은 알고 있었지만, 이를 “tokio task spawn blocking”과 연결해 설명하지 못했습니다. reqwest의 bearer_auth 사용법, 값을 빌리기 위한 단순한 & 기호, anyhow context를 통과시키는 방식, await 뒤에 적절한 단계별 ? 처리가 필요한지 등을 놓쳤습니다. 글쓴이는 이런 요소들이 실제 코드를 작성할 때는 AI와 함께 처리할 수 있지만, 면접관에게 각 동작과 오류 전파 과정을 설명해야 하는 상황에서는 전혀 다른 종류의 능력이 필요했다고 말합니다.

AI 보조 개발이 만든 능력의 비대칭

글쓴이는 AI를 사용한다고 해서 오류가 자신의 작업을 그냥 통과하는 것은 아니라고 강조합니다. 오히려 이상한 부분을 눈으로 찾아내고 마우스를 올려 문제를 감지하는 능력은 여전히 남아 있었습니다. 다만 왜 잘못되었는지, 어떤 런타임 동작과 타입·메모리·오류 처리 문제가 발생하는지를 설명하는 능력이 약해졌습니다. 일부는 면접에서의 긴장 때문이지만, 상당 부분은 코딩 근육이 실제로 위축된 결과라고 분석합니다.

과거에는 JavaScript, C#, C++, F#, Rust, HTML, CSS, Go, Python 등 9개 프로그래밍 언어를 동시에 따라갔다고 합니다. 하지만 이제는 코드에서 문제가 보이더라도 “여기”라고 가리키는 것 이상으로 설명하기 어려워졌고, 스스로를 마치 텔레프롬프터에 나오는 코드 외에는 본 적 없는 학부생처럼 느꼈다고 씁니다. AI를 이용해 변경 작업을 수행하고, AI가 같은 실수를 반복하지 않도록 인프라를 구축하는 방식에 몰입한 결과, 직접 코드를 작성하고 설명하는 과정 자체를 잊었다는 진단입니다.

면접관이 AI를 사용하지 말라고 한 뒤 글쓴이는 검색 상단에 나타나는 AI 보조 기능조차 이용하지 않고 문제를 해결했습니다. 이 과정은 상당히 고통스러웠고, 예전에 익숙했던 검색어를 다시 정확하게 작성하는 방법도 잊었다고 합니다. 작은 파일의 버그 7개를 모두 파악하고 수정하는 데 3.5시간이 걸렸습니다. 그 경험을 통해 VS Code를 비롯한 개발 환경 곳곳에서 AI가 전면에 등장하고 있으며, AI 없이 작업하는 일이 과거의 Fortran을 다시 작성하는 것처럼 낯설게 느껴질 정도라는 사실을 실감했다고 말합니다.

면접에서 확인된 역량과 채용 방식에 대한 질문

글쓴이는 마지막 질문 단계에서 회사가 실제로 해결하려는 문제와 가장 많은 작업이 필요한 영역을 구체적으로 물었고, 이것이 면접관을 놀라게 했다고 설명합니다. 그 결과 수동 코드 리뷰에서 완전히 탈락하지는 않았습니다. 면접관은 데모가 가장 인상적이었고 질문도 매우 좋았지만, 수동 리뷰에서 실력을 충분히 보여주지 못한 점은 아쉽다고 말했습니다. 글쓴이는 이후 해당 파일에 대한 수정 사항을 정리한 이메일을 작성했고, AI 없이 모든 수정 작업을 마쳤습니다.

이 경험은 글쓴이에게 개발자에게 실제 업무에서 필요한 능력과 채용 과정에서 검증하는 능력이 다를 수 있다는 문제를 남겼습니다. AI를 활용해 시스템을 만들고 문제를 해결하는 데는 큰 도움이 되는 능력이지만, 채용 면접에서는 여전히 코드를 직접 읽고 해시와 알고리즘의 크기가 맞지 않을 때 어떤 일이 일어나는지 설명하는 능력을 요구합니다. 글쓴이는 자신에게는 “16바이트 배열을 SHA-256 해시에 사용하면 부분적으로 채워지거나 불완전하게 읽혀 캐시에 도달하지 않을 것”이라는 판단만으로 충분했지만, 인간 면접관에게는 그 판단에 이르는 논리와 동작을 설명해야 했다고 말합니다.

따라서 글쓴이는 두 방향을 함께 질문합니다. 개발자가 다시 기초로 돌아가 코드를 직접 편집하고 실행 과정을 설명하는 능력을 회복해야 하는지, 아니면 채용 시스템이 AI를 전제로 한 새로운 개발 방식을 평가하도록 바뀌어야 하는지 묻습니다. 동시에 AI 활용 자체를 부정하지는 않습니다. 글쓴이는 AI에 전적으로 투자하고 있으며, AI가 부족한 부분은 직접 모든 코드를 고치기보다 재발을 막을 인프라를 구축하는 방식으로 보완해 왔다고 설명합니다. 다만 그 결과 수동 코딩과 설명 능력을 의도치 않게 방치했다는 점을 이번 면접에서 확인했습니다.

마지막으로 글쓴이는 면접관과의 대화를 통해 분산 시스템과 이를 실행하는 생태계의 내부 구조를 더 깊이 공부해야겠다는 동기도 얻었습니다. 지금까지 POSIX를 단순히 POSIX compliant라는 표현으로만 접했지만, 면접관이 모든 시스템이 여전히 POSIX를 사용하며 그것이 오래된 구조라는 설명을 해 준 뒤 POSIX 자체를 다음 연구 주제로 삼게 되었다고 합니다. 이 글은 AI를 사용하지 말자는 주장이 아니라, AI 보조 개발로도 문제를 감지할 수 있는 능력과 사람이 그 문제를 설명하고 검증하는 능력이 서로 다르게 유지될 수 있음을 면접 경험을 통해 보여줍니다.

원문: dev.to / 번역·요약: Trawling