【드래곤 스포츠】 보증업체놀이터추천홍보 : 프로그램제작판매제작의뢰 : 스포츠분석 : 무료스포츠중계tv : 섹시bj움짤 : 뉴스 : 안구정화

로그인

글쓰기

[IT뉴스]자칫하면 결제 오류·물류 마비까지…시스템 장애 막는 GS리테일의 비법

온카뱅크관리자

2026-10-28 15:37:25

<div id="layerTranslateNotice" style="display:none;"></div> [인터뷰] 이형석 GS리테일 AX본부 클라우드인프라팀 엔지니어 
 <div class="article_view" data-translation-body="true" data-tiara-layer="article_body" data-tiara-action-name="본문이미지확대_클릭"> 
 <section dmcf-sid="XmLHyrfzSm">
 <figure class="figure_frm origin_fig" contents-hash="72314d0c79995fbcc6cd3435097199b0883a659c5c5e13305d3c2d4236d86cfb" dmcf-pid="ZsoXWm4qCr" dmcf-ptype="figure">
 <img class="thumb_g_article" data-org-src="https://t1.daumcdn.net/news/202610/28/552796-pzfp7fF/20261028153015828yrvw.jpg" data-org-width="640" dmcf-mid="WoK9q5NdhC" dmcf-mtype="image" height="auto" src="https://img2.daumcdn.net/thumb/R658x0.q70/?fname=https://t1.daumcdn.net/news/202610/28/552796-pzfp7fF/20261028153015828yrvw.jpg" width="658">
 </figure>
 [디지털데일리 김보민기자] 한국을 대표하는 종합 유통회사를 꼽자면 GS리테일을 빼놓을 수 없다. 길거리 곳곳을 밝히는 편의점 'GS25'부터 슈퍼마켓 'GS더프레시', 홈쇼핑 'GS샵'까지 GS리테일이 운영하는 사업 거점들은 우리 일상 곳곳에 스며들어 있다. 여기에 '우리동네GS' 앱을 기반으로 온·오프라인을 잇는 유통망도 본격 가속도를 타고 있다.
 이는 한 번의 대형 시스템 장애가 서비스를 멈출 수 있다는 의미이기도 하다. 결제 오류부터 물류 마비까지, 예측하기 어려운 장애가 발생할 가능성도 있다. GS리테일은 지난해 말 DX본부를 AX본부로 개편하고 사이트신뢰성엔지니어(SRE) 기반을 강화하면서 원인 탐지와 해결을 고도화하는 데 집중하고 있다.
 이 과정에서 GS리테일은 인공지능(AI) 기반 옵저버빌리티 기업 데이터독을 선택했다. 수많은 워크로드를 AWS 클라우드로 운영하고, 모니터링 시스템을 데이터독으로 일원화해 풀스택 기반으로 관리하는 것이 핵심이다. 화면을 모니터링하는 RUM(Real User Monitoring)부터 서버 애플리케이션성능관리(APM), 데이터베이스(DB), 네트워크, 인프라 로깅까지 모든 스택을 단일 화면으로 관제할 수 있어 부서 간 단절(사일로)도 최소화했다.
 한 단계 나아가 AI가 장애를 자동 분석해주고 보고서까지 전달해주는 'SRE AI' 아키텍처도 구현했다. &lt;디지털데일리&gt;는 이형석 GS리테일 AX본부 클라우드인프라팀 엔지니어를 만나 GS리테일표 SRE 전략을 들어봤다.
 다음은 이형석 엔지니어와의 일문일답.
 <hr class="line_divider" contents-hash="0079938acfb26277c410746484f136ec9dde558d8eb553125438c8684c79c8a3" dmcf-pid="0Sc35lMVhA" dmcf-ptype="line">
 Q. 유통·리테일 분야에서 장애가 발생한다면 어떤 파급력이 있나.
 A. 온라인 서비스의 경우 장애가 발생하면 고객들이 로그인을 못하거나 결제가 안 되는 직접적인 불편을 겪게 된다. 오프라인 유형의 서비스에서 문제가 발생하면 각 점포에서 물건 발주를 제때 못하거나 물류 시스템에 문제가 생겨 재고 수불 처리가 안 돼 물리적인 물류와 운영 전반에 타격이 발생할 수 있다.
 <hr class="line_divider" contents-hash="a7eb43f27a415d39d21f44536a72f6e400b772c9eae5a333275dbf75f0f4f6c4" dmcf-pid="uhBcaxXSSa" dmcf-ptype="line">
 Q. GS리테일은 무(無)장애를 위해 어떤 SRE 전략을 세우고 있나.
 A. 기본적으로 사람이 하는 일이다 보니 장애는 날 수밖에 없다고 생각한다. 다만, 장애가 발생했을 때 얼마나 빨리 원인을 찾고 해결하는지에 대한 명확한 절차(프로세스)가 갖춰져 있느냐가 관건이다. 또한 동일한 장애가 재발하지 않도록 시스템이나 비즈니스 로직을 개선하는 등 어떤 노력을 기울이는지가 중요하다.
 GS리테일이 발표한 'SRE AI'도 이 맥락에서 출발했다. 기존에는 장애가 나면 사람이 정해진 프로세스대로 원인을 찾고 보고서를 쓰고 해결하느라 시간이 걸렸다. 장애가 비즈니스에 미치는 영향이 큰 만큼, AI가 사람이 쓰던 조사 도구들을 그대로 활용하게 해 장애 원인 파악과 해결 시간을 줄여보자는 목표로 시작하게 됐다.
 <hr class="line_divider" contents-hash="0d44924c12493fcae062076838b95832580f41e18107c527bddbcd87feaa1add" dmcf-pid="BT2wcdtWCn" dmcf-ptype="line">
 Q. 데이터독을 도입하기 이전에 GS리테일의 SRE 환경은 어땠나.
 A. 과거 GS리테일은 파편화된 환경에서 운영됐다. 중소업체에서 만든 모니터링 및 APM 솔루션을 각기 다르게 쓰고 있었다. DB 모니터링 역시 별도의 솔루션으로 나뉘어 있었다.
 가장 큰 문제점은 어떤 장애가 발생했을 때 로그 분석 시스템이 통합돼 있지 않아서 개발자가 일일이 서버에 접속해 로그를 확인해야 했다는 것이다. 게다가 DB 문제는 DB 관리자에게, 네트워크 문제는 네트워크 엔지니어에게, 인프라는 인프라 담당자에게 일일이 연락을 돌려야 했다. 철저히 사일로화돼 있다보니, 장애 원인이 애플리케이션이 아닐 경우 원인을 파악하는 데 너무 많은 시간이 소모됐다.
 클라우드 시스템을 올리면서 '하나의 통합 모니터링 플랫폼에 모든 데이터를 올려두고 누구나 직무에 상관없이 볼 수 있게 하자'는 목표를 삼은 이유다. RUM부터 APM, 인프라, DB, 네트워크 등 전반적인 상태를 하나에 모아 시스템 담당자가 자신의 문제 원인을 빠르게 진단하고 조치하도록 사일로를 깨는 데 노력을 기울였다.
 <hr class="line_divider" contents-hash="1b3a7368132ee989834e4ee2bcdd72a14c38acba4be78b27f289ef62104b8edf" dmcf-pid="VyVrkJFYSR" dmcf-ptype="line">
 Q. 옵저버빌리티 시장에 많은 벤더들이 있다. 데이터독을 택한 이유는.
 A. 클라우드 특성상 인프라, 애플리케이션 등 여러 영역을 한눈에 통합해 볼 수 있는 환경이 필수적이라고 생각했다. 당시만 하더라도 데이터독 한국 지사에 엔지니어가 10명도 채 안 되던 시절이었는데, 우연히 관리형서비스제공사(MSP) GS네오텍에서 데이터독이라는 솔루션을 소개해줬다. 검토해 보니 기능이 훌륭해 당시 이커머스 등 작은 시스템부터 시작해 데이터독을 적용하기 시작했다. 이후 조직 내에서 사용이 익숙해지고 새로운 시스템이 만들어질 때마다 데이터독이 기본으로 적용되기 시작했고, 점점 전사로 스며들게 됐다.
 (현재 데이터독 환경에서 가동되는 인프라와 애플리케이션 규모는) GS리테일의 AWS 계정만 200개 이상이고, 데이터독 Org도 20개 이상으로 운영되고 있다. 그 안에 들어가는 서비스는 너무 많아서 정확한 숫자를 세기 어렵지만, 마이크로서비스로 다 분리돼 있기 때문에 최소 1만개 이상은 훌쩍 넘는다. 거의 대부분의 서비스가 이미 데이터독으로 모니터링되고 있다.
 <hr class="line_divider" contents-hash="a23f21cdbb64fc35099e257d10c6b7298c2368b7faddc1ae75814de5ffa2af74" dmcf-pid="6H6IroUZhP" dmcf-ptype="line">
 Q. 'SRE AI'라는 개념이 신선하다. 구축을 결정한 계기는.
 A. 지난해 생성형 AI와 바이브 코딩 열풍(붐)이 일어났을 때, 저 역시 코덱스나 클로드 같은 AI 도구를 사용하면서 업무 효율이 비약적으로 올랐다. 그런데 업무 대부분이 개발자나 타 부서에서 들어오는 '지금 장애가 났는데 뭐가 문제인가요' 혹은 '이 시스템의 코드나 리포지토리는 어디에 있나요'와 같은 시스템 문의에 대답하는 것이라는 점을 깨달았다.
 처음에는 단순히 이러한 질의응답을 처리해줄 챗봇을 만들어야겠다고 기획하다 '장애에 대응하고 원인을 찾는 과정 자체를 AI가 스스로 하게 만들면 어떨까'라는 아이디어로 발전했다.
 처음 이를 설계할 때는 저 자신을 모델링했다. 무슨 일을 하는지 나열해보니 '모니터 알람을 받는다', '키워드를 보고 서비스를 인지한다', 'APM이나 DB모니터링 도구를 본다' 순서로 진행된다는 점을 포착했다. 이를 AI가 그대로 수행할 수 있도록 시스템 정보나 도구 사용법을 AI 메모리에 저장했다. 또한 주니어가 장애 보고서를 쓰면 선배가 교정해주듯, AI가 작성한 보고서도 평가하고 교정하게 했다. 다음에 실수하지 않도록 검색증강생성(RAG) 기반의 데이터 선순환 구조도 만들었다. 사람이 하는 방식과 최대한 동일하게 프로세스를 오케스트레이션(Orchestration)한 것이다.
 <hr class="line_divider" contents-hash="2af144b255e01cd30a399c758a338ffdf2382ecad7268fc51cd3b4808f30fef0" dmcf-pid="WLW6VpDgCV" dmcf-ptype="line">
 Q. 그렇다면 장애가 발생할 때 GS리테일표 SRE AI는 어떻게 작동하나.
 A. 프론트엔드 화면에서 에러 알람이 발생했다고 가정해보겠다. 이 현상의 원인은 서버 지연일 수도, 자바스크립트 에러일 수도, 백엔드 DB 오류나 네트워크 문제일 수도 있다. 사람이 5가지 가설을 세우듯 AI도 똑같이 가설을 세운다.
 <div contents-hash="e10e4f6275ac560f12c737465a81e2ee82c673287b8f3695675d3d301313190e" dmcf-pid="HhBcaxXSSK" dmcf-ptype="general">
 가장 먼저 데이터독의 RUM 알람을 확인해 단순 일회성 에러인지 지속적인 장애인지 판단한다. 알람이 지속된다면 AI가 코드 리포지토리에 들어가 프론트엔드 에러 로그와 소스코드를 대조한다. 이와 동시에 타 영역을 진단하는 도구들을 각각 호출해 검사한 뒤 '조사해봤으나 이쪽은 이상 없음'이라며 다른 가설들을 기각시킨다. 최종적으로 모든 조사를 마친 AI는 '프론트엔드 코드의 특정 비즈니스 로직에 결함이 있음'을 찾아내고 해당 코드를 어떻게 수정해야 하는지 권고안까지 포함해 보고서를 작성한다.
 </div>
 <figure class="figure_frm origin_fig" contents-hash="d6445eb1bafce6b67d22b46b793d11efc00fba6f1b82b34d121823bb27a3969d" dmcf-pid="XlbkNMZvyb" dmcf-ptype="figure">
 <img class="thumb_g_article" data-org-src="https://t1.daumcdn.net/news/202610/28/552796-pzfp7fF/20261028153017102trte.jpg" data-org-width="640" dmcf-mid="Ht9DAe1yls" dmcf-mtype="image" height="auto" src="https://img1.daumcdn.net/thumb/R658x0.q70/?fname=https://t1.daumcdn.net/news/202610/28/552796-pzfp7fF/20261028153017102trte.jpg" width="658">
 </figure>
 <hr class="line_divider" contents-hash="e802d073fb58274b602efa4f18802c07131dd6af581a6bd9c0690fd719fd61d2" dmcf-pid="ZSKEjR5TyB" dmcf-ptype="line">
 Q. SRE AI를 가동하는 핵심축은.
 A. SRE 오케스트레이션, 챗웹(ChatWEB), 모델콘텍스트프로토콜(MCP) 게이트웨이가 있다. SRE 오케스트레이션은 장애 분석 보고서를 작성하고 알람을 발송하며 ChatWEB은 추가적인 장애 원인에 대한 질의응답 창구 역할을 한다. SRE MCP 게이트웨이는 로컬에서 SRE 시스템의 각종 지표를 직접 호출하는 역할을 수행한다. 이 뒷단에는 AI가 서비스 간 문맥을 이해하게 해주는 그래프DB(온톨로지 데이터)와 과거 장애 이력 및 지식을 검색하는 S3 및 벡터 DB가 받쳐준다.
 <hr class="line_divider" contents-hash="e4cd998be39a0e35d0c6f85a8c15c34135c68685642d9d9f756dd27f3da7109e" dmcf-pid="tyVrkJFYl7" dmcf-ptype="line">
 Q. AI가 운영에 개입하면서 결과물에 대한 신뢰성을 해치거나, 과도한 권한을 방지해야 한다는 지적도 있다. 이에 대한 방지책이 있나.
 A. 제1원칙은 '사실(팩트)'에 기반'이다. AI가 멋대로 가설을 세우지 않도록 DB, 소스코드 등 조사 도구에서 추출한 실제 데이터를 기록해두고 이를 기반으로 추론과 분석을 진행하는 것이 기본이다. 가져온 원본을 반드시 보고서에 기재하도록 강제하는 것도 방법이다. 또한 품질관리(QA) 에이전트도 두고 있다. QA 에이전트는 AI 보고서를 평가한다. AI가 정해진 단계를 다 지켰는지, 누락된 시스템 프로필은 없는지를 평가해 보고서 하단에 A, B, C, D 등급과 그 이유를 댓글로 남겨 엔지니어가 판단할 수 있게 돕고 있다.
 민감 정보를 보호하기 위한 가드레일도 필요하다. 장애 원인을 찾기 위해 개인정보나 민감 데이터가 포함된 로그를 AI가 조회할 수 있지만, 그 내용을 보고서나 채팅창 알람 등 산출물에 절대 기입하지 못하도록 통제해 놓고 있다.
 <hr class="line_divider" contents-hash="440815a711dbc544eecb9cabbf0bc5607407580df27f3a79446dda9440c1ad17" dmcf-pid="pO7NL6YCv0" dmcf-ptype="line">
 Q. 향후 AI가 탐지·분석을 넘어 스스로 원인을 파악해 자동으로 장애를 해결하는 체계를 구축할 계획이 있나.
 A. 기술적으로 단순한 수준의 복구는 지금도 가능하지만, 단독으로 AI에게 모든 것을 맡기기에는 조심스럽다. GS리테일이 구상 중인 방법은 멀티 에이전트 교차 검증이다. GS리테일의 'SRE AI'와 데이터독에서 제공하는 'Bits AI'가 기반이 된다. SRE AI가 낸 분석 결과와 데이터독 환경 안에서 분석한 Bits AI 결과가 상호 일치할 때만 정해진 규칙(룰)에 따라 인프라 코드나 소스코드를 자동 수정하는 방식이 안전할 것으로 생각한다.
 물론 행정적인 제약도 있다. 사람이 장애를 내거나 복구를 잘못하면 해당 엔지니어의 이름이 보고서에 기입돼 책임을 져야 하지만, AI가 자동 복구를 하려다 실패해 추가 장애를 냈다면 이에 대한 책임소재와 원복 방법에 대한 기준은 모호하다. AI에게 어떤 권한을 부여할지 정립이 우선시돼야 한다. 그럼에도 불구하고 앤트로픽, 오픈AI 등 프론티어 모델들의 발전 속도가 예상을 뛰어넘을 정도로 빠르다. 이에 맞춰 GS리테일도 준비를 서두를 것이다.
 </section> 
 </div> 
 Copyright © 디지털데일리. All rights reserved. 무단 전재 및 재배포 금지.

댓글 총 0개

이번주 포인트랭킹

매주 일요일 밤 0시에 랭킹을 초기화합니다.

14,000상품권
23,000상품권
32,000상품권

업체홍보/구인 더보기

지식/노하우 더보기

판매의뢰 더보기

포토 더보기