탄소 중립이 기업의 생존 과제가 되면서, 탄소 배출량을 정확히 측정하고 보고하는 탄소 회계 플랫폼의 가치는 그 어느 때보다 높아졌습니다. 하지만 정교한 대시보드와 AI 추천 기능 뒤에 숨겨진 데이터베이스의 내부는 어떨까요?
최근 분석된 EcoNiPass의 데이터베이스 스키마는 197개의 테이블로 구성된 복잡한 구조를 가지고 있습니다. 이는 과거의 관행과 빠른 기능 구현에 치중한 결과로, 현재는 AI 확장성과 규제 리포팅이라는 높은 벽 앞에서 '데이터의 덫'이 되어버린 상태입니다. 시니어 아키텍트의 시각에서, 이 197개의 테이블이 보내는 5가지 기술적 경고를 통해 우리가 직면한 리스크와 해결책을 분석해 보겠습니다.
1. 유령 데이터의 습격: 삭제된 데이터가 당신의 탄소 배출량을 계산하고 있다면?
탄소 회계에서 '데이터의 무결성'은 곧 플랫폼의 신뢰도와 직결됩니다. EcoNiPass는 데이터 복구를 위해 deleted_at 컬럼을 사용하는 '소프트 딜리트(Soft Delete)' 방식을 채택하고 있습니다. 그러나 이 설계가 실제 쿼리 레이어에서 제대로 작동하지 않는다면, 시스템은 '유령 데이터'에 의해 오염됩니다.
분석 결과는 충격적입니다. 비즈니스 로직의 핵심인 SQL 파일들을 전수 조사했을 때, 필터링 체계가 사실상 무너져 있음이 확인되었습니다.
"전체 SQL 파일 334개 중 277개(83%)에서 deleted_at IS NULL 필터가 누락되어 있습니다. 이는 단순한 데이터 오염을 넘어, AI 출력의 신뢰성과 정부 제출용 규제 리포트의 정확성에 치명적인 영향을 미칩니다."
사용자가 삭제한 배출량 데이터가 대시보드 집계에 포함되거나, 정부에 제출할 XML 리포트에 합산된다면 이는 단순한 버그가 아니라 심각한 '규제 리스크(Regulatory Risk)'가 됩니다. 특히 AI가 오염된 데이터를 학습하여 감축 전략을 제안할 경우, 기업은 잘못된 의사결정을 내리게 되며 이는 비즈니스의 생존을 위협하는 결과로 이어질 수 있습니다.
2. 데이터베이스의 비만: 단지 '임시 저장'을 위해 84개의 테이블이 필요할까?
EcoNiPass의 스키마에는 '구조적 부채(Structural Debt)'라고 불릴 만한 극단적인 비효율이 존재합니다. 바로 확정 데이터와 초안(Draft) 데이터를 분리하기 위해 똑같은 구조의 테이블을 물리적으로 쌍을 지어 만든 설계입니다.
현재 Scope 3 배출 관리를 위해 42쌍, 즉 총 84개의 테이블(확정 42개 + T_temp_ 임시 42개)이 운영되고 있습니다. 아키텍처의 대원칙인 "단순함이 복잡함을 이긴다"는 관점에서 볼 때, 이는 status 컬럼 하나로 해결할 수 있는 문제를 물리적 테이블 분리로 대응하여 관리 비용을 기하급수적으로 늘린 전형적인 사례입니다.
이러한 '비만형 스키마'는 엔티티 파일과 마이그레이션 대상을 불필요하게 늘려 시스템의 유연성을 차단합니다. 84개의 테이블을 단 1개의 통합 테이블로 전환하고 status 컬럼을 도입하는 것만으로도 관리 비용을 획기적으로 줄일 수 있습니다.
3. 하드코딩된 비즈니스 로직: 새로운 카테고리 하나를 추가하는 데 파일 7개가 필요하다면?
비즈니스 요구사항은 끊임없이 변화합니다. GHG 프로토콜의 기준이 개정되어 새로운 탄소 배출 카테고리를 추가해야 할 때, 현재의 시스템은 얼마나 유연할까요?
EcoNiPass는 각 Scope 3 카테고리를 물리적 테이블로 생성하는 '하드코딩된 스키마' 구조를 가지고 있습니다. 이로 인해 새로운 카테고리 하나를 추가할 때마다 다음과 같은 연쇄적인 수정이 발생합니다.
- Entity: 두 개의 테이블 정의 파일(확정/임시) 생성
- Alembic: 데이터베이스 마이그레이션 파일 작성
- Repository: 데이터 접근 로직 추가
- Interactor: 비즈니스 로직 구현
- DTO: 데이터 전송 객체 생성
- API: 엔드포인트 추가 및 연결
최소 7개 이상의 파일을 새로 만들거나 수정해야 하는 이 구조는 출시 속도(Time-to-Market)를 늦출 뿐만 아니라, 최대 7개의 컬럼으로 구성된 복합 PK(Primary Key) 구조와 맞물려 스키마 진화를 원천적으로 차단하고 있습니다. 가변적인 활동 데이터를 수용할 수 있는 JSONB 타입과 Surrogate Key(UUID)를 활용한 단일 테이블 통합이 절실한 이유입니다.
4. AI는 거짓말을 하지 않는다, 오염된 데이터가 거짓말을 할 뿐
최근 EcoNiPass는 배출계수 추천 등을 위해 AI와 벡터 검색(pgvector) 기능을 강화하고 있습니다. 하지만 AI의 성능은 모델의 정교함보다 '데이터의 순도(Purity)'에서 결정됩니다.
현재의 구조에서는 벡터 검색 결과에 이미 삭제된 배출계수 정보가 포함될 위험이 큽니다. 더 심각한 점은 사용자 감사(Audit) 컬럼의 부재입니다. 현재 42개의 Scope 3 배출 데이터 테이블에는 누가, 언제 데이터를 입력하고 수정했는지 추적할 수 있는 표준화된 감사 컬럼이 부족합니다.
누가 입력했는지 증명할 수 없는 데이터는 AI 응답의 신뢰도를 떨어뜨릴 뿐만 아니라, GX-ETS나 CSRD와 같은 국제적인 규제 감사 대응을 불가능하게 만듭니다. AuditMixin과 같은 표준화된 감사 로그를 도입하여 데이터의 이력을 투명하게 관리하는 것이 AI 확장의 선결 과제입니다.
5. 결론: 지속 가능한 소프트웨어를 위한 리팩토링의 여정
기술 부채는 복리로 쌓입니다. 과거 WingArc 시절부터 이어진 '일본식 SI 관행'이나 '물리적 테이블 분리'는 초기에는 직관적으로 보였을지 모르나, 시스템 규모가 커진 지금은 비즈니스의 민첩성을 갉아먹는 거대한 장애물이 되었습니다.
EcoNiPass가 신뢰받는 탄소 회계 플랫폼으로 생존하기 위해서는 다음과 같은 단계적 리팩토링 로드맵이 실행되어야 합니다.
- P0 (즉시 해결): 277개의 SQL 파일에 deleted_at 필터를 적용하여 데이터 정확성과 규제 대응력을 즉시 회복해야 합니다.
- P1 (구조 개선): 84개의 Scope 3 임시/확정 테이블을 status 컬럼과 JSONB를 활용한 1개의 테이블로 통합하고, XML 리포트 필수 컬럼을 확보해야 합니다.
- P2 (AI 최적화): AuditMixin을 통한 감사 로그 표준화와 벡터 데이터 확충을 통해 AI 서비스의 신뢰도를 공고히 해야 합니다.
소프트웨어도 기업의 탄소 배출량처럼 관리되어야 합니다. 불필요한 기술적 찌꺼기를 줄이고 데이터의 순도를 높이는 작업은 개발팀의 생산성을 넘어, 비즈니스의 생존과 고객의 신뢰를 지키는 유일한 길입니다.
마지막으로 질문을 던집니다. 여러분의 서비스 데이터베이스는 미래의 AI 확장을 수용할 준비가 되어 있습니까, 아니면 과거의 관행에 묶여 있습니까?