[외주] 클라이언트와의 첫 프리랜서 프로젝트에서 배운 것들 - 스코프 크리프와 커뮤니케이션

1. 시작은 간단했습니다

부산에서 서울로 상경할 때, 원장님께서 먼저 연락을 주셔서 지인 할인으로 월세 70만원짜리 방을 50만원에 입주하게 되었습니다. 그렇게 고시원에서 생활하던 중 원장님께서 프로그램 개발을 도와줄 수 있냐고 부탁하셨고, 그것이 첫 프리랜서 프로젝트의 시작이었습니다.

처음 원장님께서 말씀하신 요구사항은 정말 단순했습니다.

"건물 도면을 이용해서 층별로 누가 살고 있는지 볼 수 있는 대시보드요. 간단하게만 만들어주세요."

구체적으로는 이 세 가지였습니다.

• 고시원의 장부 관리
• 현재 어느 방에 누가 살고 있는지 그리고 각 입실자가 언제부터 언제까지 거주하는지를 한 눈에 볼 수 있어야함.
• 특정 장소에서만 확인할 수 있는 방식이 아니라, 어디서든 접속해서 바로 볼 수 있는 형태를 원하셨다.

충분히 할 수 있는 범위였고, 흔쾌히 수락했습니다.

 

2. 기능이 불어나기 시작했습니다

작업을 시작하고 나서 요구사항이 하나씩 추가되기 시작했습니다. 처음엔 사장님께서 "이것도 되면 좋겠는데"라는 가벼운 말 한마디였는데, 결과적으로 최종 기능 목록은 이렇게 되어 있었습니다.

• TodoList
  • 할일 체크
  • 색깔별 구분 기능
• 대시보드
  • 층별 도면 형태의 현재 입실자 기본 정보 관리
  • 공실 상태 관리 (예약 포함)
  • 월세 납부 관리
  • 보증금 관리
  • 납부 여부 확인 기능
  • 실제 도면 PDF 다운로드 기능
  • 총 방 개수, 총 입실자 수, 현재 공실, 계약 현황 숫자 표시
• 입실자 관리
  • 층별 / 방별 상태 관리 및 유지보수 관리
  • 현재 입실자 기본 정보 관리
  • 예정 입실 관리
  • 공실 상태 관리
  • 월세 납부 및 보증금 관리
  • 퇴실 및 거주 이력 관리
  • 납부 여부 확인 기능
  • 현금 승계, PDF 출력 기능
  • 통계 숫자 표시
• 연간 캘린더
  • 막대 그래프 및 클릭 시 상세 화면
  • 층별 필터 기능
  • 통계 숫자 표시
• 통계
  • 납부 상태 현황
  • 월별 예상 수입 추이
  • 연간 유지보수 현황
  • 전체 방, 입실율, 이번 달 예상 수입, 미납 건 숫자 표시

처음 세 가지에서 시작해서 어느 순간 다섯 개의 큰 메뉴와 수십 개의 세부 기능이 생겨 있었습니다. 이른바 스코프 크리프(Scope Creep) 였습니다. 요구사항이 계획 없이 조금씩 계속 늘어나는 현상입니다.

 

3. 커뮤니케이션 문제가 겹쳤습니다

기능이 늘어난 것도 문제였지만, 더 힘들었던 건 커뮤니케이션 구조였습니다. 4월 27일에 배포를 마쳤고, 배포 이후 수정 요청이 들어오는 것 자체는 당연한 일이었습니다. 그런데 그 과정에서 문제가 생기기 시작했습니다. 수정 요청이 들어오는 경로는 다음과 같았습니다.

• 사장님 → 총무님들 → 나

사장님이 직접 말씀하시는 게 아니라 총무님들을 통해 전달이 됐고, 저는 그걸 받아서 수정했습니다. 그런데 수정을 마치고 나면 사장님이 "이게 아닌데요"라고 하시는 경우가 반복됐습니다. 전달 과정에서 의도가 바뀌거나 빠진 것들이 있었던 겁니다.

 

수정 요청뿐만 아니라 새로운 기능 요구도 계속 이어졌습니다. "TodoList에서 할일을 체크하면 알림이 왔으면 좋겠다", "휴대폰 앱으로도 쓸 수 있으면 좋겠다" 같은 식이었습니다. 배포가 끝이 아니라 오히려 새로운 시작처럼 느껴졌습니다. 거기에 원장님께서는 "너무 시간 많이 쓰지 마라"고 하시면서도 사장님께서는 "언제까지 되냐, 내가 바쁜 건 바쁜 것과 별개다"라는 말씀도 하셨습니다. 빠르게 해달라는 건지, 천천히 해도 된다는 건지 알 수 없는 상황이었습니다. 이 상태로 계속 가다가는 서로 지치겠다는 생각이 들었습니다.

 

4. 제가 선택한 방법

두 가지를 결정했습니다.

1. 추가 비용을 요청했습니다. → 추가된 기능 범위와 앞으로의 유지보수까지 고려해서, 한 달에 15만원씩 1년간의 유지보수 계약을 제안했습니다.
2. 계획표 기반의 작업 구조를 제안했습니다. → 앞으로 기능 요청이 들어올 때마다 먼저 계획표를 작성해서 드리고, 그 계획표를 기준으로 작업하겠다고 했습니다. 기간이 늘어나거나 줄어들 것 같으면 미리 업데이트해서 공유하는 방식이었습니다.

제안을 드리기 전에 먼저 사장님과 원장님께 그동안 제가 얼마나 공을 들여 작업했는지를 말씀드렸습니다. 그리고 기능을 추가하거나 수정하는 일이 왜 단순하지 않은지도 설명드렸습니다. 예를 들어 퇴실 처리 같은 경우, 하나의 데이터가 여러 데이터와 연결되어 있어서 하나를 바꾸면 연관된 것들을 전부 함께 수정해야 한다고 말씀드렸습니다. 말 한마디로 뚝딱 되는 게 아니라는 걸 구체적으로 설명드렸습니다.

이건 단순히 비용의 문제가 아니라 의사소통의 문제라고 생각했습니다. 서로 얼마나 걸리는 일인지, 왜 어려운지를 모르는 상태에서는 아무리 좋은 관계라도 오해가 쌓일 수밖에 없습니다. 또한 요청해 주시는 기능이 많아진 만큼, 비용을 받고 명확한 계약 안에서 진행하는 것이 저도, 클라이언트도 서로 더 깔끔하게 일할 수 있는 방법이라고 판단했습니다.

 

이걸 계약서 형태로 정리해서 드렸고, 여러 번의 대화 끝에 합의가 이루어졌습니다. 그 과정에서 사장님과 원장님께서 먼저 미안하다고 말씀해 주셨습니다. 말만 하면 다 되는 줄 알았는데, 막상 개발이 얼마나 어렵고 손이 많이 가는 일인지 잘 몰랐다고 하셨습니다. 또한 처음부터 요구사항을 좀 더 자세하게 정리해서 말했더라면 제가 덜 힘들었을 텐데, 너무 복잡하게 만들어서 미안하다고도 하셨습니다. 그 말씀들이 그동안의 고생을 많이 풀어주었습니다. 누가 잘못했는지를 따지는 게 아니라, 서로가 더 잘할 수 있었던 부분을 함께 돌아보게 된 순간이었습니다.

 

5. 이 경험에서 배운 것들

1. 요구사항은 반드시 문서로 남겨야 합니다. → 말로만 주고받으면 나중에 서로 기억하는 게 달라집니다. 처음부터 요구사항을 문서로 정리하고 "이 범위까지입니다"를 명확히 했어야 했습니다.
2. 커뮤니케이션 창구는 하나여야 합니다. → 중간에 여러 사람을 거치면 의도가 바뀝니다. 원장님과 직접 소통하는 구조를 처음부터 만들었어야 했습니다.
3. 범위가 늘어나면 비용과 일정도 같이 조정되어야 합니다. → 추가 요청을 수락하는 순간, 그게 공짜 야근의 시작이 될 수 있습니다. 기능이 늘어나면 당연히 비용과 기간도 같이 협의해야 한다는 걸 이번에 몸으로 배웠습니다.
4. 계획표는 나를 지키는 도구입니다. → 일정을 공유하는 게 단순히 진행 상황 보고가 아니라, 무리한 요청을 막는 방패가 된다는 걸 알게 되었습니다.

이번 프로젝트를 하면서 클라이언트를 대하는 마음가짐에 대해서도 많이 생각하게 되었습니다. 사장님과 원장님도 처음부터 어렵게 하려고 하신 게 아니라, 운영하시면서 필요한 것들이 생기다 보니 자연스럽게 요구사항이 늘어난 것이었습니다. 그 마음을 이해하면서도 개발자로서 지켜야 할 선을 지키는 것, 그 균형을 맞추는 게 쉽지 않다는 걸 느꼈습니다.

 

돌이켜보면 현업에서는 이런 상황이 훨씬 더 자주, 더 큰 규모로 일어날 것입니다. 그런 의미에서 이번 경험은 단순한 사이드 프로젝트 이상이었습니다. 실제 클라이언트와 부딪히며 요구사항을 조율하고 커뮤니케이션 구조를 만들어가는 과정을 미리 경험해볼 수 있었습니다. 기술적인 성장보다 일하는 방식에서 더 많이 배운 뜻깊은 시간이라고 생각이 들었습니다.