기존 서비스를 개선하고 문서화하기

새 서비스를 처음부터 만드는 일은 분명 매력적이다. 아무것도 없는 상태에서 문제를 정의하고, 흐름을 설계하고, 화면을 세우는 과정은 창조의 기쁨이 크다. 하지만 실무에서 더 자주 마주치는 일은 다른 쪽에 있다. 이미 돌아가고 있는 서비스를 조금이라도 더 낫게 만드는 일이다.

이 일은 겉보기에 덜 화려하다. 이미 화면이 있고, 사용자도 있고, 지표도 있다. 그래서 새로 만드는 일보다 덜 창의적으로 느껴질 수 있다. 하지만 실제로는 더 어렵다. 기존 사용자의 습관을 건드리지 않아야 하고, 이미 쌓인 기술 제약도 고려해야 하며, 팀의 기대와 현실적인 리소스 사이에서 우선순위를 잡아야 하기 때문이다.

좋은 실무자는 새로 만드는 사람인 동시에, 이미 있는 것을 더 좋아지게 만드는 사람이다. 그리고 그 개선 과정을 설득력 있게 기록하는 능력까지 갖추면 훨씬 강해진다. 개선은 했는데 왜 했는지 설명하지 못하면 팀의 자산이 되지 않고, 문서만 예쁘게 썼는데 실제 결과가 없으면 신뢰를 얻기 어렵다. 이 장에서는 그 둘을 함께 다룬다.

기존 서비스 개선은 왜 별도의 기술인가

기존 서비스를 개선할 때는 출발점이 다르다. 빈 종이가 아니라, 이미 쓰이고 있는 종이 위에 덧그려야 한다. 그래서 새 프로젝트와는 다른 질문이 먼저 나온다.

지금 이 화면은 왜 이렇게 생겼는가. 누가 어떤 이유로 이 구조를 선택했는가. 사용자는 여기에 얼마나 익숙해져 있는가. 개발 구조상 당장 못 바꾸는 것은 무엇인가. 마케팅, 운영, 고객센터, 데이터 팀은 이 화면을 어떻게 보고 있는가.

이 질문들을 무시하고 "다 갈아엎으면 더 좋아질 것 같은데요"라고 접근하면 거의 항상 실패한다. 기존 서비스 개선은 멋진 새 시안을 만드는 일이 아니라, 지금의 맥락 안에서 가장 큰 병목을 찾아내고 가장 효율적인 변화부터 만드는 일에 가깝다.

그래서 개선 프로젝트의 첫걸음은 리디자인이 아니라 진단이다.

무엇부터 고칠 것인가: 문제 화면 선정

기존 서비스를 개선한다고 할 때 가장 흔한 실수는 눈에 거슬리는 화면부터 고르는 것이다. 디자인이 낡아 보이는 화면, 팀이 자주 불평하는 화면, 대표가 싫어하는 화면이 먼저 후보에 오른다. 하지만 보기 싫다는 이유만으로 가장 중요한 개선 대상이 되지는 않는다.

문제 화면은 보통 세 가지 기준으로 고르는 편이 좋다.

• 사용 빈도가 높은가

• 비즈니스 영향이 큰가

• 실제로 개선 가능한 범위인가

예를 들어 커머스 앱에서 아주 드물게 쓰는 설정 화면보다, 상품 상세나 장바구니, 결제 진입 화면이 더 우선순위가 높을 가능성이 크다. 생산성 도구라면 관리자 설정 페이지보다 첫 프로젝트 생성이나 팀 초대 화면이 더 중요할 수 있다. 핀테크 서비스라면 자주 쓰는 송금 확인 화면이, 콘텐츠 서비스라면 첫 탐색과 재방문 진입이 더 핵심일 수 있다.

여기서 중요한 것은 "큰 문제처럼 보이는 화면"이 아니라 "많은 사용자의 행동을 실제로 막고 있는 화면"을 고르는 것이다.

문제 화면을 정할 때는 이렇게 묻는 것이 좋다.

이 화면에서 사용자는 무엇을 하려는가. 그 행동이 전체 여정에서 얼마나 중요한가. 이 단계에서 멈추면 사업에도 타격이 큰가. 그리고 이 문제를 우리가 한두 번의 개선 사이클 안에서 검증할 수 있는가.

이 질문에 답하고 나면, 개선 범위가 훨씬 또렷해진다.

사례로 따라가 보기: 장바구니에서 결제로 넘어가지 않는 문제

이 장에서는 가상의 기존 커머스 앱 사례를 따라가 보겠다. 서비스는 이미 운영 중이고, 월간 사용자도 충분하다. 상품 상세 방문은 많고 장바구니 담기 비율도 괜찮다. 그런데 이상하게 장바구니에서 주문서로 넘어가는 비율이 기대보다 낮다.

처음 회의에서는 이런 말들이 나온다.

"장바구니 화면이 좀 촌스러워요." "결제 버튼이 약해 보여요." "요즘은 더 미니멀하게 가야 하지 않을까요?"

이 말들은 아주 틀린 것은 아니다. 하지만 아직 문제는 아니다. 지금 필요한 것은 취향이 아니라 증거다. 그래서 팀은 개선 범위를 이렇게 정리한다.

개선 대상: 장바구니 화면과 주문서 진입 직전 구간
관찰된 현상: 장바구니 진입 대비 주문서 진입률이 낮음
비즈니스 영향: 구매 전환 손실
개선 목표: 사용자가 결제 전에 불필요하게 망설이는 지점을 줄이기

이렇게 정리하면 프로젝트는 갑자기 현실적인 얼굴을 갖게 된다. 이제 "예쁘게 바꾸기"가 아니라 "왜 결제로 안 넘어가는지 찾기"가 목표가 된다.

데이터는 현상을 보여주고, 피드백은 이유를 보여준다

문제 화면을 정했다면 바로 시안을 그리지 말고, 먼저 자료를 모아야 한다. 기존 서비스 개선에서 가장 위험한 순간은 문제를 안다고 착각하는 순간이다. 숫자도 조금 보고, 사용자 말도 조금 들었는데 벌써 정답을 안 것처럼 느껴질 때가 있다. 이때 가장 엉뚱한 개선이 나온다.

장바구니 사례라면 먼저 정량 데이터를 본다. 예를 들면 이런 흐름이다.

• 상품 상세 진입 수

• 장바구니 담기 수

• 장바구니 화면 진입 수

• 주문서 진입 수

• 결제 완료 수

여기서 끝내지 말고 세부 구간도 나눈다. 모바일 앱과 모바일 웹이 같은지, 신규 사용자와 기존 사용자가 다른지, 특정 카테고리 상품에서 더 심한지 살핀다. 평균만 보면 흐릿하던 문제가, 구간을 나누는 순간 선명해지는 경우가 많다.

그다음에는 정성 자료를 본다. 고객센터 문의, 리뷰, 채팅 로그, 사용성 테스트, 세션 리플레이, 실제 사용자 인터뷰가 여기에 해당한다. 정량 데이터가 "어디서 이상한 일이 생기는지"를 보여준다면, 정성 자료는 "왜 거기서 멈추는지"를 짐작하게 해준다.

예를 들어 이런 단서가 나올 수 있다.

고객센터에는 "배송비가 마지막에 붙는 줄 몰랐다"는 문의가 반복된다. 세션 리플레이에서는 사용자가 쿠폰 영역을 몇 번 열었다 닫는 행동이 보인다. 사용성 테스트에서는 "할인 적용이 된 건지 안 된 건지 모르겠다"는 말이 나온다. 어떤 사용자는 로그인 유도 배너를 보고 결제를 중단한다.

이 순간, 팀은 중요한 사실을 깨닫는다. 문제는 단순히 화면이 못생겨서가 아니라, 사용자가 금액과 조건을 확신하지 못하는 데 있을 수 있다는 것이다.

병목은 현상이 아니라 원인으로 써야 한다

많은 팀이 여기서 멈춘다. "장바구니에서 이탈이 높다"라고 적고 바로 개선안을 만들기 시작한다. 하지만 이 문장은 현상일 뿐이다. 현상만으로는 좋은 해결책이 나오기 어렵다.

병목은 조금 더 해석된 문장이어야 한다. 예를 들면 이런 식이다.

"사용자는 장바구니 화면에서 총 결제 금액이 어떻게 구성되는지 빠르게 이해하지 못해 주문서 진입을 미루고 있다."

또는 이렇게도 쓸 수 있다.

"할인과 배송 조건이 여러 영역에 흩어져 있어 사용자가 지금이 가장 유리한 구매 시점인지 판단하기 어렵다."

이렇게 쓰면 해결 방향이 생긴다. 버튼 색을 바꾸는 일이 핵심인지, 정보 구조를 정리해야 하는지, 문구를 바꿔야 하는지, 계산 로직 자체를 고쳐야 하는지가 달라지기 때문이다.

좋은 병목 문장은 대개 세 가지를 포함한다. 누구의 문제인지, 어디서 생기는지, 왜 행동을 막는지다. 이 세 가지가 있어야 디자인 논의가 취향에서 구조로 넘어간다.

개선안은 하나가 아니라 최소 세 가지가 필요하다

실무에서 흔히 일어나는 일은 첫 아이디어에 너무 빨리 사랑에 빠지는 것이다. 특히 기존 서비스 개선에서는 시간이 부족하다는 이유로 첫 안이 곧 최종안이 되기 쉽다. 하지만 가능한 한 세 가지 정도의 대안은 만들어보는 편이 좋다. 그래야 팀이 해결책을 비교할 수 있고, 문서화할 때도 사고 과정이 살아난다.

장바구니 사례에서 나올 수 있는 개선안은 다음과 같다.

개선안 A: 금액 구조를 상단에서 바로 이해시키기

현재 화면에서는 상품 금액, 할인, 배송비, 쿠폰 정보가 여러 군데 흩어져 있다고 가정해보자. 그러면 사용자는 스스로 계산을 맞춰보느라 지친다. 이 안의 핵심은 총 결제 예상 금액과 그 구성 요소를 한눈에 정리해 보여주는 것이다.

예를 들어 상단 요약 카드에서 상품 금액, 할인 적용, 배송비 조건, 최종 예상 결제액을 한 덩어리로 묶는다. 특히 배송비가 무료가 되는 기준이나 추가 비용 조건은 작게 숨기지 않고 눈에 띄게 배치한다.

이 안의 장점은 사용자의 불확실성을 빠르게 줄인다는 점이다. 반면 화면이 조금 더 정보 중심적으로 보일 수 있고, 마케팅 배너의 우선순위가 낮아질 수 있다.

개선안 B: 할인과 쿠폰의 복잡성을 줄이기

어떤 서비스는 할인 혜택이 많을수록 좋아 보인다고 생각한다. 하지만 사용자가 이해하지 못하는 혜택은 혜택이 아니라 피로가 된다. 이 안의 핵심은 쿠폰 선택, 포인트 사용, 카드 할인 안내를 단순화하는 것이다.

가장 쉬운 방법은 적용 가능한 혜택을 자동으로 추천하거나, 현재 최대로 적용된 할인을 명확하게 보여주는 것이다. "쿠폰을 고르세요"보다 "지금 적용 가능한 최대 할인 3,000원이 반영되었어요"가 훨씬 안심된다.

이 안의 장점은 판단 부담을 줄인다는 점이다. 다만 프로모션 정책이 복잡한 조직이라면 기획과 개발 협의가 조금 더 필요할 수 있다.

개선안 C: 결제 진입 전 불안을 줄이는 보조 장치 넣기

사용자는 종종 돈 때문만이 아니라 신뢰 때문에 멈춘다. 반품 정책, 배송 일정, 품절 시 처리 방식, 비회원 구매 가능 여부 같은 정보가 늦게 드러나면 "나중에 문제가 생기지 않을까?"라는 마음이 커진다.

이 안의 핵심은 장바구니 하단이나 CTA 근처에 사용자가 마지막으로 확인하고 싶은 정보를 짧고 명확하게 배치하는 것이다. 예를 들어 "배송 예정일", "반품 가능 조건", "비회원도 주문 가능" 같은 안내를 CTA 가까이에 두면, 사용자는 다시 위아래를 오가며 확인할 필요가 줄어든다.

이 안의 장점은 작은 수정으로 신뢰를 높일 수 있다는 점이다. 하지만 근본적인 금액 구조 혼란이 큰 상황이라면 이 안만으로는 충분하지 않을 수 있다.

좋은 개선안 비교는 결국 이런 질문으로 이어진다. 무엇이 가장 큰 병목을 직접 해결하는가.

우선순위는 감이 아니라 기준으로 정한다

개선안이 여러 개 나왔다고 해서 다 한 번에 하면 좋을 것 같지만, 실제 프로젝트는 그렇게 움직이지 않는다. 개발 리소스도 한정되어 있고, 동시에 너무 많은 것을 바꾸면 무엇이 효과를 냈는지 알기도 어렵다.

그래서 우선순위를 정할 기준이 필요하다. 가장 단순하면서 실무적인 방식은 세 가지다.

• 영향도: 핵심 지표를 얼마나 움직일 가능성이 큰가

• 확신도: 데이터와 사용자 근거가 충분한가

• 비용: 구현과 운영 부담이 얼마나 드는가

장바구니 사례를 간단히 정리하면 이런 식이 된다.

이 표를 보면 보통 첫 번째와 세 번째 안을 먼저 묶어볼 수 있다. 사용자 불안을 직접 다루고, 구현 부담도 상대적으로 관리 가능하기 때문이다. 두 번째 안은 효과가 클 수 있지만 정책과 시스템 복잡도가 높다면 다음 단계로 미뤄도 된다.

여기서 중요한 것은 "가장 멋진 안"이 아니라 "지금 가장 효과적으로 검증할 수 있는 안"을 먼저 선택하는 것이다.

Before와 After는 화면 차이가 아니라 판단 차이여야 한다

개선 프로젝트를 하다 보면 종종 결과물이 이렇게 정리된다. 왼쪽은 기존 화면, 오른쪽은 개선 화면. 그리고 끝이다. 하지만 이런 문서는 예쁘게 보일 수는 있어도 설득력은 약하다. 왜 바꿨는지, 무엇을 기대했는지, 어떤 문제를 해결했는지가 빠져 있기 때문이다.

좋은 Before/After 설명은 화면 비교가 아니라 판단 비교다.

예를 들어 이렇게 써야 한다.

기존 화면에서는 할인, 배송비, 최종 결제액이 서로 떨어져 있어 사용자가 총액을 빠르게 예측하기 어려웠다. 개선 화면에서는 결제 예상 금액과 조건을 상단 요약 카드에 통합해 주문 전 판단 시간을 줄이고자 했다.

또는 이렇게도 쓸 수 있다.

기존 화면의 CTA 주변에는 사용자가 마지막으로 궁금해할 배송 예정일과 반품 정보가 없었다. 개선 화면에서는 CTA 가까이에 핵심 신뢰 정보를 배치해 결제 직전의 불안을 줄이도록 했다.

이렇게 쓰면 화면이 아니라 의도가 기억된다. 그리고 이 의도는 나중에 팀의 자산이 된다.

결과 측정은 출시 다음 날 끝나지 않는다

개선안을 적용했다면 이제 결과를 봐야 한다. 그런데 이 단계에서도 자주 생기는 오해가 있다. 수치가 조금 올랐으니 성공이라고 말하거나, 기대만큼 안 올랐으니 실패라고 말하는 것이다. 실제로는 훨씬 신중하게 읽어야 한다.

먼저 이번 개선의 핵심 지표를 정한다. 장바구니 사례라면 주문서 진입률이 핵심 지표가 될 수 있다. 그리고 보조 지표를 붙인다. 장바구니 체류 시간, 쿠폰 영역 재진입 횟수, 배송비 문의 비율, 결제 완료율이 여기에 해당할 수 있다. 마지막으로 안전 지표도 본다. 예를 들어 주문 취소율, 환불 문의, 고객 불만 증가 여부 같은 것들이다.

결과를 읽을 때는 이렇게 보는 편이 좋다.

첫째, 전체 평균만 보지 않는다. 모바일 앱에서만 좋아졌는지, 신규 사용자에게 특히 효과가 있었는지, 특정 카테고리에서만 차이가 있는지 본다.

둘째, 짧은 반응만 보고 결론 내리지 않는다. 주말 프로모션이나 광고 유입 같은 외부 변수도 있을 수 있기 때문이다.

셋째, 수치와 사용자 반응을 함께 본다. 주문서 진입률이 올었는데 고객센터 문의도 줄었다면, 단순히 클릭이 늘어난 것이 아니라 실제 혼란이 줄었을 가능성이 높다.

가상의 예를 들어보자. 개선 후 2주 동안 이런 결과가 나왔다고 하자.

• 장바구니 대비 주문서 진입률 11% 상승

• 신규 사용자 구간에서 16% 상승

• 배송비 관련 고객 문의 24% 감소

• 장바구니 평균 체류 시간 소폭 감소

• 결제 완료율은 4% 상승

이 결과는 꽤 의미가 있다. 사용자가 덜 망설였고, 그 변화가 실제 구매 행동에도 연결되었다는 뜻일 가능성이 크다. 반대로 주문서 진입률은 올랐는데 결제 완료율이 그대로라면, 문제는 장바구니가 아니라 주문서 내부에 남아 있을 수 있다. 그러면 개선 범위를 다음 단계로 옮겨야 한다.

좋은 개선 프로젝트는 배운 것까지 남긴다

실무에서 정말 아쉬운 순간은 개선이 끝난 뒤 아무 기록도 남지 않는 경우다. 팀은 분명 열심히 일했고 수치도 어느 정도 좋아졌지만, 몇 달 지나면 왜 바꿨는지 아무도 설명하지 못한다. 새로 온 팀원은 다시 같은 질문을 하고, 비슷한 논쟁이 반복된다.

그래서 개선 프로젝트는 결과만이 아니라 학습을 남겨야 한다.

예를 들어 장바구니 사례에서 남길 수 있는 학습은 이런 것이다.

첫째, 사용자는 할인 규모보다 결제 총액의 예측 가능성에 더 민감했다.
둘째, 배송 조건은 상세 페이지보다 장바구니 단계에서 다시 확인하고 싶어 했다.
셋째, CTA를 강조하는 것보다 CTA 주변의 불안 요인을 줄이는 편이 더 효과적이었다.

이런 문장은 다음 프로젝트의 출발점이 된다. 좋은 조직은 화면을 쌓는 것이 아니라 학습을 쌓는다.

케이스 스터디 문서화는 어떻게 해야 하는가

이제 문서화 이야기로 넘어가 보자. 많은 사람이 포트폴리오나 회고 문서를 만들 때 완성 화면부터 보여준다. 하지만 기존 서비스 개선 프로젝트에서 더 중요한 것은 결과물 자체보다 사고 과정의 연결이다.

좋은 케이스 스터디는 보통 다음 흐름을 가진다.

1. 배경 설명

서비스가 어떤 상황이었는지 짧게 정리한다. 이미 운영 중인 서비스였는지, 어떤 핵심 흐름에서 문제가 있었는지, 왜 이 개선이 필요했는지를 설명한다.

예를 들어 이렇게 시작할 수 있다.

"운영 중인 커머스 앱에서 장바구니 진입 대비 주문서 진입률이 기대보다 낮았다. 팀은 구매 전환의 핵심 병목이 장바구니 구간에 있다고 판단했고, 사용자의 결제 직전 불안을 줄이는 개선 프로젝트를 진행했다."

이 한 문장만 있어도 문서의 방향이 생긴다.

2. 문제 정의

여기서는 막연한 감상이 아니라, 관찰 가능한 문제를 써야 한다. 가능하면 정량과 정성을 함께 둔다.

예를 들면 이런 구조다.

• 장바구니 대비 주문서 진입률이 특정 구간에서 낮았다.

• 배송비와 할인 관련 문의가 반복적으로 발생했다.

• 사용성 테스트에서 총 결제 금액 예측이 어렵다는 반응이 나타났다.

이후에는 이것을 한 줄의 문제 문장으로 압축한다.

"장바구니 화면의 정보 구조가 총 결제 금액과 조건을 빠르게 이해하기 어렵게 만들어 결제 직전 이탈을 유발하고 있었다."

3. 목표와 성공 기준

문서에서 이 부분이 빠지면 프로젝트는 산만해진다. 무엇을 바꾸려 했는지보다, 무엇이 좋아지면 성공이라고 볼 것인지를 써야 한다.

예를 들어 목표는 이렇게 적을 수 있다.

"사용자가 장바구니에서 총 결제 조건을 빠르게 이해하고, 주문서로 더 자신 있게 이동하게 만든다."

성공 기준은 이렇게 적는다.

• 핵심 지표: 주문서 진입률 상승

• 보조 지표: 배송비 관련 문의 감소, 체류 시간 감소

• 안전 지표: 주문 취소율 악화 없음

4. 조사와 해석

이 장이 케이스 스터디의 신뢰를 만든다. 무엇을 봤고, 그걸 어떻게 해석했는지 적어야 한다. 단순히 "리서치를 했다"로 쓰면 약하다.

어떤 데이터를 봤는지, 어떤 사용자 발화를 관찰했는지, 무엇이 반복 패턴이었는지, 그 근거로 어떤 가설을 세웠는지 연결해서 보여줘야 한다.

여기서 중요한 것은 자료를 많이 나열하는 것이 아니다. 결정에 영향을 준 근거만 선별해 보여주는 것이다.

5. 대안 탐색과 선택 이유

많은 문서가 이 부분을 생략한다. 하지만 실무자는 보통 여기서 실력을 본다. 최종안만 보면 결과는 알 수 있어도 판단 수준은 알기 어렵다. 어떤 대안을 고려했고, 왜 그중 하나를 선택했는지를 써야 한다.

예를 들어 세 가지 개선안을 비교했고, 그중 금액 구조 상단 요약과 CTA 근처 신뢰 정보 보강을 1차 적용안으로 선택했다면, 그 이유를 적는다. 영향도는 높고 구현 부담은 상대적으로 낮았기 때문이라는 식이다.

실패한 안이나 보류한 안도 짧게 남겨두면 좋다. 그것은 부끄러운 기록이 아니라 팀의 판단 이력이다.

6. 최종 개선안 설명

이제서야 화면을 보여준다. 그리고 화면 설명은 장식보다 의도 중심으로 쓴다.

무엇을 위로 올렸는지, 무엇을 묶었는지, 무엇을 제거했는지, 왜 그랬는지를 한두 문장씩 분명하게 적는다. 이 단계에서는 "깔끔하게 정리했다" 같은 표현보다 "결제 금액의 구성 요소를 한 영역으로 통합했다" 같은 표현이 더 좋다.

7. 결과와 해석

수치를 보여줄 때는 과장하지 말아야 한다. 숫자가 좋아졌다면 무엇이 좋아졌는지 정확히 쓰고, 아직 해결되지 않은 문제도 함께 적는다.

예를 들어 이렇게 정리할 수 있다.

"주문서 진입률은 개선되었지만, 주문서 내 쿠폰 적용 단계에서 여전히 이탈이 남아 있었다. 따라서 다음 개선 사이클에서는 주문서 내부 할인 적용 경험을 별도로 다룰 필요가 있다."

이 한 문장만으로도 문서는 훨씬 성숙해진다. UX는 한 번에 완성되는 일이 아니라는 사실을 보여주기 때문이다.

8. 배운 점

마지막에는 교훈을 적는다. 다만 너무 추상적이면 안 된다. "사용자 중심이 중요했다" 같은 말은 거의 남지 않는다. 대신 프로젝트를 통해 새롭게 확인한 구체적인 학습을 적어야 한다.

예를 들어 이런 식이다.

• 사용자는 혜택의 양보다 계산의 명확성을 더 신뢰했다.

• CTA 성능은 버튼 자체보다 주변 정보의 신뢰도에 크게 영향을 받았다.

• 기존 서비스 개선에서는 전면 개편보다 핵심 병목 제거가 더 빠른 효과를 만들었다.

이런 문장은 다음 프로젝트에도 바로 연결된다.

포트폴리오용 문서와 실무용 문서는 어떻게 다른가

문서화라고 하면 많은 사람이 포트폴리오만 떠올리지만, 실제로는 목적에 따라 문서의 결이 달라져야 한다.

실무용 문서는 팀이 빠르게 이해하고 결정할 수 있어야 한다. 그래서 배경, 문제, 근거, 안, 일정, 영향 범위가 분명해야 한다. 짧고 선명한 것이 중요하다.

반면 포트폴리오용 문서는 당신의 사고 과정을 보여줘야 한다. 그래서 왜 이 문제를 중요하게 봤는지, 어떤 선택을 했고 어떤 선택을 하지 않았는지, 결과를 어떻게 해석했는지가 더 중요하다.

둘의 공통점도 있다. 둘 다 결국 문제에서 결과까지의 연결이 있어야 한다는 것이다. 화면만 있으면 앨범이고, 과정만 있고 결과가 없으면 일기다. 좋은 문서는 둘 사이를 연결한다.

개선 문서를 쓸 때 자주 하는 실수

기존 서비스 개선 문서에서 자주 보이는 실수도 있다.

첫째, 문제보다 결과 화면을 먼저 보여주는 실수다. 그러면 보는 사람은 무엇이 바뀌었는지는 알아도 왜 바뀌었는지는 이해하기 어렵다.

둘째, 데이터는 붙였지만 해석이 없는 실수다. 숫자는 보여줬는데 그 숫자가 어떤 행동을 의미하는지 설명하지 않으면 문서는 차가워 보이고 설득력도 떨어진다.

셋째, 성공만 쓰고 실패를 지우는 실수다. 하지만 실무자는 보통 완벽한 사람보다, 잘못된 가설을 어떻게 수정했는지 아는 사람을 더 신뢰한다.

넷째, 자신의 역할을 흐리게 쓰는 실수다. "프로젝트를 진행했다"보다 "문제 정의와 개선안 설계, 테스트 해석을 주도했다"처럼 책임 범위를 분명히 쓰는 편이 낫다.

다섯째, 너무 넓은 이야기를 한 번에 담으려는 실수다. 하나의 케이스 스터디는 하나의 핵심 문제를 중심으로 읽히는 편이 훨씬 강하다.

바로 가져다 쓸 수 있는 개선 프로젝트 문서 구조

실무나 포트폴리오에서 바로 쓸 수 있도록, 문서의 뼈대를 간단히 정리해보면 이렇다.

이 구조만 잘 지켜도 문서는 훨씬 단단해진다.

결국 기존 서비스 개선은 사용자와 팀의 기억을 함께 다루는 일이다

새 서비스는 아직 습관이 없지만, 기존 서비스는 이미 사용자의 습관 위에 서 있다. 그래서 개선은 항상 조심스럽다. 너무 적게 바꾸면 효과가 없고, 너무 크게 바꾸면 익숙함이 깨진다. 그 균형을 잡는 일이 실무자의 감각이다.

여기서 중요한 것은 두 가지다. 하나는 무엇이 실제 병목인지 정확히 보는 눈이고, 다른 하나는 그 과정을 팀이 다시 사용할 수 있도록 남기는 습관이다. 이 둘이 만나야 개선이 일회성 이벤트가 아니라 조직의 학습이 된다.

결국 잘하는 사람은 새로 만드는 사람만이 아니다. 이미 있는 서비스를 더 명확하게, 더 쉽게, 더 믿을 수 있게 바꾸는 사람이다. 그리고 그 변화가 왜 필요했고 무엇을 바꾸었으며 어떤 결과를 만들었는지 차분하게 설명할 수 있는 사람이다.

그 능력은 포트폴리오를 위한 기술이 아니다. 제품을 더 오래, 더 건강하게 성장시키는 실무의 핵심 역량이다.