산업은행 프로젝트 회고 - 5개월의 개발을 마치며
2025년 9월 실제 개발 업무가 완료된 후, 시간이 조금 지나서야 객관적으로 돌아볼 수 있게 되었다. 5개월간(4월~9월)의 실제 개발 경험에 대한 냉정한 회고와 성찰을 정리한다.
자세한 감정적 기록은 산은 프로젝트종료회고 (Logbook 볼트로 이동)에 작성해두었지만, 이 문서는 좀 더 기술적이고 객관적인 관점에서의 회고이다.
프로젝트 개요 및 성과
전체 프로젝트 기간: 2025년 4월 2일 ~ 12월 31일 (약 8개월) 실제 개발 기간: 2025년 4월 2일 ~ 9월 30일 (약 5개월) 역할: 경영지원 예산/경비 도메인 개발자 (130개 프로그램 담당) 개발 완료 후: 10월부터는 통합테스트 단계로 전환, 개발팀은 프로젝트에서 철수 주요 성과:
- 레거시 JSP Model 1 → WebSquare5 + AnyFrame 아키텍처 성공적 전환
- 복잡한 금융 예산/경비 업무 로직의 완전한 시스템화
- EAI를 통한 본점-해외지점 간 실시간 데이터 연동 구현
기술적 성장과 학습
1. 금융 도메인 전문성 획득
이 프로젝트의 가장 큰 성과는 금융권 특유의 복잡한 비즈니스 로직을 이해하고 시스템으로 구현할 수 있게 된 것이다.
학습한 핵심 개념들:
- 선급경비(prepaid expense)와 후급경비의 회계 처리 차이
- 발생주의 vs 현금주의 회계 원칙의 시스템 반영
- 4단계 승인 체계의 복잡한 워크플로우 설계
- 부가세 자동 계산 및 회계 전표 자동 생성 로직
- 예산 통제와 집행 현황 실시간 관리 시스템
2. 엔터프라이즈 아키텍처 경험
200명 규모 프로젝트에서 시스템 간 연동의 복잡성을 직접 체험했다.
핵심 경험:
- MCI(Message Channel Interface)를 통한 시스템 간 통신
- EAI(Enterprise Application Integration) 기반 데이터 동기화
- DB-to-DB 실시간 연동을 통한 본점-지점 간 데이터 흐름
- 레거시 시스템과 신규 시스템 간 점진적 마이그레이션 전략
3. 새로운 기술 스택 습득
기존 웹 표준과는 다른 기업용 솔루션들의 특성을 이해했다.
기술적 전환 경험:
- WebSquare5: 웹 표준이 아닌 RIA 솔루션의 DOM 기반 개발 방식 습득
- AnyFrame: 전자정부 표준 프레임워크 기반의 엔터프라이즈 개발 경험
- EIMS: 금융권 전용 인터페이스 시스템 활용 경험
프로젝트 관리 측면에서의 교훈
1. 일정 관리의 현실
이론과 현실의 차이를 체감했다. 개발 일정 관리에서도 기록했듯이, 대규모 프로젝트에서는 예상치 못한 변수들이 계속 발생한다.
주요 도전과제들:
- 추가 인력 투입에도 불구한 지속적인 일정 지연
- 레거시 시스템 분석의 어려움 (문서화 부재, 담당자 부재)
- 업무 도메인 이해 부족으로 인한 잦은 수정
- 시스템 간 인터페이스 조율의 복잡성
2. 커뮤니케이션의 중요성
200명 규모 프로젝트에서는 기술적 역량만큼이나 소통 능력이 중요했다.
배운 점들:
- 다른 도메인 팀과의 인터페이스 협의 과정
- 업무 담당자와의 요구사항 정의 및 검증 과정
- 기술적 제약사항을 비개발자에게 설명하는 능력
개인적 성장과 변화
1. 스트레스 관리와 회복력
개발 일정 관리에서 기록한 극심한 스트레스 상황을 겪으면서 개인적인 한계와 대처 방법을 배웠다.
깨달은 점들:
- 장기적인 프로젝트에서는 페이스 조절이 중요하다
- 모르는 것을 인정하고 도움을 요청하는 것이 더 효율적이다
- 완벽을 추구하기보다는 점진적 개선이 현실적이다
2. 문제 해결 역량 향상
복잡한 시스템 오류를 디버깅하면서 체계적인 문제 해결 능력이 향상되었다.
발전된 역량들:
- 여러 시스템에 걸친 데이터 플로우 추적 능력
- 로그 분석을 통한 근본 원인 파악 능력
- 복잡한 비즈니스 로직의 체계적 분해 능력
아쉬웠던 점들
1. 초기 학습 곡선
WebSquare5와 AnyFrame이라는 생소한 기술 스택으로 인해 초기 생산성이 현저히 떨어졌다. 미리 학습할 수 있었다면 더 효율적이었을 것이다.
2. 문서화 부족
프로젝트 진행 중에는 일정에 쫓겨 충분한 문서화를 하지 못했다. 특히 복잡한 비즈니스 로직에 대한 체계적인 문서화가 부족했다.
3. 테스트 자동화 부재
수동 테스트에 의존하다 보니 회귀 테스트의 부담이 컸다. 초기부터 자동화된 테스트 환경을 구축했다면 더 안정적이었을 것이다.
향후 개발자로서의 방향성
이 프로젝트를 통해 다음과 같은 개발자로서의 방향성을 설정하게 되었다:
1. 도메인 전문성의 중요성
단순한 기술적 역량보다는 특정 도메인에 대한 깊은 이해가 더 중요하다는 것을 깨달았다. 금융권에서의 이 경험을 바탕으로 더 깊은 도메인 전문성을 쌓아나가고 싶다.
2. 엔터프라이즈 아키텍처 역량
대규모 시스템 설계와 시스템 간 통합에 대한 관심이 높아졌다. 앞으로는 단순한 기능 개발을 넘어 전체 시스템 아키텍처를 설계할 수 있는 역량을 기르고 싶다.
3. 프로젝트 관리 역량
기술적 역량과 더불어 프로젝트를 성공적으로 이끌 수 있는 관리 역량의 필요성을 느꼈다. 일정 관리, 리스크 관리, 팀 커뮤니케이션 등의 역량을 더 발전시키고 싶다.
연결노트
프로젝트 관련 상세 기록:
- 산업은행 KINS 프로젝트 개요 - 전체 프로젝트 배경과 기본 정보 (배경)
- 예산경비 업무 분석 - 담당했던 핵심 업무 도메인 분석 (직접 경험)
- 개발 일정 관리 - 프로젝트 진행 중 실제 겪었던 어려움들 (과정)
기술적 학습 내용:
- 시스템 기술 스택 분석 - 레거시에서 현대적 아키텍처로의 전환 분석 (기술 근거)
- 대규모 SI 프로젝트의 MCI 와 EAI 는뭘까 - 엔터프라이즈 아키텍처 이해 (기술 확장)
연관 경험과 확장 학습:
- 레거시 시스템 유지보수에서 문서화 부재는 예상치 못한 복잡성으로 이어진다 - 이전 레거시 시스템 경험과의 비교 (유사성)
- DB 통신 횟수를 줄이는 것이 성능 개선의 핵심이다 - 대용량 데이터 처리 경험과의 연관성 (유사성)
- 개발자의 성장과 스트레스 관리 - 압박 상황에서의 개인적 대처법 연구 (보충)
- 금융권 시스템 개발의 특징 - 금융 도메인의 일반적 특성과 개발 고려사항 (확장)
- 엔터프라이즈 아키텍처 패턴 - MCI/EAI 외 다른 통합 패턴들과의 비교 (확장)
- 프로젝트 관리와 일정 계획 - 대규모 프로젝트 관리 방법론과 현실적 제약 (근거)
- 레거시 시스템 현대화 전략 - 점진적 마이그레이션 접근법에 대한 이론적 배경 (근거)
최종 소감: 5개월간의 집중적인 개발 기간은 개발자로서 가장 힘들면서도 가장 많이 성장한 경험이었다. 공식적으로는 12월까지 프로젝트가 지속되지만, 실제 개발은 9월에 완료되어 프로젝트에서 철수하게 되었다. 이 짧고 강도 높은 기간 동안 기술적 역량뿐만 아니라 도메인 전문성, 프로젝트 관리 역량, 그리고 무엇보다 압박 상황에서의 문제 해결 능력을 키울 수 있었다. 이 경험을 바탕으로 더 나은 개발자, 더 나은 프로젝트 구성원이 되어나가고 싶다.