M&A로 서비스를 인수받았거나, 담당 개발자가 퇴사하면서 서비스를 넘겨받는 경우가 있습니다. 기대를 안고 코드를 열어보면 — 주석은 없고, 변수명은 a, b, c이고, 같은 로직이 여러 군데에 복붙되어 있고, 어디를 고치면 다른 곳이 터집니다.

이 상황에서 무엇을 할 수 있는지 정리합니다.

프로덕트 메이커는 외주 개발을 하면서 수많은 사람들의 코드를 봐왔습니다. 오픈소스 코드, 대기업 내부 코드, 중소 개발사 코드, 프리랜서가 혼자 만든 코드, 주니어가 급하게 찍어낸 코드, CTO급 시니어가 설계한 코드 — 정말 다양합니다. 그래서 코드를 열었을 때 "이건 누가, 어떤 상황에서, 어떤 수준으로 만들었구나"가 빠르게 파악됩니다. 엉망인 코드를 보고 당황하기보다, 현실적으로 어디서부터 손대야 하는지를 판단하는 데 익숙합니다.

왜 이런 상태가 되는가

코드가 엉망인 데에는 대부분 이유가 있습니다.

• 급하게 만들어서: 런칭 기한에 쫓겨 구조를 잡을 시간 없이 개발
• 한 사람이 혼자 만들어서: 코드 리뷰 없이 자기 방식으로만 작성
• 인수인계 없이 사람이 바뀌어서: 이전 개발자의 의도를 모른 채 위에 덧붙임
• 기획이 계속 바뀌어서: 원래 구조에 맞지 않는 기능을 억지로 끼워넣음

누군가의 잘못이라기보다, 시간과 상황이 만든 결과입니다. 중요한 건 지금 어떻게 할 것인가입니다.

선택지 3가지

1. 그대로 운영한다

코드가 엉망이어도, 서비스가 동작하고 있다면 당장 건드리지 않는 것도 선택입니다.

• 장점: 비용 제로, 당장의 리스크 없음
• 단점: 새 기능 추가 어려움, 장애 발생 시 원인 파악 어려움, 시간이 갈수록 상황 악화

수익이 나고 있고, 당분간 기능 변경이 없다면 합리적인 선택일 수 있습니다. 다만 이건 "해결"이 아니라 "보류"입니다.

2. 부분 리팩토링

전체를 뜯어고치지 않고, 가장 문제가 심한 부분만 개선합니다.

• 장점: 비용 절감, 기존 서비스 운영 유지, 점진적 개선
• 단점: 근본 문제는 남아있음, 리팩토링 범위 관리가 어려움

핵심 비즈니스 로직이 있는 부분, 장애가 자주 발생하는 부분부터 우선적으로 정리합니다. 한 번에 다 고치려 하면 실패합니다.

3. 리빌드

기존 코드를 버리고 처음부터 새로 만듭니다.

• 장점: 깨끗한 구조, 최신 기술 스택, 장기적으로 유지보수 용이
• 단점: 비용과 시간이 큼, 기존 데이터 마이그레이션 필요, 리빌드 기간 동안 기존 서비스도 운영해야 함

코드를 아무도 이해할 수 없고, 기술 스택이 수명을 다했고, 비즈니스 방향도 바뀌었다면 리빌드가 맞습니다.

코드 진단, 무엇을 먼저 봐야 하는가

인수받은 코드의 상태를 파악하려면, 순서가 있습니다.

1단계: 동작 여부 확인

• 빌드가 되는가? 서버가 뜨는가?
• 로컬 환경에서 실행할 수 있는가?
• 환경 변수, 외부 서비스 키가 정리되어 있는가?

빌드조차 안 되면, 그 자체로 심각한 상태입니다.

2단계: 구조 파악

• 프론트엔드와 백엔드가 분리되어 있는가?
• DB 구조가 정리되어 있는가? (ERD나 마이그레이션 파일 존재 여부)
• 외부 서비스(결제, SMS, 스토리지 등) 연동이 몇 개인가?

3단계: 위험 요소 식별

• 보안 취약점: 비밀번호 평문 저장, SQL 인젝션 가능 여부
• 데이터 유실 가능성: 백업 정책, 트랜잭션 처리 여부
• 장애 대응: 에러 로깅, 모니터링이 되어 있는가

이 3단계를 거치면, "그대로 운영 / 부분 리팩토링 / 리빌드" 중 어떤 선택이 현실적인지 판단할 수 있습니다.

혼자 판단하기 어렵다면

인수받은 코드의 상태를 비개발자가 판단하기는 어렵습니다. 내부에 개발자가 있어도, 자기가 작성하지 않은 코드를 객관적으로 진단하는 것은 다른 영역의 능력입니다.

프로덕트 메이커에 코드 진단을 의뢰하시면, 코드 상태를 파악하고 현실적인 방향을 안내드립니다. "다 새로 만드세요"가 아니라, 지금 상태에서 가장 효율적인 선택지가 무엇인지를 함께 정리합니다.

*인수받은 서비스의 코드 상태가 걱정되신다면, 프로젝트 상담을 통해 코드 진단을 의뢰해 주세요.*