공공기관 SI 프로젝트 시스템 설계 방식

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 계열이 표준처럼 사용됩니다. 전자정부 표준프레임워크도 Spring Framework 기반 MVC 구조이며, 공공프로젝트 상당수가 Spring MVC 또는 Spring Boot를 채택합니다. Java는 안정성과 인력 수급 면에서 선호되어 왔고, 최근에는 Spring Boot + JPA로 생산성을 높이는 추세입니다. 과거 .NET(C#)이나 PHP로 개발된 사례도 일부 있으나, 범정부 표준화 이후 Java 점유율이 매우 높습니다. 대용량 트래픽 서비스나 실시간 분석용으로는 Python(Django/Flask), Node.js(NestJS 등)를 부분 도입하는 경우도 있으나 주류는 아닙니다.
프론트엔드 기술	과거에는 JSP + jQuery 조합이 주로 쓰였고, 별도 프론트엔드 개발자 개념 없이 화면구현을 했습니다. 최근 웹 표준과 UX 중요성이 높아지며 React, Vue.js 등의 모던 JavaScript 프레임워크 도입이 늘었습니다. 2019년경부터 Vue.js가 각광받아 공공 분야 기술표준에 추가되기도 했고, 현재는 React가 민간 뿐 아니라 공공 웹개발에서도 강세입니다. 예를 들어 정부 포털 개편 사업에서 React 기반 SPA로 구현하는 사례가 있습니다. TypeScript도 점차 활용되어, 대규모 프로젝트의 유지보수성을 높이고 있습니다. 다만 일반 행정시스템의 경우 화면 구성이 복잡하지 않아 Vanilla JS나 jQuery로 유지되는 곳도 많습니다. 모바일 앱 개발은 필요시 하이브리드 앱(웹뷰) 또는 React Native, Flutter 등을 활용합니다. 프론트엔드 개발에서는 웹표준과 웹접근성 준수가 필수인데, 「지능정보화기본법」 등에 따라 모든 공공 웹페이지는 웹 접근성(KWCAG 2.1) 준수를 의무화하고 있어 폰트 대비, 대체텍스트, 키보드 내비게이션 등이 지켜지도록 개발합니다.
DBMS(데이터베이스)	Oracle Database가 오랫동안 주력 DB로 사용되어 왔습니다. 많은 범정부 시스템이 Oracle로 구축되었고, 안정성 때문에 선호되었습니다. 그러나 라이선스 비용 절감과 기술 자립도 향상을 위해 국산 DBMS 채택도 늘었습니다. 대표적으로 티맥스 Tibero는 성능이 Oracle 11g와 유사할 정도로 검증되었고, 현재 행정안전부, 법원 등 다수 공공기관에서 Oracle 대안으로 활용 중입니다. Tibero는 2023년 해킹 사고 이슈에서도 나타났듯 정부∙대기업 등 약 1,400곳에서 사용될 만큼 보급되었습니다. 이외에 오픈소스 DB로 **PostgreSQL, MySQL(MariaDB)**도 일부 도입 사례가 있습니다. 특히 공공 클라우드 환경에서는 PostgreSQL(Amazon RDS 등) 이용이 증가추세입니다. 다만 중요 업무계에선 지원 이슈로 상용 DB를 선호하는 경향이 남아있습니다. 이밖에 특수 용도로 NoSQL DB(MongoDB, Elasticsearch 등)를 로그관리나 빅데이터 처리에 병행 사용하는 경우도 있습니다.
WAS 및 서버	전통적으로 **Web Application Server(WAS)**로는 **JEUS(Tmax)**와 WebLogic(Oracle), WebSphere(IBM) 등이 쓰였습니다. 국내 공공시장에서 Tmax JEUS는 성능과 기술지원 측면에서 널리 채택되었고, 다수 기관 표준 WAS로 자리잡았습니다. 한편 비용 절감을 위해 JBoss EAP나 Tomcat을 쓰는 곳도 있습니다. Spring Boot 기반 마이크로서비스는 내장 톰캣으로 구동하거나, 경량 서버(Spring WebFlux+Netty 등)를 사용합니다. 웹서버는 Apache HTTP Server를 가장 많이 사용하며, 윈도우 환경에 IIS를 쓰거나, Nginx를 Reverse Proxy로 사용하는 사례도 있습니다. 공통 프레임워크가 WAS/DB 벤더 종속 없이 J2EE 표준으로 동작하도록 설계되어 있어, 기관마다 상용 WAS와 오픈소스 WAS를 자유롭게 택할 수 있습니다. 운영체제(OS)는 과거 유닉스 계열(HP-UX, AIX)이 많았으나 현재는 **Linux(Red Hat, CentOS 등)**이 주류입니다. 서버 가상화 또한 일반적이며, 최근 컨테이너 기반 OpenShift, Kubernetes 도입도 일부 진행되고 있습니다.

이와 같이 백엔드에는 안정적인 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 프로젝트는 민간과 달리 법/제도적 요구사항과 공익성을 중시하기 때문에, 설계 단계부터 오늘 살펴본 바와 같은 방식으로 치밀하게 준비하여 추진되고 있습니다.