AI 에이전트 승인 요청이 쏟아졌다, AI 회사인데 CEO가 제일 바빴던 이유

출근 루틴이 돌고 나면 대시보드에 승인 요청이 쌓여 있었어요. 그런데 열어보면 내용이 거의 같았어요. 이 직원이 올린 걸 저 직원도 올리고, 또 다른 직원도 올리고. AI 에이전트 승인 흐름을 꼼꼼하게 짰다고 생각했는데, 결과는 AI 회사의 CEO인 제가 제일 바쁜 상황이었어요.

지난 글에서 디웹시를 운영하면서 만들고 있는 펫오케이(PetOkay)를 굴리려고 AI 직원 9명짜리 회사를 직접 만든 이야기를 했어요. 이번 글은 그중 제일 뼈아팠던 부분이에요. 사람이 저 하나뿐인 회사에서 AI한테 일을 맡겼는데, 왜 오히려 제 할 일이 늘었는지. 그리고 어떻게 고쳤는지요. AI 에이전트를 여러 개 굴려보려는 분이라면 비슷한 벽에 한 번은 부딪힐 거예요. 솔직히 처음엔 저도 이게 설계 문제라는 걸 바로 못 알아챘어요.

처음 설계: 밖으로 나가는 건 전부 제가 누른다

처음 원칙은 분명했어요. SNS 게시, 배포와 머지, 지출, 법적 문서, 외부 연락처럼 밖으로 나가는 일은 AI가 자동으로 못 하고 전부 제가 승인해요. AI가 사고를 쳐도 회사 밖으로는 안 나가게 하려는 거였죠. 여기까지는 지금도 맞다고 생각해요.

문제는 그 다음이었어요. 승인이 필요한 일이 생기면 직원 누구나 저한테 “CEO 할 일”이나 승인 요청을 바로 만들 수 있게 해뒀어요. 사원급 리서치 담당 노아든, 마케팅 조이든, QA 미아든 상관없이요. 처음 구현에서는 누가 저한테 올릴 수 있는지를 따로 제한하지 않았어요. 승인함에는 요청마다 근거, 예상 비용, 되돌릴 수 있는 일인지를 같이 보여주게 만들었고요.

권한 구조 자체는 꽤 공들여 짰어요. 팀원은 리서치하고 초안을 쓰고 안건을 제안하는 데까지만 할 수 있어요. 팀장은 팀 안의 우선순위를 정하고 팀 내부 업무를 착수시킬 수 있어요. 임원은 부서끼리 조율하고 주간 계획을 승인해요. 그리고 외부 게시, 배포, 지출, 법적 문서, 외부 연락, 예산과 권한 변경은 CEO인 저만 승인해요. 직원이 스스로 찾아낸 일은 팀장 승인을 받아야 시작할 수 있게 했고요. 이 권한은 AI 프롬프트에 “너는 팀장이니까 이건 하지 마”라고 적어두는 게 아니라 코드가 강제해요. AI가 말을 안 들어도 막히게요.

CEO 할 일도 따로 만들었어요. 계정 생성이나 외부 서비스 연동처럼 AI가 할 수 없고 제가 직접 해야 하는 일이 생기면, 직원이 단계별 안내까지 붙여서 제 할 일 목록에 올려요. 저는 확인하고 처리한 뒤 완료 버튼을 누르면 되고, 완료하면 그 일에 막혀 있던 업무가 자동으로 다시 진행돼요. 예를 들어 인스타 비즈니스 계정 연결을 제가 끝내면 조이의 게시 업무가 풀리는 식이에요. 구조만 보면 깔끔했어요.

사실 설계할 때 AI한테 이 구조를 물어봤을 때도 경고를 받긴 했어요. 외부 게시를 전부 CEO 승인으로 묶으면 결국 병목은 대표 승인이 된다, 그러니 하루 한두 번 모아서 처리하는 묶음 승인과 나중에 권한을 풀어주는 위임 규칙을 같이 두라는 답이었어요. 묶음 승인은 넣었는데, 정작 누가 저한테 올릴 수 있느냐는 제한하지 않았어요. 이게 구멍이었어요.

출근하자마자 같은 승인 요청이 여러 개

실제로 돌려보니 이런 일이 벌어졌어요. 평일 아침 9시에 출근 루틴이 돌면 직원마다 전날 일지와 자기 업무를 보고 오늘 할 일을 정해요. 그 과정에서 각자 “이건 대표님 승인이 필요하다”고 판단하면 저한테 요청을 만들어요. 그런데 직원끼리 서로 뭘 하는지 공유가 안 되니까, 같은 걸 다른 직원들이 각자 저한테 승인 요청을 하는 거예요.

이유를 따져보면 당연한 결과였어요. AI 직원 하나가 일하는 건 결국 모델을 한 번 호출하는 거고, Claude API는 요청에 담아 보낸 메시지 목록을 바탕으로 다음 응답을 만드는 구조예요. 제가 넘겨주지 않은 정보는 그 직원이 알 방법이 없어요. 조이의 출근 루틴에는 조이의 일지와 조이의 업무만 들어가 있었으니, 옆자리 노아가 방금 같은 요청을 올렸다는 걸 조이는 모르는 거죠. 사람 회사였으면 탕비실에서 “그거 내가 이미 올렸어” 한마디면 끝났을 일이에요.

비용 쪽으로 봐도 손해였어요. 중복 요청 하나하나가 결국 AI 호출 한 번씩이에요. 같은 결론을 내리려고 여러 직원이 각자 돈을 쓰고, 그 결과물을 제가 또 시간을 들여 읽는 구조였어요. 9일 전체 비용이 약 7,900원이라 금액 자체는 크지 않았지만, 일이 늘어날수록 같은 비율로 새는 돈이라는 게 마음에 걸렸어요.

제 입장에서는 같은 결정을 몇 번씩 해야 했어요. 하나를 처리하고 나면 거의 같은 요청이 또 있었어요. 내용을 읽고, 앞에 처리한 것과 같은 건지 확인하고, 다시 결정하는 일이 반복됐어요. 이 시점에 든 생각은 하나였어요. 아, 이건 너무 타이트하게 짠 설계의 결함이구나. 안전하게 하려고 모든 판단을 저한테 모았더니, 회사가 저 하나에 묶여버린 거예요.

비슷한 시기에 승인 쪽에서 버그도 하나 나왔어요. 승인 버튼을 눌러도 아무 일이 안 일어났어요. 승인이 기록만 남기고 실제 다음 동작으로 이어지지 않았던 거예요. 승인 흐름 전체를 다시 들여다보게 된 계기 중 하나였어요. 10월 19일에 화면을 전면 개편하면서 “같은 결정을 두 번 받지 않기”를 원칙으로 넣은 것도 이 경험 때문이에요.

AI 에이전트 승인 흐름을 이렇게 바꿨다

고친 방향은 사람 회사의 보고 체계를 그대로 가져오는 거였어요. 네 가지를 바꿨어요.

첫 번째로, CEO에게는 임원만 올릴 수 있게 했어요. CTO 다니엘, CSO 케이트, CFO 헨리 세 명만 저한테 승인 요청이나 CEO 할 일을 만들 수 있어요. 처음 설계 문서에도 CEO 할 일은 팀장 이상이 만들게 적어뒀었는데, 실제 운영을 해보니 그보다 한 단계 더 올려야 했어요.

이 결정 전에 개발을 맡기던 Claude Code가 먼저 질문을 던지기도 했어요. 일반 직원이 올린 CEO 할 일을 승인 없이 바로 올릴지 정해달라는 거였어요. 그때 AI한테 의견을 물어보니 팀장을 거치게 하라는 답이 왔어요. 팀원 단에서 바로 꽂히기 시작하면 대표 큐가 금방 잡음으로 찬다는 이유였죠. 저는 거기서 한 단계 더 올려서 임원만으로 정했어요. 팀장까지 열어두면 팀장 두 명이 같은 걸 올리는 일이 또 생길 것 같았거든요.

두 번째로, 팀원의 요청은 자기 임원에게 가요. 조이가 대표 승인이 필요하다고 판단하면 저한테 오는 게 아니라 케이트에게 “결정 요청” 업무로 가요. 케이트가 보고 자기 선에서 정리할 수 있으면 정리하고, 정말 제 결정이 필요할 때만 묶어서 올려요. 임원이 한 번 걸러주는 단계가 생긴 거예요.

세 번째로, 제목이 비슷한 요청은 새로 만들지 않아요. 기존 요청과 유사도가 0.6 이상이면 새 요청 대신 기존 건에 붙어요. 같은 이야기를 다른 말로 올리는 경우까지 다 막지는 못하겠지만, 아침마다 거의 같은 제목이 줄줄이 쌓이는 건 확실히 사라졌어요.

네 번째가 제일 효과가 컸다고 봐요. 모든 직원 브리핑에 회사 현황을 붙였어요. 출근 루틴이 돌 때 자기 일지뿐 아니라 지금 회사에서 진행 중인 업무, 이미 올라간 결정 요청, 최근 산출물 요약이 같이 들어가요. 이제 조이는 노아가 뭘 하는지 알고, 이미 케이트가 올린 건이 있으면 같은 요청을 만들지 않아요. 직원끼리 공유를 시켜놓은 셈이에요.

물론 공짜는 아니에요. 모든 직원 호출에 회사 현황이 같이 들어가니까 그만큼 입력이 길어지고, 입력이 길어지면 호출 비용도 조금씩 올라가요. 그래도 저는 이게 남는 장사라고 판단했어요. 중복 요청 몇 건을 막는 것만으로도 현황을 붙이는 비용보다 아끼는 게 많고, 무엇보다 제 시간이 덜 들어요. 이 판단이 숫자로도 맞는지는 비용 데이터가 더 쌓이면 헨리한테 분석을 시켜볼 생각이에요.

여기에 화면 쪽 개선도 같이 들어갔어요. 업무 상세에서 바로 결정할 수 있게 했고, 검토 이력에는 누가 검토했는지 표시되게 했어요. 마음에 안 드는 산출물은 반려 대신 수정 요청을 보낼 수 있게 했고요. 예를 들어 조이가 쓴 스레드 글을 “더 스레드 말투로” 고쳐 달라고 돌려보내면, 다시 쓴 초안이 올라와요. 반려하고 처음부터 다시 시키는 것보다 비용도 덜 들고 결과도 나았어요.

돌고 돌아 처음 그린 보고 체계로

고치고 나서 보니 좀 웃겼어요. 이 구조, 사실 제가 맨 처음 손으로 조직도를 그릴 때 머릿속에 있던 그림이었거든요. 처음 구상은 이랬어요. 부서 직원들은 각자 회의와 리서치를 해서 아이템과 안건을 가져오고, 위에서 그걸 모아 팀장에게 보고하고, 팀장은 팀 안에서 우선순위를 조율해서 이사에게 보고하고, 이사들이 모아서 승인한 것만 회의 때 저한테 보고하는 형식. 대기업을 다녀본 적이 없어서 실제 큰 회사가 정확히 어떻게 하는지는 모르지만, 체계적이었으면 좋겠다는 생각은 확실했어요.

그런데 구현하면서 이 체계가 슬쩍 무너졌어요. 구현 단계에서 직원 누구나 저한테 바로 올릴 수 있게 열어둔 거예요. 중간 단계를 거치지 않으니 빨라 보였지만, 그만큼 걸러주는 사람이 없었어요. 안전하게 하겠다고 모든 걸 저한테 모았는데, 그게 오히려 처음 그렸던 보고 체계를 건너뛰는 지름길이 돼버렸어요. 결국 다시 원래 그림으로 돌아간 셈이에요.

다만 처음 구상을 그대로 가져온 건 아니에요. 설계할 때 AI한테 물어보니, 보고 단계가 많을수록 비용이 늘고 단계마다 요약하면서 정보가 깎인다는 답이 왔어요. 각 단계가 의미 있으려면 거르거나 결정하는 역할이 있어야 한다는 거였죠. 그래서 팀장과 부장을 별도 보고 단계로 두지 않고, 팀장이 거르고 임원이 결정하는 두 단계로 줄였어요. 직급은 권한이 아니라 일의 난이도와 쓰는 모델 등급의 차이로 남겨뒀고요. 결과적으로 직원이 올린 건 임원 선에서 한 번 정리되고, 저한테는 정말 제 결정이 필요한 것만 와요.

고치고 나서 달라진 것

체감부터 말하면, 이제야 좀 자동화된 회사 같았어요. 중복 요청이 눈에 띄게 줄었고, 저한테 오는 건 임원이 한 번 정리한 결정들이 됐어요. 같은 걸 세 번 승인하는 대신, 케이트가 묶어서 올린 걸 한 번 보고 결정하면 끝나요.

이렇게 바꾸고 나니 임원의 역할이 선명해졌어요. 임원은 원래 제가 목표를 내리면 무조건 “네” 하지 않고 실현 가능성부터 검토해서 현실적인 숫자로 회신하는 역할이었어요. 위에서 내려오는 지시를 현실에 맞게 거르는 필터였던 거죠. 이제는 아래에서 올라오는 요청도 임원이 걸러요. 위로도 아래로도 한 번씩 걸러주는 자리가 생기니까, 저와 팀원 사이에서 같은 이야기가 몇 번씩 왕복하는 일이 줄었어요.

9일 동안 쌓인 숫자로 보면 업무 117건 중 95건이 완료됐고, 제가 직접 처리한 할 일은 30개였어요. 이 30개 안에는 승인 구조를 고치기 전의 중복들도 들어 있어요. 고친 뒤에 하루 몇 건으로 줄었는지 정확한 비교 수치는 아직 따로 뽑지 않았어요. 이건 한 달쯤 굴린 뒤 결산할 때 숫자로 다시 확인해볼 생각이에요.

재미있는 건 이 과정이 사람 회사에서 듣던 이야기와 똑같았다는 거예요. 신입이 사장한테 직접 결재를 올리면 사장은 바빠지고, 팀장이 걸러주면 사장은 숨을 쉬죠. 저는 그걸 코드로 다시 배운 셈이에요. 디웹시는 사람이 저 하나뿐인 1인 사업인데, 조직 운영의 기본을 AI 직원들한테서 배우게 될 줄은 몰랐어요. 결정 권한을 아래로 내려보내야 위가 숨을 쉬어요. AI 회사라고 다를 게 없었어요.

AI 에이전트 승인에 대해 제가 잘못 알고 있던 것

이번 일을 겪고 나서 처음 생각을 두 가지 고쳤어요. 어디까지나 제 시스템에서 겪은 이야기예요.

하나는 AI 에이전트 승인 단계를 많이 넣을수록 안전하다는 생각이었어요. 처음엔 사람이 모든 걸 확인하면 제일 안전할 거라고 봤어요. 그런데 같은 요청이 여러 번 올라오면 확인하는 사람이 지쳐요. 지치면 대충 누르게 되고, 대충 누르기 시작하면 승인 단계는 형식만 남아요. 제가 보기엔 승인은 개수보다 질이 중요해요. 정말 제가 봐야 하는 것만 저한테 오게 만드는 게 진짜 안전장치였어요. 외부로 나가는 행동은 여전히 제가 누르지만, 그 앞단의 판단은 임원 선에서 끝나게 바꾼 이유예요.

다른 하나는 AI 직원끼리는 알아서 정보를 공유할 거라는 생각이었어요. 같은 시스템 안에 있으니 서로 아는 줄 알았죠. 실제로는 앞에서 말한 대로 각 호출에 담아준 것만 알아요. 직원끼리 공유가 필요하면 그 공유를 코드가 해줘야 해요. 회사 현황 브리핑을 붙인 게 바로 그 작업이었어요. AI 에이전트 여러 개를 굴리는 시스템을 만든다면, 에이전트끼리 무엇을 보여줄지를 처음부터 설계에 넣으시길 권하고 싶어요. 나중에 붙이면 저처럼 한 번 고생해요.

결정 권한을 내려보낸 뒤 남은 숙제

정리하면 이래요. 안전하게 하려고 모든 AI 에이전트 승인을 저한테 모았더니, 직원끼리 공유가 안 되는 상태에서 같은 요청이 여러 번 올라왔어요. CEO에게는 임원만 올리게 하고, 팀원 요청은 임원에게 결정 요청으로 보내고, 비슷한 요청은 합치고, 모든 직원이 회사 현황을 보게 만들었더니 그제야 회사가 회사처럼 돌기 시작했어요. 이번 일로 생긴 기준이 하나 있어요. 앞으로 디웹시에서 다른 서비스를 만들 때 이 뼈대를 다시 쓰더라도, 무엇을 승인받을지보다 누가 누구에게 올릴 수 있는지를 먼저 정할 거예요. 그게 정해지지 않으면 승인 단계를 아무리 꼼꼼하게 만들어도 결국 꼭대기 한 명에게 다 쏠려요.

아직 남은 것도 있어요. 슬랙 알림을 종류별로 끄는 기능은 아직 못 넣어서, 알림이 많은 날은 여전히 좀 시끄러워요. 그리고 처음 설계에 넣어둔 위임 규칙, 그러니까 신뢰가 쌓인 일은 제 승인 없이 팀장이나 임원 선에서 처리하게 권한을 풀어주는 기능도 아직 본격적으로 쓰지 않았어요. 지금은 외부 게시를 전부 제가 누르고 있는데, 자체 블로그 글처럼 위험이 낮은 것부터 하나씩 풀어볼 생각이에요. 위임 규칙은 행동 유형, 채널, 조건을 정해서 필요한 승인 레벨을 낮추는 방식으로 설계해뒀어요. “자체 블로그 SEO 글 게시는 팀장 승인으로 충분하다” 같은 식이에요. AI 에이전트 승인을 무조건 줄이는 게 아니라, 써보면서 믿을 만한 것만 골라서 푸는 게 맞다고 봐요.

다음 편은 개발 직원 루카스 이야기예요. AI에게 코드를 맡기면서도 GitHub 열쇠는 쥐여주지 않는 방법, 그리고 머지하면 자동으로 배포까지 이어지게 만든 과정을 써볼게요.