푸른영혼의별

결론부터 말씀드리면, 인증(Authentication)은 "사용자가 누구인지 확인하는 과정" 이고, 인가(Authorization)는 "사용자가 특정 자원에 접근할 권한이 있는지 확인하는 과정" 입니다.

먼저, 인증은 사용자의 신원을 검증하는 과정입니다. 예를 들어, 웹사이트에 로그인할 때 아이디와 비밀번호를 입력받아 해당 사용자가 누구인지 검증하는 것이 이에 해당합니다. 인증 방식에는 비밀번호 기반 인증, 생체 인증, OTP 인증 등이 있습니다. 또한, 최근에는 보안 강화를 위해 MFA(다중 요소 인증)도 널리 사용되고 있습니다.

반면, 인가는 인증을 통해 신원이 식별된 사용자가 특정 리소스에 접근할 수 있는 권한을 갖고 있는지 확인하는 과정입니다. 예를 들어, 회사 내부 시스템에서 일반 직원은 고객 데이터를 조회할 수 없지만, 관리자 계정은 조회할 수 있도록 설정하는 것이 인가의 한 예입니다. 이 사례에서 일반 직원이 고객 데이터에 접근하지 못하는 이유는 인증에는 성공하지만, 권한이 부족하여 인가에 실패하기 때문입니다.

접근 제어 방식에는 어떤 방식들이 있나요? 🤔

대표적인 접근 제어 방식으로는, RBAC(Role-Based Access Control), ABAC(Attribute-Based Access Control), ReBAC(Relationship-Based Access Control)이 있습니다.

RBAC는 사용자의 역할에 따라 접근 권한을 부여하는 방식으로, 조직 내에서 필요한 역할들을 생성하고 각 역할 별로 어떤 자원에 접근이 가능하며 어떤 행동이 가능한지를 설정합니다. ABAC는 사용자의 속성을 기반으로 접근 권한을 결정하는 방식으로, 보다 세밀한 제어가 가능합니다. ReBAC는 사용자 및 자원 간의 관계를 기반으로 접근 권한을 결정하는 방식입니다.

Micrometer란 무엇이며, 왜 사용하나요?

Micrometer는 벤더 중립적인 메트릭 계측 라이브러리로, 애플리케이션에서 발생하는 다양한 지표(예: CPU 사용량, 메모리 소비, HTTP 요청 및 커스텀 이벤트)를 수집합니다. 이 라이브러리는 Prometheus, Datadog, Graphite 등 여러 모니터링 시스템에 메트릭을 전송할 수 있도록 단순하고 일관된 API(파사드)를 제공하여, 각 백엔드 클라이언트의 복잡한 세부 구현을 감춥니다. 특히 Spring Boot Actuator와 깊이 통합되어, 기본 메트릭을 자동으로 수집하고 노출할 수 있습니다.

Spring Boot Actuator와 Micrometer의 관계는 무엇인가요?

Spring Boot Actuator는 애플리케이션의 상태, 헬스 체크, 환경, 로그 등 여러 운영 정보를 노출하는 관리 엔드포인트를 제공합니다. 내부적으로 Actuator는 Micrometer를 사용하여 JVM, HTTP, 데이터베이스 등 다양한 메트릭을 수집합니다. 즉, Actuator는 모니터링 및 관리 인터페이스를 제공하고, Micrometer는 그 밑에서 실제 메트릭 데이터를 계측하고 여러 모니터링 시스템으로 전송하는 역할을 담당합니다.

Micrometer를 사용하여 커스텀 메트릭을 생성하는 방법을 설명해주세요.

아래는 Micrometer를 활용하여 커스텀 메트릭(카운터, 타이머, 게이지)을 생성하고 업데이트하는 예제 코드입니다. 이 코드는 HTTP 요청의 건수와 처리 시간, 그리고 현재 활성 세션 수를 측정하는 예제입니다.

package com.example.metrics;

import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.Gauge;
import io.micrometer.core.instrument.MeterRegistry;
import io.micrometer.core.instrument.Timer;
import org.springframework.stereotype.Service;

@Service
public class CustomMetricsService {

    private final Counter requestCounter;
    private final Timer requestTimer;
    private final CustomGauge customGauge;

    // 생성자에서 MeterRegistry를 주입받아 필요한 메트릭을 등록합니다.
    public CustomMetricsService(MeterRegistry meterRegistry) {
        // HTTP 요청 총 건수를 세는 Counter (태그로 엔드포인트 구분)
        this.requestCounter = meterRegistry.counter("custom.requests.total", "endpoint", "/api/test");

        // HTTP 요청 처리 시간을 측정하는 Timer (태그로 엔드포인트 구분)
        this.requestTimer = meterRegistry.timer("custom.request.duration", "endpoint", "/api/test");

        // Gauge: 예를 들어, 현재 활성 세션 수를 측정하기 위한 커스텀 객체를 등록
        this.customGauge = new CustomGauge();
        Gauge.builder("custom.active.sessions", customGauge, CustomGauge::getActiveSessions)
                .tag("region", "us-east")
                .register(meterRegistry);
    }

    /**
     * 실제 비즈니스 로직을 실행할 때 요청 카운트와 처리 시간을 측정합니다.
     * @param requestLogic 실제 처리할 로직 (예: HTTP 요청 처리)
     */
    public void processRequest(Runnable requestLogic) {
        // 요청 수 증가
        requestCounter.increment();
        // 요청 처리 시간 측정
        requestTimer.record(requestLogic);
    }

    /**
     * 활성 세션 수 업데이트 (예를 들어, 로그인/로그아웃 이벤트에서 호출)
     * @param activeSessions 현재 활성 세션 수
     */
    public void updateActiveSessions(int activeSessions) {
        customGauge.setActiveSessions(activeSessions);
    }

    /**
     * 커스텀 Gauge의 값을 저장하는 내부 클래스.
     */
    private static class CustomGauge {
        // 현재 활성 세션 수를 저장 (volatile을 사용해 스레드 안정성 확보)
        private volatile double activeSessions = 0;

        public double getActiveSessions() {
            return activeSessions;
        }

        public void setActiveSessions(double activeSessions) {
            this.activeSessions = activeSessions;
        }
    }
}

• MeterRegistry 사용
• 생성자에서 MeterRegistry를 주입받아 애플리케이션의 모든 메트릭을 중앙에서 관리하고, 설정된 모니터링 백엔드로 주기적으로 전송합니다.
• Counter
• requestCounter는 /api/test 엔드포인트에 대한 요청 건수를 카운트합니다. 매 HTTP 요청마다 increment() 호출로 증가시킵니다.
• Timer
• requestTimer는 HTTP 요청 처리 시간을 측정합니다. record() 메서드를 사용해 실제 로직 실행 시간을 기록합니다.
• Gauge
• customGauge는 현재 활성 세션 수를 측정하는 데 사용됩니다. Gauge는 항상 현재 상태를 조회하는 함수(getActiveSessions())를 호출하여 실시간 값을 반영합니다.

시장 포지션: 엔클라우드24(㈜웰데이타시스템)는 2011년 국내 최초 MSP(Managed Service Provider)로 시작하여 15년 이상 운영된 국내 최장수 클라우드 전문 기업이다. AWS, KT클라우드, 네이버클라우드, Azure, Zenlayer 등 주요 퍼블릭 클라우드를 모두 취급하는 멀티클라우드 MSP로서, KT·NHN·네이버 등 통신·포털 계열 CSP와 경쟁한다. 삼성SDS·KT클라우드·NHN클라우드 같은 대기업 계열 클라우드 사업자 및 메가존·베스핀글로벌 같은 대형 MSP와 비교할 때, 엔클라우드24는 고객맞춤형 멀티클라우드와 24×365 기술지원 체계를 앞세워 안정성과 비용 효율을 강조한다. 특히 국내외 게임사와 스타트업, 중소기업을 주요 고객으로 삼고, 클라우드 도입 컨설팅과 운영 대행(매니지드 서비스)에 강점을 보여 왔다. 이에 따라 KT Cloud나 NHN Cloud처럼 자체 인프라 기반 대규모 CSP와는 달리, 엔클라우드24는 오히려 중소·벤처·게임사에 특화된 클라우드 파트너로 자리매김하고 있다.

STP 분석

• Segmentation (세분화): 엔클라우드24는 초기부터 게임업계와 IT 스타트업을 주요 세그먼트로 공략해 왔다. 국내 게임업체들이 해외(특히 중국) 진출 시 클라우드 기반 서비스를 필요로 하면서, 4년 전 중국법인을 설립하여 게임사 대상 최적화 서비스를 제공해 왔다. 그 외에도 엔터프라이즈, 웹서비스, 온라인마케팅, 이러닝 등 다양한 분야의 중소·중견기업과 공공기관이 타깃이다. 또한 최근에는 AI 관련 인프라(고성능 GPU 서버)와 예술계 협업(‘예술 AI 클라우드’) 등 새로운 분야로 세그먼트를 확대하고 있다.
• Targeting (타깃팅): 특히 엔클라우드24는 규모가 작은 인디·중소 게임개발사와 스타트업, 온라인 서비스 기업을 주요 공략 대상으로 삼는다. 최근에는 게임서버 백엔드 엔진 ‘플레이나누’ 사업을 인수하여, 소규모 게임사에 최적화된 올인원 서비스 제공을 강화했다. 이 외에도 공공기관용 클라우드 서비스(CSAP 인증 G-Cloud)와 AI 프로젝트(고성능 GPU 서버 임대) 등을 통해 공공·AI 분야 수요도 함께 공략하고 있다.
• Positioning (포지셔닝): 엔클라우드24는 **“국내 1세대 클라우드 MSP”**로서 신뢰성과 안정성을 강조하며, 24시간 365일 고객 지원이 가능한 토털 IT 운영 파트너로 차별화했다. 클라우드 도입 시 비용 절감과 유연성을 중시하는 기업에게 적합하다는 이미지를 내세우며, 저비용·고품질 서비스를 강점으로 홍보한다. 또한 풍부한 구축·운영 레퍼런스와 연중무휴 테크센터(24×365) 운영을 내세워 “언제나 안정적인 무중단 서비스”를 제공하는 기업으로 인식되도록 포지셔닝하고 있다.

수익 구조

엔클라우드24의 주요 수익원은 **클라우드 인프라 사용료(IaaS)**와 매니지드 서비스 및 컨설팅 수수료다. 서버(VM), 스토리지, 네트워크 등의 자원 사용량에 따라 비용을 부과하는 종량제 요금제가 기본 구조로, 사용량 기반 과금 체계로 수익을 얻는다. 예를 들어 고품질 가상화 서버와 고성능 스토리지 서비스는 모두 종량제 요금제로 제공된다. 이 외에 1년 이상 장기 계약시 할인, 프로모션 할인(예: 서버 50% 할인 이벤트) 등을 통해 가격 경쟁력을 높인다. 또한 도메인 등록·SSL 인증서·GPU 서버 임대·보안서비스 등 부가 서비스 제공을 통해서도 부수적인 매출을 확보한다. 주요 서비스별 매출 비중은 공개되지 않았으나, 일반적으로 IaaS(컴퓨팅·스토리지)가 전체 매출의 상당 부분을 차지하고, 매니지드·컨설팅 수수료와 부가 서비스 매출이 그 뒤를 잇는 구조로 추정된다.

강점과 약점

엔클라우드24의 강점으로는 첫째, 기술력과 경험이다. 업계 최초 MSP로서 15년 이상의 클라우드 구축·운영 노하우를 축적했고, 다양한 클라우드 플랫폼에 대한 전문성을 보유했다. 둘째, 24×365 고객지원 체계를 통해 운영 안정성을 확보했다. 셋째, 다계층 통합 서비스 제공이다. 단순 인프라 임대에 그치지 않고 컨설팅부터 보안·모니터링·장애대응까지 전 영역의 매니지드 서비스를 제공하여 고객의 IT 운영 부담을 덜어준다. 넷째, 비용 효율성이다. 엔터프라이즈와 게임, 이러닝 등 다양한 분야에서 비용 절감 효과를 강조하며, 중소기업이나 스타트업이 부담 없이 클라우드를 이용할 수 있도록 지원한다.

반면 약점으로는 상대적 규모와 인지도 부족을 들 수 있다. 삼성SDS나 KT·NHN 같은 대형 CSP에 비해 엔클라우드24는 자본력과 글로벌 인프라 규모가 작아 시장 점유율이 크지 않다. 자체 데이터센터를 운영하기보다는 주요 CSP 자원을 중개하는 구조이므로, 순수 클라우드 자원 제공 측면에서는 한계를 가질 수 있다. 또한, 뛰어난 맞춤 지원을 제공하는 만큼 운영비용이 발생해 가격 경쟁력 면에서는 일부 고객이 직접 CSP 서비스를 이용하는 것보다 비쌀 수 있다. 마지막으로 브랜드 인지도가 한정적이어서, 대기업이나 해외 고객 확보에는 다소 약점을 보일 수 있다.

1. 국내 vs 해외 IaaS 서비스 비교 (기술, 아키텍처, 가격, 공공 대응)

1.1 기술 성숙도 및 인프라 아키텍처 비교

해외 글로벌 사업자: AWS, Microsoft Azure, Google Cloud 등 글로벌 하이퍼스케일러들은 수년간 막대한 투자를 통해 최고 수준의 기술 성숙도를 이뤄왔습니다. IaaS 분야를 개척한 AWS는 다양한 인스턴스 유형, 컨테이너/서버리스, AI/ML 플랫폼 등 가장 폭넓은 서비스 포트폴리오를 제공하며 2024년 현재 전 세계 IaaS 시장에서 약 37.7%의 점유율로 1위를 차지하고 있습니다. Azure 역시 엔터프라이즈 솔루션과의 연계 강점을 바탕으로 23.9%의 점유율로 2위이며, Google Cloud는 데이터 분석 및 AI 역량을 앞세워 9.0%로 3위권을 형성하고 있습니다. 이들 글로벌 기업들은 **전 세계 수십 개 지역에 데이터센터 리전과 다중 가용영역(AZ)**을 구축하여 고가용성과 지연 최소화를 달성하였고, 전용 해저케이블 등 전 지구적 네트워크 인프라를 직접 운영해 안정적인 서비스를 제공합니다. 예를 들어 AWS는 서울, 도쿄, 프랑크푸르트 등 각 주요 권역별 리전을 통해 글로벌 서비스를 지원하며, 자체 설계한 네트워크 가속기(Nitro)와 서버용 칩(Graviton)을 도입해 성능과 보안 모두 선도적인 아키텍처를 구현했습니다. Azure도 한국(서울/부산)에 복수 리전을 운영하며 하이브리드 클라우드(애저 Stack 등)로 온프레미스 연동을 지원하는 등 기업 환경에 최적화된 아키텍처를 갖추고 있습니다. Google Cloud는 구글의 광대한 글로벌 백본망과 쿠버네티스 등의 오픈소스 주도 기술로 높은 확장성과 빅데이터 처리에 강점을 보입니다. Oracle Cloud는 전통적인 DB기업의 강점을 살려 고성능 오라클 DB 서비스, 엑사데이터 전용 인프라 등을 특징으로 내세우며 전 세계에 40여 개 리전을 빠르게 확장하고 있지만, 시장 영향력은 아직 상위 5위 밖의 니치(niche) 수준입니다.

국내 사업자: Naver Cloud, KT Cloud, NHN Cloud 등 국내 기업들의 기술 수준도 최근 빠르게 향상되고 있으나, 글로벌 선도사들과 비교하면 서비스 다양성, 글로벌 인프라 규모 측면에서는 제한적인 편입니다. 네이버클라우드는 2017년 서비스를 시작한 이래 국내 최고 수준의 기술 인력을 바탕으로 약 200여 종의 클라우드 서비스를 출시하며 성장해왔고, 게임 특화 서비스, AI 플랫폼(클로바 CLOVA) 등 네이버 자체 기술을 접목한 서비스도 제공합니다. 특히 2023년 초 VPC(Network 격리)를 도입하고 금융·공공 전용 클라우드 존을 운영하는 등 보안성과 안정성을 높였으며, 한국어 기술지원과 24시간 모니터링으로 고객 지원 측면의 강점도 갖추고 있습니다. Naver Cloud는 현재 국내 춘천과 세종의 자체 데이터센터(각 춘천, 각 세종)를 기반으로 서울/평촌 등 리전을 운영하고, 미국, 싱가포르 등 해외 10여 개 거점으로 글로벌 리전을 확장하여 서비스 중입니다. 다만 글로벌 커버리지나 초대형 확장성 면에서는 AWS 등에는 미치지 못하며, 일례로 최고사양 GPU 인스턴스나 자체 반도체 등 일부 최첨단 분야에서는 아직 제한적입니다. KT클라우드는 국내 통신사 인프라 출신답게 국내 여러 지역 IDC 거점과 KT망과의 연계를 통한 네트워크 품질을 강점으로 내세웁니다. 오래전부터 IaaS를 제공해온 경험으로 전통적인 가상 서버, 스토리지, 네트워크 서비스의 안정성은 높으며, 통신망 연동 IoT 클라우드나 에지 컴퓨팅 등 통신사형 서비스를 제공합니다. 하지만 글로벌 리전 부재로 해외 서비스 커버리지가 없고, 신규 기술 혁신 속도는 다소 더딘 편으로 평가됩니다. NHN클라우드는 NHN의 게임/IT서비스 인프라 운영 경험을 바탕으로 탄생하여 게임사 대상 특화 서비스, 개발 편의 기능 등에 강점을 보입니다. 경기도 판교 및 전국에 여러 데이터센터를 보유하고 있고, 특히 **공공기관 전용 데이터센터(예: 강원 춘천)**를 운영하여 지자체 전산망에 클라우드를 제공하는 등 고객 맞춤형 인프라 구성에 유연합니다. 다만 서비스 포트폴리오나 규모는 앞선 두 업체보다 작고, 글로벌 인프라는 일본 등 일부 거점에 제한됩니다. 요약하면, 글로벌 CSP들은 기술 완성도와 인프라 규모에서 앞서 있고, 국내 CSP들은 국내 고객 수요에 특화된 안정적 서비스에 주력하면서 점진적으로 기술 갭을 줄여가는 추세입니다.

1.2 가격 정책 비교

해외 글로벌 사업자: AWS를 비롯한 글로벌 IaaS 사업자들은 종량제(Pay-as-you-go) 기반의 과금체계를 표준으로 하며, 사용량만큼 비용을 지불하는 방식이 기본입니다. 여기에 예약 인스턴스 할인, 약정 할인, 규모별 할인 등 다양한 할인옵션을 제공하여 고객이 미리 리소스를 예약하거나 장기 사용 시 비용을 절감할 수 있게 합니다. 예를 들어 AWS의 경우 1년 또는 3년 약정으로 인스턴스를 예약하면 온디맨드 대비 최대 40~70%까지 할인받을 수 있고, Azure도 하이브리드 이용자를 위해 기존 온프레미스 윈도/SQL 라이선스를 클라우드에 가져오면 할인해주는 하이브리드 혜택을 제공합니다. Google Cloud는 **지속 사용 할인(Sustained Use Discount)**을 통해 한달 중 자원을 오래 사용할수록 자동으로 단가를 낮춰주는 정책을 운영하고, Oracle Cloud는 네트워크 대역폭 비용을 저렴하게 책정하는 등 가격 경쟁력을 내세우고 있습니다. 그러나 글로벌 사업자들의 과금 체계는 서비스 종류가 워낙 많고 복잡하여 최적 요금제를 찾기 어려운 단점도 있습니다. 서비스별로 세분화된 요율과 지역별 가격 차이, 데이터 전송 비용 등의 요소로 인해 예상치 못한 비용 증가(이른바 ‘Cost 폭탄’) 사례도 종종 발생합니다. 또한 해외 사업자는 기본적으로 달러화로 과금되어 환율 변동에 노출되고, 기술지원 비용이 별도인 경우도 있어 중소 규모 고객에게는 **총소유비용(TCO)**이 높게 느껴질 수 있습니다.

국내 사업자: 국내 클라우드 역시 시간당 또는 월단위 사용량 기준 과금을 적용하지만, 원화 요금제로 환율 영향이 없고 국내 기업 대상 다양한 할인 프로모션을 제공하는 등 보다 탄력적인 가격 정책을 펼치고 있습니다. 예를 들어 네이버클라우드는 신규 가입 시 3개월간 100만원 크레딧을 제공하고 일부 중소기업을 대상으로 사용료 할인 이벤트를 수시로 운영합니다. KT클라우드도 모회사 KT의 기업회선 고객에게 클라우드 패키지 할인을 적용하거나, 공공기관을 위해 커스터마이즈드 견적을 제안하는 등 비교적 유연한 가격 협상이 가능합니다. NHN클라우드 역시 게임업계 대상 대량 리소스 사용시 요율 인하 등의 협상을 통해 고객을 유치하는 전략을 써왔습니다. 국내 CSP들의 강점은 데이터 전송 비용이 저렴하거나 무료인 범위가 넓다는 점입니다. 국내 트래픽은 자체 IX(인터넷 연결노드)를 통해 교환하여 비용을 낮추고 있어, AWS 등 글로벌사가 외부망 트래픽에 GB당 과금을 매기는 것과 대비됩니다. 다만 국내 업체들도 고급 GPU나 최신 장비의 비용은 글로벌 대비 크게 저렴하지 않을 수 있고, 규모의 경제 측면에서 글로벌사보다 원가 경쟁력은 떨어진다는 평가도 있습니다. 종합하면 국내 클라우드는 중소 고객이나 원화 결제를 원하는 고객에 유리한 가격 조건을 제공하는 반면, 글로벌 클라우드는 대규모 사용 시 할인 폭이 커져 잘 활용하면 경제적일 수 있으나 구조가 복잡하다는 차이가 있습니다.

1.3 공공시장 대응 역량 비교

공공 부문의 진입 장벽: 국내 클라우드 공공시장에서는 한동안 국내 사업자가 유리한 구도가 이어졌습니다. 국가정보자원이나 정부·지자체 시스템에 민간 클라우드를 도입하려면 한국인터넷진흥원(KISA)의 클라우드 보안인증(CSAP) 획득이 필수인데, 2023년까지는 국내 CSP만 이 인증을 보유하고 있었습니다. 이에 따라 공공기관 사업 입찰에서는 자연히 Naver, KT, NHN 등 국내 기업들이 주도권을 가져왔습니다. 특히 행정망 분리, 데이터 주권 등의 이유로 한때 해외 사업자의 참여가 제한되었던 측면도 있습니다. 그러나 2023년 말 정부가 CSAP 인증을 등급제(상·중·하)로 완화 개편하고, 보안 민감도가 낮은 업무에는 외산 CSP도 활용 가능하도록 정책을 바꾸면서 상황이 변하고 있습니다. Microsoft Azure가 2022년 12월, Google Cloud가 2023년 2월, AWS가 2025년 3월까지 차례로 CSAP ‘하’ 등급 인증을 취득하며 해외 사업자 모두 공공시장 참여 자격을 갖추게 되었습니다. 실제로 AWS는 해당 인증을 바탕으로 정부 AI 연구용 컴퓨팅 지원 사업을 수주하였고, 금융보안원 등 준공공 기관에서도 Azure와 Oracle Cloud를 활용한 시스템 구축을 시작하는 등 공공 분야에서 글로벌 CSP 도입 사례가 나타나고 있습니다. 이에 따라 국내 공공 클라우드 시장도 글로벌 vs 국내 업체 간 경쟁이 본격화되는 분위기입니다.

국내 CSP의 대응 전략: 국내 사업자들은 그동안 공공 특화 역량을 키워온 덕분에 여전히 일정 강점을 유지하고 있습니다. 다년간 정부 부처, 교육청, 지자체 사업을 수행하며 정부 업무 환경에 최적화된 네트워크 구성, 행정전산망 연계, 한국형 보안 통제 등에 풍부한 경험을 쌓았습니다. 예를 들어 네이버클라우드는 행정안전부의 G-클라우드 인증을 획득하여 정부 전산망용 클라우드 서비스를 제공하고 있고, 일부 지자체 행정시스템의 이전 사업을 수주하며 레퍼런스를 확보했습니다. KT클라우드는 공공·교육 분야 100여 개 프로젝트 수행 경험을 보유하고 있으며, NHN클라우드는 지방자치단체 전용 데이터센터를 운영하면서 지역 밀착형 서비스와 물리적 망분리 요건을 충족시킨 바 있습니다. 또한 각 사 모두 행정망 전용 지원 조직을 두고 공공기관 대상 기술지원, 컨설팅 역량을 강화해왔습니다. 특히 보안인증과 국내 법규 준수 측면에서 국내 업체들이 유리합니다. 공공기관 보안 감사에 대비한 자료 제출, 대응 체계가 잘 마련되어 있고, 필요시 고객 데이터가 국내에만 머무르도록 하는 등 정부 규제 충족을 위한 커스터마이즈가 용이합니다. 반면 글로벌 업체들은 획일화된 글로벌 서비스 모델을 기반으로 하기 때문에 맞춤 대응에는 한계가 있을 수 있습니다. 다만 앞서 언급한 대로 이제는 AWS/Azure도 인증을 확보했기 때문에 기술력과 가격 경쟁력을 내세워 적극적으로 공공사업을 공략하고 있습니다. 정부 입장에서도 무조건적인 자국기업 보호보다는 보안 요건만 충족하면 글로벌 업체에도 개방하는 기조를 보이고 있어, 국내 CSP로서도 기술 경쟁력 제고와 비용 효율화 없이는 시장을 지키기 어렵다는 지적이 나옵니다.

요약: 공공 클라우드 시장은 최근 개방 기조로 전환되어 경쟁 심화가 예상되지만, 국내 사업자들은 공공 분야 특화 경험과 인증으로 선제 대응하고 있습니다. 향후 글로벌 CSP들이 중·상등급 CSAP 인증까지 획득해 핵심 기밀 업무까지 노릴 경우 경쟁이 한층 거세질 전망이며, 이에 대한 국내 업계의 전략 수립과 정부의 지원 정책이 병행되고 있습니다.

주요 비교 항목별 국내 vs 해외 사업자 특성 (요약)

국내외 주요 IaaS 사업자들을 기술·인프라, 가격, 공공대응 측면에서 비교하면 다음과 같습니다:

(각 사업자의 상세한 강점과 약점은 아래 2. 각 사업자별 장단점에서 추가 분석합니다.)

2. 주요 IaaS 사업자별 장단점 분석

2.1 아마존 웹서비스 (AWS)

• 기술적 강점: 글로벌 **IaaS 시장 점유율 1위(약 39%)**의 위상에 걸맞게 가장 방대한 서비스 카탈로그와 검증된 안정성을 보유. 2006년 EC2 출시 이래 축적한 노하우로 컴퓨팅, 스토리지, 네트워킹 기본 인프라부터 AI/ML, IoT, 데이터레이크까지 원스톱 클라우드 플랫폼 제공. **다수의 가용영역(AZ)**과 전 세계 30여 리전을 통해 어디서나 동일 품질의 서비스 활용 가능. 또한 서드파티 생태계와 기술 커뮤니티가 가장 활발하여 레퍼런스 자료와 솔루션 연동 측면에서도 유리.
• 비용 및 지원: 유연한 종량제와 다양한 할인 옵션으로 대형 고객일수록 가격 경쟁력 확보 가능. 한편 서비스 구조가 복잡하여 작은 설정 실수에도 과금이 발생할 수 있고, 숙련된 비용 관리 노하우가 필요. 중소 고객의 경우 비용 최적화에 어려움을 겪기도 함. 기본 지원은 영문 위주지만, 한국에도 기술지원 조직이 있어 유료 플랜을 통해 한글/전화 지원 가능.
• 규제 및 보안: 글로벌 표준의 보안인증(ISO 27001 등)을 두루 갖추고 있고, 한국에서도 CSAP 인증(하 등급) 획득으로 공공 진출 자격 확보. 다만 미국 기업으로서 데이터 주권 이슈를 우려하는 시각이 일부 존재하며, 국내법 준수 측면에서는 한국 법인의 법적 책임 등이 검토된 바 있음.
• 단점/고려사항: 현지화된 서비스나 지원은 제한적이어서 한국 시장 특수 요구에 빠르게 대응하기는 어려운 편이라는 지적이 있습니다. 예를 들어 한국형 금융 API나 공공기관 예산회계 연계 등은 직접 구현해야 합니다. 또한 높은 시장지배력으로 벤더 종속(lock-in) 우려를 제기하는 목소리도 있으며, 경쟁사 대비 하드웨어 비용이 높다는 평도 있습니다.

2.2 마이크로소프트 애저 (Microsoft Azure)

• 기술적 강점: Microsoft의 클라우드로, 엔터프라이즈 소프트웨어와의 친화성이 최고 강점입니다. Windows Server, MS SQL, Active Directory 등 기존 기업 환경을 클라우드로 옮기기 용이하며, Office 365, Dynamics 등 SaaS와 연계도 매끄럽습니다. Azure도 전 세계 60+ 리전 운영 중이고, 한국에 서울(코리아 중부), 부산(남부) 두 개 리전을 둬 국내 이중화 지원. 하이브리드 클라우드 구현을 위해 Azure Stack(온프레미스용 Azure)을 제공하는 등 온-오프라인 통합 관리에 강합니다. 최근 OpenAI와 협력하여 고성능 AI 인프라를 구축, AI 모델 서비스(Azure OpenAI Service)에서도 앞서가는 중입니다.
• 비용 및 혜택: AWS와 유사한 종량 과금 체계지만, 기업 라이선스와 연계한 할인(예: 기존 Windows 서버 라이선스 보유 시 VM 비용 할인)으로 기존 MS 고객에게 유리한 정책을 폅니다. 다만 가격 수준 자체는 AWS와 비슷하며, 복잡성도 비등합니다. 국내 데이터센터 리전을 통한 원화 결제 및 국내 카드 결제 등이 가능해 편의성을 높였습니다.
• 고객지원: 한국 마이크로소프트를 통해 한글 기술지원 및 컨설팅을 받을 수 있고, 대기업 대상 전담팀 운영 등 파트너 에코시스템이 탄탄합니다. 특히 MS 제품 사용 경험이 많은 국내 SI 인력들에게 Azure는 비교적 학습장벽이 낮아, IT 담당자 선호도가 높다는 평가입니다.
• 약점: 일부 개발자 생태계에서는 AWS/GCP 대비 신규 클라우드 기술 도입 속도가 느리다는 의견이 있고, 리눅스 기반 오픈소스 프로젝트 호환성 면에서 과거 제약이 지적되기도 했습니다. 그러나 현재는 리눅스 지원도 50% 이상으로 확대되었습니다. 또한 웹 콘솔 UI 복잡성이나 서비스 간 명명 규칙의 일관성 부족 등이 언급되는 등 개발자 경험(DX) 측면에서는 개선 여지가 있습니다.

2.3 구글 클라우드 플랫폼 (GCP)

• 기술적 강점: Google의 강점인 빅데이터 처리와 머신러닝 기술이 집약된 클라우드로, BigQuery(무제한 확장 SQL 데이터웨어하우스), TensorFlow/TPU(고성능 ML 가속) 등 데이터 분석 및 AI 분야 특화 서비스에서 경쟁사 대비 두각을 나타냅니다. 전용 해저케이블과 광케이블로 연결된 구글 백본망의 높은 네트워크 성능도 장점이며, 사용자 지리적 위치에 따라 자동으로 가까운 서버로 라우팅하는 등 지능형 인프라 최적화가 강력합니다. Kubernetes를 탄생시킨 배경답게 **컨테이너 및 멀티클라우드 지원(Anthos)**에도 앞서 있습니다. 서울 리전을 포함해 전 세계 35개 이상의 리전을 운영 중이며, 최근 국내에서 정부 인증(CSAP 하등급)을 획득해 공공영역에도 진출 기반을 마련했습니다.
• 비용 및 정책: GCP는 자동 지속사용할인과 **약정사용 할인(Commitment Discount)**을 제공, 사용량이 늘면 별도 신청 없이 비용이 낮아지는 등 단순하고 합리적인 요금체계를 지향합니다. 데이터 분석 서비스(BigQuery 등)의 경우 용량당 요금으로 책정되어 대규모 데이터를 가진 기업에 비용 효율적입니다. 그러나 다른 글로벌 클라우드와 마찬가지로 대역폭 비용 등은 존재하며, 전반적 비용 수준은 AWS/Azure와 큰 차이는 없으나 영역별로 약간씩 유불리가 있는 편입니다.
• 고객지원 및 생태계: 구글은 개발자 커뮤니티에서 인기있는 기술들을 많이 보유하여 스타트업이나 개발자 친화적이라는 이미지가 있습니다. Stack Overflow 등 온라인에 GCP 관련 자료도 풍부하고, 한국어 문서화도 비교적 잘 되어 있습니다. 공식 지원은 티어에 따라 제공되며, 국내에도 클라우드 전문 인력과 파트너사가 늘고 있어 지원 체계가 강화되는 추세입니다.
• 단점: GCP는 후발주자이기에 글로벌 시장점유율이 8~9% 수준으로 AWS/Azure에 비해 낮고, 기업 레퍼런스가 상대적으로 적습니다. 일부 기업들은 **구글의 서비스 단종(history)**을 우려하기도 하는데, 이전에 소비자 서비스를 갑자기 종료한 사례들 때문입니다. 다만 GCP의 핵심 클라우드 서비스는 안정적으로 지원되고 있어 이러한 우려는 점차 줄고 있습니다. 또한 Google Workspace(G Suite) 등 생산성 SaaS와의 통합을 제외하면, 전통 엔터프라이즈 ERP/CRM 솔루션과의 연계는 Azure에 비해 약한 측면이 있습니다.

2.4 오라클 클라우드 (OCI)

• 기술적 강점: Oracle Cloud Infrastructure(OCI)는 오라클이 자신들의 데이터베이스와 엔터프라이즈 애플리케이션에 최적화된 환경을 제공하기 위해 설계된 클라우드입니다. 따라서 오라클 DB를 위한 Exadata 클라우드 서비스, Autonomous Database(자율운영 DB) 등 고성능 데이터베이스 운영에 있어 타사 대비 특화된 서비스를 제공합니다. 또한 베어메탈 서버, OCI 전용 네트워크 가상화 등으로 고성능, 고집적 워크로드에 대한 지원을 강조하고 있으며, Microsoft Azure와의 상호 연동(OCI-Azure Interconnect)을 통해 두 클라우드 간 초저지연 연결을 제공하는 등 이기종 클라우드 연합 전략도 펼치고 있습니다. 전 세계 30여 개 리전을 운영 중이고 서울 리전도 개설하여 국내 서비스 중입니다.
• 가격 및 혜택: OCI는 단순하고 예측 가능한 요금제를 내세우며, 특히 네트워크 아웃바운드 비용이 경쟁사 대비 저렴하고 IOPS 등의 성능당 가격도 낮다고 주장하고 있습니다. 또한 항상 무료로 제공되는 자원(예: Arm VM, 자율 DB 소형 인스턴스 등)을 두어 초기 사용자가 부담 없이 테스트해볼 수 있게 합니다. 기업 고객과는 개별 협상을 통해 Oracle 제품 사용량에 따라 패키지 딜을 제시하기도 합니다.
• 고객지원: 오라클은 전통적 기업 고객망이 탄탄하여, OCI 도입 시 전담 기술지원팀과 컨설팅을 붙여주는 등 VIP 지원을 제공하는 경우가 많습니다. 또한 Oracle 제품에 익숙한 국내 파트너사들을 통해 솔루션 마이그레이션을 지원합니다. 다만 클라우드 네이티브 스타트업 커뮤니티에서 OCI 활용 사례는 드물어 개발자 사이 인지도는 낮은 편입니다.
• 약점: 글로벌 시장점유율 2~3% 내외로 추정될 만큼 IaaS 업계에서 영향력은 아직 제한적입니다. 따라서 AWS/Azure 대비 지원되는 서드파티 소프트웨어나 오픈소스 호환성 정보가 적을 수 있고, 커뮤니티 자료도 희소합니다. 또한 서비스 종류가 DB, ERP 주변 위주로 구성되어 범용 클라우드로서 서비스 다양성은 떨어진다는 평가가 있습니다. 국내 공공 인증의 경우 아직 획득 전이나, 향후 중등급 CSAP 인증을 목표로 정부 핵심 워크로드까지 수용 준비 중입니다. 엔터프라이즈 영역 외의 일반 웹/모바일 서비스 시장에서는 OCI를 채택해야 할 뚜렷한 차별점이 부족하다는 점도 한계로 지적됩니다.

2.5 네이버 클라우드 플랫폼 (NCP)

• 기술적 강점: 국내 사업자 중 **가장 다양한 클라우드 서비스(200여 종)**를 제공하며, **자체 AI 기술(HyperCLOVA 등)**과 네이버의 포털/커머스 플랫폼 노하우가 녹아있는 서비스들이 강점입니다. 예를 들어 AI API(음성인식, 번역 등 클로바 AI), 한글 OCR, 한글 챗봇 등 한국어 특화 AI 서비스를 클라우드 형태로 쉽게 사용할 수 있고, 게임사 대상으로 대용량 채팅/랭킹 서비스 등이 준비되어 있습니다. 국내 데이터센터 인프라도 강력해서 춘천 소재 ‘각 초대형 데이터센터’에 12만대 서버를 운영한 경험을 바탕으로, 세종에 친환경 컨셉의 두 번째 데이터센터를 가동하는 등 자체 IDC 역량이 뛰어납니다. 이로 인한 서비스 안정성과 빠른 국내 응답 속도도 장점입니다.
• 비용 및 지원: 가격 면에서 AWS 대비 20~30% 저렴한 서비스들이 많다고 알려져 있으며, 특히 국내 트래픽 비용이 무료라서 대용량 국내 사용자 서비스에 유리합니다. 초기 스타트업에게 크레딧을 제공하거나, 공공기관 전환 시 컨설팅을 무상 지원하는 등 공격적인 프로모션도 펼치고 있습니다. 고객지원은 한국어로 24시간 이루어지고, 기술문의에 대한 응답 시간이 빠르다는 평가입니다. 문제 발생 시 네이버 엔지니어가 직접 소통하며 대응하는 등 밀착 지원이 가능하고, 필요시 현장 방문도 이루어집니다.
• 공공/규제 대응: 네이버클라우드는 **금융 전용 존(Financial Cloud)**과 **공공 전용 클라우드(G-Cloud 인증)**을 별도로 운영하여 민감 데이터 보호에 만전을 기하고 있습니다. 2023년 한국은행, 한국수력원자력 등 주요 공공 프로젝트를 수주하며 국내 공공 클라우드 시장 점유율을 빠르게 높여 2023년에는 국내 공공기관 대상 매출 1위를 차지했다는 분석도 있습니다. 이러한 규제 대응력은 국내 최고 수준으로 평가됩니다.
• 약점: 글로벌 서비스 역량이 아직 제한적입니다. 해외 리전이 미주, 동남아 등에 일부 있고 중동 진출도 모색 중이나, 글로벌 커버리지는 AWS 등에 비해 한정적입니다. 따라서 한국 이용자가 주축인 서비스에는 적합하나, 다국적 사용자 대상 서비스에는 제약이 있습니다. 또한 에코시스템 규모가 글로벌 CSP 대비 작아 호환 솔루션이나 인력풀이 제한적일 수 있습니다. 예를 들어 NCP 사용 경험이 있는 개발자 수는 AWS 대비 적기 때문에 기업이 전문인력을 구하거나 트러블슈팅 정보를 찾는 데 어려움을 겪을 수 있습니다. 서비스 출시 속도 면에서도 AWS 신기능이 나오면 수개월 내 유사 서비스 출시를 따라가는 형국으로, 기술 선도보다는 빠른 추격자 역할에 머무르고 있습니다.

2.6 KT클라우드

• 기술적 강점: 국내 1세대 클라우드 사업자로 2010년대 초부터 퍼블릭 클라우드를 제공한 경험이 있습니다. 통신사 산하의 IDC 인프라를 활용하여 서울 가산, 목동, 김해 등 여러 지역에 데이터센터를 두고 광역 분산 구성으로 안정성을 확보했습니다. 통신망 운영 강점을 살려 클라우드와 MPLS 등 전용회선 연결 서비스를 쉽게 제공하고, 5G MEC(모바일 엣지 컴퓨팅)과 연계한 통신+클라우드 융합 서비스도 추진하는 등 네트워크 특화 클라우드로 차별화합니다.
• 기업 맞춤형 서비스: KT클라우드는 대기업이나 금융사 요구에 맞춘 **프라이빗 클라우드 구축 서비스(MSP 역할)**도 병행하며, 고객 전용 존, 전용선 연계, 온사이트 구축 등 유연한 커스터마이징을 제공합니다. 한편 GPU팜(GPU Farm) 서비스를 통해 AI 연산 자원을 대여하거나, 국내 소프트웨어(SaaS)들을 마켓플레이스에 입점시켜 원스톱으로 구매하도록 하는 등 국내 생태계 조성에도 힘쓰고 있습니다.
• 공공 부문: 과거 한국정보화진흥원(G-Cloud) 사업을 수행하는 등 공공기관 클라우드 전환 사업을 가장 많이 해온 사업자 중 하나입니다. 조달청 디지털서비스몰을 통해 다양한 공공 SaaS를 공급하며 공공 클라우드 전환 1단계 사업(2020~2021년)에 적극 참여했습니다. 국정원 보안 가이드 준수와 다수 공공 레퍼런스를 가지고 있어 전통적으로 정부 신뢰도가 높습니다.
• 약점: KT클라우드는 한때 기술 투자 정체로 서비스 혁신이 더디다는 평가를 받았습니다. 실제로 2021년 경 내부 시스템을 자체 클라우드에서 Azure로 옮길 정도로, 비용 효율성과 범용성 면에서 한계를 느꼈다는 사례가 있습니다. 이는 글로벌 CSP 대비 기술 서비스 다양성과 규모의 경제에서 뒤쳐진 결과로 분석됩니다. 현재 독립법인으로 분사하여 투자 여력을 확보하고 있으나, 개발자 커뮤니티 관심도나 신기술 도입 속도는 다소 낮은 편입니다. 또한 2022년 발생한 KT 통신망 장애 이슈 등으로 네트워크 안정성 이미지에 타격을 입은 점, 모회사 KT 구조개편 이슈 등 경영 불확실성도 단기 약점으로 지적됩니다.

2.7 NHN클라우드

• 기술적 강점: NHN클라우드는 한게임, 네이버 등 NHN이 오랫동안 인터넷 서비스 운영에 사용해온 **자체 클라우드 기술(OpenStack 기반)**을 외부 고객에 개방한 것으로 출발했습니다. 온라인 게임 및 웹서비스 트래픽 패턴을 잘 이해하고 있어, 게임사 대상 게임 플랫폼(Gamepot) 서비스, 대용량 채팅/메시징 서비스 등 특화 기능을 제공합니다. 또한 쿠폰 및 전자결제(Payment) 등 NHN Payco와 연계한 부가서비스도 제공하며, 올인원 비즈니스 플랫폼을 지향합니다.
• 공공 및 산업별 전략: NHN은 강원 춘천에 공공기관 전용 데이터센터(NHN TCC1)를 설립하여 지자체와 공기업 전산실을 유치하는 전략을 펼쳤고, 일부 지자체의 업무시스템을 민간클라우드로 이전하는 사업을 성공적으로 수행했습니다. 또한 게임 이외에 제조, 의료, 교육 분야별 솔루션(예: 스마트팩토리 플랫폼, 의료영상 클라우드 등)을 마련하여 특정 산업 고객에게 밀착 대응하는 모습입니다.
• 비용 및 지원: NHN클라우드는 요금 경쟁력 확보를 위해 탄력적 프로모션을 사용합니다. 예를 들어 신규 고객에게 수백만원 상당 크레딧 지급, 사용량 증가 시 요율 인하 등을 제시하며 시장 점유율을 높이려 하고 있습니다. 고객지원은 물론 한국어로 제공되고, NHN 자체 운영서비스 경험으로 장애 대응 능력이 뛰어나다는 평을 받습니다 (게임 서비스의 24/7 무중단 운영 경험 등).
• 약점: 회사 인지도 측면에서 NCP나 KT 대비 낮아 대형 고객사를 빠르게 확보하는 데 어려움이 있습니다. 실제 국내 클라우드 시장에서 NHN클라우드의 인프라 이용률은 7.0% 수준으로, 국내 CSP 3위권인 네이버(20.5%) 대비 낮습니다. 기능 면에서도 최근 컨테이너 서비스나 AI 등 신기능을 출시했으나 선두주자를 추격하는 수준이며, 글로벌 서비스 부재로 해외에 지사가 있는 기업이 선택하기에는 한계가 있습니다. 또한 모기업 NHN의 사업 구조상 게임/결제 등 특정 계열사 비즈니스에 집중되는 경향이 있어, 중립적 클라우드로 외부 고객이 바라보기엔 주저할 수 있다는 의견도 있습니다. 그럼에도 NHN은 국내 중견 기업과 공공시장에서 꾸준한 신뢰를 쌓아가고 있으며, 선택과 집중 전략으로 틈새 경쟁력을 확보하고 있습니다.

3. 시장 점유율, 성장률 및 경쟁력 평가

3.1 글로벌 시장 규모와 점유율 동향

글로벌 IaaS 시장은 계속된 두자릿수 성장세를 보이고 있습니다. Gartner에 따르면 2023년 전 세계 IaaS 시장 규모는 약 1,400억 달러로 전년(1,200억 달러) 대비 16.2% 성장했고, 2024년에는 약 1,718억 달러로 22.5% 성장한 것으로 집계되었습니다. 이 시장에서 상위 5대 CSP가 82% 이상의 점유율을 차지하는 구조가 고착되고 있으며, AWS, MS, Google 3강 체제가 굳건합니다. 2024년 기준 AWS는 매출 648억 달러로 37.7% 점유율을 기록해 1위를 유지했고, Microsoft는 **23.9%**로 격차를 좁히며 2위, Google은 **9.0%**로 3위를 차지했습니다. 그 뒤를 중국계 Aliyun(7.2%)과 Huawei Cloud(4.1%)가 이으며, 기타 사업자(Oracle, IBM 등 포함 전체)가 약 18%를 차지합니다. 이렇듯 상위 사업자들의 과점 현상은 뚜렷하며, “승자 독식” 경향이 강합니다. 이는 이들이 선점 효과와 막대한 인프라 투자로 기술·가격 경쟁력을 지속 강화한 결과이며, 신규 사업자가 이들의 규모를 따라잡기 어려운 구조적 특성이 작용한 것으로 분석됩니다. 다만 한편으로 클라우드 지출 증가율이 예년보다 다소 둔화되고 일부 지역에서 규제 이슈가 부각되면서, 수익성 확보와 지역별 전략 조정도 주요 과제가 되고 있습니다. 상위 사업자들은 생성형 AI 붐에 맞춰 GPU 인프라 투자를 크게 늘리며 향후 AI 최적화 클라우드로서 부가가치를 키우는 방향으로 경쟁력을 제고하고 있습니다. Gartner는 “IaaS는 모든 클라우드 영역(PaaS, SaaS 등)의 성장을 견인하는 조류”라 언급하며, AI 수요로 향후에도 고성장세가 지속될 것으로 전망했습니다

3.2 국내 클라우드 시장 현황과 점유율

국내 클라우드 인프라 시장 역시 빠르게 확대되고 있습니다. 한국IDC는 2024년 국내 클라우드 서비스(전체) 시장 규모가 전년 대비 19.2% 성장해 3조 원을 넘어설 것으로 전망하고 있습니다. IaaS 부문만 보면 연평균 20% 이상 고성장을 지속하여 2022년 약 4조 원 규모에서 2027년에는 7조~8조 원대에 이를 것으로 예측됩니다. 국내 IaaS 경쟁 구도를 살펴보면, 민간 시장에서는 AWS가 최대 점유율을 확보하고 있습니다. 과학기술정보통신부 조사에 따르면 국내 클라우드 이용 기업의 60.2%가 AWS를 사용하고 있어 가장 널리 활용되고 있으며, MS Azure가 24.0%, Google Cloud가 19.9%로 그 뒤를 잇고 있습니다. 국내 사업자 중에서는 Naver Cloud가 20.5%로 가장 높은 이용률을 보였고, 이어 KT Cloud 8.2%, NHN Cloud 7.0% 수준으로 파악되었습니다. 이처럼 국내 시장에서도 글로벌 사업자들이 1~2위를 차지하고 있지만, Naver Cloud는 유일하게 두자릿수 점유율을 기록하며 선전하고 있습니다. 실제 네이버클라우드의 매출은 2024년 약 1.4조 원으로 전년 대비 16.8% 성장하여 국내 퍼블릭 클라우드 사업자 중 가장 가파른 성장세를 보였습니다. 한편 KT클라우드는 2022년 분사 당시 투자 유치와 함께 “2026년 매출 2조 원” 목표를 내걸었으나, 목표 달성이 쉽지 않을 정도로 경쟁이 치열해진 상황입니다. NHN클라우드도 공공·금융 특화 전략으로 꾸준히 매출을 늘리고 있으나 전체 시장에서 차지하는 비중은 아직 한자릿수에 머무르고 있습니다.

공공시장 점유율을 따로 보면, 2023년 말 기준 공공 분야에서는 전통적으로 KT, Naver, NHN 세 곳이 3파전을 벌여왔고, 여기에 LG CNS, 카카오엔터프라이즈, 더존비즈온 등도 특정 영역에서 참여하는 구도였습니다. 하지만 2025년부터 AWS, Azure, GCP가 앞다퉈 정부 사업을 수주함에 따라 공공 점유 구도도 변화 조짐을 보이고 있습니다. 국내 클라우드 산업 경쟁력을 평가하면, 기술력과 서비스 폭에서는 글로벌 CSP 대비 아직 열세인 반면 공공 경험과 규제 대응력, 국내 고객 밀착지원 측면에서는 우위인 복합적 양상이었습니다. 정부도 한때는 국내 클라우드 육성을 위해 공공사업에서 해외 CSP 배제를 검토하기도 했지만, 현재는 개방과 경쟁 촉진 기조로 돌아선 만큼 국내 기업들도 글로벌 수준의 기술력 확보와 비용 효율화로 경쟁력을 높이는 데 주력하고 있습니다.

3.3 경쟁력 평가 및 향후 전망

종합하면, 글로벌 IaaS 시장은 AWS, Azure의 양강에 Google이 도전하는 구도로 굳어져 있고, 이들 상위사는 AI 열풍을 타고 투자여력을 더욱 확대하며 진입장벽을 높이는 추세입니다. Oracle, IBM 등 후발 글로벌 사업자들은 주로 자사 강점 분야(Oracle-DB, IBM-하이브리드클라우드 등)에서 틈새를 공략하며 특정 대기업 고객 위주로 니치 시장을 형성할 것으로 보입니다. 국내 시장에서는 AWS 등 글로벌사의 영향력이 압도적이지만, 데이터 주권, 고객 지원, 특화 서비스 요구로 인해 국내 CSP들의 존립 여지도 충분합니다. 특히 네이버클라우드는 AI와 글로벌 진출을 내세워 적극적으로 투자를 이어가고 있어 “2025년대에 국내 2위 사업자로 부상할 것”이라는 전망이 나오며, 일부 중동·동남아 국가와의 전략적 제휴를 통해 “제3의 클라우드” 입지를 노리고 있습니다. KT클라우드는 모회사 통신 인프라와 결합한 엣지 클라우드, 6G 시대 MEC 등을 미래먹거리로 삼아 차별화를 꾀하고 있고, NHN클라우드는 디지털 정부, 민간 SaaS협업 플랫폼 등에 집중하면서 선택과 집중 전략을 취하고 있습니다.

한편, 정부의 클라우드 전환 정책은 국내 시장 전체의 성장과 경쟁 구도를 크게 좌우할 요소입니다. 앞서 언급한 **공공 2.0 전환 전략(2027년까지 대부분 시스템 클라우드 이전)**이 차질없이 진행된다면 공공수요가 폭증하며 국내외 기업 모두에 새로운 기회가 열릴 것입니다. 이 과정에서 과도한 종속을 피하기 위해 멀티클라우드 전략이 확산되고, 이종 클라우드 간 상호운용성 표준이 중요해질 가능성이 큽니다. 실제 금융권 공동망을 Azure와 OCI로 동시에 구축한 사례에서 보듯, 한 기관이 여러 클라우드를 활용하는 추세는 앞으로 강화될 전망입니다 (설문에 따르면 국내 기업의 44.7%가 이미 멀티클라우드 활용 중). 따라서 각 사업자의 경쟁력은 단독으로 모든 서비스를 잘하기보다는 자사 강점을 극대화하면서 멀티클라우드 생태계에서 선택될 수 있는 매력을 키우는 방향으로 재편될 것으로 보입니다. 예컨대 AWS는 여전히 코어 인프라 플랫폼으로서 표준 지위를 공고히 하되, Azure/Oracle과의 협업으로 기업 애플리케이션 분야를 공략하고, 국내 CSP들은 공공기관 특화 클라우드나 국산 소프트웨어 생태계 허브로서 포지셔닝을 강화하는 식입니다.

결론적으로, 국내 IaaS 시장은 글로벌 거인들과 토종 업체들이 공존하며 경쟁하는 양상으로 발전하고 있습니다. 시장점유율 측면에서 글로벌 업체 우위는 당분간 지속되겠지만, 정부 정책 지원과 자체 혁신 노력 여하에 따라 국내 업체들도 특정 분야에서는 경쟁력을 확보할 수 있을 것입니다. 이용자 입장에서는 다양한 공급자 중 자신의 요구에 맞는 클라우드를 선택하거나 멀티클라우드로 최적 조합을 구성하는 전략이 중요해지고 있습니다. 향후 5년간 클라우드 시장의 고성장은 분명해 보이며, 그 속에서 기술 격차를 줄이고 서비스 혁신을 이어가는 업체만이 경쟁에서 살아남아 시장 판도를 주도할 것으로 예상됩니다.

4. 최신 공공시장 동향 및 조달 전략

정부의 클라우드 전환 정책: 2023년 정부는 '공공 클라우드 전환 2.0 전략'을 수립하고 2027년까지 중앙부처·지자체·공공기관의 핵심 정보시스템을 대폭 클라우드로 이전하기로 하였습니다. 이는 단순 인프라 이전을 넘어 행정 서비스 운영 방식 전반을 클라우드 중심으로 개편하는 ambitous한 계획으로, AI 기반 행정의사결정 지원, 민원 서비스 고도화 등도 포함된 디지털 혁신 프로젝트입니다. 이행을 위해 행안부는 공공 클라우드 통합센터 신설 및 부처별 데이터센터 통합을 검토하고, 신규 시스템은 원칙적으로 클라우드로 구축하도록 지침화했습니다. 2024년 관련 예산도 전년보다 증액된 5천억 원 규모로 편성될 전망으로, 정부가 클라우드 수요를 선도하고 있습니다. 이러한 움직임은 국내 클라우드 산업 전반의 성숙도 제고와 민간 영역 파급효과를 노린 것이며, 정부 관계자는 "공공이 움직이면 시장이 따라온다"며 공공 수요가 국내 클라우드 생태계 성장을 견인할 것이라고 밝혔습니다.

조달 체계 개선: 클라우드 확산을 가속화하기 위해 정부는 공공 클라우드 조달체계 혁신에도 나섰습니다. 행정안전부는 기존 나라장터와 별도로 디지털서비스 전문 계약제도(일명 K-클라우드 마켓)를 운영하여, 공공기관이 민간 클라우드 서비스를 보다 쉽게 구매할 수 있도록 절차를 간소화했습니다. 특히 SaaS 분야는 카탈로그 방식으로 인증 받은 서비스는 수의계약으로 신속히 도입할 수 있게 하여, 중소 소프트웨어 기업들의 공공 진입 문턱을 낮추고 있습니다. 또한 과기정통부는 클라우드 보안인증(CSAP) 등급제를 2023년 말 도입하여 낮은 보안등급 업무에 외국 CSP 활용을 허용함으로써 조달 선택지를 넓혔습니다. 이 과정에서 국정원은 공공기관용 별도 보안지침(N2SF)을 마련 중인데, CSAP와의 중복 규제를 해소하고 인증 절차를 일원화하여 기업들의 부담을 줄일 것으로 기대됩니다. 다만 국내 CSP들은 여전히 “보안 인증 취득 비용과 심사 기간이 큰 부담”이라 지적하며, 인증 절차의 추가 간소화와 조달 계약 방식 유연화를 요구하고 있습니다.

공공시장 경쟁 동향: 앞서 살핀 대로, AWS·MS·구글 등 글로벌 빅3가 공공 CSAP 인증을 확보하면서 클라우드 조달 시장의 경쟁 구도가 크게 바뀌고 있습니다. 예전에는 공공기관이 선택할 수 있는 민간클라우드가 국내사 위주로 한정됐지만, 이제는 성능이나 비용 면에서 우위를 보이는 글로벌 서비스를 적극 검토하는 분위기입니다. 실제 2023~2025년 사이 공공기관들의 클라우드 도입 사례를 보면, AI 연구, 빅데이터 분석 등 신규 프로젝트에는 해외 CSP를 활용해 보는 시도가 늘고 있습니다. 이에 대해 국내 업계는 **“보이지 않는 장벽이 허물어졌다”**며 위기감을 보이는 한편, 정부의 비관세 장벽 해소 압력 등 외부 요인도 영향을 미쳤다는 분석이 있습니다. 한편으로 정부는 디지털 주권 확보도 중요한 가치로 보고 있어, 공공 클라우드 전환을 국내 산업 경쟁력 강화와 연결짓고 있습니다. 이를 위해 민간클라우드 선순환 구조 (공공도입→민간확산)를 만들고, 국산 기술 기반을 키워 디지털 자립을 이루겠다는 정책 기조를 갖고 있습니다. 예를 들어 대민 서비스에 국산 AI를 적용하는 등 “국가대표 AI” 육성 프로젝트에 네이버클라우드 등이 참여하고 있고, 국가 초거대연구시설을 클라우드 형태로 개방하여 국내 기업들이 활용할 수 있게 하는 투자도 진행 중입니다.

조달 전략 제언: 이러한 흐름 속에서 각 클라우드 사업자는 맞춤형 조달 전략을 구사하고 있습니다. 국내 CSP들은 공공기관 요구에 맞춘 전담 조직 및 컨설팅 체계를 강화하고, 정부 주도 RFP에 적극 대응하는 한편, 전략적으로 해외 CSP와 협력하여 공공사업을 공동 수주하는 방안도 모색하고 있습니다. 예컨대 LG CNS 등 SI 업체와 클라우드 기업들이 컨소시엄을 구성해 사업에 참여하거나, 외국 CSP의 지역 파트너로 국내사가 운영을 대행하는 모델 등 공존 전략도 거론됩니다. 해외 CSP들은 한국 법인 내에 공공 전담 세일즈 팀을 꾸리고, 주요 부처에 대한 레퍼런스 확보를 위해 파일럿 프로젝트에 저가로 참여하거나 사회공헌형 클라우드 지원을 제공하기도 합니다. 또한 정부의 요구에 따라 국내 데이터센터 투자 및 일자리 창출 등 상생협력 방안을 함께 제시하며 우호적 인식을 높이는 전략도 펼칩니다.

결론적으로, 최신 공공시장 동향은 “개방과 경쟁, 그리고 전략적 협력”으로 요약되며, 조달 시장에서는 과거의 보호주의를 넘어 다양한 국내외 클라우드가 공정하게 경쟁하되 국내 산업 발전을 함께 도모하는 균형감 있는 접근이 시도되고 있습니다. 정부는 규제 합리화와 지원 정책을 병행하고, 기업들은 기술력 강화와 협업 모델 개발로 응답할 때, 국내 클라우드 산업이 글로벌 무대에서도 경쟁력을 갖춘 생태계로 성장할 수 있을 것으로 기대됩니다.

1. 웹사이트 및 교육예약 시스템 개발/운영 이력

설립 및 초기 구축: 한국수목원정원관리원(한수정)은 2017년 5월 설립되었으며, 이듬해 국립백두대간수목원(2018년)과 2020년 국립세종수목원을 개원하면서 기관 대표 웹사이트(koagi.or.kr)를 개설하여 대국민 서비스를 제공하기 시작했습니다. 초기 홈페이지는 수목원·정원 정보 제공, 공지사항/채용/보도자료 게시 등 기본 기능을 갖추었으며, 기관 설립 당시 외부 SI 업체에 위탁하여 구축된 것으로 보입니다 (※초기 구축 SI 업체는 공개 자료에서 확인되지 않음). 2021년 4월 법인 명칭이 “한국수목원관리원”에서 **“한국수목원정원관리원”**으로 변경되었고, 이에 따라 홈페이지도 명칭 변경에 맞춰 개편되었습니다.

교육예약 시스템: 한수정은 산하 수목원의 교육·체험 프로그램 예약을 위해 교육예약 시스템을 운영하고 있습니다. 이 시스템은 통합웹 내 “예약관리” 기능으로 제공되며, 국립백두대간수목원의 교육·숙박 프로그램 예약 및 안내, 국립세종수목원의 입장권 예매, 해설 프로그램 예약, 일반/전문교육 과정 신청 등을 온라인으로 처리합니다. 예를 들어, 백두대간수목원 방문객은 홈페이지에서 숙박형 교육프로그램을 예약할 수 있고, 세종수목원 방문객은 입장권 구매부터 정원해설사 프로그램 신청까지 한곳에서 이용할 수 있습니다. 이 교육예약 시스템은 수목원별로 분리 운영되던 예약 서비스를 하나로 통합한 것으로, 사용자 편의를 높이도록 설계되었습니다.

주요 기술 스택: KOAGI 홈페이지는 전자정부 표준프레임워크 기반의 콘텐츠 관리 시스템(CMS)을 사용하여 구축된 것으로 추정됩니다. 공공 웹사이트인 만큼 웹표준/웹접근성 준수, 반응형 웹 지원, 보안 (개인정보 보호 및 웹 취약점 대응) 요구사항을 충실히 반영하고 있습니다. 실제로 KOAGI 웹사이트는 다양한 브라우저/디바이스에서 접근 가능하고, CAPTCHA 등을 통한 보안 로그인, SSL 적용 등 정부기관 사이트의 표준을 따르고 있습니다. 또한 회원제 서비스(회원가입 및 로그인), 온라인 결제 연계(일부 유료 프로그램에 대한 결제), SNS 연동 등의 기능도 구현되어 있는데, 이는 전자정부 기반 CMS의 모듈을 활용한 것으로 보입니다.

운영 및 리뉴얼: 홈페이지와 예약 시스템의 운영은 외부 업체에 위탁하는 형태로 이루어져 왔습니다. 2022년 이후 현재까지 주식회사 **아이티룩스(ITLux)**가 한수정의 전산 인프라 및 포털 사이트 유지관리를 담당하고 있습니다. 2024년 기준으로 아이티룩스와 연간 유지보수 계약을 체결하여 시스템 안정화, 콘텐츠 업데이트, 보안 패치 등을 수행 중입니다. 웹사이트 개편은 수목원 개원 등에 맞춰 부분적으로 이뤄졌으며, 2025년에는 홈페이지와 예약관리시스템의 통합 리뉴얼 구축 사업이 추진되었습니다. 2025년 3월 한국수목원정원관리원은 “통합 홈페이지 및 예약관리시스템 구축” 입찰공고를 내고 전면적인 사이트 개편 작업을 진행하고 있는데, 이 프로젝트를 통해 기존 분리된 홈페이지와 교육예약 시스템을 하나의 통합 플랫폼으로 재구축하고 사용자 경험을 개선할 예정입니다. 해당 사업은 조달청 나라장터를 통해 발주되었으며(‘25.3월 공고), 2025년 하반기까지 새로운 통합 홈페이지가 완성될 것으로 예상됩니다.

2. 최근 5년간 SI 협력사 정보 (계약 현황)

KOAGI가 최근 5년(2021~2025년) 동안 계약한 주요 IT 서비스/SI 업체는 아래와 같습니다. 계약별 사업명, 기간, 계약금액 및 방식은 확인된 공개자료를 토대로 정리했습니다.

• 아이티룩스(ITLux) – “정보시스템 통합유지관리 용역”: 2022년 2월 15일 ~ 2022년 12월 31일 (이후 2023년, 2024년 연장) 한수정의 전산 인프라 및 홈페이지 유지보수를 수행. 2024년 계약기간은 1.1.~12.31.이며, 2025년에도 동일 업무를 수의계약 방식으로 연속 수행. 계약금액: 2025년도 유지관리 예산 10억3,905만 원(부가세 포함). 계약방식: 수의계약(총액) – 해당 용역은 한수정 정보시스템의 지속성 위해 기존 수행업체와 연속 계약(전자수의)된 것으로 보임. *(참고: 아이티룩스는 2021년 이전에는 계약 주체가 아니었으며, 2022년부터 유지보수 업체로 선정되었다고 추정됩니다.)
• (업체 미공개) – “KOAGI 통합 홈페이지 및 예약시스템 구축”: 2025년 사업, KOAGI 통합 홈페이지 리뉴얼 및 예약관리시스템 개발. 계약기간: 2025년 착수 ~ 2025년 말(expected). 예산: 사업계획 단계로 상세 금액 공개 자료 없음 (업계 유사 사례로 수억원 규모). 계약방식: 제한경쟁입찰(제안서 평가) 추정 – 2025년 3월 나라장터에 공고. (현재 입찰 진행 중이며, 낙찰자 정보는 미공개)
• 기타 시스템 사업: 이밖에 KOAGI는 자생식물 종자정보 구축 및 디지털 플랫폼 개발 등 IT 연관 사업에 외부 전문업체를 활용하고 있습니다. 예를 들어 “지능형 국립세종수목원 운영 통합플랫폼 구축” 사업은 2025년에 과학기술정보통신부/NIPA 지원으로 추진된 디지털트윈·AI 플랫폼 개발 프로젝트로, 공공시설물 안전 실증을 위한 3D 통합관제시스템을 외부 기술협력으로 구축했습니다. 해당 사업은 정부 지원금 10억원을 받아 수행되었으며, 전문 SI업체 컨소시엄이 참여한 것으로 보입니다 (구체적 참여업체 명칭은 공개 자료에 명시되지 않았음). 또한 2021~2025년에 걸쳐 추진 중인 “자생식물 종자정보 관리시스템(IP) 구축” 사업도 민간 IT업체 및 연구기관 협력을 통해 진행되고 있습니다. 이 사업은 국민참여예산으로 총 100억원을 투입하여 종자정보 데이터베이스와 공개 플랫폼을 구축하는 것이 목표이며, 2022년부터 본격적인 시스템 개발 단계에 돌입하였습니다. (※종자정보 시스템의 소프트웨어 개발 역시 외부 전문기업에 용역을 준 것으로 추정되나, 사업 자체가 연구개발 성격이라 단일 SI업체보다는 KOAGI 내부 연구인력+외부 개발인력이 함께 수행하는 형태입니다.)

※ 요약: 최근 5년 간 KOAGI의 핵심 IT 협력사는 아이티룩스로서, 홈페이지/전산 유지보수를 전담하고 있습니다. 신규 개발 사업의 경우 프로젝트별로 별도 발주되며, 2025년 통합 홈페이지 구축 사업 등이 진행 중입니다. 대규모 시스템 혁신 사업(종자정보 플랫폼, 디지털트윈 플랫폼)은 정부 예산을 받아 여러 업체와 협업하는 방식으로 추진되었습니다.

3. KOAGI 연도별 총사업 예산 및 매출 규모 (최근 5년)

한국수목원정원관리원의 연도별 총 예산(또는 매출에 준하는 운영수입) 현황은 아래와 같습니다. 공공기관 경영정보 공개(알리오) 자료에 따르면 2020년 이후 한수정의 수입 규모는 지속 증가 추세입니다.

• 2019년: (자료 없음) – 2019년은 기관 출범 초기 단계로, 국립백두대간수목원 운영 예산과 세종수목원 개원 준비비 등이 포함. 2020년에 비해 소폭 적은 수준으로 추정.
• 2020년: 약 4,480억 원 (결산 수익 44,805백만원) – 국립백두대간수목원 첫 해 운영เต็ม. 국비 운영비+초기 수입 등 포함.
• 2021년: 약 5,946억 원 (결산 수익 59,463백만원) – 전년 대비 33% 증가. 국립세종수목원 개원(’20년말)으로 운영예산 본격 반영.
• 2022년: 약 8,249억 원 (결산 수익 82,488백만원) – 세종수목원 연간 운영과 정원진흥 신규사업 확대 등으로 예산 확대.
• 2023년: 약 8,511억 원 (결산 수익 85,106백만원) – 전년과 유사한 수준 유지 (소폭 증가).
• 2024년: 약 8,500~8,600억 원 (결산 예상치) – 2024년 결산자료는 미공시이나, 2023년과 비슷한 규모로 추정.
• 2025년: (예산) 약 9,000억 원 내외 – 2025년 예산 총액은 공개 자료상 정확히 확인되지 않았으나, 전년 대비 증액 편성되었을 것으로 보임. 정부지원 증가 및 자체수입 확대 등을 반영.

참고: KOAGI는 기타공공기관으로서 정부 출연금(산림청 예산)과 자체 수입(입장료, 임대료 등)으로 운영됩니다. 2022년 매출액은 824억 원 규모로 발표되었으며, 2023년에도 851억 원 수준의 수익을 올린 것으로 나타납니다. 예산 구성은 국립수목원 운영관리, 정원진흥사업, 산림복원사업 3대 분야로 이루어지며, **국립수목원 운영·관리 예산 비중이 약 70%**로 가장 큽니다. 정원진흥 및 정원문화사업이 약 20%, 산림생물 보전·복원사업이 약 10% 정도를 차지하고 있습니다.

아래 표는 최근 년도별 한수정의 총 예산(매출) 규모를 요약한 것입니다:

(주: 상기 금액은 결산 기준 “수익(매출액)”이며, 억원 단위로 반올림 표기함.)

4. 연도별 IT 관련 사업 예산 및 비중

KOAGI 예산 가운데 정보화사업 및 IT 분야에 해당하는 항목을 살펴보면, 전체 예산 대비 비율은 크지 않지만 매년 꾸준한 투자가 이루어지고 있습니다. 주요 IT 관련 사업과 예산 규모는 아래와 같습니다:

• 홈페이지 및 시스템 유지보수: 한수정은 해마다 홈페이지·전산 시스템 유지관리 용역 예산을 편성하고 있습니다. 2025년의 정보시스템 통합유지관리 예산은 약 10.39억 원(약 10억4천만 원)으로 책정되었습니다. 이는 해당 연도 총예산의 약 1.2% 수준으로, 전산인력 파견, 서버/네트워크 운영, 보안관제 및 홈페이지 콘텐츠 유지보수 등을 모두 포함한 금액입니다. 2021~2024년에도 유사한 범위(연 8~10억 원대)의 유지보수 비용이 투입되었으며, 이는 외부 전문업체 계약(아이티룩스)으로 집행되었습니다. 해당 비용은 주로 국립수목원 운영·관리 예산의 일부로 계상되며, 기관 IT 인프라의 안정적 운영을 뒷받침합니다.
• 교육예약 시스템 운영: 교육예약 시스템 자체 개발/운영 예산은 별도로 크지 않게 편성되며, 주로 유지보수 범위 내 처리되고 있습니다. 다만 2025년 통합예약시스템 구축 사업 추진에 따라, 웹사이트 개편 예산 일부가 교육예약 시스템 기능 고도화에 사용될 예정입니다. 2025년 통합 홈페이지 구축 사업비가 수억원 규모로 추정되며, 이 중 예약시스템 통합 개발 비용이 포함됩니다. 이전까지는 교육예약 기능이 웹 유지보수 범위에서 관리되어 왔고, 필요 시 소규모 업그레이드 사업(예: 신규 프로그램 모듈 개발 등)이 추진되었습니다 (예산 수천만 원 수준, 수의계약 등으로 집행).
• 전산장비 및 인프라 투자: 한수정은 매년 노후 전산장비 교체, 서버 증설, 보안시스템 구입 등에 일정 예산을 배정합니다. 이는 경상경비 중 전산개발비/장비비 항목으로 편성되어 있으며, 연간 수억 원 내외입니다. 예를 들어 2023년에는 노후 PC 교체 및 네트워크 장비 업그레이드를 위해 약 1억 원대 예산을 집행했고(자료: 종합감사 결과보고서), 2024년에도 정보보안 강화 장비 도입 등에 유사한 규모의 예산이 투입되었습니다. 이러한 IT 인프라 예산은 전체 예산 대비 0.5% 미만으로 미미한 편입니다.
• 종합 정보화 사업 (신규 시스템 개발): 2021년부터 시작된 「자생식물 종자정보 빅데이터 구축 및 관리시스템 개발」 사업은 KOAGI의 핵심 IT사업입니다. 국민참여예산으로 5년간 총 100억 원(연평균 20억 원)을 지원받았으며, 2021년 기획/데이터 구축 1차년도 약 20억 원, 2022~2024년 시스템 개발 및 데이터베이스 구축 연간 20억 원씩 투입되고 있습니다. 이 예산은 산림생물다양성 보전 분야 사업예산의 상당 부분을 차지하며, KOAGI 연간 예산의 약 3~4% 수준에 해당합니다. 2021년에 748종의 종자정보 데이터 구축을 완료했고, 2022년부터 본격적인 종자정보 관리시스템(“씨앗피디아”) 개발에 착수하여 2025년 대국민 서비스 오픈을 목표로 하고 있습니다. 이처럼 종자정보 플랫폼 구축비는 한수정 IT예산 중 큰 비중을 차지하는 항목입니다.
• 스마트 플랫폼 및 기타 IT사업: 2023~2025년 동안 KOAGI는 스마트 수목원 통합플랫폼(디지털트윈) 구축에 참여하여, 2025년에 약 10억 원의 정부출연금을 지원받아 관련 시스템을 개발했습니다. 해당 사업비는 전액 정부과제 예산으로 편성되어 별도 관리되었으며, KOAGI 자체 예산 대비로는 약 1% 규모입니다. 또한 정원관광 활성화를 위한 정원산업 플랫폼 구상, 스마트가든 모니터링 등 소규모 파일럿 IT사업들도 추진되었는데, 이러한 사업들은 건당 수천만 원~1억 원 수준 예산으로 시범 운영되었습니다. 예를 들어 정원누리 정보제공 서비스나 반려식물 키트 온라인 플랫폼 등의 사업이 이에 해당하며, 모두 정원진흥사업 예산 내에 편성되었습니다.

요약하면, IT 관련 예산은 한수정 총예산의 5% 미만으로 비교적 적은 편이며, 주로 정보시스템 유지관리(약 1~2%), *데이터베이스/플랫폼 구축 등 전략사업(약 3% 내외)*에 집중되고 있습니다. 2022년 기준으로 보면, 연간 824억 원 예산 중 IT직접투자액은 약 20여억 원 수준으로 추산됩니다. 그러나 이러한 투자로 KOAGI는 종자 정보 개방 플랫폼, 디지털 스마트수목원 등 핵심 디지털 혁신과제들을 수행하고 있어, 기관 미션 대비 효율적인 예산 집행을 하고 있는 것으로 평가됩니다.

구매 시스템 기술 스택 및 구현

한국생산기술연구원(KITECH)은 2010년대 중반 전용 전자구매 시스템을 도입하였으며, 현대적인 웹 기반 아키텍처로 구축되었습니다. 프런트엔드는 웹 접근성과 크로스 브라우저 지원에 강점이 있는 AJAX 기반 RIA 프레임워크인 WebSquare를 사용하고 있습니다. 백엔드는 Java EE 플랫폼을 기반으로 개발되었으며, 초기(2010년경)에는 WebSquare와 함께 자체 Java 프레임워크인 ProWorks가 사용되었습니다.

이후 정부 IT 표준에 맞추어 전자정부 프레임워크(eGovFrame) 로 전환되었고, 특히 KITECH의 구매 시스템은 Java 8 + eGovFrame 3.8 환경에서 운영되는 것으로 알려져 있습니다. 이는 공공기관 개발 가이드라인을 준수하고 타 전자정부 시스템과의 상호운용성을 확보하기 위한 선택으로, 국내 공공기관에서 일반적으로 사용하는 Spring 기반 eGovFrame + WebSquare 조합과 동일한 구조입니다.

KITECH 전자조달시스템은 2015년경 본격 구축되었으며, 외부 SI 업체인 GS ITM이 개발을 수행했습니다. 이는 당시 공공 SI에서 일반적으로 사용되던 표준 아키텍처를 적용했음을 의미합니다. 실제 사례를 보면 KITECH의 「차세대 종합정보시스템」은 통합 포털, R&D 과제 관리, 협업, 경영정보 모듈 등을 WebSquare와 Java 프레임워크로 구현하였으며, 구매 모듈 역시 패키지 ERP가 아닌 맞춤형 개발 방식으로 구축되었습니다.

KITECH는 상용 MES/ERP 패키지의 높은 비용 문제를 인식하고, 효율성을 위해 자체 시스템 개발을 선호해왔다는 점도 공식적으로 언급한 바 있습니다.

2016년 3월에는 국가 전자조달 인프라인 나라장터와 연계한 전자입찰·전자계약 체계를 도입했습니다. 이는 KITECH 구매 시스템이 나라장터 API 또는 연계 모듈과 통신할 수 있도록 eGovFrame 기반으로 설계되었음을 의미합니다.
2024년에는 「2세대 전자조달시스템 구축」 사업을 착수하였으며, 이는 성능 및 UI/UX 개선을 위해 Java/eGovFrame의 상위 버전 도입 가능성을 포함한 플랫폼 고도화 프로젝트로 해석됩니다.

기술 스택 요약

• 프런트엔드: WebSquare
• 백엔드: Java EE (Java 8), eGovFrame 3.x
• 연계: 나라장터 전자입찰·전자계약 연계
• 운영 환경: 전자정부 표준 WAS/DB 구성

입찰 절차 및 계약 흐름

KITECH의 모든 구매는 국가계약법에 따라 공공 전자입찰 방식으로 진행되며, 입찰 제출은 전부 나라장터를 통해 수행됩니다. 2016년 이후 모든 입찰은 온라인 전자입찰로만 접수됩니다.

입찰 공고 및 참여

• 공고는 KITECH 홈페이지(알림마당 > 입찰구매) 및 나라장터에 동시 게시
• 제한경쟁 / 일반경쟁 / 협상에 의한 계약 방식 활용
• 제안요청서(RFP) 제공
• 입찰 참가 요건:
  • 나라장터 사전 등록 필수
  • 자격·면허·중소기업 제한 요건 등 명시
  • 국가계약법상 입찰 제한 업체 제외
  • 청렴계약, 이해충돌방지법 준수
  • 용역 계약의 경우 최저임금 준수 조항 포함

전자입찰 제출

• 모든 입찰은 나라장터 전자 제출
• 기술·가격 동시입찰 시:
  • 제안서(PDF) 업로드 + 가격 입력 필수
  • 제출 완료 여부는 나라장터 송신함에서 확인
• 제안서 파일 형식·용량 제한 명시(예: PDF, 300MB 이내)

평가 및 낙찰

• 최저가 입찰: 시스템 자동 개찰 후 낙찰자 선정
• 협상에 의한 계약:
  • 기술평가 → 가격 개찰 → 종합점수 산정
  • 기술점수 85% 이상 업체만 가격 평가 대상
  • 일반적으로 기술 80% + 가격 20%
• 평가 방식은 국가계약법 및 기재부 지침 준수
• 공동수급 불허 조건이 명시되는 경우가 많음

전자계약

• 낙찰 후 나라장터 전자계약 체결
• 공인인증서 기반 온라인 계약
• 통상 7~10일 이내 체결 필수
• 미체결 시 보증금 몰수 및 제재 가능

전체 흐름 요약
공고 → 전자입찰 → 마감 → 기술평가(해당 시) → 개찰 → 낙찰 → 전자계약

ERP 및 전사 시스템 운영

KITECH는 SAP·Oracle과 같은 상용 ERP를 사용하지 않고, 종합정보시스템(EIP 기반) 을 자체 개발·운영하고 있습니다.
2010년 차세대 종합정보시스템 사업(대우정보시스템 수행)을 통해 포털, R&D 관리, 성과관리, 협업, 행정 지원 시스템을 통합 구축했습니다.

이 시스템은 eGovFrame + WebSquare 기반의 맞춤형 전사 시스템으로, 재무·회계·자산·인사·연구관리 모듈을 포함합니다. 보안·인증·표준 구조 측면에서 전자정부 공통 프레임워크를 따릅니다.

운영 방식

• 주관 부서: 디지털정보혁신실
• 운영/유지보수: 외부 SI 업체 연간 계약
• 매년 유지보수·고도화 사업 발주
• 범위:
  • 헬프데스크
  • 장애 대응
  • 보안 패치
  • 경미한 기능 개선

내부 vs 외부 역할

• 내부: 기획·요건 정의·보안·감독
• 외부: 개발·운영·유지보수
• 대규모 개편은 별도 SI 프로젝트로 진행

주요 SI 업체 이력

• 대우정보시스템: 2010년 차세대 종합정보시스템 총괄
• 인스웨이브: WebSquare, ProWorks 기술 공급
• GS ITM: 2015년 전자조달시스템 구축
• 인터웹:
  • 2018~2023 종합정보시스템 유지보수
  • 2024 2세대 전자조달시스템 구축
  • 홈페이지 유지보수 수행
• 조인트리: 지식재산 관리 시스템 고도화

KITECH는 프로젝트 단위 계약 방식을 유지하며, 성과가 검증된 업체가 연속 수주하는 경향은 있으나 절차적 공정성은 유지됩니다.

SI 업계에서의 KITECH 평가

• 투명성: 나라장터 기반, 절차 명확
• 요건 명확성: RFP 품질 양호
• 대금 안정성: 정부 출연기관, 지급 리스크 없음
• 프로젝트 규모: 중소·중견 SI에 적합
• 도메인 난이도: 연구·공공 회계 이해 필요
• 혁신 성향: 전자계약, 디지털 전환 적극적
• 리스크: 대형 사고·분쟁 사례 없음

종합 평가
KITECH는 공공 SI 시장에서 안정적이고 예측 가능한 우량 발주처로 인식되며, 전자조달·종합정보시스템 구축 및 운영 경험을 쌓기 좋은 레퍼런스 기관으로 평가됩니다.

1. Any-ID SSO 솔루션의 주요 장점과 단점

장점 (기술 특성과 도입 이점):

• 사용자 편의성 향상: 한 번의 인증으로 여러 정부 웹사이트를 이용할 수 있어 로그인 절차의 반복을 제거합니다. 예를 들어 정부24에 로그인한 후 복지로 등 다른 사이트로 이동해도 추가 로그인 없이 서비스를 이용할 수 있습니다. 이는 다양한 기관 사이트마다 각각 로그인해야 했던 불편함을 해소합니다.
• 다양한 인증 수단 지원: Any-ID는 모바일 신분증, 간편인증(민간 인증서), 공동/금융인증서, 민간 ID 계정 등 총 5종의 인증수단을 표준화된 UI로 제공합니다. 국민은 본인이 편한 방식을 선택할 수 있어 접근성이 높고, 특정 인증방식 장애 시 다른 수단으로 대체할 수 있어 카카오 장애 등 한 인증수단에 대한 의존 위험을 줄입니다.
• 보안성과 표준화: 각 기관이 검증된 강력 인증수단(예: 공인된 인증서, 정부 발행 신분증 등)을 Any-ID 플랫폼을 통해 제공받으므로 전체적인 인증 보안 수준이 향상됩니다. 비밀번호 재사용을 줄이고 강력한 인증 하나로 통합하므로 비밀번호 관리 부담 감소 및 보안 강화 효과가 있습니다. 또한 기관별로 상이했던 인증 방식과 UI/UX를 통일하여 전자정부 서비스의 일관성을 높입니다.
• 중앙 관리 및 확장 용이: 공통 플랫폼으로 통합하여 인증 연계 정책을 중앙 관리할 수 있으므로 기관별로 개별 시스템을 운영하는 것보다 효율적입니다. 새로운 인증수단이 등장하면 Any-ID에만 연동하면 되어 각 기관이 별도 개발하지 않아도 되는 확장성도 장점으로 꼽힙니다. (예: 추후 모바일 주민등록증 등 신규 신분증이 나오면 Any-ID에 추가 연동하여 전체 서비스에 제공).

단점 및 제한점:

• 단일 장애점 및 연계 오류 위험: SSO 특성상 “마스터 키” 격인 인증 토큰이 유출되면 연계된 모든 서비스가 위험해질 수 있습니다. 즉, 한 계정 자격증명(ID/PW 등)이 탈취되면 여러 정부서비스에 동시 접근을 허용하게 되어 보안 리스크가 커집니다. 이러한 이유로 추가 다중인증(MFA) 등 보완이 필요합니다. 또한 중앙 Any-ID 시스템에 장애가 발생하면 다수 기관 서비스 로그인에 영향이 갈 수 있어 싱글 포인트 장애 우려가 있습니다.
• 인증수단 수준 차이에 따른 제약: Any-ID는 다양한 민간 인증을 통합하지만, 인증 등급에 따라 SSO 동작에 제한이 있습니다. 예를 들어 한국장학재단의 경우 보안등급이 낮은 *민간 ID(카카오, 네이버 등)*로 다른 기관에서 로그인한 사용자는 해당 SSO 세션을 받아들이지 않으며 재단 사이트에 다시 로그인해야 합니다. 오직 높은 등급의 인증수단(공동/금융인증서 등 2등급 이상)으로 로그인한 경우에만 SSO가 유지되어 기관 서비스를 이용할 수 있습니다. 이처럼 기관 보안정책에 따라 일부 인증수단으로는 완전한 SSO가 불가능하여 사용자 입장에서 일관된 경험이 저해될 수 있습니다.
• 초기 도입 및 연동 부담: Any-ID 사용을 위해서는 각 기관 홈페이지를 개편하여 SSO 연동 모듈을 적용해야 합니다. 표준 API나 SAML/OIDC 등을 통해 연계해야 하므로 기술적 역량이 필요하며, 기존 로그인 시스템과의 병행 운영, 사용자 전환 안내 등의 도입 과정 부담이 있습니다. 일부 신규 사용자에 대해서는 Any-ID 사용자등록 절차를 거쳐야 하고, 기관별로 추가 정보가 필요하면 별도 가입절차를 유지해야 하는 경우도 있습니다. (예: 큐넷은 자격시험 관련 고유 정보를 생성하기 위해 Any-ID 인증 후에도 자체 회원가입 정보를 입력받는 절차를 두고 있음.)
• 외부 서비스 의존성: Any-ID가 연계하는 민간 인증사업자들의 서비스 가용성에 의존하게 됩니다. 민간 인증 앱(네이버, 카카오 등)에 장애가 나면 해당 수단으로는 로그인 못하는 문제가 발생할 수 있지만, 행안부는 한 인증수단 장애 시 다른 방법을 선택할 수 있도록 여러 민간 로그인을 연계했다고 설명하고 있습니다. 그래도 각 민간 IdP와의 연동 오류 발생 시 책임 소재가 모호하거나, 장애 통보를 제때 받지 못해 대응이 지연될 수 있는 문제도 제기되었습니다. 이를 보완하기 위해 정부는 민간 플랫폼에 장애 발생시 정부에 통지 의무를 부과하는 등 제도 개선을 추진 중입니다.

2. 한국 공공기관에서의 Any-ID 적용 사례

행정안전부에 따르면 2025년 11월 기준 약 60개 공공 디지털정부 서비스에 Any-ID 통합인증이 적용되었습니다. 주요 기관과 활용 형태는 다음과 같습니다.

• 정부24 통합창구 (행정안전부): 전자정부 대표 포털인 정부24(현재 범정부 통합창구)에 Any-ID 로그인 기능이 도입되어, 한 번 로그인하면 연계된 여러 정부 서비스를 이동하면서 사용할 수 있습니다. 예를 들어 정부24에 Any-ID로 로그인 후 복지로(보건복지부 민원포털)로 넘어갈 때 추가 인증 없이 바로 민원 신청이 가능하게 되었습니다. 정부24를 시작으로 여러 기관 사이트가 Any-ID를 통한 싱글사인온 체계를 구현하였습니다.
• 대법원 가족관계등록 시스템: 사법부에서도 가족관계증명 등 발급 시스템에 Any-ID를 연계하였으며, 정부24와 함께 초기 시범 적용 기관 중 하나로 언급됩니다. 이를 통해 주민등록등본을 정부24에서 발급받은 후 가족관계증명서를 동일 세션으로 발급받는 등, 행정-사법 서비스 간 연계가 편리해졌습니다.
• 한국장학재단 (준정부기관): 2025년부터 장학재단 포털에 Any-ID 로그인이 도입되어, 학생들이 간편인증이나 인증서로 로그인할 수 있게 되었습니다. 다만 앞서 언급했듯 재단은 인증수단 등급에 따라 SSO 허용 여부를 정하고 있습니다. 1등급(모바일신분증)이나 2등급(공동/금융/간편인증)으로 로그인한 경우에는 Any-ID 세션을 유지한 채 재단 서비스를 이용할 수 있으나, 3등급 민간ID로 로그인한 세션은 받아들이지 않아 재단 사이트에서 다시 로그인해야 합니다. 이는 장학재단이 상대적으로 높은 수준의 본인확인을 요구하기 때문으로, 기관별 보안 정책에 따른 Any-ID 활용 차이를 보여주는 사례입니다.
• 큐넷(Q-Net) (한국산업인력공단): 국가기술자격 시험포털인 큐넷도 Any-ID 통합로그인을 지원합니다. 큐넷은 “정부통합로그인 사용” 토글 버튼을 제공하여, 이를 사용 상태로 둘 경우 큐넷에서 Any-ID로 로그인한 사용자는 다른 기관의 Any-ID 적용 사이트 이동 시 자동 로그인(SSO)이 유지됩니다. 해당 버튼을 “미사용”으로 전환하면 SSO 세션을 공유하지 않고 큐넷 개별 로그인만 사용하는 것으로 선택할 수도 있습니다. 이처럼 SSO On/Off 옵션을 두어 사용자가 통합로그인 여부를 결정하도록 한 것이 특징입니다. 또한 신규 회원의 경우 앞서 FAQ에서 언급된 것처럼 Any-ID 인증 후에도 큐넷 고유정보 입력을 위한 회원가입 단계가 추가됩니다.
• 그 외 적용 기관: 경찰청, 국민권익위원회, 국토교통부, 농림축산식품부, 식품의약품안전처 등 다수 기관의 온라인 민원·서비스 사이트에 단계적으로 Any-ID가 연결되고 있습니다. 예컨대 경찰청 교통민원 사이트나 권익위 국민신문고 등에서 Any-ID 버튼을 통해 민간 인증서로 로그인하고, 연계된 다른 정부 서비스에 재인증 없이 이동하는 식입니다. 2025년 현재 전자정부 법령 개정을 통해 Any-ID를 공식 본인확인 수단에 포함시킨 만큼, 향후 더 많은 기관에 확대 도입되어 범정부 통합 인증체계로 자리잡을 전망입니다.

3. Any-ID 구축 방식: 중계형 vs 설치형 비교

Any-ID 통합인증 플랫폼은 기관별 환경에 따라 두 가지 구축 방식으로 도입 가능합니다. 하나는 행안부 또는 공급업체의 클라우드 중계 서버를 통해 서비스를 연계하는 중계형(SaaS) 방식이고, 다른 하나는 기관 내부에 소프트웨어를 직접 설치하여 운영하는 설치형(On-Premise) 방식입니다. 아래 표에 두 방식의 특징을 비교합니다:

주: 일반적으로 중소규모 기관이나 신속 도입을 원하는 경우 중계형을 택하며, 월간 수백만 건 이상의 대량 인증을 처리하거나 폐쇄망 등 자체 운용 환경이 필요한 경우 설치형을 선택하는 경향이 있습니다. 중계형은 모듈 설치 없이 계약 한 번으로 다양한 민간인증과 신분증 서비스를 모두 이용할 수 있어 연동 편의성과 비용 절감 효과가 크다는 평가입니다. 반면 설치형은 초기에 비용과 시간이 더 들지만 기관별 요구에 맞춘 안정성 확보와 시스템 통제력 측면에서 유리합니다. 두 방식 모두 Any-ID의 핵심 기능은 동일하며, 기관 여건에 따라 선택 도입이 가능하도록 준비되어 있습니다

1. 기능 설계 방식

공공 SI 프로젝트에서는 요구사항 정의와 기능 설계를 체계적으로 진행합니다. 먼저 사업 제안요청서(RFP)와 이해관계자 인터뷰 등을 통해 요구사항을 수집하고 분석합니다. 수집된 요구를 명확히 정리한 요구사항 명세서를 작성하며, 여기에 시스템의 목표, 범위, 제약, 그리고 자료흐름도(DFD), 프로세스 명세서, ERD(Entity-Relationship Diagram) 같은 산출물이 포함됩니다. 이 명세서는 개발자뿐 아니라 모든 이해관계자의 합의를 거쳐 확정되며, 이후 설계∙구현의 기준이 됩니다.

요구사항 명세서의 핵심은 기능 명세서로, 최종 시스템이 어떤 기능을 어떻게 수행하는지를 사용자 관점에서 상세히 기술한 문서입니다. 기능 명세서에는 화면 설계, 입력/출력, 업무 흐름 등이 서술되며 내부 구현이나 기술적 솔루션 내용은 배제합니다. 즉 “이 시스템이 완성되면 사용자가 무엇을 할 수 있고 어떻게 동작하는지”를 명확히 적시하며, 최종 사용자 승인을 받은 문서로 활용됩니다. 기능 명세서만 충실해도 사용자가 원하는 소프트웨어를 만들 수 있고, 추후 분쟁 시에도 명세서에 근거하여 해결할 수 있습니다.

설계 단계에서는 기능 모듈 구조도 정의합니다. 전체 시스템을 주요 업무 영역별 대분류-중분류-세부기능으로 계층화하여 기능 목록을 작성하고, 화면 설계서(와이어프레임)와 메뉴 구조도를 산출합니다. 예를 들어 공공 사업 제안서 가이드에서는 기능 목록표를 작성하여 Level 3 수준의 기능을 요구사항 단위로 나열하도록 권장하고 있습니다. 각 세부 기능마다 등록/조회/수정/삭제 등 필요한 동작과 입력∙출력 요소를 정의해 기능 명세에 반영합니다. 또한 사용자 시나리오나 유스케이스를 통해 기능 간 연계를 검토하고, 필요한 경우 프로토타입을 제작해 이해관계자의 피드백을 받습니다. 이러한 과정을 거쳐 기본설계서와 상세설계서가 작성되며, 여기에는 데이터 모델, 인터페이스 설계, 화면 UI 설계 등이 포함됩니다. 모든 기능 설계 산출물은 「소프트웨어 개발방법론」 절차에 따라 검토∙승인되며, 공공사업의 경우 산출물 표준양식에 맞춰 제출됩니다.

2. 보안 요구사항

대한민국 공공기관의 시스템 설계에는 보안 요구사항이 중요하게 반영됩니다. 개인정보보호법과 전자정부법 등 관련 법령에 따라 개인정보와 시스템을 보호하기 위한 설계 상의 고려사항이 다수 존재합니다. 대표적으로 개인정보 안전조치 측면에서 민감정보의 암호화와 접근통제가 설계 단계부터 요구됩니다. 예를 들어 주민등록번호 등 고유식별정보는 DB에 저장할 때 안전한 알고리즘으로 암호화해야 하며, 설계 시 이에 대한 데이터 암호화 모듈을 포함시킵니다. 또한 개인정보 수집은 서비스 목적상 최소한으로 설계하고, 이용 목적이 지난 데이터는 지체 없이 파기될 수 있도록 개인정보 생명주기를 고려합니다. 대규모 개인정보를 처리하는 정보시스템의 경우 **개인정보 영향평가(PIA)**를 통해 설계 단계부터 위험요소를 분석하고 개선방안을 적용합니다. 한국가스공사 등 공공기관들은 이러한 노력으로 개인정보 보호수준 평가에서 최고 등급(S등급)을 받을 만큼 체계적인 보호체계를 구축하고 있으며, 국제표준 ISO 27001/27701 인증까지 취득하여 개인정보∙정보보안 관리체계를 유지합니다.

소프트웨어 개발보안 요구사항도 필수입니다. 행정안전부의 「행정기관 및 공공기관 정보시스템 구축‧운영 지침」 및 관련 법령에서는 설계 단계에서 입력 데이터 검증 및 표현, 인증 및 세션 관리, 암호화 처리, 예외 및 오류처리 등 항목을 포함한 보안 설계 기준을 명시하고 있습니다. 이는 OWASP Top 10 등을 반영한 8대 보안약점 유형(입력검증, 보안기능, 시간및상태, 에러처리, 코드오류, 캡슐화, API오용, 기타)을 고려하여 총 47개의 세부 보안약점을 예방하도록 한 것입니다. 예를 들어 SQL 인젝션 방지를 위해 입력값 필터링/검증 로직을 설계하고, 크로스사이트스크립팅(XSS) 방지를 위해 출력시 특수문자 이스케이프 처리를 적용하는 식입니다. 이러한 개발보안 요소는 분석 단계부터 식별되어야 하며, 설계∙구현 시 발생 가능한 위협을 최소화할 수 있도록 반영해야 합니다. 이후 테스트 단계에서는 소스코드 보안약점 진단과 모의해킹 등을 통해 설계된 보안 요구사항이 제대로 구현되었는지 검증합니다.

인증 및 권한설계도 보안의 핵심입니다. 사용자 인증 방식은 아래 인증체계 항목에서 다루지만, 설계 관점에서는 다중 인증체계(MFA) 적용과 세션관리, 권한분리(Least Privilege) 등이 고려됩니다. 예를 들어 행정시스템에는 내부 사용자도 SSO + OTP 같은 2차 인증을 적용하고, 권한에 따라 접근 가능한 기능을 제한하도록 설계합니다. 접속기록 감사(Log) 기능도 설계에 포함되어 관리자에게 이상 행위를 경고하고 추적할 수 있게 합니다. 한국가스공사는 매월 개인정보처리시스템 접속기록을 점검하고 불필요한 계정을 말소하는 등 접근권한 관리체계를 운영하고 있는데, 이러한 절차 역시 설계 시점부터 로그 테이블과 감사 모듈 설계로 구현 기반을 마련합니다.

**망분리(Network Segregation)**도 공공기관 보안설계의 특징입니다. 내부 업무망과 외부 인터넷망을 물리적 또는 논리적으로 분리하여 중요 정보자산을 보호하는 구조를 채택합니다. 예를 들어 외부에서 접속하는 웹서버는 DMZ 망에 두고, 주민정보 등 데이터베이스 서버는 내부망에 둬서 직접 인터넷에 노출되지 않도록 설계합니다. 필요 시 데이터 교환 게이트웨이나 전용 연계망을 통해서만 내부망과 외부망이 소통하게 합니다. 이러한 망분리 정책 덕분에, 한국가스공사는 생성형 AI 플랫폼도 인터넷이 아닌 내부망 환경에서 구축하여 사용하고 있습니다. 내부 업무자료는 사내 전용 AI모델로만 처리하고, 외부 정보 활용이 필요할 때만 검증된 상용모델(API)을 쓰도록 이원화 설계한 것입니다. 이처럼 망분리와 보안설계 원칙을 지켜 시스템을 구축하면, 사이버 침해사고의 위험을 크게 줄이고도 사용자 편의와 혁신 기능을 제공할 수 있습니다.

마지막으로, 보안 솔루션 및 인증기준도 고려됩니다. 공공기관은 중요 보안제품 사용 시 국제공통평가기준(CC) 인증 등을 충족한 제품을 도입해야 합니다. 실제로 2017년 8월부터 국가∙공공기관은 SSO 같은 보안솔루션 도입 시 CC인증 획득 제품을 사용하도록 의무화되었고, DB암호화 솔루션 등도 검증필 암호모듈 적용이 요구됩니다. 또한 대부분의 중앙행정기관 및 공공기관은 정보보호관리체계(ISMS) 인증이나 ISMS-P 인증을 받아야 하므로, 이에 부합하도록 관리적∙물리적∙기술적 보안 controls를 설계에 반영합니다. 예를 들어 세션 타임아웃, 비밀번호 복잡도 정책, 관리자 권한 분리, 백업 및 복구체계, 보안패치 적용계획 등까지 설계 문서에 포함시키고 추후 운영에 반영합니다. 이처럼 공공 SI에서는 법적 규정과 정책기준에 따른 보안 요구사항을 처음부터 꼼꼼히 녹여내어 Secure by Design을 실현합니다.

3. 인증체계

공공기관 시스템에서는 다양한 사용자 인증방식이 활용되며, 사용자 편의와 보안수준에 따라 적절한 인증체계를 설계합니다. 주요 인증 방식과 적용 사례는 다음과 같습니다:

• 공공 I-PIN: I-PIN(Internet Personal Identification Number)은 주민등록번호를 대체하여 인터넷 상에서 개인을 식별하는 ID입니다. 공공 I-PIN은 정부가 주관하는 아이핀으로, 본인확인을 거쳐 발급받은 I-PIN ID와 패스워드를 사용해 여러 웹사이트에서 본인인증에 활용할 수 있습니다. 예를 들어 정부 민원포털, 지방자치단체 홈페이지 등에서 회원가입이나 민원 신청 시 주민번호 대신 I-PIN 인증을 요구하기도 합니다. I-PIN은 한 개의 아이디로 여러 기관에서 쓸 수 있도록 통합되어 있어, 주민번호 노출 위험을 낮추고 미성년자도 휴대폰 없이 발급받아 사용할 수 있다는 장점이 있습니다. 다만 최근에는 휴대폰 인증 등 간편인증 수단이 보편화되면서 I-PIN 사용률은 예전보다 줄었지만, 법적으로 대체수단으로 여전히 제공되고 있습니다.
• 공동 인증서: 과거 공인인증서로 불리던 공동인증서는 오랜 기간 공공 웹서비스의 기본 인증수단이었습니다. 사용자가 PC나 스마트폰에 인증서(전자서명 키쌍)를 저장하고 패스워드로 인증하는 방식으로, 전자정부 서비스 로그인, 전자민원 신청, 전자계약 등에 폭넓게 활용됩니다. 2020년 전자서명법 개정으로 공인인증서 독점체제가 폐지되면서 공동인증서로 명칭이 바뀌고 민간 인증서와 경쟁하는 구도가 되었습니다. 그럼에도 현재도 정부24, 홈택스, 나라장터 같은 주요 공공서비스에는 공동인증서 로그인 옵션이 기본 제공됩니다. 공동인증서는 PKI 기반으로 전자서명 기능도 있어, 민원 문서 제출이나 금융결제, 내부결재 시스템에서 서명/인가 용도로 쓰입니다. 구현 측면에서 서버는 인증서의 유효성 검증(OCSP 또는 CRL), 전자서명 검증 모듈을 가져야 하며, 사용자는 키보드 보안 또는 암호화 모듈(예: PKCS#11 모듈)을 설치해야 해서 과거 ActiveX 의존 이슈가 있었지만, 최근엔 웹표준 기술로 개선되고 있습니다. 설계시에는 인증서 로그인 외에 OTP나 SMS인증 등을 추가 제공하여 사용자 편의를 높이고자 하는 추세입니다.
• 디지털 원패스 및 SSO: 여러 공공서비스를 하나의 계정으로 이용할 수 있는 통합 인증(SSO) 체계도 확산되고 있습니다. 행정안전부는 시민들이 각 기관마다 별도 회원가입 없이 하나의 ID로 서비스들을 이용하도록 디지털 원패스(One Pass)라는 통합인증 서비스를 운영 중입니다. 이용자는 지문/안면 등 생체인증이나 공동인증서, 간편인증(민간 인증서) 등을 원패스에 연계시켜 두면, 정부24나 국민신문고, 복지로 등의 사이트에 원패스로 로그인하여 SSO 방식으로 연계 서비스들을 이용할 수 있습니다. 기관 내부적으로는, 직원들이 여러 업무시스템을 한 번 로그인으로 이용하도록 사내 SSO를 구축하는 경우가 많습니다. 예를 들어 한국기초과학지원연구원(KBSI)은 그룹웨어, MIS, 전자결재 등 10여 개 내부시스템에 단일 로그인으로 접근하는 SSO 시스템을 도입했고, 여기에 구글 OTP 기반 2차 인증까지 붙여 보안성과 편의성을 동시에 높였습니다. 공공기관 SSO 솔루션은 SAML이나 OAuth2 기반으로 구현되며, 세션 통합과 사용자 디렉토리(예: LDAP) 연동을 포함합니다. 정부기관에서 SSO 솔루션 도입 시에는 앞서 언급한 CC인증 제품을 선정하여 구축하며, 로그인 계정 관리를 중앙화함으로써 사용자의 비밀번호 관리부담 감소와 접근통제 일원화 효과를 거두고 있습니다.
• OAuth2 및 간편인증: OAuth2.0는 주로 소셜 로그인이나 외부 API 연동에 사용되는 개방형 인증 프로토콜입니다. 공공 분야에서도 국민 편의를 위해 카카오, 네이버, 페이코 등의 간편인증을 일부 서비스에 도입하고 있습니다. 예를 들어 일부 지자체 주민참여포털에서는 카카오톡 간편로그인(OAuth2 기반)을 제공하고, 정부 데이터개방 API에서는 앱 인증에 OAuth 토큰을 사용하기도 합니다. OAuth2는 리소스 소유자의 자격증명을 직접 다루지 않고 엑세스 토큰을 통해 권한을 위임하는 방식이라, 외부 서비스와 연계 로그인을 구현할 때 유용합니다. 다만 보안상 세밀한 통제가 필요해, 공공기관에서는 OAuth를 자체 사용자 인증보다는 제3자 데이터 제공 동의나 소셜 계정 연동 용도로 제한적으로 활용합니다. 최근에는 **OpenID Connect(OIDC)**를 활용해 OAuth2 위에 ID토큰을 주고받음으로써 보다 표준화된 SSO를 구현하기도 합니다. 향후 마이데이터 등 범정부 연계 서비스에서도 이용자 인증과 권한위임을 위해 OAuth2 기반의 인증체계가 쓰일 전망입니다.
• 기타 인증수단: 이 외에도 공공기관에서는 필요에 따라 스마트폰 본인확인(휴대폰 인증), 보안토큰(일회용 패스워드 카드), 생체인증(FIDO) 등을 도입합니다. 특히 모바일 정부앱이나 키오스크 단말에서는 지문인식이나 얼굴인식 등 생체인증이 활발히 사용되고 있습니다. 또한 시스템 간 연계를 위한 서버 대 서버 인증에는 공공기관 공통의 **GPKI 인증서(행정전자서명)**를 활용하는 경우도 있습니다. 예컨대 행정기관 시스템끼리 자료를 주고받을 때는 클라이언트 인증서로 GPKI를 사용하여 상호 신원을 확인합니다. 신규 시스템 설계 시에는 이런 다양한 인증 수단을 고려해 멀티채널 인증 모듈을 구성하고, 인증서버 또는 OAuth2 인증 서버 등을 인프라에 포함시켜야 합니다. 요약하면, 공공 SI에서는 사용자군과 보안 수준에 맞춰 I-PIN, 공동인증서, SSO, OAuth2 등 적절한 인증방식을 선택하며, 종종 복합적으로 지원하도록 설계하여 보안성과 편의성의 균형을 도모합니다.

4. 연계 방식

공공기관 시스템은 다른 기관 및 내부 타 시스템과의 **연계(Integration)**가 빈번합니다. 설계시 연계 요구사항을 고려하여 적절한 방법을 선택하게 되는데, 일반적으로 다음과 같은 연계 방식들이 활용됩니다:

• DB to DB 직접 연계: 가장 단순한 형태로, 한 시스템에서 다른 시스템의 데이터베이스에 직접 연결하여 필요한 데이터를 조회/조작하는 방식입니다. 예를 들어 기관 A의 시스템이 기관 B DB의 뷰(View)나 DB Link를 통해 SELECT 쿼리를 실행하는 식입니다. 과거 레거시 환경에서는 부처 간 실시간 연계를 DB링크로 구현한 사례가 있으며, 구현이 비교적 간단하지만 보안상 취약하고 종속성이 커 잘 쓰이지 않습니다. 대신 같은 기관 내부의 하위 시스템들 간에는 직접 DB연계나 공유 DB를 쓰는 경우도 있습니다.
• 파일 연계(배치): 일정 주기마다 데이터를 **파일(CSV, XML 등)**로 생성하여 공유 디렉토리나 SFTP로 전송하고, 수신 시스템이 이를 받아 import하는 배치(batch) 방식입니다. 예를 들어 매일 밤 이용통계 정보를 추출한 CSV 파일을 다른 시스템으로 전달해 집계하는 경우입니다. 이 방식은 시스템 간 결합도를 낮추고 일괄 대용량 전송에 유리하지만, 실시간성이 부족하고 오류 발생 시 재처리가 번거롭습니다. 공공기관 간 예산정산, 통계자료 교환 등에 아직도 활용되며, ETL 도구나 배치 스케줄러로 관리됩니다.
• 웹서비스 API (SOAP/REST): 가장 일반화된 연계 방식으로, API 인터페이스를 정하여 실시간 호출로 데이터를 주고받는 방법입니다. 과거에는 SOAP 기반 웹서비스(WSDL 제공)를 많이 사용했고, 현재는 RESTful API(JSON/HTTP 기반)를 선호합니다. 한쪽 시스템이 Open API 서버를 제공하고, 다른 쪽이 HTTP 요청으로 데이터를 요청/송신하는 구조입니다. 이 경우 인터페이스 명세서에 요청URL, 메시지 구조, 인증 방식(API Key, OAuth 토큰 등) 등을 정의합니다. G2B 나라장터 연계나 행안부 주민정보 공동이용 연계 등은 현재 Open API 방식으로 제공되고 있습니다. 예를 들면 조달청 나라장터는 공공데이터포털(data.go.kr)에 오픈API를 공개하여, 개발자가 활용신청을 통해 발급받은 키로 입찰공고정보 등을 실시간 조회할 수 있습니다. API 연계의 장점은 실시간성과 표준화이며, 정부기관에서는 REST API 가이드라인을 만들어 JSON 형식과 HTTP상태코드 규약 등을 정해두고 있습니다. 설계 시에는 인터페이스 요구사항으로 어떤 시스템과 어떤 데이터 항목을 API로 주고받을지, 보안은 어떻게 할지를 상세하게 명시합니다. 또한 호출 부하 대비를 위해 API Gateway나 스로틀링(throttling), 인증/권한체계를 함께 설계합니다. 한 발전공기업 사례에서는, 기존에 내부 파일시스템으로 처리하던 연계를 RESTful OpenAPI로 전환하고 API Gateway를 도입하여 데이터 접근성을 높이고 보안을 강화했습니다. 이러한 API 중심 구조는 디지털 플랫폼 정부 구현 추세와 맞물려 더욱 확대되고 있습니다.
• EAI/ESB 기반 연계: 여러 이기종 시스템을 허브/버스를 통해 통합하는 미들웨어 연계 방식입니다. **EAI(Enterprise Application Integration)**는 기업 내 다양한 애플리케이션을 어댑터로 연결해 중앙 허브에서 데이터 변환·중계하는 방식이고, **ESB(Enterprise Service Bus)**는 이를 발전시켜 버스 구조로 서비스 단위의 메시지 송수신을 지원하는 아키텍처입니다. 공공기관에서도 2000년대 후반부터 대규모 정보화사업에 EAI/ESB 솔루션을 많이 도입했습니다. 예컨대 지방자치단체 통합징수정보시스템은 건강보험공단, 국민연금공단 등과의 데이터를 표준화된 ESB 솔루션으로 연계하여, 서로 다른 기관 간 부과·징수 정보를 교환했습니다. EAI/ESB의 장점은 유연한 확장성과 메시지 신뢰성으로, 새로운 시스템이 추가되어도 허브에 어댑터만 붙이면 되고, 큐잉 등을 통해 안정적인 비동기 연계가 가능합니다. 설계 시에는 연계 대상 시스템별 연계 어댑터 개발과 공통데이터표준 정의, 메시지 큐 구성 등을 상세히 기술합니다. 다만 초기 구축비용이 크고 운영 복잡도가 있어서, 요즘은 경량화된 API Gateway나 iPaaS(integration Platform as a Service)로 대체되는 추세입니다. 실제 공공기관 사례를 보면, 행정안전부가 행정정보공동이용센터 등 범정부 연계사업에서 수백 개 기관과의 연계를 ESB 기반 플랫폼으로 구축·운영해 왔습니다. 이러한 ESB 시스템은 기관 간 표준 데이터 포맷(XML)과 전용 망을 통해 주민정보, 복지정보 등을 주고받도록 설계되어 있습니다.
• 공공 데이터 개방 및 외부 연계: 최근에는 기관 내부 연계뿐 아니라, 대외 개방 데이터를 제공하거나 외부 데이터 활용을 연계하는 경우도 많습니다. 공공데이터포털을 통한 오픈API 제공이 대표적이며, 각 기관의 데이터베이스를 API로 개발해 포털에 등록하면 다른 기관이나 국민이 활용할 수 있게 됩니다. 예를 들어 기상청의 날씨 정보 API, 국토부의 교통정보 API 등이 있고, 이러한 오픈API를 개발할 때는 데이터 표준, 보안인증, 트래픽 관리까지 고려하여 설계합니다. 또한 민간 기업 시스템과의 연계도 늘어나고 있어, 예컨대 은행과 연계한 지방세 납부 시스템, 우정국과 연계한 주소 검증 서비스 등이 API로 구현되고 있습니다. 이 경우 OAuth2.0 등의 프로토콜로 제3자 연동에 대한 인증·인가를 수행하며, API이용 계약에 따른 QoS 제한도 설계에 반영됩니다.

요약하면, 공공 SI 프로젝트에서는 연계 요구사항에 따라 API, EAI/ESB, 파일, DB Link 등 최적의 방식을 선택하며, 하나의 사업에서도 상황에 맞게 혼합 사용하기도 합니다. 실제 입찰 제안요청서에서도 연계 방식란에 *“API/ESB/DB링크/EAI 등”*으로 가능 방식을 열거하고 협의하도록 명시하는 사례가 있습니다. 설계자는 각 연계 방식의 장단점, 실시간성 요구, 보안수준, 데이터 양 등을 고려해 결정하며, 관련 인터페이스 명세와 시험 계획도 함께 수립합니다.

5. 시스템 아키텍처

공공기관 SI에서는 안정성과 확장성을 위해 검증된 아키텍처 패턴을 적용합니다. 전통적으로는 3-Tier 구조가 보편적이며, 최근에는 **마이크로서비스 아키텍처(MSA)**도 도입되는 추세입니다. 주요 아키텍처 구성과 배포∙이중화 방안을 정리하면 다음과 같습니다:

• 3-Tier (계층형) 아키텍처: 프레젠테이션(웹) 계층, 애플리케이션(WAS) 계층, 데이터베이스 계층으로 분리된 3계층 구조를 채택하는 경우가 대부분입니다. 클라이언트의 요청은 Web 서버를 거쳐 WAS에서 비즈니스 로직을 수행하고 DB에 접근하는 형태로, 계층 간 역할분리를 통해 개발과 운영의 효율성을 높입니다. 전자정부 표준프레임워크 기반 시스템이 이 구조이며, Spring MVC를 이용한 Controller-Service-DAO 레이어로 논리적인 3계층을 구현합니다. 3-Tier 구조는 서버 증설을 통한 확장성이 좋고, 한 계층의 변경이 다른 계층에 미치는 영향을 줄여 유지보수성이 높습니다. 공공기관 대부분의 행정업무시스템(인사, 재무, 민원 등)이 이 전형적인 3계층 웹 구조로 설계되어 있으며, 발표계 환경에서는 Web/WAS/DB를 각각 개별 서버군으로 분리 배치합니다. 예컨대 Web서버 클러스터 뒤에 WAS클러스터, 그리고 DB 이중화구성이 전형적인 패턴입니다.
• MSA (Microservices Architecture): 대규모 시스템이나 디지털 서비스 플랫폼에서는 마이크로서비스를 도입해 유연성과 배포 독립성을 추구하기도 합니다. MSA는 애플리케이션을 여러 작은 서비스들로 분해하여, 각각을 독립적으로 개발, 배포, 확장 가능하게 만드는 아키텍처입니다. 국내 공공부문에서도 행정안전부의 정부24 개편 사업 등 일부 신규 프로젝트에 MSA 개념을 적용하고 있습니다. MSA 도입 시에는 도커/쿠버네티스 기반 컨테이너 인프라 위에 각 서비스별로 Spring Boot 애플리케이션 등을 올리고, 서비스 간 통신은 REST API나 메시지 큐(Kafka 등)를 활용합니다. 예를 들어 한 행정기관은 기존 모놀리식 시스템 일부를 MSA로 전환하며 Spring Cloud, Eureka, RabbitMQ 등을 도입해 이벤트 드리븐 아키텍처를 구현했습니다. MSA는 민간 IT기업에서 2015년경부터 유행했고 현재는 대기업/스타트업에서도 표준화되었는데, 공공도 이를 따라가는 양상입니다. 다만 공공 SI에서는 MSA 전환 시 데브옵스 역량과 서비스 경계 정의 등이 어려울 수 있어, 단계적 시범 적용이 이뤄지고 있습니다. 혼합 아키텍처도 많은데, 핵심 공통기능은 모놀리식 3-Tier로 두고 일부 데이터 분석 모듈이나 외부 연계모듈만 MSA로 떼어내는 식입니다.
• 배포 구조 및 망 구성: 공공기관 시스템은 대체로 온프레미스 데이터센터(또는 정부통합전산센터)에 배포되지만, 최근에는 클라우드 활용도 늘고 있습니다. 행안부의 클라우드 전환 가이드라인에 따라 정부 공용클라우드 또는 **민간 클라우드(Cloud SaaS/IaaS)**를 이용하려면 클라우드 보안인증(CSAP) 획득 서비스여야 합니다. 일부 기관은 네이버클라우드, KT클라우드 등 CSAP인증된 민간 클라우드에 개발/테스트 환경을 두고 운영 환경은 자체 센터에 두는 하이브리드 형태로 설계하기도 합니다. 배포 시 물리 망 구성은 앞서 보안에서 언급한 대로 인터넷 DMZ망, 업무 내부망, 데이터베이스망 등으로 분리합니다. 인터넷 사용자가 접속하는 웹서버 및 웹방화벽은 DMZ(외부망)에 두고, WAS와 DB서버는 내부 업무망에 위치시켜 2중, 3중 보안망을 형성합니다. 또한 기관 내부직원 전용 시스템은 아예 폐쇄망(행정망)에서만 동작하게 하여 인터넷과 논리적으로 차단하기도 합니다. 이런 망구조 설계는 정보자산 등급에 따라 결정되며, 망간 연계가 필요한 경우 전용 보안게이트웨이를 두어 자료를 교환하게 합니다.
• 이중화 및 고가용성(HA): 공공 서비스의 중단을 막기 위해 각 계층별 이중화 설계가 기본입니다. 웹서버는 L4 스위치 또는 소프트웨어 로드밸런서를 통해 다중 서버로 부하분산을 합니다. WAS도 세션을 공유하거나 무상태(stateless) 처리하도록 설계하여 여러 인스턴스를 클러스터링하고 Active-Active로 운영합니다. 데이터베이스는 이중화(DB Failover) 또는 **클러스터(RAC 등)**로 구성합니다. 예를 들어 Oracle DB의 Primary-Standby 구성이나 Tibero의 Active Cluster, MariaDB의 Galera Cluster 등을 활용해 한 노드 장애 시 자동으로 대기 노드로 전환합니다. 티맥스티베로의 경우 실시간 동기화로 장애 시 즉각 페일오버하는 ADR(Active-Active DR) 솔루션을 제공하여 공공기관 DB 이중화에 활용되고 있는데, 이러한 기술을 적용하면 RTO/RPO를 최소화할 수 있습니다. 또한 미러링 디스크, 이중 전원공급, 네트워크 중복경로 등 인프라 레벨에서도 장애 대응 설계를 합니다. 중요 시스템은 DR(재해복구) 센터에 주 센터와 동일한 구성의 예비 시스템을 마련해 두고, 주 센터에 치명적 장애가 발생하면 DR로 서비스를 절체하도록 구축합니다. 예를 들어 금융결제망, 주민등록 시스템 등 국가핵심 시스템은 원격지 DR 센터에서 주기적 동기화로 데이터 일치를 유지하며, 정기적으로 DR 모의훈련을 실시합니다.
• 성능 및 확장 고려: 아키텍처 설계 시 성능 부하 분산과 확장성도 중점 검토합니다. 공공 웹사이트의 경우 트래픽 피크가 예측될 때 CDN(콘텐츠 전송망)이나 리버스 프록시 캐시를 두어 정적 콘텐츠 부하를 줄입니다. 어플리케이션 레벨에서는 **분산 캐시(memcached, Redis 등)**를 적용해 DB 부하를 경감시키고, 비동기 처리가 필요한 부분은 메시지 큐로 처리하여 응답속도를 높입니다. 배포 자동화를 위해 CI/CD 파이프라인을 구축하고 IaC(Infrastructure as Code) 개념을 도입하는 곳도 있습니다. 다만 전통적 SI 사업에서는 변화관리에 보수적이어서, 컨테이너 오케스트레이션(Kubernetes)이나 완전한 DevOps 문화를 도입한 사례는 아직 제한적입니다. 하지만 신규 스마트시티 플랫폼이나 AI 빅데이터 플랫폼 사업에서는 컨테이너 기반 MSA와 CI/CD를 적극 활용하는 등 현대적 아키텍처를 채택하고 있습니다.

정리하면, 공공기관 시스템 아키텍처는 대체로 3계층 구조를 기본으로 하면서 요구에 따라 MSA 패턴을 부분 도입하고, 망분리와 이중화로 신뢰성을 담보하는 형태입니다. 표준화된 프레임워크와 레퍼런스 아키텍처가 존재하여 (예: 전자정부표준프레임워크 기반 3-Tier 레퍼런스) 이를 준용하되, 최신 클라우드나 데이터 기술도 점진적으로 수용하는 방향으로 발전하고 있습니다.

6. 기술 스택

대한민국 공공 SI 프로젝트에서 주로 사용되는 기술 스택은 아래와 같이 정리할 수 있습니다:

이와 같이 백엔드에는 안정적인 Java/Spring, 프론트엔드에는 현대적인 JS프레임워크, 데이터베이스는 Oracle 및 대안 DB, 서버는 상용 또는 오픈소스 WAS+Linux 조합이 공공 SI의 표준 스택이라 할 수 있습니다. 이러한 기술 스택은 재사용성과 인력 수급 측면에서 유리하여 선호되며, 새로 나온 기술도 엄격한 검증 후 도입되곤 합니다. 다만 AI, 빅데이터와 같이 새로운 업무 분야에서는 Python(PyTorch, TensorFlow)이나 R, Spark 등 특화 스택을 부가적으로 사용하는 등 요구기술에 따라 탄력적으로 선택됩니다. 전반적으로는 민간에서 검증된 오픈소스 기술을 기반으로 국산 솔루션과 조합하여 사용하는 형태가 많습니다.

7. 공공기관 프로젝트 사례

마지막으로, 실제 공공기관 SI 프로젝트에서의 설계 및 기술 적용 사례를 몇 가지 소개합니다.

• 한국기초과학지원연구원(KBSI) 통합인증 도입: KBSI는 2019년 내부 업무포털 환경을 개선하면서 SSO(Single Sign-On) 기반 통합인증 시스템을 도입한 사례가 있습니다. 그룹웨어, 경영정보시스템, 전자계약관리 등 10여 개 시스템을 단일 계정으로 연계하기 위해 SSO 솔루션 **‘Pass-Ni SSO’**를 구축했고, 동시에 구글 OTP를 활용한 2차 인증(One Time Password) 체계를 적용하여 보안을 강화했습니다. 이를 통해 사용자들은 한 번 로그인으로 모든 내부 업무시스템을 이용하게 되어 편의성이 높아졌고, ID/패스워드 관리부담도 줄었습니다. 특히 이 SSO 솔루션은 국제 CC인증을 획득한 제품으로 선정되었는데, 2017년 8월 이후 공공기관은 SSO 등 보안솔루션 도입 시 CC인증 제품을 써야 한다는 지침에 부합하기 위해서였습니다. 결과적으로 연구원은 편의성과 보안성을 모두 향상시켜 정보보안 강화와 업무효율 증대라는 성과를 얻었습니다.
• 한국가스공사(KOGAS) 차세대 시스템 및 AI 플랫폼: 한국가스공사는 디지털 전환 전략의 일환으로 차세대 통합정보시스템(ERP) 구축 사업을 추진 중입니다. 2024년 하반기 착수한 이 프로젝트는 SAP ECC 기반의 기존 ERP를 최신 SAP S/4HANA로 업그레이드하는 것으로, 약 141억 원 규모로 2027년 초까지 28개월간 진행됩니다. SAP의 기술지원 종료시한(2027년)에 선제 대응하여 미리 신규 시스템을 구축하는 사례이며, 전사 업무 프로세스 개선(PI), 생산∙공급관리 시스템 재구축, 통합 포털 구현 등이 범위에 포함됩니다. 또한 가스공사는 스마트 플랜트 구현을 위해 AI와 빅데이터 기술을 접목한 플랫폼 개발을 단계적으로 진행하고 있습니다. 전국 LNG 생산기지의 운영 데이터를 통합 관리하는 **운전정보 통합시스템(OASIS)**을 구축했고, 여기에 연계하여 AI 기반 공정위험 예측 시스템을 3단계에 걸쳐 개발하고 있습니다. 1단계로 주요 설비 위험요소 데이터 분석모델을 만들고, 2단계로 2027년까지 기지별로 시스템을 적용하며, 3단계로 2028년 이후 완전한 AI 예측 시스템을 가동할 계획입니다. 이처럼 **기존 핵심업무 시스템(ERP)**의 고도화와 신규 데이터 플랫폼 구축을 병행하여, 전사적 디지털혁신을 도모하는 사례입니다. 특히 2023년에는 내부망에서 운영되는 **생성형 AI 플랫폼 'Mate'**를 출시하여, 직원들이 문서작성, 번역 등을 AI 비서처럼 활용하도록 했습니다. 이 플랫폼은 **사내 전용 LLM 모델과 상용 거대언어모델(챗GPT 등)**을 하이브리드로 연계하되, 내부 기밀자료는 폐쇄망에서 처리하도록 설계하여 보안과 업무혁신의 균형을 잡았습니다. 한국가스공사 사례는 전통적인 업무시스템의 업그레이드와 첨단 기술 도입을 함께 추진하면서, 공공기관이 나아가는 디지털 전환 방향을 잘 보여줍니다.
• 기타 사례: 이 밖에도 다양한 공공 SI 프로젝트들이 진행되고 있습니다. 예를 들어, 조달청의 나라장터 시스템은 차세대 개편 시 마이크로서비스 아키텍처와 클라우드 기반 DevOps를 도입하는 방향을 검토 중이며, 행정안전부의 정부24 통합민원포털 역시 개편 사업에서 통합 인증과 연계 표준화, 반응형 웹기술 등을 적용했습니다. 지방자치단체들은 스마트시티 통합플랫폼 구축 사업을 통해 방범, 교통, 환경 데이터를 한데 모아 연계 처리하는 시스템을 구축하고 있는데, 이때 표준 데이터 구조, ESB 연계, CCTV 영상 공유 등의 설계를 공통으로 따르고 있습니다. 또한 공기업 분야에서는 AI 챗봇 민원상담, 블록체인 기반 문서 위변조 검증, 모바일 앱을 통한 대민서비스 고도화 등 최신 기술을 적용한 사례도 늘고 있습니다. 이러한 실제 사례들은 본문의 각 항목에서 설명한 원칙들 – 체계적인 기능설계, 엄격한 보안 준수, 다양한 인증 연계, 효율적 시스템 통합, 안정적 아키텍처, 검증된 기술스택 – 이 어떻게 현실 프로젝트에 구현되는지를 보여줍니다. 공공 SI 프로젝트는 민간과 달리 법/제도적 요구사항과 공익성을 중시하기 때문에, 설계 단계부터 오늘 살펴본 바와 같은 방식으로 치밀하게 준비하여 추진되고 있습니다.

1. Spring Boot로 전체 시스템 이행을 위한 전략적 접근

2. Servlets 기반 구조를 Spring Boot 구조로 전환하는 방법

3. Spring 4에서 Spring Boot 최신 버전으로 전환 시 고려사항

4. MyBatis 3의 호환성 및 Spring Boot 연동 방안

5. Tomcat 9을 내장 톰캣으로 전환하는 절차와 설정

6. 성능 개선 측면에서 Spring Boot의 장점과 이행 시 유의점

7. 클라우드 이행 관점에서 추천되는 아키텍처

8. 단계별 마이그레이션 로드맵 제안

1. Spring Boot로 전체 시스템 이행을 위한 전략적 접근

레거시 시스템을 Spring Boot로 마이그레이션할 때는 단계적이고 신중한 전략이 필요합니다. 먼저 현재 시스템의 아키텍처와 구성요소를 면밀히 분석하세요. 사용 중인 Java 버전(현재 Java 8)과 프레임워크(Spring 4 등)가 **목표 환경(Spring Boot 최신 버전 및 클라우드)**에서 호환되는지 확인해야 합니다. 예를 들어 Spring Boot 3은 Java 17 이상과 Jakarta EE 9 이상의 스택을 요구하므로, Java 업그레이드 및 라이브러리 호환성 점검이 선행되어야 합니다. 기존 코드에서 javax 패키지를 사용하는 부분은 Jakarta 패키지로 변경하는 등의 조치가 필요합니다.

이행 전략으로는 한 번에 전체를 교체하는 빅뱅 방식보다는, 기존 비즈니스 로직을 유지하면서 점진적으로 Spring Boot로 전환하는 리팩토링 우선 전략이 권장됩니다. 예컨대, 현재 애플리케이션을 모듈별로 나누어 하나씩 Spring Boot로 전환하며 레거시와 신규 코드를 공존시키는 방식입니다. 이러한 접근은 대규모 재작성보다 리스크가 적고, 필요시 Strangler Fig 패턴 등을 활용해 구 시스템의 일부 기능을 새 시스템으로 조금씩 대체해나갈 수 있습니다.

또한 초기 단계에서 핵심 모듈에 대한 PoC(Proof of Concept)을 통해 Spring Boot 전환의 문제점을 미리 파악하고 해결하는 것이 좋습니다. 전체 전환 계획을 수립할 때는 데이터베이스, 연동 시스템, 배포 파이프라인 등 모든 계층에 걸친 영향도를 고려하세요. 마지막으로 전환 과정 전반에 걸쳐 광범위한 테스트 계획(회귀 테스트, 부하 테스트 등)을 마련하여 기능 및 성능 회귀가 없도록 검증해야 합니다.

2. Servlets 기반 구조를 Spring Boot 구조로 전환하는 방법

Servlet API를 직접 사용하는 기존 웹 구조는 Spring MVC 패턴으로 재구성하여 Spring Boot에 적합하게 전환해야 합니다. 구체적으로, 개별 HttpServlet 클래스는 Spring MVC의 컨트롤러(controller) 클래스로 변환됩니다. 각 서블릿의 doGet, doPost 로직은 해당 메서드에 대응되는 @Controller 또는 @RestController 클래스의 메서드로 옮기고, URL 매핑은 @RequestMapping/@GetMapping 등의 애노테이션으로 지정합니다. 예를 들어 Servlet의 doGet(HttpServletRequest req, HttpServletResponse res) 메서드는 Spring MVC에서 @GetMapping이 붙은 메서드로 변경하고, req.getParameter("param") 호출 부분은 @RequestParam 매개변수로 대체하는 식입니다. 이렇게 하면 HttpServletRequest/Response에 직접 의존하던 코드를 제거하고 Spring이 요청 파라미터 바인딩과 응답 처리를 자동으로 해줄 수 있습니다. 또한 응답은 PrintWriter로 쓰는 대신 메서드 리턴값(예: 문자열 뷰 이름이나 JSON 객체)을 통해 처리하고, 필요한 경우 @ResponseBody나 ResponseEntity를 사용하여 REST 응답을 생성합니다.

Spring Boot에서는 기본적으로 DispatcherServlet 등 웹 관련 설정을 자동으로 구성하므로, 수동으로 서블릿을 등록하거나 web.xml에 디스패처를 정의할 필요가 없습니다. 특히, Spring Boot의 spring-boot-starter-web를 추가하면 내장 톰캣과 함께 Spring MVC 디스패처 서블릿이 자동 설정되어 웹 요청을 처리하게 됩니다. 따라서 기존 web.xml에 정의된 서블릿 매핑이나 리스너 설정들은 대부분 불필요해지며, 필요한 경우 Java Config나 Spring Boot 설정으로 전환하면 됩니다.

View 처리 측면에서는, 만약 기존에 JSP를 사용했다면 Spring Boot에서 그대로 JSP를 사용할 수도 있지만 추가 설정이 필요합니다. 권장되는 방법은 Thymeleaf 등의 템플릿 엔진을 사용하는 것이지만, JSP를 지속 사용하는 경우 뷰 리졸버(ViewResolver) 설정을 application.properties에 지정해야 합니다. 예를 들어 JSP 파일이 /WEB-INF/views/ 아래 위치한다면, 아래와 같이 설정합니다:

위와 같은 설정으로 Boot 환경에서 JSP를 문제없이 로드할 수 있습니다. 정적 리소스(css, js 등)는 /static 또는 /public 경로에 두면 별도 설정 없이 제공되며, 기존 mvc:resources 설정은 이러한 디렉토리 구조로 대체됩니다.

또한 Spring Boot로 전환하면서 **필터(Filter)**나 인터셉터와 같은 웹 요소도 재구성해야 합니다. 기존 javax.servlet.Filter 구현체는 @Component를 붙여주거나 FilterRegistrationBean으로 등록하면 되고, Spring MVC 인터셉터는 WebMvcConfigurer를 구현하여 addInterceptors() 메서드로 등록할 수 있습니다. 이러한 작업을 통해 Servlets 기반 코드를 Spring Boot 구조로 자연스럽게 녹여낼 수 있습니다.

3. Spring 4에서 Spring Boot 최신 버전으로 전환 시 고려사항

Spring Boot는 Spring Framework를 기반으로 개발을 단순화한 프레임워크이므로, Spring 4에서 전환할 때 설정 방식과 라이브러리 관리의 차이를 유의해야 합니다. 주요 고려사항은 다음과 같습니다:

• 스타터 의존성 및 Maven 설정: Spring Boot에서는 다수의 의존성을 하나로 묶은 Starter를 제공하여 의존성 관리를 간소화합니다. 예를 들어, 웹 관련 기능을 위해 과거에는 spring-webmvc, tomcat 라이브러리 등을 각각 추가했다면, Boot에서는 spring-boot-starter-web 하나로 대신합니다. 이 스타터에는 Spring MVC, 내장 톰캣, JSON 처리 등 웹 애플리케이션에 필요한 핵심 라이브러리가 모두 포함됩니다. Boot의 Starter 부모 POM을 사용하면 공통 의존성 버전을 관리해주므로, 기존 pom.xml에서 명시적으로 버전을 지정했던 Spring 및 서드파티 라이브러리 의존성 선언은 제거하거나 Boot에 맞게 조정해야 합니다.
• 설정 파일과 프로파일: Spring 4에서는 XML 또는 자바 설정 + *.properties 파일 조합으로 환경 설정을 했을 것입니다. Spring Boot에서는 기본적으로 프로젝트 리소스 경로에 application.properties 또는 application.yml 파일을 두고 애플리케이션 설정을 관리합니다. Boot는 이 파일을 자동으로 로드하며, 별도의 PropertyPlaceholderConfigurer 설정 없이 @Value 또는 @ConfigurationProperties 등을 통해 값을 주입할 수 있습니다. 프로파일별 설정은 application-{profile}.properties 형태로 작성하면 Boot가 활성 프로파일에 따라 자동 적용합니다. 따라서 기존 Spring 4의 PropertyPlaceholderConfigurer나 @PropertySource 사용 부분은 Boot 방식으로 단순화됩니다.
• 자동 구성과 애노테이션 처리: Spring Boot는 자동 설정(Auto-Configuration) 기능을 통해 클래스패스의 라이브러리에 따라 필요한 빈을 자동 등록합니다. 예를 들어 Spring Boot에서 spring-boot-starter-web를 포함하면 DispatcherServlet이나 RequestMappingHandlerMapping 등이 자동으로 설정되고, 별도로 <mvc:annotation-driven>이나 @EnableWebMvc를 선언할 필요가 없습니다. Boot의 메인 클래스에는 일반적으로 @SpringBootApplication 애노테이션을 사용하는데, 이 하나의 애노테이션이 기존 Spring의 @Configuration, @EnableAutoConfiguration, @ComponentScan을 모두 포함합니다. 즉, Boot의 메인 클래스가 있는 패키지 이하를 자동으로 컴포넌트 스캔하여 @Component, @Controller, @Service 등의 빈을 찾고 등록합니다. 별도로 Spring 4에서 사용하던 <context:component-scan>이나 <context:annotation-config> 설정은 더 이상 필요하지 않으며, Boot 메인 클래스 패키지 구조를 잘 정의하는 것만으로 동일한 효과를 얻습니다.
• XML 설정 이관: 기존 Spring 4 프로젝트에서 사용한 XML 설정이 있다면, 가능하면 자바 코드 기반 설정으로 변환하는 것이 좋습니다. Boot에서는 XML 설정을 지양하지만, 필요한 경우 @ImportResource를 이용해 기존 XML을 불러올 수도 있습니다. 따라서 레거시 프로젝트의 spring-*.xml (예: dispatcher-servlet.xml, applicationContext.xml 등)에 정의된 빈들을 검토하여, Boot 환경에서 제공하는 자동 설정으로 대체할 수 있는지 판단하고, 필요한 빈은 @Bean이나 스타터 의존성으로 대체합니다. 예를 들어 Spring 4 XML에서 설정했던 InternalResourceViewResolver나 CommonsMultipartResolver 같은 빈은 Boot에서는 application.properties 설정으로 대체하거나 자동구성이 제공됩니다.
• 의존성 버전 및 Jakarta 전환: Spring 4에서 Spring Boot 최신 버전(예: Spring Boot 3.x)으로 올라올 때는 Jakarta EE 네임스페이스로 전환된 사항을 꼭 확인해야 합니다. Spring Boot 3(SF 6)은 서블릿 API 등을 포함한 Java EE 라이브러리가 javax에서 jakarta로 변경되었습니다. 따라서 기존 코드나 라이브러리가 javax.servlet 같은 패키지를 쓰고 있다면, 대응되는 jakarta.servlet API로 변경해야 합니다. 예를 들어 Spring MVC의 DispatcherServlet도 Spring 6에서는 Jakarta Servlet API를 요구하므로, 기존에 javax.servlet로 작성된 필터나 서블릿 관련 코드는 컴파일 에러가 발생할 수 있습니다. 이 부분은 주로 import 문 수정과 라이브러리 업그레이드로 해결하며, Boot로 마이그레이션 시 자동으로 처리되지는 않으므로 개발자가 직접 수정해야 합니다. 다행히 Spring Boot 3 마이그레이션을 도와주는 도구(Eclipse Transformer 등)도 있어 이러한 패키지 변환을 지원하기도 합니다.
• 기타 변경사항: Spring 4 -> Spring Boot/Spring 6 환경에서 일부 애노테이션이나 설정 방식이 달라진 경우가 있습니다. 예를 들어 Spring 4에서 사용되던 @Autowired(required=false) 등의 옵션 처리, @PostConstruct 동작 등이 Spring 6에서도 지원되지만, Java 9 이상의 모듈 시스템 영향으로 리플렉션 관련 설정에 변화가 있을 수 있습니다. 또한 Spring 5부터 기본적으로 Java 8의 함수형 스트림 API나 Optional 등을 많이 활용하므로, 레거시 코드에서도 Java 8 스타일로 리팩토링하면 Boot 이행 후의 코드를 현대화하는 데 도움이 됩니다.

정리하면, Spring Boot로 전환 시에는 설정 파일의 통합 및 단순화, 의존성 관리 일원화(starter 사용), 자동 설정 활용, 그리고 Jakarta 패키지 대응에 중점을 두어야 합니다. 이러한 사항들을 미리 계획하고 대비하면 Spring 4 기반 코드를 Spring Boot 최신 환경으로 비교적 수월하게 이식할 수 있습니다.

4. MyBatis 3의 호환성 및 Spring Boot 연동 방안

현재 사용 중인 MyBatis 3는 Spring Boot 환경에서도 충분히 호환되며, Boot와 쉽게 연동할 수 있습니다. Spring Boot용 MyBatis 스타터 라이브러리를 사용하면 수동 설정을 최소화하면서 MyBatis를 통합할 수 있습니다. 우선 pom.xml에 MyBatis Spring Boot Starter 의존성을 추가합니다. 예를 들어 Maven 기준으로 아래와 같습니다:

위 스타터를 추가하면 MyBatis의 SqlSessionFactory 및 SqlSessionTemplate 등이 Spring Boot에 의해 자동 구성되며, MyBatis와 관련된 여러 빈(bean)들을 수동으로 등록할 필요가 없습니다.

데이터베이스 연결은 Spring Boot의 일반적인 방식대로 application.properties에서 설정하면 됩니다. 예를 들어 HikariCP(DataSource 기본풀) 설정과 DB URL, 계정정보를 지정합니다:

Boot 3.x의 기본 DB 커넥션 풀은 HikariCP이며, 이는 성능과 안정성이 뛰어나므로(MyBatis도 별도 설정 없이 이 풀을 사용) 바로 활용하면 됩니다. 기존에 사용하던 Tomcat JDBC Pool 등에서 전환되는 것이며, HikariCP는 경량이라 레거시 대비 커넥션 풀 성능이 향상될 수 있습니다.

MyBatis 설정의 경우, 매퍼 XML과 매퍼 인터페이스를 Boot에 인식시켜야 합니다. MyBatis Spring Boot Starter는 mybatis.configuration.* 및 mybatis.mapper-locations 등의 프로퍼티로 설정을 제공합니다. 예를 들어 application.properties에 MyBatis 관련 패키지와 매퍼 XML 경로를 지정할 수 있습니다:

위와 같이 설정하면 Boot 실행 시 해당 패키지의 클래스에 대해 별칭을 등록하고, 지정된 경로의 XML들을 모두 읽어 MyBatis 매퍼로 인식합니다. 또한 MyBatis 매퍼 인터페이스에는 @Mapper 애노테이션을 붙여주면(Spring Boot가 해당 애노테이션을 스캔) 구현체 없이도 Mapper 빈이 자동 등록됩니다. 만약 패키지 단위로 일괄 스캔하고자 한다면 Boot 메인 클래스에 @MapperScan("com.example.project.mapper")을 추가하여 매퍼 인터페이스를 찾아 등록할 수도 있습니다.

레거시 Spring 4에서는 SqlSessionFactoryBean, MapperScannerConfigurer 등을 XML이나 자바 설정으로 등록했을 가능성이 있는데, Boot 환경에서는 위 스타터가 이러한 작업을 자동으로 처리합니다. 다만 트랜잭션 관리는 여전히 Spring의 @Transactional을 그대로 사용하면 되고, Boot가 Datasource를 자동으로 감지하여 DataSourceTransactionManager를 빈으로 등록하므로 특별한 설정 없이도 MyBatis에서 Spring 트랜잭션을 사용할 수 있습니다.

호환성 측면에서 MyBatis 3 자체는 최신 Spring/Spring Boot와 호환되므로 큰 문제가 없습니다. MyBatis에서 Java EE에 의존하는 부분이 거의 없기 때문에(JDBC 기반) Jakarta 전환 이슈도 적습니다. 다만 MyBatis 관련 부가 라이브러리나 플러그인 중 Spring 4 전용으로 작성된 것이 있다면(예: MyBatis-Spring의 예전 버전) 최신 버전으로 올려야 합니다. 예를 들어 MyBatis-Spring 라이브러리는 Boot 스타터에 내장된 버전을 따르게 되므로, 호환성을 위해 Boot에 맞는 스타터 버전을 사용하면 됩니다. (Spring Boot 3.x에 대응하는 MyBatis 스타터 3.x 버전이 존재합니다.)

요약하면, MyBatis 연동 방안은:

• Spring Boot용 MyBatis 스타터 추가 (의존성 관리 용이)
• DB 연결정보 및 MyBatis 설정을 application.properties에 정의
• @Mapper 또는 @MapperScan으로 매퍼 인터페이스 등록
• 필요 시 커스텀 MyBatis 설정은 application.properties의 MyBatis 프로퍼티나 @Configuration 클래스를 통해 적용

이런 방식으로 설정하면 MyBatis를 Spring Boot에서 무리 없이 활용할 수 있습니다. MyBatis를 그대로 쓰면서도, 향후 필요에 따라 Spring Data JPA로 일부 전환하거나 복합적인 데이터 접근을 구현할 여지도 생기므로, MyBatis 모듈을 분리하여 의존성을 관리하면 유지보수에도 도움이 될 것입니다.

5. Tomcat 9을 내장 톰캣으로 전환하는 절차와 설정

현재 Tomcat 9에 WAR를 배포하는 방식을 **Spring Boot의 내장 톰캣(Embedded Tomcat)**으로 전환하면 배포와 실행 방식이 크게 단순화됩니다. 전환 절차는 다음과 같습니다:

1. 의존성 변경 및 빌드 설정: Spring Boot로 마이그레이션하면서 Maven/Gradle 빌드 설정을 Boot 스타일로 변경해야 합니다. Maven 기준으로 부모를 spring-boot-starter-parent로 지정하고, spring-boot-starter-web 의존성을 추가했다면 이미 내장 톰캣이 포함된 것입니다. Boot 스타터 웹에 Tomcat이 기본 포함되어 있으며, 별도로 Tomcat 의존성을 명시할 필요가 없습니다. 다만, 기존 Tomcat 서버 라이브러리나 Servlet API 의존성 (예: javax.servlet-api, tomcat-embed-core 등)을 pom에서 제거하거나 provided로 변경해야 합니다. Boot에서 내장 톰캣을 사용할 때는 이러한 라이브러리가 중복되지 않도록 정리합니다.
2. 실행 가능한 JAR로 패키징: Spring Boot 애플리케이션은 보통 독립 실행 JAR로 패키징합니다. 이를 위해 Maven의 Spring Boot 플러그인을 설정해야 합니다. pom.xml의 <build><plugins> 섹션에 아래와 같이 추가합니다:위 플러그인은 Maven 패키징 단계에서 실행가능한 JAR (또는 WAR)로 재포장(repackage)하는 역할을 합니다. 이 설정을 하면 mvn package 수행 시 Boot 애플리케이션이 내장 톰캣을 포함한 fat jar 형태로 생성됩니다. 이후 이 JAR 파일만으로 어플리케이션을 실행(java -jar)할 수 있게 됩니다.
3.  
   <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>${spring-boot.version}</version> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin>
4. WAR 배포에서 JAR 실행으로 전환: Boot로 전환하면서 반드시 WAR를 써야 하는 게 아니라면, JAR 실행으로 운영하는 것이 일반적입니다. 이를 위해 위와 같이 패키징을 JAR로 설정하고 (pom.xml 기본 packaging이 jar), 메인 클래스에 public static void main 메서드로 SpringApplication.run(...)을 호출하는 진입점을 두면 됩니다. 만약 호환성 등 이슈로 WAR 배포가 필요하다면, Spring Boot도 WAR 형태로 빌드해 외부 Tomcat에 배포할 수 있지만, 권장되는 방식은 내장 톰캣을 활용하는 JAR입니다. 내장 톰캣을 쓰면 특정 앱 서버 환경에 종속되지 않고 컨테이너화(Docker 등)하기도 수월합니다.
5. 설정 변경: 내장 톰캣으로 전환할 때, 서버 포트나 컨텍스트 경로 등의 설정을 application.properties로 옮길 수 있습니다. 기본적으로 Boot 내장 톰캣은 포트 8080으로 동작하며, 변경하려면 server.port=포트번호를 설정합니다. 컨텍스트 경로도 server.servlet.context-path=/경로 속성으로 지정 가능합니다. 기존 Tomcat의 server.xml에서 설정하던 스레드 풀 크기 등의 튜닝 파라미터도 필요하면 application.properties에서 server.tomcat.max-threads 등의 속성으로 조정할 수 있습니다. 예를 들어 server.tomcat.max-threads=200 등의 설정이 그것입니다.
6. JNDI 및 기타 Tomcat 전용 설정 이관: 레거시 환경에서 Tomcat에 JNDI 리소스를 정의해 쓰고 있었다면, Boot에서는 이를 직접 DataSource로 명시적으로 설정하거나 Spring Cloud Config/Vault 같은 외부 설정으로 관리해야 합니다. Boot 내장 톰캣도 JNDI를 지원할 순 있으나, 클라우드 환경에서는 애플리케이션 내 설정이나 클라우드 플랫폼의 설정 관리 서비스를 사용하는 편이 더 일반적입니다. 예를 들어 AWS 환경이라면 RDS 연결 정보를 애플리케이션 설정으로 두고, JNDI를 쓰지 않는 식입니다. Boot로 마이그레이션하면서 가능하면 JNDI 의존성을 제거하고 설정을 표준화하는 것을 권장합니다.
7. 로그 및 기타 설정: Boot는 기본 로깅으로 Logback을 내장하고 있습니다. 만약 Tomcat에서 별도로 설정하던 접근로그(Access Log) 등은 Boot의 Tomcat 설정으로 켤 수 있습니다 (server.tomcat.accesslog.enabled=true 등). 또한 배포 환경별로 다른 설정(예: Prod와 Dev의 설정 차이)은 Boot의 프로파일 기능이나 별도 설정 파일을 통해 관리하면, 하나의 JAR로 다양한 환경에 대응할 수 있습니다.

정리하면, 내장 톰캣으로의 전환은 Spring Boot 프로젝트 구조를 따르고 JAR로 패키징함으로써 이뤄집니다. 이렇게 하면 배포 시에 외부에 Tomcat 9를 설치하고 WAR를 배포하는 절차 없이, 빌드 결과물(JAR)을 원하는 서버나 컨테이너 환경에 복사하여 실행만 하면 되므로 DevOps 면에서 효율성이 높아집니다. 특히 클라우드 (쿠버네티스나 컨테이너 기반) 환경에서는 이 방식이 표준적입니다. Boot 내장 톰캣은 성능이나 기능 면에서도 Tomcat 9와 동일한 엔진으로 동작하므로 별도 이슈는 없지만, 세션 관리나 인코딩 설정 등 Tomcat 전역 설정이 있었다면 application.properties나 코드 상에서 세팅해주는 것을 잊지 않아야 합니다.

6. 성능 개선 측면에서 Spring Boot의 장점과 이행 시 유의점

Spring Boot로 마이그레이션하는 주요 목표 중 하나가 성능 개선인 만큼, Boot 기반으로 전환함으로써 얻을 수 있는 이점과 주의할 점을 살펴보겠습니다.

성능 개선 장점:

• 업그레이드된 스택의 이점: Spring Boot 최신 버전은 기반 Spring Framework와 Java 버전의 향상을 그대로 누릴 수 있습니다. Java 17+의 성능 최적화(향상된 GC, JIT 등)와 Spring 5/6의 개선된 내부 구현으로 인해 전반적인 처리 효율이 좋아집니다. Netflix의 사례를 보면, Spring Boot 3 + Java 17 업그레이드 이후 애플리케이션의 부하 처리 성능이 향상되고 리소스 비용을 크게 절감한 사례가 있습니다. (Netflix는 수천 개의 마이크로서비스를 Boot 3로 올리는 작업을 통해 배치 작업 부트 시간 단축 등으로 수십만 달러의 비용을 절감했다고 보고했습니다.) 이처럼 최신 Spring Boot로의 이행은 빠른 부팅 시간, 낮은 메모리 소비, 높은 처리량 등으로 이어질 수 있습니다.
• 내장 기술의 성능 최적화: Spring Boot는 기본 설정으로도 상당히 최적화된 구성요소를 사용합니다. 예를 들어, 데이터베이스 커넥션 풀로 Boot 2부터 HikariCP를 기본 사용하고 있는데, HikariCP는 현재 가장 가벼우면서 빠른 커넥션 풀로 평가됩니다. 레거시 시스템이 tomcat-jdbc나 DBCP 등 비교적 무거운 풀을 썼다면, Boot 전환 후 커넥션 풀이 HikariCP로 바뀜에 따라 DB연결 성능과 안정성이 개선될 수 있습니다. 또 다른 예로, Spring Boot의 기본 HTTP 메시지 컨버터나 쓰레드풀 설정 등이 대체로 효율적으로 튜닝되어 있어, 특별히 문제가 없으면 기본값을 활용하는 것만으로도 좋은 성능을 낼 수 있습니다.
• 경량화 및 모듈화: Boot로 전환하면서 불필요한 라이브러리나 미사용 컴포넌트를 걷어내는 리팩토링을 병행하게 됩니다. 이 과정에서 애플리케이션이 경량화되고 메모리 사용량이나 클래스 로딩 시간 등이 감소하는 효과가 있습니다. 또한 Boot에서는 필요한 모듈만 의존성으로 포함하면 되므로, 과거 레거시 환경에서 관성적으로 포함되던 필요없는 라이브러리를 줄여 클린한 런타임 환경을 만들 수 있습니다.
• 스케일 아웃 용이: 성능 개선은 단일 인스턴스의 처리량 향상뿐만 아니라 확장성을 통해서도 달성됩니다. Spring Boot 애플리케이션은 완전히 stateless하게 개발하기 용이하고, Docker 등의 이미지로 만들어 수평 확장하기 좋습니다. 클라우드 환경에서 부하에 따라 손쉽게 인스턴스를 증설하고 로드밸런싱 할 수 있으므로, 결과적으로 성능(처리량, 가용성)이 개선됩니다. (Spring Boot 자체가 성능을 마법처럼 높이는 것은 아니지만, 마이크로서비스 아키텍처나 클라우드 오토스케일링을 도입하기 쉽게 만들어 궁극적으로 더 높은 성능과 신뢰성을 얻을 수 있습니다.)
• 각종 부가 기능: Spring Boot는 Actuator를 통해 애플리케이션의 상태와 메트릭을 노출할 수 있고, Spring Boot Admin, Micrometer 등을 활용하면 모니터링 및 성능 진단이 쉬워집니다. 이를 통해 병목 지점을 빠르게 찾아 튜닝할 수 있으므로, 지속적인 성능 개선 사이클을 돌리기에도 용이합니다. 또한 캐싱 추상화(@Cacheable)나 비동기 처리(@Async) 지원 등이 내장되어 있어, 애플리케이션 차원의 성능 최적화 기법을 더 손쉽게 적용할 수 있습니다.

이행 시 유의점:

• 자동 구성의 오버헤드 관리: Spring Boot의 편의성은 자동 구성이지만, 필요 없는 기능까지 로딩되지 않도록 주의해야 합니다. 스타터 의존성을 추가하면 관련 빈들이 모두 올라오는데, 예를 들어 spring-boot-starter-web을 쓰면 서블릿 컨테이너와 웹 관련 여러 빈들이 등록됩니다. 만약 사용하지 않을 기능(예: JSP 템플릿엔진 등)이 있다면 의존성에서 제외(exclude)하거나 설정으로 끄는 것이 좋습니다. 불필요한 빈을 많이 로드하면 메모리 사용량 증가와 부트 시간 증가로 이어져 성능에 악영향을 줄 수 있습니다. 따라서 자동 구성의 포함/제외 설정 (spring.autoconfigure.exclude 등)을 통해 필요한 것만 쓰도록 튜닝합니다.
• JVM 및 GC 튜닝: Boot로 이전하면서 Java 버전이 올라간다면(8 -> 17) JVM 옵션이나 GC 알고리즘이 바뀔 수 있습니다. 메모리 관리 측면에서 기존에 설정해둔 옵션이 있다면 재검토하고, Java 17의 G1 GC 기본값 등이 애플리케이션에 잘 맞는지 모니터링해야 합니다. 성능 테스트를 통해 Heap 사이즈, GC 튜닝 등을 조정하는 작업도 병행하십시오.
• 프레임워크 변경에 따른 쿼리 성능: MyBatis 자체는 동일하지만, 혹시 JPA나 기타 프레임워크로 일부 전환한다면 Lazy 로딩이나 연관관계 처리 등에서 쿼리 패턴이 달라져 성능 변화가 있을 수 있습니다. 현재는 MyBatis 유지한다고 하니 큰 문제는 없겠으나, SQL 튜닝 포인트는 기존과 동일하게 관리되어야 합니다. Boot로 바뀌어도 결국 DB I/O가 성능의 큰 부분을 차지할 것이므로, MyBatis 쿼리 성능과 인덱스 최적화 등은 계속 모니터링합니다.
• 대용량 트래픽 테스트: 새로운 Boot 기반 시스템을 배포하기 전에 반드시 부하 테스트를 실시해봐야 합니다. Spring Boot로 전환하면서 (특히 분산 환경, 마이크로서비스화 시) 발생할 수 있는 네트워크 부하, 서비스 간 호출 지연 등을 점검해야 합니다. 또한 레거시와 성능 비교를 통해 **성능 지표(Throughput, Latency)**가 개선되었는지 수치화할 필요가 있습니다. 만약 Boot 이행 후 초기에는 성능 이슈가 나타난다면, 이는 설정의 디폴트 값 차이나 환경 차이일 수 있으므로 스레드풀 크기, DB커넥션풀 크기, 타임아웃 등 파라미터를 조정해볼 필요가 있습니다.
• 메모리 Footprint 변화: Boot 애플리케이션은 실행 파일(JAR)에 라이브러리를 다 포함하므로 메모리 사용이 약간 늘 수 있지만, 반대로 불필요한 외부 서버를 안 띄우기에 경량이라고 볼 수도 있습니다. 반드시 Java 힙 및 메모리 설정(Xmx 등)을 재조정하여 새로운 환경에 맞게 최적화를 진행하세요. 특히 컨테이너 환경에서는 컨테이너 메모리 제한에 맞게 설정하는 것이 중요합니다.

요약하면, Spring Boot 도입으로 성능상의 이점(업그레이드된 프레임워크, 기본 튜닝, 수평확장 용이성 등)을 얻을 수 있지만, 최대한 활용하려면 세밀한 튜닝과 테스트가 따라줘야 합니다. 이행 과정에서는 기능 개선뿐 아니라 성능 목표치에 맞추어 프로파일링하고, 병목을 제거하면서 진행하면 최종적으로 레거시 대비 향상된 성능을 달성할 수 있을 것입니다.

7. 클라우드 이행 관점에서 추천되는 아키텍처

Spring Boot로 전환한 이후 클라우드 환경에 배포할 때는 기존 모놀리틱 구조를 클라우드 네이티브 아키텍처로 최적화하는 것이 중요합니다. 일반적으로 다음과 같은 아키텍처 전략을 권장할 수 있습니다:

• 마이크로서비스 기반 설계: 레거시 시스템이 크고 일체화된 모놀리식이라면, 이를 적절히 도메인별로 분리하여 마이크로서비스로 구성하는 방안을 고려합니다. Spring Boot는 마이크로서비스 아키텍처에 최적화되어 있어, 작은 단위의 서비스 여러 개로 나누더라도 개발과 배포가 수월합니다. 각각의 서비스는 RESTful API를 통해 통신하게 하고, 독립적으로 배포/스케일링 가능하도록 설계합니다. 이렇게 하면 특정 기능에 트래픽이 집중될 때 해당 서비스만 확장하여 자원을 효율적으로 활용할 수 있고, 장애 발생 시 전체 시스템이 아닌 일부 서비스에 국한시켜 탄력성과 안정성이 높아집니다.
• API 게이트웨이 도입: 다수의 마이크로서비스로 구성될 경우, 외부 클라이언트는 여러 서비스의 엔드포인트를 알 필요 없이 API 게이트웨이를 통해 일원화된 접근을 할 수 있습니다. Spring Cloud Gateway나 Netflix Zuul과 같은 게이트웨이를 사용하면 라우팅, 인증/인가, 모니터링, 서킷브레이커 등의 크로스커팅 Concern을 게이트웨이에서 처리할 수 있습니다. 그림에서도 클라이언트 요청이 Spring Cloud Gateway를 거쳐 내부 서비스로 전달되는 구조를 보여줍니다. 이를 통해 각 서비스는 비즈니스 로직에만 집중하고 공통 기능은 게이트웨이에 위임할 수 있습니다.
• 구성 관리(Config): 클라우드 환경에서는 환경별 설정 값을 애플리케이션 코드와 분리하고 중앙 관리하는 것이 중요합니다. Spring Cloud Config Server를 도입하면 각 마이크로서비스의 설정을 git이나 저장소에 모아두고 중앙 집중형 구성 관리를 구현할 수 있습니다. 각 서비스는 Config Server로부터 자신의 환경설정을 받아오므로, 환경변수가 변경되어도 서비스 재배포 없이 반영할 수 있습니다. 예를 들어 DB 연결정보나 기능 토글 값 등을 Config 서버에서 관리하면 유용합니다. Boot Actuator와 연계하면 runtime에 /refresh로 설정 리로드도 가능합니다. 클라우드 벤더의 설정 관리 서비스(AWS SSM Parameter Store, Azure App Config 등)를 활용하는 것도 대안입니다만, Spring Cloud Config을 쓰면 애플리케이션 단에서 일관된 방법으로 설정을 다룰 수 있습니다.
• 서비스 디스커버리(Registry): 서비스가 증가하면 서로의 위치(IP/Port)을 동적으로 알아야 합니다. 서비스 레지스트리를 통해 각 서비스 인스턴스의 위치를 등록/탐색하는 메커니즘을 둡니다. Spring Cloud Netflix의 Eureka Server를 사용하면 손쉽게 서비스 등록/발견 기능을 구현할 수 있습니다. Eureka 서버를 구축하고 각 Boot 서비스에 @EnableEurekaClient를 적용하면, 서비스들은 부팅 시 Eureka에 자신의 주소를 등록하고, 다른 서비스 호출 시 Eureka로부터 대상 서비스의 최신 주소를 조회합니다. 이를 통해 쿠버네티스나 AWS ECS 등 동적으로 IP가 바뀌는 환경에서도 안정적으로 서비스 통신이 가능합니다. (만약 쿠버네티스같이 자체 서비스 디스커버리가 있는 플랫폼이라면 Eureka 없이 K8s 서비스 DNS를 활용할 수도 있습니다. 선택은 인프라에 따라 달라집니다.)
• Spring Cloud 기타 구성요소: 필요한 경우 서킷 브레이커(Resilience4j 혹은 Spring Cloud Circuitbreaker), 분산 트레이싱(Spring Cloud Sleuth + Zipkin), API 게이트웨이(앞서 언급), 配置中心/서비스 메쉬(Istio 등) 등을 도입하여 클라우드 네이티브 패턴을 구현할 수 있습니다. 예를 들어 그림에서는 Zipkin Server로 각 서비스의 호출 추적을 중앙관리하고 있는 모습도 있습니다. Spring Boot 애플리케이션에 Spring Cloud Sleuth를 추가하면 자동으로 TraceID, SpanID가 붙어 로깅되고 Zipkin으로 전송되어, 마이크로서비스간 호출 흐름을 한눈에 파악할 수 있습니다. Circuit Breaker는 마이크로서비스 일부 장애가 전파되지 않도록 해주며, Resilience4j 라이브러리를 통해 구현할 수 있습니다. Boot와 Spring Cloud 환경에서는 이처럼 마이크로서비스 패턴 구현을 지원하는 풍부한 툴킷(Spring Cloud Netflix, Spring Cloud Alibaba 등)이 있으므로 필요에 따라 조합하면 됩니다.
• 컨테이너 및 오케스트레이션: 클라우드 이행에서는 컨테이너화가 거의 필수입니다. Spring Boot는 독립 JAR로 실행되므로 Docker 이미지로 만들기 용이합니다. 멀티스테이지 빌드 등을 활용하여 경량 이미지를 만들고(Kubernetes 사용 시 init container나 sidecar로 Config나 Vault 연동도 가능), Kubernetes나 ECS 등에 배포하여 운영하는 방안을 권장합니다. 이때 각 서비스별로 Replicas를 조절하며 오토스케일링을 설정하고, ConfigMap/Secret으로 환경설정을 주입하는 형태로 운영하면 좋습니다. Boot는 쿠버네티스와도 잘 어우러지며, Spring Boot Actuator의 liveness/readiness 프로브를 이용해 Kubernetes의 헬스체크와 연동도 가능합니다.
• REST API 디자인: 클라우드에서는 각각의 서비스가 RESTful API (또는 gRPC 등)를 통해 통신합니다. REST API는 명확한 경로와 HTTP 메서드로 설계하고, API 스펙은 명세서(OpenAPI/Swagger)로 관리하면 협업에 용이합니다. Boot에서는 springdoc-openapi 같은 라이브러리를 쓰면 자동으로 API 문서를 생성할 수 있어 유용합니다. 또한 REST API 디자인 시 DTO와 엔티티 분리, 에러 처리 표준화 등을 신경써서, 서비스 간 계Contract가 명확하도록 합니다. 이러한 API 우선 설계는 향후 다른 클라이언트(모바일, 외부 파트너 등)와 통신하거나 시스템을 확장하는 데 기반이 됩니다.
• 상태 관리: 클라우드 환경에서는 무상태(stateless) 서비스를 지향해야 합니다. 세션이나 파일을 로컬에 저장하지 말고, 필요하면 Redis 같은 외부 저장소를 써서 세션 클러스터링을 구현합니다. Spring Boot에서는 Spring Session 등을 이용해 Redis 세션 스토리지를 사용할 수 있습니다. 또한 파일 업로드 등도 클라우드 스토리지(S3 등)를 이용하고 애플리케이션 인스턴스는 상태를 갖지 않도록 설계합니다. 이러면 새로운 인스턴스를 자유롭게 추가하거나 종료해도 서비스 일관성에 문제가 없습니다.

Spring Cloud 사용 여부에 대해서는, 현재 시스템 규모와 필요성에 따라 선택하면 됩니다. 마이크로서비스 아키텍처를 본격 도입한다면 Spring Cloud의 구성요소(Eureka, Config, Gateway 등)를 사용하는 것이 개발 생산성과 표준화에 이점이 있습니다. Spring Cloud는 마이크로서비스 구축을 위한 종합 플랫폼 역할을 하므로, 팀 내에 해당 기술 스택에 대한 이해도가 있다면 적극 활용을 고려하세요. 다만 서비스 규모가 작거나 Kubernetes 등의 플랫폼 기능으로 대체 가능하다면, Spring Cloud를 꼭 사용하지 않더라도 됩니다. 예를 들어 Kubernetes 사용 시에는 자체 서비스 디스커버리와 ConfigMap 등이 있으므로 Eureka나 Spring Cloud Config 없이 구현 가능하며, Istio 서비스메쉬를 쓴다면 서킷브레이커/트레이싱 등을 별도 코드 수정 없이 제공받을 수도 있습니다. 결론적으로, 클라우드 이행 아키텍처는 Spring Boot 마이크로서비스 + 필요한 Spring Cloud 모듈 조합으로 구성하고, 인프라 플랫폼의 기능과 적절히 조화를 이루도록 설계하는 것을 권장합니다. 이를 통해 확장성과 안정성을 갖춘 클라우드 네이티브 애플리케이션으로 발전시킬 수 있습니다.

8. 단계별 마이그레이션 로드맵 제안

마지막으로, 위에서 논의한 내용을 종합하여 Spring Boot 전환 및 클라우드 이행을 위한 단계별 로드맵을 제안합니다. 전체 과정을 몇 개의 Phase로 나누고 각 단계에서 수행할 작업과 목표를 정의하면, 체계적으로 마이그레이션을 진행할 수 있습니다:

1. 사전 분석 및 계획 수립: (Assessment & Planning)
   • 시스템 분석: 기존 레거시 시스템의 모듈 구성, 의존 관계, 사용 프레임워크/라이브러리 목록을 인벤토리합니다. 특히 Servlets, Spring 4, MyBatis, Tomcat 관련 설정과 코드들을 모두 정리하세요.
   • 기술 부채 파악: Deprecated되었거나 업그레이드가 필요한 부분(Java 8 -> 17, Spring 4 -> 6 등)을 식별합니다. 이 단계에서 잠재적인 문제(예: Jakarta 네임스페이스 변경으로 인한 컴파일 오류 예상 지점)를 예측해두면 좋습니다.
   • 마이그레이션 전략 결정: 전체를 한번에 전환할지, 모듈별로 점진 전환할지 결정합니다. 권장하듯이 점진적(refactoring-first) 접근을 선택하고, 우선 순위를 정합니다. 예를 들어 위험도가 낮고 공통 모듈인 부분부터 먼저 Boot로 옮기는 계획을 세울 수 있습니다. 또한 모놀리식 vs 마이크로서비스 재구조화 여부도 이 단계에서 큰 그림을 결정해야 합니다. 현재 시스템을 그대로 Boot로 옮긴 후 추후에 서비스를 분리할 것인지, 처음부터 일부 기능은 분리할 것인지 고려합니다.
2. 개발 환경 준비 및 기본 구조 구성:
   • 개발 환경 업그레이드: Java 17 등 필요한 JDK를 설치하고, 팀원들의 개발 환경(Eclipse/IDEA 설정 등)이 새로운 버전에 맞게 세팅되도록 합니다. 또한 Spring Boot 3.x의 프로젝트 구조에 익숙해지도록 기본 템플릿을 하나 생성해보는 것도 좋습니다.
   • 프로젝트 변환(POM 설정): 기존 Maven 프로젝트의 pom.xml을 수정하여 spring-boot-starter-parent와 Spring Boot 스타터들을 추가합니다. 겹치는 Spring 라이브러리 의존성(예: spring-core, spring-webmvc 등)은 제외하거나 버전을 제거합니다.
   • 메인 클래스 생성: {Application}.java라는 SpringBootApplication 애플리케이션 클래스를 생성하고 @SpringBootApplication을 부여합니다. 여기서 기존 xml 설정을 대체할 기본 패키지 구조와 컴포넌트 스캔 범위를 정합니다. 메인 클래스의 main() 메서드에서 SpringApplication.run을 호출하여 실행 진입점을 설정합니다.
   • 테스트 빌드: 일단 Boot 애플리케이션 골격이 잡혔다면 mvn spring-boot:run 또는 IDE에서 실행하여 빈 로딩 테스트를 해봅니다. 아직 기능을 모두 이관하지 않더라도, 환경이 제대로 구축됐는지 확인합니다. 에러가 난다면 의존성 충돌이나 누락된 설정을 바로 잡습니다.
3. 코드 및 설정 단계적 마이그레이션: (Refactor & Migrate)
   이 단계에서는 실제 애플리케이션의 기능들을 Spring Boot로 하나씩 옮겨옵니다.
   • 설정 이관: 먼저 설정 파일들을 이관합니다. 기존 *.properties 또는 XML에 있던 설정을 application.properties(또는 .yml)로 합칩니다. DB 연결정보, MyBatis 설정, 포트 등 핵심 설정을 옮겨놓습니다. 또한 XML 설정(예: 스프링 빈 정의)을 대부분 자바 설정으로 대체하거나 Boot 자동구성이 커버하도록 조정합니다. web.xml의 필터, 서블릿 설정 중 계속 필요한 것은 Spring Boot 방식으로 재등록합니다 (예: FilterRegistrationBean 활용).
   • 데이터 접근 레이어 이행: MyBatis 연동을 Spring Boot 환경으로 전환합니다. 위 4번 항목에서 설명한 대로 MyBatis 스타터를 적용하고 Mapper 인터페이스에 애노테이션을 추가해줍니다. 또한 트랜잭션 관리(@Transactional) 설정이 누락되지 않도록 Spring Boot 메인 클래스에 @EnableTransactionManagement가 필요하면 붙이거나(대부분 자동 설정됨), 서비스 클래스에 @Transactional을 유지합니다. 이때 Boot에 기본 포함된 HikariCP로 ConnectionPool이 바뀌므로, 커넥션 관련 설정(maxPoolSize 등)을 조정합니다.
   • 웹 레이어 이행: 컨트롤러 및 뷰 부분을 이관합니다. 기존 Servlets를 Spring MVC @Controller로 변경하고 URL 매핑을 애노테이션으로 처리합니다. JSP 뷰는 /templates나 기존 경로에 배치하고, 필요 시 ViewResolver 설정을 추가합니다. JSP 대신 Thymeleaf로 일부 변환을 검토할 수도 있습니다. 요청 필터나 인터셉터 로직은 Spring Boot에서 각각 Filter Bean이나 HandlerInterceptor로 등록하여 이어지도록 합니다. 웹 레이어 이행 후 Postman 등으로 기본적인 URL 응답을 테스트합니다.
   • 비즈니스 로직 및 기타: Service, Domain 계층의 코드는 대체로 변경 없이 동작할 것입니다. 다만 Spring 4 -> Spring 5/6 변경에 따라 @Autowired 동작이나 예외 처리 부분에서 미세한 차이가 있을 수 있으므로 컴파일 오류와 경고를 수정합니다. 예를 들어 @Autowired 필드 주입 대신 생성자 주입으로 리팩토링하는 등의 개선을 함께 진행하면 좋습니다. 또한 Spring 4에서 사용한 오래된 유틸(예: Apache Commons DBUtils 등)이 Java 8 스트림이나 새로운 라이브러리로 대체 가능한지 검토해보고, 성능에 도움된다면 교체합니다.
   • 공통 기능 마이그레이션: 로깅 설정(log4j -> logback), 보안 설정(Spring Security 사용 시 config 클래스 재작성), 스케줄러 사용 시 @Scheduled 설정 등 기타 모든 부분을 빠짐없이 옮깁니다. 특히 에러 처리 부분은 Boot에서는 기본 /error 매핑 등이 적용되므로, 기존에 custom exceptionResolver를 썼다면 Spring Boot @ControllerAdvice로 변경하는 등 처리가 필요합니다.
   • Jakarta 전환 검증: 코드 수준에서 javax -> jakarta 변경이 다 반영됐는지 마지막으로 점검합니다. 예를 들어 서블릿 필터 구현체에서 javax.servlet.Filter를 구현했다면 컴파일 오류가 날 것이므로 jakarta.servlet.Filter로 수정해야 합니다. 이런 부분을 IDE 검색 등으로 찾아 모두 수정합니다.
   Tip: 하나의 거대한 단계로 진행하기보다, 모듈별로 작은 단위로 위 작업을 반복 수행하는 것이 좋습니다. 예를 들어 "사용자 관리 기능부터 Boot로 전환 완료 -> 주문 관리 기능 전환 완료" 식으로 순차적으로 영역을 완료시키면 각 단계마다 애플리케이션이 점진적으로 Boot화 되고 테스트도 용이합니다. 이러한 incremental migration 방식은 문제 발생 시 디버깅 범위가 작아지고, 점진적 커밋/배포가 가능해져 리스크가 줄어듭니다. 가능하다면 기존 레거시 앱과 새 Boot 앱을 동시에 구동하여 일부 트래픽을 신버전으로 라우팅해보는 (블루그린 또는 카나리아 배포) 전략도 고려할 수 있습니다.
4. 테스트 및 검증: (Testing & Validation)
   • 유닛 테스트: 이행한 코드에 대해 단위 테스트를 실행하여 기본적인 동작을 확인합니다. Spring Boot Test(slice 테스트나 @SpringBootTest)를 활용해 컨텍스트 로딩과 빈 주입이 정상인지 검증합니다. 레거시에서 사용하던 테스트 코드는 신규 프로젝트에 맞게 업데이트하여 재활용합니다.
   • 통합 테스트: MyBatis를 통한 DB 쿼리 실행, MVC 컨트롤러 응답 등을 통합 테스트합니다. Test용 임베디드 DB나 H2 등을 활용할 수도 있고, 실제 DB 개발계정에 연결하여 쿼리를 검증할 수도 있습니다. 주요 비즈니스 시나리오에 대한 테스트 케이스를 작성하여 기능 회귀 여부를 점검합니다.
   • 성능 테스트: JMeter나 Gatling 등을 이용해 전환된 서비스의 성능을 측정합니다. 동일 부하에서 레거시 대비 응답시간, 자원 사용량(CPU, Memory)을 모니터링해보고, 목표한 개선이 이루어졌는지 확인합니다. 만약 성능이 예상보다 낮다면 앞서 언급한 설정 튜닝을 다시 살펴봅니다 (예: 스레드 풀, DB 커넥션 풀, 객체 직렬화 방식 등).
   • 병행 운영 테스트: 가능하다면 새로운 Spring Boot 애플리케이션을 기존 환경과 병행 운영하여 결과를 비교합니다. 예를 들어 일부 테스트 사용자 트래픽을 Boot 버전에만 연결해 기능이 동일하게 동작하는지 본다든지, A/B 테스트를 통한 사용자 피드백을 받는 등의 방법입니다. 최종적으로 기능적으로나 비기능적으로 모두 레거시와 동등 또는 그 이상의 품질이 확인되어야 합니다.
5. 배포 및 전환 실행: (Deployment & Cutover)
   • 클라우드 인프라 준비: AWS, Azure, GCP 등이든 Kubernetes든, 대상 클라우드에 필요한 자원을 세팅합니다. 예를 들어 AWS EKS 클러스터를 만들고, RDS나 필요한 매니지드 서비스도 준비합니다. 네트워크 구성 및 보안그룹/방화벽 설정도 검토합니다. CI/CD 파이프라인(Jenkins, GitHub Actions 등)을 구축하여 Spring Boot 애플리케이션을 도커 이미지로 빌드하고 배포하는 자동화를 마련합니다.
   • 모니터링 설정: 클라우드 환경에서 애플리케이션 모니터링을 위해 Prometheus, Grafana, CloudWatch, Application Insights 등 모니터링 도구를 붙입니다. Spring Boot Actuator의 엔드포인트(metrics, health 등)를 활용하여 지표를 수집하고, 로깅은 ELK 스택이나 Cloud Logging에 모아서 볼 수 있도록 설정합니다.
   • 릴리즈 전략 수립: 배포 시 가용성을 최대화하기 위해 배포 전략을 선택합니다. 블루-그린 배포, 롤링 업데이트, 카나리아 배포 중 환경에 맞는 방식을 적용합니다. 예를 들어 현재 두 대의 서버로 운영 중이라면, 먼저 한 대에 Boot 버전을 올리고 테스트한 뒤 문제가 없으면 다른 한 대를 전환하는 블루-그린 방식으로 무중단 배포를 시도할 수 있습니다. 실제 사용자 트래픽을 이전하기 전에 최종 리허설을 해보고 롤백 전략도 마련해 둡니다.
   • DNS/라우팅 전환: 새로운 Spring Boot 서비스로 완전히 전환할 준비가 되면 로드밸런서나 DNS 설정을 변경하여 트래픽을 레거시에서 Boot 서비스로 넘깁니다. 만약 마이크로서비스로 쪼갰다면, 각각의 서비스에 대한 라우팅을 API Gateway에서 신버전 서비스의 주소로 바꿉니다. 이 시점에 사용자에게는 전환이 투명하게 이뤄지도록 해야 합니다.
   • 최종 운영 및 모니터링: 전환 직후 시스템을 면밀히 모니터링합니다. CPU, 메모리, 에러 로그, 응답시간 등을 실시간 체크하여 이상 징후가 없는지 확인합니다. 문제가 발견되면 즉시 롤백할 수 있도록 대비하고, 심각한 문제가 없으면 일정 기간(예: 며칠~몇 주) 신중하게 관찰합니다.
6. 사후 최적화 및 고도화:
   • 불필요한 구성 정리: 레거시를 완전히 종료했다면, 남은 미사용 인프라(Tomcat 9 서버, 옛 배포 스크립트 등)를 정리합니다. 또한 프로젝트 레포지토리에서 사용되지 않는 옛 설정 파일이나 클래스도 제거합니다.
   • 최적화: 운영 결과를 바탕으로 튜닝 작업을 이어갑니다. 예를 들어 메모리 Xmx 조정, GC 옵션 튜닝, Hotspot 난이도가 높은 쿼리 수정 등을 진행합니다. Spring Boot 전환으로 새롭게 생긴 가능성 (예: Redis 캐시 도입, MQ 비동기 처리 등)들을 검토하여 성능과 안정성을 더 높일 수 있습니다.
   • 개선 사이클: 클라우드 환경에서 요구되는 CI/CD 파이프라인을 정교하게 다듬고, 개발 팀의 운영 절차를 Boot 중심으로 문서화합니다. 또한 Spring Boot 및 사용 라이브러리의 정기 업그레이드 전략도 수립하여 (예: Spring Boot의 minor 업그레이드는 즉시 적용, major 업그레이드는 별도 프로젝트 등) 지속적으로 최신 기능과 보안 패치를 받을 수 있게 합니다.

위 로드맵은 상황에 따라 병행되거나 순서가 바뀔 수도 있지만, 큰 틀에서 분석 → 준비 → 전환 구현 → 테스트 → 배포 흐름으로 진행됩니다. 각 단계마다 명확한 완료 조건(예: "모든 테스트 통과", "성능 목표 달성", "무중단 배포 완료")을 정해두면 프로젝트 관리에 도움이 됩니다. 무엇보다 핵심은 작게 나누어 검증하며 진행하는 것입니다. 한 번에 모두 바꾸려 하면 위험이 크므로, 단계별로 결과물을 확인하고 다음 단계로 넘어가는 방식이 성공 확률을 높입니다. 이렇게 하면 예기치 못한 문제가 생겨도 범위를 좁혀 대응할 수 있고, 결국 관리 가능한, 검증된 단계들의 연속으로 대규모 전환을 완수할 수 있습니다.

각 단계를 완료할 때마다 관련 부서(QA, 운영 등)와 협업하여 승인(sign-off)을 받고 넘어가도록 하면 품질을 담보하면서 일정을 진행할 수 있습니다. 마지막으로, 마이그레이션 완료 후에는 성과를 측정하고 (성능 개선 수치, 장애 감소 등) 이를 공유함으로써 향후 시스템 개선 작업에 대한 피드백으로 삼으시면 좋겠습니다.