본문으로 건너뛰기
피드

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

ai-ml 약 6분

AI 코딩 에이전트가 코드 품질을 떨어뜨린다는 건 도구 탓이 아니라 프로세스 문제임. 리팩토링, 네이밍 변경, 파일 분할 같은 단순하지만 시간 걸리는 기술 부채 해소 작업을 비동기 에이전트에 맡기면 비용이 거의 제로로 떨어짐. 탐색적 프로토타이핑과 Compound Engineering 루프를 통해 품질과 속도를 동시에 잡을 수 있음.

  • 1

    나쁜 코드 배포는 에이전트 탓이 아니라 선택의 문제임

  • 2

    리팩토링·네이밍 변경·파일 분할 등 단순하지만 시간 걸리는 기술 부채 작업이 에이전트의 최적 활용처임

  • 3

    Gemini Jules, OpenAI Codex 웹, Claude Code 웹 같은 비동기 에이전트로 작업 흐름 끊지 않고 병렬 처리 가능

  • 4

    코드 개선 비용이 극도로 낮아져서 코드 스멜에 대한 무관용 원칙 적용 가능

  • 5

    Every의 Compound Engineering 개념: 프로젝트마다 회고해서 에이전트 지시를 계속 발전시키는 복리 효과

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"이라고 부름. 잘 작동한 것들을 문서화해서 다음 에이전트 실행에 반영하는 것임.

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

코딩 에이전트의 가치는 코드를 빠르게 찍어내는 게 아니라, 그동안 '시간이 없어서' 미뤄둔 품질 개선 작업의 비용을 거의 제로로 만들어서 기능 개발과 품질 향상을 동시에 가능하게 하는 데 있음.

댓글

댓글

댓글을 불러오는 중...

ai-ml

제미나이 도구 호출 능력을 2,600만 파라미터 모델로 증류한 니들 공개

Cactus Compute가 Gemini 3.1의 도구 호출 능력을 2,600만 파라미터짜리 초소형 모델 Needle로 증류해 공개했다. 맥이나 PC에서 로컬 파인튜닝까지 가능하고, 프로덕션 환경에서는 프리필 6,000 토큰/초, 디코드 1,200 토큰/초를 낸다고 주장한다. 개인용 AI 기기에서 함수 호출만 빠르게 처리하는 작은 모델 실험으로 보면 꽤 흥미로운 공개다.

ai-ml

딥시크 V4 인덱서, 6기가바이트 메모리로 백만 토큰까지 밀어붙인 논문

딥시크 V3.2와 V4의 압축 희소 어텐션에서 병목이 되는 인덱서 단계를 스트리밍 방식으로 바꿔, 기존 구현이 6만5536 토큰에서 메모리 부족으로 죽던 문제를 104만8576 토큰까지 확장했다. 핵심은 전체 점수 텐서를 만들지 않고 청크 단위로 top-k를 나눠 계산한 뒤 병합하는 방식이며, 단일 엔비디아 H200에서 피크 메모리 6.21기가바이트를 기록했다. 다만 논문은 인덱서 단계만 다루며, 실제 체크포인트 기반 종단간 성능이나 더 빠른 어텐션 커널을 주장하진 않는다.

ai-ml

챗지피티가 학습에 좋다던 유명 논문, 결국 철회됨

챗지피티가 학생 학습 성과에 큰 도움이 된다고 주장했던 논문이 출판 약 1년 만에 철회됐어. 스프링거 네이처는 분석의 불일치와 결론 신뢰 부족을 이유로 들었고, 문제의 논문은 이미 500회 넘게 인용된 뒤였어.

ai-ml

샘 올트먼, 법정에서 “머스크가 오픈AI 지배권을 자녀에게 넘기려 했다”고 증언

샘 올트먼이 캘리포니아 오클랜드 연방법원 배심원 앞에서 일론 머스크가 오픈AI의 장기 지배권을 원했고, 사망 후엔 자녀에게 넘기는 방안까지 언급했다고 증언했다. 머스크는 오픈AI가 비영리로 출발했는데도 영리화됐다고 소송을 제기했지만, 올트먼은 오히려 머스크가 영리 전환과 테슬라 편입을 밀었다는 취지로 반박했다.

ai-ml

혜전대, AI로 스마트팜 생산·가공·유통 교육 모델 만든다

혜전대가 2026년 교육부·한국연구재단의 AID 전환 중점 전문대학 지원사업에 충남 지역 연합형 사업단으로 선정됐다. 연암대와 역할을 나눠 스마트팜 생산부터 가공·유통까지 전주기를 디지털화하는 교육 모델을 만들겠다는 내용이다.