LLM 생성 코드를 수동으로 다시 입력하여 인지 부채 예방하기

AI 지원 코딩에서의 인지 부채 문제

대형 언어 모델(LLM)이 프로젝트에 큰 코드 블록을 자동으로 생성하고 삽입하게 하면 "인지 부채"가 발생하는데, 이는 개발자가 자신의 소프트웨어가 어떻게 구성되는지를 근본적으로 이해하지 못하는 상태를 말합니다. AI 어시스턴트는 개발의 "지루한 부분"을 가속화할 수 있지만, 코드를 작성하는 것에서 AI가 생성한 풀 리퀘스트를 merely 검토하는 것으로 전환하는 과정은 종종 깊은 이해의 손실과 시스템의 파편화된 정신 모델을 초래합니다.

AI 생성 코드를 검토하는 과정은 과도하게 방어적이거나, 주석이 부족하거나, 미세하게 잘못된 로직을 뒤지는 unsatisfying한 과정으로 특징지어집니다. 개인 프로젝트에서는 창조 과정 자체가 결과만큼 가치가 있기 때문에, 창조자에서 검토자로의 전환은 개발의 즐거움을 없애고, 저자가 완전히 이해하지 못하는 소프트웨어를 생산함으로써 전문적인 과실의 위험을 초래합니다.

해결책: 수동 재입력

인지 부채를 극복하기 위해 Ankur Sethi는 LLM이 프로젝트 파일을 직접 수정하지 못하도록 하는 워크플로를 사용합니다. 대신 LLM은 채팅 인터페이스에서 편집을 제안하고, 개발자는 그 편집을 편집기에 수동으로 입력합니다.

구현 전략

Sethi는 AI 에이전트에 특정 시스템 명령을 사용하여 이 경계를 강제합니다:

I want to understand every line of code that goes into this project. Never create, edit, move, rename, or delete project files unless I explicitly ask you to do so. Instead, show me every proposed edit in the chat so I can type it in manually.

Do not run commands that modify project files, install dependencies, or change repository state unless I explicitly request that action. Instead, show me those commands in the chat so I can run them manually.

I'm an experienced developer. Do not explain syntax, APIs, programming concepts, or implementation details unless explicitly asked.

수동 입력의 이점

이 접근 방식은 AI로부터의 속도 향상을 줄여(잠재적인 "10배" 증가에서 약 "2배"로 전환) 몇 가지 중요한 인지적 이점을 제공합니다:

정신 모델 구축: 각 줄을 입력함으로써 개발자는 코드베이스의 공간적 지도를 구축하여 기능이 정확히 어디에 위치하는지 알 수 있습니다.
환각 탐지: 강제된 속도 저하로 인해 빠른 스킵이나 diff 검토 중에 놓칠 수 있는 mauvais 설계 선택이나 AI 환각을 더 쉽게 발견할 수 있습니다.
능동 학습: 이 과정은 교과서의 예시를 입력하는 것과 같은 전통적인 학습 방법을 반영합니다; 전사 행위는 개발자가 익숙하지 않은 API나 알고리즘에 대해 멈추고 조사하도록 장려합니다.
커스터마이징: 개발자는 입력하는 동안 실시간으로 코드를 리팩터링, 재구성, 그리고 자신의 취향에 맞게 조정할 수 있습니다.

커뮤니티 관점과 반론

이 제안은 깊은 이해를 우선시하는 개발자와 코딩을 고수준 오케스트레이션 작업으로 보는 개발자 사이에서 상당한 논쟁을 촉발했습니다.

찬성하는 의견

많은 경험이 풍부한 개발자들은 LLM 시대 이전에는 이 "느린 코딩" 습관이 일반적이었다고 지적했습니다.

"Back in the days of Stack Exchange I would always type out manually whatever answer I found to make sure I understood WTF I was adding to the system." — @bandrami

다른 이들은 "생성 효과"를 들어, 텍스트를 생산하는 행위(복사라도)가 수동적인 읽기보다 지식 유지력을 향상시킨다고 제안했습니다.

비판적인 관점

비판자들은 재입력이 실제 추론의 비효율적인 대체물이며, 개발자가 논리를 직접 만들어내지 않는 경우 인지 부채를 예방하지 못한다고 주장합니다.

수동 소비: 일부는 재입력이 단지 "paint-by-numbers"일 뿐이며, 진정한 학습은 의미의 능동적 구축을 요구하고, 문법적으로는 맞지만 "의미적으로 빈" 응답의 전사가 아니라고 주장합니다.
추상화 전환: 일부 개발자들은 산업이 더 높은 수준의 추상으로 이동하고 있다고 믿으며, 여기서 "줄별" 이해는 AI 에이전트를 조종하는 능력보다 덜 중요하다고 생각합니다.
비효율성: 비판자들은 개발자가 AI 코드를 재입력하고 수정하기 위해 충분히 열심히 생각해야 한다면, 오히려 코드를 처음부터 작성하는 것이 낫고 LLM을 완전히 없앨 수 있다고 지적합니다.

대체 완화책

속도와 이해 사이의 균형을 맞추기 위해 여러 가지 대체 전략이 제안되었습니다:

스캐폴딩: LLMs를 사용하여 고수준 구조(클래스, 인터페이스, 함수 시그니처)만 생성하고 로직은 수동으로 구현합니다.
테스트 기반 AI: LLM에게 먼저 테스트(레드 테스트)를 작성하도록 요청한 후, 해당 테스트를 통과하도록 수동으로 코드를 구현합니다.
하이브리드 접근 방식: LLMs를 연구와 학습에 사용하지만, 실제 구현에서는 엄격한 "no-agentic-coding" 규칙을 유지하여 "코딩 취향"을 보존합니다.