여섯 명이 하던 일을 세 명이 하게 됐을 때 — 백엔드1팀 AI 전환기 (1편)
2026.07.24
팀 인원이 반으로 줄어든 위기 속에서 올라핀테크 백엔드1팀이 AI 코딩 에이전트를 도입하고 일하는 방식 자체를 재설계한 생존기입니다.
코드 분석부터 멀티레포 환경 구축, 업무 과정에서 자연스럽게 위키 문서가 쌓이는 AI 워크스페이스 구축까지의 여정을 다룹니다.
1편은 그 여정의 이야기를, 2편은 우리가 실제로 만든 시스템을 다룹니다.
먼저 저희 팀이 무엇을 만드는 팀인지부터 짧게 소개하면 — 올라선정산은 쇼핑몰 판매자(셀러)에게 정산금을 미리 지급하고, 쇼핑몰 정산일에 미리 지급한 정산금을 회수하는 핀테크 서비스입니다. 백엔드1팀은 이 서비스의 심장에 해당하는 부분, 그러니까 돈이 나가고 들어오는 모든 로직을 만들고 지키는 팀이죠.
미리 말씀드리면, 이 글은 "우리 팀이 최신 AI 도구를 도입했어요"류의 자랑이 아닙니다. 굳이 분류하자면 생존기에 가깝습니다. 팀이 반으로 줄고, 사람이 떠나고, 문서는 없고, 그 와중에 서비스는 매일 돌아가야 하는 상황에서 — 우리가 어떻게 일하는 방식 자체를 다시 설계하게 됐는지에 대한 이야기입니다.
▲백엔드1팀이 수작업 코딩 중심에서 AI 워크플로우로 전환되기까지의 흐름.
코드가 곧 문서이던 시절 (~2025.03)
이 시기의 신규 입사자 온보딩은 이런 식이었습니다. 백엔드 서비스 구조를 간단히 설명듣고, 프로젝트별 성격과 연관관계를 대략 파악하면 -> 바로 실전 투입. 나머지는 일하면서 경험으로 배우는 거였죠.
일하는 방식도 단순했습니다. CX팀에서 "셀러분이 선정산 신청이 안 된대요" 같은 운영 요청이 오면, 담당자가 코드를 한 줄 한 줄 따라가며 로직을 파악하고 버그를 찾아 고쳤습니다. 기획팀에서 개발 요청이 오면 피그마나 노션의 기획 문서로 요구사항을 확인하고, 기존 로직과 충돌하진 않는지, 다른 곳에 사이드이펙트는 없는지, 역시 코드를 파보면서 확인한 뒤 개인 문서에 간단히 작업 계획을 세우고 개발했습니다. 코딩은 100% 사람 손이었고요.
돌이켜보면 이때는 이 방식이 문제라고 느끼지도 못했습니다. 팀원이 여섯이었고, 각자 잘 아는 영역이 있었으니까요. 모르는 게 생기면 "이거 OO님이 만들었던 것 같은데요?" 한마디면 답이 나왔습니다. 서비스의 역사가 문서가 아니라 사람들의 머릿속에 있었던 거죠. 이게 나중에 어떤 청구서로 돌아오는지는, 그때는 몰랐습니다.
"AI한테 시켜봤는데, 음..." (2025.04~2025.07)
Claude Code, Codex 같은 AI 코딩 에이전트가 세상에 본격적으로 활용되기 시작한 시기입니다. 요구사항을 주면 어느 정도 이해하고 직접 코드를 짜는 게 신기하긴 했는데... 막상 일을 시켜보면 실수가 잦았고, 속도도 기대만큼 빠르지 않았습니다.
그래서 자연스럽게 역할이 정해졌습니다. 개발은 사람이 하고, AI에게는 잘 모르는 부분을 물어보거나 코드 리뷰 정도를 맡기는 것. 그마저도 비즈니스 로직이 좀 커지면 AI가 리뷰를 하다가 길을 잃는 일이 종종 있었습니다. 선정산 도메인이 워낙 단계가 많거든요. 계약, 조회, 신청, 지급, 회수, 환급이 맞물려 돌아가는데, 그 전체 맥락을 AI의 좁은 기억력(컨텍스트)에 다 담을 수가 없었던 겁니다.
이 시기 팀 분위기는 솔직히 반반이었습니다. "실수도 잦고 코드 퀄리티도 별로니 사람이 직접 하는 게 낫다"는 쪽과, "그래도 이 정도면 꽤 도움이 된다"는 쪽. 특히 CX팀이나 기획팀에서 복잡하거나 모호한 요청이 오면 AI는 거의 손을 못 댔기 때문에, 회의적인 시각에도 충분히 근거가 있었습니다. 그래도 분명한 건, 이것만으로도 개발자들에게는 꽤 도움이 되는 시기였다는 겁니다.
팀이 반으로 줄었다 (2025.08~2026.01)
조직 개편으로 백엔드팀 여섯 명에서 '백엔드1팀' 세 명이 됐습니다.
여섯명일 때는 한두 명의 컨디션이 안 좋아도 나머지가 받쳐줄 수 있었습니다. 셋이 되니 한 명만 흔들려도 팀 전체가 출렁였습니다. 그리고 공교롭게도 이 시기에 AI 사용량이 본격적으로 늘기 시작하면서, 쓰던 구독 모델의 사용량 제한에 걸리는 일이 잦아졌습니다.
당연히 "구독 모델을 업그레이드해 달라"는 요청이 많아졌는데, 회사에서 돌아온 반응은 이랬습니다.
"업그레이드하면 비용이 꽤 나갈 텐데, 그 비용만큼의 퍼포먼스를 어떻게 낼 건가? 어떻게 증명할건가?"
뼈아픈 질문이었습니다. 사실 우리도 어떻게 증명해야 할지 몰랐거든요. "AI 덕분에 개발이 빨라졌습니다"를 숫자로 보여달라는 건데, 개발 생산성이라는 게 원래 측정이 어려운 영역이기도 하고요.
다만 한 가지는 분명했습니다. AI 코딩 에이전트의 능력이 눈에 띄게 좋아지고 있었다는 것. 특히 개발 설계, 병렬 작업, 코드 리뷰가 부쩍 좋아지면서 개발자가 키보드로 직접 코드를 치는 일 자체가 상당히 줄었습니다. 그리고 세 명이 기존 여섯 명 몫의 백엔드 업무를 계속 이어갈 수 있었던 건, 솔직히 말해 AI가 그 공백을 메워주고 있었기 때문입니다. 증명까지는 아니어도, 임원들에게 어느 정도 이야기해볼 만한 근거는 이미 우리 일상에 있었던 셈이죠.
▲팀 인원은 줄었지만 AI 코딩 역량은 빠르게 올라가던 시기의 교차점.
물론 이 시기에도 한계는 뚜렷했습니다. 셋 중 한두 명이 휴가를 가거나 급하게 빠지면 남은 인원에게 과부하가 그대로 쏟아졌습니다. 구독 모델 한도 때문에 AI에게 여러 일을 동시에 시키는 병렬 작업은 꿈도 못 꿨고, 거대한 비즈니스 로직 앞에서는 여전히 실수가 많고 속도도 느렸으니까요. 결국 기존 프로세스를 파악하고 설계하는 일은 여전히 사람이 코드를 직접 분석해가며 해야 했습니다.
그리고 여기에 우리 회사 특유의 사정이 하나 더 얹힙니다. 올라핀테크는 빠르게 성장해왔고 업무 프로세스가 빠르게 변하고 있었던 터라 기획 문서나 정책 문서가 상대적으로 빈약한 편이었습니다. 과거에 개발했던 내용은 코드가 아니면 확인할 길이 거의 없었습니다. 3~4년 치 정책 변경의 역사가 오직 코드 안에만 새겨져 있었던 거죠. 그러니 더더욱 코드를 파야만 했고요.
세 가지 문제가 한꺼번에 (2026.02~)
이 무렵 백엔드1팀의 문제를 추려보면 세 가지였습니다.
- 인원 부족 — 한두 명만 빠져도 남은 한 명은 하루 종일 CX팀 운영 업무만 처리해야 할 정도. 요구사항 분석에 시간이 오래 걸리고 수기 작업도 많아서, AI 코딩이 빨라지고 좋아진 것만으로는 여전히 사람이 해야 할 일이 많았습니다.
- 온보딩 부족 — 새 사람이 와도 가르쳐줄 시간이 없고, 가르쳐줄 자료도 없음.
- 히스토리 문서 부재 — 정책과 변경 이력이 코드에만 존재.
▲인원 부족, 온보딩 부족, 히스토리 문서 부재가 서로를 키우던 구조.
이 세 문제가 서로를 키웠습니다. 사람이 없으니 문서 쓸 시간이 없고, 문서가 없으니 온보딩이 안 되고, 온보딩이 안 되니 사람이 늘어도 전력이 안 되는 구조.
그리고 이 구조의 비용을 가장 아프게 치른 시기가 왔습니다. 팀 축소 후 처음으로 신규 입사자가 들어왔는데, 다들 너무 바빠서 제대로 챙겨줄 수가 없었습니다. 이전보다 더 잘 이해시켜주고 싶은 마음은 있었는데, 코드만 방대하지 문서로 남은 게 별로 없었으니까요. 결국 그분은 온보딩 중에 퇴사했습니다. 엎친 데 덮친 격으로, 팀에 가장 오래 있었고 서비스 이해도가 가장 높았던 팀원도 회사를 떠나게 됐습니다.
문서 부재의 문제는 신규 입사자만의 문제도 아니었습니다. 1~2년 넘게 다닌 개발자들조차 그 이전 3~4년간 쌓인 정책과 변경 히스토리를 코드로만 파악해야 했기 때문에, "어, 이런 게 있었어요?" 하는 순간이 계속 나왔습니다. 그때마다 파악하느라 시간이 한참 걸렸고요.
그 무렵 백엔드2팀에서 한 동료가 백엔드1팀 업무에 합류해주셨습니다. 올라 서비스 경험은 많지 않았지만, 오히려 그 덕분에 기존 팀원들에게는 익숙했던 업무 방식을 새로운 시선으로 바라볼 수 있었습니다. 백엔드 프로젝트만 다섯 개가 넘고, 서비스 간 연결은 복잡한데, 문서와 히스토리는 충분히 정리되어 있지 않았습니다. 이분은 서비스를 하나씩 따라가며 적응하는 방식만으로는 한계가 있다고 보고, 먼저 전체 구조를 빠르게 파악할 수 있는 방법을 찾기 시작했습니다.
이런 문제가 한데 뒤엉켜 있던 시기에, 마침내 회사에서 AI 구독 모델을 올려줬습니다. 드디어 AI로 뭔가 개선해볼 여지가 생긴 겁니다.
전환점: 새 동료가 일하는 걸 보고
흥미로운 변화는 예상치 못한 곳에서 시작됐습니다.
새로 합류한 동료는 특정 서비스 하나를 깊게 파기보다, 올라 서비스를 구성하는 여러 저장소의 역할과 연결 관계를 먼저 파악하는 방식을 택했습니다. 이를 위해 올라를 운영하는 여러 저장소를 역할별 디렉토리 구조로 재정리했습니다. 프론트엔드, 백엔드, 데이터 처리 서비스, 외부 연동 서버처럼 서비스의 성격이 드러나도록 멀티레포 분석 환경을 만들고, 업그레이드된 Claude로 올라 서비스 전체를 통째로 분석하기 시작했습니다.
그런데 결과가 예상 밖이었습니다. 예전 구독 모델로는 프로젝트 하나를 겨우 다루던 AI가, 이제는 여러 프로젝트를 가로질러 분석하고 각 프로젝트에 병렬로 작업을 시켜도 별문제가 없었던 겁니다.
이 장면이 우리 일하는 방식의 가정 하나를 깼습니다. 기존 팀원들은 서비스 이해도가 높으니, 문제가 생기면 "이건 정산 쪽이네" 하고 해당 서비스를 바로 찾아가 코드를 분석하고 AI로 개발했습니다. 그러니까 '문제가 어느 서비스 소관인지'를 판단하는 건 당연히 사람 몫이라고 생각했던 거죠. 그런데 새 동료가 일하는 걸 보니, 서비스별 세부 맥락을 모두 외우고 있지 않아도, 구조화된 멀티레포 환경과 AI 분석을 활용하면 원인을 좁히고 어떤 서비스를 수정해야 할지까지 찾아낼 수 있었습니다.
그렇다면 굳이 서비스 하나에 Claude 세션 하나를 붙일 게 아니라, 한 세션으로 여러 서비스를 한꺼번에 관리하고 개발해도 되겠다는 생각에 닿았습니다. 그래서 백엔드1팀의 업무 방식을 바꿔보기로 했습니다.
백엔드를 넘어 프론트엔드, 데이터 처리 서비스, 외부 연동 서비스까지 전부 분석할 수 있는 멀티레포 환경을 만들고, 그 위에서 AI 오케스트레이션으로 업무를 분석하고, 설계하고, 설계 문서까지 만들어내는 방향으로요.
해보니 좋은 점이 세 가지 분명했습니다.
- 예전에는 서비스 하나만 고려해서 개발했다면, 이제 AI가 모든 프로젝트를 다 살펴보며 분석·설계하니 놓치던 부분이 잡히기 시작했습니다.
- 하나의 업무가 여러 저장소(레포)에 걸칠 때, 병렬 작업이 수월해졌습니다.
- 그리고 설계와 운영 업무를 처리할 때마다 — 히스토리 문서가 쌓이기 시작했습니다.
세 번째가 핵심이었습니다. '인원 부족'은 빠른 분석과 병렬 작업으로 한 번 더 개선됐지만, 그보다 '온보딩 부족'과 '히스토리 문서 부재'를 동시에 해결할 실마리가 보였거든요. 어차피 일을 하려면 분석을 해야 하고, 분석을 AI가 하면 그 결과는 문서로 남습니다. 그렇다면 이 문서들을 잘 정형화해서 쌓으면, 그동안 사람 머릿속에만 있던 정책과 히스토리가 전부 기록으로 남는 위키가 되지 않을까?
그렇게 태어난 것이 지금 우리가 쓰는 분석 워크스페이스, allra-ai-analysis입니다. CX팀의 운영 요청이든 기획팀의 개발 요청이든, 아무리 작은 일이라도 전부 여기서 시작해서 문서를 남기는 것으로 팀의 업무 방식을 바꿨습니다. 2026년 7월 초 기준, 이 워크스페이스에는 분석·설계·장애 대응·작업 기록 문서가 152건 쌓여 있습니다. 일부러 시간 내서 쓴 문서가 아니라, 일 흐름 안에서 자연스럽게 남는 문서가요.
이 워크스페이스가 구체적으로 어떻게 생겼는지 — 요청 하나가 들어오면 분석하고, 설계하고, 이슈를 쪼개 발행하고, 구현하고, 결과를 보고하고, 그 모든 것이 위키가 되어 다음 분석을 더 똑똑하게 만드는 구조 — 는 2편에서 이어집니다.
“올라핀테크 팀은 앞으로도 문제를 해결한 과정을 꾸준히 기록하고 나누겠습니다!”
write. 백엔드1팀 김영완, 선혁준, 김승태