사업 운영을 돕는 AI를 만들기 시작했습니다. 어려운 문제는 AI가 아니었습니다

AI 요약

OSIO를 만든 Leon Orien은 거의 6개월 동안 주당 40~60시간을 개발에 쏟았습니다. 처음 구상은 간단했습니다. 사업주가 “지난달 늦게 결제한 고객에게 후속 연락을 해줘” 또는 “이 잠재 고객들을 계속 관리해줘”라고 말하면, 어떤 에이전트를 쓸지 고민하거나 여러 자동화를 직접 연결하지 않아도 AI가 일을 처리하는 제품을 만들고 싶었습니다.

하지만 모델이 이메일을 쓰고, 정보를 추출하고, 도구를 호출하거나 시스템을 갱신하는 일은 점점 쉬워졌습니다. 더 까다로운 문제는 업무가 시작된 뒤의 관리입니다. 누가 그 업무를 맡는지, 진행 중 모델이 바뀌면 어떻게 되는지, 에이전트가 어디까지 할 수 있는지 정해야 합니다. 업무를 만든 뒤 권한이 바뀌는 경우도 고려해야 합니다. API가 성공을 반환했다고 사업상 원하는 결과가 생긴 것은 아니며, 에이전트가 완료했다고 말해도 실제로 끝났다는 증거가 필요합니다.

에이전트가 아니라 조직을 지속성의 중심에 둡니다

이 문제를 다루며 OSIO는 에이전트가 아니라 조직을 지속적으로 유지되는 대상으로 삼게 됐습니다. 에이전트와 모델, 제공업체, 도구는 바뀔 수 있지만 사업 자체가 이들과 함께 사라져서는 안 된다는 구상입니다. 업무와 책임, 맥락, 권한, 결정, 증거, 결과를 더 오래 유지되는 곳에 기록해야 합니다. Leon은 OSIO를 ‘지능형 조직을 위한 운영 체제(Operating System for Intelligent Organisations)’라고 설명합니다.

사업주가 해야 할 일은 OSIO에 원하는 업무를 알리는 것입니다. 시스템은 관련 사업 맥락을 파악하고 AI와 사람, 연결된 도구 사이에서 업무를 조율합니다. 판단이나 승인, 실제 결정이 필요한 순간에는 사람을 다시 부릅니다. ‘여기서는 사람이 필요합니다’라는 응답도 정상적인 결과로 취급합니다. 가능한 한 많은 일을 자동으로 처리하는 것이 목표는 아닙니다.

허가, 실행, 확인, 실제 결과를 구분합니다

글에서 특히 강조하는 경계는 도구가 “성공했다”고 알리는 것과 현실에서 원하는 결과가 발생한 것을 동일시하지 않는 일입니다. 어떤 작업을 할 권한이 있다는 사실은 실제로 시도했다는 뜻이 아닙니다. 시도했다는 사실도 결과가 발생했다는 증거가 아닙니다. 결과가 발생했다는 증거가 있어도 사업주가 원한 목표까지 달성했다는 보장은 없습니다.

이 구분은 AI가 콘텐츠를 생성하는 수준을 넘어 사람을 대신해 실제 작업을 수행할수록 중요해집니다. OSIO는 작업을 무조건 자동화하기보다 위험과 판단 필요성에 따라 처리하려 합니다. 안전하게 자동화할 수 있는 작업은 자동으로 진행하고, 승인이 필요하면 요청하며, 사람의 판단이 필요하면 담당자를 불러야 합니다.

반응

• @serverdrop — 권한 부여 → 시도 → 확인 응답 → 현실의 결과라는 구분이 이 글의 핵심이라고 봅니다. 각 단계의 담당자와 증거를 명시한 감사 기록을 기본으로 만들면, ‘에이전트가 끝냈다’는 상태 하나만 두는 것보다 승인 시점을 훨씬 이해하기 쉽습니다.
• @aihiringtrigger — 네 단계 구분에 공감합니다. 저는 공개 API에서 데이터를 가져오는 작은 야간 작업을 운영하는데, 가장 무서운 실패는 ‘성공’으로 보고된 경우였습니다. 실행은 끝났고 오류도 없었지만, 데이터 제공처가 다른 플랫폼으로 옮겨간 탓에 결과가 조용히 0건으로 돌아왔습니다. 이제 ‘실행됐다’와 ‘기대한 결과를 만들었다’를 따로 기록하고, 갑자기 0건이 나오면 정상으로 처리하지 않고 알립니다. 어떤 경우에 사람에게 넘기고 어떤 경우에 재시도하는지 궁금합니다.
• @zaneberg — 회사 계정으로 Reddit에 글을 올리는 AI 에이전트에서 확인 응답과 실제 게시 결과가 다른 사례를 겪었습니다. 필터가 댓글을 지워도 작성자 본인에게는 정상적으로 보이고 API도 삭제 사실을 알리지 않았습니다. 로그아웃 상태에서 확인해야 다른 사람에게 보이지 않는다는 걸 알 수 있었습니다. 이제 몇 분 뒤 계정 밖에서 다시 읽어 게시 여부를 확인합니다. OSIO에서도 결과 증거는 작업을 수행한 세션이 아니라 고객 받은편지함이나 은행 거래 내역처럼 다른 곳에서 가져오는 편이 좋겠습니다.
• @indiehackers420 — ‘허용 → 시도 → 확인 응답 → 달성’ 구분이 이 글에서 가장 날카로운 부분입니다. 대부분의 에이전트 설정은 네 단계를 ‘성공’ 하나로 뭉치고, 바로 그 지점에서 신뢰가 깨집니다. 에이전트를 실제 책임이 있는 업무에 맡기려면 작업자가 아닌 다른 곳에서 확인한 증거가 필요합니다. 이메일 전송이 아니라 결제 완료나 답장 수신 같은 증거 말입니다. 작업 종류보다 되돌릴 수 있는지에 따라 자율성 수준을 나누는 방식도 좋습니다. 초안은 쉽게 취소할 수 있지만 환불은 그렇지 않습니다. ‘여기서는 사람이 필요합니다’도 좋은 결과입니다. 상황에 맞게 사람에게 넘기는 에이전트가 자신 있게 틀리는 에이전트보다 믿을 만합니다.
  • @Leon Orien — 되돌릴 수 있는지는 좋은 기준이지만 유일한 경계가 될 수는 없다고 생각합니다. 초안을 만드는 일과 돈을 보내는 일은 둘 다 기술적으로 허용돼도 위험이 다릅니다. 시스템에 행동 권한을 줬다고 해서 매번 그대로 진행해야 한다는 뜻은 아닙니다.
• @michaelrice_dev — AI 봇 여러 개와 작은 제품을 만들면서 검토를 별도 업무로 나눈 뒤 신뢰가 커졌습니다. 한 봇은 품질 관리만 맡고, 결과를 확인하기 전에는 아무것도 내보내지 않습니다. 결과물을 만든 봇에게 완성 여부를 묻는 방식은 가장 좋지 않습니다. 제 이름으로 공개되는 내용은 여전히 제가 승인합니다. OSIO에서는 결과를 검증하는 에이전트와 실제 작업을 수행하는 에이전트를 분리할 수 있나요, 아니면 증거는 항상 연결된 도구가 돌려주는 응답에서 가져오나요?
  • @Leon Orien — 검증 에이전트가 작업 에이전트와 같을 필요는 없습니다. 가능하면 작업자 스스로 완료를 증명하는 구조에 의존하지 않는 편이 좋습니다. 더 강한 증거는 전송된 이메일이 실제로 있는지, 기록이 바뀌었는지, 결제가 들어왔는지를 외부에서 다시 확인하는 방식입니다. 다른 에이전트가 그 증거를 검토할 수는 있지만, ‘두 번째 모델이 완료된 것 같다고 판단했다’는 말 자체를 증거로 삼고 싶지는 않습니다.
• @talaizikov — 두 개의 소규모 앱에서 AI로 마케팅을 운영하며 작업 수행 자체는 병목이 아니라고 느꼈습니다. 신뢰의 경계가 문제였습니다. 되돌릴 수 있는 정도에 따라 작업을 나누는 방식이 도움이 됐습니다. 초안 작성, 개인 블로그 게시, 자체 사이트 수정은 자동으로 진행하고, 제 이름으로 공개되는 보도자료나 이메일은 승인을 기다립니다. 에이전트의 보고가 아니라 실제 페이지가 열리거나 게시물이 보이는지 확인해야 완료로 처리합니다. OSIO는 되돌릴 수 있는 정도를 명시적으로 모델링하나요, 아니면 도구별 권한으로 관리하나요?
  • @Leon Orien — 두 방식이 조금씩 들어가지만, 되돌릴 수 있는 정도를 도구 권한 하나로만 다루지는 않습니다. 권한은 단순히 ‘이 도구를 써도 된다’가 아니라 실제로 의도한 효과와 범위에 연결돼야 합니다. 되돌리기 어려운 정도는 그 위에 얹는 위험 신호에 가깝습니다. 되돌릴 수 없는 작업도 허가할 수는 있지만, 사람을 부르지 않고 진행하는 데는 훨씬 신중해야 합니다.
• @brianainews — 권한, 실행, 제공자의 확인 응답, 현실의 결과를 구분하는 틀이 적절합니다. 결과를 쉽게 확인할 수 있는 연체 청구서 후속 연락 같은 업무부터 시작하고, 시도한 행동과 고객 반응을 모두 기록하면 좋겠습니다. 자율성을 넓히기 전에 사업주에게 구체적인 신뢰 확인 과정을 제공할 수 있습니다.
  • @Leon Orien — 그래서 처음에는 결과를 어느 정도 관찰할 수 있는 업무가 유용하다고 생각합니다. 연체 청구서 후속 연락이 좋은 예입니다. 이메일을 보냈다는 사실뿐 아니라 전송 기록을 다시 확인하고 답장을 살피며, 나중에는 청구서 결제 여부도 확인할 수 있습니다. ‘도구가 성공을 반환했다’는 것보다 훨씬 강한 근거가 됩니다.

원문: Indie Hackers / 번역·요약: Trawling