How to keep enjoying programming in a world of LLMs
LLM 시대에도 프로그래밍을 즐기는 법
Haskell 개발자인 글쓴이는 LLM에게 코딩을 맡기는 대신 조사·계획·기록·검토를 맡기고, 직접 코드를 쓰는 작업 흐름을 제안합니다. 생산성을 조금 얻으면서 코드 이해와 프로그래밍 기술, 작업의 즐거움을 지키는 방법을 설명합니다.
- 주제
AI 요약
LLM 도입으로 개발자의 역할이 코드를 만드는 사람에서 명세를 입력하는 사람으로 줄어들 수 있다는 우려에서 출발합니다. 글쓴이는 Haskell로 코드를 쓰는 과정 자체를 즐깁니다. 코드를 통째로 생성하면 그 즐거움뿐 아니라 코드베이스를 이해하고 관리하는 능력도 약해진다고 봅니다. 그렇다고 LLM 사용을 거부하기보다, 직접 코딩하는 시간을 지키면서 생산성을 얻는 방식을 찾자고 제안합니다.
코딩은 사람이, 주변 업무는 에이전트가
LLM에는 도메인 전문가의 대화를 할 일 목록으로 정리하거나, 테스트 결과를 기록하고 결함 수정 계획을 세우는 일처럼 지루하고 확인하기 쉬운 작업을 맡깁니다. 할 일은 관리 도구나 frontmatter가 포함된 Markdown 파일에 기록합니다. 문맥이 커지면 정보가 조용히 누락될 수 있으므로, 중요한 결정은 에이전트에게 넘기지 말고 사람에게 확인하도록 해야 합니다.
조사 업무도 에이전트의 답을 그대로 사실로 받아들이지 않습니다. 글쓴이는 에이전트가 참고한 자료와 조사 결과를 기록하게 하고, 자신도 검색 엔진으로 병행 조사해 해당 영역을 이해하라고 권합니다. 에이전트가 이상한 제안을 내놓으면 근거 자료를 물어봅니다. 그 과정에서 에이전트가 실수를 찾아내기도 하고, 사람이 검토해 직접 판단할 근거를 얻기도 합니다.
계획을 함께 세우고 직접 구현합니다
일반적인 코딩 에이전트 방식은 계획을 만든 뒤 구현까지 맡기는 흐름을 권하지만, 글쓴이는 계획을 함께 세운 다음 사람이 코드를 작성하자고 합니다. 에이전트는 코드베이스를 조사해 수정할 위치와 할 일, 잠재적 문제, 관련 배경 자료를 정리합니다. 개발자는 잘 정리된 할 일에 집중해 직접 구현합니다. 글쓴이는 이 방식으로 작업 상태를 파악하고 나쁜 계획을 일찍 발견하며, 기술을 계속 연습할 수 있다고 말합니다. 자신의 작업 속도는 정확히 재기 어렵지만, LLM을 쓰지 않을 때보다 대략 두 배 빨라진 듯하다고 덧붙입니다.
이 방식은 정리 작업, 작은 변경, 반복 작업, 위험이 낮은 리팩터링에 잘 맞습니다. FIXME 처리나 유사한 사례 추가, 모듈 재구성의 벤치마크, 유지보수가 중단된 라이브러리 교체가 예입니다. 복잡한 설계를 처음부터 맡기는 용도로는 적절하지 않다고 봅니다. 반복되는 코드를 에이전트에게 복사해 늘리게 하기보다 추상화할 기회인지 살펴야 합니다. 수정 지점을 에이전트가 모두 찾게 만드는 일이 잦다면, 코드 구조가 결합을 지나치게 키우지는 않았는지도 점검해야 합니다.
결과물에는 자동 검토를 붙입니다
글쓴이는 생성된 코드뿐 아니라 계획에도 자동 검토 과정을 두라고 권합니다. 계획에서 앞선 작업을 나중 작업이 전제로 삼는 모순을 찾거나, 구현 과정에서 빠진 항목을 검토 에이전트가 확인하도록 합니다. 에이전트가 결과물을 넘긴 시점이 아니라, 검토 에이전트가 더는 문제를 찾지 못하는 시점을 사람에게 보여줄 상태로 봅니다. 직접 쓴 코드도 검토받으면 사소한 지적뿐 아니라 실제 버그나 누락을 발견하는 경우가 있다고 합니다.
다만 첨단 모델에 지나치게 의존하면 에너지 사용과 토큰 비용이 늘고, 사용 한도도 예측하기 어렵습니다. 글쓴이는 토큰이 바닥난 상황을 구매량 부족이 아니라 서비스 중단에 대비하듯 다뤄야 한다고 말합니다. 에이전트가 없는 동안에도 작업을 이어가도록 계획과 할 일 목록을 남겨둡니다. 더 작은 모델이나 오픈 웨이트 모델로 바꿀 여지도 고려합니다. 결과물에 책임을 지려면 개발자가 작업 과정에 계속 참여해야 한다는 설명입니다.
코드 밖의 협업과 개발자의 상태도 챙깁니다
LLM이 만든 글을 지나치게 많이 읽으면 정신적으로 소모될 수 있으니, 사람이 쓴 글과 동료와의 대화를 유지하라고 권합니다. 풀 리퀘스트(PR)도 사람 사이의 소통으로 봅니다. 완전히 생성된 PR 본문을 그대로 보내기보다 직접 쓴 설명에 에이전트가 만든 세부 정보를 덧붙여, 읽을 사람이 필요한 만큼 확인하게 하라고 합니다. 글쓴이는 이런 작업 흐름으로 프로그래밍의 즐거움을 지키고 있으며, 앞으로도 코드를 직접 쓰는 일을 계속하고 싶다고 말합니다.
원문: Haskell Discourse / 번역·요약: Trawling