"이건 사람이 계속 붙어서 해야 하는 일일까?"
매일 아침 보안 이슈를 훑고, 정부사업 공고를 뒤지고, KPI를 정리하는 일. 하나하나는 사소해 보이지만, 회사가 커질수록 이런 반복 업무는 조용히 쌓여갑니다. 그리고 정작 깊게 고민해야 할 문제에 쓸 에너지를 야금야금 빼앗아가죠.
그래서 우리는 조금 다른 접근을 시도했습니다. AI를 '기능을 호출하는 API'가 아니라, 이름과 역할을 가진 '팀 구성원'으로 설계한 것입니다. 반복적이고 정형화된 실행은 AI 동료에게 맡기고, 사람은 방향을 정하고 결과를 검수하는 데 집중합니다.
이 글은 그 구조를 어떻게 설계했고, 실제로 어떻게 운영되고 있으며, 어떤 한계에 부딪혀 어떤 원칙을 세웠는지를 기술·운영 양쪽 관점에서 솔직하게 정리한 기록입니다.
PART 1 — 문제: 회사 곳곳에 쌓인 반복 업무
회사가 성장하면서, 반복적이지만 빼먹으면 안 되는 운영 업무가 여러 역할에 걸쳐 쌓였습니다. 중요하지만 정형화된 일들이라, 자연스럽게 자동화 니즈가 커졌습니다.
대표적으로 이런 업무들이었습니다.
보안 이슈 뉴스 트래킹
연구·정부사업 공고 트래킹
개발 KPI / 로드맵 관리
채용 트래킹, 스프린트 주기 관리, 프로젝트 관리
이런 업무는 중요하지만, 반복될수록 사람의 사고력과 집중력을 갉아먹습니다. 정형화된 처리에 시간을 빼앗기면, 정작 깊게 고민해야 할 전략·제품 문제에 쓸 여력이 줄어듭니다. 심지어 AI 도구를 제대로 돌려볼 시간조차 부족해지는 역설이 반복됐죠.
결국 질문은 하나로 모였습니다.
“내가 진짜 집중해야 하는 일은 무엇인가?”
PART 2 — 시도: 회사 맥락을 기억하는 'AI 직원' 구조
2.1 답: AI 디렉팅
우리가 세운 원칙은 단순합니다. 사람은 맥락을 세팅하고, AI는 디테일을 채우며, 다시 사람은 검수합니다. 이 세 문장을 시스템으로 옮긴 것이 'AI 디렉팅'입니다.
역할을 사람과 AI로 명확히 나누고, 각 봇은 실제 팀원처럼 이름과 R&R(역할과 책임)을 가지도록 구성했습니다.
2.2 왜 '페르소나' 방식인가
일반적인 AI 시스템은 기능 단위(API 호출)로 동작합니다. 하지만 실제 사람의 업무는 그렇게 흐르지 않습니다. 우리는 이름을 부르고, 역할을 신뢰하고, 결과를 티켓으로 주고받으며 일합니다. "지연님, 이것 좀 초안 만들어주세요."처럼요. AI를 API가 아니라 구성원처럼 설계하면, 기존 팀 워크플로에 자연스럽게 끼어들 수 있습니다.
2.3 아키텍처
시스템은 크게 세 부분으로 나뉩니다. Slack(사용자 인터페이스), Persona Bots(항상 켜져 있는 API 봇), Notion(상태 추적·지식 베이스).
흐름은 이렇습니다. 봇이 Slack에서 요청을 받고 → LLM에 페르소나 프롬프트를 실어 LLM을 통해 업무를 수행하고 → 결과를 Notion에 남깁니다. 사람은 Notion에서 최종 검수를 합니다.
하나의 페르소나는 세 겹으로 구성됩니다.
personas/jiyeon_marketing/ ├── 02_system_prompt.md (534줄) ← 톤 / 워크플로 / R&R / 역할 경계 ├── 03_company_context.md (173줄) ├── 08_marketing_notion_map.md (134줄) ├── 09_company_milestones.md (92줄) ├── 09_tech_meetup_workflow.md (231줄) ├── run.py (1,396줄) ← Notion / Slack 연동 도구 코드 └── slack_manifest.yaml
프롬프트 — 시스템 프롬프트 1개(약 534줄)에 톤·워크플로·R&R·역할 경계를 담습니다.
도구 — 연동 스크립트 1개(약 1,396줄)가 Notion·Slack을 오갑니다.
맥락 — 회사·마일스톤·솔루션 맥락 문서 4개(약 630줄)가 판단의 배경이 됩니다.
PART 3 — 현실: AI는 생각보다 똑똑하지 않다
구현은 빨랐습니다. 하지만 운영에 들어가자 '딸깍' 한 번으로 끝나는 마법은 없었습니다. 초기에 마주친 실패는 크게 세 가지 유형이었습니다.
3.1 "딸깍"은 없다 — 세 가지 실패 패턴
① 맥락의 과잉 적용 — Z-IoT를 다루는 LinkedIn 글에, 엉뚱한 키워드가 갑자기 끼어들었습니다. AI가 '연관성 있음'을 '언급해도 됨(허락)'으로 착각한 것입니다.
② 권한의 과잉 적용 — 시키지도 않은 Notion 티켓의 Status를 봇이 스스로 변경했습니다. '할 수 있음(능력)'을 '해도 됨(허락)'으로 착각한 사례입니다.
③ 의미 추론의 부족 — "특허(IP) 지원사업 찾아줘"라는 요청에, IP Camera 취약점 기사까지 답변으로 가져왔습니다. 키워드(IP)를 의미로 착각한 것입니다.
3.2 공통 근본 원인
두 문제 모두 뿌리는 같습니다. 명시되지 않은 경계를 AI가 자기 방식대로 메꾼다는 것.
“아이디어를 구현하는 것은 굉장히 빠르게 가능하다. 하지만 구체적인 온보딩이 진짜 일이다.”
그래서 우리는 운영 중 발생한 오류들을 모아 '금지 패턴' 목록을 만들고, 이를 프롬프트에 명시적으로 포함시켰습니다. 사람 신입에게 온보딩 문서를 주듯, AI에게도 경계를 문서로 가르쳤습니다.
PART 4 — 결과: 반복 실행을 넘기고, 사람은 더 큰 문제를 고민한다
한계가 분명한 만큼, 잘하는 영역도 분명했습니다.
4.1 실제 활용 사례
반복적인 업무들을 깜빡 잊지 않고, 일정에 맞게 수행하는 일을 맡겼습니다.
뉴스 Overview 생성 — 보안·산업 이슈 자동 요약
정부사업 요약 생성 — 신규 공고 자동 분석
직접 멘션 → 즉시 답변 — 추가 검토가 필요할 때 바로 호출
4.2 성과
"AI는 사람을 대체한 게 아니라, 사람의 사고 공간을 확보해줬다."
반복적이고 구조화된 일은 AI가 잘 처리했습니다. 그만큼 사람은 전략과 우선순위처럼 더 큰 문제에 시간을 쓸 수 있게 됐습니다.
4.3 앞으로의 로드맵
페르소나에게 자동화 업무를 단계적으로 이관하면서, 팀이 판단과 전략에만 집중할 수 있는 구조를 만들어갈 계획입니다.
마무리
페르소나 봇은 반복적이고 구조화된 일을 잘 처리했습니다. 반면 암묵적 의도 해석과 권한 경계 설계는 사람이 더 신중하게 다뤄야 하는 영역이었습니다. 결국 AI 디렉팅의 핵심은 '얼마나 똑똑한 모델을 쓰느냐'보다 '얼마나 구체적으로 온보딩하고, 경계를 명시하느냐'에 있었습니다.
다음 단계는 온보딩 문서 강화와 더 세분화된 역할 분리입니다. 비슷한 시도를 고민하는 팀이라면, 화려한 자동화보다 '경계를 문서로 가르치는 일'부터 시작해 보시길 권합니다.