AI와 함께 회사의 병목 해결하기 - 회사는 커졌는데, 왜 일은 같은 사람에게 몰릴까

AI와 함께 회사의 병목 해결하기 연재 1/4
크로스 CTO의 관점에서, AI 도입과 여러 내부 프로젝트가 어떤 문제의식으로 이어졌는지 돌아봅니다.

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

2026년 크로스에서는 어드민을 새로 만들고, BI와 PMO를 구축하고, 개발봇을 통합하는 일을 추진했습니다. 각각만 보면 서로 다른 목적을 가진 프로젝트처럼 보입니다. 어드민은 오래된 기술을 바꾸는 일이고, BI는 데이터를 쉽게 보는 일이며, PMO는 프로젝트를 관리하는 일이니까요.

제가 이 일들을 통해 바꾸고 싶었던 것은 하나였습니다. 회사의 성장 속도가 오래 일한 소수의 사람이 감당할 수 있는 속도에 묶여 있는 구조였습니다.

누군가에게 물어봐야 맥락을 알 수 있고, 누군가에게 요청해야 데이터를 볼 수 있으며, 특정한 사람만 실제 문제를 해결할 수 있었습니다. 그 사람들은 점점 바빠졌고, 다른 구성원들은 의지와 역량이 있어도 기여할 수 있는 범위가 제한됐습니다.

AI를 도입하며 기대한 변화는 더 많은 사람이 회사의 상황을 이해하고, 판단하고, 실행할 수 있게 되는 것이었습니다. 이 연재에서는 그 생각이 각각의 프로젝트로 어떻게 이어졌는지 이야기하려 합니다.

우리를 성장시켰던 방식

크로스에는 개발, 제품, 마케팅, 리스크, 사업, 재무, 고객관리 등 다양한 조직이 있습니다. 국내에 거주하는 외국인을 대상으로 서비스를 제공하는 특성상 고객관리 조직의 구성원도 대부분 외국인입니다. 서로 다른 전문성과 배경을 가진 사람들이 협력해야 하므로 업무에서 소통이 차지하는 비중이 큽니다.

마케팅이 고객 유입의 최전선을 맡고, 고객관리가 고객이 서비스를 계속 이용하는 데 필요한 여러 구간을 책임집니다. 사업은 앞으로 나아갈 방향에 중요한 단서를 제공하고, 재무와 리스크는 건강한 성장과 준법을 뒷받침합니다. 제품과 개발은 이 이해관계 속에서 고객에게 우선 제공할 가치를 고민하고 구현합니다.

회사가 작았을 때는 각 조직에서 오래 일한 사람들이 모이면 많은 문제가 빠르게 해결됐습니다. 어떤 문제가 생기면 과거에 비슷한 일을 겪었던 사람이 배경을 설명하고, 다른 사람이 당시의 결정을 보충했습니다. 제품과 개발은 그 맥락을 바탕으로 해결책을 정했습니다.

이 방식은 실제로 효율적이었습니다. 오랫동안 함께 일하며 쌓은 경험과 신뢰 덕분에 설명을 줄이고 실행을 앞당길 수 있었습니다. 우리가 어려운 시기를 지나 성장하는 데도 중요한 기반이 됐습니다.

사람은 늘었지만, 맥락을 아는 사람은 충분히 늘지 않았다

임직원이 100명에 가까워지면서 각 팀의 업무는 깊어졌고, 함께 고려해야 할 이해관계도 많아졌습니다. 그런데 중요한 결정의 배경은 여전히 소수의 기억 속에 남아 있었습니다.

빠르게 일하는 동안 무엇을 결정했는지는 남겨도, 왜 그렇게 결정했는지까지 충분히 기록하지 못했습니다. 새로 입사한 사람은 현재의 결과물을 볼 수 있었지만, 그것이 만들어진 이유를 이해하려면 오래 일한 동료에게 물어야 했습니다.

협업이 늘어날수록 질문도 같은 사람들에게 몰렸습니다. 그들이 자리를 비우거나 다른 업무에 집중하면 판단이 늦어졌습니다. 반대로 빠르게 결론을 내더라도 논의에 참여하지 않은 조직의 조건을 놓쳐 뒤늦게 후속 조치를 해야 하는 일이 생겼습니다.

결정에 필요한 관점은 많아졌는데, 그 관점을 모으는 방식은 회사의 규모만큼 성장하지 못했던 것입니다.

flowchart TD
    A[조직의 성장] --> B[더 많은 협업과 의사결정]
    B --> C[소수의 경험자에게 질문과 요청 집중]
    C --> D[기존 업무와 협업 대응이 충돌]
    D --> E[맥락 공유와 기록에 쓸 여유 감소]
    E --> C
    C --> F[다른 구성원의 판단과 실행도 대기]

이 구조에서 가장 아쉬웠던 것은 새로 합류한 사람들의 기여 가능성이었습니다. 본인이 더 많이 기여하고 싶어도 필요한 맥락에 접근하기 어려웠습니다. 비교적 늦게 입사했다는 이유만으로 회사에 기여할 수 있는 보이지 않는 상한이 생긴 셈입니다.

같은 회의에서도 서로 다른 숫자를 보고 있었다

데이터에서도 비슷한 병목이 있었습니다.

내부 DBMS에 적재되는 데이터는 DBA가, GA나 Firebase, Amplitude 같은 외부 도구의 데이터는 DA가 주로 다뤘습니다. 회사의 현황을 한눈에 보려면 담당자가 여러 곳에서 숫자를 추출하고 수동으로 채워 넣어야 했습니다. 담당자가 부재하면 데이터를 기다리는 회의도 영향을 받았습니다.

숫자가 준비된 뒤에도 문제가 남았습니다. 경영진은 국가별 실적이나 전체 성과처럼 집계된 지표를 주로 봤습니다. 제품개발팀은 내부 원천 데이터와 고객 행동 데이터를 조합해 구체적인 가설을 세우고, 스프린트마다 개선 여부를 확인했습니다.

제품개발팀에서 확인한 개선이 거시적인 숫자에서는 뚜렷하게 보이지 않을 수 있었습니다. 그 차이를 연결해 설명할 공통 맥락이 부족하다 보니, 한쪽은 개선의 의미를 체감하기 어려웠고 다른 쪽은 성과가 충분히 이해받지 못한다고 느꼈습니다.

데이터 기반으로 일한다는 문화는 같았지만, 판단에 사용하는 데이터와 관측 단위가 달랐던 것입니다.

DA에도 하루에 여러 번 데이터 추출 요청이 들어왔습니다. 분석을 통해 새로운 질문과 인사이트를 찾아야 할 조직이, 다른 사람이 질문할 수 있도록 데이터를 전달하는 일에 많은 시간을 쓰고 있었습니다.

개발에서도 기여할 수 있는 범위가 좁아지고 있었다

2026년의 성장 목표는 이전보다 공격적이었습니다. 해야 할 일은 많아졌지만 각 개발 직무의 인원은 많아야 서너 명 수준이었습니다. 당시 개발 업무에서 AI 활용은 사실상 없는 상태였습니다.

인원을 늘리는 방법을 생각할 수 있습니다. 다만 채용만으로 당장의 병목을 풀기에는 다른 문제가 있었습니다. 크로스는 금융업이면서 국내 거주 외국인을 대상으로 서비스를 제공합니다. 그만큼 도메인이 깊고, 신규 입사자가 자신의 역량을 충분히 발휘하기까지 최소 2~3개월의 시간이 필요했습니다.

기존 구성원 사이에도 정보 격차가 있었습니다. 전사 요구사항 상당수가 백엔드를 거치다 보니 관련 배경과 히스토리도 백엔드에 집중됐습니다. 프론트엔드와 앱 개발자는 자신의 영역을 넘어 기여하려 해도 그 맥락을 파악하기 어려웠습니다.

오래된 기술도 역할의 편중을 강화했습니다. 사내 어드민은 AngularJS 1 기반이었고, 과거 풀스택 경험이 있는 일부 백엔드 개발자가 화면까지 유지보수했습니다. 어드민 개선 요청이 들어오면 실제로 처리할 수 있는 사람은 더욱 좁혀졌습니다.

회사를 오래 이해하고 많이 기여한 사람에게 일이 계속 쌓였습니다. 다른 구성원들의 역량을 더 넓게 활용할 수 있는데도 그 길이 충분히 열려 있지 않았습니다.

세 가지 문제에서 같은 구조가 보였다

협업, 데이터, 개발은 서로 다른 문제처럼 보였지만 구조는 닮아 있었습니다.

영역	소수에게 집중된 것	다른 구성원에게 생긴 제약
협업	과거 결정의 배경과 조직 간 맥락	판단에 필요한 설명을 기다림
데이터	데이터 접근과 추출 역량	가설을 확인하기 위해 요청하고 기다림
개발	도메인 지식과 특정 시스템의 구현 역량	기여할 수 있는 업무 범위가 제한됨

그래서 제가 풀고 싶었던 질문은 더 넓어졌습니다. 각자가 더 빨리 일하도록 돕는 동시에, 지금 특정한 사람에게 의존하는 판단과 실행을 어떻게 더 많은 사람에게 열어줄 수 있을까.

그 방향을 위해서는 공통의 정보에 접근할 수 있어야 했습니다. 회사가 무엇을 중요하게 생각하는지, 어떤 근거로 결정했는지, 지금 누가 어떤 일을 하는지 알 수 있어야 했습니다. 필요한 일을 직접 실행할 수 있는 수단도 있어야 했습니다.

이 시기에 AI 활용 사례들이 시장에 쌓이기 시작했습니다. 크로스에서도 AI를 업무에 도입할 동기가 생겼습니다. 처음부터 모든 해법이 완성돼 있었던 것은 아닙니다. 큰 방향은 있었지만, 실제로 어디까지 가능한지는 구성원들과 일을 진행하며 확인해야 했습니다.

첫 번째 시도는 약 10년의 도메인 지식이 쌓인 어드민을 바꾸는 일이었습니다. 오래된 시스템을 옮기는 과정에서, 누가 회사의 문제를 해결할 수 있는지도 함께 바꿔보고 싶었습니다.

---

다음 글: 어드민을 바꿨더니, 문제를 해결하는 사람이 늘어났다