개발기초 SI 프로젝트 인수인계 받으면서 겪었던 문제들 (실무 대응 방법 정리)

SI 제조 시스템 유지보수 프로젝트에 투입되면서 기존 개발자로부터 인수인계를 받은 적이 있습니다. 문서상으로는 인수인계가 다 끝난 것처럼 보였지만, 실제로 운영을 맡아보니 문서에 없던 문제들이 계속 튀어나왔습니다. 이번 글에서는 그 과정에서 겪었던 문제와 대응 방법을 정리해보겠습니다.

상황: 인수인계 문서는 있었지만

인수인계 문서에는 시스템 구조도, 주요 화면 목록, 배포 절차 정도가 정리되어 있었습니다. 겉보기에는 충분해 보였는데, 실제로 업무를 시작하고 나서야 부족한 부분들이 드러났습니다.

문제 1: 배포 절차 문서와 실제 운영 방식이 달랐다

문서에는 [배포 스크립트를 실행하면 자동으로 배포된다]고 되어 있었는데, 실제로는 [특정 순서로 수동 작업이 필요한 단계]가 있었습니다. 이걸 모르고 첫 배포를 진행했다가 [배포가 실패했거나 서비스가 잠시 중단되는] 상황을 겪었습니다.

대응: 전임자에게 다시 연락해서 실제 배포 절차를 하나씩 확인하고, 문서에 없던 수동 단계까지 전부 다시 정리했습니다. 이후 신규 팀원이 오면 같은 문제를 겪지 않도록 체크리스트 형태로 만들어뒀습니다.

문제 2: 코드에 주석 없이 남아있는 예외 처리 로직

특정 기능의 코드를 보다가, 왜 이런 예외 처리가 들어있는지 이유를 알 수 없는 부분들이 여럿 있었습니다. 섣불리 정리했다가 [예상치 못한 장애]가 발생할까 봐 손대기가 조심스러웠습니다.

대응: Git 커밋 로그와 이슈 트래커 히스토리를 뒤져서, 해당 코드가 언제 왜 추가됐는지 최대한 추적했습니다. 완전히 파악되지 않는 부분은 일단 남겨두고, 대신 관련 로그를 추가해서 다음에 문제가 생기면 원인을 더 빨리 찾을 수 있게 해뒀습니다.

문제 3: 담당자만 알고 있던 "암묵적 규칙"

특정 데이터를 처리할 때 [정해진 순서로만 작업해야 하는 규칙]이 있었는데, 이게 어디에도 문서화되어 있지 않았습니다. 몰랐던 채로 작업했다가 [데이터 정합성 문제]가 발생한 적이 있습니다.

대응: 이 사건 이후로, 업무를 진행하면서 알게 되는 암묵적 규칙들을 발견할 때마다 바로바로 위키나 문서에 기록하는 습관을 들였습니다. "나만 아는 것"을 최대한 줄이려고 노력했습니다.

마무리하며

인수인계를 받는 입장에서 느낀 건, **문서의 존재 여부보다 "문서에 없는 걸 얼마나 빨리 찾아내고 채워 넣는가"**가 실제 적응 속도를 좌우한다는 점이었습니다. 이후로는 새 프로젝트에 투입될 때마다 처음 한 달은 의도적으로 질문을 많이 하고, 알게 된 내용을 즉시 기록하는 방식으로 접근하고 있습니다.

비슷하게 인수인계를 앞두고 계신 분들이라면, 문서를 믿기보다 처음 몇 주는 직접 부딪혀보면서 빈틈을 찾아 채워나가시는 걸 추천합니다.