# 외부 루프를 책임져라 > _이 글은 원래_ _[애디 오스마니의 블로그(Addy Osmani’s blog)](https://addyo.substack.com/p/own-the-outer-loop)_ _에 게재됐으며, 저자의 허락을 받아 이곳에 다시 싣는다._ 지난 1년 동안 **에이전트 엔지니어링(agentic engineering)**에 관한 논의는 **하네스(harnesses)**와 **[루프(loops)](https://x.com/addyosmani/article/2064127981161959567?lang=en)**, **에이전트 군단(fleets)**과 **소프트웨어 공장(software factories)**으로 옮겨갔다. 내 생각에는 엔지니어가 **외부 루프를 책임져야 한다(own the outer loop)**. 즉, 이러한 시스템에 대한 **책임성(accountability)**을 맡아야 한다. 페이블(Fable)과 GPT-5.6 같은 강력한 모델이 등장할수록 이는 더욱 분명해진다.  에이전트는 지렛대 효과를 제공하고, 지렛대 효과에는 의무가 따른다. **누군가는 무엇이 정확히 바뀌었는지, 왜 안전했는지, 판단이 틀렸을 때 어떤 일이 벌어질지를 설명할 수 있어야 한다.** 그렇지 않으면 에이전트의 행동을 정당화할 수 없다. 그러면 조직이 애초에 에이전트에게 일을 맡길 가능성도 작아진다. 그래서 세 가지 용어를 이야기하려 한다. 첫 번째인 **품질(Quality)**은 시스템을 실제로 작동시키기 전에 마련해 두는 모든 검사를 뜻한다. 이러한 검사는 증거를 만들고, 우리는 그 증거를 토대로 판정을 내린다. 두 번째인 **판정(Verdict)**은 작업 결과가 이를 사용하는 의존 시스템에 들어가기 전에 내리는 최종 결정을 뜻한다. 나는 이 콘텐츠의 총괄 제작자다. 내 이름으로 결과물을 출시하는 팀을 이끈다. 문장은 모델이 쓸 수 있지만 판정은 내가 내린다. 내가 결정하지 않으면 우리 팀의 결과물이 의존 시스템에 들어갈 수 없다. 판정은 운영 환경에 반영할지를 결정하는 일이다. 출시할 것인가, 차단할 것인가, 다른 곳으로 보낼 것인가, 응답 범위를 좁힐 것인가, 안전장치를 추가할 것인가, 아니면 완전히 거부할 것인가? 세 번째인 **설명 책임(Answerability)**은 누군가 이유를 물었을 때 내가 설명할 수 있음을 보장하는 것이다. 달리 말하면 이렇다. 에이전트는 모델에 파일, 도구, 메모리, 기술, 샌드박스, 권한, 관측 가능성, 복구 체계로 이루어진 하네스를 더한 것이다. 이 에이전트가 조사, 구현, 검증, 반복으로 구성된 루프를 실행한다. 그리고 이 구조가 소프트웨어 공장을 만든다.  모델은 엔진일 뿐이다. 하네스는 도구, 메모리, 권한, 샌드박스, 테스트를 조합해 엔진 주위에 만드는 자동차다. 그래야 모델이 실제 작업을 안전하게 수행할 수 있다.  루프는 한 번의 성공적인 실행을 다시 믿고 수행할 수 있는 프로세스로 바꾸는 방식이다. 하네스를 조사, 구현, 검증, 반복이라는 재현 가능한 주기로 감싸라. 작업 완료 여부는 모델 자신의 주장이 아니라 독립적인 검사가 결정해야 한다.  이제 여러 루프를 동시에 실행해 보자. 공장은 루프를 대규모로 확장한 것이다. 내부에서는 에이전트가 결과물을 내놓고, 경계에서는 인간이 결정을 책임진다. 그리고 **그 공장의 중심에는 시스템 내부와 외부를 나누는 세심한 경계가 있다.** 시스템 내부에서는 제품팀의 의도, 이전에 출시한 작업에 관한 지식, 최근 발생한 사고, 사용자의 구체적인 피드백 등 다양한 입력을 수집한다. 에이전트 루프는 작업을 조사하고 계획을 구현한 뒤 결과를 검증한다. 그런 다음 증거가 그 경계를 넘어간다. 의존 시스템을 책임지는 인간은 증거를 확인하고 진행 여부를 결정한다.  여러분, 이것이 바로 우리가 이루려는 전환이다. 이전에는 에이전트가 실행 루프 안쪽의 일부 작업만 수행했다. 이제 에이전트는 내부 실행 루프 전체를 운영한다. **엔지니어는 외부 루프를 책임진다.**  시스템 내부에서 에이전트가 하는 일은 사실상 한 종류뿐이다. 바로 역량이다. 작업을 조사하고, 계획을 구현하고, 결과를 테스트하고, 보고하는 역량이다. 이것이 모델의 역량이다. 앞서 말했듯이, 그런 미래는 이미 도래했다. **시스템 외부에 있는 것도 한 종류뿐이다. 바로 주도성(agency)이다. 결정하고 검증하고 승인하며 책임지는 주도성이다.** 결국 여전히 코드에 관한 이야기다. 다만 이제 그 코드는 적절한 장소에 있어야 하며, 자신이 무엇을 하는지 아는 사람이 다뤄야 한다. AI 코드의 잠재력은 더 이상 무시할 수 있는 수준이 아니다. 소나(Sonar)가 2026년에 실시한 설문 조사에서 각 팀에 AI의 도움을 받은 커밋의 비중을 물었다. 그 비중은 작았지만 무시할 정도는 아니었다. 여러 응답자는 AI 지원 커밋의 비중이 크게 늘어날 것으로 예상했다. [소나의 _2026년 코드 현황(2026 State of Code)_ 보고서](https://www.sonarsource.com/state-of-code-developer-survey-report.pdf)에 따르면 커밋된 코드의 42%가 AI로 생성됐거나 AI의 상당한 도움을 받아 작성됐다. 이 비중은 정체되지 않고 계속 증가할 것으로 예상됐다.  다시 말해, 무언가를 만드는 비용은 낮아지고 있다. 이제 더 희소한 자원은 검토, 검증, 이해, 유지보수다. 생성 속도는 통제 속도보다 훨씬 빠르게 높아졌다. 그 결과 신뢰와 검증 사이에 간극이 생겼다. 우리가 대화한 많은 사람은 여전히 AI 코드에 어느 정도 불신을 드러낸다. 그러나 그 불신을 검증 절차에 일관되게 반영하는 사람은 그보다 적어 보인다.  이는 위험한 상황이다. AI 코드가 신뢰할 만한지 더 저렴하고 명확하게 검증할 방법이 필요하다. 깃랩(GitLab)의 2026년 6월 보고서를 보면 거버넌스에 관한 질문이 달라졌음을 알 수 있다. [깃랩의 2026년 6월 AI 책임성 연구](https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx)에 따르면, 현재 AI를 사용할 때 발생하는 병목은 검토와 검증이다. 더욱 우려스러운 점은 대개 코드를 만든 뒤에야 거버넌스가 작동한다는 것이다. 이때는 이미 위험을 받아들였고 소유권에 대한 통제도 잃은 뒤다. 이제 문제는 단순한 통제에 그치지 않는다. 시스템에 어떤 제약을 설정할 것인지, 증거로 작업을 어떻게 검사할 것인지, 팀에 어떻게 책임을 물을 것인지가 중요하다. AI 수명 주기의 각 부분을 누가 책임질지도 정해야 한다.  이 논의에서 마지막으로 구분할 것은 프로세스와 품질이다. 품질은 **역압(backpressure)**이라는 개념이다. 이는 말 그대로다. **에이전트가 행사할 수 있는 최대한의 자율성을 부여해서는 안 된다.** 에이전트를 중단하고 조절하며, 작업을 검사하고, 인간성을 지킬 수 있을 만큼 충분한 역압을 유지해야 한다. 그러면서도 작업에 필요한 만큼의 자율성만 부여해야 한다. 일반적인 엔지니어링에는 작업이 올바른 방향으로 진행되는지를 보여주는 수많은 신호가 있다. 타입 검사, 테스트, 훅, 샌드박스 제한, 감사 로그, 모니터가 그 예다. 엔지니어링 시스템은 이런 신호로 가득하며, 시스템이 정직하게 작동하도록 충분한 역압을 제공하게끔 설계돼 있다. 따라서 에이전트가 이와 같은 신호를 내보내기만 한다면, 기존 엔지니어링 체계가 적절한 역압을 제공하리라고 믿어도 된다. **시스템을 신뢰한다고 해서 루프에 인간이 필요 없다는 뜻은 아니다.** 다만 인간이 내부 루프에 들어갈 필요가 없다는 뜻이다. 인간은 **제약 루프(constraints loop)**에 있어야 한다. 어떤 입력, 아키텍처, 지침, 불변 조건을 설정할 것인가? 또한 **표본 추출 루프(sampling loop)**에도 있어야 한다. 결과물 중 얼마를 표본으로 뽑아 검토할 것인가? **감사 루프(audit loop)**에서는 어떤 증거를 보관하고 감사 로그가 효과적으로 작동하는지 어떻게 확인할지를 판단해야 한다. **소유권 루프(ownership loop)**에서는 운영 경계의 어느 부분을 책임질지 결정해야 한다. 그러나 인간이 내부 루프에 있을 필요는 없다. 에이전트는 당신이 검토할 수 있는 것보다 더 많은 결과물을 내놓을 수 있다.  희소한 자원은 로그나 테스트 같은 품질 신호를 토대로 내리는 인간 고유의 판단이다. 2026년 6월 AI 보고서에 따르면 실험 환경에서는 수 시간 단위로 지속되는 에이전트형 위임이 사실상 실현됐다. [오픈AI가 올해 발표한 에이전트와 일의 미래에 관한 연구](https://openai.com/index/how-agents-are-transforming-work/)는 이러한 아이디어를 얻는 데 훌륭한 자료였다. 시스템이 우리가 검토할 수 있는 양보다 더 많은 결과물을 내놓기 시작했으므로, 이제 이러한 책임 경계를 어떻게 세울지 고민해야 한다.  바로 이 지점에서 설명 책임이 중요해진다. 장시간 작동하는 에이전트가 수 시간에 걸쳐 내리는 것은 결국 ‘결정’이다. 그리고 모든 결정이 기록되지는 않는다. 모든 결정을 입력 토큰까지 거슬러 올라가 추적할 수도 없다. 당면한 문제에 대해 에이전트가 내놓은 결과가 옳다고 믿기만 한다면, 그 결과에 이르는 결정의 사슬을 재구성해야 할 때 수백 시간, 심지어 수천 시간에 이르는 인간의 노동이 필요해진다. 사실상 불가능한 일이다. 그러므로 다시 한번 강조하지만, **설명 책임은 시스템 설계의 핵심 요소가 되어야 한다.** ## **숨겨진 비용 세 가지(Three hidden costs)** 숨겨진 비용은 세 가지다. **인지적 항복(cognitive surrender) ~ AI가 내놓은 결과를 맹목적으로 받아들이는 것.** 에이전트에게 작업을 위임하면 결과물이 에이전트의 작업처럼 보일 수 있다. 그러나 실제로는 당신의 작업이다. 당신의 평판이 걸려 있고 당신에게 책임이 있다. 결과물의 결함으로 피해를 보는 것도 당신의 소프트웨어다. 그 결과물을 반영하도록 수정해야 하는 것 역시 당신의 소프트웨어다. 따라서 에이전트의 결과는 곧 당신의 답이 되고, 거기에는 모든 책임이 따라온다. 이를 종합한 [와튼의 연구](https://executiveeducation.wharton.upenn.edu/thought-leadership/wharton-at-work/2026/05/thinking-fast-slow-and-artificially/)를 보면 AI가 옳을 때는 안심할 만하다. 그러나 AI가 틀렸을 때는 상황이 좋지 않다. AI가 틀렸는데도 거의 4분의 3에 이르는 사람들이 그 답을 그대로 받아들였다. 심지어 AI가 없었을 때보다 자신의 판단을 더 확신했다.  **인지 부채(cognitive debt) ~ 문제 해결 방법에 관한 이해와 기억이 약화되는 것.** 에이전트에게 작업을 위임하면 사고 과정 전체를 에이전트에 떠넘기게 된다. 모든 것을 직접 생각하려면 시간과 에너지가 든다. 방대한 코드베이스를 이해하며 사고하려면 더 많은 자원이 필요하다. 학습 곡선을 따라가기도 벅찬 상황에서는 그런 자원을 마련하기 어렵다. 결국 에이전트가 내놓은 결과는 자신이 직접 도달할 수 없는 수준인 경우가 많다. 에이전트가 계획하고 작업하는 시간이 길어질수록 에이전트가 만든 코드와 그 코드에 대한 자신의 이해 사이의 간극도 커진다. 간극은 복리처럼 불어나고 부채는 쌓인다. 학습 곡선을 따라잡는 비용은 거의 기하급수적으로 증가한다. [앤트로픽의 무작위 대조 시험](https://www.anthropic.com/research/AI-assistance-coding-skills)은 AI에 의존해 코드를 작성한 엔지니어가 직접 코드를 작성한 엔지니어만큼 그 코드를 잘 이해하는지 조사했다. 결론은 암울했다. 이해도 퀴즈에서 AI를 활용한 엔지니어는 그렇지 않은 엔지니어보다 17%포인트 낮은 점수를 받았다. 각각 50%와 67%였다.  그리고 **오케스트레이션 비용(orchestration tax)**도 있다. 이제 수많은 에이전트를 손쉽게 가동할 수 있지만, 인간의 인지 대역폭은 같은 방식으로 병렬화되지 않는다. 에이전트가 최악의 행동을 하지 않도록 방향을 잡고, 에이전트가 만든 결과물 가운데 주의 깊게 봐야 할 것을 가려내야 한다. 원하는 작업에 먼저 집중하도록 지시하고, 에이전트를 실행하기 전에 가장 중요한 제약과 가장 위험한 가정을 검증해야 한다. 이 모든 일에는 노력이 들며 자동화할 수도 없다. 인간의 판단을 대신할 것은 없다.  기존 시스템을 개량하는 브라운필드 환경은 특히 위험하다. 감사해야 할 시스템의 동작이 코드에만 들어 있지 않기 때문이다. 그 동작은 시스템이 남긴 상처 속에 존재한다. 해결책은 무엇일까? 아키텍처를 결정할 때 인간의 주의력을 최우선으로 삼아라. 워크트리, 범위, 증거를 이용해 초기 계획과 그 계획에서 파생되는 작업 사이의 결합도를 낮춰라. 실행할 수 없는 단계를 해결하는 데 들이는 시간에는 제한을 두어라. 그리고 소프트웨어 변경은 반드시 명시적으로 허용한 경우에만 가능하게 하라. **알파, 쇠퇴, 안목(Alpha, decay, and taste): 분야를 막론하고 경력과 성과를 좌우하는 세 가지 핵심 패턴이다.**  알파는 가장 가치가 큰 수를 두는 경쟁에서 최고 성취자가 앞서 나가는 부분이다. 쇠퇴는 누구나 반복과 관찰을 통해 익히는 확립된 패턴이다. 원한다면 정체 구간이라고 불러도 된다. 안목은 알파에서 누군가 앞서기 시작하거나 기존 패턴이 쇠퇴하기 시작하는 순간을 가장 먼저 감지하는 능력이다. 무언가 일어나고 있다는 증거가 나타나기 전에 앞으로 무엇이 올지 판단하는 것이다. [폴 그레이엄의 요점](https://paulgraham.com/taste.html)은 누구나 무엇이든 만들 수 있게 되면 ‘무엇을 만들지’ 선택하는 일이 더욱 중요해진다는 것이다. [미첼 하시모토의 정의](https://x.com/mitchellh/article/2070665127331037290)는 이를 실무적으로 설명한다. 아직 객관적인 지표가 없는 상황에서 수준 높은 정성적 판단을 내리는 능력이다. 이제부터는 안목이 모든 것을 좌우한다. 알파의 변화는 안목의 변화다. 기존의 쇠퇴 패턴이 사라지는 이유는 우리가 다른 무언가를 감지하기 시작했기 때문이다.  다음 단계는 무엇인가? 자신의 안목을 실무에 적용하라. 어떻게 해야 할까? 본능의 영역에서 의식의 영역으로 옮기려는 것이 무엇인지 드러나는 이름을 붙여라. 비평과 사례를 통해 연습하라. 판단의 근거를 명시하라.  그리고 자신의 산업에서 가장 오래 지속되는 경쟁 우위를 제공하는 방향으로 계속 나아가라. 그것이 무엇인가? 단순히 작업을 수행하는 데 그치지 마라. 작업 방법을 가르치고, 체계화하고, 언제 수행해야 할지 결정하며, 결과를 책임지는 단계까지 경쟁 우위의 경계를 끌어올려라.  이제 모두가 개발자지만, 모두가 엔지니어인 것은 아니다. 개발자가 더욱 엄격한 업무 규율을 받아들일 때 엔지니어가 된다. 철저하고 논리적으로 타당한 추론, 제약과 절충안에 대한 고려, 위험과 노출 가능성에 대한 인식, 실질적인 책임성이 그 규율에 포함된다.  미래에는 사람들이 엔지니어링의 행정 업무에서 벗어나고, 엔지니어링의 요구 수준이 높아지면서 등장하는 새로운 역할을 맡게 될 것이다. 장인 정신에서 역할을 분리하되 각자가 무엇을 하는지는 명확히 드러나는 역할이다. 프로토타입을 만드는 사람, 구축하는 사람, 정리하는 사람, 성장시키는 사람, 유지보수하는 사람이 있을 것이다.  인간은 반대 방향에서도 시스템의 경계를 지킨다. 가치 있는 일을 선택하고, 그 일을 수행할 제약을 정의하고, 증거가 진행하기에 충분한지 결정하며, 결과를 보살핌으로써 알파를 높인다. 팀이 하나든 백 개든, 이 경계는 인간만이 지킬 수 있다. **책임성이 공장을 확장한다.** 주의력과 안목처럼 책임성 역시 모든 것을 작동하게 하는 세 가지 이중성 가운데 하나다. **책임성이 없으면 규칙도 없다.** 질문하는 사람들과 씨름할 일도, 절충안도, 위험도, 안전망도 없다. 결정의 결과를 책임지는 사람이 없다면 높은 주도성은 혼란만 가져온다.  경쟁 우위의 반감기는 한 번의 릴리스에 불과하지만, 서명의 반감기는 경력 전체에 걸쳐 이어진다. 서명이란 출시된 결과물을 자신 있게 지지할 수 있도록 작업에 자신의 이름을 거는 것이다. 기술은 지렛대 효과를 제공하고, 책임성은 그 지렛대 효과를 신뢰로 바꾼다.  선택할 수 있는 것은 인간뿐이다. 결과를 감당하는 것도 인간뿐이다. 정책의 테두리 안에서 안전하게 선택하고, 전달하고, 병합하고, 상부로 보고하도록 에이전트에 요구할 수는 있다. 그러나 에이전트가 그 결과를 감당할 수는 없다.  모든 코드베이스에는 일종의 책임 계약이 필요할지 모른다. 변경을 받아들일 때 어떤 점검 목록을 이해했는지, 결정에 어떤 증거가 쓰였는지, 변경을 누가 책임졌는지, 변경이 차단된 뒤 시스템 상태가 어떠했는지를 명시하는 계약이다. 다음과 같은 요소를 담아야 한다. * 주의력과 안목 * 증거, 판정, 소유권 * 알파, 쇠퇴, 안목 ## **높은 주도성(High agency)** 일반적인 에이전트형 워크플로에서 **높은 주도성이란 언제 위임하고, 언제 검사하고, 언제 중단하며, 언제 프로세스의 결과를 책임져야 하는지를 아는 기술이다.** 주도성의 사다리는 낮은 단계에서 높은 단계로 이어진다. 잠재적인 문제를 알리고, 조사하고, 대응 작업을 실행하고, 진단하고, 해결책을 제안하고, 수정 방법을 권고하고, 문제를 해결하는 순서다. 주도성 사다리의 높은 단계에는 분별력도 있다. 문제를 찾았지만 고칠 가치가 없다고 판단하고 다음으로 넘어가는 능력이다.  ## **소프트웨어 공장을 지탱하는 12개의 기둥(The 12 pillars that hold up the software factory)** 규모 확장을 목표로 하는 공장에는 브라운필드가 최전선이다. 영리하고 작은 혁신들은 아직 대단해 보이지 않을 수 있지만, 운영 환경은 훨씬 복잡하다. 완전히 새로운 시스템을 구축할 때는 모든 것을 통제할 수 있으므로 충분한 역압 메커니즘을 계획하고 구현하기가 훨씬 쉽다. 그러나 레거시 시스템에 지능형 에이전트를 추가하는 일은 완전히 다른 문제다. 레거시 시스템에는 운영 환경에서 나타나는 모든 동작, 고객이 미래에 기대하는 사항, 마이그레이션 이력, 릴리스 및 예산 주기의 길이, 암묵적인 가정, 극단적인 사례, 데이터의 이상 현상, 런북 절차, 시스템을 돌보려는 의지가 부족한 동안 누적된 온갖 상처가 포함돼 있다. 브라운필드를 관리하려면 지속 가능한 엔지니어링이 필요하다. 암묵적 지식을 명시적 제약으로 바꾸고, 여러 팀과 세대에 걸쳐 그 지식의 일관성을 유지해야 한다. 지식을 테스트 절차와 기능 명세로 공식화하고 객관적인 증거와 연결해야 한다. 동시에 실패할 때마다 더 많은 학습을 얻도록 체계를 개선해야 한다. 시스템이 지금까지 받아온 수준의 관리를 더 이상 받지 못하면 모든 것이 무너질 수 있기 때문이다. ## **새로운 일도 진정한 일이다(New work is real work)** **규모를 확장할수록 일은 더 흥미로워진다. 다른 모든 것이 구축되고 나면 사람들은 새로운 것을 만들고 싶어 하기 때문이다.** 장인으로 일하며 키운 알파와 안목을 활용해 소프트웨어 공장에 접목할 새로운 루프를 설계하려 할 것이다. 또는 소프트웨어 공장의 모든 지식을 하나의 우아하고 선의에 충실하며 원칙적인 시도에 담은 그린필드 시스템을 구축하고 싶어 할 수도 있다. 새로운 시스템을 검증할 수 있는 수준의 새로운 증거 형식을 설계하려 할 것이다. 이제는 너무 복잡해져서 전담 관리가 필요한 브라운필드 시스템을 돌보려 할 수도 있다. 새로운 역압 메커니즘을 설계하고 관리하며, 새로운 에이전트를 설계하고, 주도성을 구축하려 할 것이다.  그 과정에서 사람들은 이 모든 것이 진정한 일이라는 사실을 깨닫게 될 것이다. 이는 좋은 일이다. 자동화는 병목을 만든다. 책임질 가치가 있는 운영상의 병목이다. 자동화를 통해 산업적 규모를 통제할 수 있기 때문이다. 그러나 산업적 규모가 새로운 병목을 낳기도 한다. **병목은 “우리가 이것을 만들 수 있는가?”에서 “이것이 존재해야 하는가? 우리가 이를 책임지고 설명할 수 있는가?”로 옮겨간다.** 내가 제안하는 것은 에이전트 엔지니어링을 확장하기 위한 실용적인 운영 모델이다. 여기에는 내부 루프와 외부 루프가 있다. 내부 루프는 실제 작업이 수행되는 곳이다. 각 루프는 최대한 독립적으로 작동하도록 설계한다. **모든 품질 보증과 검증을 루프 안에 배치하라. 루프 자체를 설계하고 검증한 뒤에는 역압 메커니즘을 마련해 자율성을 부여하면 된다. 이 메커니즘은 루프의 실행 속도와 작업 범위를 통제해야 한다. 그리고 인간을 올바른 자리에 배치해 올바른 결정을 맡겨라.** 이해를 단순한 인계 절차나 출시 관문으로 취급하지 마라. 인간이 통찰력을 발휘할 준비를 갖춘 의사 결정 지점으로 다뤄야 한다. 또한 만들어져 운영 환경에 다시 투입되고 새로운 팀과 엔지니어에게 전달되는 모든 산출물은 이전보다 더 나은 상태로 남겨라. **공장을 구축하라. 계속 가동하라. 작업을 이해할 수 있고, 검증할 수 있으며, 책임 소재가 분명하게 만들어라.** 에이전트가 코드를 작성할 수는 있다. 그러나 그 코드가 사용자에게 전달되기 전에 누군가는 왜 그것이 존재해야 하는지, 왜 운영 환경의 일부가 되기에 충분히 안전한지, 잘못됐을 때 무엇을 할지를 설명해야 한다. 이것이 외부 루프에서 수행하는 에이전트 엔지니어링이다. 이것이 지금 우리가 해야 할 일이다.