산업은행 프로젝트 회고 - 5개월의 개발을 마치며
2025년 9월, 실제 개발이 마무리된 후 시간이 조금 지나고 나서야 이 경험을 제대로 들여다볼 수 있었다. 한창 진행 중일 때는 매일 눈앞의 일을 처리하기 바빴고, 끝나고 나서는 긴장이 풀리면서 한동안 아무 생각이 안 났다.
지금 돌이켜보면, 지금까지의 개발 경험 중에서 가장 밀도 있게 성장한 5개월이었다.
감정적인 기록은 Logbook 볼트에 따로 남겨뒀다. 이 문서는 그것보다 기술적이고 객관적인 관점에서의 회고다.
프로젝트 개요
전체 기간: 2025년 4월 2일 ~ 12월 31일 (약 8개월) 실제 개발 기간: 2025년 4월 2일 ~ 9월 30일 (약 5개월) 역할: 경영지원 예산/경비 도메인 개발자, 130개 프로그램 담당
10월부터는 통합테스트 단계로 전환되면서 개발팀은 프로젝트에서 철수했다.
주요 성과:
- 레거시 JSP Model 1 → WebSquare5 + AnyFrame 아키텍처 전환
- 복잡한 금융 예산/경비 업무 로직의 완전한 시스템화
- EAI를 통한 본점-해외지점 간 실시간 데이터 연동 구현
기술적으로 성장한 것들
금융 도메인 이해
이번 프로젝트의 가장 큰 수확은 여기 있었다. 금융권 특유의 복잡한 비즈니스 로직을 이해하고 코드로 구현하는 경험이었다.
선급경비와 후급경비의 회계 처리 차이, 발생주의 vs 현금주의가 시스템에 어떻게 반영되는지, 4단계 승인 체계의 워크플로우, 부가세 자동 계산과 회계 전표 자동 생성 로직까지. 이런 개념들은 교과서나 강의에서 배울 수 있는 종류가 아니었다.
도메인을 이해해야 코드가 보인다는 말이 이렇게 실감날 줄 몰랐다.
200명 규모 SI 프로젝트의 현실
처음으로 대형 SI 프로젝트에 참여하면서 시스템 간 연동이 얼마나 복잡한지 직접 체험했다. MCI(Message Channel Interface)로 시스템 간 통신하고, EAI(Enterprise Application Integration) 기반으로 데이터를 동기화하고, DB-to-DB로 본점과 지점 데이터를 실시간 연동했다.
레거시와 신규 시스템이 공존하는 환경에서 점진적으로 마이그레이션하는 전략도 처음 경험했다. 한 번에 다 바꾸는 건 이론상의 얘기고, 현실은 항상 점진적이었다.
처음 만난 기술 스택
WebSquare5는 웹 표준이 아닌 RIA 솔루션이라 처음에 많이 낯설었다. DOM 기반 개발 방식이 일반 웹과 달라서 초기 학습 비용이 꽤 들었다. AnyFrame도 전자정부 표준 프레임워크 기반이라 Spring과 비슷하지만 미묘하게 다른 부분들이 있었다. 금융권 전용 인터페이스 시스템인 EIMS도 이번에 처음 다뤘다.
프로젝트를 하면서 느낀 것들
일정 관리의 현실
200명이 넘는 사람이 참여하는 프로젝트에서는 예상치 못한 변수가 계속 생겼다. 추가 인력을 투입해도 일정이 계속 밀렸고, 레거시 시스템 분석은 문서도 없고 담당자도 없어서 막막할 때가 많았다. 업무 도메인을 모르면 요건을 잘못 이해해서 수정이 반복됐다.
인력을 늘린다고 속도가 빨라지지는 않는다. 프레더릭 브룩스가 “맨먼스 미신”에서 한 말이 현실에서 그대로 맞아떨어지는 경험이었다.
소통이 기술만큼 중요하다
다른 도메인 팀과 인터페이스 협의하는 과정, 업무 담당자와 요구사항을 맞춰가는 과정에서 기술적 제약을 비개발자에게 설명하는 능력이 얼마나 중요한지 실감했다. 코드 짜는 시간보다 소통에 쓰는 시간이 더 많았던 날도 있었다.
장기 프로젝트에서의 페이스 조절
강도 높게 오래 일하는 환경에서 페이스 조절이 얼마나 중요한지 배웠다. 모르는 것을 빨리 인정하고 도움을 요청하는 게 혼자 끙끙거리는 것보다 훨씬 효율적이었다. 완벽을 추구하기보다 점진적 개선이 현실적이라는 것도 이 프로젝트에서 체감했다.
아쉬웠던 점들
초기 학습 곡선: WebSquare5와 AnyFrame이 낯설어서 초기 생산성이 현저히 떨어졌다. 미리 학습할 시간이 주어졌다면 훨씬 효율적이었을 것이다.
문서화 부족: 일정에 쫓기다 보니 복잡한 비즈니스 로직에 대한 문서를 충분히 남기지 못했다. 나중에 내가 짠 코드를 내가 봐도 헷갈리는 상황이 왔다.
테스트 자동화 없음: 수동 테스트에 의존하다 보니 회귀 테스트의 부담이 컸다. 처음부터 자동화된 테스트 환경을 갖췄다면 더 안정적이었을 것이다.
이 경험이 남긴 것
기술적 역량보다 도메인 이해가 먼저라는 것. 시스템이 아무리 잘 짜여도 업무를 모르면 틀린 것을 옳다고 구현하게 된다.
엔터프라이즈 아키텍처에 대한 관심도 이때 생겼다. MCI, EAI 같은 통합 패턴들이 왜 존재하는지, 대규모 시스템에서 서비스 간 데이터 흐름을 어떻게 설계해야 하는지. 단순한 기능 개발을 넘어 전체 시스템 아키텍처를 이해하고 싶다는 방향이 이 프로젝트에서 생겼다.
5개월은 짧았지만 밀도가 높았다. 힘들었던 만큼 남은 것도 많다.
연결노트
- 산업은행 KINS 프로젝트 개요 - 전체 프로젝트 배경과 기본 정보
- 예산경비 업무 분석 - 담당 업무 도메인 분석
- 개발 일정 관리 - 프로젝트 중 겪은 어려움
- 대규모 SI 프로젝트의 MCI 와 EAI 는뭘까 - 엔터프라이즈 아키텍처 이해
- 레거시 시스템 유지보수에서 문서화 부재는 예상치 못한 복잡성으로 이어진다 - 이전 레거시 경험과 비교
- DB 통신 횟수를 줄이는 것이 성능 개선의 핵심이다 - 대용량 데이터 처리 경험과의 연관성