얼마 전, 팀 내 주니어 엔지니어 한 명이 작성한 PR(Pull Request)을 리뷰하다가 등골이 서늘해지는 경험을 했습니다. 코드는 겉보기에 완벽했습니다. 변수명도 깔끔하고, 주석도 달려 있었으며, 로직도 그럴싸해 보였죠. 하지만 치명적인 레이스 컨디션(Race Condition) 가능성이 보여서 제가 질문을 던졌습니다. "이 부분, 동시성 처리가 어떻게 보장되는 거죠?" 그 친구는 당황하며 대답하지 못했습니다. 왜냐하면 그 코드는 본인이 짠 게 아니라, Cursor가 생성해 준 코드를 그대로 붙여 넣었기 때문입니다. 더 무서운 건, 그 코드가 왜 작동하는지조차 설명하지 못했다는 점입니다.
솔직히 고백하자면, 저도 개발 생산성을 위해 LLM을 씁니다. 반복적인 보일러플레이트 코드를 짤 때나 정규표현식을 만들 때 이만큼 편한 도구가 없죠. 하지만 최근 실리콘밸리에서 나온 이야기들을 종합해 보면, 우리가 간과하고 있는 거대한 함정이 있습니다. 바로 '탐색(Exploration)'과 '활용(Exploitation)'의 불균형입니다. 과거 우리가 구글링을 할 때는 수많은 검색 결과를 훑어보며 정보를 취사선택하는 '탐색' 과정이 필수였습니다. 그 과정에서 우리는 문맥을 이해하고, 왜 이 코드가 저 코드보다 나은지 사고하는 훈련을 했습니다. 이것이 엔지니어링의 기초 체력이었습니다.
하지만 지금의 LLM 기반 코딩은 '탐색' 과정을 완전히 삭제해 버립니다. 우리는 질문을 던지고, AI가 뱉어낸 첫 번째 답변을 즉시 '활용'합니다. AI가 주는 답은 마치 정답지처럼 보이지만, 사실 그건 확률적으로 가장 그럴듯한 텍스트의 나열일 뿐입니다. 이미 잘 알려진 문제(Known Problem), 즉 '바퀴를 다시 만드는' 수준의 과제에서는 AI가 훌륭한 조수 역할을 합니다. 하지만 여러분이 마주할 비즈니스 로직은 교과서에 나오지 않는 복잡하고 새로운 문제(Novel Problem)들입니다. 여기서 AI는 그럴듯한 거짓말, 즉 환각(Hallucination)을 쏟아냅니다. 이때 엔지니어가 기초 체력이 없다면, 그 코드는 시한폭탄이 되어 프로덕션 환경에 배포됩니다.
우리는 지금 '집중력(Focus)'이라는 가장 강력한 무기를 잃어가고 있습니다. 1990년대 구글이 검색의 시대를 열었을 때와 지금은 다릅니다. 검색은 우리에게 선택권을 주었지만, LLM은 우리에게 '정답 같은 답'을 강요하며 사고의 기회를 빼앗습니다. 코드를 빨리 짜는 게 능사가 아닙니다. "이 코드가 왜 여기서 메모리 누수를 일으키는가?"를 파헤치기 위해 3시간 동안 로그를 뒤지는 그 지루하고 고통스러운 집중력, 그것이 바로 엔지니어의 본질입니다. AI 툴이 발전할수록, 아이러니하게도 이 '집중력'을 유지하는 개발자의 몸값은 천정부지로 솟을 것입니다.
새벽 3시에 서버가 터지고 고객들의 항의가 빗발칠 때, ChatGPT는 여러분을 구해주지 않습니다. 터미널 창에 뜬 붉은 에러 로그를 읽고, 시스템의 아키텍처를 머릿속에 그리며 문제의 원인을 찾아내는 건 결국 인간의 몫입니다. AI가 짠 코드를 리뷰할 능력이 없다면, 여러분은 엔지니어가 아니라 그저 '프롬프트 입력기'에 불과합니다. 회사는 비싼 연봉을 주고 프롬프트 입력기를 고용할 이유가 없습니다. 비용 효율 관점에서 보면, 그런 일은 API 하나로 대체하는 게 훨씬 싸게 먹히니까요.
제가 팀원들에게 항상 강조하는 원칙이 있습니다. "AI가 짠 코드를 이해하지 못하면 커밋하지 마라." 0.1%의 성능 최적화를 위해 밤을 새워본 사람만이 AI의 결과물을 의심하고 검증할 수 있습니다. 기술의 발전 속도가 빠를수록, 역설적으로 더 깊고 느린 사고가 필요합니다. 도구에 잡아먹히지 마십시오. 우리가 기계를 만든 이유는 문제를 더 빨리 해결하기 위함이지, 기계에게 생각하는 법까지 위임하기 위함이 아니었음을 기억해야 합니다. 지금 당장 에디터의 자동 완성 기능을 끄고, 스스로의 힘으로 로직을 처음부터 끝까지 설계해보는 시간을 가져보시길 권합니다. 그 고통스러운 시간이 여러분을 3년 뒤에도 살아남는 엔지니어로 만들어 줄 유일한 동아줄입니다.
