코딩의 즐거움을 지키려면 LLM 시대에 에이전트에게 조사와 정리를 맡겨라

Haskell 커뮤니티에 올라온 한 에세이가 LLM 도입이 일반화된 개발 현장에서 "계속 코딩을 즐기는 방법"을 주제로 논의를 촉발했다. 글쓴이는 자신이 Haskell로 코드를 쓰는 과정 자체를 좋아하는 사람이라고 밝히면서, 생성형 코드에 작업을 넘길수록 그 즐거움이 위협받는다고 말한다. 동시에 LLM을 완전히 외면하기는 어려운 현실을 인정하고, 생산성과 재미를 동시에 챙기는 타협안을 제시한다.

글의 핵심 주장은 단순하다. 코드 작성은 사람이 계속 붙잡아야 한다는 것이다. 코드베이스 전체를 생성에 맡기면 결국 에이전트만 살아남을 수 있는 황폐한 저장소가 되고, 몇 주만 손을 놓아도 코딩 감각은 눈에 띄게 떨어진다. LLM은 사람이 읽기 좋은 코드를 만드는 능력에 관해서는 홍보보다 형편없으며, 자기가 이후에 계속 다룰 코드 정도나 그럭저럭 만들어낸다는 것이 그의 평가다.

대신 에이전트에게는 코딩 바깥의 일을 거의 전부 맡기라고 권한다. 도메인 전문가들의 긴 대화를 실행 가능한 할 일 목록으로 바꾸거나, 테스트를 돌리고 그 결과를 정리해 결함 수정 계획으로 묶는 식이다. 계획 항목을 제대로 추적하려면 할 일 도구나 frontmatter를 붙인 마크다운 파일을 쓰라고 조언한다. 컨텍스트 창이 크더라도 가득 차면 정보를 조용히 흘려버릴 수 있다는 점을 경계해야 한다.

중요한 결정은 에이전트에 넘기지 말고, 판단이 필요한 지점에서는 오히려 사람에게 질문을 던지게 하라고 말한다. 질문의 맥락이 이해되지 않는다면 그것은 LLM이 충분한 배경을 주지 못한 탓이며, 같은 문제로 자꾸 되돌아온다면 화면에서 벗어나 직접 생각을 정리한 뒤 돌아오는 편이 낫다.

조사 작업을 맡겼을 때 에이전트가 검색하고 "생각"하는 모습을 지켜보거나 다른 프로젝트의 에이전트를 띄우는 대신, 직접 검색엔진으로 병행 조사하라고 권한다. 에이전트가 알게 될 내용을 사람도 대략 알고 있어야 한다는 것이다. 조사 결과는 근거 링크와 함께 어딘가에 기록하게 하고, 나중에 엉뚱한 제안을 들고 오면 어떤 자료에 그렇게 나와 있는지 캐물으라고 한다. 그러면 절반 정도는 스스로 오류를 발견하고, 나머지 절반은 근거를 읽은 사람이 더 나은 판단을 할 수 있게 된다.

일반적인 코딩 도구가 유도하는 "먼저 계획하고, 그다음 에이전트가 코딩" 흐름은 거부하라고 말한다. 계획은 함께 세우되 코드는 사람이 직접 쓰라는 것이다. 에이전트에게는 코드베이스를 조사시켜 현재 할 일과 손댈 지점, 빠지기 쉬운 함정, 관련 배경 조사를 정리해달라고 요청하는 역할을 맡긴다.

이 제안이 나온 배경에는 AI 번아웃과 일자리 불안, 그리고 프로젝트 코드 품질에 대한 실망이 깔려 있다. 글쓴이는 대형 기술기업이 운영하는 프런티어 LLM의 윤리적 문제에 대해서는 별도의 논의가 필요하다며 이 글의 범위에서 의도적으로 제외한다. LLM을 아예 쓰지 않는 선택도 존중하지만, 팀이나 회사 차원에서 도입이 밀려오는 상황에서 실질적인 생산성 향상을 내야 하는 사람을 위한 현실적인 대안이라는 설명이다.

이 방식의 장점으로 그는 네 가지를 든다. 좋아하는 일을 계속할 수 있고, 코드베이스가 어떤 상태인지 항상 파악되며, 잘못된 계획을 이른 단계에서 알아챌 수 있고, 코딩 실력을 계속 갈고닦을 수 있다는 것이다. 글쓴이는 이 워크플로로 일하면서 LLM 이전보다 오히려 더 즐거울 때도 있다고 말한다. 다만 이는 한 개발자의 개인적 경험과 의견이며, 검증된 방법론이 아니라 선택지 중 하나로 읽는 것이 적절하다.