지난 4월에 했던 말에도 불구하고, 저는 여전히 개인 프로젝트에서 코딩 어시스턴트 (Coding Assistants)를 사용하고 있습니다.

어시스턴트를 사용하여 기능 전체를 한 번에 (one-shot) 구현하는 것은 저를 만족스럽지 못하게 하고 방향을 잃게 만들지만, 프로젝트의 지루한 부분들을 빠르게 넘기기 위해 사용하는 것은 즐겁습니다.

하지만 코딩 어시스턴트가 제 프로젝트에서 자유롭게 돌아다니도록 허용하는 것은 엄청난 양의 인지적 부채 (Cognitive Debt)를 남깁니다. 제 웹사이트에 태깅 기능을 추가하는 방법을 알아내기 위해 Django 문서를 꼼꼼히 읽는 것이 싫을 수도 있지만, 저는 여전히 그것이 어떻게 작동하는지 근본적으로 이해하고 싶어 합니다. 단지 문제가 지루하다고 해서 해결책에 대한 이해를 기계에 완전히 떠넘기고 싶다는 뜻은 아닙니다.

물론, LLM이 생성하는 모든 코드 라인을 검토할 수도 있습니다. 그것이 2026년이라는 이 저주받은 해에 대부분의 개발자에게 기대되는 역할입니다. 로봇이 PR (Pull Request)을 올리고, 인간이 그것을 검토합니다. 참으로 멋진 신세계입니다.

하지만 저는 AI가 생성한 PR을 검토하는 것을 즐기지 않습니다. 과도하게 방어적이고, 주석이 엉망이며, 미묘하게 틀린 수백 줄의 코드를 꼼꼼히 살펴보는 것은 즐거운 일이 아닙니다. 고용주를 위해서라면 마지못해 할 수도 있겠지만—그 고용주가 최대한 빨리 전 고용주가 되도록 확실히 조치하면서 말이죠—제 개인 프로젝트를 위해서라면 절대 하지 않을 것입니다. 개인 프로젝트는 무엇보다도 재미있어야 합니다. 개인 프로젝트를 작업하는 즐거움은 결과가 아니라 과정에서 옵니다.

그렇다면 어떻게 해야 할까요? 제 작업과 인지 능력을 이 '슬롭 머신 (Slop Machine, 저질 콘텐츠 생성기)'에 양도하지 않으면서, 어떻게 지루한 작업을 LLM에 떠넘길 수 있을까요?

저는 매우 비효율적이고 어쩌면 약간 우스꽝스러운 해결책을 찾아냈습니다. 코딩 어시스턴트에게 채팅창에서 코드를 생성해 달라고 요청한 다음, 모든 수정 사항을 제가 직접 수동으로 입력하는 것입니다.

저는 개인 프로젝트의 모든 에이전트 (Agents) 파일에 다음과 같은 지침을 넣어두었습니다:

"이 프로젝트에 들어가는 모든 코드 라인을 이해하고 싶습니다. 제가 명시적으로 요청하지 않는 한 프로젝트 파일을 생성, 수정, 이동, 이름 변경 또는 삭제하지 마세요. 대신, 제가 직접 타이핑할 수 있도록 제안하는 모든 수정 사항을 채팅창에 보여주세요."

제가 명시적으로 요청하지 않는 한, 프로젝트 파일을 수정하거나, 의존성 (dependencies)을 설치하거나, 저장소 상태 (repository state)를 변경하는 명령을 실행하지 마세요. 대신, 제가 수동으로 실행할 수 있도록 해당 명령들을 채팅창에 보여주세요.

저는 숙련된 개발자입니다. 명시적으로 요청하지 않는 한 구문 (syntax), API, 프로그래밍 개념 또는 구현 세부 사항을 설명하지 마세요.

이런 방식으로 LLM을 사용하면 LLM을 전혀 사용하지 않을 때보다 더 빠르게 작업할 수 있지만, 기계가 자신을 대신해 생각하도록 허용하는 사람들에 비해서는 여전히 느립니다. 10배 더 빨라지는 대신, 아마 2배 정도만 빨라질 것입니다. 하지만 속도 측면에서 잃는 대신, 코드에 대한 더 깊은 이해를 얻습니다.

LLM이 생성한 코드의 모든 줄을 에디터에 직접 수동으로 타이핑하면서, 저는 코드가 어떻게 작동하고 기존 코드베이스 (codebase)에 어떻게 맞물리는지에 대한 멘탈 모델 (mental model)을 구축합니다. 만약 API나 알고리즘을 이해하지 못한다면, 잠시 멈춰서 찾아보거나 LLM에게 설명을 요구할 수 있습니다.

코드를 직접 타이핑하는 것은 저를 의도적으로 속도를 늦추게 만들며, 이는 LLM이 저지를 수 있는 환각 (hallucinations)이나 잘못된 설계 선택을 감지할 가능성을 높여줍니다. 저는 타이핑을 진행하면서 코드를 정리하고, 재구성하고, 리팩터링 (refactoring)하고, 주석을 추가하며, 일반적으로 제 취향에 맞게 코드를 조정할 수 있습니다.

가장 중요한 것은, 이 워크플로 (workflow)를 통해 제 코드베이스의 *공간적 지도 (spatial map)*를 구축할 수 있다는 점입니다. 저는 코드베이스의 모든 기능이 어디에 위치하는지 알고 있습니다. 변경 사항을 만들어야 할 때, 정확히 어디에서 작업해야 하는지 압니다. 이는 프로젝트 내에서 더 빠르게 작업하도록 도울 뿐만 아니라, 향후 LLM에 더 나은 프롬프트 (prompt)를 작성하고 지시를 내리는 것을 더 쉽게 만들어 줍니다.

제가 십 대 시절에 코딩을 배우고 있을 때, 숙련된 프로그래머들은 제 프로젝트에 코드를 복사해서 붙여넣지 말라고 자주 말하곤 했습니다. 책으로 배우고 있다면, 모든 예제를 컴퓨터에 직접 타이핑하여 실행할 수 있는지 확인하라는 조언을 들었습니다. 블로그 포스트나 포럼 답변을 통해 배우고 있다면, 그것을 완전히 이해할 수 있도록 직접 타이핑하고 제 코드베이스에 맞게 수정하라는 조언을 들었습니다.

LLM이 생성한 코드를 제 코드베이스에 직접 타이핑하는 것은 정확히 동일한 학습 과정처럼 느껴집니다. 이것이 LLM과 협업하는 가장 효율적인 방식은 아닐 수도 있지만, 저는 생산성보다 이해 (Comprehension)를 더 가치 있게 여깁니다. 저는 몇 달 동안 이 방식을 실천해 왔으며, 저에게는 효과적이었습니다. 저는 가능한 한 오랫동안 이 워크플로우 (Workflow)를 계속 사용할 계획입니다.

저는 소프트웨어 산업이 조만간 갚아야 할 막대한 양의 인지적 부채 (Cognitive Debt)를 떠안고 있다는 두려움을 느낍니다. 우리 디지털 인프라의 거대한 부분들이 어떻게 구성되어 있는지 더 이상 이해하지 못하게 되는 시대가 올 것입니다. 개인적으로 산업 전체의 흐름을 바꿀 수는 없을지 모르지만, 적어도 제가 세상에 내놓는 소프트웨어만큼은 완전히 이해하도록 만들 수 있습니다. 그 외의 다른 행동은 전문적인 직무 유기 (Professional malpractice)가 될 것입니다.