에이전트를 다수 운용하면 발생하는 의문

처음엔 잘 돌아가는 것처럼 보입니다

AI 에이전트 하나를 실서비스에 붙여 보면 처음엔 꽤 잘 돌아갑니다. 코드를 짜고, 답을 만들고, 파일을 고칩니다. 그래서 하나를 더 붙이고, 또 하나를 더 붙입니다. 역할을 나누고, 권한과 한계를 정하고, 각자 맡은 일을 하게 둡니다. 여기까지는 순조롭습니다.

문제는 잘 돌아가던 것 중 하나가 어긋나는 순간에 처음 모습을 드러냅니다.

"이건 나중에 어떻게 짚지?"

에이전트가 잘못된 코드를 배포했다고 해봅니다. 혹은 잘못된 답을 내놓았거나, 건드리지 말아야 할 파일을 고쳤다고 해봅니다. 며칠 뒤 그 결정을 되짚어야 할 때, 무엇을 근거로 짚을 수 있을까요. 로그가 있습니다. 작업마다 "누가 만들었고 누가 승인했다"는 표시를 붙여 둘 수도 있습니다. 그런데 로그를 열어 보고, 표시를 확인하고, 결국 사람이 다시 들여다봅니다.

여기서 두 번째 물음이 자연스럽게 따라옵니다. 그 표시라는 게, 정말 믿을 만한 걸까요?

표시를 붙이는 행위자가 곧 표시를 받는 대상입니다

"AI가 제안하고 사람이 최종 결정한다." 원칙으로는 좋습니다. 그런데 실무에서는 속도가 앞섭니다. 승인 단계가 있어도 그냥 통과시키는 일이 잦습니다. 그러면 "사람이 승인했다"는 표시는 남지만, 정말 사람이 들여다보고 승인한 것인지 아니면 흐름에 밀려 지나간 것인지는 그 표시만 봐서는 알 수 없습니다.

더 근본적인 곳에 걸림돌이 있습니다. 그 표시를 붙인 것도, 그 로그를 남긴 것도 결국 같은 시스템입니다. 자기가 자기 일을 기록하고, 그 기록으로 자기가 옳았다고 말하는 구조입니다. 실무를 하다 보면 이 지점에서 묘한 불편함이 듭니다. 기록은 쌓이는데, 그 기록이 정작 필요한 순간에 나를 지켜 줄 것 같지가 않은 느낌입니다.

그 불편함은 착각이 아닙니다. 구조가 원래 그렇게 되어 있습니다.

자기가 남긴 기록은 자기를 증명하지 못합니다

기록을 아무리 정교하게 쌓아도, 그것이 내 손 안에서 내가 남긴 것이라면 상대에게는 "우리 로그에는 이렇게 적혀 있다"는 한쪽 주장에 지나지 않습니다. 회사 내부 장부가 아무리 정확해도 외부 회계 감사를 대신할 수 없는 것과 같은 이유입니다. 정확성의 문제가 아니라 위치의 문제입니다. 판단하는 자리와 판단받는 자리가 동일 영역에 있다면, 그 기록은 온전한 증거가 되기 어렵습니다.

에이전트가 여럿이 되면 이 문제는 한 층 더 복잡해집니다. A가 만든 것을 B가 넘겨받아 배포까지 갔는데 버그가 났다고 가정해봅시다. 책임을 어디서 끊어야 할까요? A의 로그도 자기 기록이고, B의 로그도 자기 기록입니다. 각자 자기 쪽에서는 모든 게 들어맞습니다. 그런데 이 셋을 하나로 꿰어 "어느 지점에서 무엇이 정해졌는가"를 중립적으로 말해 주는 기록은 어디에도 없습니다.

그렇다면 표시를 더 정교하게 만들면 해결될까요.

더 두꺼운 내부 기록으로는 넘지 못하는 선이 있습니다

당연히 표시를 더 촘촘하게 붙이고, 로그를 더 두껍게 쌓는 건 도움이 됩니다. 무엇이 있었는지 스스로 되짚기에는 말이죠. 하지만 아무리 두꺼워져도 그것이 여전히 내가 스스로 남긴 기록이라는 사실은 바뀌지 않습니다. 두께가 위치를 바꾸지는 못합니다. 자기 증언은 정교해질 수는 있어도, 자기 증언이라는 성질에서 벗어나지는 못합니다.

그래서 방향을 살짝 틀어 볼 필요가 생깁니다. 기록을 더 안쪽으로 파고들 게 아니라, 결정의 경계만 밖으로 내보내 두는 쪽입니다.

이런 길도 있습니다 — 결정의 경계를 밖에, 미리 고정하기

이런 발상도 가능합니다. 에이전트가 어떤 결정을 실행하기 전에, 그 결정의 경계를 자기 밖의 어딘가에 먼저 고정해 두는 것입니다. 무엇이 잘못됐는지 내부를 파헤치는 게 아닙니다. 그건 여전히 내부 디버깅의 몫입니다. 여기서 밖에 남기는 것은 훨씬 얇습니다. 누가, 언제, 어떤 범위의 결정을 실행 전에 선언했는가. 그것뿐입니다.

이렇게 해 두면 세 가지 의문이 조금씩 다른 자리에 놓입니다. 잘못된 결정을 나중에 짚을 때는, 사후에 지어낸 기록이 아니라 실행 전에 이미 밖에 고정된 선언과 대조할 수 있습니다. "사람이 승인했다"는 것도 내용이 아니라 형식으로 — 승인이 있었는지 없었는지를 결정 시점에 밖에 박아 두면, 나중에 흐름에 밀려 지나간 것인지 아닌지를 되짚을 자리가 생깁니다. A에서 B로, 다시 배포로 이어지는 마디마다 무엇이 밖에 고정됐는지를 남겨 두면, 책임을 어디서 끊을지 물을 때 기댈 중립적 지점이 하나 생깁니다.

이 발상이 특별히 새로운 건 아닙니다. 오히려 전통적 방식에 가깝습니다.

사실 이 문제 의식은 처음부터 반영되어 있었습니다

사람 사이에서도 같은 문제를 오래 풀어 왔습니다. 중요한 약속일수록 당사자 한쪽의 장부가 아니라 공증, 등기, 제3자 보관 같은 장치에 기대 온 이유가 여기 있습니다. 판단하는 손과 판단받는 손을 떼어 놓아야 기록이 증거가 되기 때문입니다.

에이전트를 여럿 운영하다 보면 자연스럽게 이 물음에 도달하게 됩니다. 누가 가르쳐 주지 않아도, 배지를 붙여 보고 로그를 쌓아 보다가 "이걸로 정말 될까" 하는 지점에 이릅니다. 그 지점이 바로 자기 증언의 벽입니다. 결정의 경계를 자기 밖에 미리 고정한다는 발상은, 그 벽을 염두에 두고 처음부터 설계에 반영된 생각입니다. 정답을 판다는 뜻이 아니라, 같은 문제를 먼저 들여다본 흔적이 있다는 뜻입니다.

아직은 급하지 않을 수 있습니다

지금 당신의 에이전트가 전부 한 지붕 아래에 있다면 — 한 사람이 소유하고 한 플랫폼 위에서 돈다면 — 배지와 로그로 당분간 버틸 수 있습니다. 자기 증언의 벽은 있지만, 아직 그 벽에 도달할 일은 드뭅니다.

그 벽이 또렷해지는 건 에이전트가 바깥과 거래하기 시작하는 순간입니다. 다른 회사의 에이전트와 합의하고, 서로 다른 플랫폼의 로그가 어긋나기 시작하면, 그때는 각자의 내부 기록이 아무리 훌륭해도 "우리는 이렇게 적혀 있다"는 두 개의 주장만 남습니다. 그 순간에 기댈 중립적 기록이 어디에 있는지 — 그 물음이 오기 전에 한 번쯤 떠올려 둘 만합니다.