다른 개발자가 만든 웹서비스를 이어서 개발할 수 있을까?

기존 개발자나 개발 업체가 만든 웹서비스를 다른 개발자가 이어서 수정하거나 고도화해야 하는 경우가 있습니다.

• 기존 개발자와 연락이 되지 않음
• 유지보수 대응이 느림
• 새로운 기능을 추가하기 어려움
• 내부 개발자를 채용함
• 제작 업체를 변경함
• 서비스 구조를 개선하고 싶음
• 투자나 사업 확장으로 개발 범위가 커짐

다른 개발자가 만든 서비스도 이어서 개발할 수 있습니다.

하지만 소스코드가 있다는 이유만으로 바로 기능을 추가할 수 있는 것은 아닙니다.

새 개발자는 먼저 다음을 확인해야 합니다.

• 코드가 실행되는가?
• 운영 중인 버전과 같은가?
• 서버에 접근할 수 있는가?
• 데이터 구조를 이해할 수 있는가?
• 외부 API와 계정을 확보했는가?
• 보안과 기술 문제가 없는가?

따라서 기존 웹서비스를 이어서 개발하는 프로젝트는 보통 인수인계 → 기술 진단 → 범위 산정 → 수정·개발의 순서로 진행합니다.

소스코드만 있으면 되는 것은 아닙니다

기존 서비스를 이어서 개발하려면 여러 자료가 필요할 수 있습니다.

1. 소스코드

• 프론트엔드
• 백엔드
• 관리자 페이지
• 배치와 자동화
• 인프라 설정
• 데이터베이스 마이그레이션

Git 저장소가 있다면 전체 이력과 브랜치를 확인하는 것이 좋습니다.

압축 파일만 있다면 실제 최신 버전인지 확인해야 합니다.

2. 데이터베이스

• 데이터베이스 종류
• 테이블 구조
• 접속 정보
• 백업 파일
• 마이그레이션 이력
• 개인정보 포함 여부

회원과 주문 등 운영 데이터가 있다면 안전하게 백업한 뒤 작업해야 합니다.

3. 서버와 배포 환경

• 클라우드 계정
• 서버 접속
• 도메인
• SSL
• 배포 방법
• 환경변수
• 로그
• 백업
• 모니터링

개발자의 개인 계정으로 서버가 만들어져 있다면 의뢰사 계정으로 이전할 필요가 있을 수 있습니다.

4. 외부 서비스

• 결제
• 이메일
• 알림톡
• 소셜 로그인
• 지도
• AI API
• 스토리지
• CRM
• ERP
• 공공 데이터

각 서비스의 계정과 API 키, 결제 정보, 허용 도메인을 확인해야 합니다.

5. 디자인과 기획 자료

• Figma
• 화면 설계
• 기능 명세
• 요구사항
• 사용자 흐름
• 운영 정책
• 기존 수정 요청

자료가 없으면 새 개발자가 화면과 코드를 직접 분석해야 하므로 시간이 더 필요할 수 있습니다.

새 개발자가 먼저 기술 진단을 하는 이유

기존 서비스의 상태를 확인하지 않고 바로 고정 견적을 제시하기는 어렵습니다.

같은 기능 추가라도 코드 상태에 따라 작업량이 크게 달라질 수 있습니다.

비교적 상태가 좋은 경우

• Git 저장소가 있음
• 최신 코드와 운영 버전이 같음
• 실행 방법이 정리됨
• 코드 구조가 일관됨
• 데이터베이스 마이그레이션이 있음
• 외부 API 문서가 있음
• 테스트 환경이 있음

위험이 큰 경우

• 최신 소스를 알 수 없음
• 서버에서만 코드가 작동함
• 환경변수가 없음
• 빌드가 실패함
• 코드가 한 파일에 몰려 있음
• 데이터베이스 구조 문서가 없음
• 운영 서버에서 직접 수정함
• 외부 계정을 찾을 수 없음
• 사용하지 않는 코드가 많음
• 보안 취약점이 있음

진단을 통해 일부 수정으로 가능한지, 구조 개선이 필요한지, 전체 재개발이 나은지 판단합니다.

기술 진단에서 확인할 항목

1. 실행 가능 여부

• 로컬 개발 환경에서 실행되는가?
• 필요한 라이브러리를 설치할 수 있는가?
• 빌드가 가능한가?
• 운영 환경과 동일한 설정을 만들 수 있는가?
• 누락된 파일이 없는가?

2. 코드 구조

• 프론트엔드와 백엔드가 구분되는가?
• 기능별로 코드가 정리되어 있는가?
• 중복 코드가 많은가?
• 특정 개발자만 이해할 수 있는 구조인가?
• 주석과 문서가 있는가?
• 사용 중인 라이브러리가 유지 가능한가?

3. 데이터베이스

• 데이터 관계가 일관적인가?
• 중복 데이터가 있는가?
• 삭제 정책이 있는가?
• 개인정보가 안전하게 저장되는가?
• 백업과 복구가 가능한가?
• 변경 이력이 관리되는가?

4. 보안

• 비밀번호가 안전하게 저장되는가?
• API 키가 소스에 노출되어 있지 않은가?
• 관리자 권한 검사가 있는가?
• 개인정보 접근이 제한되는가?
• 사용하지 않는 계정이 남아 있는가?
• 오래된 라이브러리가 있는가?

5. 서버 운영

• 로그를 확인할 수 있는가?
• 장애 발생 시 원인을 찾을 수 있는가?
• 백업이 있는가?
• SSL이 자동 갱신되는가?
• 서버 비용이 적절한가?
• 배포 과정이 안전한가?

기존 코드를 유지하는 것이 좋은 경우

다음 조건이라면 기존 구조를 활용해 이어서 개발할 수 있습니다.

• 서비스가 안정적으로 운영 중임
• 주요 기능이 정상 작동함
• 코드 구조를 이해할 수 있음
• 최신 기술이 아니어도 유지 가능함
• 데이터 이전 위험이 큼
• 추가할 기능이 기존 구조와 잘 맞음
• 재개발 예산과 시간이 부족함

완벽한 코드가 아니더라도 사업 목적에 맞게 안정적으로 수정할 수 있다면 전체 재개발은 불필요할 수 있습니다.

일부 구조 개선이 필요한 경우

기능 추가와 함께 다음 영역만 개선할 수 있습니다.

• 로그인과 권한
• 결제 처리
• 관리자 페이지
• 데이터 조회 성능
• 파일 저장
• 배포 환경
• 로그와 모니터링
• 오래된 라이브러리

이를 점진적 리팩터링이라고 볼 수 있습니다.

서비스를 중단하지 않고 필요한 부분부터 개선할 수 있다는 장점이 있습니다.

전체 재개발을 고려할 수 있는 경우

다음 문제가 여러 개 겹친다면 전체 재개발을 검토할 수 있습니다.

• 소스코드를 확보하지 못함
• 실행과 빌드가 불가능함
• 오래된 기술로 유지가 어려움
• 보안 문제가 큼
• 데이터 구조를 크게 변경해야 함
• 사용자 유형과 권한이 완전히 달라짐
• 서비스 목적 자체가 바뀜
• 오류가 반복됨
• 기능 추가마다 전체가 깨짐
• 운영 비용이 지나치게 높음

다만 재개발은 기존 기능과 데이터를 모두 다시 구현해야 하므로 신중하게 판단해야 합니다.

기존 서비스에 새 기능을 추가할 때 생기는 문제

예를 들어 기존 서비스에 기업 회원 기능을 추가한다고 가정해 보겠습니다.

현재는 모든 데이터가 개인 회원 기준으로 저장되어 있을 수 있습니다.

기업 구조를 추가하면 다음 영역이 바뀔 수 있습니다.

• 회원가입
• 로그인
• 회사 정보
• 직원 초대
• 권한
• 결제
• 데이터 조회
• 관리자
• 통계

화면 몇 개를 추가하는 문제가 아니라 전체 데이터 구조와 권한에 영향을 줄 수 있습니다.

따라서 기존 코드 진단 없이 기능 이름만으로 정확한 견적을 내기 어렵습니다.

기존 개발자에게 받아야 할 자료

1. 최신 소스코드
2. Git 저장소와 이력
3. 서버 계정
4. 데이터베이스 접속 또는 백업
5. 환경변수
6. 배포 방법
7. 도메인과 DNS
8. 외부 API 목록
9. 결제 계정
10. 파일 저장소
11. 관리자 계정
12. 디자인 원본
13. 기능 명세
14. 알려진 오류
15. 남은 작업

새 개발 업체에 전달할 내용

서비스 주소:
서비스 목적:
현재 사용자 수:
현재 주요 기능:
추가하려는 기능:
현재 발생하는 문제:
기존 개발자와 연락 가능 여부:
소스코드 보유 여부:
서버 계정 보유 여부:
데이터베이스 보유 여부:
디자인 원본:
외부 API:
결제 기능:
개인정보 포함 여부:
희망 일정:
운영 중단 가능 시간:

기존 서비스 진단은 유료일 수 있습니다

코드를 내려받고 실행해 구조를 분석하는 작업도 개발자의 시간이 필요합니다.

진단에는 다음 업무가 포함될 수 있습니다.

• 개발 환경 구성
• 빌드와 실행
• 서버 접속
• 데이터베이스 확인
• 핵심 기능 테스트
• 코드 구조 분석
• 보안 문제 확인
• 개선 범위 제안
• 견적 산정

간단한 코드는 상담 단계에서 확인할 수 있지만, 규모가 크거나 문서가 없다면 별도 진단 비용이 발생할 수 있습니다.

운영 중인 서비스를 안전하게 수정하는 방법

1. 전체 백업
2. 별도 개발 환경 구성
3. 운영과 개발 데이터 분리
4. 수정 기능 구현
5. 테스트
6. 배포 전 백업
7. 트래픽이 적은 시간에 배포
8. 배포 후 주요 기능 확인
9. 문제 발생 시 되돌리기
10. 변경 내용 문서화

운영 서버에서 코드를 직접 수정하는 방식은 피하는 것이 좋습니다.

업체 교체 후 바로 고쳐야 할 것

새 업체가 인수한 뒤 다음 항목을 우선 점검할 수 있습니다.

• 회사 명의가 아닌 계정
• 퇴사자와 이전 개발자 권한
• 노출된 API 키
• 백업
• 관리자 계정
• 서버 비용
• SSL
• 오류 로그
• 개인정보 접근
• 결제 웹훅
• 만료 예정 서비스

새 기능보다 운영 안정성을 먼저 확보해야 할 수 있습니다.

다른 개발자가 이어받기 어려운 상황

• 개발자만 아는 수동 작업이 많음
• 코드 없이 관리자 화면만 있음
• 외부 서비스가 개발자 개인 계정임
• 서버 비밀번호를 모름
• 운영 버전과 소스가 다름
• 데이터가 암호화되어 있지만 키가 없음
• 배포 방법이 없음
• 오래된 유료 라이선스에 의존함

이 경우 일부 기능을 포기하거나 새로 개발해야 할 가능성도 있습니다.

마무리

다른 개발자가 만든 웹서비스도 이어서 개발할 수 있습니다.

다만 바로 기능 견적을 내기 전에 다음을 확인해야 합니다.

• 최신 소스가 있는가?
• 실행 가능한가?
• 서버와 데이터에 접근할 수 있는가?
• 외부 서비스 계정을 확보했는가?
• 기존 구조를 유지할 수 있는가?

기존 코드가 있다는 사실보다 다른 개발자가 이해하고 안전하게 수정할 수 있는 상태인지가 중요합니다.