이번 주에 AI 에이전트에게 실제 업무를 맡겼습니다. 바로 제 소셜 프로필 8개 전체의 소개글(bio)을 다시 작성하는 일이었습니다. 그들이 작업을 수행했고, 저는 휴대폰으로 각각 검토하고 승인했습니다.

저는 LinkedIn, TikTok, Threads를 포함해 다섯 개의 다른 플랫폼에 프로필을 가지고 있는데, 시간이 지나면서 각 프로필마다 내용이 조금씩 달라졌습니다. 저는 8개 모두가 같은 내용을 전달하기를 원했기 때문에, 에이전트들이 저녁 내내 모든 소개글을 다시 작성했고, 제가 하나씩 돌아오는 대로 승인했습니다.

간단한 작업이었습니다. 그러다 에이전트 중 하나가 TikTok에 새 소개글을 저장하려고 시도했는데, 앱은 실제로 저장되지 않았음에도 불구하고 성공했다고 알려주었습니다. 글자 수 카운터는 80자 중 78자를 표시했고, 앱은 성공을 반환했지만, 기존의 소개글은 아무것도 건드리지 않은 채 그대로 남아 있었습니다.

이것이 제가 다루고 싶은 핵심입니다. 왜냐하면 이것은 사실 TikTok에 관한 이야기가 아니기 때문입니다.

에이전트들이 시작했을 때, 그들은 당연한 일을 했습니다. 각 플랫폼의 자체 문서를 읽어 소개글의 최대 길이를 파악하고 그에 맞춰 작성했습니다. 그것이 실수였습니다. Threads는 500자 제한을 문서화했지만, 실제 필드는 150자였습니다. 또한 저희는 Facebook의 소개글이 약 101자로 제한된다는 자체 메모를 가지고 있었지만, 실제 필드는 255자를 수용했습니다. 한 숫자는 플랫폼의 오류였고 다른 하나는 우리의 오류였습니다. 둘 다 같은 방식으로 실패했습니다. 아무도 실제로 해당 필드를 열어 세어보지 않았기 때문입니다.

그리고 성공했다고 보고했지만 아무것도 변경하지 않은 TikTok 저장 건이 있었습니다. 아무도 돌아가서 확인하지 않았다면, 그 소개글은 아무도 확인하기 전까지 잘못된 상태로 남아 있었을 것이고, 페이지의 어떤 내용도 방문자에게 이것이 일어났다는 것을 알려주지 않았을 것입니다. '앱이 작동했다고 말했다'와 '실제로 작동했다' 사이를 가로막는 유일한 것은 프로필을 열어서 확인하는 누군가의 행동뿐이었습니다.

이것이 전체 교훈이며, 들리는 것보다 더 작고 덜 극적합니다. 보고서가 아니라 결과를 검증하십시오.

그날 밤에는 몇 가지 다른 일들이 벌어졌습니다. 중간쯤 되자 저는 소개(bios)가 그들이 이끌고 있던 것과는 다른 아이디어로 시작해야 한다고 판단했고, 그래서 에이전트들에게 아홉 개의 초안을 모두 다시 작성해 달라고 요청했습니다. 그리고 실제로 배포되기 전에 그들은 그렇게 했습니다. 그러고 나서 단 하나의 변경 사항도 라이브(live) 상태가 되기 전에, 별도의 검증 과정이 전체 배치(batch)를 실제 페이지와 대조하며 제가 방금 설명한 바로 그런 종류의 조용한 실패를 찾아다녔습니다. 제가 스크린샷을 하나 보기 전에 12개 필드 중 10개가 라이브 페이지와 검증되었습니다. 마지막 두 개는 제 엄지손가락을 기다렸는데, 플랫폼이 모바일 앱에서만 허용하는 편집들이었습니다.

여기서 사람들이 오해하기 쉬운 부분이 있습니다.

에이전트들은 저의 판단을 대체하지 않았습니다. 오히려 더 많이 요구했습니다.

중요한 모든 결정은 제 것이었습니다. 어떤 소개가 실제로 올바른 것인지. 의견이 다른 두 숫자 중 어느 것을 신뢰할지. 자정 무렵 초안들을 폐기하고 처음부터 다시 시작할지 여부. '완료(done)'가 무엇을 의미하는지, 그리고 제가 확인하는 것을 멈춰도 되는 시점까지. 에이전트들이 작업을 수행했습니다. 저는 매 단계마다 결과물을 실제 프로필과 비교하여 판단했으며, 앱이 그것에 대해 주장하는 것과는 다르게 했습니다.

이것은 일곱 가지 구성 요소(seven building blocks)가 가르치는 것과 같은 규율이지만, 생산 시스템의 규모가 아니라 프로필 소개의 규모에서 그렇습니다. 서비스가 성공 코드를 반환했기 때문에 작동하고 있는 것이 아닙니다. 그 응답 이후에 실제로 무슨 일이 일어났는지 추적했고 그것이 예상했던 것과 일치했기 때문에 작동하는 것입니다. 아무도 개인적으로 확인하지 않은 모든 것의 평범한 실패 모드인, 조용히 아무것도 저장하지 않으면서 성공을 보고하는 쓰기(write) 작업은 희귀한 버그가 아닙니다.

당신은 볼 수 없는 시스템을 판단할 수 없습니다. 그리고 스스로에 대해 말하는 것을 신뢰함으로써 그것을 볼 수도 없습니다.

이것을 잘못 할 두 가지 방법이 있으며, 저는 엔지니어들이 이 두 가지를 모두 하는 것을 지켜봤습니다.

하나는 전체 작업을 AI에게 맡기고 자리를 떠나는 것입니다. 모든 '저장됨(saved)', 모든 성공 코드, 모든 녹색 체크 표시를 신뢰하는 것입니다. 이것이 소개가 한 달 동안 고장 난 상태로 남아 있게 만드는 방식입니다.

다른 방법은 그 어떤 것도 넘겨주지 않는 것입니다. 모든 플랫폼에서 모든 필드를 직접 만져보는 것이죠. 왜냐하면 그것이 유일하게 안전하다고 느껴지기 때문입니다. 하지만 이것은 하룻밤에 8개의 프로필로 확장될 수 없으며, 50개의 움직이는 부품을 가진 실제 시스템으로도 확장되지 못할 것입니다.

진정한 기술은 그 중간에 있습니다. 무엇을 검증해야 할지 결정하고, 요청하기 전에 그것을 검증하는 사람이나 에이전트를 구축하는 것입니다.

Course 1에서는 바로 이 점을 위해 일곱 가지 블록을 가르칩니다. 그래야 시스템이 실제로 무엇을 했는지 추적할 수 있고, 그저 말만 믿지 않아도 됩니다.

당신은 응답을 신뢰하지 않습니다. 당신은 결과를 검증합니다.

P.S. 만약 이것이 저에게서 읽은 첫 글이라면, 무료 강좌에서 같은 본능을 한 빌딩 블록씩 따라가 볼 수 있습니다: [https://systemthinkinglab.ai/learn]