모닥랩이란 무엇인가?

관심 있는 주제를 가지고 5주간 진행하는 스터디 프로그램이다.
https://blog.naver.com/smileconnector/224252174930

스마일게이트 데브 커뮤니티 (MODAC) 소속 스터디다. MODAC 이름 귀욥 ㅎ

4월 둘째 주 부터 5월 둘째 주까지 진행되었다.

자세한 언리얼 개발 기록 내용 읽을 필요 없고 AI 어떻게 썼는 지만 궁금하다면, 회고 및 결론만 보시는 걸 권장 드립니다 ㅎ

스터디 개인 목표

언리얼 프로젝트에 AI를 활용한 워크플로우 구축하여 바이브 코딩 입문.

스터디 공통 목표

AI 꿀팁 거침 없이 공유 ㅋ
밑에 주차별 기록 보다 보면 알 수 있듯이, 스터디 팀원 분들의 꿀팁 공유 덕분에 알게된 것이 많다.
아래 적은 내용 말고도 실제로 수많은 꿀팁들이 공유되었었다. 목표 달성했다고 본다.
이 글에서는 내 개인 기록만을 담아두겠다.

개인 목표 진행 방식

언리얼 5 개인 프로젝트에 Claude Code 플러그인 SuperPowers 을 사용하여 실무에서 구현한 시스템을 구현하도록 요청함.
그리고 실무에 실제로 구현한 내용과 어떤 차이가 있는 지 분석함.

주차별 진행 과정

1주차

처음에는 SuperPowers가 아닌 직접 만든 개발 워크플로우를 구성하려고 했다.
요구사항을 입력하면 시스템 설계, 코드 구현 이 2개의 단계를 중간 결과물 폴더에 먼저 출력하는 워크플로우를 만들었다.

이 워크플로우를 Claude Code로 만들었다.
Claude Code는 많은 skill 파일들을 통해 이 워크플로우를 구축해주었다.

2주차

1주차에서 팀원들에게 워크플로우를 직접 만들었다고 말씀 드리니, 유사한 기능을 이미 만들어놓은 플러그인 SuperPowers를 사용하면 된다는 추천을 받았다.
그리고 1주차에 구현한 워크플로우와 SuperPowers에 똑같은 입력을 넣어 결과를 비교해봤다.
입력은 "언리얼5 레벨 스트리밍을 활용하여 레벨 전환하는 시스템을 구현해줘" 였다.
출력은 두 워크플로우 모두 다를 바가 없었다.

그 이유는 둘 다 같은 모델을 사용해서 출력을 주기 때문이다. 중간 출력을 처리하는 방식만 다를 뿐이다.

지금 보면 이게 너무 당연한 얘기이긴 하나, 당시에는 입문 과정이라 하나하나 알아가는 재미가 있었다.

3주차

SuperPowers를 활용해서 또 어떤 목표를 달성할 지 정하였다.
언리얼에 블루프린트라는 것이 있는데, 언리얼 5에서는 이 블루프린트를 C++로 컨버팅 하는 것이 조금 복잡했던 경험이 있었다.
실제 실무에서 계속 작업 하다가 업무 우선순위에 따라 중단 됐었다.

당시 실무에서 이 작업을 해주는 여러 언리얼 플러그인 오픈 소스가 있었는데, 그 중 컨버팅을 AI에게 맡기는 것(NodeToCode)이 있었다.

당시에 해당 플러그인(NodeToCode)을 사용하려면 AI 모델 연결도 해야하다 보니, 이 방법을 채택하지 않았다. 직접 UBlueprint 객체의 정보를 통해 노드를 번역하는 언리얼 플러그인(BlueprintNativization)을 채택하여 작업했었다.

물론 이러한 이유에는 직접 UBlueprint에 어떤 정보들이 있는 지 보고, 리플렉션 시스템에 대해 공부 하라는 팀장님의 의도가 있었음을...

채택한 플러그인(BlueprintNativization)의 핵심은 결국 각 노드마다 연결된 핀 정보 등이 있어, 핀 정보를 통해 코드의 순서를 판단하는 것이었다.

그런데 실무에서 사용하는 블루프린트 중, 굉장히 복잡한 노드 구조를 가지는 경우에는 옳지 않은 방향으로 C++ 코드를 번역해주는 경우가 허다했다.

그래서 결국 이런 경우에는 사람이 직접 컨버팅하거나, AI 모델에게 컨버팅을 맡겨야 하지 않을까 라는 생각이 들었다. 컨버팅 시스템의 한계 문제 해결하기를 4주차 목표로 잡았다.

실제로 다른 회사에서도 AI로 많이 컨버팅 한다는 것을 스터디 팀원 분들을 통해 알게 됐다. 이 스터디의 장점이 여기서 드러나는 것 같다. 스터디 팀원 분들이 여러 회사에 재직 중이다 보니, 꿀팁들을 서로 공유하게 된다.

UNSEEN에서부터 이어온 인연 덕분에 다른 회사 언리얼 프로그래머들과 계속 소통할 수 있다는 건 큰 장점이다.
어쩌다보니 계속 UNSEEN을 하는 느낌이다.

4주차

AI에게 물어보니, 이러한 한계는 결국 AI가 '복잡한 노드' 라고 판단한다면 표시하여 AI 모델에게 컨버팅을 맡기고, 다른 '간단한 노드'들은 기존 BlueprintNativization 로직에게 기존대로 컨버팅 출력을 가져오면 된다고 했다.

그래서 기존 오픈소스 BlueprintNativization (실무에서 오류를 많이 해결해 놓은 상태) 경로를 알려주며, '간단한 노드'들은 이 로직을 사용하고, 다른 '복잡한 노드'들은 AI 모델이 직접 번역하는 시스템을 구현해달라고 했다.

근데 이 때 조금 바빠서 실행은 못해본 채로 5주차로 넘어갔다.

대신 팀원들에게 블루프린트 노드 클립보드로 복사되는 정보와 UBlueprint 객체의 정보가 큰 차이가 없다는 것을 공유했다.

5주차

LLM 모델을 컨버팅 시스템에 연결하는 것에 실패했다.
실제로 왜 실패했는 지 알아보려 하기도 전에, 스터디를 통해 알게 된 사실이 있었다. Claude api는 Claude 정책 이슈 때문에 연결이 안될 수 있다는 것이었다.
이걸 스터디원이 알려주지 않았더라면 삽질할 뻔했다.

그래서 두 가지 방법을 시도해보고자 한다.

(잘 보면 "translationHint": "rule_based"가 있는데, 이게 바로 '간단한 노드'라고 판단한 경우다.)

첫 번째로 LLM 모델을 따로 연결하지 않고, 직접 프롬프트에서 블루프린트 정보를 JSON 포맷으로 저장한 파일을 읽어 번역하도록 하는 방법.

두 번째로 Codex api를 연결해보는 방법.

이걸 시도하는 건 다음 주차에 하려고 했는데 생각해보니 모닥 스터디는 이미 마무리가 되었다. 이 후에도 계속 AI로 개인 언리얼 프로젝트를 진행할 예정이라서, 시도가 성공적이면 해당 시스템을 실무에서 사용할 생각이다.

이렇게 유지보수를 반복적으로 하지 않아도 되는 간단한 툴을 만드는 것은 바이브 코딩으로 뚝딱!! 만드는 것이 효율적이었다.

회고 및 결론

조금 반성하자면 AI 스터디인데 결국 언리얼 5 공부한 내용을 공유하게 되었던 것 같다.
여기에 또 약간의 핑계를 대자면,, ㅎㅎ AI를 효율적으로 쓰려면 결국 요구사항에 대한 지식이 있어야 된다는 생각이 계속 들기 시작했다.

“AI를 잘 쓰려면 도메인 지식이 필요하다”
“유지보수/디버깅 능력은 여전히 중요하다”
“실무에서는 요구사항 판단 능력이 중요하다”

AI는 문맥상 가능성이 높은 답을 생성하지만,
그것이 항상 요구사항에 맞는 정답이라는 보장은 없다.
따라서 결과의 적절성을 판단하고 수정하려면,
결국 사용자의 도메인 지식과 디버깅 능력이 필요하다.

위 내용이 나의 결론이다.

근데? 나는 아직 고작 만 1년차 이니까... 언리얼 지식을 계속 더 쌓아야 됨. 그래서 생각해낸 방법

좋은 결과물을 얻기 위해, 입력도 AI의 도움을 받으면 더 좋다!
어차피 AI는 입력이 같으면 출력이 똑같으므로, 내가 원하는 입력을 주는 것이 중요하다.
내가 원하는 입력을 꼼꼼하게 주기 위해서 AI 도움을 받자.

이렇게 당당하게 얘기해놓고 n년 뒤에 AI에게 대체 당해 짤리면 우짜지

뭐 Home Protector 직업이나 구해야겠네요 ㅋ

p.s. 바이브 코딩이 언리얼 개발에 최적화 되어있지는 않은 것 같다. 그럴만도 한 게 언리얼 엔진 자체가 방대하기도 하고, 언리얼만의 포맷(대표적으로 uasset과 같은 바이너리 파일)을 많이 사용하기 때문인 것 같다.