검색 -> 사고 -> 자동화, 그리고 시스템으로
지난 두 편의 글에서 AI를 사고 파트너로 쓰는 법, 그리고 반복 업무를 제거하는 법을 이야기했어요. 이번에는 한 발 더 나가볼게요. 반복을 발견하고 하나씩 없애는 것을 넘어서, 아예 시스템을 만든 이야기예요.
음.. PO가 시스템을 만들었다고?
네. 코드 한 줄 짤 줄 모르는 PO가요. 정확히 말하면, 코드는 모르지만 AI에게 일을 시키는 법을 알게 된 PO가요.
이 글은 설정 파일 하나에서 시작해서, 팀 대시보드, 자동 브리핑 봇, 지식 검색 시스템까지 만들어간 과정의 이야기입니다.
· 코드를 모르면 자동화를 못 한다?
· 시스템의 시작은 파일 하나였다
· 팀의 뇌를 만들다 — 대시보드와 브리핑
· 지식을 연결하다 — 검색에서 종합으로
· PO가 시스템을 만든다는 것
코드를 모르면 자동화를 못 한다?
이전 글에서 “같은 작업을 세 번 했다면(반복한다면), 네 번째부터는 AI가 해야 한다.”는 원칙을 세웠다고 했어요. 그리고 실제로 주간 보고서, 기획서 초안, 데이터 분석 같은 개인 업무의 반복을 줄였어요. 그런데 여기서 한 가지 벽이 있었어요.
개인 업무의 자동화는 “AI에게 말로 시키면” 됐어요. 하지만 팀 전체가 쓰는 시스템을 만들려면, 뭔가 더 필요했어요. 대시보드를 만들어야 하고, 봇을 돌려야 하고, 스케줄러를 설정해야 했어요. 전부 “개발”의 영역이었어요.
서두에 이야기했듯 저는 비개발자입니다. HTML, CSS 같은 것이 뭔지는 아는데 직접 짜본 적은 없고, 터미널은 가끔 명령어 복붙하는 수준이었어요. 그런데 지금은 터미널에서 AI와 대화하면서 시스템을 만들고 있어요. 코드를 직접 짜는 게 아니라, AI에게 “이런 걸 만들어줘”라고 설명하고, AI가 만든 결과를 확인하고, 다시 피드백하는 과정을 반복하는 거예요.
PO가 원래 하는 일과 정확히 같아요. 기획서를 써서 개발자에게 전달하는 것처럼, AI에게 요구사항을 전달하는 거예요. 다만 피드백 루프가 몇 주가 아니라 몇 초라는 점이 다를 뿐이에요.
시스템의 시작은 파일 하나였다
거창한 아키텍처 설계부터 시작한 게 아니에요. 시작은 정말 단순했어요. 1편에서 AI에게 ‘맥락’을 세팅한다고 이야기했잖아요. 그때는 AI 도구의 설정 화면에서 텍스트를 입력하는 수준 B이었어요. 그런데 터미널 기반의 AI 코딩 도구를 알게 되면서, 이 맥락을 ‘파일’로 관리할 수 있게 되었어요.
마크다운 파일 하나에 이런 내용을 적었어요.
| – 우리 팀의 이름, 구성원, 각자의 역할 – 프로젝트 관리 도구의 프로젝트 키 – 참고해야 할 메신저 채널 목록 – 데이터베이스 테이블 구조와 주요 지표 정의 – 문서 작성 시 지켜야 할 톤과 포맷 |
이 파일 하나가 프로젝트 폴더에 들어가면, AI가 해당 폴더에서 작업할 때 이 파일을 자동으로 읽어요. 별도로 설명하지 않아도 우리 팀의 맥락을 이해한 상태에서 시작하는 거예요. 그리고 여기에 ‘스킬’이라는 개념을 추가했어요. 스킬은 특정 작업을 위한 사전 정의된 지시문이에요. “주간 보고서를 쓸 때는 이 채널들을 참고하고, 이 포맷으로 작성해라”는 규칙을 파일로 저장해 두는 거예요.
한 줄 명령어로 주간 보고서 초안이 완성되는 순간, 느꼈어요. 이건 단순히 “편해진” 게 아니라, 시스템이 만들어지고 있다는걸요. 파일 하나, 스킬 하나를 추가할 때마다 AI가 할 수 있는 일이 누적되고 있었어요.
팀의 뇌를 만들다 — 대시보드와 브리핑
설정 파일과 스킬이 쌓이면서, 자연스럽게 “이걸 나만 쓰는 게 아니라 팀이 쓸 수 있으면 좋겠다”는 생각이 들었어요. 가장 먼저 만든 건 팀 대시보드였어요.
우리 팀은 프로젝트 관리 도구에서 이슈를 관리하고, 메신저에서 소통해요. 그런데 “지금 팀 전체가 어디까지 왔는가”를 한눈에 볼 수 있는 화면은 없었어요. 매번 이슈 목록을 열어서 필터를 걸고, 채널을 돌아다니며 상황을 파악해야 했어요.
AI에게 이렇게 말했어요. “프로젝트 관리 도구에서 우리 팀 이슈를 가져오고, 메신저에서 오늘 논의된 내용을 수집해서, 팀원별 이슈 현황과 채널 활동을 보여주는 대시보드를 만들어줘.”
AI가 HTML 파일을 만들었어요. 그걸 코드 저장소에 올리고 웹 페이지로 배포했어요. 팀원들에게 URL 하나를 공유하니, 누구나 브라우저에서 팀 현황을 볼 수 있게 되었어요.
여기서 한 발 더 나갔어요. “이 대시보드를 10분마다 자동으로 업데이트할 수 있어? “라고 물었더니, AI가 맥북의 스케줄러를 설정해 줬어요. 이제 노트북이 켜져 있는 동안 10분마다 최신 데이터로 대시보드가 갱신돼요.
그다음으로 만든 건 자동 브리핑 봇이에요.
PO의 아침은 보통이래요. 메신저를 열고, 밤사이 올라온 메시지를 하나하나 확인하고, 내가 멘션 된 것, 내가 결정해야 할 것, 참고만 하면 되는 것을 머릿속에서 분류해요. 12개가 넘는 채널을 훑는 데 30분은 걸려요.
이것도 AI에게 시켰어요. “밤사이 내가 멘션 되었거나 내 이름이 언급된 메시지를 모든 채널에서 찾아서, 결정 필요 / 액션 필요 / 참고 / FYI로 분류해서 아침에 DM으로 보내줘.”
스케줄러를 설정해서 평일 아침 8시 50분에 자동 실행되도록 했어요. 노트북을 이동 중에 못 켰더라도, 다음에 켜는 순간 누락된 구간을 자동으로 따라잡도록 설계했어요.
이제 출근하면 브리핑이 와 있어요. 12개 채널을 직접 훑는 대신, 분류된 요약을 읽고 중요한 것부터 처리해요. 아침 30분이 5분이 되었어요.
지식을 연결하다 — 검색에서 종합으로
대시보드와 브리핑이 “현재”를 보여줬다면, 다음으로 필요했던 건 “과거”에 접근하는 방법이었어요.
우리 팀의 지식은 여기저기 흩어져 있어요. 문서 도구에 정책 가이드가 있고, 프로젝트 관리 도구에 기획 이슈가 있고, 메신저 스레드에 논의 맥락이 있어요. “지난달에 논의했던 쿠폰 정책 변경 건, 어디 있더라? “라는 질문에 답하려면 세 곳을 다 뒤져야 했어요.
처음에는 세 곳을 동시에 검색해서 결과를 나열해 주는 스킬을 만들었어요. 그런데 팀원에게 보여줬더니 반응이 미지근했어요. “결과가 많긴 한데, 뭔가 통합된 느낌이 아니에요.”
그 피드백이 중요했어요. 사람이 원하는 건 “검색 결과 10개”가 아니라, “이 주제에 대해 우리 팀이 알고 있는 것을 한눈에 보는 것”이었어요. 그래서 스킬을 고도화했어요. 검색 결과를 나열하는 대신, AI가 결과를 읽고 종합해서 “현황 요약 → 최근 논의 내용 → 미해결 이슈 → 관련 문서 링크” 형태로 정리해 주도록 바꿨어요.
이제 “공유형 혜택”이라고 검색하면, 세 곳의 데이터를 종합한 지식 요약본이 나와요. 현재 진행 상태, 최근 팀 논의 내용, 아직 해결 안 된 이슈까지 한눈에 보이는 형태로요.
검색 결과를 보여주는 것과 지식을 종합해 주는 것은 전혀 다른 경험이에요. 전자는 “여기 찾아보세요”이고, 후자는 “이게 지금 상황이에요”예요.
PO가 시스템을 만든다는 것
지난 세 편을 관통하는 이야기를 해볼게요.
- 1편에서는 AI에게 맥락을 줬어요. 내가 누구인지, 어떻게 일하는지, 어떻게 생각하는지를 알려줬더니 검색 도구가 사고 파트너가 됐어요.
- 2편에서는 반복을 발견하고 없앴어요. 같은 작업을 세 번 이상 하고 있다는 걸 인식하고, AI에게 맡기기 시작했어요.
- 3편에서는 그 위에 시스템을 얹었어요. 설정 파일 하나에서 시작해서, 대시보드, 브리핑 봇, 지식 검색 시스템까지.
이 과정에서 코드를 직접 짠 적은 없어요. 그런데 시스템은 만들어졌어요.
왜 가능했을까요? PO의 핵심 역량이 “코드를 짜는 것”이 아니라 “무엇을 만들어야 하는지 정의하는 것”이기 때문이에요. 문제를 발견하고, 구조를 설계하고, 요구사항을 명확하게 전달하는 것. 그건 기획서를 쓸 때도, AI에게 시스템을 만들어 달라고 할 때도 같은 능력이에요.
달라진 건 하나예요. 예전에는 기획서를 쓰고 개발팀에 전달하면, 피드백까지 며칠에서 몇 주가 걸렸어요. 지금은 AI에게 전달하면 몇 초 만에 결과가 나오고, 바로 피드백할 수 있어요. 이 속도가 “PO가 직접 시스템을 만든다”는 것을 가능하게 해 줬어요.
물론 한계는 있어요. AI가 만든 코드가 완벽하지 않을 때도 있고, 사내 보안 정책과 충돌할 때도 있어요. 대시보드의 자동 갱신이 멈추는 날도 있고, 브리핑 봇이 메신저 API 제한에 걸리는 날도 있어요.
하지만 그런 문제를 만나면 또 AI에게 물어보면 돼요. “이거 왜 안 돼?” “이렇게 고쳐줘.” 디버깅조차 대화로 하는 거예요.
결론
세 편의 글을 쓰면서 결국 하고 싶었던 이야기는 이거예요.
AI 시대에 PO에게 필요한 건 코딩 능력이 아니에요. 여전히 가장 중요한 건 문제를 발견하는 눈, 구조를 설계하는 힘, 명확하게 전달하는 능력이에요. 다만 이제 그 능력의 출력 범위가 “기획서”에서 “시스템”으로 확장되었을 뿐이에요.
그리고 이 세 편의 글도 AI와 함께 썼어요. 그런데 재밌는 건, 이 글의 소재가 된 자동화 시스템들도 AI와 함께 만들었고, 그 시스템을 만드는 과정에서 나눈 대화 기록을 AI가 분석해서 에피소드를 추출해 줬다는 거예요. 메타 위에 메타가 쌓이는 이 구조 자체가, 어쩌면 AI와 일하는 방식의 본질일지도 모르겠어요.
결국 도구는 도구예요. 하지만 좋은 도구는 사람이 할 수 있는 일의 범위를 바꿔요. 그 범위가 바뀌었을 때, 무엇을 할 것인지를 결정하는 건 여전히 우리의 몫이에요.
June님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
