SIPE 사담콘을 다녀왔습니다!!

 

미리 세션 주제를 봤을 때, 웹 서버 개발뿐만 아니라 WebSocket 서버 구축, 요즘 개발 컨퍼런스를 하면 어디서나 빠지지 않는 AI/AX 활용을 주제로 한 세션들에 눈길이 갔다. WebSocket 관련해서는 지금 실무에서 필요한 기술은 아니지만, 실시간 양방향 서비스에 관심이 있기도 하고, 관련해서 개념 용어를 한 번쯤 들어보고 익혀보는 것도 좋을 것 같았다. 그리고 최근 팀 내 AI/AX 활용을 생각하면서, 개인이 아닌 조직적으로 어떻게 AI/AX를 유연하고, 효율적이고, 안정적으로 사용할 수 있을까 고민하던 찰나에 좋은 인사이트를 얻을 수 있으리라고 생각해 신청하게 됐다.

 

번외로 최근 여러 개발 행사에 참여하면서 어떻게 기록을 정리하면 좋을까 생각했다.

지금 이 순간에도 글을 끄적였다 지웠다 하고 있지만.. 우선 녹음한 세션 내용을 바탕으로 전체적으로 정리하면서 복기하고, 생각할 여지가 있고 고민했던 내용이 있다면 덧붙여서 정리하는 게 좋을 것 같다.

 

 

 

1. 인디 게임의 멀티플레이 서버 개발 여정

첫 번째 세션은 Unity로 개발 중인 2인 협동 퍼즐 게임의 멀티플레이 개발 경험을 주제로 한 발표였다.

먼저 싱글 플레이 게임을 개발한 이후, 멀티 플레이 기능을 추가하는 과정에서 서버 아키텍처를 고민하고 최종적으로 WebSocket 서버로 진행한 경험을 공유해주셨다.

 

1) 문제 배경

기존 게임은 싱글 플레이 기반이었다.

  • 하나의 게임 상태(State)만 관리
  • 플레이어 입력이 곧 게임의 진실(Source of Truth)
  • 저장/복구도 비교적 단순

 

하지만 협동 플레이를 지원하려면 상황이 완전히 달라진다.

 

멀티플레이에서는

  • 여러 클라이언트가 동일한 상태를 공유해야 하고
  • 누가 상태를 결정하는 권한(Authority)을 가지는지 정의해야 하며
  • 연결이 끊겼을 때 재접속 및 상태 복구가 필요하고
  • 실시간 동기화까지 고려해야 한다.

즉, 게임 상태를 어떻게 동기화할 것인지가 가장 큰 문제였다.

 

 

2) 멀티플레이 아키텍처 고려

첫 번째 선택지: P2P

  • 서버 없이 플레이어끼리 직접 통신하는 방식이다.
  • 보통 방장이 게임 상태의 권한(Authority)을 가진다.

장점

  • 서버 비용 절감
  • 중앙 서버 불필요

단점

  • 대부분의 사용자가 공유기 뒤(NAT)에 있기 때문에 연결이 실패하는 경우가 많아, NAT Traversal과 Relay 서버가 필요할 수 있음
  • STUN 방식으로 IP를 교환해 연결을 하는 Hole Punching을 시도해도, 방화벽·NAT 환경에 따라 막히는 경우가 잦음
  • 호스트가 이탈하면 다음 호스트를 누가 맡을지 정하는 Host Migration 문제가 발생함
  • 게임 성능이 호스트 회선 품질에 의존함
  • 통신 경로가 복잡해 구현과 디버깅 난이도가 높음
"즉, 이론적으로는 서버 비용이 적게 들지만 구현 난이도가 매우 높은 방식이다."

 

 

 

두 번째 선택지: 플랫폼에서 제공하는 P2P SDK

Steam, Stove, Epic Games 등의 게임 플랫폼에서 제공하는 자체 P2P SDK를 활용한다.

→ P2P 구현의 어려움(NAT Traversal, Hole Punching, Relay 서버, IP 시그널링, Peer 연결, Matchmaking..)을 대신 처리해줌..!!

 

cf. 최근 유튜브에서 봤었던 '메차 카멜레온' 이라는 게임이 있는데, 이 게임도 Steam P2P SDK를 활용한다고 한다..!

 

한계점

  • 플랫폼 P2P SDK를 사용하면 해당 플랫폼에 종속된다.
    • ex. Steam, Stove 출시 예정일 경우 Steam P2P, Stove P2P를 각각 별도로 구현 필요

 

 

세 번째 선택지: EOS(Epic Online Services)

  • 플랫폼 독립적으로 설계되어, 스팀·스토브·자체 런처 등 어디서 실행되든 통합된 환경에서 P2P 릴레이를 쓸 수 있다.
  • 또한 이 팀의 게임이 Unity C#으로 개발된 만큼, EOS가 제공하는 Unity용 C# SDK도 활용할 수 있었음

 

 

네 번째 선택지: Server-Client (WebSocket)

  • 중앙 서버 방식으로 비용은 들지만 구현이 단순하고, 디버깅이 쉬우며 빠른 프로토타이핑이 가능하다.
  • P2P 대비 상태 관리 로직이 단순해 소규모 팀이 감당하기 쉽다.

 

결론

  • 짧은 기간 안에 빠르게 구현하기 위해 중앙 서버 방식인 WebSocket 서버 구축
  • 향후 EOS P2P SDK로 마이그레이션

 

 

3) 의사결정 기준 

"최고"의 구조가 아닌 현재 게임의 요구사항과 제약에 맞는 "최선"의 결정을 진행했다.

 

  • 비용
    • 초기 구축비와 서버 유지비, 그리고 게임 세션이 비활성 상태일 때 유휴 시간 비용
  • 응답 속도
    • 협동 퍼즐 게임에서 50ms 이하의 초저지연은 불필요하다고 판단
  • 운영 난이도
    • 1인 또는 소규모 팀이 직접 운영 가능한 수준의 복잡도

 

2. CRUD에서 복잡한 아키텍처로: AI 시대의 서버 엔지니어링 의사결정

개인적으로 지금까지 서버 개발부터 인프라 운영까지 그 흐름을 공부하면서, 사이드 프로젝트 규모의 간단한 아키텍처부터 기업 서비스의 복잡한 아키텍처 구성도를 어깨 너머로 본 경우가 있었다.

 

처음 거대하고 복잡한 아키텍처를 보면, 어디서부터 어디까지 봐야될지, 이 기능은 무엇인지, 왜 이렇게 설계했는지 그 의도를 파악하기가 쉽지 않았다. 그리고는 아키텍처에 대한 물음표보다는 특정 구현 기술에만 매몰되곤 했다..

 

 

두 번째 세션에서는 

복잡한 아키텍처가 만들어지기까지 어떤 문제들을 만났길래 필요해졌는지?
그 배경을 이해하고 고민하는 과정의 중요성

 

에 대해 이야기해주셨다!

 

 

1) 단순한 CRUD에서부터 시작한다.

처음에는 매우 단순한 구조로도 충분하다.

 

Client → API Server → Database

  • 빠르게 만들 수 있고, 이해하기 쉽고, 디버깅도 쉽다
  • 예를 들어, 회원가입 기능에서는 다음과 같은 흐름이면 끝난다.
    • 클라이언트가 sign-up API 호출
    • DB에 회원 정보 저장
    • 응답 반환

 

 

2) 하나의 요청에서 처리할 일이 늘어난다.

시간이 지나면서 하나의 요청 안에 처리해야 할 일이 계속 추가된다.

  • 온보딩 상태 초기화
  • 약관 동의 처리
  • 가입 완료 알림 발송
  • 분석 이벤트 적재
  • MSA 환경일 시, 다른 서비스에 회원 가입 상태 반영

 

이 모든 것을 하나의 요청 경로 안에서 처리할 경우, 필히 다음과 같은 문제가 발생하게 된다.

  • 요청 응답 시간 증가 (p95/p99 레이턴시 상승)
  • 외부 API 실패가 사용자 요청 전체 실패로 전파
  • 일부만 성공하고 일부는 실패 (예: 가입 자체가 실패한 것처럼 보임)

 

[선택지]

  1. 동기 처리를 유지하고 작업 범위를 줄임
  2. 배치 처리
  3. 비동기 처리

→ 문제 해결의 핵심은 요청 안에 반드시 남겨야 할 작업과 요청 밖으로 분리 가능한 작업을 구분하는 것이다.

 

현재 구조에서는 '제한이 가능한 후처리를 분리'하는 목적으로 Queue + Worker를 도입하도록 한다.

그렇게 되면 회원가입 요청 안에서는 회원 정보 저장과 이후 알림 잡이나 이벤트 기록과 같은 필수적인 것만 처리하고, 나머지는 Queue와 Worker로 비동기 처리를 하는 구조가 된다.

 

 

[비동기에 대한 오해]

많은 사람들이 "비동기는 곧 성능 개선." 라고 말하지만, 이 구조에서는 그것만이 핵심이 아니다.

비동기는 지금의 실패를 사용자 요청으로부터 분리하는 기술이다.

 

 

[도입 후]

Queue와 Worker를 도입했다고 끝이 아니다.

실제로 도입하고 이전 대비 어떤 점이 개선되었는지, 혹은 새로운 문제가 발생하지는 않았는지를 추적 확인해야 한다.

  • 실제로 요청 시간이 줄었는지
  • Queue에 작업이 쌓였는지
  • 메시지가 유실되는 등의 문제가 발생하지는 않는지

 

 

3) 비동기 구조도 실패를 한다.

앞에서 말했듯, 비동기는 기존의 사용자 요청 안에서 발생했던 실패를 밖으로 분리만 되었을 뿐 여전히 실패가 발생한다.

그리고 비동기 구조를 도입함으로써 새로운 문제들도 발생하게 된다.

  • Worker 작업 실패 및 재시도 처리
  • 메시지 유실 및 중복 처리

 

[선택지]

  1. Retry
  2. DLQ(Dead Letter Queue)
  3. 수동 복구 도구

→ 핵심은 비동기 구조에서 발생한 실패를 추적하고 복구 가능한 상태로 만드는 것이다.

 

Retry는 중복 실행으로 데이터 정합성 문제가 발생하거나 계속되는 재시도로 인한 추가 장애가 발생할 수 있다.

따라서 현재 구조에서는 '비동기 실패를 추적하고 복구/운영 가능한 설계'의 목적에 맞춰서 DLQ + 수동 복구 도구를 도입한다.

 

 

[도입 후]

  • 재시도가 자주 발생하는지
  • DLQ 적재량이 얼마나 되는지
  • Worker 실패율이 허용 범위인지
  • 수동 복구에 얼마나 시간이 걸리는지

 

 

4) 서비스 쿼리와 분석 쿼리가 충돌한다.

새로운 문제가 발생했다.

처음에는 하나의 DB에서 서비스 쿼리 조회와 분석 쿼리 조회를 전부 감당할 수 있었다.

 

  • 서비스 조회: 높은 트래픽, 빠른 응답이 중요
  • 분석 조회(가입 전환율, 단계별 이탈률 등): 대규모 집계 쿼리가 많음

 

 

하지만 서비스가 점점 커지면서, 분석 쿼리가 DB에 부하를 주면서 다음과 같은 문제가 발생하게 됐다.

  • 슬로우 쿼리 증가
  • DB CPU 커넥션 고갈

 

[선택지]

  1. 인덱스, 쿼리 최적화 튜닝
  2. DB 앞단에 캐시 도입
  3. 조회 / 분석용 DB 분리
  4. Data Warehouse 도입

 

여기서도 바로 Data Warehouse를 붙이는 것이 정답이 아니다.

먼저 어떤 문제를 해결할 것인지 정확히 정의하고 판단을 해야 한다.

  • 지금 문제가 서비스 조회 성능 문제인지
  • 분석 쿼리 부하 문제인지
  • 여러 시스템의 데이터를 조합해야 하는 복잡도 문제인지

 

현재 구조에서는 '분석 쿼리 부하로 인해 서비스 조회와 분석 조회를 나누고, 여러 시스템의 데이터를 통합해 복합적으로 분석 가능한 설계'에 맞추어 Data Warehouse + 분석 API 를 도입하도록 한다.

 

 

[도입 후]

  • 서비스 조회 쿼리와 분석 쿼리의 성능이 얼마나 개선되었는지
  • SSOT(Single Soucre Of Truth), 단일 진실의 원천을 어디에 둘 것인지?
    • ex. 회원 DB: 10010명 / Redis: 10009명 / Data Warehouse: 10008명 → 회원 수의 SSOT는 회원 DB로 둔다.
  • 데이터 동기화 실패를 어떻게 감수할지
  • 데이터 반영 지연은 얼마나 허용할지

 

 

결론

많은 엔지니어들은 '어차피 나중에 Queue도 필요하고 Data Warehouse도 필요할 텐데 처음부터 넣으면 안 되나?' 라는 생각을 한다.

하지만 복잡도는 곧 비용으로 이어진다. 처음부터 Queue, Event Bus, Cache, Data Warehouse, Feature Flag, AI Pipeline 등 좋아 보이는 많은 기능들을 넣고 싶어질 수 있지만, 아직 모르는 게 너무 많다.

 

  • 병목이 어디일지
  • 데이터 규모가 얼마나 될지
  • 지금 생각하는 핵심 플로우가 계속 유지될지
  • 팀이 실제로 이 복잡도를 감당할 수 있는지
  • 도입 비용이 얼마인지

 

 

문제가 확인되기도 전에 복잡도부터 가져오면, 운영 부담과 비용이 먼저 발생하게 된다. '나중에 필요할 것 같아서' 라는 이유로 도입하는 것은 복잡도를 늘리는 결정이고, 운영·배포 복잡화, 모니터링 대상 증가, 정합성 문제, 인프라·학습 비용 증가로 이어진다.

 

따라서 아키텍처를 확장하고 새로운 기술을 도입하기 전에, 먼저 문제에 대한 질문을 던지고 가설을 세우고 실제로 검증을 해야한다.

  1. 문제가 실제로 존재하는가?
    • 감이 아닌 메트릭(p95/p99 레이턴시 등)으로 확인
  2. 병목이 어디인가?
    • API인지, DB인지, 외부 호출인지
  3. 더 단순한 대안이 있는가?
    • 큐 대신 작업 범위 축소
    • 웨어하우스 대신 인덱스·쿼리 최적화
  4. 이 아키텍처를 도입했을 때 치러야 할 대가는 무엇인가?
    • 큐를 붙이면 워커와 DLQ가 따라붙고, 웨어하우스를 붙이면 동기화 지연이 발생함
    • 실패 시 대응 주체와 성공 판단 기준도 함께 정해야 함
  5. 실제로 좋아졌는가?
    • 큐를 붙였다면 요청 시간이 줄었는지, 웨어하우스를 붙였다면 서비스 DB 부하가 줄었는지
    • 재시도를 넣었다면 실패율이 줄고 장애가 커지지 않았는지

 

여기에서 AI는 의사결정을 대신하는 존재가 되어서는 안된다.

~ 한 문제가 발생하는데 Queue를 도입해도 될까?

묻는 것보다는

~ 한 문제가 발생하는데 동기 처리, 비동기 처리, 배치 처리의
각 방식에 대해 장단점과 트레이드오프 분석, 실패 시나리오와 엣지 케이스를 정리해서 알려줘

라고 물어야 한다.

 

 

이렇게 AI는 선택지를 빠르게 정리하는 데까지 도움을 줄 수는 있다.

하지만 결정은 대신해주지 않는다. 최종적으로 어떤 선택을 할 지 고민하고 결정하는 것은 사람이 해야 한다.

  • 문제와 비즈니스의 우선순위 결정
    • 신규 기능 개발과 성능 개선 중 뭐가 더 중요한가?
  • 정합성 요구사항 결정
    • 분석용 데이터가 몇 분 정도 늦게 반영돼도 괜찮은가?
  • 장애 허용 범위 결정 
    • 서비스 회원가입 알림 발송 Worker 실패 시,
      '      가입은 성공으로 처리하고 알림만 나중에 재시도할지' or '가입 전체를 실패처리하여 롤백할지'
  • 비용 감수 여부 결정
    • 기술 도입에 예상 비용과 팀 학습 기간을 고려했을 때 도입할 가치가 있는가?
  • 보안, 개인정보 정책
    • 해외/국내 법안과 사내 보안 정책에 위반되지는 않는지?
    • 로그를 남기거나 외부 클라우드나 워크플로우 기술을 도입할 시,
      '사용자의 개인정보 원본을 그대로 남길지' or '마스킹하거나 참조 ID만 남길지'

 

이번 세션뿐만 아니라 최근 AI로 인해 기존의 개발자라는 직업이 가지고 있는 역할의 변화에 대해 고민을 계속하고 있다.

그리고 지금의 정리된 결론은 다음과 같다.

기술에 대한 전문성뿐만 아니라, 본인이 개발하고 있는 서비스의 도메인과 요구사항에 대한 깊이있게 이해하는 것이 중요하고, 이를 바탕으로 책임있는 결정을 내리기 위해 노력해야 한다고 생각한다.

 

 

이번 세션 정리는 끝!!!!!! 이지만 마지막으로 세션이 끝나고 Q&A 시간에 나온 좋은 질문들이 많아 간단히 정리하자!

질문 정리

Q. 트래픽을 예측하기 어려운 서비스(흥행에 따라 트래픽이 좌우되는 경우)는 어느 정도까지 미리 아키텍처를 고도화해야 하나요?

여전히 처음에는 단순한 구조로 시작하는 게 맞다는 입장입니다. 다만 트래픽 급증 가능성을 고려한다면 "얼마만큼의 실패를 감수할 것인가"를 미리 결정하는 문제가 될 것 같습니다. 결국 실패를 미리 방지해두는 것도 비용이므로 그 비용을 얼마나 감당할 수 있는지가 기준이 될 것 같습니다.

 

Q. 실제로 팀에서는 어떻게 아키텍처를 개선해야 할 시점을 판단하고 진행하시나요?

우선 측정하는 것이 가장 중요합니다. 실패율이나 응답 시간은 갑자기 나빠지는 경우보다 서서히 올라가는 경우가 많습니다. 그래서 특정 임계치를 넘으면 알림이 오도록 모니터링 시스템을 구성해두고, 알람이 발생하면 그 시점을 기준으로 팀 전체가 모여 논의하는 방식으로 진행하고 있습니다.

 

Q. AI 시대 이후 비용 판단 기준이 달라진 부분이 있을까요?

가장 크게 달라진 부분은 분석 단계의 오퍼레이터 역할이 사람에서 AI로 바뀐 것이 가장 큰 것 같습니다. 인건비보다 저렴한 비용으로 동일한 역할을 AI에 맡길 수 있다는 점이 비용 측면에서 가장 큰 차이점이라고 생각합니다.

 

Q. 발표 때 소개해드린 아키텍처와 같이, 복잡한 아키텍처를 설계할 때 중요한 점은 무엇일까요?

특정 아키텍처를 아는가 모르는가가 정말 중요하다고 생각합니다. 어떤 기술인지, 아키텍처인지 전혀 모르고 있으면 선택조차 할 수 없습니다. 100%를 알지는 못해도 '이런 기술이 있다' 정도만 알아도 필요할 때 찾아보고 검토할 수 있습니다. 그래서 이러한 동아리 활동에 참여하거나 기술 아티클을 읽으면서 평소에 정보를 얻는 것이 Zero to One으로 가는 데 많은 도움이 됐습니다. 그리고 사내에서는 ADR 문서도 자주 읽으며 참고했습니다.

 

 

 

3. AI 시대, 개발자의 AX는 무엇인가

최근 AI의 활용과 AX 경험을 혼자만이 아닌 팀 전체가 잘 활용할 수 있도록 하기 위해 어떤 방법들이 있을까? 그리고 어떻게 구축하고 설계해야 될까? 를 고민하고 회사 내 주니어 개발자 분들과도 이야기를 종종 나누고 있다. 여러 기술 블로그에서도 이를 주제로 한 글들이 굉장히 폭넓고 많다. (SDD, MCP, RAG, 하네스, 루프 엔지니어링...)

 

그러면 AX가 뭘까?

지금의 AX라는 거대한 흐름이 있기 전에, 많은 기업에서 DX 혁신을 외치고 있었다.

 

먼저 DX에 대한 정의를 찾아보니

DX(Digital Transformation) 직역하면 '디지털 전환'을 의미한다. 풀어서 설명하면 AI, 클라우드, 데이터 분석 등의 디지털 기술과 도구를 활용해 기존의 비즈니스 모델과 업무 방식, 프로세스 등을 혁신하는 것을 의미한다. 그렇게 하여 업무 효율을 향상시키고 비용을 절감하고, 새로운 수익 모델을 찾아내고, 데이터 기반의 의사결정들로 탈바꿈하게 되는 것이다! 😲

 

AX도 동일하다.

AX(AI Transformation) 직역하면 'AI 전환', AI 활용을 핵심 역량으로 삼고 기존의 서비스와 업무 방식, 의사결정 등을 혁신하는 것이다.

기존의 DX에서 데이터화 한 것들을 바탕으로 AI가 매우 빠르게 취합하고 분석하여 사람의 의사결정을 보조하여, 기존의 단순하고 반복적인 업무들을 대체해 나가는 것을 목표로 한다.

(참고로 AI가 생각하고 판단하는 기저가 기존에 축적한 데이터이기 때문에, DX 전환이 선행이 되어야만 AX로의 전환이 가능하다고 생각한다.)

(위에서 이야기 한 내용과 연결이 될 것 같다. AI로 인해 기존의 단순 업무(구현)가 대체 자동화되고, 의사결정을 보조하는만큼 "기술 + 서비스 이해 = 책임있는 결정"이 중요해지고 있다고 생각한다.)

 

 

이 세션에서도 "AX"를 고민하고, "개발자의 AX"에 대한 생각과 이를 실현하여 어떻게 AI Agent를 설계하여 도입했는지 많은 인사이트를 공유해주셨다!!🙇🏻‍♂️

 

1) 회사에서 요구하는 AX

회사에서 올해 업무 평가의 30%를 AX 성과를 넣겠다!

 

그래서 회사가 말하는 AX는 무엇일까? 라고 물어보았고, 이에 대한 회사의 답변은 반복 업무를 AI로 자동화하는 것이었다.

 

개발자는 원래 뭐 하는 사람인가?

 

  • 도메인 전문가(분석·운영·기획)는 무엇이 필요한지 이미 안다.
    게임으로 치면 검사는 검이 필요한 걸 알고, 마법사는 마법책이 필요한 걸 안다.
  • 개발자는 그 사람들에게 무기를 쥐어주는 사람이다.

 

즉, 이러한 각 직무의 전문가분들이 직접 도메인 특화된 Agent를 만들 수 있는 환경을 만들어주는 것을 목표로 방향을 잡게 되었다.

 

 

 

2) AI Agent 용어 정리

AI Agent를 구현하기에 앞서 AI Agent에 대한 정의를 다음의 3단계로 구분했다.

 

  1. 프롬프트 엔지니어링: 모델이 학습된 지식 내에서만 답변
  2. RAG: 참고 가능한 데이터가 추가되어 도메인 특화 답변 가능, 그러나 액션은 불가
  3. Agentic AI: 계획(Plan) → 도구 호출(Tool Call) → 관찰/수정 루프를 통해 행동까지 수행

 

지금 설계하고자 하는 시스템은 RAG로 질문에 잘 대답하는 시스템이 아닌, Agentic AI로 실제로 조회를 하고 액션까지 취할 수 있는 시스템이 필요했다. 이러한 Agentic AI의 주요 구성 요소와 실행 방식은 아래와 같이 개념을 정리하고 진행을 했다.

 

Agentic AI의 구성 요소

  • Model — Tool Calling이 되는 모델
  • Prompt — 모델에게 맥락을 넣어주는 부분
  • Tool — 모델이 쓸 수 있는 API or 도구

 

ReAct = Reasoning + Acting

  • Reasoning(추론) — 현재 상황을 분석하고, 문제 해결에 어떤 단계가 필요한지 미리 생각한다
  • Acting(행동) — 추론 결과를 바탕으로 수행할 작업을 탐색하고, 실행할 도구를 결정·사용한다
  • Observation(관찰) — 문제가 해결됐는지 확인하고 다음 단계를 정한다 → 다시 1번으로

 

AX(Agent Experience)의 구성 요소

  • 접근(Access) — 에이전트를 어디에 연결할 것인가 → Slack, Jira, GitLab
  • 도구(Tools) — 에이전트에게 어떤 도구를 줄 것인가 → MCP
  • 컨텍스트(Context) — 무엇을 컨텍스트로 올릴 것인가 → SKILL.md
  • 실행(Execution) — 어떻게 실행할 것인가 → ReAct
  • 운영(Operation) — 어떻게 운영할 것인가 → K8s CRD + 오퍼레이터

 

 

3) v1: 사내 Slack 챗봇

기존에 CS 답변만 하던 사내 메신저 챗봇에 Tool Calling을 얹었다.

 

이렇게 구축하니 장애 대응을 할 때, Snowflake DB + Jira + Slack 스레드를 파악해서 종합적으로 사내 툴들을 호출하고 맥락을 파악한 후 답변을 받을 수 있었다.

  • 지금 어떤 장애가 발생했고
  • 기존에 이미 동일한 장애 이력이 있었고
  • 배치는 어디까지 진행 중이며
  • 이후 배치는 실행되지 않았다

 

구성

  • 입력: Slack 메시지 
  • 오케스트레이션: LangGraph (ReAct 루프)

 

이렇게 이슈도 검색해주고 코드 리뷰 코멘트도 달아주니 "AX 별거 아니네" 싶었지만..

이렇게 간단히 끝났으면 AX가 아니었다.

 

바로 드러난 문제점들이 있었다.

  1. 도구 호출이 제대로 일어나지 않는 문제
  2. 옆 팀, 같은 팀의 다른 파트(프론트엔드 vs 백엔드)가 각자 도메인에 맞는 봇을 원함
    → 매번 같은 봇을 새로 만들어주고 특화시켜야 함

여기에서 그동안 'AI Transformation'에 대한 답만 찾다가 AX(Agent Experience) 라는 개념을 만나게 된다.

 

 

4) 문제 ①: 도구가 늘어날수록 무너지는 Tool Calling

사내 에이전트가 의미를 가지려면 단순 API 호출이 아니라 사내 MCP, CLI, 사내 전용 게이트웨이 API 같은 걸 다 붙여야 한다.

그래서 Snowflake, 사내 MCP, 각종 API를 일단 다 붙였다. 요즘 모델은 똑똑하니 알아서 잘 고르겠지 하고.

 

[문제 원인]

  • MCP에 등록된 툴이랑 스킬 명세가 너무 많아, AI 모델이 어떤 MCP를 사용하고 어떤 툴과 스킬들을 선택해야 할 지 모르는 문제가 발생했다.
  • MCP는 툴 단위가 아니라 서버 단위로 로드한다. 이 때 요청마다 MCP 서버를 미리 띄워야 하는데 서버 하나당 약 2초 + 메모리 약 100MB 이상 소모가 되어 메모리 낭비가 심하는 문제가 발생한다.

 

[해결]

1. MCP와 스킬을 분리해서 관리한다.

  • MCP(Tool): 실제 호출 가능한 도구 집합
  • SKILL.md: 이 MCP에서 어떤 툴을 쓸 지와 어떻게 쓸 지를 명시
    • 에이전트는 SKILL.md를 읽고 명시된 툴(allowed-tools)만 사용, 하단 맥락으로 작업 방식을 파악한다.
SKILL.md

---
allowed-tools:
  - <이 작업에 실제로 필요한 툴만 나열>
---

# 코드 리뷰

<무엇을 읽고, 어떻게 리뷰할지에 대한 맥락과 절차>

 

 

2. Semantic Routing 도입

  • 도구 설명을 미리 임베딩해두고, 질문이 들어오면 질문을 임베딩해서 코사인 유사도로 어떤 도구를 Tool Calling할지 판단한다.
    즉, 스킬 단위로 필요한 MCP만 활성화한다.
  • 적용 이후, 컨텍스트 토큰 125K → 35K로 절감

 

3. Lazy Connect

  • 시맨틱 셀렉션이 되면 그 다음이 가능해진다.
  • 호출할 때만 MCP 서버를 띄우고, 일정 시간(발표자는 5분으로 설정) 미사용이면 끊는다.
    단, 실행 중인 작업이 있으면 끊지 않고 유지한다.
    • ex. 사내 MCP 스킬을 쓰면, 미리 로드하지 않고 사용 시점에 사내 MCP 서버를 실행한다.
      (연결이 끊겨도 로그인 세션은 로컬에 남아 있어 재연결이 가능하다)
  • 모든 MCP를 미리 올릴 필요가 없어지고, 메모리 낭비가 사라진다.

 

 

5) 문제 ②: 비용 추적 불가

한 달쯤 운영해보았더니 예상보다 비싼 청구서가 날아왔다. 문제는 "왜 비싼지"를 알 수가 없었다..

기존 서버 개발하듯 로그를 쌓아놨는데, 막상 보려니 아무것도 알 수 없었다.

  • 이 파이프라인 중간에 누가 끼어 있었는지
  • 이 Tool Calling을 어떤 에이전트가 했는지
  • 여기서 쓴 토큰을 어떤 에이전트가 어떻게 썼는지

 

[해결]

OpenTelemetry + LLM Observability 도입

  • 요청 단위를 묶는 Trace ID 표준 적용
  • Trace ID 기반으로 에이전트 실행 흐름 중 어디서 문제(예: Tool Calling 실패, 스팬 누락)가 발생했는지 파악 가능
  • Langfuse 연동하여 프롬프트/응답, 토큰 비용, 세션 뷰, 평가 스코어를 기능 활용 → 비용 처리 및 피드백 루프 개선
  • 실제로 비용을 약 65%까지 절감

 

6) 문제 ③: 스스로 멈출 줄 모르는 추론 루프

관측과 비용을 잡고 나서 더 어려운 업무를 시켜봤더니, 항상 나이스한 답변이 오는 건 아니었다.

에이전트가 스스로 멈추지 못하고 계속 사고에 빠지면서 이것도 찾아보고 저것도 찾아보다가 답변이 오지 않는다.
또는 "나중에 알려드릴게요" 하고 알려주지 않는다.

 

이게 추론 루프(reasoning loop) 문제다.

LLM은 스스로 멈출 줄 모른다. 생각에 빠지면 계속 깊이 들어간다.

 

 

[해결]

LLM은 본체 비결정적인 시스템이며, 이러한 시스템에서는 실패는 예외가 아니라 기본값이다.

그리고 실패를 throw 하는 게 아니라 try catch 잡아서 처리하도록 설계해야 한다.

  • 멈추는 일은 바깥의 결정적(deterministic) 코드가 해줘야 한다
  • LangChain/LangGraph 수준에서의 서킷 브레이커 패턴이 필요하다.
  • 거짓말 답변이나 조용한 멈춤(silent stall)은 재질의를 유도하도록 설계한다.

 

7) 여러 팀으로의 AI Agent 확장 운영

여러 팀에서 각자의 팀 에이전트를 요청하기 시작하면서 개별적으로 만들어주고 관리해주는 게 어려워졌다.
이를 해결하기 위해 다음과 같이 k8s로 인프라를 운영하고, 각자의 팀 도메인과 서비스에 특화된 스킬만 갈아 끼우면 Agent를 활용할 수 있도록 진행했다.

 

[해결]

  • AI Agent를 k8s 워크로드로 전환 (AI Agent Bot 하나 = 파드 하나)
  • AI Agent 생성을 명령형이 아닌 CRD(Custom Resource Definition)로 선언
  • Operator 패턴으로 k8s가 알아서 상태를 관리하도록 구축
  • Git으로 버전 관리(GitOps) → 팀 에이전트를 직접 관리

 

스킬 마켓플레이스

  • 로컬 스킬 → 팀 스킬 → 공유 스킬로 승격되는 구조
  • 공유된 스킬은 다른 팀에서도 재사용 가능, 반대로 다른 팀에서 쓰던 스킬을 개인이 로컬에서 다시 활용 가능
  • 각 팀 도메인 전문가는 스킬 작성에만 집중

 

이렇게 해서 실무에서 아래와 같이 여러 에이전트들을 구축하고 사용할 수 있는 환경이 되었다.

  • 텍스트 → dbt SQL 변환 에이전트
  • 커뮤니티 데이터 요약·답변 에이전트
  • GitLab에서 작업할 경우, Jira 이슈를 업데이트하고 상태를 변경해주는 에이전트
  • 코드 리뷰 에이전트

 

질문 정리

Q. 개인 차원에서 AX를 도입해보려면 어떤 것부터 시작하는 게 좋을까요?

개인 AX에서 제일 쉬웠던 건 지금 가장 핫한 AI 에이전트를 한번 써보는 거라고 생각합니다. 올해 초까지는 오픈클로가 그랬고 지금은 헤르메스가 유행하고 있는데, 사용해보고 반대로 헤르메스 같은 에이전트를 직접 만들어보는 것도 좋습니다. 관련 프레임워크나 라이브러리, 오픈소스가 많아서 홈서버에 똑같이 구축해보며 만들다 보면 헤르메스가 왜 지금 핫한지, 이전의 오픈클로는 왜 그렇게 핫했는지를 하나하나 뜯어보면서 알게 되더라고요. 그래서 저는 항상 지금 가장 핫한 에이전트를 써보고 분석해보는 것을 권합니다.

 

Q. 사내에 에이전트를 공개할 때 보안은 어떻게 관리하셨나요? 프롬프트 인젝션을 시도하는 사람도 있고, 권한을 어디까지 줘야 할지도 고민입니다.

저희도 똑같은 고민을 했습니다. 저희 회사에서 제일 유명한 프롬프트 인젝션 테스트는 "된장찌개 레시피 알려줘"인데, 사내에서 AX를 하면 다들 한 번씩 물어보고 알려주면 실패한 에이전트라고 부릅니다. 인증 같은 경우에는 기본적으로 비결정적인 시스템으로는 할 수가 없고, 결정적인 시스템으로 파이프라인을 만들어 미들웨어에서 관리했습니다. 사용자 권한은 인증 토큰으로 관리하되, 저는 모든 에이전트가 BYOK(Bring Your Own Key)를 써야 한다고 생각합니다. 그 에이전트를 만든 팀에서 해당 에이전트의 권한과 PAT, API 접근 권한을 직접 관리해야 한다고 보고, 그런 방식으로 해결하려고 했습니다.

 

Q. Slack을 프론트엔드로 쓰면 데스크톱 앱이나 인터랙티브 CLI만큼 인터랙션을 주기 어려운데, UX를 어디까지 만드셨나요?
(Steering: 사용자가 에이전트 행동을 중간에 조정하는 것, Rate Limit: Slack API 호출 제한, Skill 보기 어려움)

사실 로컬에서 할 수 있는 일은 사실 요청하시는 분이 로컬에 직접 설치하는 게 더 빠릅니다. 예를 들어 Claude Code CLI에 본인 MCP를 연결해서 물어보는 게 편합니다. Slack으로 물어보는 경우는 주로 비동기 커뮤니케이션 할 때 많이 필요로 해서, 예를 들어 CS 업무나 코드 리뷰, 모니터링 같은 용도로 많이 활용했습니다. Slack은 사실 제공할 수 있는 UX가 많지 않아서 버튼까지만 구현하고, 그 이후에 필요한 것들은 페이지 URL을 전달하는 식으로 해결하려고 했습니다.

 

Q. 하네스 엔지니어링이나 루프 엔지니어링 같은 구조도 고민하셨나요?

그런 구조들도 많이 고민을 했었는데, 다만 이 에이전트는 팀 에이전트로 쓰다 보니 하네스 엔지니어링보다는 루프 엔지니어링 쪽이 더 특화되어 있다고 생각했습니다. 하네스 엔지니어링은 개인에 특화되어 있고 개인의 로컬 PC에서 관리할 때 더 효과가 있다고 봐서, 지금은 루프 엔지니어링 구조를 채택했습니다.

 

Q. AX로 만든 제품의 검증은 어떻게 하고 계신가요? 성능 지표는 무엇을 쓰셨나요?

제품 검증 자체도 앞서 말씀드린 Langfuse나 Phoenix 같은 도구로 가능합니다. 피드백을 남길 수 있어서 이 답변은 잘못된 답변이다, 이건 좋은 답변이다 하는 평가가 가능하고, 아까 잠깐 보여드린 Text to SQL 같은 경우도 더 나은 답변이 됐는지 아닌지를 확인할 수 있기 때문에, 그걸로 많이 개선하려고 했습니다.

저작자표시 (새창열림)

'TIL' 카테고리의 다른 글

스프링캠프 2026을 다녀와서  (0) 2026.06.25
K-Devcon 3월 밋업을 다녀와서  (0) 2026.03.29
AWS SAA 후기  (0) 2026.03.09
AWS AIF 후기  (0) 2026.03.02
블로그 글쓰기의 '이미지 업로드'는 어떻게 동작할까??  (0) 2025.12.17

티스토리툴바