Max
Max · Software Engineer

반복 업무를 실제 제품과
운영 흐름으로 바꿉니다.

데스크톱 도구와 웹 서비스, iOS 앱을 만들고 반복되는 작업을 자동화합니다. 각 프로젝트에서 어떤 제약을 풀었고, 어디까지 구현하고 확인했는지를 기록합니다.

데스크톱 엔지니어링자동화 & 서비스 연동웹 포털 & 콘텐츠 운영온디바이스 iOS 앱
작업 보기GitHub

GitHub 작업 확인 ·

주요 작업 목차 (4)클릭 시 바로 이동
Case Studies

직접 만들고 이어가는 작업

프로젝트의 시작점부터 주요 판단, 구현한 결과와 남은 한계까지 정리했습니다.

사례 01 · 2025.10 – 현재

KBPM: KREAM 네이티브 거래 작업공간

v2 개발 중 · 최종 거래 실행 비활성

거래 정보를 읽고 비교하는 화면부터, 실행을 멈추는 조건까지 설계

KREAM 보관판매 자동화에서 시작해 거래·보유·발매 정보를 모아 보는 무료 네이티브 데스크톱 작업공간으로 발전시키고 있습니다. SwiftUI와 WinUI 3 화면에 Python sidecar를 연결하고, 상품 검색·계정 내역·관심 상품·수수료 미리보기를 구현했습니다.

담당 · 제품 설계, macOS·Windows 네이티브 UI 및 Python 엔진 개발

01. 마주친 제약

  • 로그인 성공과 실제 계정 데이터 조회·화면 표시의 성공을 각각 확인해야 하는 외부 서비스 연동
  • 입찰·보관판매 등 실제 거래는 비용과 상태 변경을 수반하므로 불확실한 결과를 자동 재시도할 수 없음

02. 주요 판단

  • macOS SwiftUI와 Windows WinUI 3 셸이 Python sidecar를 자식 프로세스로 소유하고 IPC로 조회 결과와 상태를 전달하도록 구성
  • KREAM API 조회와 브라우저 세션을 연결하되, 상품·옵션·계정 근거가 부족하면 거래 단계로 진행하지 않도록 설계

03. 구현한 결과

  • 상품 검색, 계정 내역, 관심 상품과 보관판매·입찰 비용 미리보기 화면 구현
  • SwiftUI·WinUI 3 네이티브 셸과 Python sidecar 연결

남은 한계 · 최종 거래 제출은 비활성 상태이며, 일부 macOS 확인 결과를 Windows·전체 KREAM 거래·공개 배포 검증으로 확대하지 않습니다.

PythonSwift / SwiftUI & WinUI 3KREAM API & Browser SessionLocal Validation
상세 사례 연구 보기
사례 02 · 2026.01 – 2026.08

YouTube & Tistory MCP 자동 배포 파이프라인

기존 콘텐츠 자동화 사례

복사와 업로드를 반복하던 작업을 실제 배포 흐름으로 연결

플레이리스트 정리와 기술 블로그 발행에서 반복되던 수동 복사·붙여넣기 업무를 Model Context Protocol(MCP) 기반의 승인형 배포 파이프라인으로 전환했습니다. 단순한 AI 텍스트 생성이 아니라 사람의 Plan 검토를 거쳐 실제 API로 배포되는 안전한 자동화를 구축했습니다.

담당 · TypeScript 기반 YouTube MCP stdio 서버 개발

01. 마주친 제약

  • YouTube Data API 호출별 할당량과 외부 인증 제약
  • 재생목록 일괄 변경 시 누락·중복 발생 시 복구가 어려운 문제

02. 주요 판단

  • YouTube MCP: TypeScript와 @modelcontextprotocol/sdk를 사용하여 Data API v3 및 Live Streaming API를 다루는 stdio 서버 구현
  • Plan / Apply 워크플로: 재생목록 변경 시 즉시 수정하지 않고 snapshot -> plan -> 사용자 승인 -> apply -> journal 기록 순으로 안전 실행하며, 문제 시 inverse plan으로 롤백 지원

03. 구현한 결과

  • YouTube 동영상·재생목록 작업을 연결한 로컬 TypeScript stdio MCP 서버
  • 재생목록 스냅샷, diff 계산, Quota 추정, 일괄 편집 및 역계획 롤백 엔진

남은 한계 · YouTube Music 전용 라이브러리나 Google 비공개 API(시청 기록 등)는 공식 Data API 범위 밖으로 지원 불가

TypeScript & Node.js 20+@modelcontextprotocol/sdkGoogle YouTube Data API v3OAuth 2.0 PKCE & Loopback
상세 사례 연구 보기
사례 03 · 2026.06 – 현재

에버리프: 공식 웹사이트와 EverWiki CMS

공식 사이트 공개 · EverWiki CMS 확장

게임을 소개하는 랜딩에서 운영자가 직접 고치는 도감까지

MapleStory Worlds 게임 에버리프의 소개·게임플레이 미디어·도감을 담은 공식 웹사이트를 만들었습니다. 최근에는 흩어진 게임 정보를 EverWiki로 정리하고, 운영자가 초안을 편집하고 발행할 수 있는 Supabase 기반 CMS로 확장했습니다.

담당 · Next.js 공식 웹사이트와 EverWiki CMS 설계·개발

01. 마주친 제약

  • 편집 중인 초안과 현재 공개된 문서를 분리하고 동시 편집으로 인한 덮어쓰기를 방지해야 함
  • 외부 문서·이미지를 가져올 때 출처와 첨부 파일을 확인하고 발행 전에 검토해야 함

02. 주요 판단

  • Next.js 16과 Supabase로 EverWiki·공지·게임 데이터를 관리하는 통합 CMS 구성
  • GitHub 계정에 역할별 편집 권한을 부여하고 초안·발행 개정본을 분리해 발행 시점에 공개 데이터를 갱신

03. 구현한 결과

  • 공개 EverWiki와 게임 소개·뉴스를 연결한 공식 웹사이트
  • 역할별 권한, 초안·발행본 분리, 개정 이력과 발행 충돌 방지를 포함한 CMS

남은 한계 · CMS 병합과 공개 페이지 응답은 확인했으며, 실제 관리자 계정의 전체 편집·발행 흐름 검증과 외부 문서 이관 완료 여부는 별도입니다.

Next.js 16 & React 19Supabase / PostgreSQLGitHub OAuthTailwind CSS & Vercel Analytics
상세 사례 연구 보기
사례 04 · 2026.07 – 현재

찍술: 기기 안에서 분석하고 직접 확인하는 음주 기록

iOS MVP · 다중 사진 인식 실험 중

사진에서 읽은 제품 정보와 실제로 마신 양을 구분하는 기록 경험

술병·술캔의 라벨과 바코드를 기기 안에서 분석하고, 사용자가 제품과 실제 마신 양을 확인한 뒤 캘린더에 저장하는 iPhone 앱입니다. 기록 경험 개선을 기본 브랜치에 반영했고, 여러 사진의 관찰 결과를 모으는 인식 기능은 별도 PR에서 검증하고 있습니다.

담당 · SwiftUI·SwiftData 기반 iOS 앱 설계와 개발

01. 마주친 제약

  • 사진 속 제품·용기 수를 사용자의 실제 음용량으로 간주할 수 없음
  • 제품 카탈로그와 OCR 근거가 부족할 때 확정 대신 후보·미확인 상태를 유지해야 함

02. 주요 판단

  • Vision OCR·바코드와 출처를 확인한 로컬 카탈로그로 제품 후보를 만들고 실제 음용량은 사용자가 입력하도록 구성
  • 촬영·사진 선택·직접 입력 모두 확인 화면을 거쳐 명시적으로 저장할 때만 기록 생성

03. 구현한 결과

  • Today·캘린더·제품 확인·직접 입력·내보내기를 연결한 iOS MVP
  • 기본 브랜치에 기록 경험, Xcode Canvas 프리뷰, App Intents와 워드마크 개선 병합

남은 한계 · 다중 사진 인식은 미병합 PR이며, 내부 TestFlight 업로드를 테스터의 설치·실행 성공이나 App Store 출시로 간주하지 않습니다.

Swift 6 & SwiftUIApple VisionSwiftData & ObservationAppIntents & PhotosUI
상세 사례 연구 보기
Recent Work

최근 GitHub 작업

저장소에서 확인한 최근 변경을 프로젝트별로 모았습니다.

KBPM

v2 거래 제어와 네이티브 조회 화면을 통합했습니다. macOS의 목록·페이지 이동·창 수명주기 검증 기록을 남기고, 최종 거래 실행은 비활성 상태로 유지했습니다.

작업 자세히 보기KBPM

EverLeaf

EverWiki와 통합 CMS 변경을 병합했습니다. GitHub 역할별 권한, 초안·발행본 분리, 발행 충돌 방지와 검토형 가져오기 흐름을 추가했습니다.

작업 자세히 보기EverLeaf

ZzikSool

Today·캘린더·확인 화면과 워드마크 개선을 병합했습니다. 다중 사진 인식 PR은 열려 있으며, 내부 TestFlight 업로드 기록과 실기기 설치·실행 검증을 구분했습니다.

작업 자세히 보기ZzikSool
Work Method

제가 반복해서 사용하는 작업 순서

문제를 관찰하고 작은 흐름을 구현한 뒤, 실행 환경에서 확인하고 다음 작업으로 연결합니다.

01

사람이 반복하는 작업을 관찰한다

자동화나 제품을 만들기 전, 사람이 수동으로 어떤 단계를 거치며 어디서 병목과 피로가 발생하는지 파악합니다.

MCP Publishing
02

실제 실패 조건과 예외를 먼저 수집한다

CSR 지연, 로그인 세션 만료, 난반사, 결로 현상 등 실제 사용자 환경에서 발생하는 실패 요인을 사전에 리스트업합니다.

KBPM
03

가장 작은 동작 가능한 흐름을 만든다

모든 기능을 한 번에 만들기보다, 핵심 입력과 출력이 끝까지 연결되는 MVP를 최우선으로 검증합니다.

iOS Prototyping (찍술)
04

다른 환경에서 실행해 본다

시뮬레이터와 실제 기기, macOS와 Windows의 확인 결과를 나누어 기록하고 미검증 범위를 남깁니다.

KBPM
05

배포와 업데이트 방법을 함께 만든다

코드를 작성하는 것으로 끝내지 않고 GitHub Actions 릴리스, TestFlight, GitHub Pages 등 실제 전달 경로를 구축합니다.

찍술 & 포트폴리오
06

사용자가 이해할 설명과 홍보물까지 준비한다

소프트웨어만 완성해 두지 않고, 스토리보드 기반 영상, 타이틀 그래픽, 공식 웹페이지로 제품의 가치를 온전히 전달합니다.

EverLeaf
07

실패 기록을 다음 구조 개편에 반영한다

임시 땜질식 코드에 기대지 않고, 런타임 실패와 운영 한계를 다음 버전의 네이티브 아키텍처 재설계에 반영합니다.

KBPM v2
Technical Rationale

기술은 결과 옆에서 설명합니다

어떤 문제를 풀기 위해 기술을 선택했고 무엇을 배웠는지를 기록합니다.

기술선택 이유 및 적용 위치실제 겪은 제약 및 배운 점
Python & IPC
KBPM 조회·거래 제어 엔진과 네이티브 셸 연결프로세스 수명주기와 불완전한 응답을 명시적인 상태로 전달
Swift / SwiftUI & WinUI 3
KBPM 데스크톱 셸과 찍술 iPhone 앱공통 기능 구현과 OS·실기기 검증을 구분
Apple Vision & SwiftData
찍술의 기기 내 제품 분석과 개인 기록 저장인식 결과와 실제 음용량 확인을 분리
TypeScript & Node.js
MCP 서버와 웹사이트의 데이터·도구 계약외부 서비스 변경과 실패를 처리할 경계 설계
Next.js & Tailwind CSS
포트폴리오의 정적 배포와 에버리프 공식 사이트·CMS포트폴리오는 Next.js 15 정적 export, 에버리프는 Next.js 16 기반 서버 기능 사용
Supabase & GitHub OAuth
EverWiki 콘텐츠·개정 이력과 운영자 권한로그인·편집·발행 권한과 공개 버전을 구분
Next Steps

각 프로젝트에서 다음으로 확인할 것

현재 구현에서 남은 과제를 바탕으로 다음 작업을 정했습니다.

KBPM

실제 Windows와 KREAM 주요 흐름의 검증 범위를 넓히고, 최종 제출 활성화에 필요한 근거를 확보

EverLeaf

검토를 거친 문서 이관과 운영자 편집·발행 흐름의 실제 사용 검증

ZzikSool

실제 iPhone 설치·촬영 흐름과 독립된 촬영 세션에서 제품 식별·중복 처리 검증

소개와 연결

도구를 기존 작업 흐름에 붙여 실제 결과를 만든 경험을 중요하게 봅니다. 개발이 끝난 뒤에도 배포, 운영, 설명과 홍보가 남는다는 전제로 작업합니다.

GitHubLinkedInTistory