제품과 도구가 서로를 키운다 — 내 일하는 방식에 걸린 선순환 루프

2026-07-08 · Ascendy Engineering

TL;DR

나는 제품(어센디)을 만들려고 도구(오픈소스 리뷰 하네스 redteam)를 만들었다. 그런데 그 도구를 실제 제품에 쓰다 보니, 도구와 제품이 서로를 키우는 선순환이 생겼다.
한 바퀴는 이렇게 돈다: 제품을 만드는 에이전트가 도구를 쓰다 불편을 만나 → 도구 레포에 이슈로 등록 → 도구 담당 에이전트가 타당성을 검토해 고침 → 나아진 도구가 다음 제품 작업을 낫게 함.
loop engineering이 하네스 안의 검증 루프라면, 이건 하네스 밖에서 내가 설계한 조직이 도는 한 층 위의 루프다.
신기한 건 — 이 루프가 어찌나 잘 도는지, “어느 불편이 어느 이슈가 됐나”라는 세부 출처조차 나한테 없다. 그 지식은 에이전트들에게 흩어져 있고, 나는 설계하고 라우팅하는 자리에만 있다.

이 글에 대하여. 인터뷰로 끌어낸, 내 작업 조직 설계에 대한 1인칭 기록이다. 이 방식은 내 방식이지 정답 주장이 아니다. 구체적인 이슈 번호는 일부러 박지 않았다 — 그 세부 출처가 나에게 없기 때문인데, 그 사실 자체가 이 글의 요점이기도 하다. 같은 결의 조율은 파일이 아니라 이슈로, 설계한 게 아니라 위임했다와 이어진다.

두 개의 루프

전에 loop engineering 얘기를 쓴 적이 있다. 그때의 루프는 하네스 안에 있었다 — AI가 코드를 짜고, 다른 모델이 검증하고, 고치고, 다시 돈다. AI가 도는 루프다.

그런데 요즘 내가 일하는 방식을 들여다보면, 그것과는 다른 루프가 하나 더 있다. 하네스 안이 아니라 하네스 밖, AI가 아니라 내가 설계한 조직이 도는 루프. 큰 의미의 루프라고 부를 수 있겠다.

이야기는 이렇게 시작한다. 나는 지금 제품 하나(어센디)를 만들고 있다. 그 제품을 더 잘 만들기 위한 도구로 리뷰 하네스(redteam)를 만들었다. 그런데 그 도구를 실제 제품 개발에 쓰다 보니, 도구가 제품을 낫게 하고, 제품을 만들다 나온 불편이 다시 도구를 낫게 하는 고리가 돌기 시작했다.

한 바퀴는 어떻게 도나

이 선순환의 한 바퀴는 구체적으로 이렇게 돈다.

제품 에이전트가 도구를 쓴다. 백엔드·프론트엔드를 맡은 에이전트에게 “redteam을 써서 이걸 구현해”라고 시킨다.
불편이 드러난다. 그 에이전트들이 도구를 쓰다가 뭔가 걸리면, 나에게 “이건 제품 문제가 아니라 하네스 쪽 문제 같습니다”라고 보고한다.
이슈로 등록시킨다. 그러면 나는 그 에이전트에게 “그럼 redteam 레포에 이슈로 등록해”라고 한다.
도구 담당 에이전트가 게이트하고 고친다. redteam을 맡은 에이전트가 등록된 이슈를 읽고, 타당성을 검토해서 실제 하네스 문제로 판단되면 개선한다. 심지어 이 개선 작업도 그 도구 자신으로 검증한다(dogfooding).
나아진 도구가 다음 제품을 낫게 한다. 버전업된 도구로 다음 제품 작업이 조금 더 매끄러워지고, 거기서 또 다음 불편이 나온다.

그리고 이게 계속 돈다. 제품을 만들수록 도구가 좋아지고, 도구가 좋아질수록 제품을 만들기 쉬워진다.

왜 그 자리에서 안 고치고, 이슈로 우회시키나

여기서 이상하게 보일 수 있다. 불편을 만난 에이전트가 그 자리에서 바로 고치면 될 텐데, 왜 굳이 이슈로 등록시키고 다른 에이전트에게 넘기나?

기록이 남아야 하기 때문이다.

에이전트 세션은 언제든 리셋된다. 컨텍스트가 날아가고, 그때 무슨 일이 있었는지 다음 세션은 모른다. 그런데 그 불편과 판단이 이슈로 남아 있으면, 리셋된 다음 세션에게 “그 이슈 읽어봐” 한마디면 컨텍스트가 복원된다. 즉 이 기록의 1차 독자는 사람인 내가 아니라, 리셋된 다음의 에이전트다.

원래 나는 이런 걸 문서로 만들어 깃헙에 계속 누적시켰다. 그런데 어느 순간 생각했다 — 굳이 그럴 필요가 있나? 깃헙에는 이미 이슈 트래커라는 좋은 도구가 있다. 상태(열림/닫힘)가 있고, 스레드가 있고, 참조가 걸린다. 문서를 손으로 쌓는 대신, 이미 있는 좋은 도구를 그냥 쓰면 됐다. (파일로 쌓던 조율을 이슈로 옮긴 이야기와 같은 뿌리다.)

왜 타당성 판단을 사람이 아니라 에이전트에게 맡기나

또 하나. 등록된 이슈가 진짜 고칠 가치가 있는지를 판단하는 건, 내가 아니라 도구 담당 에이전트다. 왜 그 게이트를 사람이 아니라 에이전트에 뒀나?

처음부터 그렇게 설계했다. 나는 각 에이전트에게 세 가지를 심어 뒀다:

(a) 전체 프로젝트의 컨텍스트 — 우리가 뭘 만들고 있는지.
(b) 자기가 맡은 역할 — 너는 백엔드다, 너는 프론트다, 너는 도구(redteam) 담당이다.
(c) 다른 담당 에이전트가 존재한다는 사실 — 각자가 서로의 역할을 안다.

이 셋이 심어져 있으니, 라우팅이 그냥 된다. 제품 에이전트는 “이건 하네스 문제니까 도구 담당에게 넘겨야겠다”를 알고, 도구 담당 에이전트는 “이건 내 소관이니 내가 타당성을 판단한다”를 안다. 게이트를 도구-담당 에이전트에 둔 건 즉흥이 아니라, 이 작은 조직을 그렇게 설계했기 때문이다.

그래서 사람의 자리는 위로 올라간다

이 이야기에서 내가 가장 신기하게 느끼는 지점이 있다. 앞서 이 글을 쓰려고 “어느 제품 불편이 어느 이슈가 됐는지” 구체적인 사례를 대려 했는데 — 나는 그걸 모른다.

그건 내 지식이 아니라, 이슈를 올린 에이전트들의 지식이다. 나는 “이건 하네스 문제 같으면 이슈로 남겨”라는 규칙을 설계하고 라우팅했을 뿐, 어느 불편이 어느 이슈로 이어졌는지 그 세부 출처(provenance)는 내 머릿속에 없다. 그 지식은 에이전트들에게 분산돼 있다.

이게 위임을 극한까지 밀어올린 모습이라고 나는 생각한다. 사람이 붙잡는 지점이 구현에서, 구현의 이력에서도 떠나, 조직의 설계와 라우팅으로 올라간 것이다. 나는 루프를 돌리는 게 아니라, 루프가 돌아가도록 설계한다.

그런데 이게 정말 선순환일까 — 헛돌지 않는 이유

솔직한 질문. 도구를 내가 만들다 보니, 제품 만들 시간에 도구만 다듬고 있는 함정(yak-shaving)에 빠질 수도 있지 않나?

두 가지 장치가 그걸 막는다.

병렬이다. 이 모든 걸 에이전트들이 나눠서 하니, 도구를 고치는 동안에도 제품을 만드는 에이전트는 멈추지 않는다. 도구 수리가 제품 개발을 정지시키지 않는다.
타당성 게이트가 있다. 보고된 불편이 전부 고쳐지는 게 아니다. 도구 담당 에이전트가 “이건 진짜 하네스 문제다 / 이건 아니다”를 걸러낸다. 그래서 모든 불평이 버전업으로 이어지지 않는다.

이 두 장치가 있어서, 이 루프는 헛도는 쳇바퀴가 아니라 실제로 앞으로 나아가는 선순환이 된다 — 적어도 지금 내 경우엔 그렇다.

가져갈 것

제품과 도구를 함께 돌려라. 제품을 만들려고 만든 도구를, 그 제품에 직접 써라. 제품이 도구를 낫게 하고, 도구가 제품을 낫게 하는 고리가 돈다.
불편은 그 자리에서 고치지 말고 기록으로 남겨라. 세션은 리셋된다. 이슈로 남기면 다음 세션이 읽고 복원한다 — 기록의 독자는 사람이 아니라 다음 에이전트다.
에이전트들을 조직으로 설계하라. 각자에게 전체 컨텍스트 + 자기 역할 + 서로의 존재를 심으면, 라우팅과 게이트가 그냥 돈다.
헛돌지 않으려면 병렬 + 게이트. 도구 수리가 제품을 멈추지 않게 하고, 타당성 판단으로 헛짓을 거른다.

솔직히 이것도 정답이 아니라 지금의 내 방식이다. 다만 일하는 방식 자체에 루프를 걸고, 사람은 그 루프를 돌리는 대신 설계하는 자리로 올라가는 것 — 그게 지금 내가 찾은, 혼자서 제품과 도구를 함께 굴리는 가장 나은 방법이다.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: ai, agents, workflow, dogfooding, multi-agent, opinion