정부지원금으로 외주개발한 플랫폼, 2년 뒤 망하는 이유
2년 뒤에도 망하지 않는 외주개발 설게와 운영 체크포인트
안녕하세요! 킵고잉걸이에요~~ :)
지난번엔 MVP 확장 타이밍을 주제로 이야기를 했었는데요!
오늘도 비슷하지만 조금은 다른 이야기를 해보려고 해요~
정부지원사업으로 앱이나 웹 서비스를 한 번쯤 만들어본 분들이라면,
런칭까지는 어떻게든 버티는데 그 이후가 진짜 시작이라는 점 알고계실거예요...ㅎㅎ
사업기간 안에 시제품을 완성하고 평가를 통과했을 때까지만 해도 꽤 뿌듯하거든요!
간판 걸 서비스도 생긴 것 같고, 보고서도 무사 통과했고,
초기 사용자도 조금씩 들어오니까요~ㅎㅎㅎ
그런데 1년, 2년이 지나면 상황이 슬슬 달라지기 시작해요...ㅠㅠㅠ
간단해 보이는 수정인데도 견적이 계속 크게 나오고,
새로운 기능을 붙이려 하면 구조상 어렵다는 답변을 자주 듣게 되구요...
조금만 손을 대도 어디가 같이 무너질지 몰라서
팀 내부에서도 이 서비스를 건드리는 일이 점점 부담스러워지죠.
어느 순간에는 이걸 계속 붙들고 가는 게 맞는지,
차라리 처음부터 다시 만드는 게 나은지 고민이 커지기도 해요.
오늘은 정부지원 외주개발로 만든 서비스가
왜 2년 즈음에 대체로 망하는 코스로 들어가는지,
그리고 처음 외주 설계 단계에서 무엇을 바꿔야
이 흐름을 막을 수 있는지 사업개발자의 관점에서 이야기해보려고 해요! :)
정부지원금 외주개발 2년 뒤에 생기는 문제
처음 6개월에서 1년 정도는 문제가 잘 드러나지 않아요.
평가도 통과했고, 큰 장애가 없으면 대체로 좋은 분위기가 유지되기 쉬워요!
이용자가 많지 않은 초기에는 구조적인 한계도 잘 느껴지지 않는데요,
그런데 실제 운영이 쌓이면서 운영팀의 요구가 하나둘씩 생기기 시작해요...
관리자 화면에서 필터를 하나 더 넣어달라는 요청,
엑셀 다운로드 기능이 있으면 좋겠다는 제안,
알림 규칙을 조금 조정해달라는 요구 같은 것들이 점점 쌓여가죠ㅎㅎ..ㅠ
운영자 입장에서는 사소한 개선처럼 느껴지는데,
개발사에서는 생각보다 일이 크다고 설명하는 경우가 많아요~ ㅜㅠㅜㅜㅜㅜ
견적이 예상보다 크게 나오거나, 기존 구조와 맞지 않는다며 새 개발을 권유받기도 해요.
담당자가 바뀌면 난이도는 한 번 더 올라가요.
새 PM이나 디자이너는 서비스 설계 히스토리를 모르기 때문에,
어디까지 건드려도 되는지 감도 잘 오지 않구요...
조금만 수정해도 다른 부분에 영향이 갈까 봐 손이 느려지고,
어느 순간 이 서비스는 팀 내부에서 건드리기 무서운 존재가 되어버리기도 하죠 ㅎㅎ
이쯤 되면 처음에는 잘 만든 줄 알았는데 시간이 갈수록 망해가는 느낌이 들죠 ㅠㅠ
그렇다면 이 상황은 도대체 어디에서 시작된 걸까요?!
서비스 망하는 전형적인 정부지원금 외주개발 구조
여러 팀과 프로젝트를 지켜보면,
정부지원 외주개발이 2년 뒤에 망하는 이유는 공통적인 몇 가지가 있어요!
외주개발사의 역량 문제라기보다는
처음 외주를 어떤 기준으로 설계했는지가 더 큰 영향을 주는 경우가 많아요.
1. 사업기간 내 런칭만 목표가 되는 구조
지원사업 특성상 일정과 평가가 가장 강력한 기준이 되는데요!
기획과 개발의 방향이 자연스럽게 런칭 데드라인과 결과보고서에 맞춰지기 쉬워요.
운영과 확장, 리뉴얼은 대부분 나중에 생각해도 된다는 쪽으로 밀려나 있어요.
그 결과 서비스는 평가를 통과할 만큼의 기능은 갖추지만,
예외 케이스나 운영 효율을 고려한 설계는 충분하지 않은 상태가 되겠죠...ㅠㅠ
초기에는 이 사실이 잘 드러나지 않지만,
실제 사용자가 늘고 운영 상황이 복잡해질수록
구조적인 한계가 서서히 드러나기 시작해요.
이때부터는 작은 요구도 계속 구조와 부딪히는 느낌이 들기 쉬워요~
2. 소스와 인프라가 개발사 내부에만 묶이는 구조
두 번째 패턴은 소스코드와 인프라, 설정 정보가
모두 개발사 내부에만 묶여 있는 구조예요.
코드 레포지토리, 서버 계정, 배포 파이프라인 등
핵심 정보가 클라이언트 계정이 아니라 개발사 계정에만 있으면
시간이 갈수록 서비스는 점점 유지하기 힘들어져요.
담당 개발자가 바뀌거나,
더 이상 이 프로젝트를 우선순위에 두기 어려운 상황이 오면
새로운 개발사를 찾으려 해도 진입 장벽이 높아져요!
코드와 인프라를 이해하는 데만 시간이 많이 들어가고,
작은 수정도 리스크가 크게 느껴지기 때문이에요.
결국 내부에서는 이 서비스에 손대는 일을 피하게 되고,
서비스는 조용히 방치되는 수순으로 가기 쉬워요 ㅠㅠ
3. 화면만 쌓아 올린 디자인·데이터 구조
세 번째 패턴은 디자인 시스템과 데이터 모델 없이 화면 위주로 쌓아 올린 구조예요...!
지원기간 안에 구현해야 할 화면과 기능이 많다 보니
페이지 단위로 급하게 작업을 진행하는 경우가 많아요.
버튼, 입력 폼, 카드, 모달 같은 기본 컴포넌트가
페이지마다 조금씩 다르게 구현되기 쉬워요,..ㅜ
데이터 구조도 장기 운영 관점이 아니라,
그때그때 필요한 필드를 추가하는 방식으로 쌓이는 경우가 많아요.
이렇게 되면 새로운 기능을 붙이거나
정책을 바꿀 때마다 예상하지 못한 제약이 계속 생겨요.
팀원이 바뀔수록 전체 구조를 이해하는 사람은 줄어들고,
서비스는 점점 오래된 건물처럼 건드리기 어려운 상태가 되죠...ㅎㅎ
2년 뒤에도 지속되는 플랫폼 외주개발 꿀팁
서비스가 2년 뒤에도 제 역할을 하려면,
처음 정부지원 외주개발을 설계할 때부터 기준을 다르게 잡아야 해요!
빠른 런칭만을 목표로 하는 대신
장기 운영과 2차 고도화를 함께 전제로 두는 것이 중요해요~~
1. 기획 단계에서 운영과 데이터부터 그리기
기획 단계에서는 화면 목록과 기능 리스트를 정리하는 것에서 한 발 더 나가야 해요.
운영자가 실제로 어떤 흐름으로 일을 처리하는지,
어떤 데이터를 보고 의사결정을 하는지 먼저 그려보는 편이 좋아요!
예약, 승인, 정산, 후기 관리처럼
도메인마다 반복되는 흐름을 분해해서 정리해두면 도움이 되겠죠?!
또한 어떤 데이터가 언제 생성되고, 누가 조회하고, 어떻게 수정되는지
최소한의 데이터 모델을 함께 정리해두는 것이 좋아요.
이 흐름이 잡혀 있어야 나중에 정책이 바뀌거나 사용자가 늘어날 때도
구조를 크게 흔들지 않고 대응할 수 있어요.
어드민 화면과 대시보드도 처음부터 꼭 필요한 최소 단위만이라도
함께 설계해두면 운영 피로도를 크게 줄일 수 있어요. ㅎㅎ
2. 계약과 산출물에서 소유권과 문서 확보하기
외주개발 계약을 할 때는 결과물뿐 아니라 소유권과 문서를 함께 요구해야 해요.
소스코드 레포지토리는 가능하면 클라이언트 계정을 기준으로 만들고,
개발사는 협업자로 참여하는 구조가 안전해요.
클라우드 계정, 도메인, 배포 파이프라인도
나중에 내부 개발자나 다른 파트너에게 넘길 수 있는 형태로 정리해두는 편이 좋아요~ㅎㅎ
산출물도 화면 디자인 파일과 완성된 서비스만으로는 부족해요.
서비스 구조를 보여주는 간단한 아키텍처 다이어그램,
주요 테이블과 관계를 정리한 데이터 모델,
핵심 API 인터페이스 정도는 문서로 남겨두는 것이 좋아요.
이런 문서는 새로운 인력이 합류할 때 온보딩 속도를 크게 줄여주고,
특정 개발사에 종속되는 위험을 줄여줘요.
3. 디자인 시스템과 컴포넌트 기준 설정하기
디자인 측면에서는 페이지 단위보다 컴포넌트 단위로 기준을 잡아두는 것이 중요해요.
버튼, 입력창, 리스트, 카드, 모달 등
자주 쓰이는 요소의 스타일과 사용 규칙을 미리 정의해두면 좋아요.
컬러, 타이포그래피, 여백 기준을 토큰처럼 관리하면
화면이 늘어나도 전체 분위기가 크게 흐트러지지 않아요.
이렇게 디자인 시스템을 외주 범위 안에 포함시키면
시간이 지나 화면이 늘어나도 서비스의 무드가 심하게 흔들리지 않아요.
새로운 디자이너가 합류해도 기존 규칙을 참고해 자연스럽게 확장할 수 있고,
개발자 입장에서도 재사용 가능한 컴포넌트로 구현해 유지보수 효율을 높일 수 있어요 :)
4. 장기 운영과 2차 고도화까지 가정하는 파트너 찾기
장기적으로 서비스가 버티려면,
외주개발 파트너도 이런 관점을 공유하는 팀인지가 중요해요!
개발만 단독으로 수행하는 팀이 아니라, 기획과 데이터, 디자인 시스템,
운영 플로우까지 함께 설계할 수 있는 팀인지 보는 편이 좋아요~ㅎㅎ
저도 정부지원사업 프로젝트를 여러 번 진행하면서
외주 파트너로 똑똑한개발자와 함께한 경험이 있는데요!
지원기간 안에 MVP를 내는 것과 동시에
이후 지표가 나오면 어떤 기능을 확장할지, 어떤 부분을 리뉴얼할지까지
미리 가정하면서 데이터 모델과 어드민 구조, 디자인 시스템을 함께 잡아준 덕분에
사업 종료 후에도 완전히 새로 만드는 대신
기존 구조를 활용해 고도화를 이어갈 수 있었고,
이 과정에서 특정 인력이나 팀에 과도하게 종속되지 않는 구조를 설계해두는 것이
얼마나 중요한지 생각할 수 있게 되었죠!!! :)
특히 똑똑한개발자는 자체 SaaS를 만들고
고도화해본 경험이 있어서 그런지
그런 부분에 있어 훨씬 더 서포트를 잘 해주는 외주개발사 같더라고요!
똑똑한개발자 추천드려요! 아래 링크예요 ㅎㅎ
지금 내 정부지원 외주 서비스 점검 포인트
지금 운영 중인 정부지원 외주 서비스가
아래 상황과 비슷하다면 한 번 다시 점검해보시는 것이 좋아요.
소스코드와 서버 계정, 배포 방법을 내부에서 아는 사람이 거의 없다
작은 기능 수정인데도 견적이 크게 나오거나, 구조상 어렵다는 말을 자주 듣는다
운영자가 필요한 데이터를 직접 보지 못해 수기로 엑셀을 정리하는 일이 많다
페이지별 디자인과 컴포넌트가 제각각이라 새로운 화면을 붙일 때마다 부담이 크다
이 중 두세 가지라도 해당된다면,
서비스가 천천히 망해가고 있는지 점검해볼 타이밍일 수 있어요 ㅠㅠ
지금이라도 구조를 정리하고,
장기 운영과 2차 고도화를 전제로 계획을 다시 세우면 충분히 방향을 바꿀 수 있어요!
새로운 외주개발사를 찾거나
기존 파트너와의 협업 방식을 조정하는 것도 좋은 방법이에요.
정부지원사업으로 한 번 만든 서비스가 그때로 끝나는 것이 아니라,
이후에도 계속 성장할 수 있도록 설계해두는 것이 결국 팀의 리스크를 줄이는 길이라고 느껴요.
오늘 글이 정부지원금으로 만든 외주개발 서비스를
다시 들여다보는 계기가 되었으면 좋겠어요.
2년 뒤에도 안 망하는 서비스 구조를 함께 고민해보면서,
다음 선택을 조금 더 안정적으로 가져가실 수 있으시길 바랍니당~ㅎㅎ
끝까지 읽어주셔서 감사합니다!
댓글과 공감도 부탁드려요 :)
