에이전트에게 가장 하기 싫은 지시 중 하나는 “다른 저장소에서 이미 해결한 문제니 파일을 찾아 여기서 비슷하게 처리해 달라”는 말이다. 기능은 이미 있지만 다른 스크립트와 가정 속에 흩어져 있다. 결국 직접 찾아서 공유할 파일을 고르고, 이미 만든 것을 에이전트가 다시 구성하도록 도와야 한다.

AI 덕분에 재구성이 훨씬 쉬워졌다. 하지만 애초에 다시 구성할 필요가 없었으면 한다.

내가 Swamp를 가장 좋아하는 이유도 여기에 있다. 에이전트가 복사할 코드가 아니라, 새 해결책을 조합하는 데 쓸 수 있는 재사용 가능한 작업을 제공한다.

행동 중심 설계가 바꾸는 것

AI가 빠르게 발전하는 시기에 일할 수 있어 감사하다. AI가 내 업무에서 차지하는 비중은 줄어들기보다 커질 것이라고 본다. 다만 에이전트가 전체 절차를 맡아야 한다고 가정하기보다, 필요한 행동부터 정하고 싶다.

에이전트 중심 흐름에서는 모델이 목표를 받고 도구를 선택한 뒤, 결과를 읽고 다음 행동을 결정한다. 낯선 문제를 탐색할 때는 이런 유연성이 유용하다. 절차가 이미 정해진 일에서는 모델에게 이미 코드로 정할 수 있는 결정을 반복해서 맡기게 된다.

행동 중심 설계에서는 작업을 재사용 단위로 삼는다. 작업이 무엇을 입력받고, 무엇을 하며, 어떤 결과를 내는지 정한다. 그런 작업을 조합해 순서와 조건, 실패 처리를 담당하는 워크플로를 구성한다. 워크플로 안에서 모델이 요청을 해석하거나 검토 의견을 판단할 수 있지만, 주변 절차 전체를 조율할 필요는 없다.

Swamp에서는 이런 작업을 타입이 지정된 모델의 메서드로 정의한다. 입력과 출력은 검증하고, 데이터는 버전 관리하며, 자격 증명은 볼트(vault)를 통해 참조한다. 워크플로는 메서드를 연결하고 결과를 다음 단계로 전달한다. 여기에는 내 흩어진 스크립트에 빠져 있던 공통 구조가 있다.

AI는 여기서 두 가지 역할을 한다. 행동을 만들고 유지하는 일을 돕고, 실행 중에는 특정한 추론 작업을 맡는다. 이는 열린 형태의 에이전트를 스크립트로 감싼 것과 다르다. 워크플로가 지능을 언제 호출할지, 그 답으로 무엇을 할 수 있는지를 통제한다.

하나의 기능을 여러 곳에서 활용하기

반복 가능한 도구로 에이전트 다루기에서 풀 리퀘스트(PR) 묶음을 관리하는 반복 업무를 소개했다. 실패한 CI를 찾고, 코드에 비춰 검토 의견을 평가하며, 수정안이나 답변을 준비하는 일이다.

이제 예약된 메서드가 기록된 PR·CI·티켓 상태를 갱신한다. 코드가 조치가 필요한 피드백을 고르고, 범위가 제한된 에이전트가 소스 코드를 참고해 의견을 평가하고 제안을 준비한다. 답변 게시나 변경 적용은 별도의 작업이다.

한 검토 의견에서 불일치가 드러났다. 프로젝트의 이미지 개수에는 협업자의 사진이 포함됐지만, 사진 선택 로직은 회사 소유 사진만 허용했다. 제안된 수정안은 프로젝트를 선택하기 전에 조건에 맞는 이미지 개수를 확인했다. 이 불일치를 파악하는 일은 모델이 맡기 좋은 작업이다. GitHub를 확인할 시점인지 결정하는 일은 그렇지 않다.

내 소프트웨어 팩토리는 이 구분을 구체적으로 보여준다. 에이전트는 변경 사항의 계획·구현·검토를 돕는다. 실행 시점의 메서드는 선언된 검사를 수행하고 근거가 통과했는지, 실패했는지, 없는지를 기록한다. 에이전트는 실패한 테스트를 진단할 수 있지만 테스트 실행 방법을 매번 다시 찾아낼 필요는 없다. 에이전트의 확신은 테스트 결과가 아니다.

이런 행동은 소프트웨어 팩토리 바깥에서도 쓸 수 있다. 내 cli-agent 확장은 PR 의견 분류와 CI 복구뿐 아니라 팩토리에서도 사용한다. 팩토리의 작업 트리 작업은 PR 대시보드의 수정 경로도 지원한다. 재사용하는 것은 코드만이 아니다. 입력과 결과, 실행 범위가 정해진 작업을 재사용한다.

커뮤니티 확장은 이를 내 작업 너머로 넓힌다. 필요한 연동 기능을 이미 다른 사람이 만들었을 수도 있다.

판단은 여전히 과정에 남는다

계획을 세울 때는 여전히 에이전트와 긴밀히 협력한다. 여러 대안을 살피고 가정을 따져보지만 최종 결정은 내가 내린다. 린트 실행, 테스트, 환경 설정과 정리 같은 절차에는 코드를 쓰고 싶다.

이것이 Amp는 하네스, Swamp는 런타임에서 설명한 역할 분담이다. 모든 결정을 경직된 규칙으로 만들자는 뜻은 아니다.

내 팩토리에 검사와 인계 절차가 쌓이자 규모를 줄여야 했다. 한 검사는 계획의 의도를 확인해야 하는 자리에서 기획자가 문장 끝에 구두점을 붙였다는 이유로 계획을 거부했다. 필수 입력란은 코드로 검사할 수 있다. 계획이 타당한지는 다른 문제다.

결정론적이라고 해서 오류가 없는 것은 아니다. API는 실패하고 가정은 낡을 수 있으며, 범위가 제한된 모델 호출도 틀릴 수 있다. 명시적인 절차는 작업을 살피고 고치기 쉽게 하지만, 그 절차가 목표에 맞는지 판단할 책임까지 없애지는 않는다.

소프트웨어 개발을 넘어

같은 접근 방식은 내가 만든 다른 작업에도 적용됐다.

이 팀이 만드는 제품을 반기는 이유

독립적으로 Swamp를 사용하는 입장에서 Discord와 팟캐스트를 통해 팀의 균형 잡힌 태도를 좋게 봤다. AI의 가능성에 기대를 보이면서도 엔지니어링 경험이 쓸모없어졌다고 여기지 않고, 도구에 한계가 있다고 해서 무시하지 않는다. 현재 AI 소식을 논하는 방식에서도 그런 관점이 드러난다. 나 역시 이 도구를 만들고 활용하는 동안 소중하게 여기는 태도다.

Swamp는 오늘 출시와 Amplify Partners가 주도한 700만 달러 규모의 시드 투자를 발표한다. 팀에 축하를 전한다.

프로젝트마다 같은 연동이나 실행 절차를 에이전트에게 다시 만들도록 하고 있다면 Swamp를 살펴볼 수 있다. 반복되는 작업 하나부터 시작해 필요한 행동을 정의하고, 다음 워크플로가 사용할 수 있게 하면 된다.

AI가 더 많은 문제를 해결하도록 돕고 싶다. 같은 문제를 계속 다시 해결하고 싶지는 않다.

공개 사항: 독립적으로 Swamp를 사용한다. 이 글은 후원을 받지 않았다.