최근에 있었던 일
이전글에서 공통 개발과 AA 역할을 해볼 수 있어서 신나게 일하던 어느날...
얼마 해보지도 못하고 담당 업무가 바뀌게 되었다.ㅜㅜ
실제 도메인 업무로 변경된 이후 감리가 얼마 남지 않아 2주간 8시에 퇴근하라는 특명을 받고 더 우울해졌다. 면접도 준비해야되는데..
그래도 관련된 데이터베이스를 설계하면서 생긴 의문점을 해소하는 과정에서 중요한 관점하나를 깨닫게 되었고, 오늘은 이에관해서 얘기하고자 한다.
기술적 완성도 & 최적화에 대한 집착
작년 취업을 준비할때 매우 무서운 말들을 많이 들었었다.
SI가면 SI마인드 박혀서 탈출못함
특히 공공SI가면 산출물만 하다가 물경력됩니다 등등..
하지만 반대로 SI를 탈출한 사람들의 후기를 보면
코드가 돌아가는걸로 그치지말고 최적화 방안을 고민해야됩니다
생산성이나 성능적으로 항상 고민한 흔적을 남겨야합니다
라고 얘기했다.
내가 블로그를 최근 꾸준히 올리는 이유중에 이러한 고민도 어느정도는 지분을 차지한다. 그렇게 최근까지도 물경력이 되지 않기 위해 성능 최적화에 몰두하며 기술적 완성도만을 추구해왔었지만..
이 과정에서 회사와 고객이 가장 중요하게 생각하는 도메인과 비즈니스 관점을 놓치는 실수를 범했다.
실제 사례: 대량 코드 데이터 관리 문제
최근 프로젝트에서 Ncode(약 15,000개 종류)와 NLink(약 50만개 종류)라는 두 가지 대량 코드 데이터를 크로스 조인하여 단일 테이블로 관리해야 하는 상황이 발생했다.
순수 기술적 관점에서 이는 매우 비효율적으로 보였다.
크로스 조인 결과는 약 75억 개(15,000 × 500,000)의 레코드를 생성할 수 있었고,
이를 계속 업데이트해야 했기 때문이다.
내 생각으로는 데이터 파티셔닝을 통한 관리가 더 효율적이라고 판단했다.
예를 들어, 지역별로 테이블을 파티셔닝하여 관리하면 검색 및 업데이트 성능을 크게 향상시킬 수 있을 것이라 생각했다.
또한, 인덱싱 전략을 최적화하고 필요한 경우에만 동적으로 조인하는 방식이 더 나은 접근법이라 생각했었다.
PM님과의 대화
이러한 의문을 해소하기 위해 프로젝트 매니저(PM)님에게 직접 문의했다. 놀랍게도, 고객사(환경부)의 입장에서 본 상황은 완전히 달랐다.
PM님은 이렇게 설명해주셨다.
지금 도메인의 코드 항목들은 예측할 수 없는 방식으로 변경될 수 있어요. 예를 들어, 기훈씨가 제안한 지역을 기준으로 파티셔닝을 했다가 새로운 지역이 추가되면 테이블 구조 자체를 변경해야 하는 상황이 발생할 수 있어요. 이는 사용자가 관리 기능을 통해 자체적으로 해결할 수 없고, 새로운 개발팀의 개입이 필요한 문제를 초래할 수 있습니다.
이 말을 듣는 순간, 나는 큰 깨달음을 얻었다. 고객사는 시스템의 유연성과 사용자 자율성을 기술적 효율성보다 더 중요하게 생각했고, 이는 이미 우리 프로젝트의 관리자와 협의가 된 사항이였다. 그들에게는 코드 항목을 스스로 관리하고 필요할 때 즉시 변경할 수 있는 능력이 핵심 요구사항이었다.
기술적 효율성과 비즈니스 요구사항의 충돌
이 사례는 기술적 효율성과 비즈니스 요구사항이 충돌할 수 있는 전형적인 예였다. 내가 제안한 파티셔닝 방식은 데이터베이스 성능 측면에서는 최적이었을지 모르지만, 다음과 같은 문제가 있었다.
- 유지보수 복잡성: 파티셔닝 구조를 변경하려면 개발팀의 개입이 필요했다.
- 사용자 자율성 제한: 고객이 스스로 코드 체계를 관리하기 어려워졌다.
- 변화 대응 지연: 새로운 요구사항(예: 새 지역 추가)에 신속하게 대응하기 어려웠다.
반면, 단일 테이블 접근 방식은 기술적으로는 덜 효율적으로 보였지만 다음과 같은 이점이 있었다.
- 유연성: 사용자가 코드 항목을 자유롭게 추가, 수정, 삭제할 수 있었다.
- 자율성: 고객이 개발팀의 도움 없이 시스템을 관리할 수 있었다.
- 빠른 변화 대응: 비즈니스 규칙이나 요구사항 변경에 즉시 대응할 수 있었다.
(결국은 75억개의 데이터는 너무 방대한 양이여서, 다른 방안으로 대처하긴했다.)
비즈니스 요구사항의 중요성
이 경험을 통해 다음과 같은 중요한 교훈을 얻었다.
- 기술적 최적화보다 비즈니스 유연성: 때로는 기술적으로 덜 효율적인 방식이라도 비즈니스 요구사항에 더 유연하게 대응할 수 있다면 그것이 더 나은 선택일 수 있다.
- 고객 관점의 이해: 개발자는 성능이나 기술적 측면만 고려하는 것이 아니라, 최종 사용자와 고객의 실제 필요와 운영 환경을 이해해야 한다.
- 장기적인 유지보수성: 단기적인 성능 이점보다 장기적인 유지보수성과 확장성이 더 중요할 수 있다.
- 의사소통의 중요성: 기술팀과 비즈니스팀 간의 효과적인 의사소통은 프로젝트의 성공에 필수적이다.
기술과 비즈니스의 조화
이 경험 이후, 나는 데이터베이스 설계 접근 방식을 다시 생각해보게 되었다. 최적의 솔루션은 기술적 효율성과 비즈니스 요구사항 사이의 균형을 찾는 것이었다. 몇 가지 추가 대안을 고려해 볼 수 있었다.
- 하이브리드 접근법: 기본 구조는 유연성을 제공하되, 성능 최적화를 위한 기술적 방안(인덱싱, 캐싱 등)을 추가로 적용한다.
- 점진적 최적화: 시스템을 유연하게 설계하되, 실제 사용 패턴을 모니터링하여 병목 지점을 식별하고 점진적으로 최적화한다.
- 비즈니스 규칙 분석: 데이터 구조를 설계하기 전에 비즈니스 규칙과 요구사항을 철저히 분석하여 변경 가능성이 높은 부분을 식별한다.
결론
데이터베이스 설계, 특히 코드 테이블의 설계는 단순한 기술적 결정이 아닌 비즈니스 요구사항과 사용자 경험을 고려한 종합적인 접근이 필요했다.
개발자 관점에서는 유지보수성, 가독성 등 기술적 측면과 소비자 관점에서는 비즈니스 유연성, 사용자 요구사항, 장기적인 운영 관점등을 균형 있게 고려하는 것이 중요했다.
결국 데이터베이스 설계는 기술과 비즈니스의 균형점을 찾는 과정이었으며, 이 균형을 이해하고 적용할 때 진정으로 가치 있는 시스템을 구축할 수 있음을 깨달았다. 개발자로서 단순히 물경력이 되지 않기 위해 기술적 완성도만 추구하는 것이 아니라, 비즈니스 도메인을 깊이 이해하고 고객의 실제 필요에 맞는 솔루션을 제공하는 것이 진정한 성장의 방향이지 않을까... 생각해보며 글을 마친다.
