"기획자의 적은 기획자?" - 히스토리와 레거시의 언어 (유지보수)

새로운 것을 만드는 것보다 힘든 것은 과거의 파편을 맞추는 일입니다. 전임자가 남긴 "왜 이렇게 했지?"라는 의문을 풀어나가며 시스템을 점진적으로 개선하는 '고고학자 기획자'의 자세를 다룹니다. 1. 레거시는 죄가 없다, 다만 기록이 없을 뿐 우리가 '레거시(Legacy)'라고 부르는 낡은 시스템도 한때는 최선의 기획이자 혁신이었습니다. 문제는 그 '이유'가 전해지지 않는다는 것입니다. - 히스토리 추적의 고충: 기획서가 없거나, 기획서와 실제 서비스가 다를 때 기획자는 패닉에 빠집니다. - 영향도 분석의 늪: "이 버튼 하나만 고치면 되죠?"라고 했다가 연결된 DB 테이블 5개가 꼬이는 상황을 방지해야 합니다. - 기획자의 마인드셋: 전임자를 비난하기보다, 당시의 비즈니스 상황과 기술적 제약을 이해하려는 노력이 '진짜 실력'입니다. 2. 꼬인 실타래를 푸는 유지보수 기획의 3단계 1단계: 소스코드보다 정확한 '현행화(AS-IS) 파악' 실행: 현재 서비스가 실제로 어떻게 동작하고 있는지 UI, API, DB를 거꾸로 타고 올라가며 정리합니다. 핵심 기술: * 현행화 기획서 작성: 현재의 동작 로직을 문서로 다시 만듭니다. DB 스키마 확인: 개발자에게 요청하여 데이터가 어떤 테이블에 어떤 값으로 저장되는지 확인합니다. 2단계: '도미노 현상'을 막는 영향도 분석 실행: 수정하려는 기능과 연결된 모든 접점(Interface)을 리스트업합니다. 핵심 기술: * 사이드 이펙트(Side Effect) 체크리스트: A 기능을 고칠 때 B 화면에 영향이 없는지, 연동된 외부 API가 깨지지 않는지 전수 조사합니다. QA팀과의 긴밀한 협의: 예상치 못한 오류가 발생할 수 있는 지점을 미리 공유하고 테스트 케이스를 촘촘히 짭니다. 3단계: 미래의 나를 위한 '결정의 이유' 기록 실행: 기획서에 '무엇(What)'을 했는지뿐만 아니라, '왜(Why)' 이렇게 결정했는지 배경을 남깁니다. |핵심 기술: * Decision Log 작성: "당시 법규 대응을 위해 한시적으로 도입한 로직임" 같은 주석을 남깁니다. 문서 업데이트의 습관화: 작은 수정 사항이라도 반드시 최신 기획서에 반영하여 '살아있는 문서'를 만듭니다. 3. 유지보수 기획자가 사랑받는 비결: '점진적 개선' 한번에 다 갈아엎지 않기: 리스크를 최소화하기 위해 단계별 개선안을 제시합니다. 기술 부채(Technical Debt) 이해: 개발자가 "이건 구조적으로 힘들어요"라고 할 때, 그 이유를 경청하고 함께 타협안을 찾습니다. 정리 정돈의 미학: 복잡한 정책을 단순화하여 관리 포인트 자체를 줄여주는 기획자가 가장 유능한 기획자입니다. 포스팅 마무리 꿀팁 "오늘 여러분이 남긴 한 줄의 주석이 훗날 후임 기획자의 생명줄이 됩니다." 신규 기획만큼이나 위대한 것이 바로 기존 서비스를 안전하고 건강하게 유지하는 것입니다. 레거시라는 거대한 숲에서 길을 잃지 않고, 차근차근 지도를 그려나가는 기획자가 되어보세요.