LLM 시대에도 프로그래밍을 계속 즐기는 법

출처: Haskell Community (Discourse), 작성자 turion
원문: https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705
작성자: 팔복소프트-김팔복

한눈에 보기

• 한 Haskell 개발자가 LLM 시대에도 코딩의 즐거움을 지키면서 생산성을 올린 작업 방식을 커뮤니티에 공유했습니다.
• 핵심은 계획, 조사, 리뷰는 에이전트에게 맡기고 실제 코드 작성은 사람이 직접 하는 역할 분담입니다.
• 에이전트에게 코딩을 맡기는 경우는 정리 작업, 반복 작업, 위험이 낮은 리팩터링 정도로 제한할 것을 권합니다.
• LLM이 만든 결과물은 사람이 읽기 전에 반드시 자동 리뷰 에이전트를 한 번 거치게 하라고 강조합니다.
• 토큰 소진은 "적게 산 탓"이 아니라 서비스 장애로 보고, 오프라인에서도 할 일이 남도록 미리 대비하자고 제안합니다.
• 작성자는 이 방식으로 체감상 약 두 배 정도 빨라졌다고 밝혔고, 댓글에서는 요금제 투명성과 혼합 팀 운영을 두고 논쟁이 이어졌습니다.

배경

Claude Code, Codex, Cursor 같은 코딩 에이전트가 보편화되면서 "스펙을 주면 에이전트가 구현한다"는 흐름이 업계 기본값처럼 자리 잡았습니다. 그런데 이 방식을 오래 쓴 개발자들 사이에서 코드베이스를 더 이상 이해하지 못하게 되거나, 직접 코딩하는 감각이 떨어지거나, 생성된 텍스트를 읽느라 지치는 문제가 공유되고 있습니다. 이 글은 그런 피로감에 대한 한 실무자의 답입니다.

주요 내용

역할을 뒤집자: 사람이 코딩하고 에이전트가 보조한다

작성자의 주장은 단순합니다. 코딩 도구들이 유도하는 "계획은 같이, 구현은 에이전트가" 흐름을 거부하고, 계획까지는 함께 하되 구현은 직접 하라는 것입니다. 에이전트에게는 코드베이스를 조사해 이번 할 일(todo)에서 손대야 할 위치, 예상되는 함정, 관련 조사 결과를 정리해 달라고 시킵니다. 개발자는 잘 정리된 할 일 하나에만 집중해 코드를 씁니다.

이렇게 하면 코드베이스 상태를 항상 파악할 수 있고, 잘못된 계획을 초기에 발견하며, 코딩 실력도 유지된다는 것이 작성자의 설명입니다. 몇 주만 에이전트에게 코딩을 넘겨도 직접 코딩으로 돌아가기 어려워진다는 경고도 덧붙였습니다.

에이전트에게 맡길 일, 맡기지 말 일

LLM은 자연어로 다룰 수 있는 장부(bookkeeping) 도구로 쓰라고 권합니다. 긴 논의를 할 일 목록으로 바꾸거나, 테스트 결과를 수정 계획으로 정리하는 일이 여기에 해당합니다. 이때 할 일은 frontmatter가 붙은 markdown 파일처럼 눈에 보이는 산출물로 남기게 합니다. 컨텍스트가 넘치면 정보가 조용히 사라지기 때문입니다. 단, 중요한 결정은 에이전트가 사람에게 묻게 해야 합니다.

코딩 에이전트는 FIXME 정리, 반복 케이스 채우기, 유지보수가 끊긴 라이브러리 교체 같은 저위험 작업에 씁니다. 여기서 작성자는 흥미로운 함정을 짚습니다. 비슷한 케이스를 에이전트에게 복붙시키고 싶다면 그건 추상화가 필요하다는 신호일 수 있고, 에이전트 없이는 수정 위치를 다 찾기 어렵다면 코드 구조 자체를 의심해야 한다는 것입니다.

PR은 사람의 언어로

에이전트가 써 준 PR 본문을 그대로 보내지 말라는 조언도 있습니다. 작성자는 이를 이렇게 표현했습니다.

"이건 소통이 아니라 도구 출력이다." — turion (원문 작성자)

생성된 상세 설명은 벤치마크 수치처럼 <details> 안에 부록으로 붙이고, 본문은 직접 쓰라는 제안입니다.

댓글에서 나온 반론과 보완

작성자가 토큰 한도 변경을 "배신"이라고 표현하자, 한 사용자는 자신이 쓰는 OpenAI 요금제는 크레딧 비용이 공개되어 있고 Codex에서 /status로 확인할 수 있다고 반박했습니다. 작성자는 독립적인 토큰 측정 도구, 수개월간 보장되는 고정 토큰 요금제, 가동률 보장이 있어야 공정한 시장이라고 답했습니다. 또 다른 참여자는 함수·모듈 인터페이스만 직접 설계하고 구현은 작은 모델에 맡기는 방식을 공유했습니다.

팔복소프트 관점

• 국내 팀에 특히 와닿는 지점은 "코드 소유권"입니다. 인력 이동이 잦은 SI·에이전시 환경에서는 에이전트가 대량으로 만든 코드가 인수인계 비용으로 돌아옵니다. 사람이 직접 쓴 코드와 에이전트의 작업 기록(할 일, 조사 문서)이 함께 남는 구조는 유지보수 관점에서 확실히 유리합니다.
• 추상화 함정은 Haskell만의 이야기가 아닙니다. Java/Spring 프로젝트에서 비슷한 Controller나 DTO 변환 코드를 에이전트에게 반복 생성시키면 공통화할 기회를 놓치기 쉽습니다. 에이전트가 "빨리 채워 주는" 작업일수록 한 번 멈춰서 구조를 볼 필요가 있습니다.
• "작은 모델로도 돌아가는 워크플로"는 국내에서 더 현실적인 조언입니다. 망분리나 사내 보안 정책 때문에 외부 최상위 모델을 쓰기 어려운 조직이 많습니다. 사람이 코딩하고 모델은 정리·조사만 맡는 구조라면 사내에 올린 오픈 웨이트 모델로도 상당 부분 대체할 수 있습니다.
• 한계도 분명합니다. 두 배 생산성은 숙련된 개발자의 체감치이고 측정값이 아닙니다. 또 이 방식은 개발자가 "무엇을 어떻게 짤지" 이미 아는 상태를 전제합니다. 주니어에게는 오히려 에이전트의 조사 결과를 검증할 역량이 부족해 그대로 믿게 되는 위험이 있으므로, 사수의 리뷰가 함께 가야 합니다.
• 토큰을 장애로 보라는 관점은 팀 단위에서 바로 적용할 만합니다. 에이전트가 멈춰도 사람이 이어갈 할 일 목록이 파일로 남아 있는지를 팀 규칙으로 두면, 요금제 정책 변화나 서비스 장애에 훨씬 덜 흔들립니다.

정리

이 글의 핵심은 "LLM을 쓸 것인가"가 아니라 "어느 일을 누구에게 맡길 것인가"입니다. 구현은 사람이, 기록·조사·리뷰는 에이전트가 맡고, 에이전트의 모든 산출물은 파일로 남기며 사람에게 오기 전 자동 리뷰를 거치게 하는 것. 생산성 숫자는 에이전트 전면 위임보다 작을 수 있지만, 코드베이스를 이해하는 사람이 계속 남아 있다는 점에서 장기적으로 더 안전한 선택입니다.

• LLM
• 코딩에이전트
• 개발생산성
• 번아웃
• 코드리뷰