← Ascendy EN

meta

나는 그걸 설계하지 않았다 — 에이전트에게 맡겼다

· Ascendy Engineering

TL;DR

이 글에 대하여. 1인으로 제품을 만들며 사고방식이 어떻게 바뀌었는지에 대한 1인칭 기록이다. 에피소드의 질문자와 내 소속은 일반화했다. 같은 결의 루프 엔지니어링의 심장은 검증이다, Build in studying과 이어진다.

”그건 어떻게 설계했어요?”

언젠가 한 동료가 물었다. 내가 에이전트에게 여러 작업을 병렬로 시키는 걸 보고서다.

“병렬로 일을 시키면 깃 브랜치가 꼬일 텐데 — 그게 안 꼬이게 어떻게 설계했어요?”

좋은 질문이다. 그리고 예전의 나라면 한참을 설명했을 질문이다 — 브랜치 전략을 어떻게 짜고, 의존성을 어떤 순서로 풀고, 충돌을 어떻게 막는지.

그런데 내 대답은 이거였다. “설계 안 했는데요. 그것도 에이전트에게 맡겼어요.”

나는 task만 던진다. “이거, 이거, 이거 해줘.” 그러면 task 사이의 의존성이 뭔지, 무엇을 먼저 하고 무엇을 나중에 할지, 어떤 건 병렬로 돌려도 되는지 — 그 판단까지 에이전트가 하도록 하네스를 구성해 뒀다. 그가 잠깐 멈칫하더니 말했다. “아… 그런 것도 다 맡기는구나.”

그 짧은 반응에, 사고방식의 차이가 통째로 들어 있었다.

개발자의 본능이 가장 큰 장애물이다

그가 “어떻게 설계했냐”고 물은 건 자연스럽다. 개발자는 문제를 만나면 “이걸 내가 어떻게 풀지” 를 먼저 떠올리도록 훈련된 사람들이다. 어떤 자료구조를 쓸지, 어떤 아키텍처로 짤지, 어떤 기술이 맞을지 — 평생 그렇게 고민하며 살았다. 그게 곧 실력이었으니까.

그런데 그 본능이, AI 시대엔 가장 큰 장애물이 된다. 질문이 바뀌어야 하기 때문이다.

이건 단순한 도구 교체가 아니라 습관을 거스르는 일이라, 하루아침에 안 바뀐다. “이건 어떻게 풀지”가 반사적으로 먼저 튀어나온다. 그걸 의식적으로 “이건 어떻게 맡기지”로 바꿔 잡아야 한다.

”복잡하니까 내가 해야지”가 함정인 이유

가장 흔한 함정은 이렇게 생겼다.

“이건 너무 복잡하니까 내가 해야지.” “AI가 자꾸 할루시네이션을 하니까, 이건 내가 직접 봐야지.”

둘 다 합리적으로 들린다. 실제로 복잡하고, 실제로 AI는 그럴듯하게 틀린다. 그래서 틀린 결론이 아닌 것처럼 보인다. 함정은 거기 있다.

나도 처음엔 그렇게 했다. AI가 거짓말하고 과장하니까, 프롬프트를 계속 고치고, 결과를 일일이 직접 확인했다. 그런데 곧 깨달았다 — 그렇게 하면 내가 병목이 된다. 일을 아무리 빨리 만들어내도, 그걸 전부 내가 검수해야 하면 결국 내 손 속도가 천장이다. 시간도, 노동 효율도 늘지 않았다. AI를 쓰는 의미가 없어졌다.

“복잡하니까 내가” / “할루시네이션하니까 내가”의 결론은 — 영원히 내가 모든 걸 붙잡고 있는 것이다. 그건 AI를 빠른 손으로 쓸 뿐, 레버리지로 쓰는 게 아니다.

그래서 고민의 방향이 바뀌어야 한다

같은 사실(복잡하다, 할루시네이션한다)에서, 결론을 반대로 끌어야 한다.

핵심은 검증을 내가 하는 일에서 구조가 하는 일로 옮기는 것이다. “내가 봐야지”가 아니라 “어떻게 안 보고도 믿을 수 있게 만들지”. 나는 그 답을 찾다가 하네스와 루프 엔지니어링에 닿았고, 결국 직접 만들기로 했다.

그렇게 만든 게 우리 오픈소스 redteam이다. 하네스 안에 루프를 넣고, dogfooding으로 결과물을 검증하고 개선하는 과정을 거치니, 점점 신뢰할 수 있는 도구가 됐다. 그리고 지금 나는 — 진짜로 결과만 확인하고 피드백하는 정도로만 일하고, 대부분을 위임한다.

신뢰의 구조는 ‘모델 교차 검증’이다

맡긴 결과를 믿게 만드는 핵심 장치는, 한 모델을 더 똑똑하게 만드는 게 아니다. 작성한 모델과 다른 계열의 모델이 그 결과를 교차 검증하게 하는 것이다. 코드를 짠 모델이 자기 코드를 심판하면 통과시키지만, 다른 계열의 모델은 동의할 이유가 없다.

흥미롭게도 젠스파크(Genspark)는 이 아이디어를 서비스로 만들었다 — 여러 모델(GPT·Claude·Gemini 등)에 작업을 라우팅하고 서로의 출력을 교차 검증하는 구조(Mixture-of-Agents)다. 이건 “모델 교차 검증”이 제품이 될 만큼 중요해졌다는 신호다.

다만 한 가지는 짚어두자. 이미 두 개 이상의 모델(GPT·Claude·Gemini 등)을 구독하고 있다면, 굳이 별도 서비스가 아니어도 된다 — redteam 같은 하네스를 써서 직접 교차 검증을 구성할 수 있다. 서비스로 사든, 하네스로 직접 짜든 — 중요한 건 작성자와 다른 시선이 검증을 한다는 구조 그 자체다.

그럼 다 맡기나? 아니다 — 통제점을 옮기는 것이다

오해는 말자. 위임은 손을 떼는 것이 아니다. 다 맡기고 나 몰라라 하는 게 아니라, 내가 쥐는 지점을 옮기는 것이다.

끝까지 사람이 쥐는 건 셋이다 — 무엇을 맡길지 정하는 것, 돌아온 결과를 판단하는 것, 그걸로 피드백을 주는 것. 나는 더 이상 “이걸 어떻게 구현하지”를 쥐지 않는다. 대신 “이걸 어떻게 맡길 구조로 만들지”, 그리고 “돌아온 결과가 쓸 만한지”를 쥔다. 통제점이 구현에서 위임 설계와 판단으로 올라간 것이다.

그래서 사고를 바꿔야 한다. “이걸 내가 어떻게 풀지”가 아니라, “이걸 어떻게 맡길 구조를 만들지.” 설계하지 않고 맡기되, 맡긴 걸 믿을 수 있게 만드는 구조를 설계하는 것 — 그게 지금 개발자가 옮겨가야 할 자리다.

가져갈 것

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

Tags: ai, agents, delegation, loop-engineering, redteam, opinion