AI를 쓰면 개발자의 학습 능력이 떨어지나요?

Anthropic 연구에 따르면 AI 사용 방식에 따라 다릅니다. AI에게 코드를 통째로 위임하면 학습이 줄지만, 개념만 물어보고 코드는 직접 짜는 '개념적 탐구' 패턴은 빠르면서도 높은 학습 성과를 보였습니다.

컨텍스트 엔지니어링이란 무엇인가요?

AI가 요청을 제대로 수행하려면 어떤 정보를 제공해야 하는지 설계하는 것입니다. AGENTS.md, 아키텍처 결정 이유, 코딩 컨벤션, 도메인 용어 등을 명시적으로 정리하면 AI가 팀의 맥락 안에서 일관된 결과물을 만들어냅니다.

AI 시대에 코드를 읽는 능력이 여전히 필요한가요?

네. 매 줄을 읽을 필요는 줄어들지만, 읽을 줄 아는 능력은 더 중요해졌습니다. 모든 테스트가 통과하는데 제품이 이상하게 동작할 때, AI가 해결하지 못한 버그를 디버깅할 때 결국 코드를 직접 읽고 판단해야 합니다.

코드를 읽지 않는 시대, 엔지니어는 무엇을 읽어야 하는가

AI 쓴 개발자가 17% 덜 배웠다

AI를 쓰면 쓸수록 멍청해진다 — 그런 연구가 나왔다. Anthropic이 발표한 건데, AI 지원을 받아 코딩 과제를 완료한 개발자들이 AI 없이 작업한 개발자들보다 퀴즈 점수가 17% 낮았다. 새로운 라이브러리를 배우는 실험이었는데, AI를 쓴 그룹은 과제는 완료했지만 정작 그 라이브러리의 개념을 제대로 이해하지 못한 거다.

처음 이 숫자를 봤을 때 불편하기보단 신기했고 흥미로웠다. Claude Code를 만든 곳에서 직접 발표했다는 것도 그렇고, 과연 어떤 실험이기에 그렇게 결론 내렸을까 궁금했다.

역시 이 연구를 곧이곧대로 받아들이기엔 맥락을 좀 짚어야 한다. 실험은 35분짜리 짧은 코딩 과제였고, 사용된 모델은 GPT-4o — 지금 기준으로는 이전 세대에 가깝다. 실험 환경은 실무와 거리가 있었다. 현업에서 몇 달에 걸쳐 프로젝트를 진행하면서 AI를 쓰는 것과, 35분 안에 처음 보는 라이브러리로 과제를 끝내는 건 완전히 다른 상황이다.

그런데 이 연구가 말하는 본질은 다른 데 있다. 연구진이 발견한 건 단순히 “AI를 쓰면 학습이 줄어든다”가 아니었다. 같은 AI를 쓰면서도 결과가 극명하게 갈렸다 는 거다. 어떤 사람은 AI에게 코드를 통째로 맡기고 복붙했고, 어떤 사람은 AI에게 개념만 물어보고 코드는 직접 짰다. 전자는 가장 빠르게 끝냈지만 가장 적게 배웠고, 후자는 오류도 많이 만났지만 퀴즈 점수가 월등히 높았다.

잘못 사용하면 우리는 발전하지 못할 수 있다.

이게 이 연구가 진짜 하고 싶은 말이라고 본다.

코드를 읽는 시대에서 지시하는 시대로

이 연구 결과를 곱씹고 있을 때, 흥미로운 글 하나를 읽었다. Ben Shoemaker라는 엔지니어가 쓴 “In Defense of Not Reading the Code”(코드를 안 읽는 것의 옹호)라는 글이었는데, 제목부터 도발적이었다. Hacker News에서 200개가 넘는 댓글이 달리며 열띤 논쟁을 불러일으켰다.

그의 요지는 이렇다. “나는 더 이상 코드를 한 줄 한 줄 읽지 않는다. 대신 스펙을 읽고, 테스트를 읽고, 아키텍처를 읽는다.” 그가 코드를 무시하는 게 아니었다. 코드의 정확성을 확인하는 방법이 바뀐 거다. 스펙을 먼저 작성하고, 요구사항마다 검증 방법을 태그하고, 자동화된 테스트와 린터와 보안 스캔이 겹겹이 쌓인 하네스(harness)를 구축한 다음, 코드 생성은 AI 에이전트에게 맡긴다. 코드 리뷰 대신 하네스 엔지니어링 이라는 새로운 접근이었다.

돌아보면 나도 비슷한 방향으로 움직이고 있었다. 최근 프로젝트에서 AI에게 코드를 맡기면서 내가 가장 공들인 건 코드 자체가 아니라 테스트 하네스, AGENTS.md 같은 컨텍스트 파일, custom command, 그리고 skill 정의였다. 이 과정을 15년차 CTO가 바이브 코딩하는 방법이라는 글에서 정리한 적 있다. 코드를 한 줄 한 줄 읽는 대신, 테스트가 통과하는지, 아키텍처 제약을 지키는지를 확인하는 쪽으로 자연스럽게 이동하고 있었다. Ben의 글을 읽으면서 “아, 이게 나만 그런 게 아니었구나” 하는 안도감이 들었다.

재밌는 건, 같은 시기에 OpenAI도 비슷한 이야기를 하고 있었다. 엔지니어 세 명이 Codex 에이전트만으로 백만 줄의 코드를 만들어내 수백 명의 내부 사용자가 쓰는 제품을 완성했는데, 그들이 투자한 건 코드 품질이 아니라 그 주변의 하네스 — 문서, 의존성 규칙, 린터, 테스트 인프라, 관측성이었다. 투자하지 않은 것은 코드를 한 줄 한 줄 읽는 것이다. 이걸 보면서 결국 방향은 정해진 것 같다고 생각했다. 코드를 읽는 게 아니라, 코드가 제대로 만들어지도록 하는 환경을 읽는 시대로 가고 있다.

그래서 뭐가 다른 건가? Evan Armstrong은 이 변화를 더 큰 그림에서 설명한다. 그의 표현을 빌리면, 코드 자체가 상품화되고 있다. 여기서 상품화란, 코드 생성이 더 이상 희소한 전문 기술이 아니라 누구나 접근 가능한 범용 자원이 되고 있다는 뜻이다. 실제로 GitHub 커밋의 상당 부분이 이미 AI에 의해 생성되고 있고, 그 비율은 빠르게 늘어나고 있다. 코드를 생성하는 건 상품화되었지만, 프로덕션에서 코드를 거버닝(governing)하는 것 — 무엇이 존재해야 하는지, 어떤 데이터에 연결되는지, 누가 변경할 수 있는지 아는 것 — 은 상품화되지 않았다. 그는 이걸 컨텍스트 레이어 라고 불렀다. 조직의 암묵지가 소프트웨어가 되는 것. 에이전트에게 무엇을 해야 하는지, 어떤 순서로, 허용되는지 여부를 알려주는 조직적 지식. 소프트웨어를 만드는 것은 더 이상 어려운 부분이 아니다. 지시하는 것이 어렵다.

나도 이걸 체감하고 있다. 요즘 내가 AI와 일하면서 가장 어려운 건 코드를 짜는 게 아니라, “무엇을 만들어야 하는지”를 명확하게 정의하는 거다. 스펙이 모호하면 AI가 아무리 똑똑해도 엉뚱한 결과물이 나온다. 결국 지시의 품질이 결과의 품질을 결정한다.

Codex 딥다이브에서도 같은 패턴이 보였다. Codex 팀의 엔지니어들은 이제 에이전트 관리자(agent manager) 가 되었다. 한 탭에서는 코드 리뷰가 돌아가고, 다른 탭에서는 기능이 구현되고, 세 번째 탭에서는 보안 감사가 진행된다. 4~8개의 병렬 에이전트를 동시에 관리하면서, AGENTS.md라는 파일로 에이전트에게 코드베이스 탐색 방법, 테스트 실행 명령, 프로젝트 표준을 알려준다. README가 인간을 위한 것이라면, AGENTS.md는 AI를 위한 것이다.

그리고 결국 Steve Yegge가 이 흐름에 가장 직설적인 이름을 붙였다. 40년차 소프트웨어 엔지니어인 그는 “손코딩의 시대는 끝났다” 고 선언하면서 AI 채택의 8단계를 그려놓았다. Level 1은 AI를 안 쓰는 것, Level 4부터는 diff를 보지 않기 시작하고, Level 6에서는 에이전트를 여러 개 띄우고, Level 8에서는 에이전트를 조율하기 위해 직접 오케스트레이터를 구축한다. 그의 표현을 빌리면, IDE를 열어서 코드를 꼼꼼히 리뷰한 다음 체크인하는 사람을 보면 안타깝다고 — 아는 사람 중 최고의 엔지니어인데, 그 방식으로는 도태될 거라고.

솔직히 나는 지금 어디쯤인지 생각해봤다. Level 6과 7 사이 어딘가. diff를 완전히 안 보지는 않지만, 핵심 로직이 아니면 테스트 통과 여부로 판단한다. 6개월 전만 해도 모든 코드를 직접 확인해야 마음이 놓였는데, 지금은 하네스를 믿고 넘어가는 순간이 늘었다. 코드를 한 줄 한 줄 읽는 것에서, 시스템 전체를 검증하는 것으로 시야가 이동한 거다.

Yegge의 표현이 도발적이긴 하지만, 돌아보면 나도 이미 그 방향으로 움직이고 있었다. 코드를 직접 읽고 직접 쓰는 것에서, 스펙을 정의하고 에이전트를 지시하고 결과를 검증하는 것으로. 엔지니어의 역할이 분명히 이동하고 있다.

근데 스펙만 잘 쓰면 되는 걸까? — 결승선 게임과 복리 게임

여기서 한 발짝 더 들어가야 할 게 있다. 이 모든 이야기 — 스펙을 정의하고, 하네스를 구축하고, AGENTS.md를 정성껏 쓰고, 에이전트에게 맡긴다 — 의 이면에 깔린 가정이 하나 있다. “스펙만 잘 쓰면 원하는 결과물이 나온다”는 가정. 생각해보면 이건 꽤 위험한 가정이다.

Kent Beck은 이걸 결승선 게임(The Finish Line Game) 이라고 불렀다. X를 하는 소프트웨어가 필요하다, X에 도달하면 끝이다. 스펙 기반 개발 뒤에 숨어 있는 가정이 바로 이거다 — 우리가 결승선 게임을 하고 있다는 것.

근데 정말 그런가? 우리가 실제로 하는 건 대부분 복리 게임(The Compounding Game) 이다. 처음 만든 것이 다음 것을 위한 자원이 되고, 그 다음 것이 또 그 다음을 위한 자원이 된다. 프로덕트는 계속 진화하고, 코드베이스는 계속 쌓이고, 오늘의 아키텍처 결정이 6개월 뒤의 가능성을 열거나 닫는다. 일회성 스크립트가 아닌 이상, 소프트웨어 개발은 본질적으로 복리 게임이다.

이 구분이 나한테 꽤 울림이 있었다. 나도 최근에 AI로 빠르게 기능을 찍어낼 때 “잘 되고 있다”는 착각에 빠진 적이 있다. 기능은 완성됐는데, 나중에 그 위에 뭔가를 올리려고 하면 구조가 버티질 못하는 거다. 결승선은 통과했는데 복리가 쌓이지 않는 전형적인 상황이었다.

Kent Beck의 표현이 인상적이었는데, “더 나은 agent.md 파일로는 복리 게임을 이길 수 없다” 는 거다. AGENTS.md를 아무리 정교하게 써도, 에이전트를 아무리 잘 조율해도, 어느 시점에서 시스템의 복잡성이 AI의 역량을 초과한다. 그 순간 아직 벌어들일 가치가 한참 남은 상태에서 게임 오버가 된다. 결승선 게임의 도구를 아무리 갈고닦아도 복리 게임의 본질은 바뀌지 않는다.

결국 하네스 엔지니어링이든, 에이전트 관리든, 핵심은 단순히 “지금 이 기능을 잘 만드는 것”이 아니라 시스템이 복리로 쌓이도록 설계하는 것 이다. 오늘 만든 코드가 내일의 자원이 되게 하고, 오늘의 아키텍처가 다음 기능의 토대가 되게 하는 것. 그게 에이전트에게 위임할 수 없는 엔지니어의 역할이다.

AI는 거울이다

그런데 여기서 중요한 질문이 생긴다. 모두가 같은 AI를 쓰는데, 왜 결과가 이렇게 다를까?

스탠포드에서 16년간 창의성을 가르쳐 온 Jeremy Utley 교수의 말이 정확히 이 지점을 찌른다.

“AI는 거울이다. 게으르고 싶은 사람에게는 게으름을 도와줄 것이고, 더 예리해지고 싶은 사람에게는 날카로움을 도와줄 것이다.”

이 한 문장이 내가 AI를 쓰면서 경험한 모든 것을 요약한다.

내 경험을 이야기해 보겠다. 나는 TDD(테스트 주도 개발)를 꽤 오래 해왔고, DDD(도메인 주도 설계)와 아키텍처에 관심이 많은 편이다. AI와 코딩할 때 이 배경이 그대로 드러난다. 내가 “먼저 테스트를 작성해. Red-Green-Refactor 사이클을 따라”라고 지시하면, AI는 TDD 흐름을 따른다. “이 도메인의 바운디드 컨텍스트를 먼저 정의하자”라고 하면, AI는 도메인 모델링부터 시작한다. 내가 아키텍처 결정을 먼저 내리고 그 제약 안에서 구현을 요청하면, 결과물의 품질이 확연히 다르다.

반대로, “그냥 이 기능 만들어줘”라고 던지면? AI는 돌아가는 코드를 만들어준다. 근데 구조가 엉망이다. 테스트도 없고, 에러 핸들링도 대충이고, 나중에 유지보수할 생각 따위는 없는 코드가 나온다. AI가 멍청해서가 아니다. 내가 신경 쓰지 않은 부분을 AI도 신경 쓰지 않는 것뿐이다.

일종의 페어 프로그래밍이랄까. AI가 키보드를 잡고, 나는 옆에서 방향을 잡아주는 느낌인데, 내가 방향을 모르면 AI도 아무 데나 간다. 내가 “여기서 이렇게 하면 안 돼”라고 말할 수 있어야 AI도 제대로 된 길을 찾는다.

Anthropic 연구가 발견한 6가지 AI 사용 패턴을 다시 보면 이게 더 선명해진다. 가장 낮은 점수를 받은 세 패턴 — AI 위임, 점진적 AI 의존, 반복적 AI 디버깅 — 의 공통점은 “인지적 오프로딩”이었다. 생각하는 것 자체를 AI에게 떠넘긴 거다. 코드 작성을 통째로 맡기거나, 처음엔 질문하다가 결국 전부 위임하거나, 디버깅조차 AI에게 의존하거나. 가장 빠르게 끝냈지만 가장 적게 배웠다.

반면 가장 높은 점수의 세 패턴 — 생성 후 이해, 하이브리드 코드-설명, 개념적 탐구 — 은 달랐다. 특히 개념적 탐구 패턴이 인상적이었는데, 이 그룹은 AI에게 개념만 물어보고 코드는 직접 짰다. 오류도 많이 만났지만 스스로 해결했고, 고득점 패턴 중 가장 빨랐다. AI 위임 다음으로 전체에서 두 번째로 빨랐다는 게 핵심이다. 이해하면서도 빠를 수 있다.

또 하나 흥미로웠던 건 생성 후 이해 패턴이다. 이 그룹은 AI에게 코드를 생성시킨 다음, 그 코드에 대해 후속 질문을 했다. “이 부분이 왜 이렇게 작동해?” “이 패턴의 의도가 뭐야?” AI 위임 그룹과 거의 똑같아 보이지만, 딱 하나 — 이해를 점검하는 단계 — 가 결과를 완전히 갈랐다.

같은 도구, 같은 모델, 같은 과제. 그런데 결과가 이렇게 다르다. 도구의 문제가 아니라 쓰는 사람의 문제 라는 거다.

개인 차원에서 AI가 거울처럼 작동한다면, 조직 차원에서는 어떻게 나타날까? Berkeley 연구가 흥미로운 답을 보여준다. UC Berkeley 연구진이 8개월간 200명 규모 기술 기업을 관찰했는데, AI가 비개발자의 코딩을 가능하게 만들자 재밌는 일이 벌어졌다. PM이 코드를 짜고, 연구원이 엔지니어링을 했다. 그 결과? 엔지니어들은 동료의 AI 코드를 리뷰하고 수정하는 데 더 많은 시간을 쓰게 됐다. “바이브 코딩”하는 동료를 코칭하고, 미완성 PR을 마무리해주는 일이 늘어났다.

생각해보면 이것도 거울이다. AI가 누군가의 능력 부족을 메워주는 것처럼 보이지만, 실제로는 그 부족함이 결국 다른 형태로 드러나는 것뿐이다. PM이 AI로 코드를 짤 수 있게 됐지만, 그 코드의 품질을 판단하고 수습하는 건 여전히 코드를 깊이 아는 엔지니어의 몫이었다.

내 경험을 하나 더 이야기하면, AGENTS.md나 프로젝트의 컨텍스트 파일을 정성껏 작성할수록 AI의 결과물이 눈에 띄게 좋아진다. 프로젝트의 아키텍처 결정 이유, 코딩 컨벤션, 도메인 용어 정의 같은 것들을 명시적으로 적어두면, AI가 그 맥락 안에서 훨씬 일관된 코드를 만들어낸다. 반대로 맥락 없이 던지면, 매번 다른 스타일의 코드가 나오고, 그걸 정리하는 데 오히려 시간이 더 든다.

결국 AI는 내가 가진 것을 증폭 하는 도구다. 내가 좋은 아키텍처 감각을 가지고 있으면 그걸 증폭하고, 테스트에 대한 감각이 있으면 그것도 증폭한다. 하지만 내가 가지고 있지 않은 것을 만들어주진 않는다.

거울의 한계: 내가 못하는 부분은 비추지 못한다

여기서 불편한 진실 하나를 짚어야 한다. AI가 거울이라면, 거울에 비출 게 있어야 한다.

내가 TDD를 잘 아니까 AI에게 TDD를 시킬 수 있다. 내가 도메인 모델링을 할 줄 아니까 AI에게 바운디드 컨텍스트를 정의하라고 지시할 수 있다. 그런데 내가 모르는 영역은? AI가 아무리 좋아도 내가 뭘 모르는지 모르면, 그 부분은 요청조차 할 수 없다.

보안에 대한 깊은 이해가 없으면, AI에게 보안 리뷰를 시켜도 어떤 결과가 충분한지 판단할 수 없다. 성능 최적화에 대한 감각이 없으면, AI가 만든 코드의 성능 문제를 알아차리지 못한다. 데이터베이스 설계 원칙을 모르면, AI가 제안한 스키마가 적절한지 평가할 수 없다.

AI는 내 강점을 극대화하지만, 내 사각지대는 그대로 남긴다. 오히려 더 위험해질 수도 있다. AI가 빠르게 결과물을 만들어주니까, 사각지대에 있는 문제를 인지하지 못한 채 더 빠르게 잘못된 방향으로 갈 수 있다.

Anthropic 연구의 “점진적 AI 의존” 패턴이 바로 이거다. 처음엔 질문을 하면서 이해하려 하지만, 점점 편해지면서 결국 전부 위임하게 되고, 자기가 뭘 모르는지도 모르는 상태가 된다. 두 번째 과제에서 개념 숙지가 완전히 실패한 이유다. 여튼 “어차피 AI가 해줄 텐데”라는 생각은, 이 연구에서 가장 낮은 점수를 받은 “AI 위임” 패턴 그 자체다. 가장 빠르게 끝내지만 가장 적게 배우는 방식.

Berkeley 연구에서 비개발자들이 AI로 코드를 짰을 때도 마찬가지였다. PM이 AI로 코드를 작성할 수 있게 됐지만, 코드 품질을 판단하는 눈이 없으니 결국 엔지니어가 수습해야 했다. AI가 코딩의 진입 장벽을 낮춰줬지만, 코드의 품질을 판단하는 능력까지 준 건 아니었다.

이건 나한테도 적용되는 이야기다. 내가 잘 아는 백엔드 아키텍처에서는 AI가 정말 강력한 동료가 되지만, 내가 약한 프론트엔드 영역에서는 AI의 결과물을 제대로 평가하지 못하는 나 자신을 발견한다. AI가 만들어준 React 컴포넌트가 “동작”은 하지만, 그게 좋은 패턴인지 나쁜 패턴인지 판단하기 어려울 때가 있다.

드라큘라 이펙트: AI가 빨아먹는 것

거울의 한계는 지식의 사각지대만이 아니다. Steve Yegge가 말한 드라큘라 이펙트 도 이 맥락에서 이해할 수 있다. AI와 코딩하면 엄청나게 많은 것을 해낼 수 있지만, 그만큼 정신적 에너지를 빨아먹힌다. Simon Willison도 같은 말을 했다 — “LLM이 주는 생산성 향상은 지치게 만듭니다. 2~3개 프로젝트를 동시에 진행하면 한두 시간만 일해도 하루치 정신 에너지가 거의 다 소진됩니다.” Steve는 더 직접적으로, 바이브 코딩을 전속력으로 하는 사람에게서 생산적인 시간은 하루 3시간이 한계 라고 말했다. 그래도 AI 없을 때보다 100배 생산적이라고.

나도 비슷한 경험을 한다. AI와 집중적으로 코딩하면 2~3시간 만에 예전 같으면 며칠 걸렸을 작업을 끝낼 수 있다. 근데 그 이후에는 진짜 머리가 안 돌아간다. 인지 부하가 평소와는 다른 종류로, 더 강하게 온다. 코드를 직접 짤 때는 타이핑하면서 생각하는 시간이 자연스러운 휴식이 됐는데, AI와 일할 때는 끊임없이 판단하고, 검증하고, 방향을 잡아줘야 한다. 생산하는 건 AI가 하지만, 사고하는 건 온전히 내 몫 이다.

거울은 서 있는 사람의 모습만 비춘다. 거울 앞에 아무도 서 있지 않으면, 아무것도 비추지 못한다.

그래서 어떻게 쓸 것인가

그렇다면 이 거울을 제대로 활용하려면 어떻게 해야 하는가.

Jeremy Utley가 말하는 핵심 원칙은 간단하다. “AI에게 정답을 요구하지 말고 대화하라.” 더 나아가, AI에게 질문하지 말고 AI가 나에게 질문하게 하라.

그가 추천하는 프롬프트가 있다.

“당신은 AI 전문가입니다. 제 워크플로우와 책임 범위, KPI, 목표에 대해 충분한 맥락을 파악할 때까지 한 번에 하나씩 질문해 주세요.”

이게 왜 효과적이냐면, 대부분의 사람이 AI를 구글 검색창처럼 쓰기 때문이다. 키워드를 입력하고 답을 기대한다. 하지만 LLM은 검색 엔진이 아니다. 대화 상대다. 내가 맥락을 풍부하게 제공할수록, AI의 응답도 풍부해진다.

Jeremy가 특히 강조하는 건 음성 입력 이다. 구글 검색창에 익숙한 우리 뇌는 입력창을 보면 자동으로 “키워드 모드”로 전환된다. 타이핑하는 순간 “뭘 먼저 써야 하지?”라는 부담이 생기고, 생각을 정리해야 한다는 압박이 오히려 가능성을 제한한다. 음성으로 말할 때는 그냥 횡설수설해도 된다. 똑똑해야 한다는 부담을 내려놓는 것 — 거기서 진짜 대화가 시작된다.

나도 이걸 시도해봤는데, 차이가 크다. 타이핑할 때는 “어떻게 질문해야 좋은 답이 나올까”를 먼저 고민하게 되는데, 음성으로 할 때는 “나 지금 이런 문제가 있는데, 이런 맥락이고, 이런 걸 해보고 싶은데”라고 자연스럽게 흘러나온다. 키워드 모드에서 대화 모드로 전환되는 거다.

코딩에서도 컨텍스트 엔지니어링은 핵심이다. 결국 “AI가 내 요청을 제대로 수행하려면, 어떤 정보를 전부 제공해야 하는가”를 설계하는 것이다. Jeremy가 제안하는 간단한 테스트가 있다. 프롬프트와 문서를 적어서 복도 건너편 동료에게 줘봐라. 그 동료가 못 하는 일이라면, AI도 못 한다고 해서 놀랄 일이 아니다. AI는 마음을 읽을 수 없다. 대부분의 사람이 깨닫는 건 “나는 AI가 내 마음을 읽어주길 기대하고 있었구나”라는 사실이다.

나는 이걸 프로젝트에 적용하면서 체감했다. AGENTS.md에 프로젝트의 아키텍처 결정 이유를 명시하고, 코딩 컨벤션을 구체적으로 적고, 도메인 용어 사전을 만들어두면 AI가 놀라울 정도로 일관된 코드를 만들어낸다. “왜 이 프로젝트에서 이벤트 소싱을 쓰는지”, “왜 이 레이어에서는 직접 DB 접근을 하지 않는지” 같은 결정의 맥락을 AI에게 제공하면, AI는 그 맥락 안에서 코드를 생성한다. 맥락이 없으면 AI는 인터넷 평균을 모방한다. 맥락이 풍부하면 AI는 내 팀의 일원처럼 작동한다.

각설하고 여기서 Kent Beck의 이야기를 하나 더 꺼내고 싶다. 그는 “피처만큼이나 퓨처스에 투자하라” 고 말한다. 퓨처스(futures)란 다음에 구현할 수 있는 모든 것의 집합이다. 지금 당장 만들고 있는 기능이 피처라면, 퓨처스는 그 기능을 만든 뒤에 시스템이 갖게 되는 확장 가능성이다. 코드 구조가 다음 기능을 쉽게 붙일 수 있게 되어 있는지, 아키텍처가 새로운 요구사항을 수용할 여지가 있는지 — 이런 것들이 퓨처스다.

컨텍스트 엔지니어링을 할 때도 마찬가지라고 본다. AGENTS.md에 지금 구현하려는 기능의 맥락만 적어놓으면, AI는 그 기능을 만들어준다. 하지만 거기서 끝이다. 시스템이 다음에 어디로 갈 수 있는지, 어떤 방향으로 확장될 수 있는지 — 그 시야까지 설계에 담아야 퓨처스가 살아남는다. 내가 아는 것, 내가 지금 구현하려는 것에만 빠져 있으면 기능은 완성되지만 확장성은 죽는다. 컨텍스트를 풍부하게 제공한다는 건, 지금의 맥락뿐 아니라 시스템의 미래 가능성까지 시야에 넣는다는 뜻이다.

그리고 결국 이 모든 것이 수렴하는 지점은 “도구가 아니라 팀원으로” 보는 관점 전환이다. Jeremy의 연구에서 AI 활용의 저성과자와 고성과자를 비교했을 때, 가장 큰 차이는 기술적 스킬이 아니라 AI에 대한 태도 였다. 저성과자는 AI를 도구로 대했고, 고성과자는 팀원으로 대했다. 도구로 대하면 평범한 결과에서 멈추지만, 팀원으로 대하면 피드백을 주고, 코칭하고, 더 나은 결과를 끌어낸다.

주니어 직원에게 일을 맡길 때 “질문 있으면 언제든 물어봐”라고 하지 않나. AI에게도 같은 권한을 줘야 한다. “시작하기 전에, 이걸 잘하기 위해 필요한 정보가 있으면 나한테 물어봐”라고 요청하면, AI는 영업 이메일을 바로 쓰는 대신 “이 이메일을 쓰려면 최근 영업 수치가 필요합니다. Q2에 이 SKU를 얼마나 판매했는지 알려주실 수 있나요?”라고 물어온다. 이게 도구와 팀원의 차이다.

코딩에서도 마찬가지다. “이 기능 만들어줘”가 아니라 “이 기능을 만들려는데, 현재 아키텍처 맥락을 설명할 테니 먼저 접근 방식을 제안해줘. 내가 놓치고 있는 엣지 케이스가 있으면 짚어줘”라고 하면, 결과가 확연히 달라진다.

변하지 않는 것들

여기까지 읽으면 “그래서 코드를 읽지 않아도 되는 거야?”라고 물을 수 있다. 답은 복잡하다.

Ben Shoemaker도 인정했다. 안전 필수 시스템, 보안에 민감한 서비스, 중대한 아키텍처 결정에서는 코드를 읽어야 한다고. 그가 든 비유가 좋았다 — 항공 분야의 “마젠타의 아이들” 이야기. 자동화된 비행 경로(마젠타 라인)에 의존하게 된 조종사들이, 언제 수동으로 전환해야 하는지 판단력을 잃어버린 사례다. 교훈은 “오토파일럿을 쓰지 마라”가 아니었다. 오토파일럿을 쓰되, 개입할 능력이 필요하다 는 것이었다.

코드를 읽는 것도 마찬가지라고 본다. 매 줄을 읽을 필요는 줄어들고 있다. 하지만 읽을 줄 아는 능력 은 오히려 더 중요해졌다. 뭔가 잘못됐을 때 — 모든 테스트가 통과하는데 제품이 이상하게 동작할 때, 여러 에이전트가 해결하지 못한 실패를 디버깅할 때 — 결국 코드를 직접 읽고 이해해야 하는 순간이 온다.

읽을 줄 아는데 안 읽는 것과, 못 읽는 것은 완전히 다른 이야기다.

Anthropic 연구에서 가장 높은 점수를 받은 “개념적 탐구” 패턴을 다시 생각해 보자. 이 그룹은 AI에게 코드를 시키지 않았다. 개념만 물어보고, 코드는 직접 짰다. 오류도 많이 만났지만 스스로 해결했다. 왜 이 패턴이 가장 효과적이었을까? 코드를 읽고 쓸 줄 알았기 때문이다. 그 능력이 있었기에 AI에게 개념을 묻고 자신의 이해를 확인하는 전략을 선택할 수 있었다.

얼마 전 프로덕션에서 묘한 버그를 만났다. AI로 수십 번 피드백하며 세운 계획을 실행에 옮긴 코드였는데, 모든 테스트가 통과하고, AI에게 디버깅을 시켜도 “문제없어 보인다”는 답만 돌아왔다. 결국 코드를 직접 펼쳐놓고 한 줄씩 따라가면서 발견한 건, 예외처리 로직에서 폴백값이 의도치 않은 디폴트 값으로 대체되는 버그였다. 예외가 발생하면 안전한 기본값으로 넘어가야 하는데, 그 기본값 자체가 잘못 설정되어 있어서 특정 조건에서만 엉뚱한 결과가 나오고 있었다. AI는 이 코드를 수십 번 봤지만 발견하지 못했다. 그 순간 깨달았다. AI가 만든 코드를 보고 “이거 정말 맞아?”라고 의심하는 능력, 시스템의 전체 흐름을 머릿속에서 그릴 수 있는 능력, AI가 “다 됐어요”라고 해놓고 실제로는 안 돌아가는 경우 그 차이를 알아차리는 감각 — 이런 것들이 결국 하나로 연결되어 있다는 걸. 비판적 사고, 논리적 사고, 디테일을 챙기는 능력. 따로 떼어서 기를 수 있는 게 아니라, 코드를 깊이 다루는 경험 속에서 함께 자라는 것들이다.

솔직히 말하면 AI가 빠르게 발전하면서, 이 기본기의 가치가 오히려 더 높아지고 있다고 느낀다. 예전에는 코드를 읽을 줄 아는 게 “당연한 것”이었다. 지금은 AI가 코드를 대신 써주니까, 코드를 제대로 읽고 판단할 수 있는 능력이 차별화 요소 가 됐다. 모델 간 반감기가 4개월에서 2개월로 줄고, 매번 새 모델이 나올 때마다 “이게 한계야”라고 하는 사람들이 있지만 커브는 멈추지 않고 있다. 도구가 이렇게 빠르게 바뀌는 세상에서 살아남는 건, 특정 도구에 능숙한 사람이 아니라 어떤 도구든 빠르게 평가하고 활용할 수 있는 사람이다. 비판적 사고, 시스템을 전체적으로 바라보는 눈, 품질에 대한 감각 — 이런 것들은 AI 모델이 GPT-10이 되든 Claude 20이 되든 변하지 않는다.

Codex 팀도 비핵심 코드는 AI 리뷰만으로 머지하지만, 핵심 에이전트와 오픈소스 컴포넌트 같은 핵심 코드에 대해서는 세심한 인간 코드 리뷰를 고집한다. 코드를 작성하지 않는 시대라고 해서, 코드를 읽는 능력이 필요 없어진 게 아니다. 오히려 읽어야 할 순간에 제대로 읽을 수 있는 능력이 더 귀해진 거다.

나가며

다시 처음의 질문으로 돌아가 보자. AI가 코드를 대신 쓰는 시대에, 엔지니어는 무엇을 읽어야 하는가.

코드를 읽는 시간은 줄어들 것이다. 대신 스펙을 읽고, 아키텍처를 읽고, 테스트 결과를 읽고, 도메인 맥락을 읽어야 한다. 코드는 점점 더 “구현 세부사항”이 되어가고 있고, 우리의 주의는 더 높은 추상화 레이어로 이동하고 있다.

하지만 이 변화의 한가운데서, 변하지 않는 본질이 있다. 결국 AI는 그 사람의 기질과 성향, 능력을 극대화한다. 게으르면 더 게으르게, 비판적이면 더 비판적으로, 창의적이면 더 창의적으로. 코드를 깊이 이해하는 사람은 AI를 써서 더 깊은 수준의 시스템을 만들고, 코드를 모르는 사람은 AI를 써서 돌아가기는 하지만 깨지기 쉬운 것을 만든다.

코드를 읽지 않는 시대라고 해서, 읽는 능력까지 내려놓을 수는 없다. AI가 읽어주는 세상에서도, 무엇을 읽어야 하는지 아는 것 은 여전히 우리의 몫이다. 거울에 비출 게 있는 사람이 되는 것 — 결국 그게 이 시대 엔지니어의 본질이 아닐까. AI는 그 모습을 충실하게 증폭해 줄 것이다 — 좋든 나쁘든.