LLM이 생성한 코드를 직접 다시 입력해 인지 부채를 막자

지난 4월에 했던 말과 달리, 나는 여전히 개인 프로젝트에서 코딩 어시스턴트를 사용하고 있다.

기능 전체를 한 번에 만들게 하면 만족감도 없고 무슨 일이 벌어졌는지 파악하기도 어렵다. 하지만 프로젝트의 지루한 부분을 빠르게 건너뛸 때는 즐겨 사용한다.

다만 코딩 어시스턴트가 프로젝트를 제멋대로 돌아다니게 두면 엄청난 인지 부채가 쌓인다. 웹사이트에 태그 기능을 추가하는 방법을 알아내려고 Django 문서를 샅샅이 읽는 일은 싫을 수 있지만, 그래도 그 기능이 어떻게 작동하는지는 근본적으로 이해하고 싶다. 문제가 지루하다고 해서 해결책을 이해하는 일까지 전부 기계에 넘기고 싶지는 않다.

물론 LLM이 만든 코드를 한 줄도 빠짐없이 검토할 수도 있다. 저주받은 2026년을 사는 개발자 대부분에게 요구되는 일이 바로 이것이다. 로봇이 PR을 올리고 인간이 검토한다. 멋진 신세계다.

하지만 나는 AI가 만든 PR을 검토하는 일이 즐겁지 않다. 지나치게 방어적이고, 주석은 엉망이며, 미묘하게 틀린 코드 수백 줄을 샅샅이 살피는 건 재미가 없다. 고용주를 위해서라면 마지못해 할 수도 있다. 물론 그 고용주가 최대한 빨리 전 고용주가 되도록 노력하면서 말이다. 하지만 개인 프로젝트에서는 절대로 그렇게 하지 않을 것이다. 개인 프로젝트는 무엇보다 재미있어야 한다. 개인 프로젝트에서 느끼는 즐거움은 결과가 아니라 과정에서 나오기 때문이다.

그럼 나는 뭘 해야 할까? 지루한 작업은 LLM에 맡기면서도 내 작업과 사고에 대한 통제권을 쓰레기 생산 기계에 넘기지 않으려면 어떻게 해야 할까?

터무니없이 비효율적이고 어쩌면 조금 우스운 해결책을 하나 생각해 냈다. 코딩 어시스턴트에게 채팅으로 코드를 생성하게 한 다음, 모든 수정 사항을 내가 직접 입력하는 것이다.

내 개인 프로젝트의 모든 에이전트 파일에는 다음 지침이 들어 있다.

나는 이 프로젝트에 들어가는 모든 코드 한 줄 한 줄을 이해하고 싶다. 내가 명시적으로 요청하지 않는 한 프로젝트 파일을 생성하거나 편집하거나 이동하거나 이름을 바꾸거나 삭제하지 마라. 대신 제안하는 모든 수정 사항을 채팅에 보여 줘서 내가 직접 입력할 수 있게 하라. 내가 명시적으로 요청하지 않는 한 프로젝트 파일을 수정하거나 의존성을 설치하거나 저장소 상태를 변경하는 명령을 실행하지 마라. 대신 해당 명령을 채팅에 보여 줘서 내가 직접 실행할 수 있게 하라. 나는 숙련된 개발자다. 명시적으로 요청하지 않는 한 문법, API, 프로그래밍 개념 또는 구현 세부 사항을 설명하지 마라.

LLM을 이런 방식으로 사용하면 전혀 사용하지 않을 때보다 빠르게 작업할 수 있다. 하지만 기계가 자신을 대신해 생각하도록 허용하는 사람들보다는 여전히 느리다. 10x가 아니라 아마 2x 정도 빨라지는 데 그친다. 대신 속도를 포기한 만큼 내 코드를 더 깊이 이해하게 된다.

LLM이 생성한 코드를 한 줄씩 에디터에 직접 입력하면서, 그 코드가 어떻게 작동하고 기존 코드베이스에 어떻게 맞물리는지 머릿속에 모델을 세운다. 이해하지 못하는 API나 알고리즘이 나오면 멈추고 찾아보거나 LLM에 설명을 요청하면 된다.

코드를 직접 입력하면 어쩔 수 없이 속도를 늦추게 되고, 그만큼 LLM의 환각이나 잘못된 설계 결정을 발견할 가능성이 커진다. 입력하는 동안 코드를 정리하고, 구조를 바꾸고, 리팩터링하고, 주석을 추가하며 전반적으로 내 취향에 맞게 다듬을 수도 있다.

무엇보다 이 작업 방식은 코드베이스의 공간 지도를 머릿속에 그릴 수 있게 해준다. 어떤 기능이 코드베이스의 어디에 있는지 모두 알게 된다. 수정할 일이 생기면 정확히 어디를 고쳐야 하는지도 안다. 덕분에 프로젝트 안에서 더 빠르게 작업할 수 있을 뿐 아니라, 앞으로 LLM에 더 나은 프롬프트와 지시를 주기도 쉬워진다.

십 대에 코딩을 배울 때, 숙련된 프로그래머들은 프로젝트에 코드를 절대 복사해서 붙여 넣지 말라고 자주 이야기했다. 책으로 공부할 때는 모든 예제를 컴퓨터에 직접 입력하고 실제로 실행되는지 확인하라는 조언을 받았다. 블로그 글이나 포럼 답변에서 배울 때도 코드를 직접 입력한 뒤 내 코드베이스에 맞게 고쳐서 완전히 이해하라는 조언을 받았다.

LLM이 생성한 코드를 코드베이스에 직접 입력하는 일도 정확히 같은 학습 과정처럼 느껴진다. LLM과 함께 일하는 가장 효율적인 방법은 아닐지 몰라도, 나는 생산성보다 이해를 중요하게 여긴다. 몇 달째 이 방식을 사용하고 있는데 지금까지는 잘 맞는다. 가능한 한 오래 이 작업 방식을 계속 사용할 생각이다.

소프트웨어 업계가 막대한 인지 부채를 떠안고 있으며, 머지않아 그 빚을 갚아야 할까 봐 두렵다. 언젠가는 디지털 인프라의 많은 부분이 어떻게 구성되어 있는지 더 이상 이해하지 못하는 때가 올 것이다. 내가 혼자서 업계 전체의 진로를 바꿀 수는 없겠지만, 적어도 세상에 내놓는 소프트웨어만큼은 완전히 이해하고 있다고 확신할 수 있다. 그렇지 않다면 전문가로서의 직무유기다.

^{source https://ankursethi.com/blog/prevent-cognitive-debt-by-manually-retyping-llm-generated-code/}

HN에서는 LLM이 만든 코드를 다시 입력하는 방식이 이해를 높이는지, 아니면 생산성과 사고력을 함께 잃는 단순 필사인지에 반응이 갈렸다. 이를 지지한 개발자들은 Stack Overflow나 서적의 예제를 옮겨 적던 경험을 들었다. 복사할 때와 달리 직접 입력하면 import가 왜 필요한지, 주변 코드와 어떤 가정을 공유하는지 짚어보게 돼 코드베이스를 파악하는 데 도움이 된다는 설명이다.

반론은 손을 움직이는 일과 스스로 해법을 구성하는 사고를 구분해야 한다는 데서 출발한다. 생성된 답을 그대로 옮기면 문법과 형태는 익힐 수 있어도 대안을 탐색하고 설계상의 제약을 다루기 어렵다. 집중하지 않으면 필사도 기계적인 동작에 그친다. 먼저 직접 구현한 뒤 LLM에 검토와 개선을 맡기거나, 제안받은 코드를 자기 방식으로 고쳐 써야 학습 효과가 크다는 주장도 이어졌다.

실무에서는 모든 줄을 이해하겠다는 목표가 규모가 커질수록 유지되기 어렵다는 지적이 나왔다. 동료의 PR을 전부 다시 쓰지 않듯 방향과 구조, 핵심 결정, 실패했을 때의 영향 범위를 관리하는 능력이 더 중요하다는 시각이다. 반면 개인 프로젝트나 낯선 언어를 배우는 상황이라면 속도보다 과정과 숙련이 목적이므로 느린 방식도 합리적일 수 있다.

현실적인 절충안은 핵심 도메인과 구조를 사람이 정하고, 변경을 작게 나눠 검토하는 것이다. 이해가 필요한 부분은 이유를 묻고 문서와 테스트로 확인해야 한다. 반복 작업과 검증하기 쉬운 세부는 맡길 수 있지만, 나중에 직접 수정하고 장애를 추적해야 할 코드까지 이해 없이 받아들이고 있지는 않은지 판단해야 한다.