내가 직접 경험해보니, 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의 유용성이 겹치는 부분도 있음(예: 새 프로젝트 보일러플레이트 자동 생성 등). 그럴 때는 ‘에이전트 모드’가 더 편함. 아직은 내 실전 경험이 부족한 편임
제대로 작동할수록 기대가 점점 높아지고, 쓰임새도 넓히게 되는데, 그러다가 한계에 부딪치면 오히려 처음보다 더 실망감이 커짐
Hacker News 의견