‘AI를 쓰는 것’과 ‘AI로 조직을 운영하는 것’은 다르다. 그 차이를 구조 한 장으로.
글을 끝까지 읽으면, 1인 창업가가 어떻게 ‘AI 부서’들을 하나의 조직으로 묶어 운영하는지 구조 한 장과, 오늘 당신 워크플로에 바로 적용할 원칙 세 개를 가져가게 된다.
대부분은 AI를 도구로 쓴다. 질문하고, 답을 받고, 복붙한다. 나는 이런 사람을 프롬프트 관광객이라 부른다. 신기한 걸 구경하고 거기서 멈추는 사람. 나쁘진 않다. 다만 멈춘다.
나는 다른 걸 했다. AI를 직원처럼 고용하고, 그들을 하나의 회사로 조직했다. 이름은 yTower다.
#트레이딩 · #입찰 · #법령 … 각자 권한과 금지선이 글로 박혀 있다.
부서의 상태가 채팅이 아니라 페이지로 항상 떠 있다. 묻지 않아도 보인다.
결과를 만든 적 없는 에이전트가 채점하고, 미달이면 되돌린다.
세 층이 핵심이다. 부서마다 전담 페르소나가 있고, 트레이딩 담당은 실행 주문을 절대 만들지 않으며, 법령 담당은 “이렇게 하라”가 아니라 “이런 법이 있다”까지만 한다. 그리고 가장 중요한 건 맨 오른쪽, 만든 결과를 다른 에이전트가 의심하는 층이다.
왜 이렇게까지 했나. 나는 20년을 고장 진단(fault diagnosis)을 연구한 제어공학자다. 직업병이 하나 있다. 만든 사람과 검사하는 사람이 같으면, 고장을 못 잡는다. 만능 비서 하나에게 다 시키면 그 비서는 자기 실수를 검토할 수 없다. 그래서 만드는 부서와 채점하는 부서를 일부러 분리했다.
나는 더 똑똑한 도구를 산 게 아니라, 더 나은 조직을 설계했다.
다시 말해, AI의 한계는 모델이 아니라 구조다. 같은 모델도 어떻게 배치하느냐에 따라 관광객의 장난감이 되거나, 일을 끝내는 조직이 된다. 한 문장으로 남는 그림은 이렇다 — 직원 0명, 부서 9개, 그들을 의심하는 한 층.
그리고 솔직히, 이 그림도 골격일 뿐이다. 9개 부서 위에 십수 개의 상시 키퍼가 늘 돌아간다. 다음 호부터 하나씩 연다. 다만 각 페르소나의 프롬프트, 모델 배정 규칙, 오케스트레이션 방식, 스크립트는 공개하지 않는다. 공개는 ‘무엇이 어떻게 배치됐나’까지다.
거대한 프롬프트 하나보다, 좁은 역할 다섯 개가 정확하다. 좁을수록 정확하다.
결과를 만든 에이전트에게 “이거 맞아?”를 묻지 마라. 만든 적 없는 에이전트에게 물어라.
무엇을 해도 되고 무엇을 절대 하면 안 되는지. 없으면 조직이 아니라 사고다.