Blog·인사이트

기존 서비스를 인수받았는데 코드가 엉망이다

···5분 읽기
요약

오픈소스부터 주니어 코드, 시니어 설계까지 다양한 코드를 본 경험에서 보면 패턴이 있습니다. 살릴 부분과 새로 만들 부분을 진단하는 것이 출발이고, 무작정 다시 만드는 것이 답은 아닙니다.

이전 외주 개발사가 작업하던 서비스를 넘겨받거나, 사내에서 담당하던 개발자가 퇴사하면서 코드를 떠안는 경우가 있습니다. 가장 흔한 두 가지 상황입니다. 기대를 안고 코드를 열어보면 — 주석은 없고, 변수명은 a, b, c이고, 같은 로직이 여러 군데에 복붙되어 있고, 어디를 고치면 다른 곳이 터집니다.

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

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

왜 이런 상태가 되는가

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

  • 급하게 만들어서: 런칭 기한에 쫓겨 구조를 잡을 시간 없이 개발
  • 문서 없이 한 사람 머릿속에만 있어서: 그 사람만 아는 규칙과 맥락이 코드 곳곳에 그대로 남음
  • 인수인계 없이 사람이 바뀌어서: 이전 개발자의 의도를 모른 채 위에 덧붙임
  • 기획이 계속 바뀌어서: 원래 구조에 맞지 않는 기능을 억지로 끼워넣음

누군가의 잘못이라기보다, 시간과 상황이 만든 결과입니다.

한 가지 짚어둘 게 있습니다. '혼자 만든 것' 자체가 문제는 아닙니다. 실력 있는 한 명이 혼자 깔끔하게 만든 코드도 많고, 오히려 여러 명이 손대다 일관성이 깨진 코드보다 나은 경우도 흔합니다. 핵심은 혼자냐 여럿이냐가 아니라, 다음 사람이 이어받을 수 있게 문서와 맥락이 남아 있느냐입니다. 같은 한 사람이 만들어도, 인수인계를 전제하고 정리해 둔 코드와 자기 머릿속에만 두고 떠난 코드는 완전히 다릅니다. 중요한 건 지금 어떻게 할 것인가입니다.

선택지 3가지

1. 그대로 운영한다

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

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

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

2. 부분 리팩토링

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

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

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

3. 리빌드

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

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

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

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

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

1단계: 동작 여부 확인

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

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

2단계: 구조 파악

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

3단계: 위험 요소 식별

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

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

혼자 판단하기 어렵다면

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

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

우리가 실제로 인수받아 본 경험

프로덕트 메이커는 한 회사의 서비스를 통째로 인수받아 운영으로 전환한 적이 있습니다. 마이크로서비스 아키텍처(MSA)로 구성된 서비스라 소스코드가 9개의 저장소로 분리돼 있었고, 저장소마다 코드 상태가 천차만별이었습니다. 어떤 건 문서도 주석도 없이 빌드부터 막혔고, 어떤 건 구조가 깔끔해서 그대로 이어받아 기능을 얹을 수 있었습니다. 그때도 가장 먼저 한 일은 전부 다시 만드는 게 아니라, 위에서 적은 순서대로 저장소를 하나씩 진단해 "살릴 것과 다시 만들 것"을 나누는 작업이었습니다.

여기서 솔직히 짚을 게 있습니다. 대부분의 개발자와 개발사는 남이 짠 코드를 일단 안 좋게 봅니다. 다른 사람의 소스코드를 높게 평가하는 경우는 극히 드뭅니다 — 거의 개발자의 본능에 가까운 성향입니다. 그래서 인수 프로젝트를 보면 반사적으로 "이건 못 씁니다, 다시 만들죠"가 나옵니다. 다시 만들면 자기에게 익숙한 구조로 깔 수 있고, 책임 범위도 깔끔해지니까요.

저희는 그렇게 하지 않습니다. 무작정 리빌드부터 외치는 것이 클라이언트 입장에서는 가장 비싼 선택인 경우가 많기 때문입니다. 동작하는 코드에는 그동안 쌓인 예외 처리와 운영 노하우가 박혀 있어서, 새로 만들면 그 디테일을 처음부터 다시 다 겪어야 합니다. 엉망으로 보여도 일단 정확히 진단하고, 살릴 수 있는 것은 살리는 편이 시간과 비용을 모두 아끼는 길입니다. "다시 만들자"는 개발사가 편한 답이고, "살릴 건 살리자"는 클라이언트를 위한 답입니다.

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


인수인계,레거시,코드품질,기술부채
다른 포스팅
Blog·인사이트

기존 서비스를 인수받았는데 코드가 엉망이다

···5분 읽기

이전 외주 개발사가 작업하던 서비스를 넘겨받거나, 사내에서 담당하던 개발자가 퇴사하면서 코드를 떠안는 경우가 있습니다. 가장 흔한 두 가지 상황입니다. 기대를 안고 코드를 열어보면 — 주석은 없고, 변수명은 a, b, c이고, 같은 로직이 여러 군데에 복붙되어 있고, 어디를 고치면 다른 곳이 터집니다.

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

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

왜 이런 상태가 되는가

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

  • 급하게 만들어서: 런칭 기한에 쫓겨 구조를 잡을 시간 없이 개발
  • 문서 없이 한 사람 머릿속에만 있어서: 그 사람만 아는 규칙과 맥락이 코드 곳곳에 그대로 남음
  • 인수인계 없이 사람이 바뀌어서: 이전 개발자의 의도를 모른 채 위에 덧붙임
  • 기획이 계속 바뀌어서: 원래 구조에 맞지 않는 기능을 억지로 끼워넣음

누군가의 잘못이라기보다, 시간과 상황이 만든 결과입니다.

한 가지 짚어둘 게 있습니다. '혼자 만든 것' 자체가 문제는 아닙니다. 실력 있는 한 명이 혼자 깔끔하게 만든 코드도 많고, 오히려 여러 명이 손대다 일관성이 깨진 코드보다 나은 경우도 흔합니다. 핵심은 혼자냐 여럿이냐가 아니라, 다음 사람이 이어받을 수 있게 문서와 맥락이 남아 있느냐입니다. 같은 한 사람이 만들어도, 인수인계를 전제하고 정리해 둔 코드와 자기 머릿속에만 두고 떠난 코드는 완전히 다릅니다. 중요한 건 지금 어떻게 할 것인가입니다.

선택지 3가지

1. 그대로 운영한다

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

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

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

2. 부분 리팩토링

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

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

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

3. 리빌드

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

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

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

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

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

1단계: 동작 여부 확인

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

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

2단계: 구조 파악

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

3단계: 위험 요소 식별

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

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

혼자 판단하기 어렵다면

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

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

우리가 실제로 인수받아 본 경험

프로덕트 메이커는 한 회사의 서비스를 통째로 인수받아 운영으로 전환한 적이 있습니다. 마이크로서비스 아키텍처(MSA)로 구성된 서비스라 소스코드가 9개의 저장소로 분리돼 있었고, 저장소마다 코드 상태가 천차만별이었습니다. 어떤 건 문서도 주석도 없이 빌드부터 막혔고, 어떤 건 구조가 깔끔해서 그대로 이어받아 기능을 얹을 수 있었습니다. 그때도 가장 먼저 한 일은 전부 다시 만드는 게 아니라, 위에서 적은 순서대로 저장소를 하나씩 진단해 "살릴 것과 다시 만들 것"을 나누는 작업이었습니다.

여기서 솔직히 짚을 게 있습니다. 대부분의 개발자와 개발사는 남이 짠 코드를 일단 안 좋게 봅니다. 다른 사람의 소스코드를 높게 평가하는 경우는 극히 드뭅니다 — 거의 개발자의 본능에 가까운 성향입니다. 그래서 인수 프로젝트를 보면 반사적으로 "이건 못 씁니다, 다시 만들죠"가 나옵니다. 다시 만들면 자기에게 익숙한 구조로 깔 수 있고, 책임 범위도 깔끔해지니까요.

저희는 그렇게 하지 않습니다. 무작정 리빌드부터 외치는 것이 클라이언트 입장에서는 가장 비싼 선택인 경우가 많기 때문입니다. 동작하는 코드에는 그동안 쌓인 예외 처리와 운영 노하우가 박혀 있어서, 새로 만들면 그 디테일을 처음부터 다시 다 겪어야 합니다. 엉망으로 보여도 일단 정확히 진단하고, 살릴 수 있는 것은 살리는 편이 시간과 비용을 모두 아끼는 길입니다. "다시 만들자"는 개발사가 편한 답이고, "살릴 건 살리자"는 클라이언트를 위한 답입니다.

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


인수인계,레거시,코드품질,기술부채
다른 포스팅
WebGL프로젝트 상담