에이전트가 일할 때 필요한 비판적 사고
TMT예전에는 비판적 사고란 새로운 정보를 겸손한 호기심과 적절한 의심을 품고 대하는 것이라고 배웠습니다. 다양한 관점을 받아들이고 자기 의견을 형성하라는 것이었죠. 지금도 맞는 말입니다. 하지만 업무의 상당 부분을 에이전트로 처리하게 되면서, 일상에서 비판적으로 생각하도록 요구받는 일이 점점 사라지고 있습니다. 여러 세션을 병렬로 실행하고 모델이 더 좋아질 것을 기대하며 에이전트 중심의 워크플로를 적극적으로 받아들인 엔지니어와 제품 담당자들에게 이 말을 전하고 싶습니다. 저 역시 이 도구들을 무척 좋아합니다. 에이전트 활용을 줄이자고 이 글을 쓰는 것은 아닙니다.
무엇이든 에이전트에게 맡기기 쉬운 세상에서 비판적 사고를 유지하도록 돕는 것이 제 목표입니다.
과거에는 질문과 답변 사이에서 생각을 정리하고 미적인 판단을 내리는 일이 대부분 이루어졌습니다. 이제 그 시간은 몇 초에 불과합니다. 에이전트 중심의 워크플로를 많이 사용할수록 비판적 사고를 유지하기는 더 어려워집니다. 다만 사람들이 예상했던 이유 때문은 아닐 겁니다. 모델이 좋아질수록 눈에 띄는 오류의 비율이 낮아지기 때문입니다. 많은 결과물, 어쩌면 대부분의 결과물은 잘 쓰였고 대체로 정확하지만, 다시 살펴봐야겠다는 생각이 들지 않습니다.
동시에 여러 에이전트를 돌리더라도 결과물을 살펴볼 사람은 여전히 한 명입니다.
비판적 사고를 일상에 의도적으로 끼워 넣어야 합니다. 저절로 그렇게 생각하게 만드는 일은 없기 때문입니다.
이 문제를 스스로 바로잡기 어려운 이유 중 하나는 에이전트 중심의 워크플로가 쾌적하다는 데 있습니다. 바쁜 하루에 빠르고 기분 좋으며 대체로 정확한 답을 받으면 숨통이 트입니다. 하지만 바로 그 때문에 경계심을 늦추기도 쉽습니다.
위임, 판단 의존, 항복
저는 사람들과 이 문제를 이야기할 때 하나의 연속선으로 설명합니다.
맨 위에는 인지적 위임(cognitive offloading)이 있습니다. AI에 작업을 맡기되 결과는 여전히 자신이 책임지는 것입니다. 저는 하루 종일 이렇게 일합니다. 여러분도 그렇게 하길 권합니다. 중간에는 판단 의존(deferral)이 있습니다. 도구의 출력이 다음 입력이 되고, 그 결과를 더는 가설로 취급하지 않는 단계입니다. 맨 아래에는 인지적 항복(cognitive surrender)이 있습니다. AI의 결과물을 어느새 자기 생각으로 받아들이고, 확인할 필요조차 느끼지 않는 상태입니다.
인지적 항복은 와튼스쿨의 Steven Shaw와 Gideon Nave가 만든 용어입니다. 제가 지켜본 현상과 정확히 들어맞습니다. 신뢰나 게으름이 커질수록 사람들은 이 연속선 아래로 내려갑니다. 단계마다 변화가 점진적이고 나름 합리적으로 보이기 때문에 그 전환을 알아차리는 경우는 드뭅니다. 지난 답변을 꼼꼼히 읽었으니 다음 답변은 훑어봅니다. 그다음 답변은 뼈대만 봅니다. 그러다 누군가 특정 줄에 관해 물으면, 에이전트의 도움을 받아도 설명하지 못합니다.
이것이 인지적 항복입니다. 인지 부채도 이렇게 쌓입니다. 보통은 시스템에 대한 멘탈 모델을 적용하려다가, 머릿속에 그런 이해 자체가 없다는 사실을 깨닫게 됩니다. Margaret-Anne Storey는 팀이 공유하는 시스템의 작동 원리에 대한 이해가 서서히 무너지는 형태로 이 문제가 드러난다고 썼습니다. 저는 코드에서 나타나는 같은 문제를 이해 부채(comprehension debt)라고 설명한 적이 있습니다. Jeremy Twei가 만든 용어입니다. 그 순간에는 전혀 드러나지 않습니다. 코드베이스는 깔끔하고 테스트도 통과합니다. 시스템을 수정해야 할 때가 되어서야 이제는 아무도 그 시스템을 이해하지 못한다는 사실이 분명해집니다. 전략 문서나 명세서의 목차만 읽고 승인했을 때도 마찬가지입니다.
불가능한 일을 하자는 뜻은 아닙니다. 규모가 큰 현대의 코드베이스 전체를 머릿속에 온전히 담아 둘 수는 없습니다. Claude Code 팀은 필요할 때 이해를 다시 구축한다고 공개적으로 밝혔습니다. 전체 모델을 머릿속에 유지하는 대신, 특정 부분을 이해해야 할 때 Claude에게 그 부분을 설명해 달라고 요청한다는 것입니다. 전에 썼듯이, 이런 부채는 대부분의 엔지니어가 예상하는 것보다 회복하기 쉽습니다. 필요할 때 해당 부분에 대한 이해를 다시 구축할 수 있다면 전체 모델을 유지할 필요는 없습니다. 자신이 무엇을 이해하지 못하고 있는지만 알면 됩니다.
잘못되어도 부담이 작은 일은 전부 맡겨도 됩니다. 하지만 에이전트의 도움을 받아도 질문에 대한 답을 설명할 수 없다면, 결과를 스스로 책임지고 판단하는 주도권을 넘긴 것입니다.
그렇다고 언제나 문제가 되는 것도 아닙니다. 얼마 전 강의를 녹화하면서 평점이 비슷한 호텔 세 곳 중 녹화 장소 한 곳을 골라야 했습니다. 후기를 일일이 읽을 시간이 없어 AI에 결정을 맡겼습니다. 결과는 좋았고, 다음에도 똑같이 할 겁니다. 하지만 우리 돈을 어떻게 투자할지, 아이들의 진로에 어떤 조언을 할지 결정할 때는 그렇게 하지 않을 겁니다. 업무에서도 무엇을 만들어야 하는지, 어떤 변경이 어떤 사용자에게 영향을 주는지, 배포해도 안전한지를 판단할 때는 마찬가지입니다. 틀려도 손해가 작은 일은 맡기되, 다른 사람이 그 결과를 감당해야 하는 일은 판단의 근거를 직접 이해해야 합니다.
스스로에게 던지는 질문들
제 생각이 무엇인지 잘 모르겠을 때면 보통 다음과 같은 기본 질문으로 돌아갔습니다. 내가 올바른 문제를 다루고 있다는 것을 어떻게 알 수 있을까? 올바른 방식으로 해결하고 있다는 것은 어떻게 알 수 있을까? 내 결론을 뒷받침하는 근거가 있을까? 일이 끝났다는 것은 어떻게 알 수 있을까? 대부분은 누가, 무엇을, 어디서, 왜, 언제, 어떻게라는 질문입니다. 글로 적어 놓으면 지나치게 초보적인 질문처럼 보이지만, 평소라면 무시했을 항목까지 생각하게 만듭니다. 요즘은 이 과정을 통째로 건너뛰고 무엇을 해야 할지 에이전트에게 묻기가 너무 쉽습니다. 그래서 지금은 다음과 같이 바꿔 스스로에게 묻습니다.
묻기 전에 가설을 세웠는가? 사소하지 않은 작업을 에이전트에게 맡기기 전에는 답이 무엇일지 제 생각을 적어 둡니다. 머릿속으로 정리하는 정도라도 괜찮습니다. 추측이 틀려도 됩니다. 새로운 정보를 알게 되면 언제든 생각을 바꿀 수 있습니다. 하지만 잘 쓴 답변을 읽고 나면 다른 가능성을 떠올리기가 어려워집니다. 도무지 방향을 잡을 수 없다면 Thariq Shihipar가 말하는 사각지대 점검(blind spot pass)을 요청하세요. 자신이 아는 것을 모델에 주고, 무엇을 모르는지조차 몰랐던 부분을 찾아 달라고 하는 것입니다.
생각하는 데 도움을 달라는 것인가, 생각 자체를 대신해 달라는 것인가? 어느 쪽이든 괜찮습니다. 자신이 무엇을 하고 있는지만 알면 됩니다.
어떤 조건이라면 이 답이 틀릴까? 그런 다음 실제로 확인해 보세요. 모델이 스스로 매긴 확신의 정도는 직접 수행할 수 있는 테스트보다 가치가 훨씬 낮습니다. 그러니 실제로 테스트하게 하세요.
다른 관점에서 나온 반론도 들어 봤는가? 어느 정도 열린 문제에 대해 강한 입장을 취했을 때는 여러 모델에 반대편 주장을 펼쳐 달라고 요청합니다. 그런 다음 결과를 검토하고 제 의견을 형성합니다. 시간은 더 걸리지만 그 주제를 훨씬 깊이 알게 됩니다.
이 결과물을 유지·보수해야 할 사람 앞에서도 확신을 걸 수 있는가? 코드뿐 아니라 전달하는 모든 결과물에 해당합니다. 저는 이것이 자신의 결과물에 대해 설명할 책임을 다하는 기준이라고 생각합니다.
더는 연습하지 않게 된 것은 무엇인가? 일상적인 디버깅의 일부일 수도 있습니다. 어느 정도는 손에서 놓아도 괜찮지만, 의도적으로 내린 선택이기를 바랍니다.
검증을 습관으로 만들기
최근 검증에 관한 글을 많이 쓰는 이유는 병목이 코드를 작성하는 일에서 올바르게 만들었는지 확신하는 일로 옮겨 갔다고 생각하기 때문입니다. 엔드투엔드 테스트든 속성 기반 테스트든 실제 앱 조작이든, 에이전트에게 자신의 작업을 검증할 수단을 주면 사람이 살펴보기도 전에 변경하고, 검증 테스트를 실행하고, 출력을 읽고, 다시 시도할 수 있습니다. Boris Cherny는 이를 “Claude가 자신의 작업을 검증할 방법을 제공하라”고 표현했습니다. 저는 이것이 좋은 결과를 얻는 데 가장 중요한 요소 중 하나라고 생각합니다. 모든 줄을 직접 읽는 대신 이러한 반복 과정을 구축하고 근거를 검토하게 되는 것입니다.
검증마저 포기할 수도 있습니다. “내 결론을 뒷받침하는 근거가 있는가?”라는 질문이 “검사가 초록불로 바뀌었는가?”로 바뀝니다. 에이전트 덕분에 테스트를 만드는 비용이 크게 낮아져 초록불을 자주 보게 되지만, 기능이 고장 나 있어도 통과하는 테스트가 있을 수 있습니다. 기능과 테스트를 작성할 때 같은 실수를 했다면 테스트는 통과합니다. 게다가 초록불 하나가 알려 주는 것은 속성 하나뿐입니다. 그것으로 모든 것을 확인했다고 생각하기는 너무 쉽습니다.
검사가 통과하면 무엇을 입증했는지 물어보세요. 그런 다음 무엇을 입증하지 못했는지도 물어보세요.
‘검증했다’는 말의 의미를 미리 정해 두세요. 일이 끝난 뒤에는 어떤 결과든 합리화하게 됩니다.
에이전트 작업의 완료 기준은 테스트 통과, 스크린샷, 로그나 트레이스처럼 구체적인 것이어야 합니다. 그래야 완료 여부를 사실에 근거해 판단할 수 있습니다. “끝난 것 같다”는 식으로 해석에 맡겼다가 판단을 포기하지 않게 됩니다. 에이전트에게 완료 알림을 받으면 요약부터 보지 말고, 먼저 실행한 명령의 코드 조각과 그 출력을 확인하세요.
Claude Code는 새로운 컨텍스트의 서브에이전트를 통해 자신의 작업을 스스로 비평하며 기본적인 타당성을 점검할 수도 있습니다. 생각날 때만 하는 것이 아니라 매번 실행하도록 작업 과정에 넣어 둘 만합니다. 저는 마지막에 여전히 “내가 빠뜨린 게 있을까?”라고 묻습니다. 별것 아닌 질문처럼 들리지만, 최상위 성능의 모델로 복잡한 기능을 구현한 뒤 결과를 살펴보고 검토하고 나서 이 질문을 하면, 추가로 두세 가지를 찾아오는 일이 아주 흔합니다. 그래서 늘 묻습니다.
물론 언제나 이 모든 절차를 거칠 필요는 없습니다. 언제 깊이 들어가야 하는지 아는 것도 능력입니다. Claude Code 팀의 코드 리뷰 방식에 관한 글에서 제가 가장 좋아하는 기준은 이것입니다. “검사가 무엇을 놓칠 수 있는지 설명할 수 없다면, 간단한 승인 대신 제대로 된 리뷰를 요청하세요.”
코드 밖에서도 마찬가지입니다. 에이전트가 고객 통화 50건을 종합하거나 경쟁사 분석을 해 주었다면, 원본 문서 몇 개를 확인해 요약이 정확한지 살펴보세요. 권고안의 근거가 되는 수치가 있다면 계산이 올바른지도 확인하세요.
에이전트 덕분에 검증 절차를 마련하는 비용은 낮아졌습니다. 어려운 일은 좋은 검증이 어떤 모습인지 아는 것입니다.
생성된 결과물에 제대로 주의 기울이기
에이전트가 600줄짜리 PR을 제시했다고 해 봅시다. 구조를 대충 살펴보지만 모든 줄을 읽지는 않습니다. 변수 이름도 적절해 보이고 테스트도 통과하니 승인합니다. 하지만 중간 어딘가에서 트랜잭션 경계의 실행 순서가 미묘하게 바뀌었거나, 생각해 보지 못한 예외 상황의 기본값이 반대로 뒤집혔습니다. 리뷰를 하기는 했다고 볼 수 있겠지만, 이미 예상한 것만 확인한 셈입니다.
코드를 작성하는 능력과 리뷰하는 능력은 서로 다르며, 리뷰가 형식적인 승인으로 바뀌는 지점이 있습니다. 그러니 AI가 작성했다는 생각을 내려놓고 diff를 읽으세요. 그런 다음 diff 너머로 에이전트가 어떤 결정을 내렸는지도 살펴보세요. 긴 세션 동안 에이전트는 기본값, 범위에서 제외할 사항, 요구 사항 둘이 충돌할 때 어느 쪽을 재해석할지 등 수많은 작은 결정을 대신 내립니다.
모든 일이 잘 끝났다는 요약만으로는 이런 결정을 알 수 없습니다. 그러니 어떤 결정을 내렸고 어떤 가정을 했는지 나열해 달라고 요청하세요. 그런 다음 스스로 이해도를 시험해 보세요. 몇 줄을 무작위로 골라 “이 줄은 왜 이렇게 썼지? 저 줄은?” 하고 물어보세요. 문서라면 닫은 뒤 핵심 주장을 기억에 의지해 적어 보세요. 긴 세션에서 제가 좋아하는 습관을 실천하는 사람들도 있습니다. Claude에게 변경 사항 보고서를 쓰고 맨 아래에 퀴즈를 붙이게 한 다음, “퀴즈를 완벽하게 통과한 뒤에만 머지한다”는 규칙을 지키는 것입니다.
내보내는 결과물에 대해 근거를 들어 설명할 수 있을 만큼 이해하세요. 언젠가 누군가 물어볼 수 있기 때문입니다.
에이전트는 어디에 주의를 기울여야 할지 판단하는 데도 도움을 줄 수 있습니다. 예를 들어 제 오픈소스 프로젝트에는 PR이 많이 들어옵니다. 저는 에이전트를 활용해 어떤 변경이 들어오는지, 무엇이 가이드라인에 어긋나는지, 어디에 제 주의가 필요할지 파악합니다. 에이전트가 이를 전적으로 판단하게 하는 경우는 드물지만, 제가 집중해야 할 곳을 좁혀 줄 수는 있습니다. 그런 다음에는 이 변경이 올바른 문제를 올바른 방식으로 해결하는지 직접 생각할 수 있습니다.
처리량 문제도 있으며, 이 점에서는 자신에게 솔직해야 합니다. 저는 이를 조율 비용(orchestration tax)이라고 불렀습니다. 에이전트가 생성하는 양과, 자기 이름을 걸고 내보내도 괜찮다고 느끼는 양 사이의 격차입니다. 완료된 작업이 검토할 수 있는 속도보다 빠르게 쌓인다면, 그 문제를 해결하기 전까지는 세션을 하나 더 열어도 도움이 되지 않습니다. 직접 살펴봐야 하는 양이 줄도록 검사를 강화하거나, 속도를 늦추세요.
책임질 수 있는 양보다 더 많이 만들어 내고 있다면, 더는 검토하는 것이 아닙니다. 그저 잘되기를 바라고 있는 것입니다.
좋은 입력에서 좋은 결과가 나온다
사람의 멘탈 모델은 여전히 필요하지만, 작업의 중간 대신 시작과 끝에서 역할을 합니다. 작업 설명과 컨텍스트를 준비하는 앞부분, 결과물을 검토하는 뒷부분에 힘을 쏟는 것입니다. 그래서 좋은 결과를 얻으려면 입력이 중요하며, 저는 좋은 프롬프트를 작성하는 능력도 비판적 사고의 하나로 봅니다.
예전에는 모호하게 요청하면 누군가 의문을 제기했고, 그러다 “잠깐, 나도 이 부분을 제대로 생각하지 않았구나” 하고 깨달을 수 있었습니다. 에이전트는 그 지점에서 멈춰 세우지 않는 경우가 많습니다. 바탕이 되는 생각이 여전히 불분명한데도 빠진 내용을 채우고 완성된 듯한 결과물을 내놓습니다. 저는 이를 의도 부채(intent debt)라고 쓴 적이 있습니다. 직접 작성하지 않은 결과물에 암묵적으로 들어 있을 수 있는 목표, 제약 조건, 판단 근거를 말합니다. 다른 종류의 부채와 달리 이것은 다른 사람이 대신 해결해 줄 수 없습니다. 의도는 자신에게서 나와야 합니다.
프롬프트에는 문제를 얼마나 이해했는지가 드러납니다. 명확하게 표현할 수 없다면 머릿속에서도 명확하지 않을 수 있습니다.
도움을 요청하기 전에 자기 말로 요청 내용을 먼저 정리하세요. 대상 독자나 사용자, 범위에서 제외할 사항, 완료 기준을 적으세요. 두 번째 수정 요청을 하고도 원하는 결과를 얻지 못했다면, 조금씩 고치는 것을 멈추고 프롬프트를 다시 쓰세요.
이 과정에서도 에이전트의 도움을 받을 수 있습니다. 저는 Andy Clark가 AI 시스템에 위임하는 것과 AI 시스템과 협업하는 것을 구분한 방식을 좋아합니다. 협업할 때는 서로의 역량을 높이는 선순환이 생깁니다. 프롬프트를 다듬으면 결과가 좋아지고, 그 결과를 바탕으로 다음 프롬프트와 문제에 대한 멘탈 모델도 더 정교해집니다. 명확하지 않다면 에이전트가 이해하지 못한 부분을 질문하게 하세요. 세션을 마칠 때 자신의 멘탈 모델이 더 정교해졌다면 성공의 신호입니다.
입력 자체도 주의해서 다뤄야 합니다. 각 에이전트가 이전 에이전트의 요약만 컨텍스트로 전달받기는 쉽습니다. 그러다 보면 어느새 세 번째 에이전트는 원문을 읽지 않은 상태가 됩니다.
결과물에 대한 자기만의 기준도 필요합니다. 저는 다양한 창작 분야에서 AI를 활용해 봤지만, 대부분은 제 기준에 미치지 못해 공개하지 않았습니다. 이제는 무엇이든 형식이 깔끔하고 자신만만한 문장으로 나오므로, 겉으로 잘 다듬어졌다는 것은 더는 유용한 품질 신호가 아닙니다.
AI 덕분에 더 빨리 만들 수 있게 되었더라도, 내 결과물이라고 밝히기 꺼려진다면 내보내지 않습니다.
기준에 미치지 못하는 결과물이 나오면 같은 일이 반복되지 않도록 공유 설정이나 훅, 테스트에 그 이유를 기록하세요. 그렇게 판단의 안목이 쌓입니다. 어떤 결과물이 왜 기준에 미치지 못했는지 적는 일 자체도 좋은 습관입니다.
“모델이 나보다 더 잘하게 될 텐데”
주변의 많은 사람처럼 이 분야의 미래를 낙관한다면, 앞의 몇 절을 읽으면서 이미 이런 생각을 했을지도 모릅니다. 1~2년 뒤에는 모델도 내가 발견할 수 있는 문제를 찾아낼 텐데, 굳이 그 능력을 유지하려 애쓸 필요가 있을까?
많은 문제를 찾아내는 능력에 대해서는 맞는 말일 수 있습니다. 저 역시 문제를 발견하는 일을 점점 더 에이전트에게 맡기자고 주장해 왔습니다. 그래도 여전히 중요하다고 생각하는 이유가 있습니다. 결국 내보낸 결과물에는 누군가 책임을 져야 합니다. AI의 도움을 얼마나 받았든 사람이 책임져야 합니다.
어떤 작업에서 에이전트를 얼마나 신뢰할지 결정하는 것 자체가 판단입니다. 그 판단을 현실에 맞게 유지하려면 작업을 검토해야 합니다. 모델이 틀리는 부분은 계속 달라지기 때문입니다. Anthropic도 자사 엔지니어와 연구자를 대상으로 한 연구에서 이 함정을 감독의 역설로 지적합니다. “Claude를 감독하려면 코딩 능력이 필요한데, 바로 그 능력이 AI를 지나치게 사용하면서 약해질 수 있다”는 것입니다.
제가 특히 중요하게 여기는 질문 중에는 모델이 더 좋아져도 해결해 주지 못할 것들이 있습니다. 무엇을 만드는가? 왜 만들 가치가 있는가? 누구에게 영향을 주는가? 무엇을 희생할 의향이 있는가? 모두 스스로 답해야 할 질문입니다. 에이전트가 함께 고민하는 데 도움을 줄 수 있고 저 역시 그러기를 바라지만, 결국 답할 사람은 여전히 자신입니다.
작업과 검토의 상당 부분은 맡길 수 있어도, 책임까지 맡길 수는 없습니다.
일상에서 실천하기
이 모든 것을 엄격하게 지킬 필요는 없습니다. 자신의 워크플로에 맞는 것을 골라 적용하면 됩니다.
일주일에 한 번은 에이전트 없이 코드를 조금 작성하거나, 방법을 잊어버리면 곤란할 실제 작업 하나를 직접 해 보세요. 저는 이를 자신의 실력을 가늠하는 연습이라고 불렀지만, 도덕적인 의미로 하는 말은 아닙니다. 한 달에 한 번은 더 이상 직접 하지 않는 일을 적어 보고, 그중 무엇은 하지 않아도 괜찮을지 결정하세요. 예전 블로그 글에서 던진 질문은 지금도 유효합니다. AI가 없다면 얼마나 막막할까요?
이해하지 못하는 것이 있다면 배우세요. 글을 쓰다가 처음 보는 표현을 만나면 구글에서 한 줄짜리 설명을 찾아 그대로 넣을 수도 있습니다. 하지만 저는 조금 더 조사해 제대로 이해하는 편을 택합니다. 그래야 그 표현이 어떤 맥락에 들어맞는지 알 수 있기 때문입니다.
기계의 결과물을 제대로 확인하는 것도 엄연한 업무입니다. 그렇지 않은 척하면 결국 팀에서 아무도 그 일을 하지 않게 됩니다. 공짜로 할 수 있는 일이 아니므로 일정에 별도 업무로 넣어 두세요. 그래야 실제로 하게 됩니다.
쓰지 않는 능력은 사라집니다. 아마 예상보다 빠르게 그럴 것입니다. 놓치고 싶지 않은 능력은 계속 직접 사용하세요.
기억해 둘 것들
- 의도적으로 실천하세요. 에이전트에게 퀴즈를 내게 하거나, 질문하게 하거나, 근거를 보여 주게 할 수 있습니다. 하지만 그렇게 하도록 준비해야만 가능합니다. 그러니 미리 마련해 두세요.
- 연속선의 어디에 있는지 솔직하게 인정하세요. 에이전트의 도움을 받아도 답을 설명할 수 없다면 이미 판단을 포기한 것입니다.
- 가설을 세우세요. 틀린 가설이라도 묻기 전에 먼저 세우세요.
- 초록불 하나가 뜻하는 것은 하나뿐입니다. 무엇을 확인했나요? 무엇을 확인하지 않았나요?
- 근거를 찾으세요. 요약보다 먼저 무엇을 실행했고 어떤 결과가 나왔는지 읽으세요.
- 어떤 결정을 내렸는지 알기 위해 읽으세요. 에이전트가 무엇을 대신 결정했나요?
- 프롬프트를 공들여 쓰세요. 요청을 어떻게 쓰는지에 문제를 얼마나 이해했는지가 드러납니다.
- 기준을 세우고 지키세요. 자기 이름을 걸 수 없는 결과물이라면 내보내지 마세요.
중요한 능력을 직접 사용하면서 계속 판단에 참여하세요. 한 가지 해 볼 만한 방법이 있습니다. 요청하기 전에 어떤 결과가 나올지 예상해서 적고, 에이전트가 일을 마친 뒤에는 확인하지 않은 것 한 가지를 적어 보세요. 그렇게 했을 때 결과물을 읽는 방식이 달라지는지 알려 주세요. 스스로 생각하세요. 더 나은 질문을 하세요. 결과에 책임을 지세요.
