AI와 함께 회사의 병목 해결하기 - 어드민을 바꿨더니, 문제를 해결하는 사람이 늘어났다

AI와 함께 회사의 병목 해결하기 연재 2/4
약 10년의 도메인이 쌓인 어드민을 이관하며, AI 활용과 역할 분산의 가능성을 확인했습니다.

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

크로스에서 어드민에 기능을 추가하려면 백엔드 개발자를 기다려야 했습니다. 서버 로직이 필요해서만은 아니었습니다. 화면을 고칠 수 있는 사람도 일부 백엔드 개발자에게 집중돼 있었기 때문입니다.

어드민 프론트엔드는 AngularJS 1 기반이었고, 과거 풀스택 경험이 있는 소수의 개발자가 유지보수를 맡았습니다. CTO인 저 역시 그중 한 명이었습니다. 어드민 기능이 언제 배포될지는 뒷단 로직의 개발보다 화면을 누가 만들 수 있느냐에 달리기도 했습니다.

지난 글에서 이야기한 병목이 한 시스템에 응축돼 있었습니다. 도메인을 잘 아는 사람에게 구현과 설명, 개선 요청까지 몰리는 구조였습니다.

기술을 바꾸면서 역할도 다시 나누고 싶었다

크로스 어드민은 약 10년 동안 쌓인 사내 업무의 집합소입니다. 다양한 도메인과 예외 상황을 처리하는 기능이 곳곳에 들어 있습니다. 이를 이해하는 일과 구현하는 일이 소수에게 묶여 있었습니다.

신 어드민 프로젝트에서는 프론트엔드와 백엔드의 오너십을 분리하고 싶었습니다. 백엔드는 API와 서버 로직을 담당하고, 프론트엔드는 화면과 사용자 경험을 담당하도록 역할을 나누는 것입니다.

이렇게 하면 프론트엔드 개발자의 UX 역량을 사내 도구에도 적용할 수 있습니다. 더 나아가 기능의 배경을 이해하는 사람이 늘어나면, 어드민 개선 요청을 함께 해결할 수 있겠다고 생각했습니다.

목표는 새 어드민을 여는 것에서 끝나지 않았습니다. 오픈 이후의 업무가 계속 같은 사람에게 돌아오는 구조까지 바꾸고 싶었습니다.

AI를 실무에 들이기까지

프로젝트에 앞서 AI를 개발 업무에 사용할 수 있는지부터 검토했습니다. 금융 서비스를 만드는 조직으로서 데이터 보안과 코드 유출에 관한 조건을 확인해야 했습니다.

약 2주 동안 위험 요소를 검토하고, AI가 프로젝트의 어느 범위까지 읽을 수 있는지 규칙을 정했습니다. 기존 코드에 키값 등 민감정보가 남아 있지 않은지도 전수조사했습니다. 준비를 포함해 거의 한 달을 보낸 뒤 Claude Code를 공식적인 실무 도구로 사용하기로 했습니다.

도구를 사용할 수 있게 되자 또 다른 격차가 보였습니다. 누군가는 프롬프트 중심으로 사용했고, 누군가는 스킬과 훅, 에이전트까지 활용했습니다. 같은 도구를 쓰더라도 각자의 활용 방식에 따라 생산성의 차이가 벌어졌습니다.

그래서 공통 과제를 수행하면서 AI 활용 역량을 끌어올릴 필요가 있었습니다. 신 어드민은 AI를 주된 작업 수단으로 삼은 첫 프로젝트가 됐습니다.

큰 과제에서 반복 가능한 단위를 찾기

이관 대상은 약 500개의 API와 관련 화면이었습니다. 초기에는 전체 작업에 1년 정도를 예상했습니다. 저는 AI 활용을 통해 더 짧은 기간에 도전해보고자 5월 정식 오픈을 목표로 설정했습니다.

다른 중요한 전사 프로젝트와 병행해야 했기 때문에 팀 내 반발도 있었습니다. 목표만 앞당긴다고 작업 방식이 저절로 바뀌는 것은 아니었습니다. 실제로 이관을 반복할 수 있는 방법을 찾아야 했습니다.

진행하면서 백엔드와 프론트엔드는 기능 하나를 옮기는 작업에서 규칙성을 찾았습니다.

1. 기존 기능을 설명 가능한 문서로 만든다. 백엔드에서 기존 프론트엔드와 서버 코드를 분석해 해당 기능의 목적과 동작을 정리했습니다.
2. 새 API로 이관하고 계약을 남긴다. 백엔드 코드를 신규 어드민 API로 옮기고 API 문서를 작성했습니다. 기존 기능 분석과 API 이관에는 백엔드의 어드민 이관 스킬을 활용했습니다.
3. 공통 컴포넌트 위에 화면을 구현한다. 프론트엔드는 전달받은 HTML, JavaScript, 서비스 로직과 API 문서를 검토했습니다. 미리 정의한 디자인 컴포넌트를 활용해 일관된 화면을 만들었습니다.

flowchart TD
    A[기존 화면과 서버 코드] --> B[기능의 목적과 동작 정리]
    B --> C[새 API 구현과 API 문서 작성]
    B --> D[화면 구현에 필요한 맥락 전달]
    C --> E[공통 디자인 컴포넌트로 화면 구현]
    D --> E
    E --> F[기능 이관]

각 기능의 맥락을 명시적으로 전달하고, 반복되는 작업을 스킬과 공통 컴포넌트에 담으면서 역할을 나누기 쉬워졌습니다.

이 방식이 자리 잡은 뒤에는 하루에 10개 이상의 API를 이관하는 수준까지 진행할 수 있었습니다. 백엔드에서는 3~4명이 참여했습니다. 토큰 사용량의 제약이 생겼을 때는 다른 직무의 개발자도 같은 규칙을 따라 이관에 기여할 수 있었습니다.

개인의 사용 요령이던 것이 다른 사람도 활용할 수 있는 작업 방식으로 바뀌기 시작한 것입니다.

오픈 이후에 더 분명해진 변화

우리는 목표했던 5월까지 개발을 마쳤습니다. 이후 구 어드민과 신 어드민을 병행 운영하며 실제 사용자인 사내 구성원들의 적응을 기다렸고, 프로젝트를 마무리했습니다.

일정 내에 이관한 것도 성과였지만, 제가 더 크게 본 변화는 그 뒤에 나타났습니다.

프론트엔드 개발자들이 이관 과정에서 어드민의 기능과 도메인을 이해하면서 이후의 개선 업무를 함께 처리하기 시작했습니다. 기존 기능을 그대로 고치는 데서 더 나아가, 다른 사용자 경험과 접근 방식으로 문제를 해결하는 제안도 나왔습니다.

사내 도구를 고도화하고 작은 비효율을 개선하는 문제 해결자의 범위가 넓어졌습니다. 프론트엔드 개발자들의 전문성이 회사 내부의 문제를 해결하는 데 더 많이 쓰이게 됐습니다.

백엔드는 어드민 개발에서 맡는 범위가 줄었고, 개발자 확인 요청으로 업무가 끊기는 빈도도 크게 줄었습니다. 그만큼 본래 집중해야 할 서버 업무에 시간을 쓸 수 있는 환경이 마련됐습니다.

flowchart TD
    subgraph Before[이관 전]
        A[어드민 요청] --> B[소수의 백엔드 개발자]
        B --> C[맥락 설명과 서버 개발]
        B --> D[화면 개발과 유지보수]
    end
    subgraph After[이관 후]
        E[어드민 요청과 공유된 도메인 맥락] --> F[백엔드: API와 서버 로직]
        E --> G[프론트엔드: 화면과 UX 개선]
        F --> H[함께 문제 해결]
        G --> H
    end

이 프로젝트가 다음 과제의 출발점이 됐다

처음 의도한 것은 어드민의 오너십을 나누고, 지식과 요청의 편중을 줄이는 일이었습니다. 실행하며 확인한 것은 더 넓었습니다.

작업에서 반복 가능한 규칙을 찾고, 필요한 맥락을 문서화하고, 그것을 AI가 활용할 수 있게 만들면 다른 구성원이 참여할 수 있는 범위가 넓어졌습니다. 특정 개인이 반복해서 설명하거나 직접 처리해야 했던 부분을 줄일 수 있었습니다.

그렇다고 도메인에 대한 판단이나 각 직무의 전문성이 사라진 것은 아닙니다. 오히려 프론트엔드 개발자들이 자신의 전문성을 발휘할 수 있는 대상이 늘어났습니다. 백엔드는 집중할 시간을 확보했습니다.

이 경험은 이후 과제를 바라보는 기준이 됐습니다. 어떤 도구를 만들지 정하기 전에, 먼저 무엇이 소수에게 묶여 있는지 보고, 다른 사람이 기여하려면 어떤 맥락과 실행 수단이 필요한지 생각하게 됐습니다.

개발 영역에서 그 가능성을 확인했다면, 다음은 전사였습니다. 데이터와 업무 맥락에 접근하기 위해 누군가를 기다려야 하는 구조도 바꿔야 했습니다. BI와 PMO를 추진한 이유가 여기에 있습니다.

---

이전 글: 회사는 커졌는데, 왜 일은 같은 사람에게 몰릴까
다음 글: 같은 숫자와 같은 맥락을 보고 일하기 위해