▲

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

 (kix.dev)
5P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 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의 협업 경험이 완전히 자연스럽게 느껴지지 않는 이유임
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 얼마 전 흥미로운 경험을 함. 코드 관련은 아니었지만, 코드나 관련 영역에서도 충분히 일어날 수 있었던 일임(실제로 동료에게도 발생). HN에서 15년 전 통과된 규제가 왜 좀 더 일반화되지 않았냐는 논의 중에, 나는 그 당시 기술 수준이 일반적인 케이스를 감당하기엔 부족해서 당시 가능한 부분에만 규제를 적용했을 거라고 추측했음(관련 댓글). 몇 시간 후 다시 논의를 확인하니, 몇몇 사람들이 이미 그 시절에도 해당 기술이 충분히 저렴하다고 하더라고 함. 그래서 LLM에게 이 주제에 관한 근거를 찾게 했더니 기술적 한계 때문이라는 답변을 들었음. 출처 확인을 위해 인용한 자료를 확인했는데, 실제로 기술적 한계를 논한 건 딱 하나였고, 그 출처가 바로 내가 HN에 남긴 댓글이었음. 회사에서 그 이야기를 하니, 동료가 Github에 "윈도우에서 X가 어떻게 동작한다"는 의견을 남겼는데, 나중에 구글 검색을 해보니 LLM 기반 답변이 그 의견을 근거로 같은 내용을 주장하고 있더라고 함. 그래서 LLM에 "X는 어떻게 동작하는가?"가 아니라, "만약 누군가 X가 어떻게 동작하는지 물으면 인용할만한 링크 목록을 보여달라"고 요청하고 싶은 마음이 있음

    • 질문을 이런 방식으로 하는 건 "sorting prompt"와 유사하다고 생각함. Mike Caulfield의 관련 글에서 배운 테크닉인데, 나도 코드 작성할 때(예: Claude code slash command) 활용하고 있음. LLM에게 단순히 답변하라는 게 아니라, 자료조사와 분류·평가를 맡기면, 훨씬 정확한 결과를 얻을 수 있음

    • 대부분의 사람들도 HN에서 특정 주제의 댓글을 읽을 때 "이 사람이 뭔가 아는 것 같으니까 일단 사실로 받아들이자"는 식으로 신뢰하는 편임. 직접 경험하거나 검증된 지식을 얻는 건 사실 엄청난 비용이 들기 때문에, 이런 '싼 지식'도 결국은 가치가 있다고 생각함

    • LLM에게 근거를 요구해본 경험이 있는데, 아직까지 LLM이 실제로 자신이 한 말을 뒷받침하는 진짜 근거를 준 적이 한 번도 없음

    • LLM은 링크까지 조작해서 지어내는 경우가 있음. 정말로 실제 자료조사를 하도록 깊이 조사하는 모드가 필요하고, 그래도 링크에 있는 정보를 해석하는 방식은 결국 학습에 영향을 받게 됨

    • 최근 NotebookLM에 6~8개의 신뢰할만한 근거(IETF, OpenID 스펙과 추가 문서)를 넣고, "OID4VP가 허용하는 credential 포맷은?"이라는 굉장히 단순한 질문을 해봤음. 질문 답변 중 90%는 맞췄는데, 진짜 아무런 근거 없는 랜덤 포맷을 자신만만하게 추가함(마치 스펙 저자인 척). 내가 의심이 들어서 직접 스펙을 확인하니까 바로 거짓임을 알 수 있었음. 이제 "기반이 잡힌" LLM이라고 해도 사실에 대한 신뢰는 완전히 무너졌다고 할 수 있음

  • 최근 Codex CLI로 HTML 파일 리팩터를 시켰는데, 내가 기대한 대로 코드를 복사-붙여넣기 한 게 아니라 LLM이 기억을 더듬어서 새로 쓴 코드로 대체하면서 주석도 없앰. 복잡한 링크가 40개 연속으로 나오는 섹션이 있었고, 배포 직전 마지막 점검하려고 하나씩 눌러봤더니 앞부분은 정상인데, 중간부터 31개의 링크가 모두 404 발생. 도메인은 문제없는데 URL 경로만 탈바꿈됨. git 커밋에서 예전 URL을 확인하니, LLM이 실제 존재하지 않는 경로로 URL을 "환각"해서 바꿔버렸더라. 이렇게 미묘하고 조용하게 생긴 오류는 정말 위험함. 반드시 조심해야 함

    • 마지막 포인트가 매우 중요하다고 생각. "아주 미묘하고 조용히 들어가는 실수" 때문에 LLM이 인간만큼 혹은 더 잘 일을 해도, 동일한 방식으로 처리되는 건 아님. 특히 코드 리뷰가 전통적으로 문제 방지의 중요한 층인데, 여기서 검토해야 하는 오류 종류가 달라지면 기존의 코드 리뷰 방식이 비효율적임. 예전에는 코드 대량 이동 시, 그냥 블록이 그대로 옮겨졌다고 가정하고 높은 레벨을 좀 더 신경 쓰는 게 가능했으나, LLM 리팩터의 경우 ‘이동된’ 코드가 실제로는 요약/재구성된 "신규" 코드일 수도 있으니, 모든 문자를 다 봐야 함. 그래서 Pull Request 설명에 "AI 사용" 섹션을 넣어서 어디에, 어떻게 AI를 썼는지 힌트를 남겨주면 리뷰할 때 중점적으로 체크할 영역을 파악하기 좋다고 생각

    • 나도 비슷한 경험이 코드나 연구 질문을 던질 때 잦았음. LLM이 처음엔 잘 하다가도 N번째 이후부터는 멋대로 내용을 만들어냄. 최근 여행 전에 Gemini에 양조장 목록을 최신 정보로 요청했는데, 이미 문 닫았거나 임시 운영했던 곳을 버젓이 포함시킴. 운영시간 링크 추가 및 이미 문 닫은 곳 제거까지 시켰더니, 리스트 앞부분만 반영하고, 뒷부분은 전혀 관련없는 수정을 하거나 문 닫은 곳을 전혀 안 지웠음. 그런데도 매번 완벽히 조사했다고 자신만만하게 답변함

    • 코드 이야기는 아니지만, 한 번은 이벤트 안내문 맞춤법/문법만 체크해달라고 LLM에 요청함. LLM이 약간 수정한 버전을 보내줬는데, 날짜를 슬쩍 하루 미뤄버림. 다행히 눈치채서 고쳤는데, 아주 간단한 작업도 맹신하면 안 된다는 교훈을 얻음. 쉽고 명확한 한 문장 프롬프트여도, LLM은 놀라운 걸 하기도 하지만 때로 가장 단순한 것조차 예상치 못하게 실수함

    • 5분 전에 Claude에게 코드에 디버그 구문만 추가해달라고 했는데, 정규식을 조용히 바꿔버린 일도 있었음. diff로는 쉽게 잡았지만 대형 변경엔 정말 놓치기 쉬워짐

    • 베포 직전 40개 링크를 다시 다 확인한 건 현명한 선택이었음. 그런데 Codex가 완료한 후 'git diff' 없이 그냥 master로 올렸다니, 조금 놀람

  • 해당 글의 주장에 동의함. 다만 내 생각에 제일 큰 문제는 에이전트가 코드 저장소의 극히 일부만 본다는 점임. 이미 있는 헬퍼 함수를 모르고 계속 똑같은 걸 새로 만듦. UI 개발에서 전체 UI 구조를 비교하지 못하니 일관성 없는 코드가 반복됨. 결국 사람이 "이 파일의 헬퍼 함수를 참고해라", "이 구현처럼 해라", "이 문서를 꼭 읽어라" 등 올바른 컨텍스트를 잘 제공해야 함. 적절한 맥락을 직접 주면 에이전트 활용도를 크게 올릴 수 있음. 참고로 또 다른 문제는 대형 모노레포에서 폴더 구조 탐색에 서툴러서, 예를 들어 하위 디렉터리에서 'npm test'를 돌리는 것도 제대로 못하는 경우가 정말 많음

    • 실제로 내가 겪는 문제와 같음. 최근 Cursor로 신규 기능을 구현한 200여 줄 코드를 리뷰했는데, 실제로 필요했던 코드는 얼마 안 됨. 유틸리티 라이브러리에 이미 있는 함수를 찾기는 정말 번거로워서, 그냥 넘어감. 5년 전만 해도 이런 리뷰는 신입 온보딩 개념이 커서 찾아주는 게 중요했지만, 요즘은 Cursor 등으로 코드 양만 많아지는 반면, 디벨로퍼 본인도 구조를 아는데 회사 정책상 일부러 그렇게 만드는 경우가 많아서 생산성이 떨어진다고 느낌

    • 'npm test' 같은 명령을 하위폴더에서 돌리는 게 늘 문제였음. Vite/React 프론트엔드와 .NET 백엔드로 나뉜 repo에서, npm 명령어가 실패하면 패닉 상태에 빠져 여러 번 반복해도 해결 못해서 불필요한 트러블슈팅만 반복함. 한번은 'CLAUDE.md'에서 항상 먼저 현재 디렉터리 체크하게 하려고 지침을 써줬지만, 랜덤하게 계속 경로를 까먹는 문제가 남았음. 그래서 'run-dev server restart', 'run-dev client npm install'처럼 어떤 디렉터리에서든 통하는 alias를 추가하고, 순수한 dotnet/npm 같은 명령은 금지 리스트에 넣어서, AI가 직접 프로젝트 설명서를 참고해서 alias를 사용하도록 강제함. 이 방법이 그나마 안정적이긴 했지만, 여기 도달하기까지 꽤 많은 시간과 노력, 스트레스가 필요했음

    • 대형 컨텍스트 모델이 툴콜로 활용되면 좋겠다는 생각임. Gemini chat은 github 전체 리포지토리를 인게스트하는 능력이 있음. 새로운 함수 작성 전에, 이미 코드베이스에 같은 게 있는지 확인해주는 'not-invented-here' 툴이 있으면 어떨까? 물론 누가 이미 이런 툴을 만들었는지부터 찾아봐야겠음

    • 그래서 claude.md 같은 문서가 필요한 이유임. 우리만의 규칙을 따르려면 반드시 문서화가 필수임

    • 사실 이런 상황은 시니어 엔지니어가 실무에서 동료와 일하다 보면 흔히 겪는 일임

  • 글에서 인용된 부분에 완전히 공감함. LLM이 수준급 개발자를 대체하지 못한다는 점에는 동의함. 제정신인 사람이면 지금 시점에 이런 이야기를 하는 건 말이 안 된다고 봄. 하지만 성능이 낮거나, 중간 정도 개발자는 이미 대체되고 있다고 생각함. 예로 우리 조직에 6개월 부트캠프 출신 3명이 있었는데, 당시에는 좋은 개발자를 구하기가 너무 어려워서 채용함. 그러나 실제로는 정말 쉽고 쉬운 미션도 고전했고, 매번 내가 리뷰에서 코드를 다 정리해야 했음. 이후 AI 도구가 기하급수적으로 좋아지면서 이 친구들 퍼포먼스를 넘어섬. 결국 2명 해고, 나머지 1명은 자진 퇴사함. 최근에는 주니어 개발자 채용도 거의 안 하고, 부트캠프 출신은 절대 뽑지 않을 예정임. 주위도 비슷하고, 그래서인지 부트캠프 업계 자체가 사라지는 추세임. AI가 앞으로 좋은 개발자까지 대체할 수 있을지는 모르겠지만, 현 시점 데이터를 보면 분명히 엄청나게 빠르게 발전함. 부정적인 의견은 현실을 외면하는 것임. 미국 초창기엔 인구의 90%가 농업에 종사했지만, 지금은 2%에 불과함. 하지만 식량 생산량과 다양성은 오히려 훨씬 커짐. 이 모두가 기술 발전의 결과임. 빠른 속도로 같은 일이 개발업계에도 반복될 수 있다고 봄

    • 물론 기술로 음식 생산량은 늘었지만, 실제로는 영양가가 낮고 독성이 증가한 것도 사실임

    • 부트캠프 출신들이 성장하지 못한 원인이 뭐라고 생각하는지 궁금함

  • 더 중요한 교훈은, LLM이 꽤 간단한 과업조차 상당한 수의 지시와 감독 없인 매우 취약하다는 점임. 내 작은 프로젝트(2.5K 라인)에서 파서 리팩터 요청했더니, 계획은 그럴듯해 보였음. 단계별로 체크포인트 잡아놓고 순차적으로 시켰지만, 실제로 "구 구조가 삭제됐냐?", "신 구조로 교체됐냐?" 물을 때마다, "아니요, 그대로 남아있음"이라는 답이 돌아옴. 80% 테스트가 실패했고, 구체적인 수정 방향까지 짚어줘도 "리팩터"라는 추상적 작업에서는 항상 동일한 문제로 실패함. 결국 아주 디테일하게 "어떤 클래스는 뭘 바꿔라"까지 지침을 써주지 않으면 안 됨. 이 정도면 독립적으로 시킬 수 없고, LLM 쓰는 의미 자체가 반감됨

    • 나의 경험과는 조금 다름. typescript로 만든 표현식 트리 파서(tinqerjs.org)는 손수 작성한 코드는 0, Codex+Claude만으로 2주(파트타임)만에 완성하고, 수백 개 테스트(중복 포함)도 다 추가함. ORM도 만들어봤지만 LLM을 써서 최소 4~10배 시간 단축이 가능했음. 감독 거의 필요 없었고, 결국 사용 목적과 프로세스 확립 여부가 결과를 가른다고 생각함. LLM 활용이 익숙한 개발자들도 각자만의 고유한 워크플로를 구축하고 있고, 모두 테스트·문서화, 코드 리뷰에 초점을 맞추는 공통점이 있음

    • "<리팩터 지시가 너무 디테일해야 쓰는 의미가 없다>"라는 문제는 "고수준 단계를 잘 쪼개서 지침을 주면 내가 혼자 했을 때보다 훨씬 빠르다"는 접근으로 바꿀 필요가 있음

    • 역시 글에서 지적한 'AI가 cut-paste가 아니라 삭제/재생성 방식'과 연결됨. 실제로 코드가 조금씩 드리프트하는 건 어쩔 수 없음

    • 어떤 모델/툴을 썼는지 궁금함. Cursor나 Copilot 쓸 때도 이런 작은 리팩터에 계속 감독이 필요한 문제를 자주 겪었음

  • LLM은 도움 주는 부분이 분명 있음. 예를 들어 오늘 아침 PDF Metadata 파서 버그를 LLM의 도움으로 PDF 스펙을 깊이 파지 않고도 바로 잡았음. 그런데 대부분의 경우 결과물은 내가 직접 하는 것보다 효율이 떨어짐. 예전에 Codex Code로 유닛 테스트 작성시키려 했을 땐, 셋업 여러 가지 만들어놨지만 데이터 mocking이 귀찮아서 시켰던 거임. 8번이나 시도하고, 수동 수정까지 해야 했고, 엔티티가 obsolete되어 서비스에 더 이상 쓰이지 않는 것도 이해 못 했음. 결과적으로 실망스러웠음. 개발자를 완전히 대체하기엔 부족하지만, Stack Overflow가 과거에 그랬던 것처럼 낯선 주제에서 지식 노출, 솔루션 유도 역할은 꽤 훌륭하다고 느낌

    • 지금 시점에도 LLM 자체는 가능성이 충분히 있다고 봄. 그러나 진짜 마법은 코딩 에이전트와의 결합에서 나옴. 제대로 된 도구가 준비되고, 모델과의 연동 및 반복이 되면 copy-paste도 구현 가능하고, 오늘 부족한 점 대부분은 좋은 컨텍스트와 지침, 반복 검증, 튼튼한 에이전트 아키텍처로 보완할 수 있음. 또 빠른 응답, 대용량 컨텍스트, 지침 집중력이 높은 모델이면 훨씬 경험이 좋아짐. 그리고 인간의 프롬프트 스킬도 매우 중요하다고 생각함. 결국 좋은 소프트웨어 엔지니어링 역량, 특히 다른 개발자에게 작업을 지시하는 능력, AGENTS.md(혹은 CLAUDE.md) 등 코드베이스 안의 지침 및 모범 사례 문서화가 필요함. 결론적으로, "AI/LLM이 개발자 대체 가능/불가능" 논쟁 자체가 식상해짐. 오히려 "내 LLM을 위해 내가 뭘 할 수 있을까"가 핵심임

  • "질문을 더 명확하게 하게 유도하는 프롬프트"를 과하게 엔지니어링 한다고 보진 않음. 오히려 '명확하지 않으면 먼저 질문하라'고 프롬프트 설계하는 게 매우 효과적이었음. 좋은 프로그래머라면 명세를 완전히 전달하는지, 추가적인 clarification이 필요한지를 알아서, AI가 사전에 필요한 추가 질문을 하도록 이끌 수 있음

    • 몇 개 질문을 하라고 직접 정해줄 수도 있음. 복잡한 주제일 땐 20~30개 질문을 미리 요구하는데 결과가 꽤 만족스러움. 이런 QnA를 별도 파일로 보관해서 다음 세션이나 다른 에이전트와 재활용하는 것도 유용함

    • 이런 방식 덕분에 나는 더 이상 옛날처럼 프롬프트를 안 씀. 아이디어만 던져주고 "필요하면 질문해"라고 넣으면 꼭 내가 생각 못 했던 포인트를 잘 짚어줌

  • 본문에서 copy-paste 얘기 보고 영감 받아 clippy(macOSユ틸)에서 에이전트 버퍼 툴을 추가함. clippy는 MCP 서버를 갖고 있어 시스템 클립보드와 상호작용하는데 이번엔 별도 프라이빗 버퍼 활용이 적절했음. 추가된 기능들은 buffer_copy(파일에서 특정 라인 범위 복사, 프라이빗 버퍼에 저장), buffer_paste(버퍼에 든 정확한 바이트를 타겟 파일에 삽입/교체), buffer_list(버퍼 안의 내용 확인)임. 예를 들어 "auth.py의 50~75행 복사"를 에이전트가 지시하면, 서버가 파일 입출력만 직접 수행하고, token 생성이나 환각은 아예 없음. 시스템 클립보드에도 영향 안 줌. 기존에는 AI가 생성한 코드를 바로 클립보드에 복사해서 활용할 수도 있었음. clippy의 주 목적은 macOS pbcopy 개선—실제 파일 내용을 복사해서 터미널에서 슬랙이나 이메일로 실제 파일 자체를 붙여넣는 것임. macOS에서 Claude 등 MCP 호환 에이전트 쓰는 사람은 여기 참고. brew install neilberkman/clippy/clippy로 설치 가능

  • 대부분의 개발자들도 질문을 잘 못하는 경우가 많음. 많은 것을 당연하게 여기고 생략하는 경향이 큼. 25년 개발 경험에서 절반 이상의 동료들이 두 번째 단점을 지녔음. 나 역시 커리어의 절반은 그랬기 때문에 더 공감함

    • 다만, 사람들이 자율주행차나 AI의 신뢰도를 인간 이상으로 원하게 되는 건 자연스러운 현상임. "인간도 못한다"는 변명은 그런 기대를 가진 사람들에게 별로 소용없는 논거임. 개인적으로는 충분히 이해되는 태도임

  • "LLMs는 copy-paste(혹은 cut-paste)를 하지 않는다"는 본문의 주장처럼, 코드를 기억해서 삭제하고 새로 쓰는 방식이고, 그래서 매번 새로운 write command만 내리는 느낌임. 리팩터에서는 사실상 실제 copy/paste가 많진 않아서, 컨텍스트 기반 recall만으로 처리하는 게 더 많음. 실제 작업에선 copy/paste 명령 자체가 딱히 유용한지도 불분명하다고 느낌(적어도 내 테스트에선 큰 차이 없었음). 오히려 반복적이고 컨텍스트를 많이 차지하는 부분은 fastmod 같은 도구로 codex나 claude에 "이 부분 일괄 수정" 도와주는 게 효과적임. 문제 해결 접근법 자체가 인간과 달라 어색하긴 한데, 충분히 플랜을 짜면서 소통하면 접근 방식 자체가 크게 달라질 수 있음

    • IDE는 여러 파일에서 함수 시그니처나 이름을 즉각 바꿀 수 있는데, LLM 에이전트가 시도하면 수분이 걸려도 정확하게 처리하지 못하는 경우가 많음. 실제 copy/paste 지원의 효용이 분명하다고 생각함

    • copy/paste는 컨텍스트 폭발을 줄여주는 역할이 큼. 모델이 코드 블록 내용을 기억하지 않아도 필요할 때마다 언제든 접근 가능해지기 때문임

답변달기