천천히 하지만 확실하게

[게임잼] 가짜 게임 개발자 AI 게임잼 후기

HighCl — Fri, 8 May 2026 04:19:03 +0900

어겜기 - 가짜게임개발자 : AI 인간 개발 전쟁 후기｜어겜기

항목	내용
주최	가짜 게임 개발자 / 고라니
시간	오전 10시 30분 ~ 오후 4시, 약 5시간 30분
장소	성수 소셜캠퍼스 온 서울1
주제	농식품과 작물을 이용한 창의적인 게임 제작
홈페이지	없음
플레이 링크	https://highcl.itch.io/baldo-duel

개요

유튜버 고라니님이 진행한 <가짜 게임 개발자> AI 게임잼에 참가했습니다.
이번 게임잼은 AI를 사용하는 루키 개발자와 AI를 사용하지 않는 시니어 개발자의 게임 개발 대결이라는 콘셉트로 진행됐습니다.
저는 그중 AI를 사용하는 루키 개발자 쪽으로 참여했고, 이번 글에서는 짧은 시간 안에서 AI를 어떻게 활용했는지와 그 과정에서 느낀 점을 정리해보려 합니다.

행사 시간은 오전 10시 반부터 오후 4시까지 약 5시간 반 정도였습니다.
다만 중간 준비와 환경 세팅 시간, 마감 시간을 고려하여 실제로 제가 결과물을 만드는 데 사용한 시간은 약 3시간 반 정도였습니다.

목적

어겜기 - 가짜게임개발자 : AI 인간 개발 전쟁 후기｜어겜기

이번 게임잼에서 확인하고 싶었던 목적은 크게 세 가지였습니다.

첫 번째는 Unity 프로젝트에서 AI 기반 바이브코딩이 어디까지 가능한지 확인하는 것이었습니다.
코드를 하나하나 직접 붙잡고 구현하기보다, 작업 의도와 세부 지시를 전달했을 때 AI가 어느 정도까지 실행 가능한 프로토타입을 만들어낼 수 있는지 보고 싶었습니다.
특히 제한 시간이 짧은 게임잼 환경에서도 AI가 기획, 구현, 에셋 적용, UI 배치 같은 작업을 얼마나 빠르게 연결할 수 있는지가 궁금했습니다.

두 번째는 제 AI 활용 역량 자체를 점검하는 것이었습니다.
이번 게임잼에는 평소 사용하던 작업 환경과 스킬들을 사용할 수 없었습니다.
그만큼 불안 요소도 있었지만, 오히려 현장에서 바로 세팅하고 대응하는 능력을 확인하기에는 좋은 조건이었습니다.

세 번째는 다른 참가자들의 AI 활용 방식을 직접 관찰하는 것이었습니다.
다른 개발자들은 AI를 어떤 방식으로 활용하는지, MCP 같은 도구를 어디까지 작업 흐름에 연결하는지,
그리고 시니어 개발자는 AI 없이 짧은 시간 안에 어디까지 구현하는지 확인하고 싶었습니다.

진행 방식

주제는 '농식품과 작물을 이용한 창의적인 게임 제작'이었으며, 당근이 대파로 진검승부를 펼치는 1대1 로컬 코옵 게임인 'Baldo Duel'을 개발했습니다.
짧은 시간 안에 결과물을 내야 했기 때문에, 시작하자마자 AGENTS.md와 전체 플로우 중심의 최소 문서를 먼저 만들었습니다.
복잡한 기획서를 쓰기보다는 AI가 프로젝트의 방향을 잃지 않도록 핵심 규칙과 작업 기준만 잡았습니다.

이후에는 멀티 데스크톱을 활용하여 CMD 창 3개와 Codex Desktop, 총 4개의 AI 세션으로 작업 흐름을 병렬로 운영했습니다.

- cmd1: 핵심 기능 개발
- cmd2: 보조 기능 개발과 에셋 적용
- cmd3: MCP 기반 UI 세팅
- Codex Desktop: 에셋 탐색 및 추가 작업

기존에는 개발자가 직접 왔다 갔다 하며 처리해야 했던 반복 작업을 AI에게 나눠 맡길 수 있었고,
저는 전체 흐름을 보고 지시를 정리하는 쪽에 더 집중했습니다.

특히 Unity MCP가 인상적이었습니다.
기존에는 UI 프리펩 수정 정도로만 사용해왔지만, 이번에는 더 적극적으로 활용해보기로 했습니다.
그 결과 리소스 배치, 애니메이션 구성, Animator 제어, UI 배치, 타일맵 배치까지 생각보다 많은 부분을 자연스럽게 처리해 주었습니다.
덕분에 짧은 시간 안에 기대 이상으로 결과물을 끌어올리는 데 도움이 됐습니다.

결과

어겜기 - 가짜게임개발자 : AI 인간 개발 전쟁 후기｜어겜기

결과적으로 제한된 시간 안에서 플레이 가능한 형태 그 이상의 만족스러운 게임을 완성할 수 있었습니다.
게임잼 규모에서는 llm wiki, 도메인 문서 등 디테일한 문서가 없어도, AI가 프로젝트 의도와 작업 맥락을 꽤 잘 이해했습니다.
짧은 지시를 반복해서 던지는 것보다, 처음에 최소한의 방향과 규칙을 잡아둔 것이 효과적이었습니다.

아쉬운 점도 있었습니다.
설계적인 관점에서는 로직이 단일 클래스에 몰리면서 단일 책임 원칙이 약해지는 흐름도 보였습니다.
긴 프로젝트였다면 바로 분리했겠지만, 게임잼이라는 조건에서 버그 발생 시 헨들링이 가능하다보니 치명적인 문제로 보이지 않았습니다.
이번에는 제한 시간 안에서 동작하는 결과물을 만드는 것이 우선이었기에 그대로 구현했습니다.

시연

골드메탈 - 5시간 게임잼에서 만든 작품 소개합니다 [라이브]

골드메탈님은 시니어 개발자 포지션으로 참여하셨습니다.
AI 없이도 짧은 시간 안에 높은 완성도의 게임을 만들어내시는 모습을 보면서, 기본기가 가진 힘은 역시 강력하다는 것을 다시 느꼈습니다.

루키로 참가한 다른 분들의 결과물도 정말 인상적이었습니다.
특히 프린세스 메이커에 가까운 규모의 게임이 5시간 게임잼에서 나온 장면이 기억에 남았습니다.
대화 시스템, 멀티 엔딩, 성장, 전투까지 모두 포함된 결과물이었고 영상, 이미지, 나레이션까지 전부 AI로 적용되어 있었고
짧은 시간 안에 만든 게임이라고 보기 어려울 정도의 퀄리티를 가지고 있었습니다.

후기

[출처: 가짜게임개발자 : AI 인간 개발 전쟁 후기｜어겜기]

이번 게임잼을 통해 AI 게임 개발의 현재 수준을 꽤 선명하게 체감했습니다.
사전에 준비한 전용 프로젝트 세팅도 없었고, GitHub 설정부터 MCP 설정, AGENTS.md, 작업 규칙 설정까지 모두 현장에서 잡아야 했습니다.

그럼에도 저는 방향과 우선순위, 그리고 AI 세션들이 엇나가지 않도록 작업 흐름을 조율했습니다.
반복적이지만 시간이 많이 드는 작업 대부분을 AI에게 위임할 수 있었습니다.

그 결과 AI 활용 역량과 고급 모델을 유연하게 활용하면서 짧은 시간 안에 꽤 완성도 높은 결과물을 만들 수 있었습니다.

덕분에 지금까지 참가한 게임잼 중 가장 평화로웠습니다.
게임잼 기간이 짧은 만큼, 범위 코스트를 작게 잡긴 했습니다만
AI 세션을 3개 이상 동시에 돌려두고, 크롬 원격 데스크톱으로 진행 상황을 확인하면서 주변 개발자분들과 대화도 나누고, 행사장도 둘러볼 수 있었습니다.
평소 게임잼에서는 마감에 쫓겨 주변을 볼 여유가 거의 없었는데, 이번에는 제 작업을 관리하면서 다른 사람들이 어떻게 만들고 있는지도 관찰할 수 있었습니다.
사람들과 대화를 나누며 인사이트를 얻고, 다른 참가자들의 AI 활용 방식을 관찰하다보니 게임 개발의 변화가 훨씬 실감났습니다.
당일치기 게임잼에서 경험하는 여유는 꽤 신선했습니다.

저는 최근 올린 [[AI] 게임 개발자의 오픈클로 및 AI 실생활 활용] 글의 후기에 작성한 것처럼, AI 발전 덕분에 개발이 너무 즐겁습니다.
추구하는 성장 방향성에 속도를 더해주는 만큼, 최근 업로드한 [블로그 업로드 자동화 스킬 제작] 글처럼 AI를 활용하여 검색, 자동화, 요약, QA 등 여러 방향으로 실험하며 개발 외적인 생산성 개선에 활용하고 있습니다.

이번에는 Unity MCP의 가능성도 확인할 수 있었으니 앞으로는 MCP와 CLI 활용을 더 연구하면서 엔진 단의 자동화를 넓혀보려 합니다.

긴 글 읽어주셔서 감사합니다.

궁금한 점이 있으시다면 링크드인을 통해 편하게 연락 주시면 감사하겠습니다.
https://www.linkedin.com/in/highcl/

비고1

이번에 제작한 게임은 https://highcl.itch.io/baldo-duel에서 플레이 가능합니다.

비고2

업무를 하는 입장에서 게임잼이 꽤 부담스럽게 느껴질 때가 많았습니다.
이번 행사는 당일치기로 진행돼 피로도가 크지 않았고, 부담 없이 참가하기에 좋았습니다.

다시 한번 좋은 게임잼 행사를 열어주신 고라니님과 셰이더쿠 주한기님께 감사드립니다.
그리고 이 행사를 함께 지원해 주신 많은 분들께도 감사드립니다.

링크

- Tistory - [AI] 게임 개발자의 오픈클로 및 AI 실생활 활용: https://highcl.tistory.com/62
- Tistory - 블로그 업로드 자동화 스킬 제작: https://highcl.tistory.com/64
- 가짜게임개발자 : AI 인간 개발 전쟁 후기｜어겜기: https://www.youtube.com/watch?v=qFahj_e2vjg
- 5시간 게임잼에서 만든 작품 소개합니다 [라이브]: https://www.youtube.com/watch?v=NFfOzqcTeAo&t=10s

[AI] 블로그 업로드 자동화 스킬 제작

HighCl — Tue, 28 Apr 2026 21:08:03 +0900

개요

블로그를 꾸준히 관리하다 보니 글을 쓰는 시간만큼 업로드 과정에도 많은 시간이 들어갔습니다.
작성해 둔 글을 옮길 때마다 서식 유지, 이미지 첨부, 업로드 확인을 계속 신경 써야 했습니다.
특히 비슷한 과정을 반복하다 보니 글 자체보다 배포 과정에서 피로가 더 크게 쌓였습니다.
그래서 Obsidian에서 관리하던 마크다운 Note를 최대한 그대로 블로그에 올릴 수 있도록 업로드 자동화 스킬을 제작했습니다.

목표

목표는 단순했습니다.
본문을 다시 복사하고, 이미지를 다시 맞추고, 글마다 서식을 확인하는 반복 작업을 줄이는 것이었습니다.
블로그 글의 품질은 유지하되, 업로드 과정은 최대한 자동화하고 싶었습니다.

특히 중요하게 본 부분은 두 가지였습니다.
하나는 Obsidian에서 작성한 본문 흐름을 최대한 유지하는 것이었습니다.
다른 하나는 이미지 첨부까지 에이전트에게 맡길 수 있게 만드는 것이었습니다.

프로세스

블로그 본문에 작성할 내용은 PARA Note 기반으로 정리해 두는 만큼,
이 내용을 배포할 수 있는 방법만 찾으면 됐습니다.

처음에는 Tistory API를 활용하는 방향을 찾아봤으나, 기존 Tistory API는 지원이 중단되어 사용할 수 없었습니다.
그래서 Playwright CLI로 웹을 직접 조작하면서 블로그 업로드를 자동화하는 방향으로 잡았습니다.

다만, 브라우저 자동화는 자유도가 높은 만큼 문제가 발생할 가능성도 높습니다.
그래서 script 기반 제어를 통해 제약을 두는 방향으로 설계하여
제어 가능하면서도 안정적으로 블로그 글을 작성할 수 있게 만들고자 했습니다.

이슈

만드는 과정에서 다양한 이슈를 만났습니다.
특히 Playwright를 활용한 브라우저 자동화 과정에서 예상보다 많은 기술 이슈가 나왔습니다.

- 실행 환경 이슈
문제1: Chrome 프로필 경로가 실제 User Data 구조와 어긋나면 자동화가 바로 멈췄습니다.
문제2: 실행 인자가 조금만 달라도 같은 흐름이 재현되지 않았습니다.
문제3: 원격 제어 포트 조건이 맞지 않으면 자동화가 시작조차 되지 않았습니다.
그래서 전용 프로필 경로, 실행 인자, 원격 제어 조건을 고정하고 실행 기준을 하나로 정리했습니다.

- 티스토리 에디터 판정 이슈
문제1: 겉으로는 같은 화면처럼 보여도 실제로는 다른 모드인 경우가 있었습니다.
문제2: 숨은 편집 영역을 잘못 읽어서 에디터 상태를 잘못 판단하는 문제가 있었습니다.
문제3: 첫 번째 편집기만 잡는 방식 때문에 실제 입력 대상이 아닌 곳을 건드리는 경우가 있었습니다.
그래서 실제로 보이는 상태를 더 엄격하게 확인하도록 바꾸고, 모드 전환과 편집기 판정 로직을 다시 다듬었습니다.

- 본문과 이미지 분리 이슈
문제1: 본문 입력과 이미지 첨부는 실패 지점이 달랐는데 처음에는 한 단계처럼 다뤘습니다.
문제2: 그래서 어디서 막혔는지 파악하기 어려웠고, 재시도 과정도 비효율적이었습니다.
그래서 본문 반영 단계와 이미지 반영 단계를 분리했습니다.
본문 반영 단계에서는 이미지가 들어갈 위치에 표시를 남겨두고, 이미지 반영 단계에서 해당 표시를 실제 이미지로 전환하는 방식으로 수정했습니다.

- 이미지 업로드 방식 이슈
문제1: 파일 선택기 방식은 상황에 따라 불안정해서 같은 동작이 안정적으로 재현되지 않았습니다.
문제2: 실패를 가리는 우회 처리 때문에 실제 원인을 찾기 더 어려웠습니다.
그래서 이미지 반영 방식을 클립보드 붙여넣기 방식으로 바꾸고, 실패하면 원인이 바로 드러나도록 수정했습니다.

- 마크다운 변환 이슈
문제1: 마크다운 모드로 작성하니 줄바꿈이 사라지거나 빈 줄이 무너져서 초안의 읽는 흐름이 달라졌습니다.
그래서 작성한 글의 서식을 유지한 채 HTML로 변환한 다음, HTML 모드로 입력하도록 하여 본문 형태가 최대한 유지되도록 했습니다.

결과

결과적으로 제가 원했던 범위 이상으로 만족스러운 결과물이 나왔습니다.
Obsidian에서 글을 정리하고, 자동화 스킬을 통해 Tistory 글쓰기 화면에 반영하는 흐름까지 연결할 수 있었습니다.

특히 인상 깊었던 부분은 세 가지였습니다.

- Playwright는 로컬 서버 포트를 열고 CDP를 통해 통신한다는 점.
- 기본 프로필은 자동화 도구로 제어하지 못하게 구현되어 있다는 점.
- 본문에 이미지를 추가할 때 파일 탐색기를 사용하면서 발생하는 여러 복잡한 이슈를 복사 붙여넣기라는 간단한 방식으로 해결할 수 있었다는 점.

Playwright와 프로필 관리 규칙에 대한 도메인 지식이 부족하다 보니 여러 이슈를 만났습니다.
이를 해결하는 과정에서 도메인 지식의 중요성을 다시 한번 상기했고, 관련 지식이 늘어나는 계기가 되었습니다.

긴 글 읽어주셔서 감사합니다.

궁금한 점이 있으시다면 링크드인을 통해 편하게 연락 주시면 감사하겠습니다.
https://www.linkedin.com/in/highcl/

[AI] 클로드와 코덱스를 활용한 멀티 에이전트 루프 실험기

HighCl — Mon, 20 Apr 2026 03:24:51 +0900

개요

이번에 클로드를 결제하면서 클로드와 코덱스를 한 루프로 묶어서 설계와 구현을 분리하는 흐름을 직접 실험해봤습니다.
이번 글에서는 왜 이 조합을 시도했는지, 실제로 어디까지 작동했는지, 그리고 왜 아직은 실무에 바로 쓰기 어렵다고 느꼈는지를 정리해보려 합니다.
결론부터 말하면 흐름 자체는 확인했으나, 아직은 실무에 바로 넣기에는 속도와 비용에 대한 비효율이 컸습니다.

배경

많은 사람들의 의견과 여러 AI를 사용해본 입장에서 각 모델별로 특징을 아래와 같이 느꼈습니다.
클로드는 설계와 메모리 기능과 같은 다양한 기능이 강점이지만 토큰 여유가 크지 않고,
코덱스는 구현 능력이 뛰어나면서도 비교적 넉넉한 토큰을 활용할 수 있습니다.

이를 바탕으로 제가 기대한 역할 분담은 비교적 단순했습니다.

Claude는 설계 정리와 메모리 활용을 담당
Codex는 넉넉한 토큰을 바탕으로 실제 구현을 담당

즉, Codex의 많은 토큰량과 구현 능력을 활용하면서 Claude가 가진 메모리와 보조 기능을 함께 사용할 수 있는 작업 흐름을 만들고 싶었습니다.

플러그인 구성

codex-plugin-cc는 클로드 코드 안에서 코덱스를 호출해 코드 리뷰를 맡기거나, 별도 작업을 백그라운드로 위임할 수 있게 해주는 플러그인입니다.
기본적으로 로컬에 설치된 codex 실행 파일과 인증 정보를 그대로 사용합니다.

실제 작업에서 사용하는 주요 명령어는 다음과 같습니다.

명령어

/codex:review

/codex:adversarial-review

/codex:rescue

/codex:status

/codex:result

/codex:cancel

실험

이번 실험에서는 가장 기본적인 /codex:rescue를 먼저 사용해보는 방향으로 실험을 진행했습니다.
안드레 카파시가 제시한 llm wiki를 기반으로 만든 클로드 플러그인 LLM wiki compiler를 사용해보고자 했습니다.
이 플러그인은 설정 과정에서 비교적 많은 토큰을 요구하기 때문에, 많은 토큰을 활용할 수 있는 코덱스에게 처리를 위임하려던 이번 실험 방향과도 잘 맞았습니다.

토큰 소모량이 큰 초기화 작업을 codex:rescue를 통해 서브 에이전트에게 위임하도록 프롬프트를 작성했고,
클로드는 codex:rescue를 활용해 서브 에이전트 7개를 호출했고, 이를 통해 초기화 과정을 마무리했습니다.

결과

하지만 결과만 보면 실험은 절반 이상 성공이었습니다.
흐름 자체는 실제로 돌아갔고, 설계와 구현을 분리했을 때 어떤 장점이 생기는지도 체감할 수 있었습니다.

문제는 속도가 너무 느렸습니다.
체감상 한 번 돌릴 때 20분 이상 걸릴 정도로 느렸고 대기하는 동안 토큰도 계속 소모되어 부담이 컸습니다.
또한, 서브 에이전트 상태를 확인하기 어려운 점도 답답했습니다.
codex:status로 현재 작동 중인 에이전트를 확인할 수는 있었지만, 내부 진행 상황까지 파악하기는 어려웠습니다.
그래서 멈춘 것인지, 아직 작업 중인 것인지 알기 어려웠습니다.

즉, 구조는 흥미로웠지만 실무에서 사용하기 위해서는 속도가 먼저 해결되어야겠다는 판단이 들었습니다.

https://github.com/openai/codex-plugin-cc/issues
관련 이슈 목록을 함께 확인해보니, 아직 초기 단계인 만큼 다양한 문제 제보가 계속 올라오고 있었습니다.
이 조합은 아이디어 차원에서는 흥미롭지만, 실제로 안정적인 작업 환경이라고 보기에는 아직 이르다고 판단했습니다.

회고

이번에는 기대만큼 만족스러운 결과를 얻지는 못했지만, 이런 루프 자체가 가진 비용 효율의 가능성은 여전히 유효하다고 봤습니다.
그렇기에 속도와 토큰 효율, 진행 상태 확인만 조금 더 좋아지면 다시 시도해볼 만하다고 느꼈습니다.
추후 개선이 된다면 실제 작업 루프 기준으로 어디까지 실용적으로 쓸 수 있는지 더 구체적으로 확인해보고 싶습니다.

긴 글 읽어주셔서 감사합니다.

궁금한 점이 있으시다면 링크드인을 통해 편하게 연락 주시면 감사하겠습니다.
https://www.linkedin.com/in/highcl/

비고

이번 작업을 계기로 클로드를 처음 사용해봤습니다.
예전에도 Gemini에서 코덱스로 넘어올 때 비슷하게 느꼈지만, 결국 중요한 것은 모델 자체보다 설계와 구성 방식이라는 점을 다시 확인했습니다.
AI의 핵심 구조인 Agent.md, 스킬, 훅 등의 하네스를 잘 잡아두니 모델을 바꾸는 일이 생각보다 훨씬 수월하다는 점을 느꼈습니다.

링크

GitHub: https://github.com/openai/codex-plugin-cc
실 사용 영상(편집자P): https://youtu.be/rHALOHWBsL4?si=rTZXgWWSoEY8ov8q&t=1160

[AI] 게임 개발자의 오픈클로 및 AI 실생활 활용

HighCl — Thu, 9 Apr 2026 02:03:08 +0900

개요

요즘 저는 AI를 단순히 질문에 답해주는 도구가 아니라, 실제 생활과 작업 흐름을 줄여주는 실행 도구로 익히고 있습니다. 그 과정에서 특히 흥미롭게 보고 있는 것이 오픈클로 같은 에이전트형 워크플로우입니다.

얼마 전 팝업스토어 현장에서 제휴 카페 5곳이 적힌 안내 이미지를 본 적이 있었습니다. 시간이 늦어 운영 시간과 동선을 빠르게 확인해야 했는데, 이미지를 보고 매장 이름을 하나씩 옮겨 적은 뒤 검색하는 방식은 번거롭고 실수도 나기 쉽습니다.

집에 돌아온 뒤 이 과정을 오픈클로로 다시 풀어봤습니다. 단순히 검색을 대신해주는 AI 정도가 아니라, 이미지에서 정보 추출, 웹 탐색, 정리, 산출물 제작까지 한 흐름으로 연결되는 경험이 꽤 인상적이었습니다. 이번 글에서는 그 과정을 정리하면서, 제가 요즘 AI를 어떤 식으로 활용하고 있는지도 함께 남겨보려고 합니다.

프로세스 1. 이미지에서 매장 이름 추출

가장 먼저 한 일은 이미지에서 텍스트를 읽고, 필요한 정보만 골라내는 것이었습니다.
이 단계에서 저는 텍스트를 잘 못 읽을 가능성을 고려하여 먼저 월드 스페이스 서울을 제외한 5개 카페의 이름을 추출해 달라고 요청했습니다.
설정 이슈로 처음에는 문제가 조금 있었지만, 곧 정확하게 리스트를 추출할 수 있었습니다.

프로세스 2. 추출한 매장 이름 검색

prompt:

이 5개 카페를

운영 시간,
네이버 지도 링크,
유명한 음식

세 가지로 정리해서 보고서를 제출해

이후에는 추출한 매장 이름을 기준으로 검색을 돌렸습니다.

직접 브라우저를 열어서 하나씩 찾는 대신, playwright cli를 활용하여 직접 웹 브라우저를 탐색하며 필요한 정보를 모으도록 제작했습니다.

특히 운영 시간, 지도 링크, 대표 메뉴처럼 반복적으로 확인해야 하는 항목은 사람이 수작업으로 할수록 집중력이 분산되기 쉬운데, 이런 부분에서 꽤 실용적이라고 느꼈습니다.

프로세스 3. 검색 결과를 보고서로 정리

익선동 카페 보고서.pdf

0.07MB

검색으로 모은 정보는 나중에 다시 보기 어렵습니다. 그래서 저는 중간 산출물을 보고서 형태로 묶는 방식을 선호합니다. 한 번 정리된 문서가 생기면 비교도 쉽고, 다른 사람에게 보여주기도 훨씬 편해집니다.

이번에도 단순 검색 결과 나열이 아니라, 바로 확인 가능한 형태의 보고서로 정리해두었습니다. "찾기"와 "정리"가 따로 노는 것이 아니라 한 흐름으로 이어진다는 점이, 실제 활용 관점에서 꽤 강하게 다가왔습니다.

프로세스 4. PPT 제작

마지막으로 정리된 보고서를 스킬을 활용하여 PPT로 변환하는 단계까지 이어갈 수 있었습니다.

앞으로의 방향성

무엇보다 인상적이었던 점은, 위 과정이 결국 하나의 요청으로 연결될 수 있다는 부분입니다. 이번에는 구현과 검증을 위해 단계별로 나누어 진행했지만, 방향성 자체는 이미 꽤 분명합니다. 앞으로는 한 번의 명령으로 의도한 산출물까지 자연스럽게 이어지게 만들 수 있습니다.

예를 들면 아래와 같은 식입니다.

이미지 속 월드 스페이스 서울을 제외한 5개 카페를 정리하고, 운영 시간·네이버 지도 링크·대표 음식 3가지를 포함한 뒤, Highcl Brand Guideline 스킬과 PPTX 스킬을 활용하여 PPT로 제공해

ikseon_cafes_white_gray.pptx

0.04MB

지금은 아직 손으로 다듬는 단계가 일부 남아 있지만, 방향은 분명합니다. 필요한 기준과 스킬만 잘 정리해두면 한 번의 명령으로 꽤 완성도 높은 아웃풋이 나옵니다. 위에 첨부한 PPT도 그런 가능성을 확인해본 결과물입니다.

PARA, Second Brain, 그리고 AI4PKM

저는 요즘 Obsidian을 활용해 PARA 기반의 Second Brain과 AI4PKM 환경도 함께 구축하고 있습니다. 관련해서는 이 글에서도 정리했는데, 핵심은 AI가 제 문맥을 더 잘 이해할 수 있는 기반을 직접 만드는 데 있습니다.

예를 들어 20_Area 아래 20_운동 관계성 파일과 그 안에 연결된 운동 일지 Note들이 충분히 쌓여 있다면, 단순 일반론이 아니라 제 실제 기록을 바탕으로 다음 운동 루틴을 제안받는 식의 활용도 가능할 것입니다. 결국 중요한 건 AI 자체보다, AI가 읽을 수 있는 개인 데이터 구조를 얼마나 잘 설계하느냐라고 생각하고 있습니다.

물론 이런 활용에는 항상 주의가 필요합니다. 오픈클로 같은 에이전트형 도구는 편리한 만큼 보안 이슈를 신경 써야 하고, AI 환각 문제도 여전히 분명히 존재합니다. 그래서 저는 "무조건 맡긴다"보다 "제약과 단계별 보고를 통해 검증 가능한 흐름으로 설계한다"는 쪽에 더 가깝게 접근하고 있습니다.

스킬을 내 작업 방식에 맞게 다듬는 중

요즘은 스킬 자체도 더 정밀하게 설계하고 있습니다. 여기서 말하고 싶은 건 방금 보여드린 PPT 결과물 하나가 아니라, 그런 결과물을 반복 가능하게 만드는 작업 환경 자체를 계속 다듬고 있다는 점입니다.

Anthropic에서 공개한 skills 저장소에는 브랜드 가이드라인이나 PPTX 제작과 관련된 스킬도 포함되어 있습니다. 저는 이런 공개 스킬을 그대로 사용하는 데서 멈추지 않고, 제 작업 방식에 맞는 구조로 다시 수정합니다.

예를 들어 브랜드 가이드라인 스킬에는 로고나 심볼 같은 리소스를 붙이고,
PPTX 스킬에는 제가 선호하는 템플릿과 피드백 루프를 추가하는 식입니다.
이렇게 다듬어두면 두 스킬을 동시에 트리거했을 때 브랜드에 맞으면서도 가독성 좋은 발표 자료를 자동으로 만드는 방향으로 연결할 수 있습니다.

이런 스킬들은 GitHub로 관리하고 있습니다. 여러 로컬 환경에서 Codex, Gemini, OpenClaw 같은 에이전트가 각자 필요한 구조를 빠르게 세팅할 수 있도록 common-skill-sync 같은 보조 스킬도 따로 만들어 두었습니다. 결국 제가 하고 있는 일은 AI를 잘 쓰는 법을 찾는 것과 함께, 반복 가능한 작업 환경을 구축하는 데 더 가깝습니다.

후기

신입 프로그래머인 저는 요즘 개발이 정말 재미있습니다.

예전에는 개발 무용론에 대한 불안감 때문에 걱정할 때도 많았습니다.

사실 지금도 완전히 자유로운 것은 아닙니다.

그런데 AI를 배우면 배울수록, 더욱 놀라게 됩니다. 1년 전 4월쯤 주변 지인의 도움으로 AI의 강력함을 조금 일찍 체감했고, Cursor를 통해 에이전트 개발을 시작하면서 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링, MCP, CLI 등 여러 흐름을 직접 따라가 보았습니다.

그 과정에서 회사 안에 AI 활용 문화를 정착시키는 데 기여했고, 제 작업 방식에 맞는 하네스 세팅도 꾸준히 다듬어 왔습니다.

덕분에 기존 프로젝트와 라이브러리를 더 정밀하게 다루고, 게임잼이나 신규 프로젝트 초반에 필요한 아키텍처와 기반 작업도 예전보다 훨씬 빠르게 시작할 수 있게 되었습니다.

AI의 발전 속도는 솔직히 무서울 정도로 빠릅니다.

그렇기에 역설적으로, 저는 지금이 즐겁습니다.

저는 지난 몇 년 동안 인디 팀에서 팀장 역할을 맡으면서 재미있는 아이디어가 구현 속도 문제로 사라지는 장면을 여러 번 봤습니다. 그래서 자연스럽게 개발 속도를 높여 아이디어 검증 비용을 낮추는 환경에 관심이 많아졌습니다. 이 일환으로 입사 전부터 꾸준히 개인 라이브러리를 관리해왔으며, AI 환경 세팅에 노력을 기울였습니다.

제가 되고 싶은 개발자는, 기획자가 기술 제약에 막히기보다 아이디어의 본질과 코어 재미 구현에 더 오래 집중할 수 있게 도와주는 사람입니다.

그리고 그 성장의 끝에는 제가 만든 게임으로 누군가에게 긍정적인 영향을 주고 싶다는 꿈도 있습니다.

요즘은 AI의 발전이 그런 꿈에 저를 조금 더 가까이 데려가고 있다는 생각을 자주 합니다.

반년 뒤에는 무엇이 가능해질지,

한 달 뒤에는 무엇이 등장할지,

심지어 일주일 뒤에는 또 어떤 것이 바뀌어 있을지

정말 가늠하기 어렵습니다.

그만큼 제가 할 수 있는 맨파워도 커지고 있고, 하고 싶은 일도 점점 많아지고 있습니다. 다만 AI에 휘둘리지 않도록 균형 잡힌 시각을 유지하고, 기술을 좇다가 정작 저라는 사람의 방향을 잃지 않으려는 태도는 계속 붙잡고 가고 싶습니다.

그래서 앞으로도 기본에 충실하면서 천천히 나아가 보려고 합니다.
결국 중요한 건 어떤 방향으로 가고 있는지라고 생각합니다.

긴 글 읽어주셔서 감사합니다.

궁금한 점이 있으시다면 링크드인을 통해 편하게 연락 주시면 감사하겠습니다.
https://www.linkedin.com/in/highcl/

비고1

저와 관련된 주요 글들은 아래에서 확인하실 수 있습니다.

2025 - 게임잼_Star Mari - 거실 게임잼2 참가 회고
2025 - MCP 연구 - ExcelMCP 활용 워크프로세스 개선
2024 - 로프 타겟 보정 구현 과정
2023 - Hellbound Ropes(헬바운드 롶즈) 회고

Antigravity - Prompt Enhancement Workflow

HighCl — Sun, 25 Jan 2026 14:17:29 +0900

개요

AI와 함께 코딩을 하다 보면, 모호한 프롬프트 한 줄 때문에 의도와는 전혀 다른 결과물이 나와 당황스러울 때가 많습니다.

이를 방지하기 위해서는 프롬프트를 아주 구체적으로 작성해야 하지만, 매번 구체적인 프롬프트를 짜는 것은 부담이 됩니다.

여기서 구체적이라 함은 현재 코드베이스에 대한 이해보다는

명령에 대한 의도, 의의를 전달하는 데 있어서 개념의 구체성을 의미합니다.
AI는 기본적으로 프롬프트에 담긴 내용을 그대로 반영하려고 노력하기 때문에, 의도가 불분명하게 전달된다면 기능 역시 모호하게 구현될 수밖에 없습니다.

최근 Cursor나 Antigravity와 같은 도구들은 'Plan' 모드를 통해 사용자의 의도를 어느 정도 파악하며 작업을 진행하기도 합니다.

하지만 새로운 대화를 시작하는 첫 번째 질문에서부터 의도가 어긋나면, 서로의 싱크를 맞추는 데 생각보다 많은 Cost가 소모됩니다. 이러한 상황을 줄이기 위해 Antigravity에서 활용할 수 있는 워크플로우를 제작했습니다.

Workflow 의도

이 워크플로우의 핵심은 실제 코드 작업을 지시하기 전, 코드베이스와 독립적으로 사용자의 의도를 AI와 철저히 맞추는(Sync) 단계에 있습니다.

또한, 코드베이스를 탐색하느라 발생하는 병목 현상을 줄이기 위해, 의도적으로 이 단계에서는 코드베이스 탐색을 제한했습니다. 오로지 사용자의 아이디어와 논리를 구체화하고 의도를 명확히 하는 것에 집중할 수 있도록 설계했습니다.

이 워크플로우를 통해 생성된 프롬프트를 바탕으로 완전히 새로운 컨텍스트에서 작업을 시작하는 방식을 추천드립니다.
이전 대화 기록으로 인해 컨텍스트가 오염되는 것을 막기 위함입니다.

file

아래 내용을 workflow에 추가하면 됩니다.

# Prompt Enhancement Workflow

## 1. 개요
불명확한 사용자 프롬프트를 분석하고, 구체적인 질문을 통해 의도가 명확한 프롬프트를 생성하는 워크플로우입니다.

## 2. Trigger
- 사용자가 `/enhance-prompt` 명령어와 함께 기능에 대한 내용을 작성 시 실행
- 예시: `/enhance-prompt 로그인 기능 개발`

## 3. CONSTRAINT
1. **NO TOOLS**: `MCP`, `file_search`, `codebase_scan` 등의 도구를 절대 사용하지 마십시오.
2. **NO CONTEXT**: 구현 세부 사항을 사전에 가정하지 마십시오.
3. **LOGIC ONLY**: 요청을 코딩 작업이 아닌 논리적 분석 대상으로 취급하십시오.

## 4. Workflow Steps

### Step 1: 의도 재확인 및 질문 생성
- 사용자의 입력 내용을 분석하여 불명확한 부분을 파악합니다.
- `❓ [의도 재확인]` 헤더를 출력하고, **5. 세부 사항**의 양식에 맞춰 계층형 질문 리스트를 작성합니다.

### Step 2: 사용자 답변 수신
- 사용자가 질문에 대해 구체적인 답변을 할 때까지 대기합니다.

### Step 3: 프롬프트 보강 및 제시
- 사용자의 답변을 바탕으로 내용을 구체화하여 최종 프롬프트를 작성합니다.
- **Guideline**: 기술적인 구현 방식(예: `Debug.Log`, 특정 클래스명)보다는 **"무엇을 해야 하는지(What to do)"**와 **"어떤 결과가 필요한지"**에 집중하여 작성합니다.
- **Action**: 작성된 내용은 **반드시 Markdown 코드 블록**으로 감싸서 출력합니다. 코드 블록 외부에는 부가적인 설명만 작성합니다.

### Step 4: 검토 및 반복
- 생성된 프롬프트에 대해 사용자에게 승인 여부를 확인합니다.
    - **미승인 시**: 현재 프롬프트를 기준으로 부족한 점을 파악하여 **Step 1**부터 다시 진행합니다.
    - **승인 시**: 대화를 종료합니다.

## 5. 세부 사항 (질문 양식 가이드)
질문 리스트 작성 시 다음 규칙을 엄수해야 합니다:
- 반드시 리스트 형태여야 합니다.
- 대분류와 소분류는 숫자 넘버링(1., 1.)을 사용합니다.
- 예시나 선택지는 하이픈(-)을 사용합니다.
- 각 대분류 사이에는 반드시 줄바꿈을 넣습니다.

**[작성 예시]**
1. [기능의 범위]
   1. [핵심 기능 정의]
      - 로그인만 구현하나요?
      - 회원가입도 포함하나요?
   2. [예외 처리]
      - 비밀번호 분실 시 로직이 필요한가요?

2. [기술 스택]
   1. [인증 방식]
      - JWT를 사용하나요?
      - Session 방식을 선호하나요?

사용법

1. 요청
워크플로우 호출과 함께 평소처럼 기능을 요청합니다.
예시에서는 의도적으로 프롬프트를 단순화 시켰습니다.

그러면 AI가 프롬프트를 구체화하기 위한 질문을 합니다.
이 질문에 답변하면서 의도에 대한 sync를 맞춥니다.

질문에 대한 답변을 통해 프롬프트가 생성됩니다.
이 프롬프트는 즉시 복사할 수 있도록 markdown(.md) 형태로 제공됩니다.

모호한 프롬프트로 뒤끝 SDK를 활용한다는 점을 몰랐으므로, 이에 대한 재질문을 요청하고,
추가 질문을 통해 의도와 일치하게 프롬프트를 제작합니다.

제작된 프롬프트는 새 컨텍스트에 전달하여 구현을 시작합니다.

[스크랩]올인원 RAG 프레임워크 오픈소스 WeKnora | Tencent

HighCl — Sun, 21 Dec 2025 22:25:43 +0900

https://www.linkedin.com/posts/h4y3j1n_tencent-activity-7407555266591932416-7ScG?utm_source=share&utm_medium=member_desktop&rcm=ACoAAEGB-XEB0Xy6DcNYtpUnsNdRWdkWnKkubHE

#tencent | HaYeJin Kang

#Tencent 가 미쳤네요. 올인원 RAG 프레임워크를 오픈소스로 내놨습니다. ReACT 패턴으로 지식베이스 + 웹 검색 + MCP 도구까지 알아서 조합해서 답변하도록 개발되었어요. 그러니까 예를 들어 "우리

kr.linkedin.com

링크드인에서 발견한 글입니다.

Tencent에서 올인원 RAG 프레임워크를 오픈소스로 공개했다네요

노트를 실행 중심으로: PARA 정리법 2주 실험기

HighCl — Sat, 1 Nov 2025 21:38:40 +0900

✏️ 도입 목적

1. 복잡한 노트 정리의 한계와 새로운 시도

기존에는 주제별로 노트를 구분해 정리했지만, 시간이 지날수록 복잡도가 높아지고
새로운 아이디어나 작업을 어디에 넣어야 할지 혼란스러워졌습니다.
이 문제를 해결하기 위해 2주간 노션을 기반으로 ‘PARA 노트 정리법’을 도입해보기로 했습니다.

닥터가드너(안과 전문의이자 생산성 크리에이터)의 영상을 통해 처음 접했습니다.
참고 영상
노션 PARA 템플릿

2. PARA 정리법이란?

PARA는 Projects, Areas, Resources, Archives의 약자입니다.
핵심은 ‘주제’가 아닌 실행 정도에 따라 노트를 분류하는 것입니다.

구분	의미	예시
P - Projects	단기 실행 중심의 목표나 과제	"회사 블로그 업로드", "지스타 출장 준비"
A - Areas	지속적 관리가 필요한 영역	"업무 관리", "블로그 운영"
R - Resources	참고용 자료, 영감, 수집 정보	"생활 팁", "개발 공부"
A - Archives	완료된 항목, 보관용 자료	"완료된 프로젝트", "과거 여행 기록"

이 구조는 ‘지금 무엇을 해야 하는가’를 빠르게 파악하게 도와줍니다.
즉, 노트를 찾는 구조가 아니라, 실행을 중심으로 노트가 움직이는 구조입니다.

3. PARA 기법 사용성 연구 계획

기간: 2025.10.09 ~ 2025.10.22
목표: 새로 작성하는 노트에 PARA 방식 적용 후 효율성 검증

4. 사용 후기 및 실제 적용 사례

느낀 변화

실행 우선순위가 명확해짐
프로젝트 단위로 정리되다 보니, 지금 집중해야 할 일이 무엇인지 한눈에 보였습니다.
중복·누락 최소화
한 노트를 여러 프로젝트나 Area에 연결할 수 있어,
관련 자료를 찾거나 중복 작성하는 일이 줄었습니다.
고정 노트로 장기 관리 가능
주기적으로 확인이 필요한 항목(예: 점검표, 루틴)을 고정해두니 지속 관리가 쉬웠습니다.

실제 적용 예시

1. 회사 기술 블로그 프로젝트
이는 특히 분류가 애매한 경우에 매력적으로 느껴졌습니다.
최근 회사의 요청으로 기술 문서를 주기적으로 블로그에 업로드할 예정인데,
이 경우 하나의 노트가 아래와 같이 여러 영역에 걸치게 됩니다.

Project: 회사 프로젝트
Area: 블로그
Resource: 개발 공부
노션의 관계형을 통해 이 모든 영역에 노트를 연결할 수 있어
누락되는 일 없이 지식을 효과적으로 관리할 수 있다고 생각했습니다.

2. 지스타 출장 준비

이전엔 ‘여행 준비물 / 예매 팁 / 시간 정리’가 각각 흩어져 있었지만,
PARA 적용 후 다음과 같이 정리되었습니다.

내용	분류
시간·비용 정리	Project – 지스타 출장
여행 준비물	Archive – 생활 팁
기차 예매 팁	Archive – 생활 팁

다음 여행 시에도 단순히 새 프로젝트에 기존 노트를 연결하면 끝이 나고
관리 비용이 크게 줄었습니다.

5. 결론

2주간의 테스트를 통해 느낀 PARA의 핵심은 "단순하지만 유기적인 구조"였습니다.
노트를 실행 기준으로 관리하니,

정보가 쌓일수록 오히려 정리 부담이 줄고 재활용성은 높아지는 효과가 있었습니다.

특히 분류가 애매한 경우, 이전 정리법보다 훨씬 매력적으로 느껴졌습니다.
기존 주제별 분류 방식에서는 한 노트가 여러 카테고리에 속할 때 어디에 두어야 할지 고민이 되었지만,
PARA 방식은 하나의 노트를 여러 영역(Project, Area, Resource 등)에 동시에 연결할 수 있어
분류 기준이 불명확한 경우에도 유연하게 대응할 수 있다는 점이 큰 장점이었습니다.

이 경험을 바탕으로, 닥터가드너가 제작한 세컨드 브레인 OS 템플릿에도 관심이 생겼습니다.( 템플릿 링크)
해당 템플릿은 PARA뿐 아니라 GTD, NUDGE, CODE 등 다양한 생산성 프레임워크를 통합한 시스템입니다.

앞으로도 PARA 기법을 중심으로 문서와 지식을 관리해 나갈 예정이며,
추후 세컨드 브레인 OS를 직접 사용하게 되면 그 후기도 함께 공유하겠습니다.

비고

학습 전략 및 지식 소화 방법

PARA 기법 연구 과정에서 노트 정리법 외에도 다양한 생산성 프레임워크와 학습 방법론을 함께 학습할 수 있었습니다.

( 참고 영상)

Color Bath Effect와 PARA의 Project 연계: 가장 실행도가 높은 프로젝트를 리마인드한 후 목표를 구체화하여 학습하는 전략
지식 구조화 방법: 마인드맵 또는 상하위 재구성을 통한 지식 배치 및 연결
독서 노트 작성법: 조각 노트 생성 → 북노트로 묶기 → 아웃풋 노트에 전체 주제 및 구조 작성

Unity Text Mesh Pro 이모지 폰트 추가

HighCl — Sun, 19 Oct 2025 21:24:05 +0900

작성 및 공유 안내

소속 팀의 기술 공유 요청에 따라 개인 시간을 활용하여 작성한 글로,
회사 및 프로젝트 특정 정보가 배제된 순수 기술 내용으로 구성하여 블로그 공유 허가를 받았습니다.

1. 목적

Unity 프로젝트에서 TextMeshPro 기반 로그 시스템의 이모지 지원 구현

문제 상황: Ingame Debug Asset 실행 시 이모지 폰트 누락으로 인한 지속적인 Warning 메시지 발생
해결 방향: 로그 메시지 구분을 위한 이모지 활용 시 폰트 지원 추가
기대 효과: 로그 오염 제거 및 디버깅 효율성 향상
구현 방식: TMP Settings의 Fallback Emoji 기능을 활용하여 사이드이펙트를 최소화하여 구현

2. 조건

기능적 요구사항

로그 메시지에 사용되는 이모지만 지원 (전체 이모지 세트 불필요)
기존 Text Asset 사용에 미치는 영향 최소화

기술적 제약사항

상업적 이용 가능한 폰트 사용 필수 (Windows Segoe UI Emoji는 상업적 이용 제한)
개발 환경 전용 사용 (실제 게임 배포 시에는 이모지 미사용)

3. 설계에 대한 고민

1. 폰트 선택 전략

라이선스 고려사항: Windows 기본 Segoe UI Emoji는 상업적 이용 제한
선택한 솔루션: Google의 Noto Color Emoji (SIL 오픈 폰트 라이선스)
최적화 접근: Dynamic Font 활용으로 실제 사용되는 이모지만 로드하여 용량 최소화

2. 구현 아키텍처 설계

핵심 기술: Unity TextMeshPro의 Fallback Emoji 기능 활용
설계 원칙: 기존 TMP Component에 추가 설정 없이 자동 지원
성능 보장: 런타임 중 Fallback 발생 최소화로 성능 영향 제거

4. 분할

1단계: Font Asset 준비

Google Noto Color Emoji 폰트 파일 다운로드
Unity 프로젝트에 폰트 파일 임포트 및 설정

2단계: Font Asset 생성

Unity Editor에서 Create/TextMeshPro/Font Asset/Color 실행
이모지 전용 Font Asset 생성 및 최적화 설정

3단계: TMP Settings 통합

TMP Settings의 Fallback Emoji 필드에 생성된 Font Asset 연결
기존 TMP Component들의 자동 이모지 지원 활성화

5. 배치

구현 순서

1. Noto Color Emoji 폰트 파일 준비 및 Unity 프로젝트 임포트
2. Unity Editor에서 우클릭 → Create/TextMeshPro/Font Asset/Color 실행
3. 생성된 Font Asset을 TMP Settings의 Fallback Emoji 필드에 연결
4. 기존 TMP Component들은 추가 설정 없이 자동으로 이모지 지원 활성화

6. 결과

구현 완료 사항
TMP Settings의 Fallback Emoji 기능을 활용하여 기존 TMP Component에 추가적인 설정 없이 구현 완료

달성 효과

이모지 폰트 누락으로 인한 Warning 메시지 완전 제거
로그 시스템의 가독성 향상으로 디버깅 효율성 증대
개발 환경에서의 사용자 경험 개선

7. 후속 처리

이모지 폰트 추가로 발생하는 사이드이펙트 검증

용량 영향 분석

Dynamic Font 활용으로 실제 사용되는 이모지만 로드하여 실질적 용량 최소화
향후 Addressable Asset System 도입을 통한 추가 최적화 가능성 확보

성능 영향 분석

개발 환경 전용 사용으로 배포 버전에 성능 영향 없음
런타임 중에는 Fallback이 발생하지 않아 성능 영향 없음

참고 자료

CursorIDE 상속 클래스 참조 확인 방법

HighCl — Sat, 18 Oct 2025 20:38:48 +0900

참조를 확인할 때 보통 Shift + F12를 눌러서 확인합니다.

이 경우 변수 선언 등을 포함하여 사용되는 모든 위치가 표시되기에 탐색에 불편함이 있었습니다.
Ctrl + Shift + F12를 누르면 상속 관계에 있는 클래스만 표시되는 기능이 있어 공유합니다.

예시 코드

public class TempA
{
}
public class TempBInA : TempA
{
}
public class TempC : TempBInA
{
    public TempA tempA;
}
public class TempDInB : TempBInA
{
}

이전에 사용하던 참조 확인(Shift+F12)은 TempC 클래스에 있는 변수도 표시되지만

피킹 구현(Ctrl + Shift + F12)를 누르면 모든 상속 관계를 보여줍니다

[게임잼]Star Mari - 거실 게임잼2 참가 회고

HighCl — Wed, 8 Oct 2025 19:44:56 +0900

주최: 거실
시간: 주제 발표 후 약 43시간(2025.09.26 ~ 2025.09.28)
장소: 비공개
주제: 별
플레이 링크: https://highcl.itch.io/starmari

회사에 제안드린 게임잼 팀 참가

이번 게임잼은 작은 계기에서 시작되었습니다.
회사의 큰 마일스톤이 마무리되던 시절, 저는 팀장님께 팀 단위로 게임잼 참가를 제안드렸습니다.
이전에 참가한 게임잼을 통해 큰 성장을 했었고, 회사의 핏과도 매치되는 부분이 있었던 만큼,

참가하게 된다면 팀 전체적으로 긍정적인 영향을 줄 것이라고 생각했습니다.

감사하게도 제안을 긍정적으로 검토해주셨고, 회사 분들도 뜻을 함께해 주시며 참가해 주었습니다.
또한, 좋은 계기로 외부 인원과 함께하는 게임잼으로 발전하게 되었습니다.

개발하지 못하면 나갈 수 없는 방

26일 저녁 8시 30분경 주제 발표와 함께 43시간의 대장정이 시작되었습니다.
주제는 GPT를 활용하여 20개의 주제를 뽑은 다음, 뽑기 프로그램을 통해 결정되었습니다.

이번 게임잼에 클라이언트 프로그래머로 참가했으며, 개인적인 목표는 다음과 같았습니다.

CursorAI를 활용한 개발 기간 단축
신규 기술 스택 접목 게임 개발

저는 약 6개월간 CursorAI를 활용해 게임을 개발해오며, 사이드 이펙트를 줄이기 위한 규칙과 워크플로우를 다듬어왔습니다. 이번 게임잼에서는 그동안의 개선된 방식이 실제 개발 속도와 효율성 측면에서 어떤 발전이 있을지 궁금했습니다.

또한, 처음 활용하는 외부 기술 스택이나 API를 단기간에 학습하고, 적용해 보고 싶었습니다.
다행히 GPT API를 활용할 수 있는 기획이 나오게 되면서 이를 적용해보게 되었습니다.

연구비로 투자한 5$

이번 게임잼의 주제는 ‘별’이었습니다.
브레인스토밍 도중 시골 침상에서 하늘의 별을 도화지삼아 그리던 기억이 떠올랐고, 이를 게임으로 구현하자는 의견을 제안드렸습니다. 팀원분들의 좋은 반응 덕분에 다양한 아이디어가 떠올랐고, 금세 방향이 정해졌습니다.

게임의 이름은 ‘별마리’.
‘마리’는 말레이시아어로 “이리 와”라는 뜻을 가지고 있습니다.
어린 시절, 누군가와 함께 밤하늘을 바라보는 그 시절,
별에게 말을 걸며 본인만의 별자리를 그렸던 기억을 떠올리며,
추억과 감성을 불러와 그 시절의 나와 다시 연결될 수 있도록 만들어주는 힐링 게임입니다.

별과 관련된 게임을 제작한 덕분일까요?
신기하게도, 개발 중이던 그날 밤 흐린 하늘 사이로 희미하게나마 오리온자리를 볼 수 있었습니다.

게임잼은 시간이 촉박한 만큼, 단계별 마일스톤과 데드라인, 대비책을 정했습니다.
처음 다뤄보는 GPT API를 활용하기에 구현 가능성을 빠르게 검증하는 것이 중요했습니다.
이를 위한 데드라인을 첫날 새벽까지로 정했고 시간 내 구현이 어려울 경우에 대한 대비책도 준비해두었습니다.
새벽 전에 검증에 성공하게 되면서 이를 활용하는 방향으로 개발을 이어갔습니다.

오랜만에 게임잼은 설레면서도 즐거웠습니다.
이전에 합을 맞춰본 분들과 함께 작업했기에 협업 및 소통 방법에 대해 잘 알고 있었고 원만하게 진행될 수 있었습니다.
근무 이후 진행하는 게임잼인 만큼 체력적인 피로가 있었지만 금세 적응하고 개발을 이어갔습니다.

이처럼 GPT API에 시간을 투자하였으나, 결론적으로 적용하지 않았습니다.
이번 게임에서의 초기 Goal은 GPT에서 점수를 높게 평가받아 전시회를 통과하는 것이 목적인 게임이었습니다.
하지만 개발을 진행하는 과정에서 이 Goal을 제거했습니다.

게임잼 초기부터 GPT API의 기술적 활용에 시간을 많이 할애하여 기술적 구현 및 검증을 모두 마쳤습니다.
호출에 대한 콜백 확인도,
규칙적인 룰 설정도,
등급 산정 및 그에 대한 활용도 모두 확인했습니다.

하지만 점수를 통한 Pass / Fail 구조를 넣는 순간, 플레이어가 ‘통과’를 위한 별자리를 그리게 될 거라 생각했습니다.
이는 창의적인 표현을 제약하고, 결국 몰입을 방해할 수 있다고 판단했습니다.
자유로움과 힐링을 추구하는 게임의 세그먼트, 타겟층에 맞게 과감히 제거했습니다.

그 결과 시연 과정에서 아트분들이 그려준 별자리 그림들에는 자유로운 창작에 대한 열정이 묻어져 나왔습니다.
덕분에 게임에서 더욱 아름답고 몽환적인 분위기를 느꼈습니다.

시연당시 그려주신 그림들

그럼 Goal이 없는 이 게임에서 게임을 하는 목적은 무엇일까요?
그거에 대한 개인적인 생각은 다음과 같습니다.
'현재와 과거와의 연결'

사람은 과거의 여러 사건들을 경험하며 현재의 내가 됩니다.
하지만 바쁜 일상 속에서 과거의 기억들은 점점 희미해지고 잊혀지게 됩니다.
저희는 이 게임을 통해 그런 기억을 회상할 수 있는 게임이었으면 했습니다.
제 어린 시절, 시골 침상에 누워 하늘의 별을 도화지삼아 저만의 별자리를 만들었던 경험처럼
누군가에겐 추억의 기억을,
누군가에겐 설렘의 경험을,
누군가에겐 아련했던 과거를,
회상하고 느끼게 해주고 싶었습니다.
그렇기에 이 게임을 완성해가는 건 플레이어. 즉, 여러분들입니다.

별은 늘 그 자리에 있지만, 바라보는 이의 마음에 따라 다른 별자리가 됩니다.
여러분은 이 게임에서 어떤 별자리를 찾고, 어떤 기억을 떠올리실지 기대하겠습니다.

게임 속에 숨겨져 있는 크래딧

마치며

이번 게임잼을 통해 기술 중심 사고의 함정에 빠졌다는 것을 알게 되었습니다.
GPT API를 게임에 적용하고자 했던 시도는 좋았지만, ‘이 기능이 정말 게임에 필요한가?’라는 질문을 충분히 던지지 않은 채 개발에 들어갔습니다.
결과적으로 많은 시간을 투자했음에도, 게임의 감성과 방향성에는 어울리지 않는다고 판단해 과감히 제거해야 했습니다.

기술을 버리는 결정은 쉽지 않았습니다. 하지만 그 과정을 지나며 한 가지 사실을 깨달았습니다.
’기술이 게임을 완성시키는 게 아니라, 경험이 게임을 완성시킨다’는 사실을요
기술은 수단일 뿐, 그 자체가 목적이 되어선 안 된다는 걸 다시금 느꼈습니다.

게임잼이 끝난 뒤 돌아보니, GPT API를 활용하면서도 감성을 더할 수 있는 방법은 충분히 있었습니다.
예를 들어, 사진 촬영 이후 간단한 코멘트를 덧붙이거나, 전시회에 방문한 사람들의 대사나 말풍선을 자동으로 생성하는 식으로 말이죠.
기술은 감성을 대체하는 것이 아니라, 감정을 보조하고 확장하는 역할을 해야 한다고 느끼게 되었습니다.

결국 기술은 도구일 뿐, 그 자체가 목적이 되어서는 안 됩니다.
이번에는 그것을 간과했고, 그 대가로 시간과 리소스를 잃었습니다.
하지만 덕분에 한 가지를 확실히 배웠습니다.

앞으로는 새로운 기술을 도입하기 전,
게임의 세그먼트와 코호트를 명확히 정의하고,
그 기술이 이 게임에 반드시 필요한 지에 대해 먼저 검증하려고 합니다.
이것이 이번 ‘별마리’ 프로젝트를 통해 배운 가장 큰 교훈입니다.

비고1_세그먼트와 코호트

이번 글에서 작성한 세그먼트와 코호트는 약 1년전 성공하는 프로덕트의 리텐션 극대화 전략이라는 세미나에서 알게 된 개념입니다.

행동을 기준으로 유저를 나누는 세그먼트와 집단을 기준으로 유저를 나누는 코호트라는 개념은
연사님의 Product와 성격은 다르지만, 게임에서도 충분히 유의미한 지표로 고려할 수 있다는 생각을 했었습니다. 그리고 이번 게임잼을 경험하면서 더욱 크게 와닿게 되었습니다.

비고2_감사합니다

작게나마 회사 이야기가 나온는 것에 대해 걱정을 했고, 관련 부분에 대해 조심스럽게 질문드렸습니다.
다행히 문제가 없다고 이야기해 주셔서 이렇게 내용을 작성할 수 있었습니다.
이 글을 빌어 게임잼 참가에 대해 긍정적으로 검토해주신 팀장님과 함께해준 팀원분들에게 다시 한번 감사의 말씀을 드립니다.

그리고 이 글을 끝까지 읽어주신 여러분들 모두 감사합니다.

긴 글 읽어주셔서 감사합니다.

추가적으로 이야기하고 싶은 내용이 있다면 언제든 편하게 공지 내 연락처로 연락주세요

https://highcl.tistory.com/11