AI 에이전트는 '어렵습니다'라고 말하지 않는다. 모호한 요청으로 실패했던 경험담
요약
필자는 Claude Code 사용 경험을 바탕으로 AI 에이전트 활용의 실질적인 노하우를 공유합니다. 에이전트는 지시의 모순이나 목표 자체의 모호성을 스스로 인지하지 못하고, 요청받은 대로 어정쩡한 결과물을 내놓는 경향이 있습니다. 따라서 개발 과정에서는 목적과 수단의 계층 구조를 명확히 하고, '승인 게이트'를 설정하는 것이 중요합니다.
핵심 포인트
- 에이전트는 지시의 모순을 스스로 인지하지 못하고 결과를 도출한다.
- 요청 전, 목적(Goal)과 수단(Means)의 계층 구조를 명확히 해야 한다.
- 개발 방식은 '플레이어'에서 '디렉터'로 역할이 변화해야 한다.
- 코딩보다 에이전트가 이해할 수 있는 문서화 작업에 시간을 투자하는 것이 효과적이다.
이 글에 대하여
필자가 Claude Code를 사용하기 시작한 6개월 동안 깨달은 점들을 정리한 것입니다. 필자의 실전 경험과 고찰을 바탕으로 한 글입니다. 필자가 Claude에게 음성 입력으로 말한 내용을 Claude가 문장으로 정리했습니다. 중간에 인용된 조사 수치는 조사 원 공식 페이지에서 확인하실 수 있습니다. 에이전트 사용에 대한 평가는 필자 본인의 사용 경험에 따른 감상입니다.
대상 독자는 AI 에이전트를 막 사용하기 시작했거나, 사용하면서 뭔가 찜찜한 느낌을 받는 분들입니다.
결론
- 지시에 모순이 있으면, 에이전트는 이를 지적하지 않고 둘 다 만족시키려고 노력하며, 어정쩡한 결과물을 내놓습니다.
- 모순의 상당 부분은 원하는 결과 이미지 자체가 모호하기 때문에 발생합니다. 요청을 하기 전에 목적과 수단의 계층 구조가 뒤섞이지 않았는지 확인해야 합니다.
- 개발 진행 방식은 정해두지 않는 것이 현재 필자의 판단입니다. 결정할 것은 승인 게이트, 즉 어디서 멈춰서 확인을 요구할지만입니다.
- 자신의 역할은 플레이어에서 디렉터로 바뀝니다. 그럼에도 불구하고, 판단을 위한 기술적인 감각(勘所)은 스스로 유지해야 합니다.
코드를 쓰지 않게 되었다
Claude Code를 사용한 지 6개월이 되었습니다. 지금은 제 손으로 코드를 쓰는 일이 없어졌습니다. 이번 주도 작성한 코드는 '0'입니다. 키보드 자체도 그다지 많이 치지 않습니다. Claude에게 내리는 지시는, 할 수 있을 때는 음성 입력입니다.
대신 시간을 쓰고 있는 것은 에이전트가 읽을 수 있는 문장으로 다듬는 것입니다. 과거 자료나 기존 코드 자산에 대해 무엇이 어디에 있고, 어떤 의도로 만들어졌는지 글(문서)로 작성하고 있습니다. 하는 일은 모르는 사람에게 업무를 인계하기 위한 인수인계 자료 만들기와 같습니다. 처음에는 시간이 걸리지만, 이 작업 자체도 에이전트가 도와줄 수 있어서 생각보다 빨리 진행됩니다.
손으로 쓰는 것과 말로 부탁하는 것은 사용하는 두뇌가 다르다
에이전트를 사용하기 전, 필자는 러프한 설계로 직접 코드를 만지는 타입이었습니다. 시스템 구성도와 클래스 관계를 대충 그려놓고 바로 코딩을 시작합니다. 생각해야 할 부분은 주석으로 남기면서 작성해 나갑니다. 20년 가까이 그렇게 해왔기 때문에, 설계가 정해지면 손이 저절로 움직이는 감각이 있었습니다.
지금은 말로 요청을 합니다. 같은 '개발하기'라도 두뇌의 작동 방식이 완전히 다릅니다. 손으로 코드를 작성할 때는 글을 쓰는 뇌가 아니라, 코드를 쓰는 뇌를 사용하고 있었다고 생각합니다. 익숙해지는 데는 약 3개월 정도 걸렸습니다. 그동안은 머리가 쉽게 피로했습니다. 수면 시간이 평소보다 길어지곤 했고, 충분히 자지 못하면 언제까지나 졸린 느낌이 계속되었습니다.
말로 요청하게 되면서 한동안 이 차이가 언어로 정리되지 않아 찜찜함을 느꼈습니다. 최근에야 비로소 머릿속이 정돈되기 시작했습니다. 이 글은 그 정리의 결과물입니다.
모순된 지시는 어정쩡한 결과물이 된다
가장 크게 깨달은 점은, 자신의 논리적 모순이 그대로 결과물에 나타난다는 것입니다.
인간 부하직원이라면
측정 데이터 분석에서, 박스 플롯(box plot)에 나타난 분산을 줄이고 싶다는 업무가 있었습니다. 박스 플롯에는 여러 샘플 간의 대표값 분산이 나와 있습니다. 한편, 각 샘플 내부에도 측정값의 분산이 존재합니다.
제가 부탁한 것은 각 샘플 내부의 측정값 분산을 작게 만드는 로직을 추가하는 것이었습니다. 그 결과, 샘플 내부의 분산은 몇 퍼센트 줄어들었습니다. 하지만, 샘플 간의 대표값 분산은 줄지 않았습니다. 이상치(outlier) 같은 샘플이 섞여 있다면, 그 내부를 아무리 균일하게 해도 대표값은 벗어난 상태이기 때문입니다.
줄이고 싶은 것은 샘플 간의 분산이었는데, 부탁한 것은 샘플 내부의 분산이었습니다. 목적과 수단이 다른 계층에 있었습니다. 에이전트는 요청받은 것을 정확히 수행했고, 제가 원했던 결과는 얻지 못했습니다.
모호한 목표가 모순을 낳는다
두 예시에서 공통적인 것은, 저에게 '마지막에는 이런 산출물이 필요하다'라는 그림이 명확하지 않았다는 것입니다. 에이전트에게 부탁할 때, 요청하는 사람에게는 달성하고 싶은 목적과 원하는 결과의 모습이 있어야 합니다. 그 모습이 모호하면 지시도 모호해지고, 모순을 낳기 쉽습니다. Claude는 '곤란합니다'라고 말하지 않지만, 내부적으로 난처한 상황에 놓여 있고, 그것이 어중간한 산출물로 나타납니다.
반대로 말하면, 에이전트에게 언어로 부탁하는 것은 자신의 논리를 점검할 기회가 됩니다. 손으로 적을 때는 모순이 있어도 쓰면서 억지로 맞추곤 했습니다. 말로 하면, 모순은 말 그대로 남아 산출물에 나타납니다. 저는 에이전트를 사용할수록 논리력이 단련된다고 느낍니다.
진행 방식은 고정하지 않는다
또 하나, 시행착오 끝에 바꾼 것이 있습니다. 개발의 진행 방식을 세세하게 정하는 것을 그만두었습니다.
당초에는 스펙 주도(specification-driven)와 테스트 주도(test-driven)를 염두에 두고, 진행 방식을 확실한 틀로 만들려고 했습니다. GitHub Issue에는 라벨 체계를 만들고, 수정, 기능 추가, 요구사항 정의 문서 작성 등 종류별로 라벨을 붙였습니다. 문서의 종류별로 브랜치 명명 규칙을 정했습니다. 이런 틀을 Claude와 상담하며 조립하고 있었습니다.
그만둔 이유는 두 가지입니다. 하나는 같은 것을 전 세계 사람들이 생각해서 플러그인이나 스킬, 공개 리포지토리 형태로 이미 정리되고 있다는 것입니다. 또 하나는 모델 자체도, 에이전트의 오케스트레이션(orchestration)도, 주변의 플러그인도 계속 진화한다는 것입니다. 진행 방식을 스스로 고정할수록 그 진화에 뒤처집니다.
현재 개발 흐름 문서에는 얇은 내용만 있습니다. 요구사항 정의, 설계, 구현, 테스트라는 큰 흐름 속에서 진행하는 것. 컨텍스트(context)의 위치는 어디인가. 그리고 승인 게이트(approval gate), 즉 어디서 작업을 멈추고 저의 승인을 구할 것인가. 쓰여 있는 것은 그 정도입니다. 연구로 말하면, 배경, 목적, 방법, 결과, 결론이라는 흐름을 지킨다는 정도의 지정입니다. 세부 사항은 그 시점에서 사용 가능한 플러그인이나 스킬에 맡깁니다.
에이전트는 증폭기. 역할은 디렉터로 바뀐다
저는 에이전트를 사용하는 사람 능력의 증폭기라고 생각합니다. 잘 쓰는 사람은 생산성이 크게 오르고, 그렇지 않은 사람은 그 정도가 아닙니다. 차이는 사용하는 쪽 실력으로 벌어집니다.
Gallup은 2026년 7월 기사에서 AI의 생산성에 미치는 영향을 '매우 좋다(extremely good)'고 답한 비율이 리더층에서 21%, 개인 기여자(individual contributor)에서 13%였다고 보고했습니다. 또한, AI를 자주 사용하는 사람의 비율은 2023년부터 2026년 2분기까지, 리더층에서 17%에서 51%로, 매니저에서 15%에서 36%로, 개인 기여자에서 9%에서 26%로 증가했다고 합니다. 이는 AI 전반에 대한 조사이며, 에이전트에 국한된 수치는 아닙니다. 그럼에도 불구하고, 무엇을 맡기고 어디서 확인할지 일상적으로 판단하는 사람일수록 AI의 효과를 느끼고 있다는 저의 감각과 모순되지 않는 결과입니다.
저 자신은 관리직에 가까운 경험도 조금 있지만, 플레이어로서의 경험이 훨씬 긴 사람입니다. 지시나 지휘 명령에 능한 관리직처럼 아직 할 수는 없습니다. 그 경험을 에이전트와의 상호작용을 통해 쌓고 있는 것은 예상치 못한 수확이었습니다.
역할은 플레이어에서 디렉터로 바뀌었습니다. 다만, 디렉터로서 기술적 지식이 없으면 판단하기 어려운 경우가 많습니다. 통제해야 할 부분은 스스로 통제하고, 기술의 캐치업(catch-up)은 계속하는 것. 이것이 현재 저의 위치입니다.
요약
- 에이전트는 모순된 지시를 지적하지 않고, 양쪽을 모두 충족시키려다 애매한 결과물을 반환한다.
- 모순의 원인은 원하는 결과물의 모습이 모호하기 때문이다. 목적과 수단의 계층 구조를 확인한 후 요청하라.
- 말로 요청하는 과정 자체가 자신의 논리를 점검할 기회가 된다.
- 진행 방식은 미리 정하지 않는다. 결정하는 것은 큰 흐름과 승인 게이트(approval gate)뿐이다.
- 역할은 디렉터(Director)로 바뀐다. 기술의 핵심 감각(勘所)은 스스로 계속 가져가야 한다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기