LLM이 코드를 완벽하게 짜도, 에이전트는 자신이 만든 슬롭을 해결하지 못한다

에이전트에게 코드 품질에 대한 피드백을 주기 위한 정량적 접근을 연구하는 사람들이 있다니 정말 반갑네요. 이 글은 좋은 출발점처럼 보입니다!

저자가 받을 주요 피드백은, 조잡함(sloppiness)의 가장 중요한 문제는 국소적 속성이 아니라 전역적 속성이라는 점입니다. 제 경험상 에이전트는 인간처럼 주의력에 한계가 있지만, 방해가 되는 국소적 조잡함을 만나면 필요할 때 고칠 수 있습니다. 정말 중요한 기술 부채 문제는 보통 고치기 쉽지 않은 전역적 문제입니다. 전역적 분석과 전역적 리팩터링이 필요하죠.

답은 모르겠지만, 관심사 분리, 명확한 아키텍처 계층화, 잘 정의된 인터페이스 같은 아키텍처 속성을 측정할 방법이 필요할 것 같습니다.

프런티어 모델에 무제한 토큰을 쓴다면 코딩은 해결된 문제일지도 모릅니다. 그것이 영원히 엄청나게 비쌀지는 아직 지켜봐야 합니다. 제 회사에서는 상황이 좋을 때 토큰을 최대로 썼습니다. 그런데 Anthropic의 엔터프라이즈 플랜으로 전환해 토큰당 비용을 내기 시작하자 정말 난리가 났죠. 이제 우리는 합리적인 비용 수준으로 후퇴하고 있는데, 아니나 다를까, 사람의 힘이 비용 효율적일 수도 있다는 걸 알게 됐습니다. 물론 AI는 활용할 수 있는 엄청난 도구이지만, 루프를 만들어 돌리는 데는 여전히 너무 비쌉니다. 시간이 지나면 바뀌겠지만, 해결된 문제라고 가정하는 건 말도 안 됩니다. 아마 핵융합을 해결한다면 가능하겠죠. 그때까지는 진화가 엔트로피와의 전쟁에서 이기고 있습니다.

저자와 같은 결론에 도달한 덕분에 저는 아키텍처 리뷰를 하는 첫 에이전트를 만들게 되었고, 그렇게 몇 년간 따라온 모범 사례 뒤에 있는 지표들(LCOM, 순환 복잡도 같은 것들)을 알게 되었습니다...

코드를 많이 배포하는 건 너무 쉽습니다. 코드가 올바른지 보장하는 데 더 많은 노력을 기울여야 하고, 개발자가 참여하는 자기 개선 피드백 루프와 전용 도구가 필요합니다...

하지만 다시 말해, 얼마 전까지만 해도 모든 게 프롬프트 엔지니어링이었는데 이제는 아이디어를 모호하게 표현해도 어느 정도 작동하는 결과를 얻을 수 있으니, 이것도 빠르게 진화할 가능성이 큽니다...

LLM이 코드베이스에서 처리할 수 있는 복잡성에 한계가 있는지 실제로 아는 사람이 있나요? LLM이 사람이 이해하기에 적합한 코드를 작성하지 않는다는 건 아주 명백하고(이 모델들을 훈련하는 데 RL이 더 많이 쓰일수록 점점 더 심해질 겁니다), 만약 LLM이 도입한 복잡성 때문에 LLM도 어려움을 겪는 지점이 없다면, 안전이 중요한 소프트웨어가 아닌 많은 소프트웨어에서는 더 이상 별로 중요하지 않을지도 모르겠습니다. 저는 그런 지점이 있기를 정말 바랍니다. 왜냐하면 그것을 조종하는 것이 제가 여전히 가치를 더할 수 있는 마지막 역량 중 하나라고 느끼기 때문입니다. 그런데 이 모델들이 형편없이 유지된 코드에서 더 어려움을 겪는다는 증거가 실제로 있나요?

여기서 굿하트의 법칙이 아무 논의도 없이 소환되었네요. 필요한 모든 테스트를 통과하는 최소 LOC를 최적화하면 조잡한 코드가 나온다고 확신할 수 있나요? 그리고 조잡한 코드란 대체 무엇인가요? 정의할 수 있다면, 그 정의를 컨텍스트에 넣고 LLM에게 피하라고 말할 수 있지 않을까요?

코딩은 단지 메모리에서 실행되는 프로그램만이 아니라, 팀 사이에 이해의 정신 모델을 분배하는 과정이기도 합니다.

인간이 점점 더 코딩에서 배제된다면, 누가 정신 모델을 보유하나요?

AI가 정신 모델을 보유한다면, 정의상 인간의 프롬프트는 손실이 있는 채널을 거치게 됩니다. 이는 AI가 없어도 마찬가지입니다. 소프트웨어 품질은 비즈니스/PM 언어를 기술적 결정으로 번역하는 훌륭한 개발자에게 직접적으로 달려 있습니다.

그렇다면 코딩은 이제 해결된 건가요? 그것은 이미 수십 년 전에 해결되었습니다.

좋은 척도는 소통입니다. 공통된 이해가 있다면, 그 기원은 반드시 중요한 게 아닙니다.