취업용으로 블로그를 만들기로 하면서 먼저 해야 할 일은 사이트 디자인이 아니라 작업 목록을 정리하는 것이었다. 지금까지 만든 것이 꽤 많지만, 그대로 나열하면 산만해진다. 그래서 기준을 세웠다.

이 글에는 개발자 블로그에 올릴 만한 것만 남긴다.

통신사 상담, 단순 비교, 지나간 잡무 같은 기록은 블로그에는 넣지 않는다.

공개 글로 먼저 밀 것

Dessert Rush

가장 먼저 공개할 프로젝트다. Godot 게임을 React/TypeScript 기반 Apps in Toss shell에 붙이고, Godot Web runtime을 iframe 없이 top-level canvas로 로드했다.

이 프로젝트는 단순히 게임을 만들었다는 점보다 플랫폼 제약을 처리한 과정이 중요하다. Apps in Toss 환경에서는 shell, 약관, 광고/IAP adapter, 빌드 산출물, QA 체크리스트가 필요했고, Godot는 실제 게임 플레이를 맡았다.

블로그에서 보여줄 수 있는 포인트:

지금 필요한 보강:

Cat Rescue

고양이 구조 퍼즐은 게임 로직과 콘텐츠 제작 도구를 보여주기 좋다. 겉으로는 코지 픽셀 퍼즐이지만, 실제로는 규칙 엔진, JSON 레벨 포맷, 웹 레벨 에디터, Godot/Toss 동기화가 핵심이다.

이 프로젝트에서 보여줄 수 있는 포인트:

이건 “게임 하나 만들었다”보다 “콘텐츠를 계속 만들 수 있는 구조를 만들었다”로 설명해야 한다.

Oracle Tarot

Oracle Tarot은 제품 자체보다 운영 상태를 보는 방식이 더 좋은 글감이다. preview URL이 있다는 사실과 최신 코드가 배포됐다는 사실, readiness가 정상이라는 사실은 서로 다르다.

이 프로젝트에서 보여줄 수 있는 포인트:

취업용으로는 “배포된 서비스의 실제 상태를 확인하는 습관”을 보여주는 글이 된다.

minseo.log

지금 만들고 있는 이 블로그 자체도 하나의 프로젝트다. 다만 포트폴리오 사이트처럼 전면에 내세우기보다, 개인 기술 블로그를 어떻게 설계했는지 정도로만 남기면 된다.

선택한 방향은 RPG Quest Log다. 게임 만드는 사람의 취향은 보이되, 글 목록과 본문 가독성이 중심이어야 한다.

보여줄 수 있는 포인트:

진행 중인 게임 아이디어

꿈 생명체 로그라이트

처음에는 ASCII pet 계열에서 출발했지만, 나중에는 꿈 생명체를 수집하고 키우는 모바일 로그라이트 RPG로 정리했다.

핵심 루프는 다음과 같다.

꿈알 부화
→ 3마리 파티 편성
→ 꿈 던전 입장
→ 자동전투와 방 선택
→ 보상 3택으로 이번 런 빌드 구성
→ 영구 성장 재료 획득
→ HP / ATK / DEF / SPD 훈련
→ 진화와 PvP로 성장 확인

이 아이디어에서 중요한 것은 귀여운 수집형 게임처럼 보이지만, 실제 깊이는 팀 조합, 상태효과, 스탯 투자, 던전 보상 선택에서 만든다는 점이다.

굴밑마을 생존조합

최근에는 꿈 생명체 구조에서 더 어두운 생존 로그라이트로 방향을 틀었다. 작업명은 굴밑마을 생존조합이다.

플레이어는 빈민가의 작은 작업반 관리자다. 매일 의뢰를 고르고, 절차 생성된 동물 노동자 3명을 현장에 보낸다. 현장에서는 자동전투와 위기 선택을 거치며 계속 전진할지, 철수할지, 누군가를 희생해서라도 의뢰를 완수할지 판단한다.

핵심 감정은 승리보다 생존이다.

하루 시작
→ 의뢰 3개 제시
→ 작업반 3명 편성
→ 장비/식량/약품 배분
→ 노드 맵 진입
→ 전투/사건/휴식/채집 진행
→ 계속 진행 또는 안전 철수
→ 보상과 손실 정산
→ 다음 날

이 프로젝트는 아직 프로토타입 전이지만, 기획 문서는 꽤 구체적이다. 첫 구현 목표는 30일 캠페인이 아니라 3일 생존 캠페인이다. 많은 콘텐츠보다 의뢰 선택, 편성, 위기 선택, 철수, 사망, 정산의 감정 루프가 작동하는지 검증하는 것이 먼저다.

제품 아이디어와 설계 기록

AI 영상 편집 assistant

처음에는 넓은 AI 영상 편집기를 생각했지만, 너무 범위가 컸다. 그래서 vlog rough cut assistant 쪽으로 좁혔다.

핵심 구조는 다음과 같다.

analysis
→ timeline IR
→ LLM planner
→ edit executor
→ preview
→ QA/check
→ export

기술 후보는 FFmpeg/ffprobe, PySceneDetect, transcription, Remotion, OpenTimelineIO 같은 쪽으로 정리했다. 이 아이디어는 아직 제품 구현보다 설계 기록에 가깝다. 블로그에서는 “큰 AI 제품 아이디어를 어떻게 실행 가능한 workflow로 줄였는가”를 보여주는 글감이다.

디지털 로직 breadboard simulator

디지털공학 및 실습 과목용으로 생각한 시뮬레이터다. 일반 전자회로가 아니라 조합논리 중심의 디지털 로직으로 범위를 좁혔다.

MVP 범위:

이 프로젝트는 아직 구현보다 제품 정의 단계다. 하지만 좋은 점은 범위가 명확하다는 것이다. 모든 전자회로를 하려는 것이 아니라, 수업에서 바로 쓰는 디지털 논리 실습 도구로 좁혔다.

여행 자동 기록 앱

소비자 앱 아이디어를 넓게 잡으면 대부분 약하다. 여행 앱도 계획, 추천, SNS로 가면 이미 너무 많다. 그래서 “여행 후 자동 복원”으로 좁혔다.

아이디어의 핵심은 여행 중 직접 기록하지 않아도 사진과 위치를 바탕으로 나중에 지도 앨범을 복원하는 것이다. 이것도 아직 구현보다 제품 방향에 가깝다.

이 글감은 개발보다 제품 판단을 보여주는 쪽이다. broad category에서 unresolved workflow를 찾는 방식.

크라우드펀딩 후보 정리

기존 프로젝트를 텀블벅/와디즈에 올릴 수 있을지 검토한 적이 있다. 이때 배운 것은 기술적으로 좋은 프로젝트와 사람들이 돈을 낼 프로젝트가 다르다는 점이다.

BreadLab이나 Logicboard 같은 도구형 프로젝트는 수요가 좁아 보였고, 하루냥이나 Oracle Tarot처럼 캐릭터/IP, 굿즈, 실물 보상으로 바꿀 수 있는 것이 더 맞았다.

블로그에 쓴다면 “기술 프로젝트를 수요 기준으로 다시 보는 법” 정도가 된다.

작업 방식 자체도 글감이다

AI agent를 쓰는 방식도 계속 정리하고 있다. 중요한 것은 “AI가 해줬다”가 아니라 다음 질문에 답할 수 있어야 한다는 점이다.

Codex/Claude Code는 repo 구현에 맞고, OpenClaw/Hermes는 GUI, 브라우저, 로컬 머신 제어에 더 맞는 식으로 역할을 나눠 생각했다. 긴 세션이 모바일에서 열리지 않을 때는 거대한 기록을 살리기보다 짧은 replacement handoff를 만드는 편이 나았다.

블로그 운영 순서

지금 기준 우선순위는 이렇게 둔다.

  1. Dessert Rush 글을 공개 퀄리티로 만든다.
  2. Cat Rescue 글에 실제 레벨 JSON과 에디터 화면을 붙인다.
  3. Oracle 글에는 readiness 응답 예시와 preview commit 차이를 정리한다.
  4. 굴밑마을 생존조합은 프로토타입 전 기획 글로 남긴다.
  5. AI 영상 편집 assistant와 디지털 로직 시뮬레이터는 제품 설계 글로 남긴다.

목표는 “많이 했다”가 아니다. 각 글에서 하나의 판단을 보여주는 것이다. 취업용으로도 그게 더 읽힌다.