AI와 함께 회사의 병목 해결하기 - 같은 숫자와 같은 맥락을 보고 일하기 위해

AI와 함께 회사의 병목 해결하기 연재 3/4
BI와 PMO를 통해, 더 많은 구성원이 회사의 상황을 이해하고 판단할 수 있는 기반을 만들고 있습니다.

회차	글	중심 내용
1	회사는 커졌는데, 왜 일은 같은 사람에게 몰릴까	협업·데이터·개발에서 발견한 공통 병목과 전체 방향
2	어드민을 바꿨더니, 문제를 해결하는 사람이 늘어났다	AI 활용, 반복 가능한 이관 방식, 도메인과 역할의 분산
3	같은 숫자와 같은 맥락을 보고 일하기 위해 (지금 읽는 글)	BI·PMO를 통한 데이터 접근과 업무 맥락의 공유
4	개인의 AI 활용을 조직의 역량으로 만드는 일	개발봇·공통 툴킷, 프로젝트 간 연결과 CTO의 역할

회의 중 새로운 질문이 나왔는데 데이터를 바로 확인할 수 없다면 논의는 잠시 멈춥니다. 담당자에게 추출을 요청하고, 결과를 받은 뒤 다시 이야기를 이어가야 합니다.

진행 중인 프로젝트의 배경을 알고 싶을 때도 비슷했습니다. 자료가 어디에 있는지 찾고, 슬랙의 대화를 거슬러 올라가고, 그래도 부족하면 당시 참여자에게 물어야 했습니다.

두 상황 모두 판단하려는 의지는 있지만 필요한 정보가 손에 없는 상태입니다. 신 어드민을 통해 개발자가 기여할 수 있는 범위를 넓혔다면, BI와 PMO에서는 전사 구성원이 판단할 수 있는 기반을 넓히고 싶었습니다.

BI: 질문이 생긴 자리에서 데이터를 확인하기

기존에는 데이터가 필요하면 DA나 DBA에게 요청했습니다. 내부 DBMS와 외부 분석 도구의 오너십이 나뉘어 있어 고객 여정을 함께 보려면 여러 소스의 데이터를 조합해야 했습니다.

이 구조는 데이터를 받는 사람과 추출하는 사람 모두에게 제약이 됐습니다. 요청자는 가설을 확인하기 위해 기다려야 했고, DA는 새로운 인사이트를 찾는 일보다 반복적인 추출 요청에 대응하는 비중이 높았습니다.

BI를 추진하며 기대한 것은 누구나 필요할 때 데이터를 확인하고, 그 결과를 바탕으로 다음 질문을 할 수 있는 환경이었습니다. 접근 가능한 데이터를 바탕으로 회사의 상황을 이해하고, 문제의식과 가설을 제안하는 사람이 늘어나기를 바랐습니다.

고객 여정을 한곳에서 볼 수 있어야 했다

고객의 최초 유입에 관한 정보는 외부 도구에, 이후 서비스 이용 과정의 데이터는 내부 DB에 기록됩니다. 유입부터 서비스 이용까지 이어서 보려면 이 데이터들이 한곳에서 연결돼야 했습니다.

그래서 BI의 기반으로 데이터 웨어하우스, DW가 필요했습니다. 내부의 MongoDB, MySQL, Elasticsearch, ClickHouse, Redis 등과 외부의 GA4, Amplitude, Firebase 등 전사에 기록하는 데이터를 한곳에서 활용하는 것이 목표였습니다.

데이터를 모으는 방식에도 조건을 뒀습니다. 운영 DB를 직접 조회하는 대신 백업 데이터를 복제하고, 개인정보와 민감정보는 마스킹·해시 처리하거나 제거한 상태로 가져오도록 했습니다.

그 위에서 자연어로 데이터를 조회하고, 주요 지표는 대시보드와 스냅샷으로 반복 확인할 수 있어야 했습니다.

flowchart TD
    A[내부 서비스 데이터의 백업] --> C[개인정보와 민감정보 처리]
    B[외부 분석 도구의 데이터] --> C
    C --> D[DW: 고객 여정을 연결할 데이터 기반]
    D --> E[슬랙에서 자연어로 조회]
    D --> F[주요 지표 대시보드와 스냅샷]
    E --> G[확인 결과를 바탕으로 논의와 판단]
    F --> G

이 도식은 데이터를 활용하기 위한 구조를 나타냅니다. 조회 결과를 바로 받을 수 있다는 것과 모든 원천 데이터가 실시간으로 갱신된다는 것은 구분할 필요가 있습니다. 여기서 없애고 싶었던 기다림은 담당자가 수동으로 데이터를 추출해줄 때까지의 대기였습니다.

지금 달라진 일의 방식

BI는 DBA가 주도해 개발했고, 현재는 DA도 개발에 기여하고 있습니다. 지금은 슬랙 챗봇으로 데이터를 조회할 수 있고, 각자가 필요한 지표를 모은 대시보드도 구성할 수 있습니다.

회의에서 확인할 내용이 생기면 DA나 DBA의 응답을 기다리지 않고 그 자리에서 데이터를 조회할 수 있게 됐습니다. 가설을 확인하고 목표를 다시 논의하는 흐름을 이어가기 쉬워졌습니다.

현재 BI가 다루기 어려운 민감정보 관련 요청 등을 제외하면, DA와 DBA에게 수동 추출을 요청하는 경우는 많아야 주 1회 정도입니다. 이전에는 하루에도 여러 번 요청하던 상황에서 반복적인 의존이 크게 줄었습니다.

같은 지표를 공유하는 기반도 생겼습니다. 경영진이 보는 전체 성과와 제품개발팀이 보는 세부 개선을 연결해 설명할 수 있는 출발점입니다. BI를 열었다고 그 해석까지 자동으로 일치하는 것은 아니지만, 적어도 같은 데이터를 놓고 함께 이야기할 수 있게 됐습니다.

PMO: 논의에 참여하지 못했어도 맥락을 따라갈 수 있게

업무 맥락은 데이터보다 더 여러 곳에 흩어져 있었습니다.

개발팀은 GitLab 이슈로 일하고, 회의록과 할 일은 Notion에 남겼습니다. 보안상 민감한 문서는 내부 설치형 Confluence를 썼습니다. 제품팀은 주로 Notion을, 재무·마케팅·사업은 Google 스프레드시트와 Notion 등을 활용했습니다. 공통 소통 채널은 슬랙이었습니다.

슬랙에서 대화가 시작돼도 실제 자료가 있는 곳은 매번 달랐습니다. 멘션을 놓치면 관련 논의의 흐름을 따라가기 어려웠고, 지금 어떤 일이 우선인지 한눈에 확인하기도 어려웠습니다.

처음에는 업무를 Notion으로 일원화하려고 했습니다. 그러나 내부망의 GitLab을 연결하고, 전사 프로젝트·리소스·우선순위를 원하는 방식으로 보여주는 데 어려움이 있었습니다.

그래서 전사 협업이 필요한 프로젝트를 한곳에서 확인하는 PMO 사이트를 만들기로 했습니다. 개발을 주도한 사람은 QA Lead였습니다.

업무 목록에 배경과 참여 관계를 함께 담았다

PMO에서는 프로젝트와 참여자, 각자의 역할과 세부 태스크를 등록하고 간트차트로 진행 상황을 볼 수 있게 했습니다. 프로젝트 설명과 필수 의논 사항, 관련 자료도 함께 모았습니다. 슬랙 대화를 놓치더라도 프로젝트의 맥락을 다시 따라갈 수 있게 하기 위해서였습니다.

한 사람이 두 개 이상의 프로젝트에 참여하면 알림이 뜨는 장치도 넣었습니다. 일이 특정인에게 계속 몰리는 상황을 살펴볼 수 있도록 만든 신호입니다. 프로젝트 수만으로 실제 업무 부하를 모두 설명할 수는 없지만, 자원 배분을 논의할 때 편중 여부를 확인하는 출발점이 됩니다.

GitLab과의 동기화를 통해 PMO에서도 개발 이슈를 확인하고 다룰 수 있게 했고, 릴리즈 노트와 포스트모템 같은 제품 변경 기록도 남길 수 있도록 했습니다. PMO 기능을 대화로 이용할 수 있도록 MCP와 슬랙봇도 연결했습니다.

이렇게 PMO는 전사 프로젝트의 기록 저장소이자 중단기 로드맵을 확인하는 공간이 됐습니다.

BI와 PMO가 연결되면서 보이는 것

PMO에는 어떤 문제를 풀기 위해 누가 무엇을 하는지가 담깁니다. BI에는 그 일이 영향을 주려는 성과를 확인할 데이터가 있습니다.

PMO에서 프로젝트와 BI의 성과 대시보드를 연결할 수 있게 하면서, 진행 상황과 결과를 함께 살펴볼 기반이 생겼습니다. 개발이 끝났는지에 더해, 기대한 변화가 나타나는지, 다음 단계가 필요한지도 확인할 수 있습니다.

flowchart TD
    A[BI: 현재 상황과 문제 확인] --> B[가설과 목표 논의]
    B --> C[PMO: 프로젝트 배경과 역할 공유]
    C --> D[실행과 진행 상황 기록]
    D --> E[BI: 성과 대시보드 확인]
    E --> F[다음 단계 판단]
    F --> B

이 흐름은 앞으로 일하는 방식으로 자리 잡히게 하고 싶은 모습이기도 합니다. 도구를 연결한 것만으로 모든 프로젝트가 이 순환을 완성했다고 볼 수는 없습니다. 다만 구성원들이 같은 상황을 보고, 같은 목표 아래 실행하고, 결과를 함께 검토할 수 있는 조건을 만들었습니다.

생각할 수 있는 사람에게 필요한 조건

저는 더 많은 구성원이 문제를 발견하고 해결 방향을 제안하는 사람, 이 연재에서 말하는 Thinker가 되기를 바랍니다.

그러려면 생각의 근거가 되는 데이터와 맥락에 접근할 수 있어야 합니다. 필요한 숫자를 요청하고 기다려야 하거나, 당시 회의에 없었다는 이유로 결정의 배경을 알 수 없다면 기여의 범위는 쉽게 넓어지지 않습니다.

BI와 PMO는 그 조건을 만드는 프로젝트였습니다. 데이터를 전달받던 사람이 직접 질문할 수 있게 하고, 프로젝트의 일부만 알던 사람이 전체 맥락 속에서 자신의 역할을 이해할 수 있게 하는 일입니다.

남은 연결은 개발 과정에 있었습니다. 공통 정보에 접근할 수 있어도 개발 관련 질문과 요청이 계속 특정 동료에게 몰린다면 업무는 여전히 자주 끊깁니다. 다음 글에서는 이 구간을 다루기 위해 개발봇과 공통 툴킷을 어떻게 모았는지 이야기하겠습니다.

---

이전 글: 어드민을 바꿨더니, 문제를 해결하는 사람이 늘어났다
다음 글: 개인의 AI 활용을 조직의 역량으로 만드는 일