Dev Stories

첨단의 클라우드, 늘어나는 수작업, AICE 수작업 탈출기!

시작하며

컴퓨터가 처음 등장한 이후 일의 효율성은 언제나 중요한 주제였습니다. 최근 인공지능(AI) 기술이 비약적으로 발전하면서, 이제는 혼자서 훨씬 많은 일을 처리할 수 있을 뿐만 아니라 한 사람이 하나의 사업을 완결짓는 시대가 되었습니다. 요새 흔히 보이는 "1인 개발자"나 "1인 창업" 같은 모습이 대표적인 예입니다.

그렇다면 인터넷 서비스를 유지하고 관리하는 "시스템 운영" 영역은 어떨까요? 개발 분야에서 일어난 변화처럼 운영 업무도 혼자서 다 할 수 있을 만큼 쉬워질 수 있을까요?

개발과 운영은 성격이 꽤 다릅니다. 개발은 정해진 기간 내에 원하는 기능들을 만들어내는 것이 핵심이라면, 운영은 정해진 규칙 없이 불쑥 찾아오는 크고 작은 문제들을 빠르게 발견하고 해결하는 것이 핵심입니다.

서비스의 인기가 많아지고 기능이 추가될수록 전체 시스템은 더 복잡해지고, 그에 따라 예기치 못한 문제나 장애도 늘어나기 마련입니다. 예기치 않은 문제를 완전히 안 생기게 막기는 어려우므로, 핵심은 "문제가 생겼을 때 얼마나 빨리 알아채고 자동으로 바로잡을 수 있는가"로 귀결 됩니다.


클라우드의 장점과 새로운 숙제

"클라우드"의 등장으로 기존에는 서비스의 기획과 개발에 수반되는 기술부채 등으로 감히 시도하기 어려웠던 것들을 편하게 사용하게 됨으로써 더 많은 것들을 도전할 수 있게 되었습니다. 비싼 장비를 직접 사서 설치할 필요가 없고, 사용자가 몰릴 때 필요한 만큼만 시스템을 사용후 사용량이 적을 때는 필요없는 자원을 반납해서 불필요한 비용을 줄이는 것도 가능해졌습니다.

하지만 클라우드를 쓴다고 해서 모든 문제가 저절로 해결되지는 않았습니다. 특히 사용량에 따라 가상 서버가 새로 생겼다 사라지는 일이 반복되다 보니, 진행 중이던 작업 정보(상태)를 중간에 잃어버리지 않고 일정하게 유지하는 것이 더 큰 숙제가 되었습니다. 문제가 터졌을 때 어떤 가상 서버에서 왜 오류가 났는지 추적하기도 더 어려워졌습니다.

시스템 운영이 복잡해지는 이유 중 가장 대표적인 것은 서비스가 고객의 개인 상태나 이전 행동 기록을 기억하고 맞춰서 동작해야 할 때입니다. 이 개념을 아주 쉽게 비교해 볼 수 있습니다.
  • 맥락유지형(Stateful): 온라인 쇼핑 시 고객이 장바구니에 담은 상품이나 선택한 결제 수단(현금, 카드, 쿠폰 등)에 따라 가격을 조정하거나 맞춤 상품을 추천하는 등 맥락에 맞춰 대응하는 방식입니다. 정교하지만 기억해야 할 정보가 많아 관리가 복잡해집니다.
  • 독립판단형(Stateless): 온라인 쇼핑에서 결제 시 현금, 카드, 쿠폰 등 어떤 수단을 사용하더라도 이전 구매 기록과 관계없이 요청된 각 건을 독립적으로 처리하는 방식입니다. 과거 상태를 기억할 필요가 없어 단순하고 안정적입니다.

운영 시스템이 복잡해지는 이유는 대부분의 서비스가 "맥락유지형(Stateful)" 이라는 사실에 기인하는데, 초기에 단순한 업무나 프로세스들이 서비스의 발전이나 업무의 확장 등에 따라 더 많은 서비스의 구성요소들이 복잡하게 발전하는 경향이 있습니다. 다행히 이러한 문제들을 해결하는데 활용 할 수 있는 다양한 자동화 기법과 도구들이 발전하고 있습니다.

쿠버네티스(Kubernetes)와 같은 클라우드 솔루션들에서는 이런 문제를 직접적으로 지원하고자 클라우드 환경에서 관리하는 다양한 자원과 작업을 다루는 복잡한 운영 업무를 자동화 할 수 있는 Kubernetes Operator와 같은 도구를 제공합니다. Kubernetes Operator의 경우, 도메인 종속적인 업무요소를 정의해서 그것이 생성되어 변경되고 용도를 만료하는 단계까지 각각의 진행상태에 따라 취할 수 있는 작업들을 정의해서 업무를 자동화 할 수 있다.


AICE 사례: 수작업 준비 방식의 한계

AICE는 AI 활용 능력을 실기 시험으로 평가하는 자격시험입니다. 국가공인자격으로 인정받으면서 응시자가 크게 늘어났고, 앞으로 해외 서비스까지 계획하고 있어 훨씬 많은 응시 인원을 감당해야 하는 상황이 되었습니다.

실기 시험 특성상 컴퓨터 자원을 많이 사용하는데, 특히 시험을 치르는 특정 시간에만 요청이 몰리는 특징이 있습니다. 그래서 처음부터 유연하게 서버를 늘리고 줄일 수 있는 클라우드 기반의 분산 구조로 설계하여 운영 비용을 줄일 수 있었습니다. 이 덕분에 얻은 주요 장점은 다음과 같습니다.
  • 문제 격리: 한곳에 문제가 생겨도 다른 곳으로 확산되지 않음
  • 유연성: 필요한 기능을 빠르게 개선하고 반영함
  • 확장성: 응시자 수에 따라 시스템 크기를 자유롭게 조절함
  • 생산성: 개발과 관리 효율이 올라감
정도로 요약해 볼 수 있습니다.

하지만 시험 진행 과정에서 사람이 직접 개입해야 하는 수작업이 남아있다는 점이 문제였습니다. 응시자가 몇백 명일 때는 수작업을 하더라도 별 문제가 없었지만, 응시자의 규모가 사람이 직관적으로 관리 할 수 있는 수준을 넘어가고 동시에 진행하는 시험이 많아짐에 따라 일관적으로 시스템을 모니터링하면서 문제를 식별하고 조치하는 것이 거의 불가능해졌습니다.

온라인 시험처럼 시간의 흐름이나 진행 단계에 따라 처리할 내용이 달라지는 시스템은 관리하기 까다로운 맥락유지형 서비스(Stateful)의 전형입니다. 변동성이 높은 클라우드의 특성상 서비스의 맥락을 유실할 위험이 항상 내재하므로, 이를 안전하게 관리 할 수 있는 방식과 도구를 꼭 적용해야 합니다.

시험 시작부터 종료까지 필요한 시스템 자원을 제때 자동으로 할당하고, 시험이 끝나면 회수하는 전 과정을 자동화해야 했습니다. 특히 예기치 못한 문제가 생겼을 때 이를 알아채고 스스로 바로잡는 기능이 필수적이었는데, 앞서 언급한 Kubernetes Operator가 이 역할을 맡게 되었습니다.

이미지
[ 그림1: AICE 시험 단계별 상태 변화와 자동 관리 작업 ]


AICE: 근본적인 해결을 위한 자동화 구축

기존에는 사람이 직접 감당할 수 있는 수준으로 응시 인원을 제한해야만 했습니다. 이를 극복하기 위해 수작업에 의존하던 시스템 구조를 완전히 새로 개편했습니다.

 새 아키텍처의 중심에는 사람이 하던 복잡한 관리를 대신해 주는 시험운영자(Kubernetes Operator)가 위치합니다.

이미지
 [ 그림2: AICE 자동화 시스템 구성도 ]

개편의 핵심 원리는 간단합니다. 관리가 필요한 시험 상태는 시험운용자가 알아서 처리하게 만들고, 나머지 서비스 구성 요소들은 언제든 교체 가능한 "독립판단형 상태(Stateless)"로 만들어 운영 복잡도를 최소화한 것입니다. 그 결과 다음과 같은 이점을 얻을 수 있었습니다.
  • 운영 자동화: 운영자가 수작업으로 하던 시험 환경 준비 및 정리 작업을 프로그램이 자동으로 처리
  • 자동 용량 조절: 시험 응시자 수와 접속 부하에 따라 서버 크기가 자동으로 늘어나고 줄어듦
  • 자가 복구: 시스템에 오류가 생기면 스스로 감지하여 정상 상태로 자동 복구
  • 무중단 업데이트: 일부 시스템을 업데이트하거나 재배포해도 시험 서비스는 중단 없이 계속 유지됨
정도로 정리할 수 있습니다. 

결과적으로 시험 환경 준비부터 자원 회수, 갑작스러운 문제 대응까지 사람이 직접 개입할 필요를 최소화하여 대규모 시험도 안정적으로 치를 수 있게 되었습니다.


글을 마치며

지나고 보면 명백한 것들이 겪어보기 전에는 의심을 하게 되는 것들이 많이 있습니다. 특히 ‘사용주의’라는 꼬리표가 붙은 것들이라면 더더욱 사용이 망설여 지는 것은 어쩔 수 없는 현상으로 보입니다. IT에서도 당연히 이러한 현상을 피할 수는 없겠지만, 다행인 것은 이러한 새로운 것들을 빠르고 쉽게 경험 할 수 있는 방법이 많이 생겨서 개념적인 이해로만 결정할 필요가 없다는 것입니다. 특히, 최근 AI 기반의 도구들은 그마저도 더 쉽게 할 수 있는 방법들을 제공하고 있습니다. 

시스템은 그 목적에 따라 너무나도 다양한 종류가 있기 때문에 어떻게 개발하는 것이 좋은 방향이라고 일반화 하는 것은 어려워 보입니다. 하지만, 그 와중에 몇가지 원칙을 찾는다면 그 중 하나가 “가능한 Stateless하게 유지하라”고 말하고 싶습니다. Stateful 구성 요소가 하나 둘 생길 때는 못느끼지만 어느듯 그런 요소와 처리 범위가 넓어지면 상상의 범위를 넘어서는 복잡한 세상으로 발전하는 것이 흔한 일이기 때문입니다. 

저의 사례로 공유하고자 한 내용은 서비스의 Stateful 요소로 인해 야기되는 수작업을 최소화하기 위한 방법이었습니다. Stateful 요소를 없앨 수는 없지만 더 전문화된 도구로 자동화로 처리하고 나머지 구성요소들을 Stateless하게 유지하는 것이 주요 내용이었습니다. 유사한 사례에 도움이 되기를 바라겠습니다.


전상윤

AICE 자격인증 서비스를 기획 및 개발하고 있습니다.

←이전 글
첨단의 클라우드, 늘어나는 수작업, AICE 수작업 탈출기! - kode