프로젝트 인수인계 시 꼭 기억할 5가지
0. 글을 시작하며
2024년을 시작하면서 입사 후 한 해동안 진행하던 프로젝트를 마무리하고 새로운 프로젝트를 인수인계 받아 진행하게 되었습니다.
이전 프로젝트는 처음부터 프로젝트를 세팅하고 코드를 직접 작성하며 진행한 프로젝트였지만 이번 프로젝트는 지난 1년부터 지금까지 개발과 유지보수 병행하며 실제 운영 중인 서비스를 유지보수하고 추가 개발하는 내용이었습니다.
이전에는 머릿속으로 정리한 논리를 코드로만 잘 작성하면 되었지만 이제는 기존 전임자의 코드를 통해서 핵심 로직을 이해하고, 전체 시스템에 대해 이해하여 서비스에 대한 유지보수와 함께 신규 기능 추가 개발을 통해 서비스를 향상시켜야할 필요가 있었습니다. 즉, 이전에는 나의 방식대로 로직만 잘 작성하여 요구사항을 충족하는 능력만 있으면 되었다면, 이제는 다른 사람이 작성한 코드를 분석하여 이해하고 이를 바탕으로 나의 코드를 기존 시스템의 코드에 녹여내야하는 능력이 필요해졌습니다.
문제는 대부분 이러한 경우 인수인계를 위한 문서가 잘 준비되어 있지 않은 경우가 굉장히 많다는 점입니다. 프로젝트가 어떤 방향으로 진행되어 왔는 지, 중요한 의사결정에는 무엇이 있었는 지, 데이터 흐름이 어떤 식으로 구성되는 지 등 프로젝트를 이해하는 데 대단히 중요한 정보들이 실제로 남아있지 않은 경우가 굉장히 많고, 전달되더라도 구전으로 전달되어 잊혀져 버리는 아쉬운 상황들이 많이 발생 합니다.
저 또한 이러한 문제들과 함께 급히 인수인계를 받았고, 갑자기 들어오는 요청사항이나 이슈를 대응하면서 하면서 많은 어려움을 겪었으며, 이러한 어려움은 지금도 현재 진행형입니다. 그래서 이 과정에서 제가 지금까지 느끼고 배운 점들을 이렇게 글을 통해서 남겨보고자 합니다. 대단한 경험에서 나온 좋은 글은 아니지만 저처럼 갑자기 프로젝트 인수인계를 받아 추가 개발 및 이슈대응을 위해 지금 이 시간에도 모니터 앞에서 다른 사람의 코드를 켜두고 씨름하고 계시는 많은 분들에게 조금이나마 도움이 되었으면 좋겠습니다.
1. 처음부터 프로젝트의 모든 코드를 이해하겠다는 것은 무모한 생각!
저는 인수인계 초기에 다음과 같은 생각을 하였습니다.
최대한 빠른 시간 안에 프로젝트의 모든 코드와 로직을 이해해야겠다.
모든 소스 파일들을 하나하나 열어서 위에서 아래로 라인 하나하나 코드를 보고 정리한다면 이 프로젝트에 대해서 가장 잘 이해할 수 있을 것이라고 생각했었습니다. 물론 작은 단위의 프로젝트라면 이러한 접근 방식이 도움이 될 수도 있습니다. 하지만 실무에서 만나게 되는 대부분의 프로젝트는 그 규모에 차이가 있을 뿐 대부분 복잡하게 구성되어 있습니다. 수십개의 DB 테이블, 다 세기도 어려운 수많은 클래스들, 객체가 사용하는 수많은 필드들을 하나하나 모두 확인하면서 프로젝트를 구성하는 모든 소스들을 분석하는 것은 현실적으로 어려울 뿐더러 많은 시간을 들여서 그렇게 한다고 해도 금방 잊어버리게 되어 의미없는 시간이 될 가능성이 높습니다.
처음에 복잡한 프로젝트의 구조와 다른 사람이 작성한 코드를 이해하지 못하는 자신의 모습을 보면서 자책하는 경우가 생기게 되는 데 그러실 필요가 없습니다. 잘 안되는 게 당연한 겁니다. 물론 우리가 더 좋은 개발자로 성장하기 위해서는 여러 연습과 훈련을 통해서 타인의 코드를 이해하는 데 걸리는 시간을 줄여나갈 필요가 있지만 처음부터 다른 사람이 오랫동안 개발해온 복잡한 프로젝트를 몇 일 만에 모든 소스를 보고 이해하겠다는 것은 대단히 위험한 생각입니다. 저도 처음에 이러한 접근 방식을 시도하다가 많은 시간과 체력을 사용하면서도 정작 프로젝트에 대해서 충분히 이해하지 못하는 어려움을 겪었습니다. 저는 이 문제를 두고 회사의 사수, 학교 선배 등 업계에 저보다 훨씬 오래 일하신 분들에게 조언을 구하였고, 많고 다양한 답변 중에서 이 답변을 가장 공통적으로 많이 받았습니다.
처음부터 프로젝트의 모든 것을 이해하겠다는 생각은 무모하고, 포기하는 것이 좋습니다.
물론 자신이 맡게 된 프로젝트의 모든 코드를 완벽히 이해해서 빠르게 기여하고 싶은 마음은 좋은 마음이고 이해하지만, 프로젝트에 대해 차근차근 알아가며 큰 그림을 먼저 이해해야하는 초기 단계에서는 이런 조급한 마음은 오히려 독이 될 수 있습니다.
2. 텍스트 중심이 아니라 동작 중심으로 큰 그림부터 분석하자
그렇다면 어떻게 프로젝트를 분석하고 이해해야할까요? 제가 두 번째로 가장 많이 받은 조언은 "텍스트 중심이 아니라 동작 중심으로 프로젝트의 큰 그림부터 분석하자" 라는 내용이었습니다. 이게 무슨 내용인지 조금 이해하기 어려우 실 수 있습니다. 여기서 주목할 키워드는 다음 2가지 인데 각 키워드를 이렇게 해석해서 읽어보시면 이해가 더 쉬워집니다.
- 텍스트 : 코드
- 동작 : 데이터, 실행 흐름
즉, 코드 중심으로 프로젝트를 이해하려고 하는 것보다 애플리케이션이 동작하면서 지속적으로 발생하는 데이터와 실행의 흐름을 따라가면서 프로젝트의 전체적인 구조를 먼저 이해하는 것이 가장 중요합니다. 나무만 보지 말고 숲을 보라는 조언을 많이 들어보셨을 겁니다. 프로젝트에 대한 전체적인 구조와 대략적인 동작방식을 이해하는 것이 초기 단계에서는 가장 중요하기 때문에 나무가 아닌 숲을 보자는 내용은 이 상황에도 동일하게 적용할 수 있습니다.
그래서 저 같은 경우 PPT를 사용해서 프로젝트의 전체적인 구조도를 그려보는 방식으로 접근했습니다. 단 여기서의 구조는 클래스 수준에서의 세부적인 통신이 아니라 애플리케이션 간의 통신, 애플리케이션과 DB 간의 통신, 그 외 애플리케이션과 다른 노드들 간의 주고받는 주요 데이터 등과 같은 내용을 구조도로 표현하여 사수분에게 확인받는 방식으로 접근하였습니다.
대충 아래와 같은 느낌으로 작성했다고 이해하시면 됩니다. (이는 이해를 돕기 위해 첨부한 예시이며, 실제 업무와는 무관한 이미지 입니다).
프로젝트 전체 구조에 대해서 제가 이해한 내용을 그림으로 표현하니 제가 이해한 내용을 명확하게 표현이 가능했고, 질문을 받으시는 사수분도 비교적 더 빠르고 정확하게 피드백을 주실 수 있었습니다. 물론 자신의 이해를 구조도 형식으로 표현하는 것이 다소 귀찮고 번거로운 작업이 될 수 있지만 이 방식이 주는 장점은 확실하기 때문에 충분히 시간을 투자할 가치가 있다고 생각합니다.
이렇게 프로젝트에 대한 큰 그림을 먼저 그려야 어떤 이슈가 발생하거나 요청사항이 들어왔을 때 어떤 파트에서 문제가 발생했는 지 혹은 어떤 부분에 대한 작업이 필요한 지를 비교적 더 빠르게 파악할 수 있기 때문에 이러한 접근은 반드시 필요합니다. 그렇다고 해서 코드 수준의 분석을 할 필요가 없다는 의미가 절대 아닙니다. 이렇게 큰 그림에 대한 이해를 먼저 잘 해두고 이후 필요한 부분부터 소스 분석을 통해 프로젝트에 대한 이해를 구체화 하자는 것 입니다.
텍스트 중심이 아니라 동작 중심으로 프로젝트를 먼저 이해하고 바라보는 것. 굉장히 중요한 전략입니다.
3. 도메인 지식은 프로젝트를 이해하는 중요한 열쇠가 된다.
대부분의 서비스들은 어떠한 특정 도메인에서 발생하는 문제나 불편함을 개선 및 해결하는 데 목적을 두고 있습니다. 그렇기 때문에 모든 서비스들이 포함하는 핵심 로직들은 해당 서비스와 연관된 도메인 지식을 밀접하게 포함하고 있을 가능성이 굉장히 높습니다. 예를 들어 스포츠를 위한 서비스라면 해당 스포츠의 룰이나 경기일정과 관련된 내용, 주식과 관련된 서비스라면 주식시장 및 거래 규정과 관련된 내용, 특정 공동체를 위한 서비스라면 그 공동체의 특별한 특징(교회, 학교 등)을 반영하게 됩니다.
그렇기 때문에 무작정 해당 서비스와 연관된 도메인에 대한 지식없이 핵심 로직을 바로 코드 수준으로 분석하게 되면 이해하기 어려운 코드들이 생각보다 많습니다. 만약 핵심 로직을 분석하는 과정에 맥락을 이해하기 어려운 로직들이 존재한다면 혹시 관련 도메인 지식에서 내가 놓치고 있는 부분은 없는 지 먼저 확인해보는 것이 이러한 의문점을 해결하는 데 큰 도움을 줄 수 있습니다.
예를 들어 주식과 관련된 서비스 코드에 실시간 거래 및 주가 정보를 연동하는 스케쥴을 09:00에 시작하고 15:30에 중지시키는 로직이 들어있다고 가정해보겠습니다. 그런데 해당 소스를 분석하는 개발자가 국내 주식시장이 09시에 열리고 15시 반에 마감된다는 도메인 지식을 알고 있지 못하다면 실시간 거래 및 주가정보 연동 스케줄이 왜 특정 시간대만 연동되는 것인지 이해할 수 없는 것과 같은 맥락입니다.
그만큼 도메인 지식은 프로젝트, 서비스, 핵심 로직을 이해하는 데 중요한 열쇠가 될 수 있기 때문에 중요합니다.
4. 전임자에게 도움을 구할 수 있는 상황이라면 반드시 구하자.
하지만 앞에서 이야기한 방법들보다도 가장 효과적인 방법은 해당 프로젝트에 대한 개발을 진행해온 전임자에게 직접 질문하고 도움을 요청하는 것입니다. 전임자의 경우 문서에는 포함되어 있지 않은 프로젝트 진행 중에 발생한 중요한 의사결정이나 프로젝트 진행 히스토리를 알고 있을 가능성이 높습니다. 이러한 정보는 우리가 프로젝트를 이해하는 데 굉장히 중요한 역할을 하게 됩니다.
물론 전임자가 퇴사하거나 타 부서로 이동하는 등의 경우는 어쩔 수 없지만 전임자가 같은 팀이나 부서에 있어 충분히 도움을 요청할 수 있는 상황이라면 조금 번거롭고 죄송스러운 마음이 들더라도 적극적으로 도움을 요청하는 것이 좋다고 생각합니다. 이렇게 도움을 요청하는 것이 많이 어렵게 느껴지더라도 눈 한번 딱! 감고 정중하게 요청드려보는 것은 어떨까요? (경험상 대체로 흔쾌히 잘 받아주셨었습니다.)
혼자서 끙끙대면서 오랜시간 투자해도 이해하거나 해결하기 어려운 내용들이 전임자의 설명과 도움 몇 분만으로 해결되는 경우가 많습니다. 그렇다면 잠깐의 불편함을 감수하고 도움을 요청드릴 가치가 충분하지 않을까요? 전임자에게 기존 코드 분석 과정에서 겪는 어려움에 대한 도움을 요청하는 것은 결코 부끄러운 일이 아닙니다. 타인이 오랜 시간 고민해서 작성했을 코드를 잠깐 보고 이해할 수 있다는 것 자체가 쉽지 않은 일입니다.
전임자에게 도움을 구할 수 있는 상황이라면 반드시 구해보는 것이 좋다고 생각합니다.
5. 내가 겪은 시행착오가 반복되지 않도록 부족한 내용은 문서화 해두자.
우리가 맡은 프로젝트를 끝까지 맡을 것이라는 보장은 없습니다. 앞으로 다른 프로젝트에 투입될 수도 있고, 이직을 할 수도 있고 다양한 원인과 변수에 의해서 자신이 열심히 인계받아서 진행하던 프로젝트를 또 다른 사람에게 인수해줘야하는 상황은 언제든 올 수 있습니다. 자신이 과거에 프로젝트에 대한 설명과 문서의 부족으로 고생하면서 현재 프로젝트에 대한 이해를 쌓았다면 새로운 담당자가 프로젝트를 이해하는 데 큰 도움을 줄 수 있도록 별도로 문서를 남겨주는 것은 어떨까요?
테스트 코드나 주석이 문서화를 대신할 수 있다고 하지만 새롭게 해당 프로젝트를 전달받는 사람의 입장에서는 이것이 잘 들어오지 않습니다. 하지만 필요한 내용들을 깔끔하게 정리한 문서를 인수인계 과정에서 함께 준비해서 전달할 수 있다면 이는 후임자에게 굉장히 큰 도움이 될 것입니다. 저는 보통 문서화 과정에서 다음 정보들을 꼭 포함하려고 노력하고 있습니다.
- 빌드 및 실행방법
- 시스템 전체 구조도
- 분석 과정에서 착각하기 쉬운 부분, 주의사항
- 필수 도메인 지식
- 프로젝트 진행 과정에서 있었던 주요 커뮤니케이션이나 의사결정내용
우리가 앞에서 겪은 시행착오를 또 다른 사람이 동일하게 겪도록 만들 필요는 없습니다. 완벽할수는 없지만 평소 프로젝트를 진행하면서 조금씩 기록해두는 내용들이 나중에는 하나의 좋은 문서가 되어 후임자에게 큰 도움을 줄 수 있을 것이라고 생각하고, 이것이 좋은 개발문화를 만들어가는 데 필요한 하나의 좋은 실천사항 중 하나라고 생각합니다.
6. 마치며
앞에서 언급한 5가지 내용을 기억하고 실천한다고 해서 기존 프로젝트를 쉽고 빠르게 분석할 수 있다는 것은 아닙니다. 우리가 대체로 실무에서 인수인계 받게될 프로젝트들을 오랜 기간, 많은 사람들을 거쳐 개발 및 유지보수 되어왔을 가능성이 높기 때문입니다. 물론 여전히 이 과정에서 우리에게 어려움은 존재하겠지만 이 내용들을 기억함으로서 불필요한 시행착오를 줄이는 데 도움이 될 수 있을 것이라 생각되어 이렇게 글로 남겨보게 되었습니다.
저를 포함하여 각자의 환경 속에서 전임자의 코드를 분석하며 프로젝트를 열심히 인수인계 받고 계시는 모든 개발자 분들을 응원하며 이 글을 마치겠습니다.
긴 글 읽어주셔서 감사합니다.
'ETC > 회고' 카테고리의 다른 글
| 단위 테스트가 프로젝트에 가져온 긍정적 효과 (0) | 2024.03.31 |
|---|---|
| 동적 쿼리와의 전쟁... Querydsl을 도입할 수 없었던 이유 (4) | 2024.03.17 |
| 자기개발 미루지 않는 개발자 되기 (1) | 2024.01.21 |