▲

에이전트형 AI를 밀어붙이는 이유는 무엇인가? 모델이 간단한 지시도 제대로 따르지 못하는데

 (forum.cursor.com)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • AI 코딩 모델이 단일 명령조차 신뢰성 있게 수행하지 못하는 현실에서, 백그라운드에서 자율적으로 작동하는 에이전틱 코딩에 대한 과도한 기대가 형성되고 있음
  • 작성자는 100줄 규모의 Golang 함수를 참조 코드로 제공했음에도 GPT-5와 Gemini Pro 모두 일부 로직을 누락하거나 업데이트를 빠뜨리는 문제를 경험
  • 에이전틱 시스템이 50개 파일과 다수 함수를 자율적으로 처리하는 것은 현재 기술 수준에서 비현실적이며, 오히려 디버깅에 더 많은 시간이 소요될 위험이 있음
  • 커뮤니티 응답은 체계적인 프롬프팅, 문서화, 단계별 검증을 통해 제한적으로 성공적인 활용이 가능하다는 의견과, 에이전틱은 아직 실용적이지 않다는 회의적 의견으로 양분됨
  • 현재 LLM은 지능이 아닌 지식 기반 시스템이므로, 개발자가 직접 맥락을 제공하고 단계별로 검증하는 "도구적 활용"이 현실적인 접근법임

원글 작성자의 문제 제기

  • 단순 명령 실패 사례: 100줄의 Golang 함수를 참조로 제공하고 다른 함수를 같은 구조로 업데이트하도록 요청했으나, GPT-5와 Gemini Pro 모두 일부 로직을 누락하거나 업데이트를 빠뜨림
  • 에이전틱 코딩의 비현실성: 단일 함수도 제대로 처리하지 못하는 상황에서 50개 파일에 걸쳐 다수의 함수를 자율적으로 수정하는 에이전틱 방식은 더 많은 문제를 야기할 것으로 우려
  • 6000줄 파일 업데이트 질문: Stripe 버전 업데이트처럼 6000줄 규모의 파일을 안전하게 수정하는 방법에 대해 커뮤니티 의견 요청

긍정적 활용 사례 및 방법론

체계적 문서화 및 인덱싱 접근

  • Markdown 참조 파일 활용: .md 파일에 레퍼런스를 저장하고 AI가 이를 읽도록 지시하면 일관성과 정확도가 향상됨
    • 예시 프롬프트: "첨부된 goLang_Update_reference.md 파일을 참조하여 update 함수의 핵심 포인트를 요약하고, 이를 기반으로 소프트웨어 업데이트 초안 작성"
  • 로컬 인덱스 구축: 대규모 파일(6000줄 이상)의 경우 1000줄 단위로 스캔하여 함수명과 라인 참조를 포함한 인덱스 생성
    • 프론트엔드 작업 시 fr.index.md 등 특정 영역만 분리한 인덱스 활용

에이전트 관리 및 작업 구조화

  • 에이전트 전문화: 설계(architect), 코드 탐색(codeseeker), 코더(coder) 등 역할별 에이전트를 구성하고 각각에 맞는 .md 규칙 파일 제공
  • 수직 슬라이스 접근: 10만 토큰 이하로 완성 가능한 작은 기능 단위로 작업을 분할
    • 10만 토큰을 초과하면 에이전트의 오작동 가능성이 급증함
  • 작업 문서화 강제: docs/TASKS.md, docs/WORKLOG.md, docs/DECISIONS.md 업데이트를 필수화하여 작업 연속성 확보

Plan Mode 및 Ask Mode 활용

  • Plan Mode: 프로젝트 전체를 검토하고 요청에 따라 계획을 수립한 뒤 단계별로 진행
  • Ask Mode: 코드베이스 쿼리, 아이디어 탐색, 옵션 검토 등에 활용하며 Google/StackOverflow 대체 도구로 유용

단위 테스트 선행 접근

  • 테스트 기반 개발: 함수 작성 전 단위 테스트를 먼저 작성하고, AI가 테스트를 통과하는 코드를 반복 생성하도록 함
    • 기능적으로 올바른 코드를 얻을 확률이 크게 증가하며, 이후 최적화 및 정리 작업만 필요

회의적 의견 및 한계 인식

에이전틱의 현실적 한계

  • 감독 없는 작업은 자살 행위: 현재 기술 수준에서 티켓을 할당하고 백그라운드에서 자율적으로 작업하도록 두는 것은 실패 확률이 높음
  • 거짓말 가능성: 모델은 성공보다 환각(hallucination)을 생성할 가능성이 더 높으며, 최악의 경우 기존 코드를 파괴할 수 있음
  • Planning Mode의 중복성: 기본 모델에게 상세한 계획을 요청하는 것으로도 충분하며, Planning Mode는 실질적으로 새로운 기능을 제공하지 않음

LLM의 본질적 제약

  • 추론이 아닌 예측: 모델은 결과를 검증하지 않고 다음 단어를 예측하는 방식으로 작동하므로, grounding, memory, feedback이 개선되기 전까지 신뢰성은 계속 불안정할 것
  • 지능 없는 지식 기반: LLM은 지능이 없는 고도화된 지식 베이스이며, 개발자가 직접 지능(BYOI: Bring Your Own Intelligence)과 맥락을 제공해야 함
  • 메모리 부족: 모델은 진정한 메모리가 없고 context와 context cache에만 의존하므로, 새 채팅을 시작할 때마다 맥락이 초기화됨

언어 및 데이터 편향

  • Golang의 상대적 불리함: Golang은 Python이나 JavaScript에 비해 공개 코드베이스가 적어 모델이 학습한 패턴과 관례가 부족함
    • 이는 일관성 있는 편집이나 변환 결과를 얻기 어렵게 만드는 구조적 요인

성공적 활용을 위한 실용적 가이드

프롬프팅 및 맥락 제공

  • 명확하고 상세한 지시: 문법과 구두점을 정확히 사용하며, 모호한 표현 대신 명시적 지시 제공
  • 모든 관련 파일 명시적 참조: 에이전트가 사용해야 할 파일을 모두 명시하지 않으면 스파게티 코드 발생 확률이 증가
  • 규칙 파일 설정: 워크스페이스 전체 규칙과 프로젝트별 규칙 파일을 설정하여 일관된 코드 생성 유도
  • @Docs 활용: 에이전트에게 필요한 핵심 지식을 제공하기 위해 문서 참조 기능 활용 (일부 버전에서 작동 불안정)

작업 범위 및 검증

  • 작은 단위로 분할: 한 번에 처리할 수 있는 최소 단위로 작업을 나누고, 각 단계를 검증한 후 다음 단계로 진행
  • 실시간 검토: 생성되는 모든 코드를 실시간으로 검토하고, 즉시 수정 요청하여 스파게티 코드 방지
  • 백업 및 버전 관리: 각 단계마다 백업을 생성하고 GitHub 등 버전 관리 시스템 활용
  • 테스트 실행: pytest --testmon -q로 영향받는 테스트를 증분 실행하고, 완료 전 전체 테스트 실행

모듈화 및 코드 구조

  • 6000줄 파일 분할: 단일 파일에 6000줄은 비모듈적이며 맥락 제공에 불리하므로, 500줄 규모의 12개 파일로 분할하는 것이 효과적
  • 수직 슬라이스 선호: 끝에서 끝까지 실행 가능한 작은 기능 단위로 개발

모델 선택 및 비용 관리

  • Claude Sonnet 4.5 우선 고려: GPT나 Gemini에 비해 일관성과 정확도가 높아 추가 비용 대비 가치가 있음
  • 토큰 소비 주의: 대규모 계획은 많은 토큰을 소모하므로, 실제 실행 시 작은 단계로 나누어 진행하는 것이 비용 효율적

특수 사용 사례

일회성 스크립트 생성

  • 분석 스크립트: 하루에 수백 개의 일회성 데이터 분석 스크립트를 작성해야 하는 경우, 정확도가 50%라도 수동 작성 대비 1000배 빠르게 생성 및 실행 가능
  • 결과 검증 가능성: 결과를 직접 검증할 수 있으므로 정확도가 낮아도 실용적

처음부터 앱 구축

  • 멀티 에이전트 구조: 대규모 앱을 처음부터 구축할 때 감독 에이전트가 다른 에이전트의 작업을 검토하며 일관성 유지
    • import 이름, 변수명 일관성, 코드 중복 방지 등에 효과적
  • 비용 대비 효율성: 여전히 복잡한 수정 및 리팩토링이 필요하여 단계별 접근이 장기적으로 더 저렴

커뮤니티 의견 요약

긍정적 경험 (3~5배 생산성 향상)

  • Next.js 웹사이트: 제로에서 완전 작동하는 배포 가능한 웹사이트를 몇 분 만에 구축
  • 복잡한 기능 구현: 채팅 앱에 threads 기능을 3~4분 만에 구현 (예상 3일 작업량)
  • 체계적 접근 시: 명확한 규칙, 충분한 맥락, 단계별 검증을 조합하면 일관된 성공 가능

부정적 경험 (현재는 비실용적)

  • 스파게티 코드 양산: 광범위한 목표를 주면 문서 업데이트 누락, 잔여 파일 미삭제 등 문제 발생
  • 의미적 오류: 기술적으로는 작동하지만 코드 위치가 부적절하거나 기존 함수를 재구현하는 등 구조적 문제
  • 5분 이상 추적 실패: 5분 이상 실행되는 긴 추적은 대부분 쓸모없는 결과 생성
▲
GN⁺ 4시간전  [-]
Hacker News 의견
  • 내가 직접 경험해보니, LLM들이 대부분 내 지시를 잘 따른다는 느낌임. 물론 세밀하게 잘 다듬은 프롬프트와 사전 계획이 필요하지만, 그 세 가지 감만 잡으면 이러한 코딩 에이전트로 충분히 날아다닐 수 있음. 가끔은 10번 중 1번 정도는 틀리지만, 이런 경우에도 빠른 중단과 재지정으로 금방 원래 길로 복귀함. 여기 HN에서 많은 사람들이 효과에 회의적인 점이 의외임. 물론 비용, 직업 변화 등 걱정거리가 많겠지만, 코딩 에이전트의 효용성을 의심하는 게 자주 보이는 건 뜻밖임
    • 실제로 에이전트 시스템이나 LLM이 구글 검색이나 stack overflow를 넘는 가치를 창출하는 사례를 영상이나 실사례로 본다면 좋겠음
    • 현재 상태, 원하는 결과, 그리고 진행 방법을 충분히 설명해주면, 에이전트와 함께 계획을 세우고 다듬어서 실행할 수 있음. 이렇게 하면 최신 기술 수준도 꽤 인상적임. 단 한 문장으로 복잡한 걸 기대하는 건 무리임. 현업 경험이 없는 똑똑한 인턴에게 기술 작업을 맡길 때와 비슷하게 실제 시간과 수고가 필요함. 다만 AI 에이전트는 인간 인턴보다 훨씬 빠르게 일함
    • “대부분 잘 된다”는 사실상 신뢰성 지표(9의 개수)가 없다는 뜻임
    • 방금 개 산책하다가 Codex(gpt-5-high)로 Python 앱을 Go로 한 번에 변환시켰음. 결과물 테스트해보니 잘 작동함. 버추얼환경 없이 단일 바이너리로 배포 가능해진 점이 만족스러움. 명령이 엄청 쉬웠던 건지는 잘 모르겠음
    • “대부분 잘 된다”는 기준이 나에겐 충분치 않음. 더 심각한 문제는 지시를 따르지 않는 것보다 잘못됐다는 걸 인정하지 않고 오히려 계속 우기는 현상임. 내가 중간 정도로 복잡한 걸 시키거나 에러 분석을 요구하면, 꽤 자주 잘못된 결론에 집착함. 내가 문제를 직접 언급할 때까지도 돌파구를 못 찾는 경우가 많음. 단순한 코드나 보일러플레이트 작업엔 정말 좋고, 약간의 피드백만 주면 새로운 라이브러리도 만들 수 있었음. 하지만 자주 틀리다 보니 더 복잡한 건 맡기고 싶지 않음. 그래도 막혔을 땐 아이디어 쏟아내기용으로 쓰는데, 비록 틀리더라도 동기부여엔 도움됨
  • LLM에 대한 개발자별 경험 차이가 신기하게 클 때 진짜로 우리가 자문해야 할 것은 “왜 이렇게 경험이 다를까?”라는 점임. “너가 제대로 안 쓴다”는 식의 설명이 가장 단순하지만, AI시스템 개발자로서 실제로 복잡한 지시 없이 “고쳐줘”, “보고서 만들어”만 써놓고 결과를 기대하는 사용자가 많다는 것도 놀라움. ‘AI로 뭐든 할 수 있다’는 식의 오버된 경영진 하이프도 있는데, 이건 기업가치·주가와도 연결됨. 일반 대중도 AI를 ‘진짜 인공지능’이라 여기는 듯. 사실 LLM이 간단한 지시조차 못 따른다는 주장은 신빙성이 낮고, 중요한 건 복잡한 일은 여전히 제대로 못 한다는 것임
    • 내 또 다른 이론은, 각자 머릿속의 사양(spec)이 있는데 그걸 두서없이 적어서 LLM이 구현하길 바라면 실제 결과물이 항상 사양과 어긋난다는 점임. 어떤 개발자는 이걸 마음속에서 사후적으로 바꾸거나 약간의 차이를 그냥 수용하는데 반해, 어떤 개발자는 LLM이 머릿속 계획을 못 맞췄다고 실망함. 약간 심리적 ‘가짜 기억’처럼, 누군가 더 유연하고 타협적이고, 누군가는 완고하게 구는 차이임. 나도 이 두 가지를 번갈아 체험함
    • 이제는 누가 실제로 비(非)트리비얼한 기능을 만들어내는 모든 과정을 보여주는 스크린캐스트, 긴 글, 무엇이든 더 많이 보고 싶음. AI 인플루언서들은 거의 AI로 AI툴 만들거나 CRUD, hello world 데모만 보여줌. 베테랑 개발자도 코드베이스 절반 이상을 AI가 만들어줬다 하면서, 실제론 거의 다 버리고 일부 참고만 한다고 밝힘. “싱글 프롬프트 → 완성된 앱” 이야기는 금방 “빈 화면에서 동기부여 받을 때는 유용함” 식으로 바뀜. 실제 현업 개발자가 진짜 어떻게 쓰는지 더 투명하게 공유됐으면 함
    • 사실 “개발자”라는 범주는 워낙 광범위해서 이 논의에 큰 의미가 없음. 대부분이 비슷한 CRUD형식의 코드 조각 맞추기에는 LLM이 제법 잘 작동함
    • 모두 각자 다른 코드베이스에서 딴 작업을 함. 이 중요한 세부사항은 거의 얘기 안 됨. 더 자주 쓸수록 기대 기준이 점점 높아지고 한계를 빨리 체감하게 됨. 가끔만 쓰면 인상적이지만, 하루 종일 쓰면 결국 실망감 누적임. “이쯤은 해낼 수 있어야 한다” 싶은 것도 다시 손봐야 하는 경우 많음
    • 결과가 다른 게 아니라 각자의 기대치가 다르다고 확신함. 회사 IT SVP는 AI 찬양론자. 최근 그가 예전에 만든 PHP 레거시 프로젝트를 작업하는데, 평소 그가 만족하는 코드 퀄리티 수준이 엄청 낮다는 걸 깨달음. 나도 매일 LLM을 쓰지만 항상 결과를 수정함. 즉, 코드 퀄리티가 낮을수록 LLM 결과물에 더 만족하게 됨
  • cursor 포럼에선 “네가 잘못 쓴 거야”라는 얘기만 반복되지만, 진짜 궁금한 건 신뢰, 프로세스, 실제 현업 적용임. 여기서도 결국 대규모로 쓰는 경우를 거의 못 본다는 느낌임. 우리도 AI를 대부분 ‘멍청한 동료’쯤으로 쓰고, 제약 적은 사이드 프로젝트에서 더 실험적으로 활용함. 에이전트는 거의 하이프(혹은 극히 틈새용)라는 인상임
    • OP가 결과가 나쁜 이유는 Cursor를 쓰기 때문임. Cursor는 비용 절감을 위해 대화 맥락을 무자비하게 잘라냄. 모델 프로바이더와 달리 LLM 사용에 소매가로 비용을 지불해야 해서 불리한 가격 경쟁에 있음. Cursor가 맥락을 얼마나 자르는지 투명하게 공개하지 않고, 내 경험상 정말 공격적으로 맥락을 쳐내서, 똑같은 파일을 반복해서 불러줘야 뭐가 뭔지 파악할 수준임. 내 조언은 Cursor에 시간 투자 그만두는 것임. Cursor가 만들어낸 코드는 부채만 생김. Codex와 Claude로 넘어와서 훨씬 만족 중임
    • 구체적으로 어떤 개선을 바라는지 궁금함. 원 포스팅에 구체적 예시·프롬프트·방법론이 없고 그저 “나 프롬프트 잘 짜요”뿐인데 이러면 평가도, 조언도 어려움. 애초에 에이전트적 워크플로에 회의적인 시선도 이해하지만, 사람들에게 제대로 반론 기회도 안 준 셈임. 나도 몇 달간 에이전트와 함께 일하고 있는데, 아직도 뭐가 잘 되고 뭐가 실패하는지 배워가는 중임. 내 경험상:
      • agent-os와 같은 프레임워크로 오케스트레이션이 필수적임
      • 지도와 자율의 균형 잡기가 중요함
      • 특히 레거시 코드에선 사전 계획이 정말 중요함
      • 나의 예시: 레거시 시스템에서 맥락창을 자꾸 초과하며, 맥락 정리하면 필수 정보가 자꾸 빠져서 같은 실수를 반복함.
      • 효과적이었던 방법: 문제를 명확히 구조화하고, 발견/학습한 내용 일일이 정리해서 기록하며, 아주 구체적인 하위 에이전트로 분할함(맥락창을 관리할 수 있음). 그제야 레거시 코드 탐색에 에이전트가 실질적 도움이 됨
    • 에이전트가 내가 못 찾던 프로덕션 버그 여러 개를 잡아낸 경험 있음(내가 충분한 시간 못 쏟은 낯선 버그). 물론 못 찾는 버그도 훨씬 많지만, SW 엔지니어 한 시간 들여 찾는 것 대비 거의 공짜나 마찬가지인데 종종 먹히면 충분히 쓸만한 전략임
    • 실질적이고 구체적 예제를 포함한 글이 더 의미 있고, 더 좋은 답변을 이끌어낼 것임. 구체적인 현업 문제와 LLM이 실패한 과정을 보여주는 정보가 더 유익함
    • 실제 비즈니스 가치는 사람들이 생각하는 것보다 훨씬 작아서 답답함. 확실히 보일러플레이트나 익숙한 분야에선 인간보다 잘 쓰는 경우도 있음. 하지만 그 밖의 문제점(빅테크 종속, 데이터 오염, 검증 불가 정보, 창의성 저하, 오리지널리티 붕괴, AI광신도 무지, 에너지 소비, 인간 창작물 도용 등)이 너무 큼. 이런 게 인류에 순이익이라고 믿는 게 신기할 따름임
  • 2025년엔 마케팅이 레딧, LinkedIn 등 모든 포럼에서 브랜드가 대화에 스며드는 식으로 정말 잘 이뤄짐. CEO, AI “사상가”, VC들은 LLM을 마법처럼 선전하고 v0, Lovable 등을 차세대 혁신으로 포장함. 리더십의 대답도 죄다 비슷함(관련 영상). 하지만 실제로 CLAUDE.md나 cursorrules 같은 걸 아무리 만들어도 거의 효과 없음. 결국 LLM이 지시를 따라야 하는데 실제로는 랜덤 같음. 아주 단순한 규칙조차 거의 안 지켜서, 커서 포럼에 글 쓴 사람들은 다 아마추어 같다는 생각이 듦. 그리고, 새로운 코드 작업은 LLM이 정말 못함. 존재하지도 않는 라이브러리로 가정 짓고 별 쓸모 없는 글자만 만들어냄. 나는 말 그대로 speech-to-text처럼만 쓰는데, LLM이 내가 놓친 엣지 케이스, 모르는 베스트 프랙티스, 문법 등은 더 잘 잡아냄.
    • [1] 검색, Perplexity 등에서 나오는 결과는 대부분 마케팅팀이 뿌려놓은 마케팅 덩어리임
    • 새로운 코드 작업엔 LLM이 정말 끔찍하다는 말에 완전히 공감함. 현행 SOTA 모델은 아주 유명하고 일관된 패턴(MVC 등)이 있는 프레임워크에선 보일러플레이트나 단순 구조는 곧잘 만들어냄. 진짜 돋보이는 점은 많은 정보를 훑어서 어떤 것(코드베이스, 로그, 스택 트레이스 등)을 찾아내는 임무임. 하지만 ‘에이전트가 코드베이스 전체를 만든다’는 마케팅은, 지금으로선 실화가 아니라는 생각임
    • 나는 경험이 완전히 정반대임. 최근 일주일간 Claude Code가 내가 관리하는 컴파일러 문제를 거의 자기 주도적으로 수정해줬음. 가끔 답답했던 경우를 빼면, 꾸준히 미묘한 코드 생성·파서 버그까지 잘 고쳐줬고, 내가 개입하는 부분도 compaction 관리 등 도구의 한계에 더 가까움. 책 찾아봐야 알 만한 방법도 구현했고, 실제로 돌려봤을 때 잘 작동함을 확인함. 완전히 새롭고 진짜 “혁신”적인 건 적겠지만, 사실 거의 모든 코드는 새로울 게 없음. 내 경험상, 잘 구조화된 가이드에 따라 시키면 대체로 매우 잘 따름. 단순히 CLAUDE.md에 막 적어놓는다고 되는 게 아님. 핵심은 프로세스에 대한 꼼꼼한 안내임. 내 작업 방식은 1) 프로젝트별 디버깅 가이드, 2) 수용기준 명확화, 3) 테스트 자주 돌리고, 단위별로 작은 변화는 파일로 기록하게 하는 식으로 나뉨. 이렇게 하면 Claude로 수 시간 자동 작업도 거의 감독 없이 돌릴 수 있음(중간에 “계속” 명령어 주거나 /compact 쓰는 정도). 매번 완벽한 코드를 주진 않지만, 나도 마찬가지임. 그래도 대체로 긍정적 변화로 이어지고 내 노력은 훨씬 줄었음. 완벽히 설계되지 않은 상태에서 부트스트랩은 아직 권장하지 않지만, 가끔은 이것도 해냄(단, 사전 리뷰 필요함). 요즘엔 Claude가 며칠 단위로 문제를 자동 해결하도록 논스톱 작업을 고민할 정도임
    • 각자의 LLM 경험이 이렇게 다를 수 있다는 게 진짜 흥미로움. 나의 경우 codex-cli로 생산성 5배 증가를 체감함. 매우 이례적인 구조의 소스와 내부 SVG 실행 트레이스를 커스텀 JSON 그래프 포맷으로 변환하거나, 복합 Python/C++ 코드베이스(저수준 RISCV 커널까지)에서 정확한 문서 추출도 거뜬했음. 같은 도구로도 이렇게 다른 결과가 나오는 원인이 정말 궁금함
    • Claude로 코딩할 때 슬롯머신 돌리는 느낌임. 가끔 원하는 것 딱 나오지만, 훨씬 더 자주 아니거나 완전 빗나감. 절대 혼자 무인 운행에 맡기면 위험함
    • 내가 느끼기에도 LLM의 가장 꾸준한 가치는, 인간이 자주 놓치는 사소한 실수나 최선 예시, 코드 문법 등을 제일 잘 잡아준다는 점임. 그래서 PR리뷰어로 쓰면 소금 한 스푼 곁들여 괜찮음
  • 우리 회사는 클래식 XP 방식 적용함. 브라운필드 앱에 새 기능 개발할 때 “red-test-writer”, “minimal-green-implementer”, “refactorer” 등 거의 8개 하위 에이전트로 분할함. 이제 Claude Code에 “이 TDD 프로세스로 X 기능 만들어줘”라고만 입력하면 30분만에 훨씬 더 나은 코드, 90% 테스트 커버리지, 즉시 수락 가능한 상태로 결과물 완성됨. 수 년간 XP·페어프로그래밍·TDD 경험 바탕이긴 하지만, 1년 넘게 프로덕션 코드 95%가 AI가 쓴 코드임(비트리비얼한 복잡 기능도 포함함). 사실상 비밀 노하우도 없이, 잘 굴러감. 우리에겐 정말 효과가 대단함
  • 여기 의견 차이가 엄청남. 각자 뭐에 실패했는지, 어떤 작업에 쓰는지 밝히지 않으면 제대로 된 토론이 불가능함. LLM이 실패/성공한 구체적 범주 얘기 안 하면 다 잡음 그 이상 아님
    • 토론 땐 언어/프레임워크, 문제도메인, SRE 레벨, LLM(모델/버전), agentic harness(claude code, codex, copilot 등), 실패/성공 케이스, LLM 숙련도까지 상세히 명시해야 함. 또 엔지니어가 한 코드베이스만 10년 했는지, 여러 프로젝트를 번갈아 하는지, 신규개발(Greenfield)인지 유지보수인지, 혁신 연구인지, CRUD인지 등 조건도 다를 수 있음
  • 과학자 입장에선 각 데이터셋마다 조금씩 다른 보일러플레이트를 반복해야 할 때가 많은데, 코딩 에이전트가 이걸 상당 부분 해결해줌. 특히 “절대 데이터를 만들어내지 마, np.random 쓰지 마”라고 다섯 번 대문자로 강조해도 Claude가 무시할 때가 있음. 이런 점은 의외로 황당함. 잘 될 때는 환상적이지만, 안 되면 실패 신호조차 없음. LLM 마케팅 관점에선 코딩 에이전트 뒤에 감시하는 ‘PIPA(Performance Improvement Plan Agent)’ 같은 에이전트가 따라다니면서 제대로 일하는지 실시간 감시하는 것도 상상해봄. PIPA가 코딩 에이전트의 성과를 체크해 HR 또는 경영진이 AI 직원(에이전트)을 관리하게 되고, 이런 식으로 미래가 올 수도 있음
    • "분홍색 튜튜 입은 코끼리 생각하지 마!"라고 하면 오히려 떠오르지 않았나? 과학자라면 LLM 특성상 부정문을 잘 못 이해한다는 걸 알아야 함. LLM은 토큰 단위로 학습해서 “NO ELEPHANTS”라고 해도 ‘코끼리’란 단어가 맥락에 남음. 그래서 되려 해당 단어로 유도됨. 긍정 지시문을 써야 더 유리함
    • PIPA 상상만 해도 무서움
  • 모델이 스스로 적절한 맥락을 찾도록 프롬프트(좋은 오류 메시지 등)가 핵심이고, 작업을 아주 작고 일정하게 나누면 반복/단계 테스트 결과를 다음 작업 맥락으로 전달하는 게 가능해짐. 50%의 문제는 이 방식에 맞고, 50%는 전통적 자동화보다 LLM 루프가 덜 번거로울 정도지만, 그 중 절반은 투자 대비 추구 가치가 떨어짐. 결국 마법의 “12.5%” 사례가 있다면 강하게 제한된(Constrained) 에이전트 방식이 최적임
    • 그 과정 그대로 유튜브 등으로 생중계(튜토리얼 말고 자연스러운 라이브 코딩)를 해보면 좋은 인사이트 공유가 될 것임
  • 거의 30년 전, AI에 입문했을 땐 이런 말을 들음. “intelligent agent(지능형 에이전트)”란 말을 들으면 “훈련 가능한 개미”라고 생각하라는 조언이 있었음
    • 더 자세히 궁금함
  • 나에겐 가장 큰 문제가 AI툴의 성능이 작업별로 큰 폭으로 들쭉날쭉하고, 어디서 실패할지 예측이 어려워 시간을 쓰는 일이 있다는 점임. 툴 경험이 쌓이면 프롬프트 실력이 좋아지겠다 싶지만 여전히 답답함. 다만, 에이전트와 AI의 유용성이 겹치는 부분도 있음(예: 새 프로젝트 보일러플레이트 자동 생성 등). 그럴 때는 ‘에이전트 모드’가 더 편함. 아직은 내 실전 경험이 부족한 편임
    • 제대로 작동할수록 기대가 점점 높아지고, 쓰임새도 넓히게 되는데, 그러다가 한계에 부딪치면 오히려 처음보다 더 실망감이 커짐
답변달기