최근에 AWS 제품군을 많이 쓰게 되다 보니, 시간이 맞으면 관련 행사에도 가급적 가보려고 합니다. 지난 10월 27일에는 Games on AWS 2026에 다녀왔는데요. 이번 행사는 정말 좋았습니다.
저희는 세 명이 일하는 작은 회사입니다. AI로 개발하는 일은 점점 편해지는데, 막상 서비스를 만들다 보면 데이터나 보안, 운영처럼 계속 걸리는 부분들이 있죠. 이번 발표들을 듣다 보니 ‘우리도 이 고민을 하고 있는데’ 싶은 내용이 정말 많았습니다. 먼저 해본 회사들이 어디서 막혔고 어떻게 풀었는지까지 이야기해 주니 더 재미있더군요.
행사는 더블트리 바이 힐튼 서울 판교에서 열렸고, 메가존클라우드와 GS네오텍이 주최했습니다. 세션과 발표자 정보는 공식 홈페이지에서 볼 수 있습니다. 저는 오전에 일을 하고 가느라 11시 반쯤 도착해서, 오후 세션 위주로 들었습니다.
AWS 행사에 기대하는 것
대학 강의를 시작했던 약 4년 전부터 AWS 행사에 다니면서 비슷한 생각을 하고 있습니다. 현업 개발자분들이나 개발자가 되고 싶은 분들이 시간상 행사를 딱 하나만 가야 한다면, 저는 개인적으로 AWS 행사를 추천하고 싶습니다. 구성도 잘 되어 있고, 실제로 그 기술을 써온 회사들의 이야기를 들을 수 있다는 점이 좋거든요.
물론 최근에는 조금 아쉬웠던 적도 있습니다. AI 위주로 내용이 바뀌면서 기술 설명은 많은데, 그걸 제가 하는 일에 어떻게 연결할지는 잘 와닿지 않는 경우도 있었죠.
그런데 이번 게임즈온은 그 부분이 꽤 달랐습니다. AWS가 하려는 방향, 파트너사들의 지원, 실제 발표자들이 겪은 일들이 딱 맞아떨어진다는 느낌이 들었습니다. 듣는 분들도 비슷한 고민을 하고 있지 않을까 싶었고요. 기술 이야기를 들으면서도 계속 저희 회사 일을 떠올리게 됐습니다.
GS네오텍: 보안이 중요하다는 말 다음에 무엇을 해야 할까
처음 들은 발표는 박제호 시큐리티 리드의 ‘AI 시대의 게임 클라우드 보안: 모델 밖의 책임과 공격 경로’였습니다. 사실 처음에는 큰 기대를 하지는 않았습니다. 그런데 듣다 보니 요즘 제가 고민하던 내용이 그대로 나오더군요.
저도 요즘 강의나 학생들 멘토링을 할 때 보안 이야기를 많이 합니다. AI가 강력해지면 혼자서 만들 수 있는 것도 늘어나지만, 공격하는 쪽도 똑같은 도구를 쓸 수 있으니까요. 특히 직접 서비스를 제공하는 입장에서는 개인정보나 이용자 데이터에 접근하는 기능을 만들고 나서, 문제가 생기면 어떻게 대응할 것인지까지 생각해야 합니다.
그런데 중요하다는 것은 알겠는데, 작은 회사에서 어디부터 준비해야 할지는 막막하죠. 이번 발표에서는 그 순서를 꽤 구체적으로 보여줬습니다. 우선 회사에 어떤 자산이 있는지 파악하고, 서비스·데이터·취약점·담당자가 어떻게 연결되는지 봅니다. 그다음 사업에 미치는 영향을 기준으로 먼저 고칠 것을 정하고, 조치한 뒤에는 실제로 해결됐는지 다시 확인하는 식입니다.
- 식별무엇이 있는지
- 연결어디와 이어지는지
- 우선순위무엇부터 고칠지
- 조치누가 해결할지
- 재검증실제로 해결됐는지
↺ 점검 결과를 반영해 다시 식별·연결부터 확인합니다.
같은 취약점이 있어도 외부에서 접근할 수 있는 곳인지, 중요한 데이터나 서비스와 연결돼 있는지에 따라 급한 정도가 달라집니다. 단순히 목록을 만들어두는 것에서 끝나면 안 되는 이유죠. 이 문제가 우리 서비스에 어떤 영향을 주는지까지 알아야 대응 순서를 정할 수 있습니다.
AI를 보안 업무에 쓰는 것도 이런 정보가 정리되어 있어야 가능한 일이었습니다. 어디까지 자동으로 처리하고 어디서 사람이 확인할지, 누가 어떤 판단으로 조치했는지, 그 결과는 어땠는지까지 남기는 것이죠. 회사 안에서 AI를 쓸 때와 이용자에게 AI 기능을 제공할 때, 각각 무엇을 챙겨야 할지도 생각해 보게 됐습니다.
개인적으로는 이제 작은 팀이나 개인이 이런 문제를 전부 직접 챙기기는 점점 어려워질 것 같습니다. 기능을 만드는 일이 쉬워졌다고 문제가 생겼을 때의 책임까지 가벼워지는 것은 아니니까요. 저희도 어디까지 직접 하고 어느 부분에서 전문적인 도움을 받아야 할지 고민하게 됐습니다. AI 서비스를 준비하고 있거나 비슷한 보안 고민이 있다면, GS네오텍에 자기 회사 상황을 놓고 문의해 봐도 좋을 것 같습니다.
베이글코드: 모델을 띄운 다음에도 계속 바뀌는 것들
다음은 베이글코드 정현진 팀리드의 ‘Amazon SageMaker HyperPod 기반 오픈소스 모델 서빙 최적화하기’였습니다. 회사에서 AI를 쓰기로 결정한 뒤 장비와 운영 방식을 어떻게 바꿔왔는지 이야기해 주셨는데요. 이렇게까지 자세히 이야기해 줘도 되나 싶을 정도였습니다. 듣는 입장에서는 참 고마운 발표였죠.
직접 장비를 사서 운영할지, GPU를 빌릴지, 클라우드를 쓸지는 저도 관심이 많은 부분입니다. 데이터와 보안이 중요하니 직접 운영하고 싶다가도, 더 좋은 모델을 돌리고 싶어지거나 사용량이 늘면 또 고민이 생기게 됩니다. 장비만 사면 끝나는 일이 아닌 거죠.
발표에서도 우선 실제로 얼마나 쓰는지부터 확인했습니다. 직원 수만 보는 것이 아니라 입력·출력 토큰, 동시에 들어오는 요청, 사용하는 업무를 살펴봤다고 합니다. 요즘처럼 에이전트가 계속 일하는 환경에서는 같은 한 명이어도 사용하는 양이 꽤 다를 수밖에 없겠죠.
모델은 실제 업무 문항으로 평가해서 필요한 답변 수준을 먼저 정했습니다. GPU를 고를 때도 구매 가격뿐 아니라 전력, 공간, 유지보수, 수급, 운영 부담을 함께 봤고요. 회사를 운영하는 입장에서는 이런 이야기가 더 와닿았습니다. 성능 좋은 장비를 고르는 것도 중요하지만, 결국 누군가는 계속 관리해야 하니까요.
실제 구성은 EC2에서 검증을 시작해 사내 GPU와 클라우드를 EKS로 함께 다루고, 이후 HyperPod Inference Operator를 활용하는 과정으로 이어졌습니다. 인증·정책을 확인하는 입구와, 같은 모델을 돌리는 여러 서버에 요청을 나눠 보내는 부분을 분리하면서, 직접 관리해야 할 일을 줄여갔습니다.
여기서 재미있었던 것은 사내 장비가 사라지지 않았다는 점입니다. 사내 GPU와 클라우드, 여러 리전의 구성을 함께 쓰면서 필요한 부분에 관리형 기능을 도입하고 있었습니다. 모델이 바뀔 때마다 처음부터 다시 만드는 부담을 줄이고, 교체와 검증을 계속할 수 있게 정리해 온 과정으로 들렸습니다.
사실 저희처럼 세 명이 일하는 회사에서는 당장 따라 하기 어려운 부분도 많습니다. 그래도 나중에 회사가 커지면 비슷한 선택을 하게 되지 않을까 싶더군요. 모델을 바꾸고 요청이 성공하는지만 보는 것이 아니라, 실제 업무에서 답변이 제대로 나오는지까지 확인한다는 이야기도 기억에 남습니다. 저는 SageMaker를 주로 연구나 학습 쪽으로 생각했었는데, HyperPod의 모델 배포와 추론 운영도 다시 살펴보고 싶어졌습니다.
모델을 고르기 전에 정리할 네 가지
이 이야기를 저희 회사에 대입해 보면, 우선 아래 네 가지부터 정리해야겠다는 생각이 듭니다. 어떤 GPU를 살지보다 실제로 무슨 일을 얼마나 시킬지부터 알아야 하는 것이죠.
| 기준 | 확인할 내용 |
|---|---|
| 사용량 | 입력·출력 토큰과 동시 요청은 얼마나 되는가 |
| 품질 | 실제 업무 문항에서 필요한 답변 수준을 만족하는가 |
| 운영 | GPU 확보·배포·장애 복구를 누가 맡는가 |
| 데이터 | 어떤 입력을 어디에서 처리하고 누가 접근하는가 |
카카오게임즈: 판단은 AI에게, 실행 기준은 코드로
카카오게임즈 주철민 리드와 이종우 개발자의 ‘인게임 AI 어시스턴트에게 게임 플레이 훈수 받기’도 정말 재미있게 들었습니다. 저도 AI를 게임 개발이나 게임 안에서 어떻게 쓸 수 있을지 학생들에게 이야기하고, ‘자원 전쟁’ 같은 프로젝트를 만들면서 계속 시도해 왔는데요. 그때부터 중요하게 생각했던 것이 판단과 실행을 나누는 일이었습니다.
이번 발표에는 저희가 메인 프로젝트를 만들려고 시도했던 내용들도 많이 나왔습니다. 제가 이야기하고 싶었던 것들을 실제 운영 경험과 함께 풀어주시니 공감이 많이 됐습니다.
솔직히 좀 부럽기도 하고, 배가 아프기도 했습니다. 직접 부딪히면서 이런 결과를 만들어낸 개발자분들이 참 멋있더군요.
기술적으로는 Amazon Bedrock AgentCore의 Runtime·Memory·Gateway를 필요한 곳에 도입하면서 기존 코드를 최대한 유지한 이야기가 나왔습니다. API도 처음 연결할 때만 생각하면 간단해 보이지만, 다른 팀에서 API를 바꿀 때마다 도구 정의와 호출 코드를 수정하고 다시 확인해야 하죠. 이런 뒤쪽의 일까지 이야기해 주는 게 좋았습니다.
특히 같은 조회를 계속 반복했던 사례가 기억에 남습니다. 정상적으로 조회했지만 데이터가 없는 것과 조회 자체가 실패한 것은 다른데, AI가 이것을 잘 구분하지 못하면 계속 다시 해보려고 하는 것이죠. 그래서 실패한 이유와 시도한 횟수, 이미 성공한 결과를 함께 알려주도록 보완했다고 합니다.
물론 이렇게 알려준다고 무조건 멈추는 것은 아니니, 전체 실행 한도는 코드에서 관리했습니다. 여기서 좋았던 부분은 한도를 다 쓰고 에러로 끝내기 전에 답변할 여유를 남겨뒀다는 점입니다. 일부 조회만 성공했어도 확보한 정보로 답변을 마무리할 수 있게 한 것이죠. 서비스로 만든다면 이런 부분을 챙겨야겠구나 싶었습니다.
실행 환경이 자동으로 늘어난다고 뒤에 있는 DB 연결 문제까지 알아서 해결되지는 않았습니다. RDS Proxy를 쓰고, 재사용하는 런타임에 남은 Redis 유휴 연결을 정리하는 이야기도 이어졌습니다. 실제로 운영하면서 만난 문제들이라 더 재미있게 들었던 것 같습니다.
결국 AI가 판단할 일과 코드가 처리할 일을 잘 나눠야 한다는 이야기였습니다. 다음 행동은 AI가 고르더라도 필수 규칙과 실행 범위, 종료 조건은 코드로 정해두는 것이죠. 제가 개발하고 강의하면서 계속 이야기하고 싶었던 부분이라 더 반가웠습니다. 앞으로 게임 회사들에서도 이런 방식으로 개발한 이야기가 많이 나오지 않을까 싶습니다.
GameLift: 다시 검토하고 싶어진 서버, 그리고 설치 없는 체험
마지막으로 들은 것은 Pooja Kaji와 김민석 솔루션즈 아키텍트의 ‘Amazon GameLift: What’s new and what’s next’였습니다. GameLift는 예전부터 알고 있었고, 도입을 고민해 본 적도 몇 번 있습니다. 다만 대규모 게임까지 서비스할 수 있게 만들어진 솔루션이다 보니 생각할 게 너무 많았습니다. 저희 같은 작은 회사나 인디 개발사가 쓰기에는 부담스럽다는 인상이 있었죠.
그런데 요즘은 AI 에이전트의 도움을 받다 보니 클라우드에 대한 두려움이 많이 줄었습니다. 회사 솔루션을 위해 GameLift 서버 구성을 테스트해 봤는데, 생각보다 너무 좋았습니다. 그러던 중에 이 발표를 들으니 더 관심이 갔습니다.
서버 쪽에서는 비용과 DDoS 대응 이야기가 나왔습니다. Player Gateway처럼 실제 게임 서버 앞에서 플레이어 트래픽을 확인하는 방식은 앞서 들었던 보안 세션과도 연결됐습니다. 다만 서비스를 쓴다고 전부 자동으로 적용되는 것은 아니고, 보호 조건과 직접 연동할 부분은 확인해야 합니다. AWS 공식 문서에서도 자동 보호와 별도 연동이 필요한 Player Gateway를 나눠 설명하고 있습니다.
그리고 이번에 특히 해보고 싶어진 것은 스트리밍이었습니다. 사실 이런 기능이 있는지도 잘 몰랐거든요. GameLift Servers가 멀티플레이 서버 운영을 맡는다면, GameLift Streams는 클라우드에서 실행한 게임을 브라우저로 보내줍니다. 게임 전체를 내려받아 설치하지 않고도 바로 체험할 수 있는 것이죠. 두 제품의 역할은 GameLift 소개 페이지에서도 따로 볼 수 있습니다.
이름이 비슷한 것들이 여럿 나오는데, 역할을 나누면 이렇게 정리할 수 있습니다.
| 구분 | 맡는 역할 | 우리 회사의 질문 |
|---|---|---|
| GameLift Servers | 멀티플레이 서버 호스팅·세션 운영·확장 | 서버 운영은 어디까지? |
| GameLift Streams | 클라우드 실행·브라우저 전달 | 설치 없는 체험은 어떻게? |
| Instant Play Demos | Streams 기반 체험 캠페인 | 관심을 스토어 방문으로? |
현장에서는 VARCO 3D로 자기 캐릭터를 만들고, 그걸로 멀티플레이를 하는 과정까지 보여줬습니다. 중간중간 잘 안 되거나 기다려야 하는 부분도 있기는 했습니다. 그래도 직접 만든 캐릭터로 게임을 하고, 그 과정을 클라이언트 설치 없이 웹 브라우저에서 볼 수 있다는 게 꽤 재미있었습니다.
물론 클라우드에서 실행한다고 보안 문제가 전부 사라지는 것은 아닙니다. 애플리케이션과 데이터는 여전히 저희가 챙겨야 하죠. 그래도 작은 팀이 직접 운영할 부분을 줄이고, 이용자가 게임을 접하는 방식까지 바꿔볼 수 있다는 점은 매력적이었습니다. 이건 회사에서 작은 POC로라도 꼭 한번 해보고 싶다는 생각이 들었습니다.
후반에 나온 Instant Play Demos도 재미있었습니다. 광고나 유통 채널에서 게임을 발견하면 그 자리에서 실제로 해보고, 마음에 들면 스토어로 넘어가는 흐름입니다. 영상을 보고 관심이 생겨도 설치까지는 안 하게 되는 경우가 있는데, 그 중간에서 한번 해볼 수 있게 만드는 것이죠.
실제로 쓰려면 원하는 국가와 채널에서 이용할 수 있는지부터 확인해야겠지만, 작은 게임 회사 입장에서는 관심이 가는 내용이었습니다. 누구나 AI로 게임을 만들기 쉬워지면 경쟁도 더 심해질 테니까요. 게임을 잘 만드는 것과 함께, 어떻게 알리고 매출로 연결할지도 계속 고민하게 될 것 같습니다. 설치 없는 데모를 활용하는 방식도 그중 하나로 검토해 볼 만하겠죠.
이미 해본 사람들의 이야기가 반가웠던 하루
행사장에서는 오랜만에 반가운 분들과 이야기도 나누고, 마지막 럭키드로까지 함께했습니다. 이런 분들을 만나서 이야기할 수 있다는 것도 오프라인 행사에 가는 재미죠.
이번 행사는 너무너무 좋았던 기억으로 남았습니다. 기술을 소개하는 데서 끝나는 게 아니라, 실제로 해온 분들의 이야기가 저희가 하는 일과 맞닿아 있어서 더 그랬던 것 같습니다. 준비해 주신 메가존클라우드·GS네오텍·AWS 관계자분들, 그리고 좋은 경험을 나눠주신 발표자분들께 감사드립니다.
전반적으로 다 좋았는데… 굳이 아쉬웠던 것을 말하자면, 도시락?!
맛도 좋고 양도 많았습니다. 그런데 먹기가 불편했어요. ㅠㅠ 책상이나 식사할 공간이 충분히 준비되어 있지 않아서 저는 행사장 의자에 앉아서 먹었습니다. 커피 같은 음료도 중간에 일부 시간에만 이용할 수 있었고, 근처에 마땅히 갈 만한 카페도 없어서 그런 부분은 좀 아쉬웠습니다.
사실 공짜 밥도 주셔서 좋았고, 맛있게 잘 먹었습니다. AWS 행사가 워낙 밥을 잘 주다 보니 제 눈높이가 좀 높아진 것도 있는 것 같네요. ㅋㅋㅋ
이번 행사를 다녀오니 앞으로가 더 기대됩니다. 연말에도 굵직굵직한 행사들이 많을 것 같은데, 관련 행사에 다녀오거나 재미있는 정보가 있으면 또 후기로 잘 정리해보겠습니다.
읽어주셔서 감사합니다.
관련 AWS 공식 자료
발표에서 나온 기능들이 궁금하신 분들은 아래 공식 자료도 함께 보시면 좋겠습니다.
- AWS 게임 기술 블로그 — 게임 개발·운영 사례와 기술 소식
- AWS 공동 책임 모델 — AWS와 고객이 나누어 맡는 보안 책임
- SageMaker HyperPod 모델 배포 가이드 — 모델 배포와 추론 운영
- Amazon Bedrock AgentCore 개요 — AI 에이전트 구축·배포·운영 기능
- Amazon GameLift Servers 소개 — 멀티플레이 서버 호스팅과 확장
- Amazon GameLift Streams 소개 — 클라우드에서 실행한 게임의 브라우저 스트리밍
- GameLift Streams의 Instant Play Demos 활용 가이드 — 설치 없이 체험하는 게임 데모의 제작·운영 팁
※ 본문의 순순·흑심 일러스트는 제가 그린 캐릭터를 바탕으로 AI를 활용해 제작했습니다.