LLM 코딩 에이전트가 여전히 잘 못하는 두 가지

• LLM 코딩 에이전트는 복사-붙여넣기 같은 코드 이동 작업을 자연스럽게 수행하지 못함
• 코드 리팩터링 시 기억에 의존한 코드 작성 방식으로 인해 일관성을 보장하기 어려움
• 문제 해결 과정에서 질문을 거의 하지 않고 추측성 시도로 일관함
• 인간 개발자는 모호할 때 질문을 통해 문제를 명확히 하지만, LLM은 벽에 부딪힐 때까지 시도를 반복함
• 이러한 특성 때문에 LLM 에이전트를 인간 개발자 대체가 아닌, 자신감만 앞서는 인턴 수준으로 인식함

LLM 코딩 에이전트의 주요 한계

최근 LLM을 코딩 도움 도구로 활용하려고 시도하고 있지만, 여전히 인간 개발자가 느끼기에 어색한 점이 있음. 이 글에서는 LLM 코딩 에이전트가 특히 불편함을 주는 두 가지 이유를 명확히 설명함

1. 코드 이동 및 리팩터링 방식의 어색함

• LLM은 실제 '복사-붙여넣기' 동작을 수행하지 않음
  • 예를 들어, 대형 파일을 소규모 파일로 리팩터링 요청 시, LLM은 코드 블록 일부를 '기억'하여, 원본 파일에서는 delete 명령을 사용하는 동시에 새 파일에 '기억한' 코드를 write 명령으로 작성함
  • 'cut'이나 'paste' 도구를 활용하지 않고, 모든 수정이 메모리에서 복원됨
  • 인간 개발자는 코드 이동 시 '복사-붙여넣기'를 통해 코드 일치성에 대한 확신을 가지지만, LLM은 이를 보장하지 않음
  • 지금까지 Codex만이 sed나 awk 명령을 사용해 인간의 '복사-붙여넣기' 동작을 흉내 내려는 시도를 일부 보였으나, 완벽하지 않음

2. 질문 없는 문제 해결 접근

• LLM의 문제 해결 과정 또한 인간과 매우 다름
  • LLM은 거의 질문을 하지 않고, 수많은 가정을 바탕으로 문제를 해결하려 시도함
  • 인간 개발자는 대규모 변경 혹은 명확하지 않은 상황에서 늘 질문을 통해 상황을 확인, '나쁜 질문은 없다'는 명제 아래 행동함
  • 반면 LLM은 계속 시도만 반복하다가 문제가 생기면 더 강하게 반복하는 경향이 있음
  • 프롬프트를 과하게 설계해 질문을 유도할 수도 있지만, Roo 등 일부 툴을 제외하면 이런 행동은 잘 이루어지지 않음
  • 근본적으로는 LLM 개발 기업이 '더 빠른 코드 작성'에 초점을 맞춘 RL(강화 학습)을 적용했기 때문일 수 있음

결론

• 이러한 특성으로 인해, LLM은 아직 인간 개발자를 대체하기에는 부족
• 실제 업무에서는 '지나치게 자신감 있는 인턴' 정도의 능력을 보임
• LLM의 협업 경험이 완전히 자연스럽게 느껴지지 않는 이유임