이 상황!

소스는 있습니다.

문서도 있습니다.

그런데 빌드가 안 됩니다.

레거시 시스템을 넘겨받을 때 가장 흔하게 만나는 상황입니다. 그리고 여기서 대부분의 회사가 손을 뗍니다.

견적을 낼 수가 없거든요. 얼마나 걸릴지 모르니까요.

이 글은 그 상태에서 뭘 먼저 확인하는지를 정리한 것입니다.

먼저: 빌드 실패는 원인이 몇 가지로 정해져 있습니다

무한한 가능성이 있는 것처럼 보이지만 실제로는 아닙니다. 순서대로 좁혀 가면 됩니다.

① 의존성을 못 받는다 ← 가장 흔함

② 빌드 도구 버전이 안 맞는다

③ JDK 버전이 안 맞는다

④ 소스 자체가 불완전하다

⑤ 빌드는 되는데 안 뜬다

①에서 ⑤로 갈수록 심각합니다. 그리고 ④부터는 인계가 잘못된 겁니다.

① 의존성을 못 받는 경우

가장 많은 케이스입니다. 원인은 대체로 셋 중 하나입니다.

사내 저장소가 닫혔다 pom.xml이나 빌드 스크립트에 사내 Nexus 주소가 박혀 있는데, 그 서버가 이미 없는 경우입니다. 만든 회사가 없어졌으면 당연히 그 저장소도 없습니다.

로컬 jar가 빠졌다 저장소에 없어서 lib 폴더에 직접 넣어 쓰던 jar가 있습니다. 소스만 압축해서 넘기면 이게 빠집니다.

버전이 저장소에서 내려갔다 공개 저장소에 있던 버전이라도 시간이 지나면 사라지기도 합니다.

확인할 것은 하나입니다. "받아야 하는 의존성 목록"과 "실제로 받아진 것"의 차이입니다. 그 차이가 몇 개이고, 각각을 어디서 구할 수 있는지가 곧 작업량입니다.

② 빌드 도구 버전

오래된 프로젝트는 그 시절 빌드 도구를 전제로 쓰여 있습니다. 지금 최신 버전으로 돌리면 문법이 안 맞거나 플러그인이 안 붙습니다.

최신 도구로 억지로 맞추려 하지 않는 편이 낫습니다. 그 시절 버전을 그대로 구해서 먼저 빌드를 성공시킨 다음, 필요하면 그때 올립니다.

순서가 중요합니다.

잘못된 순서 최신 도구로 맞추기 → 빌드 성공 → 배포

맞는 순서 원래 버전으로 빌드 성공 → 배포 확인 → 그다음에 올릴지 판단

되는 상태를 먼저 만들어야 뭘 바꿔도 비교가 됩니다.

③ JDK 버전

소스 레벨과 실행 JDK가 안 맞으면 컴파일부터 막힙니다. 빌드 설정에 적힌 소스/타깃 레벨을 먼저 보고, 그에 맞는 JDK로 돌립니다.

여기서도 같습니다. 일단 원래 버전으로 되게 만든 뒤에 올릴지를 판단합니다.

④ 소스가 불완전한 경우

이건 앞의 셋과 성격이 다릅니다. 기술 문제가 아니라 인계가 덜 된 것입니다.

설정 파일이 통째로 없음 (서버에만 있었던 경우)

특정 모듈이 빠짐

DB 스키마나 초기 데이터가 없음

형상관리 이력이 없고 최종 스냅샷만 있음

이 경우엔 코드를 붙잡고 있어봐야 답이 안 나옵니다. 빠진 게 뭔지 목록을 만들어서, 받을 수 있는 곳을 찾는 게 먼저입니다. 이전 담당자, 운영 서버, 백업 매체 순으로요.

[진도님 확인 필요] 실제로 빠진 것을 어디서 찾아냈던 경험이 있다면 여기에. 없으면 이 블록 삭제.

⑤ 빌드는 되는데 안 뜨는 경우

컴파일은 통과했는데 기동이 안 되는 상황입니다. 대체로 환경 의존입니다.

DB 접속 정보가 없거나 그 DB가 이미 없음

외부 연계 대상이 응답하지 않아 기동 중 멈춤

특정 경로(파일 업로드 디렉터리 등)가 없어서 실패

여기서 확인할 것은 "연계가 다 끊긴 상태에서도 뜨는가"입니다. 안 뜬다면, 개발 환경을 만들 때마다 외부 시스템이 필요하다는 뜻입니다. 그건 그것대로 손봐야 할 문제입니다.

그래서 얼마나 걸리나

정직하게 말하면 ①~③은 예측 가능하고, ④는 예측이 어렵습니다.

①~③은 원인이 유한하고 확인 순서가 정해져 있어서, 며칠 안에 되든 안 되든 판가름이 납니다. ④는 빠진 게 뭔지, 그게 어딘가에 남아 있는지에 따라 완전히 달라집니다.

그래서 저희는 이 종류의 일에 처음부터 총액을 부르지 않습니다. 먼저 상태를 확인하고, 어디까지 되살릴 수 있는지 판단한 다음에 범위를 정합니다. 안 되는 걸 된다고 하고 시작하는 게 서로에게 가장 나쁩니다.