코딩 에이전트는 AI 워크플로우의 내부 구조(plumbing)를 작성해서는 안 된다. 워크플로우 자체를 작성해야 한다.

원래 Medium에 게시되었습니다.

AI 피로감(AI fatigue)은 현실입니다. 새로운 기술들은 항상 개발자들을 끌어당겨 왔습니다. Ruby on Rails, Go, Rust: 우리는 간단한 "Hello World"를 작성하고 잠시 가지고 놀다가 몇 달 또는 몇 년에 걸쳐 그것이 실제로 무엇에 좋은지 결정했습니다. AI의 경우, 그 주기가 며칠로 줄었습니다. 거의 매주 새로운 프레임워크나 무언가를 하는 새로운 방식이 생겨나고 있고, 따라가기란 너무 지치는 일 때문에 많은 개발자들이 시도하는 것을 그만두고 있습니다.

생성형 AI(Generative AI)는 전통적인 프로그래밍이 가졌던 것이 아닌 무언가, 즉 추론 능력을 가져왔습니다. 삶은 결코 직선적이지 않으며, 머신러닝(machine learning)의 아름다움은 그것이 삶의 규칙들이 미리 작성되어 있다고 가정하지 않는다는 것입니다. 우리 자신의 규칙들도 마찬가지입니다. 그것들은 역사와 관행에서 비롯되며, 우리의 뇌에 새겨진 조상의 신경 패턴이며, 때때로 재해석됩니다. AI는 이 축적된 인간 지식이 코드로화되어 지금까지 사람들의 연결고리가 필요했던 워크플로우를 자동화할 수 있다는 희미한 빛, 희망을 우리에게 제공합니다.

하지만 자세히 살펴보면, 우리가 그것으로 만들고 있는 대부분의 것은 같은 것입니다. 그러한 워크플로우들은 그래프입니다. 코딩 에이전트(coding agents), 지원 봇(support bots), OpenClaw와 같은 개인 비서 모두 그 형태를 따릅니다. 인간의 워크플로우는 에이전트들의 네트워크로 대체됩니다.

상용화되는 것은 그러한 그래프를 구축하기 위한 프레임워크입니다. LangChain과 Spring AI가 이를 개척했으며, 저는 두 가지 모두에게 깊은 존경심을 가지고 있습니다. 저희 회사에서는 LangChain과 LangGraph를 사용해 왔고, 이에 대해 잘 알게 되었습니다. LangChain이 '배터리 포함(batteries included)' 에이전트 하니스인 Deep Agents를 소개했을 때, 저는 그것이 근본적으로 더 주관적이고 표준화된 그래프라는 것을 깨달았습니다. CrewAI, n8n 등 나머지 도구들은 워크플로우가 어떻게 구축되어야 하는지에 대해 각자의 의견을 제시합니다. 업계 전반적으로 우리는 올바른 추상화(abstraction)를 찾는 초기 단계에 있습니다.

한편, 이 작업은 여러 번의 변환 과정을 거칩니다. 우리는 워크플로우를 구상하고, 그것을 코딩 에이전트에게 영어로 설명하면, 에이전트는 우리가 구상한 대로 작동하는지 확인하기 위해 검토해야 하는 Python이나 Java 코드를 작성합니다. 그 과정에서 우리는 프레임워크 용어로 어려운 질문들에 답해야 합니다: 노드(node)는 무엇이어야 하는가, 에이전트(agent)는 무엇이어야 하는가, 사람에게 언제 요청해야 하는가, 자동화하기에 안전한 수준은 어느 정도인가. 개발자들이 프레임워크를 포기하고 직접 루프(loop)를 구현하는 것이 놀랍지 않습니다.

꼭 이런 방식으로 작동할 필요는 없습니다. 만약 코딩 에이전트가 구현 자체를 작성하지 않는다면 어떨까요? 만약 그것이 우리가 1분 안에 읽고 그래프로 볼 수 있는 언어로 워크플로우 자체를 작성하고, 프레임워크가 그것을 실행되는 시스템으로 변환한다면 어떨까요? 사용자가 무엇이 워크플로우인지, 그리고 그것이 무엇을 보장해야 하는지 결정하고, 생성된 복잡한 연결 구조(plumbing) 페이지들을 검토하는 것을 멈출 수 있습니다.

그러니 네, 이것은 또 다른 도구입니다. 하지만 그래프를 연결하는 또 다른 방식은 아닙니다. 아예 연결 자체를 작성하지 않게 만드는 방법입니다.

Loom 재소개

저는 이전에 Loom의 설계에 대해 글을 쓴 적이 있습니다 올해 초. 그 글은 컴파일러 측면의 이야기를 다룹니다. 그때 이후로 Loom은 보안 감사(security audit), 평가 하니스(eval harness), 작업(tasks) 및 CLI를 갖추게 되었습니다. 이번 내용은 개발자 경험에 관한 것입니다.

예를 들어, 제가 Ubuntu 노트북에서 문제를 설명하면 워크플로우가 웹에서 이를 조사하고 수정 스크립트를 작성하는 자동화된 워크플로우를 원한다고 가정해 봅시다. 이 내용을 코딩 에이전트에게 영어로 설명하면, Loom 가이드 스킬을 사용하여 다음과 같이 초안을 작성합니다 (자세한 내용은 마지막에 설명).

// laptop-doctor: 영어로 노트북 문제를 설명하세요. 에이전트가 진단하고 조사하며, 다른 에이전트가 수정 스크립트를 작성합니다. 데이터 삭제를 시도하는 것은 코드 검사 블록에서 막고, 두 번 승인해야만 스크립트가 실행됩니다.

...

VS Code 확장은 타이핑할 때 유효성을 검사하고 에디터 옆에 에이전트의 네트워크를 그립니다:

각 줄이 제공하는 기능은 다음과 같습니다:

budget { tokens: 400000  calls: 60 }

이는 한 번의 실행이 사용할 수 있는 최대치를 나타내는 하드 상한선입니다. 나중에 확인하는 대시보드가 아닙니다. 할당량이 소진되면 실행이 중지됩니다. 동일한 제한은 단일 에이전트나 단일 단계에 적용될 수 있습니다.

tool Inspect { use: shell  allow: "df, free, uptime, ..." }

이는 에이전트에게 쉘(shell)을 제공하지만, 사용자가 나열한 명령어에 대해서만 가능하며, 이 모든 것은 변경하기보다는 보기 위한 것입니다. 각 호출은 20초의 제한 시간이 있습니다. 목록에 있는 어떤 것도 기계를 수정할 수 없기 때문에, 에이전트는 매번 사용자에게 요청하지 않고도 이를 사용할 수 있습니다.

tools: [Inspect]

그리고

tools: [web_search]

은 누가 무엇을 할 수 있는지 결정합니다. 진단가(Diagnostician)와 복구자(Remediator)는 기계를 볼 수 있습니다. 연구원(Researcher)과 스크립트 작성자(ScriptAuthor)는 웹을 검색할 수 있습니다. 어떤 에이전트도 둘 다 가질 수 없으며, 그들 중 어느 누구도 수정 작업을 실행할 수는 없습니다.

guard { pii: mask }

은 보이는 것보다 더 중요합니다. 시스템 로그에는 사용자 이름, 이메일 주소, IP 주소가 가득합니다. 무언가가 모델에 도달하기 전에 이들은 플레이스홀더로 대체됩니다.

loop until (research_result.verdict == "ENOUGH") max 4 

Researcher가 진단사(Diagnostician)에게 더 많은 증거를 요청하며 되돌려 보내게 하고, 최대 세 번까지 반복할 수 있습니다. 이 루프는 통제 불능 상태가 될 수 없으며, 에이전트들이 언제 멈출지 결정하지 않습니다. 스크립트가 결정합니다.

expecting { verdict: enum["ENOUGH", "NEED_MORE"], ... }

은 각 답변이 고정된 형태로 도착하도록 만들어 다음 단계가 자유 형식의 텍스트를 추측하는 대신, verdict 또는 has_script에 따라 분기하게 합니다. ScriptAuthor가 안전한 수정 사항을 찾지 못하면, 다음과 같이 알립니다.

has_script: "NO"

그리고 워크플로우는 임의로 만드는 대신 정직하게 멈춥니다.

run ValidateScript(...)

이것이 핵심입니다. 이것은 모델이 아니라 Java 코드입니다. 모델이 스크립트를 작성하고, 코드가 그것이 안전한지 결정합니다. 차단된 스크립트는 이유와 함께 저자에게 최대 두 번까지 되돌아갑니다. 확인할 수 없는 경우, 그렇게 알리고 사용자 승인 프롬프트가 명확하게 알려줍니다. 동일한 입력에 대해 동일한 답변을 얻고 토큰은 소모되지 않으며, 로그 파일의 기발한 문구로도 내용을 바꿀 수 없습니다.

human_prompt

먼저 스크립트를 읽고 승인합니다. 그런 다음 저장되고, 지금 실행할지 아니면 나중에 보관할지 다시 묻습니다. 콘솔에 아무도 없으면, 스레드를 점유하지 않고 워크플로우가 일시 중지되었다가 답변이 도착하면 이미 수행된 작업을 반복하지 않고 재개됩니다.

run RunScript(path = ..., sha256 = ...)

은 승인한 파일만 실행하며, 무결성 검사(checksum)를 거치므로 중간에 다른 것으로 교체될 수 없습니다. 최대 2분 동안 진행됩니다. 결과는 즉시 표시되므로, 비용 제한이 Remediator의 보고서를 중단시키더라도 무슨 일이 일어났는지 여전히 볼 수 있습니다.

스크립트 주변에는 직접 작성할 필요가 없었던 더 많은 것들이 있습니다: 이 파일을 읽고 신뢰할 수 없는 텍스트를 읽거나, 사설 데이터에 접근하거나, 행동할 수 있는 에이전트를 플래그하는 보안 감사(security audit); 자체 예시로 테스트하기 위한 평가 하네스(evaluation harness); 중단된 실행을 처음부터 다시 시작하는 대신 재개할 수 있게 하는 저널(journal); 스크립트에서 직접 그려진 워크플로우 그래프; 그리고 코딩 에이전트가 같은 방식으로 구축하도록 따를 수 있는 가이드입니다.

Loom의 핵심은 바로 여기에 있습니다. 워크플로우 자체가 흥미로운 부분이므로, 나머지 모든 것은 그 안에 내장되어 있습니다.

하나의 도구로 두 가지 방식으로 접근: 명령줄(command line)과 VS Code

Loom은 단일 jar 파일, weave 명령줄, 그리고 이를 담고 있는 VS Code 확장의 형태로 배포됩니다. 별도로 서버를 구축하거나 로그인할 플랫폼이 필요하지 않습니다.

명령줄은 터미널에서 작업하는 방식이자 파이프라인이 워크플로우와 상호작용하는 방식을 보여줍니다:

weave check laptop-doctor.loom # 모든 문제점을 라인별로 확인 (실행하거나 비용을 지불하지 않음) weave graph laptop-doctor.loom --format mermaid # 워크플로우를 다이어그램으로 생성 weave explain laptop-doctor.loom # 스크립트를 일반 영어로 설명해 줌 weave audit laptop-doctor.loom # 보안 검토; 높은 취약점이 발견되면 1을 반환하며 종료 weave run laptop-doctor.loom --max-tokens 50000 # 제한을 두고 실행 weave package laptop-doctor.loom --fat # 독립적인 jar 파일로 패키징 weave next # 이 프로젝트에서 다음에 할 일

이 명령어들은 CI(Continuous Integration)가 기대하는 코드로 종료됩니다.

VS Code 확장은 대부분의 작문 작업이 이루어지는 곳입니다: 구문 강조 표시, 저장할 때 밑줄로 표시되는 문제점들, 워크플로우 개요, 일반적인 문장을 확장해 주는 스니펫(snippets), 커서가 따라가는 실시간 그래프, 원클릭 실행 기능, 그리고 한 명령어만 떨어져 있는 가이드.

프로젝트와 파일은 동일하며, 어떤 방식으로 접근하든 같습니다. CI의 터미널에서 확인하고, 에디터에서 빌드할 수 있으며, 두 방식 사이를 번역할 필요가 없습니다.

개인 데이터 및 보호 장치(guardrails)를 한 줄에 담아

노트북의 로그는 생각보다 많은 것을 알려줍니다. 사용자의 사용자 이름, 이메일 주소, 연결한 IP 주소 등이 포함됩니다. laptop-doctor가 모델이 이러한 정보 중 어떤 것을 읽을 수 있게 할지 결정하기 전에, 핵심 질문은 '모델에게 무엇을 보여줄 것인가'입니다. Loom에서는 이것이 에이전트의 속성(property)이며, 해당 모델 옆에 작성됩니다:

agent Diagnostician { model:

마스크(mask): 모델에 도달하기 전에 이메일, 전화번호, 사회보장번호, 카드 번호 및 IP 주소는 [EMAIL]과 같은 자리 표시자로 처리됩니다. 이는 작업, 컨텍스트, 에이전트의 메모리, 그리고 도구의 결과를 모두 포함하므로, `journalctl`이 출력하는 모든 내용은 진단가(Diagnostician)가 보기 전에 마스크 처리됩니다. 답변을 저장하기 전에도 마스크 처리가 되기 때문에, 연구원(Researcher)이 웹에 가져가는 증거에는 당신의 흔적이 전혀 남지 않습니다.

블록(block): 작업이나 답변에 개인 데이터가 포함되면 단계가 실패하고, 오류는 값 자체를 기록하는 것이 아니라 어떤 종류의 데이터인지 명시합니다.

경고(warn): 발견된 내용을 기록하고 계속 진행합니다.

편향(bias): warn 또는 bias: block은 기본적으로 간단한 규칙이나 사용자가 지정한 심사 모델을 사용하여 답변에 편향이 있는지 확인합니다.

워크플로우의 일부만 보호하고 싶다면? 해당 단계를 가드레일(guardrail)로 감싸고, 위반될 경우 어떤 일이 발생하는지 명시할 수 있습니다:

`guardrail (PII) {   delegate "Problem: {laptop_issue}\nEvidence:\n{evidence_text}" to Researcher -> research_result   } on_violation {   note "개인 데이터가 연구 단계에 도달했습니다. 검색이 이루어지기 전에 중단되었습니다."   }`

감사 추적(audit trail)도 같은 규칙을 따릅니다: 데이터 자체가 아니라 개수와 종류만 기록합니다. API 키, 웹훅 URL 및 비밀번호와 같은 비밀 정보는 스크립트에 절대로 작성될 수 없습니다. 이들은 환경 변수나 시크릿 스토어에서 오며, 결과, 오류, 추적(trace), 로그에서 제거됩니다.

CI에 통합되는 보안 검토가 필요합니다. 내장 감사 기능은 워크플로우를 실행하지 않고 읽어 각 에이전트가 무엇을 건드릴 수 있는지 보여줍니다. 이 기능은 에이전트에게 가장 중요한 질문을 던집니다. 즉, 단일 에이전트가 신뢰할 수 없는 콘텐츠를 읽거나, 개인 데이터에 접근하고, 전송하거나 행동할 방법이 있는가? 이러한 조합이 [Simon Willison의 치명적인 삼중주(lethal trifecta)](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)이며, 로그 파일이나 웹 페이지에 숨겨진 지침이 유출이나 유해한 행동으로 변하는 방식입니다. Loom은 이를 승인되지 않은 부작용, 누락된 예산, 또는 보호 장치가 없는 개인 데이터와 함께 플래그 지정합니다. 모든 발견 사항은 OWASP Top 10 for LLM 애플리케이션에 매핑되며 무엇을 변경해야 하는지 알려줍니다.

[![weave audit report](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fg1ry3qzgkd0lkms1bsfe.png)](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fg1ry3qzgkd0lkms1bsfe.png)

laptop-doctor에서는 기계를 살펴보는 에이전트는 웹 검색을 할 수 없고, 검색하는 에이전트가 기계에 접근할 수 없으며, 그 어느 것도 수정(fix)을 실행할 수 없습니다. 항상 발생해야 하는 단계들은 프롬프트 자체가 아닙니다. 그것은 코드입니다. 다음 내용입니다.

**직접 도구를 작성하고, 필수 단계를 건너뛸 수 없게 만드세요**

실제 워크플로우는 무언가를 해야 합니다: 시스템을 살펴보고, 내부 API를 호출하며, 스크립트를 실행합니다. Loom은 이에 대해 명확하게 생각할 방법을 제공합니다.