AI는 더 나은 코드를 만드는 데 도움을 줘야 함

원문: AI should help us produce better code by Simon Willison

AI 코딩 에이전트가 코드 품질을 떨어뜨린다고? 그건 도구 탓이 아니라 프로세스의 문제임. Simon Willison이 에이전트를 활용해서 오히려 코드 품질을 끌어올리는 방법을 정리했음.

나쁜 코드를 만드는 건 선택의 문제임

많은 개발자들이 AI 도구에 코딩을 맡기면 품질이 떨어질 거라고 걱정함. 빠르게 찍어내는 대신 질이 나빠지고, 의사결정권자들은 속도에 눈이 멀어서 그걸 눈감아줄 거라는 우려임.

근데 Willison의 입장은 명확함. "에이전트로 나쁜 코드를 배포하는 건 선택임." 코딩 에이전트 도입 후에 코드 품질이 떨어졌다면, 도구를 탓할 게 아니라 프로세스의 어디가 문제인지 찾아서 고쳐야 함. 더 나은 코드를 배포하는 것도 마찬가지로 선택할 수 있는 일임.

기술 부채, 사실 단순한데 시간이 없었던 것들

기술 부채는 보통 트레이드오프의 결과임. "제대로 하면 시간이 너무 오래 걸리니까" 일단 넘어가는 거임. 근데 실제로 보면, 흔한 기술 부채 수정 작업들은 개념적으로는 단순한데 그냥 시간이 오래 걸리는 것들임:

• API 재설계: 초기 설계가 나중에 생긴 케이스를 커버 못 해서, 수십 군데를 고쳐야 하니까 그냥 비슷한 새 API를 하나 더 만들어버리는 경우
• 네이밍 변경: 초기에 잘못 지은 이름(예: groups 대신 teams)을 전체 코드에서 바꾸기 너무 힘들어서 UI에서만 바꾸는 경우
• 중복 기능 통합: 시간이 지나면서 비슷하지만 미묘하게 다른 기능들이 쌓여서 합치고 리팩토링해야 하는 경우
• 파일 분할: 수천 줄짜리 파일을 여러 모듈로 쪼개야 하는 경우

다 "해야 하는 건 아는데 당장 급한 일이 있어서" 못 하는 것들임.

코딩 에이전트가 이런 걸 대신 해줌

이런 리팩토링 작업이야말로 코딩 에이전트의 최적 활용처임. 에이전트 하나 띄워놓고, 뭘 바꿔야 하는지 알려준 다음, 별도 브랜치나 worktree에서 백그라운드로 돌려놓으면 됨.

Willison은 특히 비동기 코딩 에이전트를 추천함:

• Gemini Jules
• OpenAI Codex (웹)
• Claude Code (웹)

이런 도구들을 쓰면 로컬 랩탑에서 하던 작업 흐름을 끊지 않고 리팩토링 작업을 병렬로 돌릴 수 있음. 결과는 PR로 확인하고, 괜찮으면 머지하고, 아쉬우면 추가 프롬프트 주고, 완전 별로면 그냥 버리면 됨.

핵심은 이거임: 코드 개선 비용이 극도로 낮아졌기 때문에, 사소한 코드 스멜이나 불편함에 대해 무관용 원칙을 적용할 수 있게 됨. 예전에는 "이거 고치면 좋긴 한데 시간이..." 했던 것들을 이제 바로바로 처리할 수 있다는 얘기임.

탐색적 프로토타이핑에도 활용됨

기술 부채 중에서 가장 큰 건 계획 단계에서 잘못된 선택을 하는 것임. 더 쉬운 방법이 있었는데 모르고 넘어가거나, 나중에 안 맞는 기술을 선택하는 경우.

LLM은 우리가 미처 떠올리지 못한 뻔한 해결책을 제안해줄 수 있음. 학습 데이터에 많이 나오는 걸 추천하는 거니까 결국 검증된 "지루한 기술"이 되는데, 그게 오히려 실전에서 제일 잘 작동하는 기술임.

더 중요한 건 탐색적 프로토타이핑임. 예를 들어:

"수천 명이 동시 접속하는 사이트의 활동 피드에 Redis가 괜찮을까?"

가장 확실한 방법은 시뮬레이션을 만들어서 부하 테스트를 돌려보는 건데, 코딩 에이전트한테 잘 짠 프롬프트 하나 던지면 이런 시뮬레이션을 바로 만들어줌. 비용이 거의 제로에 가까우니까 여러 실험을 동시에 돌려서 최적의 솔루션을 고를 수도 있음.

Compound Engineering: 반복할수록 나아지는 루프

에이전트는 지시를 따르는 도구임. 그 지시를 시간이 지나면서 발전시키면 점점 더 나은 결과가 나옴.

Dan Shipper와 Kieran Klaassen이 Every에서 실천하는 "Compound Engineering" 개념이 정확히 이거임. 모든 코딩 프로젝트가 끝나면 회고(retrospective)를 하는데, 이걸 "compound step"이라고 부름. 잘 작동한 것들을 문서화해서 다음 에이전트 실행에 반영하는 것임.

결국 핵심 메시지는 이거임: 작은 개선이 복리처럼 쌓임. 예전에는 시간이 너무 걸려서 못 했던 품질 개선 작업들의 비용이 이제 거의 제로로 떨어졌으니, 새 기능을 배포하면서 동시에 품질에도 투자하지 않을 이유가 없음. 코딩 에이전트 덕분에 드디어 둘 다 가질 수 있게 된 거임.