차세대 프로젝트의 반전
주어진 역할 이상을 해야 한다.
2015년 7월, 차세대 프로젝트에 투입됐다. 안드로이드 앱 개발자 고급으로 계약했다. 당시 경력이 16년 차였다. 특급으로 투입되어야 했지만 TO가 고급밖에 없었다. TO는 Table of Organization, 정원이다. 자리가 없으면 한 등급 낮춰서라도 들어가야 한다. 프로젝트 경험이 중요했다.
차세대 프로젝트는 운영 중인 사이트를 새로운 기술로 전체 업그레이드하는 작업이다. 대기업은 대략 10년 단위로 시스템을 갈아엎는다. 1년에서 2년 동안 진행되는 대규모 프로젝트다. 이미 8개월이 진행되고 있었다. 각 파트 개발이 중반쯤 와있었다.
앱 개발은 아직 시작도 안 했다. 적어도 한 달은 더 있어야 했다. 그 한 달 동안 인력을 놀릴 수는 없다. 간단한 업무가 할당됐다. 웹 페이지의 기능 하나를 만드는 일이었다.
문제는 개발 방식이었다. DB 조회부터 서비스 로직 개발, 화면 노출까지 전부 혼자 해야 했다. 이런 방식을 수직적 개발이라고 부른다. 한 사람이 하나의 기능을 처음부터 끝까지 책임지는 구조다.
전문 분야는 기획과 프론트엔드 개발, 퍼블리싱이었다. DB 조회와 서비스 로직 개발은 할 수는 있지만 시간이 필요했다. 백엔드는 전문 영역이 아니었다. 하지만 프로젝트에는 일정이 있다. 개인 사정에 맞춰 조율할 수는 없었다.
며칠을 고민했다. 소스 코드를 파악해야 했다. 8개월 동안 쌓인 코드를 이해하는 것부터 시간이 걸렸다. 전문 분야가 아닌 DB 컨트롤과 서비스 로직까지 하려면 부담이 컸다. 주어진 일정 안에 완료할 자신이 없었다.
계약 회사 PM을 찾아갔다. 큰 프로젝트에는 여러 회사가 참여한다. 전체 프로젝트를 진행하는 회사가 있고, 각 파트를 맡은 협력사들이 있다. 각 협력사는 현장 관리를 위해 PM을 파견한다. 계약 회사 PM은 소속 회사 인력들을 관리하는 역할이다.
수평적 개발 방식으로 바꾸자고 제안했다. 수평적 개발은 전문성을 강조한 방식이다. 백엔드 개발자는 DB와 서비스 로직만, 프론트엔드 개발자는 화면 개발만 담당한다. 각자 잘하는 영역에 집중하는 구조다.
PM은 난색을 보였다. 당연했다. 8개월 동안 수직적으로 진행해 온 방식을 바꾼다는 건 쉬운 결정이 아니었다. 전체 파트의 개발 방식을 바꾸려면 다른 협력사들과도 조율해야 했다. 일정에도 영향을 줄 수 있었다.
일부만 시범적으로 1주일만 해보자고 했다. 전체를 바꾸는 게 아니라 작은 단위로 테스트해 보자는 제안하고, 프론트는 혼자 다 하겠다고 딜을 던졌다. PM이 고민하다 승낙했다. 1주일, 그것도 일부 기능만으로 제한됐다.
DB와 서비스 로직은 3명의 백엔드 개발자가 맡았다. 프론트엔드는 혼자 담당했다. 백엔드 개발자들은 DB 스키마를 설계하고, 쿼리를 작성하고, 비즈니스 로직을 구현했다. API를 만들어 데이터를 전달해 줬다.
API 명세서를 받아 화면 개발만 집중했다. HTML 구조를 짜고, CSS로 스타일링하고, JavaScript로 데이터를 연동했다. DB가 어떻게 설계됐는지, 서비스 로직이 어떻게 돌아가는지 알 필요가 없었다. API가 주는 데이터를 화면에 표시하고, 필요한 데이터를 요청하면 됐다.
속도가 빨랐다. 각자 전문 분야에만 집중하니 개발 속도가 올라갔다. 백엔드 개발자들은 화면 레이아웃을 고민할 필요 없이 로직에만 집중했다. 프론트엔드는 DB 구조를 파악하느라 시간 쓸 필요 없이 화면 구현에만 몰두했다.
코드 품질도 좋아졌다. 각자 잘하는 분야라 실수가 줄었다. 백엔드 개발자가 억지로 화면을 만들 때 나오는 어색한 코드가 없었다. 프론트엔드 개발자가 서투르게 짠 쿼리도 없었다.
1주일 후 결과를 비교했다. 같은 기간 동안 수직적 방식으로 개발한 팀보다 진도가 빨랐다. 오류도 적었다. PM이 파트 리더와 회의했다. 수평적 방식을 확대 적용하자는 회의였다.
반대가 있었다. 8개월 동안 해온 방식을 갑자기 바꾼다는 게 불편했다. 이미 수직적 방식에 익숙해진 개발자들이 많았다. 다시 역할을 나누고, 협업 구조를 바꾸고, 커뮤니케이션 방식을 재정립해야 했다.
일정 지연을 우려하는 목소리도 있었다. 방식을 바꾸는 과정에서 혼란이 생길 수 있다는 지적이었다. 전환 기간 동안 생산성이 떨어질 수 있다는 것도 맞는 말이었다.
하지만 8개월동안 제대로 된 페이지조차 나오지 못하는 상황이었다. 앞으로 남은 개발 기간이 4개월이었다. 지금 방식을 바꾸면 그 4개월 동안 개발 속도를 높일 수 있다고 제안했다. 테스트 기간도 줄일 수 있었다. 각 분야 전문가가 개발한 코드가 품질이 좋으니 오류가 적을 것이라는 기대도 있었다.
결국 파트 전체가 수평적 방식으로 전환됐다. 백엔드 개발자들은 백엔드만, 프론트엔드 개발자들은 프론트엔드만 담당하도록 역할이 재편됐다. API 명세서 작성 규칙이 만들어졌다. 데이터 전달 방식이 표준화됐다.
한 달 후, 프론트엔드 개발 파트의 PL이 됐다. PL은 Project Leader, 파트를 책임지는 위치다. 업무가 늘어났다. 프론트엔드 개발자들의 작업을 분배하고, 진도를 체크하고, 이슈를 해결해야 했다. 백엔드 팀과 협업 구조를 만들고, API 명세서를 검토하고, 공통 컴포넌트를 설계해야 했다.
공통 표준까지 설계하게 됐다. 프론트엔드 개발자들이 일관된 방식으로 개발할 수 있도록 가이드를 만들었다. HTML 구조 규칙, CSS 네이밍 컨벤션, JavaScript 코딩 스타일, 파일 구조, 주석 작성법까지.
화면 설계서를 받으면 전체를 분석했다. 어떤 화면에 공통 요소가 있는지, 재사용 가능한 컴포넌트는 무엇인지, 각 개발자에게 어떻게 분배할지 정했다. 공통 컴포넌트를 먼저 개발하고, 각 화면 개발자들이 그걸 가져다 쓰도록 했다.
백엔드 팀과 주 2회 정기 회의를 했다. API 명세서를 검토하고, 데이터 구조를 협의하고, 이슈를 조율했다. 백엔드에서 데이터를 어떤 형태로 줄지, 프론트엔드에서 어떻게 가공할지 합의했다. 서로의 작업 영역을 명확히 구분했다.
업무는 늘었지만 뿌듯했다. 8개월 동안 진행된 방식을 바꿔서 효율적이라고 인정받은 게 책임감으로 이어졌다. 단순히 주어진 기능을 개발하는 게 아니라, 파트 전체의 방향을 만들어간다는 느낌이었다.
프론트엔드 개발자들의 실력도 올라갔다. 각자 화면 개발에만 집중하니 전문성이 높아졌다. CSS 애니메이션, 반응형 레이아웃, JavaScript 인터랙션 같은 부분에서 품질이 좋아졌다. 백엔드를 신경 쓰지 않으니 프론트엔드 기술을 깊이 있게 파고들 수 있었다.
백엔드 팀도 마찬가지였다. 화면을 신경 쓰지 않으니 로직 최적화에 집중했다. 쿼리 성능을 개선하고, 비즈니스 로직을 정교하게 다듬고, API 응답 속도를 높였다. 서로의 영역에서 최선을 다할 수 있는 구조가 됐다.
물론 쉽지만은 않았다. 수평적 방식은 협업이 중요하다. 백엔드와 프론트엔드가 긴밀하게 소통하지 않으면 문제가 생긴다. API 명세서가 불명확하면 프론트엔드 개발자가 헤맨다. 데이터 형태가 바뀌면 화면 코드를 전부 수정해야 한다.
초반에는 혼란도 있었다. 역할 구분이 명확하지 않아 서로 책임을 미루는 경우도 있었다. "이건 백엔드에서 처리해야 하는 거 아니에요?" "아니요, 프론트에서 하는 게 맞죠." 같은 실랑이가 잦았다.
API 명세서 작성에 시간이 걸렸다. 백엔드 개발자들이 명세서 작성에 익숙하지 않았다. 어떤 데이터를 어떤 형태로 전달할지 문서화하는 게 귀찮은 작업이었다. 하지만 명세서 없이는 프론트엔드 개발이 시작조차 안 됐다.
회의도 많아졌다. 수직적 방식에서는 혼자 결정하면 됐던 것들을 팀 간 합의로 결정해야 했다. 백엔드와 프론트엔드가 함께 앉아 데이터 구조를 논의하고, 처리 방식을 조율하고, 예외 케이스를 정리했다.
그럼에도 효과는 명확했다. 남은 4개월 동안 개발 속도가 빨라졌다. 각자 전문 분야에 집중하니 생산성이 올라갔다. 공통 컴포넌트를 재사용하니 중복 작업이 줄었다. 코드 품질이 좋아지니 테스트에서 오류가 적게 나왔다.
다른 파트에서도 수평적 방식을 도입하려는 움직임이 생겼다. 효과를 본 파트가 늘어났다. 프로젝트 전체가 조금씩 방식을 바꿔갔다. 8개월간 고착된 방식이 서서히 깨졌다.
16년차 경력이지만 TO가 없어 한 등급 낮춰서 들어온 프로젝트였다. 한 달의 공백기에 받은 어색한 업무가 시작이었다. 수직적 방식이 불편해서 던진 제안 하나가 파트 전체를 바꿨다. PL이 되고, 공통 표준을 설계하고, 프론트엔드 팀을 이끌게 됐다.
돌이켜보면 운도 좋았다. PM이 1주일 실험을 승낙하지 않았다면 아무 일도 안 일어났을 것이다. 1주일의 결과가 좋지 않았다면 거기서 끝났을 것이다. 파트 리더가 반대했다면 확대되지 못했을 것이다.
하지만 운만은 아니다. 문제를 발견하고, 해결책을 제시하고, 실행하고, 증명했다. 불편함을 그냥 참고 넘어가지 않았다. 실력도 실력이지만, 힘들어도 할 수 있다는 자신감과 책임감이 바꿀 수 있다는 믿음으로 이어졌다.
25년 동안 수많은 프로젝트를 거쳤지만, 이번 차세대 프로젝트는 특별했다. 주어진 역할을 수행하는 게 아니라, 구조 자체를 바꾼 경험이었다. 8개월간 굳어진 방식에 균열을 낸 순간이었다. 개발자는 코드만 짜는 게 아니라는 걸 배운 프로젝트였다.
