지난 글에서 AI와 함께 생각하는 법을 이야기했어요. AI에게 맥락을 주니 검색 도구가 사고 파트너가 되었다는 이야기였죠.
이번에는 그다음 단계예요. 생각하는 방식이 바뀌고 나니, 자연스럽게 일하는 방식도 바뀌기 시작했어요. 특히 반복되는 업무를 마주할 때마다 드는 생각이 하나 있었어요.
“이거, 너무 귀찮다.. 또 하고 있네.”
같은 포맷으로 매주 보고서를 쓰고, 같은 구조로 기획서를 정리하고, 같은 유형의 질문에 같은 맥락으로 답변하고. 하나하나는 크지 않은 일이지만, 쌓이면 하루의 상당 부분을 차지하고 있었어요.
그때 드는 생각이 하나 있어요. “같은 작업을 세 번 했다면(반복한다면), 네 번째부터는 AI가 해야 한다.”
이번 글은 그 생각을 개인 업무에서 팀 업무까지 확장해 나간 이야기입니다.
· 반복을 발견하는 눈
· 개인의 반복을 없애다
· 팀의 반복을 없애다
· 도구는 바뀌어도, PO의 본질은 같다
AI로 업무를 자동화하겠다고 하면, 대부분은 먼저 거창한 시스템을 떠올려요. 대시보드를 만들거나, 봇을 개발하거나, 복잡한 파이프라인을 설계하거나.
그런데 저한테 실제로 가장 효과가 컸던 건, 아주 작은 반복을 발견하는 것이었어요.
어느 날 스스로에게 이런 질문을 던져봤어요. “지난 한 달간, 내가 반복한 업무가 뭐지?”, "내가 계속하는 업무들을 자동화할 수 있을까?" 그리고 AI에게 그간의 대화 기록을 분석해 달라고 요청했어요.
결과가 꽤 충격적이었어요. 제가 계속 혼잣말로 되뇌던,, "이거, 너무 귀찮다.. 또 하고 있네."라고 말하게 만들던 것들이 모두 가능하다고 도출되었거든요. 매주 반복하는 주간 보고서 작성, 비어 있는 프로젝트 관리 티켓을 찾아서 내용을 채우는 작업, 슬랙에서 온 요청을 기획서로 정리하는 작업, 프로모션 정책에 대한 반복 문의 응대. 이런 것들이 효율화 가능한 명확한 패턴으로 나타났어요.
흥미로운 건, 이 반복들을 하나하나 직접 하고 있을 때는 “원래 그런 거지”라고 느꼈다는 거예요. 반복이라는 사실 자체를 인식하지 못하고 있었어요. 매주 하니까 당연한 업무라고 생각했던 거죠.
반복을 발견하는 것. 이게 자동화의 첫 번째이자 가장 중요한 단계였어요.
반복 패턴을 발견하고 나서, 가장 먼저 손댄 건 제 개인 업무였어요. 세 가지 사례를 소개할게요.
사례 1. 주간 보고서 — 2시간이 10분이 되다
매주 금요일, 저는 6~8개의 슬랙 채널을 돌아다니며 이번 주에 무슨 일이 있었는지 하나하나 확인하고, 네 개 섹션으로 나누어 정리했어요. 완료된 업무 중심으로 정리하고, 정량적 지표를 포함하고, 경어체로 작성하는 것이 우리 팀의 포맷이었죠.
지난 글에서 이야기한 ‘맥락 세팅’이 여기서 빛을 발했어요. AI에게 우리 팀의 보고서 구조, 톤, 참고해야 할 슬랙 채널 목록을 미리 세팅해 두었거든요.
세팅은 이렇게 했어요. AI에게 “주간 보고서는 네 개 섹션으로 나누고, 각 섹션에는 이런 슬랙 채널의 내용이 들어간다”는 규칙을 알려주고, 참고할 채널 목록과 작성 톤(“완료 업무 중심, 경어체, 정량 지표 포함”)을 미리 저장해 뒀어요. 일부 AI 도구에서는 이런 반복 작업을 ‘스킬’이나 ‘워크플로우’로 저장할 수 있어서, 한 번 만들어두면 매주 동일한 품질로 초안이 나와요.
이제는 “이번 주 위클리 정리해 줘”라는 한마디에, AI가 슬랙 채널들을 자동으로 훑고 섹션별로 분류한 초안을 만들어줘요. 저는 그 초안을 검토하고 맥락에 맞게 보완하는 것만 하면 됩니다.
처음에 2시간 가까이 걸리던 작업이 10분 내외로 줄었어요. 하지만 더 중요한 건 시간 절약이 아니에요. 보고서 작성에 쓰던 에너지가 “이번 주 우리 팀이 실제로 어떤 임팩트를 만들었는가”를 생각하는 데로 옮겨간 거예요.
사례 2. 기획서 초안 — 슬랙 한 줄에서 문서까지
PO라면 공감할 텐데, 기획의 시작은 대부분 슬랙이에요. 누군가가 스레드에 요청을 남기고, 거기에 논의가 쌓이고, 그걸 정리해서 기획서로 만드는 과정이 반복돼요.
이것도 AI에게 맥락을 세팅해 뒀어요. 기획서 구조 자체를 AI에게 템플릿으로 알려둔 거예요. “개요에는 문제 정의, 목표, 타겟, 제약조건을 넣고, 요구사항은 사용자 시나리오로 시작한 뒤 상세 내용을 붙여라. 필요하면 다이어그램을 넣어라.” 이런 식으로요. 여기에 “구현 방식은 상세하게 쓰지 말 것, How는 만드는 사람에게 여지를 남길 것”이라는 원칙까지 넣어두었어요.
이제는 슬랙 스레드 링크 하나를 던지면, AI가 스레드의 논의를 읽고 기획서 초안을 자동으로 생성해요. 배경, 목표, 요구사항, 제약조건까지 정리된 상태로요. 물론 그대로 쓰지는 않아요. 하지만 빈 문서 앞에서 “어디서부터 쓰지? “라는 고민이 사라진 것만으로도 큰 차이예요.
사례 3. 데이터 분석 — 자연어로 쿼리를 쓰다
저는 비개발자예요. SQL을 직접 짜는 게 쉽지 않았어요. 그런데 업무상 데이터를 직접 확인해야 할 일이 많았어요. “이번 달 특정 쿠폰의 발급 건수와 사용률이 얼마지?”, “채널별 성과를 비교해 보고 싶은데” 같은 질문들이요.
지난 글에서 이야기한 것처럼, AI에게 우리 팀이 쓰는 데이터 테이블 구조를 미리 알려두었어요. 자주 조회하는 테이블 이름, 주요 컬럼, “이 지표는 이렇게 계산한다”는 정의를 텍스트로 정리해서 넣어둔 거예요. 그랬더니 “지난주 쿠폰 A의 발급 대비 사용률 알려줘”라고 자연어로 물으면, 해당 테이블에 맞는 쿼리가 바로 생성되더라고요.
비개발자가 데이터에 직접 접근할 수 있게 된 건, 단순히 편해진 것 이상의 의미가 있었어요. 데이터 확인을 위해 개발자나 DA에게 요청하고 기다리는 시간이 사라졌고, “이 숫자가 왜 이런지”를 탐색할 수 있게 되었으니까요.
개인 업무의 반복을 줄이고 나니, 자연스럽게 팀 전체의 반복이 보이기 시작했어요. 특히 “이 질문, 또 왔네”라는 순간이 잦았어요.
사례 4. 반복 문의 봇 — 같은 질문에 같은 답을 하지 않기
우리 팀은 사내에서 프로모션 정책에 대한 문의를 꽤 자주 받아요. “이 쿠폰 중복 적용 되나요?”, “프로모션 요청은 어디에 하나요?”, “이 용어가 무슨 뜻이에요?” 같은 질문들이요.
질문 하나하나는 1~2분이면 답할 수 있지만, 이게 하루에 서너 번씩 쌓이면 꽤 많은 시간이 돼요. 그리고 무엇보다, 같은 질문에 같은 답을 반복하는 건 질문하는 쪽도, 답변하는 쪽도 비효율적이에요.
그래서 회사 내부의 AI 플랫폼을 활용해서 프로모션 Q&A 봇을 만들었어요. 봇을 만드는 과정도 생각보다 간단했어요. 기존에 정리해 둔 정책 문서, 운영 가이드, 용어집을 봇에 연결하고, “이 문서들을 기반으로 답변하되, 문서에 없는 내용은 추측하지 말고 담당자를 안내해 줘”라는 규칙을 설정했어요. 요즘 대부분의 AI 플랫폼이 문서를 연결하고 규칙을 설정하는 기능을 제공하고 있어서, 코드를 짤 줄 몰라도 이 정도는 충분히 할 수 있어요.
슬랙에서 봇을 멘션 하면 문서를 기반으로 답변을 생성하도록 설계했죠. 봇이 모든 질문에 완벽하게 답할 수 있는 건 아니에요. 문서에 없는 내용은 “담당자에게 연결해 드릴게요”라고 안내하도록 했어요. 핵심은 “전체를 대체하자”가 아니라 “반복되는 70%를 자동화하자”였어요.
사례 5. 슬랙 메시지 → 자동 DB 입력 — 삼중 입력을 없애다
이건 조금 더 큰 자동화 사례예요. 영업 담당자분들이 새로운 프로모션 딜을 따오면, 그 정보를 슬랙에 기록하고, 다시 스프레드시트에 옮기고, 다시 어드민 시스템에 입력하고 있었어요. 같은 정보를 세 번 입력하는 거죠.
AI 팀과 협의해서, 영업 담당자가 슬랙에 메시지를 남기면 AI가 그 내용을 파싱 해서 데이터베이스에 자동으로 넣는 시스템을 설계했어요. 메시지에서 가맹점명, 프로모션 기간, 할인 조건, 예산 같은 정보를 추출하고, 누락된 필드가 있으면 같은 스레드에서 추가 요청을 보내는 구조예요.
이건 PO가 기획서를 써서 개발팀에 요청한 케이스인데, 여기서 중요한 건 “PO가 직접 코드를 짰느냐”가 아니에요. 반복 패턴을 발견하고, 해결 가능한 구조를 설계하고, 그걸 실행 가능한 형태로 정리한 것. 그게 PO의 역할이었어요.
두 편의 글을 쓰면서 계속 돌아오는 생각이 하나 있어요.
AI가 해준 건 결국 ‘실행’이에요. 반복 업무를 대신 처리하고, 초안을 만들어주고, 데이터를 정리해 주는 것. 하지만 그전에 “이게 반복이다”라고 인식하는 것, “이 반복을 이런 구조로 줄일 수 있다”라고 설계하는 것, 그건 여전히 사람의 몫이에요.
지난 글에서 “AI를 잘 쓰는 건 기술이 아니라, 내 업무를 구조화하는 능력의 문제”라고 했었는데요, 자동화도 마찬가지예요. 어떤 도구를 쓰느냐보다, 무엇을 자동화할지 판단하는 눈이 더 중요해요.
PO의 본질은 아마 이런 거 아닐까 싶어요. 문제를 발견하고, 구조화하고, 해결 방법을 설계하는 것. AI 시대에 PO에게 필요한 건 더 많은 기능을 만드는 게 아니라, 더 적은 반복을 만드는 것일 수 있어요.
저는 이렇게 절약한 시간을 다시 활용해서 더 많은 생각을 할 수 있게 되었고, 최근에는 Claude Code나 Skills를 적용해서 업무에 활용하는 방향으로 좀 더 개선할 수 있게 되었어요. 이뿐만 아니라 팀의 레포를 Clone 해서 Terminal 환경에서 실제 구현이 어떻게 되었는지를 확인하고 정책을 정리하는 과정을 업무에 적용해보기도 했어요. 이는 모두 전반적으로 PO의 업무 역량을 크게 확장하는 계기로 동작하게 되었습니다. 제가 더 많은 일을, 더 효율적이고 효과적으로 수행할 수 있게 된 거예요.
마지막으로 한 가지. 이런 사고에 대한 실험으로 두 편의 글도 AI와 함께 썼어요. 주제를 잡고, 구조를 짜고, 사례를 정리하는 과정에서 AI는 사고 파트너이자 초안 작성 보조였어요. 하지만 무엇을 이야기할지, 어떤 경험이 의미 있는지, 어떤 톤으로 전달할지를 결정한 건 저였고요.
결국 AI는 도구예요. 좋은 도구는 사람을 대체하는 게 아니라, 사람이 더 중요한 일에 집중할 수 있게 해 줘요. 그리고 그 “더 중요한 일”이 무엇인지를 판단하는 건, 여전히 우리의 몫이라고 생각합니다.