카타마리 아키텍처 — LLM이 만든 코드가 진흙덩이가 되는 이유

AI 요약

LLM 에이전트는 요청을 가장 짧은 경로로 해결하려는 경향이 있어, 기능을 기존 구조에 무작위로 붙이는 코드베이스를 만들기 쉽습니다. 글쓴이는 이를 게임 《Katamari Damacy》에서 잡다한 물건을 굴려 붙이는 ‘카타마리’에 빗댑니다. 겉보기에는 즉흥적으로 뭉친 덩어리지만 게임 속 구체는 알고리즘으로 세심하게 다듬어졌습니다. 반면 LLM은 새 기능을 어디에 어떻게 넣어야 하는지 판단하지 못한 채 코드에 덧붙인다는 설명입니다.

진흙덩이 아키텍처와 비교

Foote와 Yoder가 설명한 ‘진흙덩이(Big Ball of Mud)’ 아키텍처는 시간, 비용, 경험, 숙련도, 가시성, 복잡도, 규모 같은 여러 압력이 쌓여 나타납니다. 글쓴이는 이 요인 가운데 LLM 코드의 카타마리화를 설명하는 주된 원인으로 숙련도, 가시성, 변화 속도를 꼽습니다.

시간과 비용은 주된 원인이 아닙니다. LLM은 사람보다 빠르게 쉬지 않고 일할 수 있고, 많은 기업은 토큰 비용을 충분히 감당합니다. 경험도 결정적이지 않습니다. LLM은 방대한 소프트웨어와 문서를 학습했지만, 질문을 받지 않으면 평균적이고 무난한 설계만 내놓기 쉽습니다. 반면 숙련도는 문제입니다. LLM은 일부 작업에서 뛰어난 성능을 보이지만 다른 작업에서는 엉뚱한 실수를 합니다. 그 실수는 사람의 실수와 다르고, 검토자가 발견하기도 어렵습니다.

코드 가시성 저하와 변화의 누적

LLM은 한눈에 검토하기 어려울 만큼 많은 코드를 생성합니다. 글쓴이는 줄 수가 6,000줄 이상 늘고 400줄이 삭제된 풀 리퀘스트(PR)를 누구도 꼼꼼히 읽지 않을 것이라고 지적합니다. 생성 코드가 늘수록 코드베이스의 가시성은 낮아집니다. 개발자조차 코드를 읽지 않고 동작 여부와 배포 가능성만 따지는 태도가 자리 잡으면, 구조를 이해하고 문제를 찾아내기 어려워집니다.

자동 코딩은 변경 속도도 높입니다. 사람의 작업량은 변화 속도를 늦추는 제동 장치지만, LLM은 기능 추가를 요청만큼 쉽게 만듭니다. 다만 기존 아키텍처를 근본적으로 다시 설계하기보다는 그 위에 변경 사항을 쌓는 경향이 있습니다. 사람이 설계한 핵심 구조 위로 서로 어울리지 않는 코드가 겹겹이 붙으면서, 카타마리 같은 코드베이스가 만들어집니다. 복잡한 시스템을 처음부터 다시 쓰는 일은 어렵고 오래 걸리므로, 에이전트가 자발적으로 전면 재설계를 시도해도 성공하기 어렵다고 봅니다.

무엇을 할 것인가

글쓴이는 LLM을 코드 생성에 쓰는 방식보다 퍼징처럼 사람이 작성한 코드를 검사해 실제 버그를 찾는 비생성형 활용에 가능성을 둡니다. 유지보수자는 LLM이 만든 코드인지 알아볼 수 없는 경우에만 기여를 허용하는 규칙을 둘 수도 있습니다. 생성 코드를 사람이 직접 읽고 이해한 뒤 다시 작성하게 만들면, 기여자가 결과물을 더 깊이 검토하게 된다는 제안입니다.

글쓴이는 빠르고 일회용인 개발이 최선이라는 주장에도 동의하지 않습니다. 기능을 끝없이 추가하고 마감만 맞추는 방식은 진흙덩이와 카타마리 아키텍처를 낳습니다. 더 빠른 속도보다 세심한 관리가 필요하며, 더 적은 버그가 있는 작은 소프트웨어를 만들고 개발자는 더 적게 일하면서 더 많은 보수를 받아야 한다고 주장합니다.

Lobsters 반응

• @novedevo — 안녕하세요, 제가 쓴 글입니다! 조금 장황한 이 글을 올려주셔서 감사합니다.
  • @gennyble — 물론이죠! 글이 좋았고 여기 사람들이 즐길 것 같아 올렸습니다. Lobsters에 잘 어울리는 글 같아요.
• @gennyble — 이 글에 philosophy와 practice 태그를 둘 다 붙이는 게 좋을까요? 둘 다 관련 있어 보입니다. 저는 새로 글을 올리는 사람이라 잘 모르겠네요. 알려주세요!

원문: nove.dev / 번역·요약: Trawling