어떻게 기존 프로젝트를 분석하는게 좋을까?
새로운 팀에 합류하거나 기존 프로젝트를 인수인계 받을 때, 개발 당시 최선을 다해 관리 했다고 해도, 처음 부터 파악 해야하는 입장에서 복잡하게 얽힌 시스템과 정제되어 있지 않는 문서와 스파게티 처럼 얽혀있는 소스 코드를 보면 "도대체 어디서부터 시작해야 하지?"라는 막막함을 느껴본 적이 있을 겁니다.
기존 프로젝트를 효과적으로 분석하고 이해하기 위해서는 약간의 체계적인 접근이 필요합니다. 무작정 코드부터 보거나 문서를 읽기 시작하면 오히려 더 혼란스러울 수 있거든요.
거창한 건 아니고 기존 프로젝트를 분석할 때 단계별로 접근할 수 있는 개인적인 방법을 공유하겠습니다. 당연히 이 방법은 만능은 아니고 주어진 프로젝트에 대해 적절하게 첨삭해가며 조정해야합니다.
이 루틴은 적어도 프로젝트의 전체적인 그림을 빠르게 파악하고, 핵심 이슈들을 놓치지 않는 것에 주안 점을 둡니다.
요약하면 다음과 같습니다.
- 일단 어떤 데이터가 쌓여 있는지 눈으로 데이터를 확인하고 가설을 세우고 이해합니다. 현재까지의 프로젝트의 진행 상황을 파악합니다.
- 업무 데이터가 스키마 (또는 규칙)에 맞게 정합성을 유지하며 CRUD가 되는지 확인합니다. 앞으로의 사업 방향과 확장 가능성의 비전을 봅니다.
- 서비스에 필요한 서버들과 스케일 업, 아웃 형태, CI/CD 구조를 봅니다. 비즈니스의 규모와 업무 담당자와 기술 담당자의 이해관계를 예측 가능합니다.
- 프로그램들의 아키텍처, 배치 자동화, 외부 연계 서비스의 구조를 봅니다. 업무 담당자와 개발자가 비즈니스 구조에 얼마나 관심이 있는지 확인 가능합니다.
- 필요한 순간에 확인이 필요한 모든 소스 코드를 파악하도록 도구와 기술을 미리 확인하고 준비합니다. 소스 품질은 개발팀의 개발 역량과 함께 관리 수준을 보여줍니다.
즉 데이터를 먼저 확인하고, 정합성과 확장성을 검토하며, 인프라와 배포 구조를 분석하고, 프로그램 아키텍처와 시스템 연동 구조를 파악하고, 마지막으로 소스 코드 품질과 개발 도구를 점검하는 순서로 진행합니다. ^^
데이터 현황 파악 - 프로젝트의 맥락을 확인합니다
"데이터는 거짓말하지 않는다"
프로젝트 분석의 첫 번째 단계는 쌓여있는 데이터를 직접 눈으로 확인하는 것입니다. 이는 단순히 데이터, 데이터베이스 스키마, 문서 기록을 보는 것이 아니라, 핵심은 실제 운영 데이터의 품질과 패턴을 분석하는 과정입니다.
주요 검토 항목
- 데이터 볼륨과 증가 추세: 일별, 월별 데이터 증가량을 통해 비즈니스 성장세 파악
- 데이터 품질 현황: NULL 값, 중복 데이터, 이상치 존재 여부
- 사용자 행동 패턴: 실제 서비스 이용 현황과 트렌드 분석
- 히스토리 데이터: 과거 데이터를 통한 비즈니스 변화 추이 확인
이 단계에서 중요한 것은 가설 설정입니다. 데이터를 보면서 "왜 이런 패턴이 나타났을까?", "이 데이터가 비즈니스에 어떤 의미일까?", "그래서 무엇을 위한 데이터인가?"라는 질문을 끊임없이 던져야 합니다. 물어 볼 사람이 주위에 있으면 더욱 좋겠지만, 기본적으로 이러한 가설들은 이후 단계에서 검증의 기준이 됩니다.
데이터 정합성 및 확장성 검토 - 미래를 준비하는 토대
"오늘의 편의는 내일의 기술부채가 될 수 있다"
두 번째 단계에서는 현재 데이터가 정의된 스키마와 비즈니스 규칙에 맞게 관리되고 있는지 확인합니다. 비즈니스 규칙에 맞게 관리 하는것은 향후 사업 확장 시 현재 구조가 얼마나 유연하게 대응할 수 있는지 평가하는 것입니다.
주요 검토 항목
- 스키마 일관성: 테이블 간 관계, 제약조건, 인덱스 설계의 적절성
- CRUD 작업 효율성: 각 데이터 조작 작업의 성능과 안정성
- 비즈니스 규칙 준수: 도메인 로직이 애플리케이션 또는 데이터 계층에서 하드코딩 없이 올바르게 구현되었는지
- 확장성 시나리오: 데이터량 10배, 100배 증가 시 대응 가능성
이 단계에서는 앞으로의 사업 방향과 확장 가능성의 비전 확인이 핵심입니다. 현재 구조가 6개월, 1년 후 지금 보다 많은 양의 비즈니스 처리를 지원할 수 있는지 면밀히 검토해야 합니다. 만약 한계가 예상된다면, 지금부터 대안을 준비해야 합니다.
인프라 및 배포 구조 분석 - 안정성의 기반
"시스템의 안정성은 비즈니스의 신뢰성이다"
세 번째 단계에서는 서비스를 지탱하는 인프라와 배포 프로세스를 종합적으로 점검합니다. 이는 단순한 기술적 검토를 넘어서, 조직의 성숙도와 협업 문화를 파악하는 과정이기도 합니다.
주요 검토 항목
- 서버 구성과 역할: 웹서버, 애플리케이션 서버, 데이터베이스 서버의 분리와 역할 분담
- 스케일링 전략: 수직 확장(Scale Up) vs 수평 확장(Scale Out) 방식의 적절성
- CI/CD 파이프라인: 환경설정 관리 방법, 코드 통합부터 배포까지의 자동화 수준
- 모니터링 체계: 장애 감지, 성능 모니터링, 알림 시스템의 완비 여부
이 과정에서 이해관계자 매핑이 중요합니다. 비즈니스 담당자가 기술적 제약사항을 얼마나 이해하고 있는지, 기술 담당자가 비즈니스 요구사항을 얼마나 파악하고 있는지 확인해야 합니다. 양쪽의 이해와 커뮤니케이션 수준이 프로젝트 역량의 핵심입니다.
아키텍처 및 시스템 연동 구조 파악 - 복잡성 관리
"좋은 아키텍처는 복잡함을 단순하게 만든다."
네 번째 단계에서는 전체 시스템의 아키텍처와 외부 시스템과의 연동 구조를 분석합니다. 이는 시스템의 복잡성을 이해하고, 변경 시 영향도를 예측하는 데 필수적입니다.
주요 검토 항목
- 시스템 아키텍처 패턴: MVC, 마이크로서비스, 이벤트 드리븐 등 적용된 패턴의 적절성
- 배치 작업 자동화: 정기 작업, 데이터 처리 파이프라인의 안정성과 효율성
- 외부 연계 서비스: API 연동, 데이터 동기화, 써드파티 서비스 의존성 관리
- 장애 대응 메커니즘: Circuit Breaker, Retry Logic, Fallback 전략의 구현 여부
여기서 중요한 것은 업무 담당자와 개발자가 비즈니스 구조에 얼마나 관심이 있는지 파악해야 합니다. 이는 향후 기존 기능 유지보수와 추가 기능 작업의 난이도를 예측할 수 있습니다.
소스 코드 품질 및 개발 도구 점검 - 지속가능성의 척도
"소스 품질은 개발팀의 개발 역량과 함께 관리 수준을 보여줍니다"
필요한 순간에 확인이 필요한 모든 소스 코드를 파악하도록 도구와 기술을 미리 확인하고 준비합니다. 이는 프로젝트의 지속가능성과 팀의 개발 역량을 가장 직접적으로 보여주는 지표입니다.
주요 검토 항목
- 코드 품질 메트릭: 복잡도, 중복도, 테스트 커버리지, 기술부채 수준
- 개발 도구 및 환경: IDE 설정, 정적 분석 도구, 코드 리뷰 프로세스
- 문서화 수준: API 문서, 개발 가이드, 아키텍처 문서의 완성도
- 버전 관리 및 브랜칭 전략: Git 사용 패턴, 브랜치 관리 규칙
이 단계에서는 개발팀의 성숙도를 정확히 파악할 수 있습니다. 소스 코드의 품질은 단순히 기술적 역량만을 보여주는 것이 아니라, 팀의 협업 문화, 품질에 대한 의식, 장기적 사고 등을 종합적으로 반영합니다.
기존 프로젝트를 분석한다는 건
첫 술에 배부를 수 는 없겠죠. 기존 프로젝트를 분석하는 것은 단순히 코드를 읽고 문서를 검토하는 것을 넘어, 프로젝트의 맥락과 구조를 이해하는 과정입니다.
기존 프로젝트를 분석하기 위한 이러한 접근의 가장 큰 장점은 리스크 예측이 가능해진다는 것입니다. "이 부분을 수정하면 어디에 영향을 줄까?", "새로운 기능을 추가할 때 어떤 제약사항이 있을까?"와 같은 질문을 통해
기존 팀원들과 대화할 때 구체적이고 맥락을 이해한 질문을 할 수 있고, 개선 제안이나 새로운 아이디어도 더 설득력 있게 전달할 수 있습니다.
무엇보다 중요한 것은 이런 분석 능력은 경험을 할 때 마다 개선 된다는 점입니다. 경험이 쌓이면 여기에서 제시한 방법 말고도 자신만의 루틴이나 방법 또는 직관이 생기는 데, 앞으로 어려운 프로젝트를 만나더라도 일단 적응하고 활용할 수 있는 무기가 될 것입니다.