들어가며

PM으로 직군을 전환하고 맡은 첫 장기 프로젝트가 드디어 릴리즈되었다.

그동안은 짧은 개선 작업 위주였는데, 이번엔 6년 동안 아무도 손대지 않은 보고서 기능을 기획부터 릴리즈까지 맡게 됐다. FE로 일할 때 받아보던 기획서를 이제 내가 쓰는 입장이 된 셈. (그것도 레거시 기능의 기획서를..)

처음엔 걱정이 앞섰다. 기능을 제대로 아는 사람도 거의 없고, 장기 프로젝트 기획은 처음인 내가 기획·디자인·FE·BE·iOS·Android·QA가 함께 움직이는 프로젝트를 끌고 갈 수 있을까? 그런데 릴리즈를 마치고 돌아보니, 프로젝트를 시작하기 전의 나와 비교했을 때 지금의 나는

  • 기획서를 ‘그리는 것’이 아니라 ‘설계하는 것’으로 보게 되었고
  • 결정마다 근거를 데이터로 들고 가는 습관이 생겼고
  • 화면 밖의 사용자까지 릴리즈 범위로 보게 되었다.

물론 잘한 것만 있는 건 아니었다. 프로젝트를 진행하며 배우고, 또 놓친 것들을 정리해본다.

왜 보고서였나

시작은 결재 기능이었다. 고객사 요구로 보고서에 결재 기능을 추가해야 했고, 단계별 승인은 VoC로도 오래 쌓여 있던 요청이었다.

문제는 보고서가 6년 동안 고도화되지 않은 기능이었다는 것. Web, Server, iOS, Android까지 전부 레거시 스택이었고, 해결되지 않은 VoC도 21건이나 쌓여 있었다.

VoC를 하나씩 읽으며 카테고리로 묶다 보니 공통점이 보였다. 고객사가 자기 조직의 운영 방식(누가·언제·무엇을·누구에게)에 맞게 보고서를 설정하거나, 운영 중에 바꿀 수 없다는 것. 그래서 고객사들은 기능에 운영을 맞추며 우회하고 있었다.

대표적인 게 템플릿 수정이다. 작성 항목을 고칠 수 없으니 템플릿을 새로 만들고, 기존 템플릿은 비활성으로 돌리는 식이었다. 여러 고객사가 같은 방식으로 버티고 있었다.

정리하면 갈래는 세 가지였다.

  • 템플릿을 운영에 맞게 만들고 바꾸기 어렵다
  • 누가 보고서를 받고 보는지 제어할 수 없다
  • 현장 기록·보관·다운로드에 한계가 있다

범위를 정하기까지

결재 기능을 어디에 붙일지부터 정해야 했다. 선택지는 크게 세 가지였다.

  1. 레거시 위에 결재 기능을 바로 얹는다
  2. 신규 스택으로 전면 재개발한다
  3. 신규 스택으로 부분 전환하면서, 쌓인 VoC 중 수용 가능한 것을 함께 반영한다

1번은 가장 빨라 보였지만, 수정할 수 없는 구조 위에 기능만 늘어나는 셈이었다. 결재처럼 단계가 복잡한 기능을 얹고 나면 다음 개선은 더 어려워질 게 뻔했다. 2번은 깔끔했지만 리소스와 일정이 허락하지 않았다. 결국 3번을 택했고, 프로젝트를 두 단계로 나눴다.

  • Phase 1: 리팩토링 + VoC 고도화
  • Phase 2: 결재형 보고서함

리팩토링 범위도 플랫폼마다 다르게 잡았다. Web은 React로 전면 전환하고 서버도 리팩토링했지만, App은 작성·제출·수정 화면만 리팩토링했다. 결재가 붙을 화면만 확장 가능하게 만들어 두고, 나머지는 유지보수 비용을 최소화하자는 판단이었다.

Phase 1이지만 설계는 Phase 2를 보고 했다. 보고서함을 만들 때 일반형/결재형을 ‘옵션’이 아니라 ‘고유 유형’으로 고르게 했고, 만든 뒤에는 바꿀 수 없게 했다. 운영 중에 결재 흐름이 끼어들었다 빠졌다 하면 데이터가 꼬일 테니까.

가장 큰 변화는 템플릿 버전 관리였다. 고객사들이 템플릿을 새로 만들어 우회하던 바로 그 문제다.

  • 작성 항목을 수정하면 메이저 업데이트(새 버전). 이미 제출된 보고서와 임시저장 데이터에는 소급 적용하지 않아 데이터 무결성을 지킨다.
  • 작성 항목 외 설정을 수정하면 마이너 업데이트(덮어쓰기, 바로 반영)
  • 기존 템플릿은 모두 v1로 일괄 마이그레이션

이 외에도 정보 구조 개편, 동영상 첨부, 첨부 개수 확대(4개 → 10개), PDF 다운로드, 이메일 알림 등을 함께 담았고, 연결된 VoC 19건 이상을 출시했다.

아무도 모르는 기능에서 시작하기

범위를 정하는 것보다 먼저 부딪힌 문제가 있었다. 이 기능을 제대로 아는 사람이 거의 없었다.

6년간 고도화되지 않은 기능이라 기획서도 제대로 아카이빙되어 있지 않았고, 있는 것도 개선 이력이 여러 문서에 흩어져 있었다. 게다가 남아있는 기획서는 실제 동작과 괴리가 컸다. 보고서는 서비스 공통 권한 3종 외에 고유 권한 3종이 따로 있어서, 권한이 엮이는 순간 케이스가 순식간에 불어났다.

그래서 코드를 직접 보며 최신 상태를 역추적하고, 권한별 케이스를 하나하나 테스트해 spreadsheet로 정리했다. 보통은 Figma에 바로 정리하지만, 레거시는 ‘지금 어떻게 동작하는가’부터 확정해야 했다. (Figma 산출물은 언제 나오나 하는 시선이 조금 따가웠던 건 비밀..)

결과적으로 이건 지연이 아니라 투자였다. 이 spreadsheet는

  • 이후 기획 전반의 참조 자료가 되었고
  • 권한 정책 문서의 원재료가 되었고
  • 서버 검토 단계의 기준 문서로도 쓰일 예정이다.

여기에 권한 구조, 주요 용어, 보고서 데이터의 생애주기를 더해 온보딩 자료를 만들었다. 킥오프 전에 팀 전체가 같은 그림을 보고 시작할 수 있도록 기대를 맞추는 시간도 가졌다. 회고 때 iOS 개발자분이 킥오프에서 히스토리와 전체 그림을 이해하고 시작해서 수월했다는 이야기를 해주셨는데, 그 말이 꽤 오래 남았다.

개발자가 읽기 편한 기획서

FE로 일할 때 기획서를 보며 불편했던 기억이 있다. 디스크립션마다 같은 정책이 중복으로 적혀 있어서, 하나가 바뀌면 다른 곳엔 반영이 안 되는 경우가 있었다. 개발할 때 필요한 건 그 요소가 어떻게 동작하는지인데, 부연 설명 사이에서 원하는 정보를 찾느라 번거로웠다.

이번엔 내가 쓰는 입장이니, 그 불편함만큼은 만들고 싶지 않았다. 마침 PM팀의 디스크립션 작성 방식이 md 파일 기반으로 바뀌는 시점이었고(Figma는 플러그인으로 뷰잉만 하는 구조), 개발할 때 익숙하던 단일 진실 공급원(Single Source of Truth)과 추상화 개념을 문서에도 적용해보기로 했다.

  1. 정책은 정책 문서에만 두고, 디스크립션은 UI 동작 위주로 쓴다
  2. 여러 화면에서 반복되는 동작은 공통 문서로 분리하고, 각 화면에서는 링크로 참조한다

공통 컴포넌트를 뽑아내듯 구성원 선택 Modal, 상태 설정, 파일 첨부 같은 공통 디스크립션을 분리했다. 최종적으로 정책 문서 8개, 화면 디스크립션 75개(그중 공통 8개)가 나왔다. 조건 분기 표기, 버튼 활성화 조건, API 성공/실패 분기, Toast 표기 같은 디스크립션 작성 규칙도 직접 다듬었는데, 이 규칙은 Phase 2와 PM팀 스킬로 이어졌다.

물론 처음부터 이 형태였던 건 아니다. 초반엔 시행착오가 많았다.

  • 바뀌지 않는 기존 화면까지 전부 다시 그렸고
  • 디스크립션에 담을 내용과 flowchart로 표현할 내용의 경계가 모호했고
  • 성공/실패 케이스를 어떤 형식으로 표현할지 기준이 없었고
  • Figma가 손에 익지 않아 같은 걸 지우고 다시 그리기를 반복했다. (개발자 시절엔 보기만 하던 툴이었으니..)

작성 기준이 하나씩 잡히면서 뒤로 갈수록 기획이 수월해졌다. 회고에서 개발자분들이 정책 섹션이 분리돼 기능 위주로 보기 좋았다, flow별로 나뉘어 있고 정책 중복이 없었다는 이야기를 해주셨을 때, FE 시절의 내가 받고 싶던 기획서를 어느 정도는 만들었구나 싶었다.

그런데 같은 회고에서 디자이너분에게선 반대 방향의 피드백을 받았다. 기획 초안이 아이콘과 동작까지 너무 자세해서, 디자인이 능동적으로 작업하기 어려웠다는 것. 돌아보니 내 안에 ’공유 가능한 기획서 = 모든 화면이 완벽히 그려진 기획서‘라는 기준이 있었다. 개발자에게 친절하려던 디테일이 디자이너에겐 여지를 지우는 일이 되었던 셈이다. 다음엔 기획은 정책과 큰 틀까지, 상세 레이아웃은 디자인에 맡겨보려 한다.

QA가 1명이 됐을 때

개발이 한창일 때 QA 인력이 3명에서 1명으로 줄었다. 검증해야 할 TC는 수천 개. 정식 검증 절차만으로는 일정과 품질을 동시에 지키기 어려웠다.

QA팀과 논의해 검증을 단계로 나눴다.

  1. Full TC 중 우선순위 높은 항목만 추린 Sanity TC로 개발팀이 먼저 검증한다
  2. 우선순위 상위 케이스는 개발자끼리 교차검증한다
  3. 이후 QA가 정식 Full TC로 검증한다

역할도 나눴다. 기준이 되는 핵심 flow(설정 → 작성·제출 → 검토 → 분석)는 내가 정의했고, TC 항목은 QA팀이 그 flow를 기준으로 산정했다.

결과는 생각보다 좋았다. QA 1명으로 예정일 안에 릴리즈했고, 같은 TC 수 대비 QA 단계 이슈가 약 45% 줄었다. QA 단계에선 critical 이슈도 거의 없었다. 개발자 간 교차검증 과정에서 iOS와 Android의 UX 차이를 발견해 개선하는 부수 효과도 있었고, 이 방식은 이후 다른 프로젝트에서도 정착했다.

동료들의 반응도 기억에 남는다. QA분은 주요 버그가 먼저 고쳐져 있어 검증이 수월했다고 했고, BE 개발자분은 개발자들의 서비스 이해도가 올라갔다고 했다. 디자이너분도 디자인 QA 기간을 따로 확보할 수 있어 좋았다고 해주셨다.

다만 계속 이 방식으로 가도 될까?는 아직 고민이다. 일정 압박이 있을 땐 개발자 리소스 부담이 커지고, 테스트 데이터 세팅에도 시간이 많이 든다는 의견이 있었다. QA팀이 제안한 타임박싱 교차 테스트처럼, 부담을 나누는 방법을 더 찾아봐야 한다.

릴리즈 전후

앱 강제 업데이트

템플릿 버전 관리와 동영상 작성 항목 때문에, 구버전 앱에서는 데이터 불일치가 생기거나 조회가 안 될 수 있었다. 강제 업데이트를 하지 않으면 구버전 기준 TC를 추가로 검증해야 했는데, QA가 1명인 상황에선 부담이 컸다.

문제는 조직의 기조였다. B2B SaaS라 고객사 운영에 영향을 주는 변경은 최소화하자는 분위기가 강했다. 그래서 감이 아니라 데이터로 이야기하기로 했다. 활성 고객사의 기준을 먼저 정의하고, 제출량으로 사용 강도를 나눠 강제 업데이트의 영향 범위를 가늠했다.

강제 업데이트로 합의한 뒤 심사 완료 → DB 마이그레이션 → 서버·앱 동시 배포 순으로 진행했고, 비즈니스팀에 미리 공유했다. 리포팅된 이슈는 일시적인 제출 오류 몇 건이 전부였고, 미리 공유받은 비즈니스팀에서 바로 안내해 해소됐다.

외부 API 안내 누락

릴리즈 직후엔 예상하지 못한 곳에서 문제가 터졌다. 릴리즈와 함께 보고서 외부 API도 새 버전으로 바뀌었는데, 문서 갱신과 고객사 사전 안내가 빠져 있었다. 요청 구조가 바뀐 탓에, 외부 연동으로 데이터를 받아가던 고객사에서 동기화 문제가 생겼다.

BE에서 API 문서를 갱신하고 해당 API를 호출한 고객사를 추출해, 비즈니스팀이 개별 안내하며 급한 불은 껐다. 이후 비즈니스팀에서 “API가 바뀌면 사전 안내가 필요하지 않나?”라는 이야기가 나왔다. 나는 이걸 이번 한 번의 실수가 아니라 변경을 미리 알리는 체계가 없다는 구조 문제로 봤다. 현행을 파악하고 쟁점(대상 기준, 분기 기준, 시점, 역할)을 정리해, 3일 만에 비즈니스·BE·PM 3개 팀의 합의를 이끌었다.

합의안은 생각보다 가볍다. 외부 API 변경을 공유하는 채널을 만들고, 변경이 생기면 BE가 변경 내역과 영향받는 고객사를 공유한다. 처음 제안보다 가볍게 시작해 운영하며 고도화하기로 했고, 범위는 보고서뿐 아니라 외부 제공 API 전반으로 넓혔다.

돌아보면 릴리즈 범위에 ‘외부 API 문서와 고객 안내’가 빠져 있었다. 화면과 앱만 릴리즈 범위로 봤던 거다. 화면 밖에서 우리 기능을 쓰는 사용자도 릴리즈 계획에 들어가야 한다는 걸 배웠다.

마무리하며

돌아보면 이번 프로젝트의 문제들은 대부분 예상하지 못한 제약에서 시작됐다. 아무도 모르는 레거시, 흩어진 문서, 갑자기 줄어든 QA. 그때마다 원칙을 세우고 구조로 풀어냈고, 그 판단들은 지금 돌아봐도 타당했다고 생각한다.

반대로 아쉬움은 대부분 설계 논리 밖에 있는 사람에게서 나왔다. 상세한 초안 앞에서 여지를 잃은 디자이너, 화면 밖에서 API를 쓰던 고객사. 원칙은 세웠지만, 그 원칙이 쓰는 사람에게 어떻게 닿을지는 충분히 검증하지 못했다.

그래서 다음 장기 프로젝트에선 이렇게 해보려 한다.

기획은 정책과 큰 틀까지, 상세는 함께 채워가기

변경은 추적 가능한 형태로, 처음부터 알리기

측정과 고객 안내까지 릴리즈 범위에 넣기

지금은 Phase 1에서 다진 기반 위에서 Phase 2(결재)가 진행 중이다. 기반부터 다지자던 결정이 정말 옳았는지는 Phase 2가 답해줄 것 같다.

내게 보고서 고도화 Phase 1은 개발자의 눈으로 보던 기획서를, 함께 일하는 사람들의 눈으로 다시 쓰는 연습이었다.

PM으로서의 첫 장기 프로젝트를 믿고 함께 달려준 팀원분들께 무한한 감사를! 🙇🏻