여러 개의 AI 에이전트를 일상적으로 구동하는 구성을 약 2개월간 운용하며, 잘 되었던 점과 처참하게 실패했던 점을 그대로 정리했습니다.

처음에 저지르기 쉬운 실수

AI 에이전트를 사용하기 시작하면, 대개 처음에 이렇게 합니다.

"이 안건 어떻게 생각해? 괜찮으면 진행해줘"

이것은 3가지의 서로 다른 일을 한 번에 부탁하는 것입니다.

• 안건을 내놓기 (생성 (Generation))
• 안건이 타당한지 확인하기 (평가 (Evaluation))
• 실행할지 말지 결정하기 (결정 (Decision))

같은 AI에게 동시에 시키면, 이 세 가지는 서로를 망가뜨립니다.

평가가 생성을 죽인다— "근거를 확인한 뒤에 내놓으라"고 말하는 순간, 근거를 확보할 수 있는 안건 = 이미 누군가가 하고 있는 안건밖에 나오지 않게 된다 -
생성이 평가를 죽인다— 자신이 낸 안건을 스스로 평가하면, 통과시키고 싶은 방향으로 편향 (Bias)이 걸린다 -
경위가 평가를 죽인다— "전부터 하고 싶었다"라고 전달하는 시점에서, AI는 해도 되는 이유를 찾기 시작한다 -

이 기사는 그 세 가지를 분리하는 것부터 시작하여, 실제로 에이전트 구성을 구동하는 과정에서 빠졌던 5가지 함정에 대한 기록입니다. 역할을 나눈 것만으로 끝나지 않고, 나눈 후의 운용 (데이터 전달 · 자동화 범위)에서도 또 다른 실패를 거듭했습니다.

핵심 설계: 생성 / 평가 / 결정의 분리

포인트는 3가지입니다.

에이전트는 몇 명이라도 좋다. 단, 권능을 중첩시키지 마라. 같은 권능 안에서 여러 개를 실행하는 것은 권장됩니다 (생성 담당을 별개 테마로 2회 실행하거나, 평가 담당을 별개 조건으로 병렬 판정시키는 등). 권능이 겹치면 모든 것이 어중간해집니다. -
평가 담당에게는 「경위」를 전달하지 마라. 이것이 가장 효과적입니다. 동기 · 배경 · 감정을 빼고, 숫자와 사실만 전달합니다. -
결정은 인간이 한다. 평가 담당이 NG라고 해도 밀어붙일 권리, GO라고 해도 보류할 권리는 인간 측에 있습니다.

이하, 실제로 빠졌던 5가지 함정입니다. 모두 "작동하지 않았다"가 아니라, 작동하는 것처럼 보이지만 틀렸던 종류의 실패였습니다.

함정 1: 평가 담당에게 경위를 알려주면, 판정이 느슨해진다

판단을 체크하게 하는 「평가 담당」 에이전트에게 다음과 같이 전달하고 있었습니다.

이러이러한 이유로 이 안건을 진행하고 싶다고 생각하고 있다. 체크해 주길 바란다.

평가 담당은 거의 모두 통과시켰습니다. 지금 생각하면 당연한데, 이쪽의 기대를 먼저 전달해 버렸기 때문입니다. AI는 상대의 의도를 파악하는 데 능숙하므로, "진행하고 싶다"라고 쓴 시점에서 진행해도 되는 이유를 찾는 쪽으로 돌아섭니다.

어떻게 고쳤나: 평가 담당에 대한 입력에서 동기 · 경위 · 감정을 전부 뺐습니다. 숫자와 사실만 전달합니다.

나쁜 예:
"전부터 신경 쓰였던 안건이라 슬슬 움직이고 싶다. 이하를 평가해 줘"
좋은 예:
...

나아가, 평가 담당은 대화 이력을 이어받지 않는 독립된 에이전트로서 기동합니다. 같은 대화 속에서 "그럼 다음은 엄격하게 체크해 줘"라고 역할을 전환해도, 그때까지의 흐름이 전부 문맥(Context)으로 남아 있기 때문에 독립성이 생기지 않습니다.

평가의 독립성은 프롬프트로 "엄격하게 봐줘"라고 부탁해서 만드는 것이 아니라,

전달하는 정보를 물리적으로 제한함으로써 만드는 것입니다.

함정 2: 발상 담당에게 근거 확인을 시키면, 발상이 죽는다

처음에는 "정확한 아이디어를 원한다"고 생각하여, 발상 담당에게 "반드시 근거를 확인한 뒤에 내놓을 것"이라고 지시했습니다. 결과적으로 나오는 안건이 무난한 것들뿐이 되었습니다.

근거 확인을 의무화하는 순간 "근거를 확보할 수 있는 안건"밖에 나오지 않게 됩니다. 즉 이미 누군가가 하고 있는 일밖에 나오지 않습니다. 새로운 조합은 정의상 아직 아무도 검증하지 않았기 때문에, 근거 확인을 조건으로 걸면 처음에 사라집니다.

어떻게 고쳤나: 발상 담당의 지시서에 명확하게 이렇게 적었습니다.

- 사실로서 옳은가보다, 재미있는가 · 연결되는가를 우선한다
- 근거 확인은 불필요하다. 틀려도 괜찮다
- 내놓은 것은 좋고 나쁨을 불문하고 전부 남긴다 (나중에 선택하는 것은 이쪽의 일)

근거 확인은 다음 공정(평가 담당)의 일로서 완전히 분리했습니다.

생성과 평가를 같은 에이전트에게 시키면, 평가가 생성을 죽입니다. 순서대로 통과시키는 것은 옳지만,

동시에 시켜서는 안 됩니다.

함정 3: 아이디어가 아무리 많이 나와도, 하나도 형태를 갖추지 못했다

함정 2를 수정한 결과, 발상(Ideation) 역할을 맡은 에이전트는 잘 움직이게 되었습니다. 몇 차례 반복하니 안건들이 정리되어 어느 정도 쌓였습니다.

그런데 아무 일도 일어나지 않았습니다.

매번 "이게 아니다"라는 반응으로 끝납니다. 안건의 질 문제라고 생각하여 발상 기법을 늘리거나 테마를 바꾸어 보기도 했지만, 몇 번을 해도 같은 지점에서 멈췄습니다.

조직도를 그려보며 깨달았습니다. "발상한다", "조사한다", "기록한다", "판단한다" 역할은 있는데, "만든다", "보여준다" 역할이 어디에도 없었습니다.

즉, 연구 개발(R&D)만 있고 공장과 판매가 없는 상태였습니다. 결정된 이후의 목적지가 구조적으로 존재하지 않기 때문에, 아무리 좋은 안건이 나와도 마지막에는 반드시 공중에 붕 뜨게 됩니다. "이게 아니다"라는 반응은 안건이 나빴던 것이 아니라, 목적지가 없는 안건은 모두 "이게 아니다"로 보일 수밖에 없다는 이야기였습니다.

어떻게 수정했나: "만들고, 보여주고, 숫자를 모으는" 일만 담당하는 역할을 하나 추가했습니다. 규칙은 딱 세 가지입니다.

• 3일 이내에 만들 수 있는 최소한의 형태로 압축한다 (3일 내에 만들 수 없다면 안건을 분할하거나 보류한다)
• 만들기 전에 무엇을 측정할지 결정한다 (나중에 편의에 따라 지표를 선택하지 않는다)
• 보고는 속행 / 피보트 (Pivot) / 철수의 3가지 선택지로 고정한다

아이디어가 형태를 갖추지 못할 때, 원인은 거의 아이디어의 질이 아닙니다.

결정 이후의 후속 공정이 조직도에 존재하지 않을 뿐입니다.

함정 4: 필드명을 착각하여, 다른 의미의 숫자로 판단하고 있었다

자동 수집한 데이터를 에이전트에게 전달하고 있었는데, 그중 특정 항목을 계속 다른 의미의 수치라고 생각하며 읽고 있었습니다. 실제로는 완전히 다른 지표였습니다. 이름에서 연상되는 의미와 실제 들어있는 값의 의미가 달랐던 것입니다. 게다가 수치상으로는 일단 그럴싸한 범위 안에 들어오기 때문에, 출력을 봐도 오류를 알아차릴 수 없습니다.

이를 발견한 것은 평가(Evaluation) 역할이었습니다. "이 수치의 분포는 이름에서 상정되는 지표로서 부자연스럽다"라고 지적해 주었고, 그제야 비로소 밝혀졌습니다.

어떻게 수정했나:

• 데이터를 전달하는 에이전트 측에 반드시 데이터 사전 (Data Dictionary) (각 필드가 무엇을 의미하는지)을 둔다
• 에이전트에게 숫자를 전달하기 전에, 필드명이 아니라 사전을 대조하도록 규칙을 정한다
• 올바른 의미의 항목을 별칭으로 추가하여, 이름만으로는 추측할 수 없게 만든다

AI는 전달받은 숫자를 의심하지 않습니다. 이름에서 의미를 추측하여 그대로 사용합니다.

필드명의 의미는 인간이 보증하지 않으면 아무도 보증할 수 없습니다. 그리고 이런 종류의 실수는 출력이 망가지지 않기 때문에 발견이 늦어집니다.

함정 5: 자동 생성을 전면 개방했더니, 쓰레기가 양산되었다

기록으로부터 기사 초안을 자동 생성하는 메커니즘을 만들었고, 대상을 모든 기록으로 설정했습니다. "재료는 많을수록 좋다"고 생각했기 때문입니다.

다음 날 아침, 내부용 작업 메모까지 무차별적으로 기사화된 초안이 수십 건 만들어져 있었습니다. 모두 공개할 수 있는 수준이 아니었기에 전부 버렸습니다.

어떻게 수정했나: "무엇을 쓸 것인가"는 인간이 선택하고, "쓰는 것"만 자동화하는 반자동 설계로 변경했습니다.

• "이것은 기사로 쓸 가치가 있다"라고 판단한 것만 전용 공간에 짧은 기획 메모를 둔다
• 자동 생성의 대상을 그 공간으로만 한정한다

생성량은 급격히 줄었지만, 사용할 수 있는 초안의 수는 늘어났습니다.

자동화해도 되는 것은 "작업"이지 "선택"이 아닙니다. 선택까지 자동화하면,

출력의 양에 비례하여 쓰레기가 늘어납니다.

요약: 5가지 함정에 공통적으로 나타난 것

나열해 보면 거의 전부가 비슷한 형태를 띠고 있었습니다.

그리고 공통적으로 말할 수 있는 것은 이것입니다.

모두 "돌아가고 있는 것처럼 보였다"는 점입니다.

AI 에이전트 운용에서 정말 위험한 것은 멈추는 것이 아니라, 그럴싸한 출력을 계속 내놓으면서 틀리고 있는 것이었습니다. 역할을 나누고 전달하는 정보를 좁히는 등의 수수한 노력이 효과가 있었던 이유는, 그것이 유일하게 오류를 겉으로 드러내는 방법이었기 때문이라고 생각합니다.

이 외에도 빠졌던 함정이 몇 가지 더 있습니다. 정리되는 대로 속보로 공개하겠습니다.

Discussion