프론트엔드(FE)와 백엔드(BE) 팀이 분리되어 API 스펙 조율 및 일정 대기 등 비효율 발생
직군 통합 실험을 통해 FE와 BE 엔지니어가 한 팀으로 화면부터 서버까지 전 과정 담당
팀 통합 후에도 스프린트 완료량 유지 및 개인별 반대 직군 티켓 할당으로 속도 저하 방지
AI 코딩 도구와 문서화된 지식을 활용하여 낯선 영역 학습 비용 절감 및 전문성 활용
안정성 우려는 있었으나, 장애 대응 매뉴얼(Runbook)과 상호 검증으로 리스크 관리
기존 프론트엔드(FE)와 백엔드(BE) 분리 구조에서는 API 스펙 정의 지연으로 인한 화면 작업 대기, 한쪽 팀의 일정 지연이 다른 쪽으로 전파되는 문제가 발생했다. 팀 통합 후에는 FE와 BE 엔지니어가 한 팀이 되어 화면부터 서버까지 전체 개발 과정을 책임지게 되었다. 이를 통해 티켓이 직군 간 이동하며 발생하는 조율 및 대기 시간이 크게 줄었으며, 엔지니어 한 명이 문제를 끝까지 해결하는 사례가 증가했다. 이는 개발 프로세스의 병목 현상 해소에 직접적으로 기여했다.
팀 통합 후 엔지니어들은 낯선 반대 직군의 코드를 작성해야 하는 과제에 직면했다. 이때 AI 코딩 도구(AI Coding Tools)는 초안 코드 생성을 지원하여 진입 장벽을 낮추는 데 결정적인 역할을 했다. 특히, 팀 내부에 축적된 문서화된 지식(Documented Knowledge)은 AI에게 정확한 맥락(Context)을 제공하는 연료 역할을 했다. 온콜 Runbook(On-call Runbook)과 기술 문서 저장소(Technical Documentation Repository)는 신규 멤버의 온보딩 자료이자, 장애 발생 시 독립적인 대응을 가능하게 하는 기반이 되었다. 이는 지식 구축과 활용의 선순환 구조를 만들었다.
팀 통합 후에도 스프린트 완료량(Sprint Velocity)은 이전 수준을 유지했다. 이는 모든 팀원이 최소 1개의 반대 직군 티켓을 담당하도록 배분하고, 팀 리드가 직접 시범을 보이는 '시범(Demonstration)' 원칙을 따른 결과다. 또한, 장애 발생 시 온콜(On-call) 대응과 신뢰성 인프라 투자를 통해 안정성을 확보하려 노력했다. 4월에는 결제 시스템 장애 등 인시던트가 발생했지만, 6월에는 신규 인시던트가 0건으로 감소하는 추세를 보였다. 이는 상호 검증(Mutual Verification) 강화와 장애 대응 매뉴얼(Runbook)의 효과로 분석된다.
직군 통합은 엔지니어 개인이 화면부터 서버까지 전 과정을 다룰 수 있게 했지만, 개인의 전문성이 얕아질 수 있다는 리스크는 존재한다. 이를 보완하기 위해 팀은 동료 리뷰(Peer Review)와 설계 문서(Tech Spec) 기반의 팀/실 단위 리뷰를 진행한다. AI가 생성한 코드의 완성도를 80~90% 수준으로 받아들이고 속도를 얻는 대신, 확신이 없는 부분은 동료 전문가에게 질문하며 전문성을 채워나간다. AI 결과물을 걸러내는 최종 검증자로서의 전문성 재정의가 이루어지고 있다.
AI 활용으로 개별 엔지니어의 처리 시간은 줄었지만, 계획되지 않은 업무의 비중이 증가하며 예측 가능성이 낮아지는 비용이 발생했다. 또한, 각자 병렬적으로 빨라진 만큼 '팀으로서 일한다'는 감각이 옅어지는 현상도 나타났다. 이를 해결하기 위해 팀은 AI 도구를 팀 표준 습관으로 만드는 작업을 진행 중이며, 지속 가능한 방식을 모색하고 있다. 회의, 추가 업무, 온콜 CS 처리 등에서 발생하는 야근 및 품이 드는 문제를 해결하고 예측 가능성을 되찾는 것이 다음 분기의 주요 과제이다.