기본 키 조회 한 번에 SQLite보다 20,171배 느린 LLM 코드. 57만 줄짜리 Rust SQLite 재구현 프로젝트에서 실제 발생한 일이다. 우리는 지금 LLM이 생성한 코드가 얼마나 '그럴듯한지'에 놀라지만, 그 코드가 과연 '맞는 코드'인지, 그리고 '잘 작동하는 코드'인지는 또 다른 이야기다. AI가 엄청난 속도로 코드를 쏟아내는 시대, 개발이라는 행위의 본질과 우리의 역할은 근본적으로 재정의되고 있다.

하지만 이 숫자의 이면에는 또 다른 가능성이 존재한다. 60세 개발자가 Claude Code를 통해 프로그래밍에 대한 식지 않는 열정을 다시 발견했다는 소식은 AI 코딩 도구가 단순히 효율성을 넘어, 개발자에게 새로운 영감과 즐거움을 선사하는 촉매제가 될 수 있음을 보여준다. Active Server Pages나 VB6를 배우며 느꼈던 그 순수한 몰입감을 Claude Code에서 다시 느꼈다는 그의 고백은 AI가 개발의 문턱을 낮추고, 숙련된 이들에게는 또 다른 창조의 기회를 제공한다는 점을 분명히 한다. 이처럼 AI는 개발자에게 양날의 검과 같다. 엄청난 생산성과 가능성을 제시하지만, 동시에 숨겨진 함정과 새로운 요구사항을 던진다.

LLM 코드, '그럴듯함' 너머 '진짜'를 찾는 눈

LLM이 생성한 57만 줄짜리 Rust SQLite 재구현 코드의 벤치마크 결과는 충격적이다. 코드는 컴파일되고 테스트도 통과했지만, 실제 성능은 SQLite 원본에 비해 2만 배 이상 느렸다. 이 간극은 어디서 발생했을까. 문제는 쿼리 플래너가 B-tree 인덱스를 제대로 활용하지 못하고 전체 스캔을 돌리는 것에서 시작했다. `is_rowid_ref()` 함수가 "rowid", "_rowid_", "oid" 세 문자열만 인식하도록 설계되어, `id INTEGER PRIMARY KEY`와 같은 일반적인 선언으로는 B-tree 탐색 경로를 타지 못했다. 100행 데이터를 100회 조회할 때 B-tree 700단계 대신 1만 번의 비교가 발생하며 O(n log n)이 O(n²)으로 바뀌는 치명적인 성능 저하로 이어진 것이다.

이보다 더 미묘한 문제는 바로 '안전한 기본값'의 복리 효과에서 나타난다. 개별적으로 보면 합리적인 선택으로 보이는 결정들이 겹치면서 성능이 기하급수적으로 무너지는 현상이다. Rust의 소유권 모델 때문에 AST를 매번 복제하고 바이트코드를 재컴파일하는 것, 페이지를 읽을 때마다 4KB 힙 할당을 하는 것, 커밋할 때마다 스키마 전체를 재구성하는 것, 그리고 문장마다 `fsync`를 호출하는 것 등이 그러하다. SQLite는 이런 문제들을 핸들 재사용, 캐시에서 포인터 직접 반환, 쿠키 정수값 비교, `fdatasync`로 메타데이터 동기화 생략 등으로 효율적으로 처리한다. LLM은 '시킨 것'을 만들지만, '진정으로 필요한 것'이나 '최적화된 것'을 만들지는 못한다는 점을 단적으로 보여주는 사례이다. 단순히 기능적으로 올바른 코드를 넘어, 성능과 효율성을 겸비한 코드를 생산하는 것은 여전히 인간 개발자의 고유한 영역으로 남아 있다.

독자는 지금부터 LLM이 생성한 코드에 대해 더 비판적인 시각을 가져야 한다. 단순히 코드가 컴파일되고 테스트를 통과하는 것에 만족하지 말고, 실제 운영 환경에서의 성능과 효율성을 검증하는 데 더 많은 노력을 기울여야 한다. 코드 리뷰 시 AI가 제시한 솔루션의 아키텍처적 선택, 알고리즘 복잡도, 그리고 잠재적인 병목 지점을 깊이 있게 분석하는 역량을 강화해야 한다. 작은 기능 구현에는 AI를 활용하되, 핵심 로직이나 성능에 민감한 부분에서는 인간의 전문성을 바탕으로 벤치마크 테스트와 프로파일링을 반드시 수행해야 한다.

AI 에이전트 시대, 시스템적 사고가 성패를 가른다

그렇다면 AI 에이전트가 긴 호흡의 복잡한 작업을 수행하게 하려면 어떻게 해야 할까? OpenAI의 에이전트가 25시간 동안 1,300만 토큰을 사용해 3만 줄의 코드를 생성한 사례는 그 답을 제시한다. 여기서 핵심은 모델 자체의 지능보다 `docs/` 폴더 기반의 체계적인 운영 구조였다. 에이전트의 성공적인 장기 작업은 한 번의 뛰어난 프롬프트가 아니라, 에이전트가 계속 참조할 수 있는 파일 스택, 즉 명확한 목표(`docs/ prompt.md`), 상세한 계획(`docs/ plans.md`), 실행 규칙(`docs/ implement.md`), 그리고 지속적인 문서화(`docs/ documentation.md`) 루프에 달려 있었다.

이러한 구조는 에이전트가 "인상적이지만 틀린 것"을 만들지 않도록 목표를 고정하고, 마일스톤마다 `tests`, `lint`, `typecheck`, `build` 같은 검증을 돌려 실패하면 즉시 수정하게 한다. 이는 '코드를 썼다'는 단순한 결과가 아니라 '검증 가능한 상태로 전진했다'는 프로세스 지향적 접근을 의미한다. Long-horizon 에이전트의 승부처는 모델의 성능이 아니라, 파일 구조와 검증 루프가 만들어내는 견고한 '작업 시스템'인 것이다. 결국 AI 에이전트의 잠재력을 최대한 끌어내기 위해서는 인간이 제공하는 체계적인 가이드라인과 시스템적 사고가 필수적이다.

독자는 AI 에이전트와 협업할 때, 단순히 '무엇을 해달라'는 지시를 넘어 '어떻게 목표를 달성하고, 무엇을 검증하며, 그 과정을 어떻게 기록할 것인가'에 대한 명확한 운영 구조를 설계해야 한다. `docs/` 폴더처럼 목표, 계획, 실행 규칙, 그리고 문서화된 상태를 에이전트가 상시 참조할 수 있도록 시스템화하는 데 집중하라. 이는 에이전트가 독립적으로 작업을 수행하면서도 일관성과 정확성을 유지하게 하는 핵심 열쇠이다. 마치 신입 개발자를 온보딩하듯이, 에이전트에게도 명확한 작업 가이드와 검증 프로세스를 제공하는 것이 중요하다.

고립된 지식 자산, 새로운 협업의 필요성

AI 시대에는 기존 협업 도구의 한계도 명확히 드러나고 있다. 데이터 통합 회사 Fivetran의 CEO는 Slack이 기업의 '축적된 집단 지성'을 폐쇄적인 데이터 정책 안에 가두어, AI와의 효율적인 협업을 가로막는다고 지적한다. Slack은 기업의 운영 방식에 대한 필터링되지 않은 실시간 스트림을 담고 있지만, 그 데이터에 대한 접근 정책은 사실상 "No"에 가깝다. 이는 기업 지식 자산이 사일로화되어 AI 에이전트가 대화에 직접 참여하고 기업 지식을 쉽게 활용하는 것을 방해한다. Claude 같은 AI가 대화에 일등 시민으로 참여하고, 그들의 기술과 플러그인, 컨텍스트를 활용하려면 개방형 협업 플랫폼이 필수적이라는 주장이다.

기존 협업 도구들은 네트워크 효과로 인해 난공불락처럼 보였지만, 실제로는 그리 강력하지 않을 수 있다. AI-네이티브 협업 도구가 제공할 수 있는 이점이 기존 도구의 전환 비용을 상쇄할 만큼 크다면, 시장의 판도는 바뀔 수 있다. 이 문제는 단지 기술적 통합의 영역을 넘어선다. 기업의 핵심 자산인 지식의 흐름을 어떻게 관리하고 활용할 것인가에 대한 전략적 접근이 필요하다. AI 시대에는 인간의 대화와 AI의 지능이 유기적으로 결합하여 새로운 가치를 창출할 수 있는 환경이 요구된다.

독자는 본인이 속한 조직의 협업 도구가 AI 시대의 지식 관리에 적합한지 점검해야 한다. 팀의 '트라이벌 지식'이 특정 도구에 갇혀 AI와의 연동이 어려운 상황은 아닌지 확인하라. AI가 팀 대화에 자연스럽게 참여하고, 축적된 지식을 기반으로 통찰력을 제공할 수 있는 환경을 구축하는 방안을 모색해야 한다. 데이터 접근 정책에 대한 면밀한 검토와 함께, 장기적으로는 AI와의 유기적 협업을 위한 개방형 지식 플랫폼 도입을 고려하는 것이 현명하다.

AI 시대, 인간 개발자의 진화와 경청의 지혜

앤트로픽의 최신 보고서는 컴퓨터 프로그래머(업무 커버리지 75%)를 포함한 화이트칼라 직군이 AI에 가장 많이 노출되고 있으며, AI 커버리지가 10%포인트 증가할 때마다 향후 10년 고용 성장 전망치가 0.6%포인트 하락한다는 구체적인 수치를 제시했다. 특히 청년층의 채용 둔화는 AI가 노동 시장에 미치는 영향이 현실화되고 있음을 보여준다. 보고서에 따르면 Claude 사용 기업들의 AI 활용 사례 중 77%가 '전체 업무 위임'과 같은 자동화 사례였고, '노동 증강'은 12%에 불과했다. 기업들은 인간의 개입을 줄여 비용을 절감하는 완전 자동화를 선호하는 경향이 뚜렷하다.

이러한 현실은 개발자의 역할 변화를 가속한다. 단순 코딩 작업을 넘어, LLM이 만든 비효율적인 코드를 개선하고, 에이전트의 작동 시스템을 설계하며, AI가 생성한 결과물의 품질과 성능을 검증하고, 복잡한 비즈니스 문제를 AI를 활용해 해결하는 '오케스트레이션' 역량이 중요해지고 있다. AI가 빠르게 확장되는 '자율성'의 시대, 인간 개발자는 '그럴듯한' 것과 '진짜'를 구분하는 통찰력, 그리고 시스템 전체의 맥락을 읽어내는 능력을 키워야 한다.

여기서 언어학자 야마다 하루가 말하는 '경청의 기술'은 AI 시대 개발자에게 중요한 지혜를 준다. '경청'은 단순한 수동적 활동이 아니라, 고도의 지능이자 대화를 주도하고 관계를 심화시키는 적극적인 리더십 기술이다. 맥락을 두루 살피는 '느린 듣기'를 통해 상대방이 말하지 않는 암묵적인 의미와 의도까지 포착하고, '거짓말'과 '프레임'을 간파하는 능력은 AI가 쏟아내는 정보의 홍수 속에서 본질을 꿰뚫어 보는 개발자의 중요한 역량으로 치환될 수 있다. AI의 출력을 단순히 수용하는 것이 아니라, 그 배경과 의도, 그리고 잠재적 함정을 '느리게 듣는' 비판적 시각이 필요하다.

독자는 AI가 대체하기 어려운 '문제 정의', '아키텍처 설계', '시스템 최적화', 그리고 AI 에이전트의 '오케스트레이션' 역할에 집중하여 자신의 전문성을 확장해야 한다. AI 도구를 단순히 사용하는 것을 넘어, 그 한계를 이해하고 보완하는 'AI 활용 능력(AI Fluency)'을 최우선으로 습득해야 한다. 마치 야마다 하루가 말하는 '느린 듣기'처럼, AI가 내놓는 결과물을 비판적으로 '듣고', 그 맥락과 의도를 파악하며, 더 나아가 시스템 전체의 품질을 책임지는 '선장'의 역할을 수행하는 데 주력해야 한다.

AI는 분명 개발의 미래를 바꿔놓고 있다. 코드를 생성하는 방식, 협업하는 환경, 그리고 개발자의 커리어 경로까지 모두 변하고 있다. AI가 인간의 일자리를 빼앗을 것이라는 두려움도 크지만, 동시에 AI를 통해 새로운 열정을 찾고 더 높은 차원의 가치를 창출할 기회도 존재한다. 과연 우리는 이 거대한 변화의 흐름 속에서, 단순히 '코드를 만드는 사람'을 넘어 '시스템을 이해하고 가치를 창출하는 사람'으로 진화할 수 있을까?

참고

  • Anthropic, please make a new Slack (Fivetran Blog)
  • 에이전트 코딩의 진짜 변화는 모델이 더 똑똑해진 게 아닙니다. 시간 지평이 바뀌고 있습니다. (Goobong Jeong, LinkedIn)
  • AI 노출 가장 높은 직군은?… 앤트로픽이 밝혀낸 화이트칼라 위기의 실체 (더밀크)
  • 경청의 기술 : 말없이 대화를 주도하는 사람들의 비밀 (롱블랙)
  • LLM 이 쓴 57만 줄은 틀리지 않습니다. 그런데 맞지도 않아요. (Jeongmin Lee, LinkedIn)
  • I'm 60 years old. Claude Code has ignited a passion again (Hacker News)