GROWTH LOG STORIES

함께 만든 성장을,
기록으로 연결합니다.

AI와 함께 배우고, 직접 만들고, 서로 나눈
그로스로그 멤버들의 생생한 성장 기록을 만나보세요.

성장 기록
5기+이어진 커뮤니티
HEALTHIO
PROJECT

사진 한 장으로 시작하는 건강 루틴, Health IO

대표 이야기 읽기

ALL STORIES

성장의 순간을
한곳에서 만나보세요.

프로젝트의 시작부터 모임에서 나눈 인사이트까지,
그로스로그가 함께 만든 기록을 모았습니다.
개의 성장 기록

성장일지

[GL 2기] 언리얼 강화학습 플러그인, 쿠버네티스 Service, 컨퍼런스에서 건진 것 (성장일지 2회차 큐레이션) 🌱

GROWTH LOG🌱 2026. 8. 7. 02:11

안녕하세요! 그로스로그 입니다!😊 🌱

국내 자료가 거의 없는 플러그인을 직접 파본 기록, 통신이 되는 이유까지 따진 쿠버네티스 정리, 그리고 컨퍼런스를 자기 경험과 엮은 후기. 2기 2회차입니다.

성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.

이번 회차는 "남이 정리해둔 게 없을 때 어떻게 하는가"를 보여준 세 편입니다.

 

01

🤖 [언리얼5.4] Learning Agents 개요

허해수 님

허해수 님 원문에 실린 이미지
이런 내용이에요
언리얼 엔진 5.4에 들어간 Learning Agents 플러그인을 정리한 글입니다. 게임 안의 캐릭터를 강화학습으로 훈련시킬 수 있게 해주는 기능이에요.
국내에 참고 자료가 거의 없는 신규 플러그인이라, 사실상 공식 문서와 직접 실험만으로 구조를 파악해야 했습니다.
글은 Manager / Interactor / Trainer라는 세 구성 요소가 각각 무슨 역할을 하는지부터 짚고, 훈련 모드와 추론 모드를 어떻게 전환하는지까지 이어집니다. 희소성과 실행 가능성을 함께 갖춘 정리예요.

새로 나온 기술을 공부할 때 가장 어려운 건, 검색해도 아무것도 안 나온다는 점입니다.

Learning Agents는 언리얼 5.4에 들어간 지 얼마 안 된 플러그인이었습니다. 한국어 자료는 사실상 없었고, 영어 자료도 공식 문서 외엔 드물었어요. 이 글은 그 상태에서 시작합니다.

조금 더 들어가 보면

강화학습(Reinforcement Learning)은 정답을 알려주지 않고 점수만 주는 학습 방식입니다.

지도학습은 "이 사진은 고양이야"라고 정답을 알려줍니다. 강화학습은 다릅니다. 캐릭터가 어떤 행동을 하면 그 결과에 점수를 매기고, 캐릭터는 점수를 높이는 방향으로 스스로 행동을 바꿔갑니다. 앞으로 가서 목표에 가까워지면 +1, 벽에 부딪히면 -1 같은 식이죠. 수천 번 반복하다 보면 벽을 피해 목표로 가는 법을 알아냅니다.

게임에서 이게 매력적인 이유는 명확합니다. NPC 행동을 일일이 코딩하지 않아도 되니까요. 기존 방식은 상태 머신이나 행동 트리로 "적이 5m 안에 오면 공격, 체력이 30% 이하면 후퇴" 같은 규칙을 사람이 다 짜야 했습니다. 상황이 복잡해지면 규칙이 폭발하죠.

Learning Agents가 나눈 세 요소가 이 흐름을 그대로 반영합니다.

Interactor는 에이전트와 게임 세계의 접점입니다. 캐릭터가 무엇을 관측할지(적의 위치, 내 체력), 어떤 행동을 할 수 있는지(이동, 점프)를 정의해요. 강화학습에서 가장 중요한 설계 지점입니다. 관측에 없는 정보는 에이전트가 영원히 모르니까요.

Trainer는 학습을 돌립니다. 보상을 계산하고, 신경망 가중치를 갱신하고, 수천 번의 시행착오를 관리해요.

Manager는 전체를 조율합니다. 여러 에이전트를 동시에 굴리면서 학습 과정을 관리하죠.

그리고 글이 짚은 훈련 모드와 추론 모드의 전환이 실무적으로 중요합니다. 훈련은 무겁습니다. 수천 번 반복하며 가중치를 계속 고쳐야 하니 게임을 실시간으로 돌릴 수가 없어요. 그래서 훈련은 따로 오래 돌려두고, 결과물인 학습된 모델만 게임에 싣습니다. 이때는 관측을 넣으면 행동이 나오는 계산만 하니 가볍습니다.

이 구분을 모르면 "왜 학습이 이렇게 느리지"에서 막히게 됩니다.

큐레이터 노트

자료가 없는 영역을 직접 정리했다는 점에서 뽑았습니다.

이미 좋은 글이 많은 주제를 다시 쓰는 것도 의미가 있습니다. 자기 언어로 소화하는 과정이니까요. 그런데 아무도 안 쓴 걸 쓰는 건 다른 차원의 기여입니다. 이 글이 나온 시점에 한국어로 Learning Agents를 설명한 자료는 거의 없었어요.

그리고 개요에서 그치지 않고 훈련·추론 전환까지 짚은 게 실행 가능성을 만들었습니다. 구조만 설명하고 끝났다면 "그래서 어떻게 쓰지"가 남았을 텐데, 실제로 돌려본 사람만 쓸 수 있는 내용이 들어가 있어요.

원문 읽으러 가기  ↗imresearcher.tistory.com/m/41
 

02

☸️ [Study 4주차] 쿠버네티스 Service — ClusterIP

김경보 님

김경보 님 원문에 실린 이미지
이런 내용이에요
쿠버네티스의 Service 중 가장 기본이 되는 ClusterIP를 정리한 글입니다. 클러스터 내부에서 파드끼리 통신할 때 쓰는 방식이에요.
"ClusterIP를 만들면 통신이 된다"에서 멈추지 않은 게 이 글의 특징입니다. 어떤 설정이 어떤 역할을 하는지, 셀렉터와 라벨이 어떻게 연결되는지까지 짚습니다.
그리고 트러블슈팅까지 포함했어요. 만들었는데 연결이 안 될 때 어디를 봐야 하는지가 함께 있어서, 따라 하다 막힌 사람이 쓸 수 있는 글이 됐습니다.

쿠버네티스를 공부할 때 Service는 꼭 지나가는 관문입니다. 그런데 대부분의 입문 자료가 "이렇게 만들면 됩니다"에서 끝나요.

이 글은 왜 그게 통신을 가능하게 만드는지까지 들어갑니다.

조금 더 들어가 보면

쿠버네티스에서 Service가 필요한 이유는 파드가 사라지는 존재이기 때문입니다.

파드는 컨테이너를 감싼 최소 실행 단위인데, 언제든 죽고 다시 뜹니다. 배포하면 새 파드로 교체되고, 노드에 문제가 생기면 다른 노드로 옮겨가고, 부하가 늘면 여러 개로 늘어납니다. 그때마다 IP가 바뀝니다.

그러면 백엔드 파드가 DB 파드를 부르려 할 때 곤란해집니다. 어제 알던 IP가 오늘은 다른 파드의 것일 수 있으니까요.

Service는 이 문제를 "변하지 않는 이름과 주소"를 주는 것으로 해결합니다. Service를 하나 만들어두면 클러스터 안에서 고정된 가상 IP(ClusterIP)와 DNS 이름을 갖게 되고, 다른 파드들은 그 이름만 알면 됩니다. 실제로 어떤 파드로 갈지는 쿠버네티스가 알아서 정하고요.

연결을 만드는 장치가 라벨 셀렉터입니다. Service에 "app=backend 라벨이 붙은 파드로 보내줘"라고 적어두면, 그 라벨을 가진 파드가 새로 뜨든 죽든 알아서 목록이 갱신됩니다. 파드를 직접 지목하는 게 아니라 조건으로 지목하는 거죠. 쿠버네티스 전반을 관통하는 사고방식입니다.

여기서 초보자가 가장 많이 막히는 지점도 라벨입니다. Service의 셀렉터와 파드의 라벨이 한 글자라도 다르면 아무 에러 없이 그냥 연결이 안 돼요. 오타가 나도 쿠버네티스는 "그런 파드가 없네" 하고 조용히 넘어갑니다. 그래서 kubectl get endpoints실제로 연결된 파드가 있는지 확인하는 습관이 중요합니다. 비어 있으면 셀렉터가 틀린 거예요.

ClusterIP는 이름 그대로 클러스터 내부 전용입니다. 외부에서 접근하려면 NodePort나 LoadBalancer, Ingress를 써야 해요. 이 구분을 처음에 잡아두면 다음 단계가 수월해집니다.

큐레이터 노트

"된다"에서 멈추지 않은 글이라 뽑았습니다.

쿠버네티스는 개념이 많아서, 따라 하기 문서를 그대로 따라 하면 일단 동작은 합니다. 문제는 그다음이에요. 조금이라도 상황이 다르면 왜 안 되는지를 알 수 없습니다.

이 글은 설정 하나하나가 무슨 역할을 하는지 짚고, 막혔을 때 어디를 볼지까지 적었습니다. 스터디 4주차 기록인데 정리 수준이 정보글에 가까워요.

스터디에서 배운 걸 이렇게 남겨두면, 다음 기수 멤버가 같은 스터디를 시작할 때 그대로 참고 자료가 됩니다. 커뮤니티 안에서 지식이 쌓이는 방식이 이렇다고 생각해요.

원문 읽으러 가기  ↗kimalarm.tistory.com/99
 

03

🎤 [Flutter] Future<Flutter> 컨퍼런스 참여 후기

박예승 님

gl2-02-박예승.jpg
이런 내용이에요
Flutter 컨퍼런스 참관기인데, 단순 후기가 아닙니다.
들은 발표를 나열하는 대신 자기가 실제로 겪은 문제와 엮어서 정리했어요. WebRTC 시그널링, 크래시 로그 분석, FFI로 네이티브 코드 연동하기, iOS에서의 초기화 문제 같은 주제들입니다.
컨퍼런스에서 들은 이야기가 "아, 그때 그 문제가 이거였구나"로 연결되는 순간들이 담겨 있습니다. 그래서 참석하지 않은 사람이 읽어도 남는 게 있어요.

컨퍼런스 후기는 쓰기 쉬운 만큼 남기기 어려운 글입니다. 발표 목록과 사진만 나열하면 참석자 본인에게만 의미가 있죠.

이 글은 다릅니다. 본인이 붙들고 있던 문제를 기준으로 발표 내용을 재배열했어요.

조금 더 들어가 보면

글에 나오는 주제들이 공교롭게도 Flutter로 실제 서비스를 만들 때 만나는 어려운 지점들입니다. 하나씩 보면 왜 그런지 보입니다.

WebRTC 시그널링 — 화상통화나 실시간 통신을 붙일 때 필요합니다. WebRTC 자체는 브라우저 간 P2P 연결을 만들어주는데, 연결을 맺기 전에 서로의 정보를 교환할 통로가 따로 필요해요. 이걸 시그널링이라고 합니다. WebRTC 표준에는 시그널링 방식이 정해져 있지 않아서, 각 팀이 직접 구현해야 합니다. Flutter처럼 크로스 플랫폼 환경이면 iOS·안드로이드·웹에서 각각 다르게 동작하는 문제까지 겹치고요.

크래시 로그 분석 — Flutter 앱이 죽었을 때 원인을 찾기가 유독 어렵습니다. Dart 코드에서 난 문제인지, 플랫폼 채널을 넘어간 네이티브 쪽 문제인지 구분해야 하거든요. 스택 트레이스가 난독화되어 있으면 심볼 파일로 복원하는 과정도 필요합니다.

FFI(Foreign Function Interface) — Dart에서 C/C++ 라이브러리를 직접 부르는 방법입니다. 기존 네이티브 SDK를 써야 하거나 성능이 중요한 연산을 넘길 때 씁니다. 강력하지만 메모리 관리를 직접 해야 해서 실수하면 앱이 통째로 죽어요.

iOS 초기화 문제 — 1회차에서 다룬 FlutterEngine 이야기와 이어집니다. iOS는 앱 생명주기와 메모리 관리 방식이 안드로이드와 달라서, 같은 코드인데 iOS에서만 초기화 타이밍 문제가 나는 경우가 있습니다.

컨퍼런스의 진짜 값어치가 여기 있다고 생각합니다. 발표 내용 자체는 나중에 영상으로도 볼 수 있어요. 그런데 "내가 지금 막혀 있는 문제"를 들고 가서 듣는 것과 그냥 듣는 건 완전히 다릅니다. 같은 발표가 답이 되기도 하고 흘러가기도 하죠.

큐레이터 노트

후기를 자기 경험으로 소화한 글이라 뽑았습니다.

"이런 발표가 있었고 이런 내용이었습니다"로 끝나는 후기는 검색해서 나오는 발표 자료와 크게 다르지 않습니다. 이 글은 들은 내용을 본인이 겪은 문제 옆에 놓았어요. 그래서 읽는 사람도 "나는 어떤 문제를 갖고 있지"를 떠올리게 됩니다.

박예승 님은 2기 1·2·3회차 연속 큐레이션되셨는데, 세 편의 성격이 다 다릅니다. 하이브리드 도입(1회차), 컨퍼런스 후기(2회차), ML 모델 연동(3회차). 같은 사람이 매 회차 다른 각도로 쓰면 기록이 훨씬 입체적으로 남는다는 걸 보여주는 사례예요.

원문 읽으러 가기  ↗velog.io/@martin_0610/FutureFlutter-%EC%BB%A8%ED%8D%BC%EB%…

💡 세 편을 겹쳐 읽으며

이번 회차 세 편의 공통점은 참고할 게 마땅히 없는 상태에서 시작했다는 점입니다.

허해수 님은 국내 자료가 없는 신규 플러그인을 붙들었습니다. 김경보 님은 "된다"까지만 알려주는 문서들 사이에서 "왜 되는가"를 스스로 채웠고요. 박예승 님은 컨퍼런스라는 흩어진 정보 더미에서 자기 문제에 맞는 조각을 골라냈습니다.

셋 다 주어진 자료를 소비한 게 아니라, 자료가 없는 자리를 메웠어요.

그리고 그 결과물이 다시 다음 사람의 자료가 됩니다. 지금 Learning Agents를 검색하는 누군가는 허해수 님의 글을 만나게 될 거고, 쿠버네티스 스터디를 시작하는 다음 기수는 김경보 님의 정리를 참고하게 되겠죠.

이번 회차에서 가져갈 것

1. 자료가 없다는 건 기회다. 검색해서 안 나오면 막막하지만, 뒤집으면 내가 쓰면 그게 첫 자료가 됩니다. 새 기술을 공부할 때 정리해서 남기는 습관이 가장 크게 값어치를 발휘하는 순간이에요.

2. 조용히 실패하는 설정을 조심하기. 쿠버네티스 셀렉터처럼 오타가 나도 에러 없이 그냥 안 되는 지점들이 있습니다. 이런 영역은 "확인하는 명령어"를 함께 외워두세요. kubectl get endpoints가 비어 있는지 보는 것처럼요.

3. 문제를 들고 배우기. 컨퍼런스든 강의든 책이든, 지금 막혀 있는 문제를 하나 들고 가면 흡수율이 완전히 달라집니다. 그냥 들으면 흘러가는 내용이 답으로 바뀌거든요.


좋은 글 남겨주신 허해수 님, 김경보 님, 박예승 님께 감사드립니다! 😊

다음 큐레이션으로 다시 찾아오겠습니다! 🌱

- 에디터 · 성장일지 큐레이터 -


※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.

WRITE YOUR GROWTH

오늘의 배움을
내일의 성장으로.

기록은 나를 돌아보게 하고, 공유는 우리를 연결합니다.
당신의 다음 성장 이야기도 그로스로그에서 시작해보세요.

커뮤니티 둘러보기