Developer 쿠의 개발이야기

[토스 미니앱 - 내일 주가 예측 3] AI와 '다음에 출시할 앱' 발굴하기

Chris.Koo — Sat, 18 Jul 2026 13:07:36 +0900

이전글은 아래에

2026.06.28 - [AI(바이브코딩)/앱인토스] - [토스 미니앱 - 내일 주가 예측 2] '단일 앱' 보다는 앱만드는 '공장'으로 - AI를 '개발자'가 아니라 '운영자'로 세팅하기

1. 자료 조사

2. 하네스 구축 및 스킬 MCP 세팅

3. 아이디어 내기

4. 개발

5. QA

6. 검수 및 콘솔 정보 입력

7. 출시

8. 운영

1편에서 토스 미니앱 하나가 단기간 안에 폭팔적인 사용 유저수를 모은 얘기, 2편에서 그걸 가능하게 한 운영 체계(하네스) 얘기를 했다. 여기서 예상치 못한점은 차후 설명할 나름의 아이디어 점수표에서 1등 했던 앱들은 잠잠하고, 정작 점수 낮아서 곁가지로 만든 앱이 훨씬 더 잘된바 있다. 이번 편은 아이디어에 관한 이야기이다. — "그래서 다음엔 뭘 만들 건데?"

사실 이게 어려운 부분이다. 코드는 클로드 코드가 짜주는데, 뭘 만들지는 결국 내가 정해야한다. 바이브코딩이라고 하면 보통 코드 짜는 것만 떠올리는데, 나는 그 앞단(뭘 만들지 고르기)까지 시스템으로 만들었다. 아이디어를 모으고, 점수 매기고, 거르는 파이프라인 말이다.

근데 결론부터 말하면 그 점수표가 한 번 크게 틀렸었다. 점수 1등이 아니라 점수 낮던 앱이 오히려 잘됐다. 왜 그랬는지, 그래서 선정 기준을 어떻게 갈아엎었는지까지 풀어볼 예정이다.

일단 무식하게 아이디어 50개에 점수표

처음엔 그냥 아이디어를 쏟아냈다. 그리고 감으로 고르지 않으려고 점수표(루브릭)를 만들었다. 항목마다 1~5점 매기고 가중치를 곱해서 합산하는 식이다. 가중치가 핵심인데, 내 상황(복무 중 무료·무수익)에 맞춰 아래처럼 계산했다.

DAU 잠재력 / 습관성	×3	매일 다시 열 이유가 있나
토스 유저 적합성	×2	19+ 한국 매스마켓, 금융·생활 밀착
무수익 리텐션	×2	광고 없이도 끈끈한가
개발 속도	×2	솔로+AI로 1~2주에 출시 가능한가
차별성 / 방어력	×1.5	유사앱 정지 리스크 낮고 복제 어려움
검수 난이도	×1	등급분류 등 복잡도 낮음

제일 무겁게 둔 게 "매일 다시 열 이유(DAU 습관성)"이다. 무수익이라 광고로 버틸 수가 없으니, 사람들이 진짜 매일 여는 앱이 아니면 의미가 없다고 생각했다. (위 표는 핵심 항목만 추린 발췌본임. '전역 후 수익화 경로' 같은 항목도 있었는데, 복무 중엔 무수익이라 비중을 거의 안 줬다.)

점수 매기기 전에 '하드 필터'부터

근데 점수를 매기기 전에 먼저 하는 게 있다. 만들어도 망하는 걸 쳐내는 하드 필터. 점수가 아무리 높아도 여기 걸리면 그냥 탈락이다.

크게 아래 두 종류가 있다.

① 토스에 이미 있는 것. 토스 안에 만보기·가계부·환율·신용점수·고양이 키우기·행운퀴즈·오늘의 운세, 매일 예측하는 '두근두근 1등찍기' 같은 게 기본으로 들어있다. 여기랑 정면으로 겹치면 사람들이 굳이 제 미니앱을 안 쓸것이다. (한때 점수 상위 후보였던 '운세' 앱은, 토스가 '오늘의 운세'를 기본 탑재한 걸 보고 강등시켰다.)

② 토스가 출시를 안 시켜주는 것. 토스 서비스 정책상 가상자산·증권/금융상품·투자자문(종목·전략)·사행성·의료중개 카테고리는 출시가 막힌다. 이건 만들어봤자 검토에서 반려되거나, 무리하게 냈다가 기존 출시 앱까지 운영 제한될 수 있어서 제일 먼저 거른다.

위 필터를 먼저 통과한 것만 점수를 매기기로 했다.

그런데 점수 1등이 아니라, 점수 낮던 게 터졌다

자, 여기가 반전이다.

내 점수표에서 상위권인 무지출 챌린지, 금연 카운터, 감사일기 같은 깔끔한 습관 앱들부터 만들었다.

그런데 정작 현재 기준 5000명을 넘긴 건 내일 주가 예측이었어요. 이건 솔직히 점수표 기준으론 비권장에 가까웠다. 증권 정보라 정책 리스크도 있고, 곁가지로 지정해서 만든 앱이었기 때문이다.

그래서 고민해보았다. "왜 이건 사람들이 매일 열까?"

다음은 고민과 리서치 끝에 내가 내린 결론이다.. 열 이유를 앱이 아니라 '세상'이 매일 공짜로 공급하기 때문이다. 평일마다 장이 열리고, 밤사이 미국장이 움직인다. 그러니 사용자는 "오늘은 뭐 떴나" 보러 매일 와야 할 것이다. 앱이 알림을 안 보내도, 세상이 콘텐츠를 갱신해준다.

솔직히, 내가 점수 믿고 먼저 만든 감사일기,기분 기록 등은 사람들이 잘 안 돌아왔다. 유저 본인들이 안 적으면 화면이 그대로이기 때문이다. 반대로 주가 앱은 제가 아무것도 안 해도 밤마다 새 내용이 떠 있었다는게 결정적 차이였다.

그래서 점수표를 갈아엎었다. - '리텐션 렌즈'

여기서 하나 더 배운게 있다. 처음엔 '많이 들어왔다 = 성공'인 줄 알았는데, 데이터를 보니 유저를 데려오는 것(획득)이랑, 데려온 유저가 남는 것(리텐션)은 완전 다른 문제인것을 깨달았다. 획득은 솔직히 돈이나 푸시로 어느 정도 만들 수 있는데 "내일 또 열까?"는 못 산다. 그건 순전히 앱이 매일 열 이유를 주느냐에 달렸고, 그게 점수표가 못 잡던 진짜 변수였다.

그래서 루브릭을 리텐션 중심으로 다시 짰다

R1 외생적 일일 트리거	30	세상이 매일 열 이유를 주나(장·날씨·월급일). 자기보고=0
R2 외생 신선도	20	내 입력 0인데 열 때마다 새 정보가 뜨나
R3 고관여 stake	20	돈 > 건강 > 시간 > 호기심 순으로 무겁게
R4 누적 개인자산 락인	15	스트릭·기록·컬렉션이 쌓여서 못 떠나게
R5 공유	10	매일 재생산되는 정직한 공유

한 줄로 요약하면, 유저가 아니라 세상이 매일 열 이유를 주는 앱에 점수를 몰아주었다.

그래도 새 아이디어는 어떻게 '발굴'하나

물론 풀이 마르면 새 후보도 계속 캐야한다. 이때 2편에서 말한 서브에이전트를 쓴다. 에이전트 여러 마리를 동시에 띄워서 축을 나눠 리서치시키는 것이다. 한 마리는 해외 슈퍼앱, 한 마리는 한국 MZ 트렌드, 또 한 마리는 공공데이터 유틸, 또 한 마리는 토스 중복·정책 체크. 웹서치만 백 번 넘게 돌아간다.

여기서 해외 레퍼런스를 많이 본다. 검증된 메커닉을 한국 공백에 이식하는 게 안전하다고 판단했다. 예를 들면 이래요.

일본 두통 예보 앱(頭痛ーる, 2,000만 다운로드) → '기압 미리보기'
일본 최애 덕질 기록 앱(Oshibana) → '덕질 로그'
집중 타이머 Forest → '집중 펭귄'

그리고 이 발굴·채점도 손으로 안 하고, 에이전트들이 매긴 점수를 종합해서 시트(ideas/평가.xlsx)에 가중점수로 자동 정렬되게 해놨다.

지금의 결론 — 신규보다 '검증된 앱에 얹기'

그래서 요즘 우선순위가 좀 바뀌었다. 새 앱을 하나 더 만드는 것보다, 이미 사람들이 오는 게 검증된 앱에 R4(개인 누적 자산)를 얹는 게 훨씬 ROI가 높다는 거예요. 0에서 시작하는 신규 앱보다, 이미 매일 열리는 앱에 "남을 이유"를 더하는 게 빠르고 안전하다고 생각했다.

이게 점수표 → 데이터 → 리텐션 렌즈로 이어진, 제 아이디어 선정의 현재 버전이다. 아마 또 틀릴 거고, 또 고칠 예정이다. 근데 그게 핵심이거 선순환이라고 생각한다. 선정 기준 자체를 출시 데이터로 계속 고쳐 쓰는 것.

마무리

정리하면, '다음 앱 고르기'도 감이 아니라 시스템이다.

1. 만들면 망하는 걸 하드 필터로 먼저 쳐내고

2. 가중 점수표로 후보를 줄이고

3. 근데 그 점수표를 출시 데이터로 계속 교정한다.

[토스 미니앱 - 내일 주가 예측 2] '단일 앱' 보다는 앱만드는 '공장'으로 - AI를 '개발자'가 아니라 '운영자'로 세팅하기

Chris.Koo — Sun, 28 Jun 2026 14:33:09 +0900

이전글은 아래에

2026.06.23 - [AI(바이브코딩)/앱인토스] - [토스 미니앱 - 내일 주가 예측 1] AI로 출시 이주만에 유저 1,000+명 돌파한 앱 만들기

1. 자료 조사

2. 하네스 구축 및 스킬 MCP 세팅

3. 아이디어 내기

4. 개발

5. QA

6. 검수 및 콘솔 정보 입력

7. 출시

8. 운영

하네스 구축

하네스(harness)란? AI 에이전트는 강력하지만 방치하면 예측 불가능한 방향으로 작동하기도 합니다. 하네스는 그 힘을 억누르는 것이 아니라, 올바른 방향으로 제어하면서 최대한 활용하기 위한 구조를 일컫는 표현입니다. 즉, 하네스란 AI 에이전트가 안전하고 예측 가능한 방식으로 작동하도록 설계된 제어 구조 전체를 말합니다. (https://channel.io/ko/blog/articles/what-is-harness-2611ddf1)

내 로컬에는 현재 토스 미니앱이 이미 16개 개발되어 있다. 이중 7개가 출시되었고, 9개가 출시 대기 중이다. 1달 남짓한 시간만에 이렇게 까지 만들 수 있었던 이유는 처음부터 '단일 앱'이 아니라 '앱 공장'을 노렸기 때문이다. 클로드를 활용할 때 '내일 주가 예측' 앱 또한 단순하게 "이 앱을 만들어줘"라고 시킨 게 아니라, 앱을 기획하고 -> 개발하고 -> 출시 준비 -> 콘솔 정보 입력 -> QA 및 테스팅 -> 데이터 취합 -> 다음 앱을 정하는 그 전체 사이클을 혼자 굴리는 '운영자'로 페르소나를 구축하였고, 나를 가만히 앉아서 아이디어 보강이나 출시 전략과 방향성 설정 정도만 하는 '사장님'으로 만들었다.

이번 글에서는 나만의 토스 앱 공장의 비밀 '하네스(harness)'에 대해 공개하고자 한다.

바이브 코딩은 앱 하나 뚝딱이 아니다

요즘 바이브 코딩 글들 보면 대부분 비슷하다. "AI한테 시켰더니 앱이 뚝딱 나왔다". 근데 막상 해보면 알 것이다. 코드는 잘 짜지만 뭔가 부족하다는 것을...

앱 하나 출시하려면 뭐가 필요하냐면

아이디어 수십 개 중에 뭘 만들지 고르고
그게 토스 정책에 안 걸리는지 확인하고
스캐폴딩 하고, MVP 짜고
검수 체크리스트(비게임 필수 항목) 다 맞추고
콘솔 등록 정보(상세설명·스크린숏·키워드) 쓰고
테스트 빌드 올리고, 실기기에서 확인하고
출시하고, 데이터 보고, 다음을 정하고…

이걸 앱마다 반복해야 한다. 개발은 이 중에 하나일 뿐이다. 그래서 난 아예 생각을 바꿔서 AI한테 코딩만 시킬게 아니라, 이 전체 운영을 맡기기로 하였다. 아래는 내가 만든 앱 공장의 컨트롤 타워(대시보드)다.

컨트롤 타워 메인화면

각 앱별 세부 화면 - 콘솔 등록물 (토스 콘솔에 복붙할 내용들)

A to Z까지 AI가 모두 담당하도록 되어있다. 알아서 앱의 스크린샷도 찍고, 오른쪽 위 검은색 '데모' 버튼을 누르면 해당 앱의 데모도 웹으로 직접 렌더링 해서 보여준다. 스마트 발송은 토스가 내 앱을 홍보해 주기 위해 푸시메시지를 전송해 주는 기능인데, A/B 테스팅을 위한 여러 푸시메시지용 후보군 텍스트들을 설정해야 해서 해당 텍스트들 마저도 자동화 해서 복붙 할 수 있도록 되어있다. 와 앱로고와 배너 같은 경우는 이미지 만들어 내는 프롬프트를 AI가 주면 이를 내가 직접 Google Flow내 Nano Banana를 통해 이미지를 생성해서 업로드하는 방식이다. 아무래도 내가 직접 플로우를 통해 이미지를 만들어야 되기 때문에 이곳이 살짝 병목인 지점이다. 차후 Playwright MCP 같은 걸로 브라우저를 조작하게 만들어서 병목을 없앨 예정이다. 100% 자동화 공정을 위하여.

아래는 아이디어를 모아둔 탭이다. 곧 앱으로 만들어질 친구들로서 특정 기준에 의해 점수화되어 있다. 아이디어도 당연히 AI발이다. 차후에 좀 더 자세하게 기술할 예정이다.

이와 같은 구조로 되려면 AI를 '코딩 도구'가 아니라 '운영자'로 봐야 한다. 그리고 운영자한테는 코드 한 줄이 아니라 회사 규정집과 업무 매뉴얼을 줘야 할 것이다. 이게 바로 하네스의 시작이다.

하네스의 3중 레이어 구성

프로젝트 구성은 대강 이러한 형식이다.

PLAYBOOK.md ← 불변 원칙 (절대 안 바뀜)
CLAUDE.md ← 컨트롤타워 (운영 지침)
apps/<app>/CLAUDE.md ← 앱별 얇은 지침

클로드 코드는 세션마다 이 문서를 읽는다(정확히는 CLAUDE.md를 클로드 코드 매번 읽도록 되어있으며, 이는 내가 시킨 게 아니라 원래 그렇다. 그리고 그 문서에 각 프로젝트별로 위 문서의 내용을 읽어 엄격히 지키라고 되어있는 것이다.)

1층 — PLAYBOOK.md (헌법). 상황이 바뀌어도 절대 안 변하는 원칙만 둔다. 예를 들면 이런 것들이 있다.

복무 중에는 어떤 앱도 광고·인앱결제·유료 기능을 켜지 않는다.
사업자 등록 및 토스 로그인 기능은 사용하지 않는다.
군 규정 확인 완료: 무수익 미니앱은 출시운영 가능, 수익화만 금지.

(군 복무 중이라 "무수익"이 대전제다. 그래서 이게 1층 헌법에 박혀 있다.)

이외에도 "복무 중에는 무료·무수익 미니앱을 빠르게 다수 출시해 DAU(사용자)부터 확보하고, 전역 후 사업자 등록을 통해 수익화로 전환한다". 같은 나만의 이 프로젝트의 존재 의의 라던지, 각종 기술 컨벤션 및 토스 플랫폼 규칙들이 명시되어 있다.

2층 — CLAUDE.md (운영 지침). 컨트롤타워로서 매일 어떻게 일할지. 파이프라인, 자율 경계, 런북 같은 게 여기 있다. 중요한 건 매 세션별로 성장하고 더 나은 프로덕트가 될 수 있도록 기록하는 곳이기도 하다.

### 3번째 후보 — 밤사이 주가 (`apps/premarket-kr`) — ⛔ 토스 출시 불가(정책)
(중략...)
- ✅ **Naver를 .ait에서 동작하게(#12)** — `fetchKorea`를 절대 URL로(미니앱은 같은 출처 `/naver` 못 씀). `deploy.sh`에 **CORS(`ACAO:*`) + 업스트림 Origin/Sec-Fetch 제거**(네이버가 Origin 보면 403) 추가 → Origin 붙은 교차출처 호출도 200 검증. **출시된 .ait이 우리 Caddy 프록시=한국시세 백엔드**에 의존(박스 다운 시 perp로 degrade). Vercel 이전은 나중(운영자).- ✅ **콘솔 등록물 초안(#11)** — `store-assets/README.md`: 앱명 국/영·부제·상세설명(접속→행동→결과)·카테고리(증권/투자정보)·키워드·앱내기능 1개(`intoss://premarket-kr/`)·출시로그·면책·데이터출처·실기기 QA(3소스 외부 fetch·스냅샷)·게이트.
(중략...)
- **운영 교훈(아이디어 선정에 반영):** 토스 서비스 오픈 정책상 **가상자산·증권/금융상품·투자자문(종목·전략)·사행성·의료중개 카테고리는 출시 불가.** 50개 아이디어 재평가 시 이 필터를 먼저 적용한다.

이런 식으로 클로드가 직접 본인의 시행착오와 개발 일지(?)를 작성하게 만들어서 다른 세션마다 같은 실수를 반복하지 않도록 한다.

3층 — apps//CLAUDE.md (앱별). 각 앱의 한 줄 정의, 핵심 루프, MVP 범위등과 함께 좀 더 specific 한 개발 컨벤션이나 특이사항, 기술 스택 및 구조, 각종 명령어나 배포 설명서, 이 앱에 대한 작업 수칙등이 적혀있다.

그리고 제일 중요한 규칙 하나. 충돌하면 위층이 이긴다. PLAYBOOK이랑 앱별 지침이 부딪히면 PLAYBOOK이 우선이다. 이걸 명시해 두면 AI가 헷갈릴 때 스스로 우선순위를 판단하도록 만들 수 있다.

이걸 왜 이렇게까지 나누냐면 LLM은 대화 맥락이 길어지면 앞에 한 말을 까먹거나, 앞뒤가 안 맞는 말을 한다. 근데 "헌법 / 운영지침 / 앱별"로 층을 갈라두면, 세부 지침이 아무리 늘어나도 절대 원칙은 안 흔들리고 내 입맛(?)대로 원하는 결과물을 얻을 확률이 올라간다.

스킬 및 MCP 설정

규정집(문서)만 줬다고 AI가 알아서 잘 굴러가진 않는다. 그렇다고 엄청 중요한 부분은 아니지만 스킬과 mcp도 적절히 활용할 줄 알아야 한다.

스킬은 superpowers와 antropic 공식 frontend-design skill 정도만 세팅해도 괜찮은 것 같다. 특히 superpowers의 브레인스토밍 기능을 통해 사전에 충분히 계획하고 태스크를 잘게 쪼개 작업가능하여 AI가 Planning이 끝나고 개발에 착수할 때에도 원활한 작업을 도와준다.

MCP는 앱인토스 공식 MCP가 따로 개발되어있다 토스 미니앱 개발 문서랑 TDS(토스 디자인 시스템) 문서를 AI가 그 자리에서 최신본으로 찾아본다. PLAYBOOK에도 "공식 MCP를 켠다 → 문서 최신본을 라이브로 참조하므로 매번 문서를 학습시킬 필요 없음." 이런 식으로 적혀 있다. 토스가 문서를 바꿔도 AI가 옛날 지식으로 헛다리 짚지 않게 만들 수 있다. 출시 직전엔 docs-search로 공식 검수 체크리스트 원문을 한 번 더 대조하기도 한다.

토스 미니앱은 순수 react는 아니고 ait / Granite 같은 프레임워크를 사용 중이어서 일반 리엑트 개발과는 다소 다른 방식으로 개발해야 한다. 또한, 디자인도 TDS(Toss Design System)를 준수하도록 하였다. 이런 것들도 문서에서 실시간으로 읽어오도록 하였다.

추가적으로 자체 검수할 때도 문서를 참고한다. 토스는 비게임 미니앱에 검수 체크리스트가 있다. 이걸 공식 문서에서 뽑아 docs/검수체크리스트. md로 정리해 두고, 코드로 막을 수 있는 항목은 scaffold 직후부터 기본값으로 박는다. 핀치줌 끄기, 라이트모드 고정, SSR 금지(CSR만), eval 및 외부 코드 실행 금지, 평문 ws:// 금지, 화이트아웃 방어용 최상위 ErrorBoundary 등. 출시 전엔 금지 패턴(asyncstorage, eval 등을 아예 grep으로 스캔까지 한다.

뿐만 아니라, Opus의 ultracode 모드(/effort ultracode 명령어로 킬 수 있음)도 큰 도움이 됐다. 컨트롤타워(메인 AI)가 일을 혼자 다 하는 게 아니라 여러 서브에이전트한테 역할을 쪼개서 시킬 수 있다. 이를 통해 각 에이전트를 빌더, 검수자, 리서처, 적대적 평론가(유저)로 나누기도 한다. 이렇게 하면 속도나 비용보다 '제일 정확한 결과'를 뽑을 수 있다. 흩어서 찾고, 적대적으로 검증하고, 종합한다. 이를 통해 사람 팀이 코드 리뷰하는 걸 AI 여러대로 돌리는 셈이다.

업무 파이프라인 for AI

운영자한테는 반복 업무 매뉴얼이 있어야 한다. 내 CLAUDE.md에는 이런 파이프라인이 박혀 있다. 그냥 뚝딱 나온 순서가 아니라 한 줄 한 줄에 여러 번 데인 흔적이 박혀 있다.

다음 앱 선정 — 아이디어 시트에서 점수 최상위 1개 + 선정 이유 1줄
앱 지침 작성 — apps//CLAUDE.md
Scaffold — npx create-ait-app
MVP 구현 — 마일스톤 단위 커밋
테스트 — 샌드박스 핵심 루프 + 빌드
출시 — (검토 요청은 내 승인 후)
관측 — 데이터 대시보드로 유입·리텐션 확인
→ 1번으로 반복

한 번 배운 교훈을 문서로 박으면, 그다음 앱부터는 AI가 그 교훈을 공짜로 물려받도록 되어있다.

이렇게 까지 해야 돼?

네 맞아요 허허..

정리하면, AI 앱 개발을 바이브코딩으로 진짜 제대로 하려면 "AI한테 앱 만들어줘"에서 멈추면 안 된다고 생각한다. 규정집(PLAYBOOK) + 업무 매뉴얼(파이프라인) + 권한 경계(자율 경계) + 기억(STATUS), 그리고 일할 연장(스킬·MCP·서브에이전트)을 세팅해 주는 게 본게임이다. 그게 사람으로 비유하면 "앱 만드는 사람"에서 "앱 공장을 운영하는 사람들"로 바꿔준다.

[토스 미니앱 - 내일 주가 예측 1] AI로 출시 이주만에 유저 1,000+명 돌파한 앱 만들기

Chris.Koo — Tue, 23 Jun 2026 20:17:12 +0900

2편 -
2026.06.28 - [AI(바이브코딩)/앱인토스] - [토스 미니앱 - 내일 주가 예측 2] '단일 앱' 보다는 앱만드는 '공장'으로 - AI를 '개발자'가 아니라 '운영자'로 세팅하기

중학교 때 정올이나 알고리즘 대회를 준비할 때부터 대학교, 회사 그리고 군대에 와서도 개발을 하고 있다. 햇수로는 개발을 시작한 지 거의 10년이 넘는 세월 동안 가장 큰 변화는 단연코 AI인 것 같다. Openclaw 같은 에이전트나 Claude Opus 같은 초고성능(?) 모델이 대거 출시됨으로써 올해 2026년부터는 대 바이브 코딩의 시대가 열렸다.

이런 반열에 못 끼어들면 바보라는 일종의 FOMO가 들었다. 이런 기회를 놓치기 싫어서 다소 부족한 부분이 많지만 우여곡절 완성한 첫 바이브 코딩 프로젝트를 야심차게 선보이고자 한다.

먼저 아래 사진은 내가 출시한 앱이 일주일만에 311명의 유저수를 달성한 오늘자(6/23) 모습이다. 마지막 그래프가 꺾인 이유는 아직 집계 중이라 그렇다.

(추가 - 6/28 기점 유저 1,000명을 넘겼다!)

(추가 - 7/18 기점 유저 5,400명을 넘겼다!)

(추가 2 - 6/28 도구 순위 15위에 올랐다!)

그래서 어떤앱?

출시한 앱은 "내일 주가 예측"이다. 요즘 코스피가 HOT 한데, 오늘 장이 종료된 후에도 내일 장은 오를지 내릴지, 오른다면 얼마나 오를지가 궁금해서 만들게 되었다.
그럼 어떻게 예측을 하냐, 먼저 하이퍼리퀴드(https://app.hyperliquid.xyz/trade)에서 코스피의 가격을 받아온다. 코스피 같은 주식을 토큰화하여 블록체인 기반 거래소에 상장시킴으로써(요즘 트렌드, 이외에도 애플, 마소 등 주식도 상장되어 있어 거래 가능하다).
24h 거래되기 때문에 이 가격을 받아와서 종가랑 비교해 주면 끝이다. 실제로 80% 정도로 예측된 가격과 그다음 날의 종가가 일치한다는 게 백테스트 결과 증명되기도 하였다. 투자에 활용해도 좋을 것 같다. 더 이상의 설명보다는 이제 그만 아래 UI를 보도록 하자.

토스 미니앱 - 내일 주가 예측 앱 메인 화면 (6/27 업데이트)

크게 두 섹션으로 나누어져 있는데, 첫 번째 맨 위 섹션은 코스피 200의 비교화면이고, 그 아래는 대형주의 가격 비교화면이다. 실시간으로 환율과 위에서 설명한 하이퍼리퀴드 내 각 티커의 가격을 비교해서 서버에서 뿌려준다. 물론 서버 클라 모두 바이브 코딩으로 일절의 코드도 입력하지 않았음을 밝힌다.

어떻게 만들었는지 설명하기에 앞서 직접 앱을 써보고 싶으신 분들은 아래 링크를 접속해서 쓰시면 됩니다 ㅎㅎ
https://minion.toss.im/L5v9Unt2

토스 내일 주가 예측

앱 설치 없이 쓰는 토스 미니앱

og.toss.im

백지상태부터 출시까지의 단계는 다음과 같다.
1. 자료 조사
2. 하네스 구축 및 스킬 MCP 세팅
3. 아이디어 내기
4. 개발
5. QA
6. 검수 및 콘솔 정보 입력
7. 출시
8. 운영

당연하겠지만 1번부터 8번까지 모두 AI로 구축한다. 나 같은 경우는 자료조사마저도 먼저 클로드 웹에서 시킨 후 "클로드코드에게 인수인계 하도록 만들어줘" 하면 마크다운으로 아주 잘 정리해서 준다. 이때 몇 가지가 중요한데, 바로 자료조사 시 AI관련 툴이나 Skill 등이 있다면 해당 스킬을 미리 설치하도록 안내해야 한다. 이 또한 물론 인수인계서에 녹이게 시킨다.

앱인토스 with AI

토스는 아래와 같이 바이브코딩에 대해 매우 친절하게 안내하고 있으며, 각종 콘솔 mcp라던지 독스 검색을 통해 ai가 헛짓거리(?) 안 할 수 있도록 도와주는 스킬들을 미리 개발해 두었다.
https://developers-apps-in-toss.toss.im/tutorials/ai-vibe-coding.html#_3-3-ai-도구에-mcp-연결하기

앱인토스 개발자센터

Are you an LLM? You can read better optimized documentation at /tutorials/ai-vibe-coding.md for this page in Markdown format 미니앱 만들기 Copy as Markdown Download as Markdown 코딩 경험이 없어도 괜찮아요. AI와 함께라면 앱인토스

developers-apps-in-toss.toss.im

클로드 코드에서 스킬들을 셋업하고 채팅 세션에 인수인계까지 해두었으면 이제 모든 준비가 끝난 것이다. 이젠 가장 중요한 하네스를 구축할 때이다.

다음 글에서...
2편 -
2026.06.28 - [AI(바이브코딩)/앱인토스] - [토스 미니앱 - 내일 주가 예측 2] '단일 앱' 보다는 앱만드는 '공장'으로 - AI를 '개발자'가 아니라 '운영자'로 세팅하기

[토스 미니앱 - 내일 주가 예측 2] '단일 앱' 보다는 앱만드는 '공장'으로 - AI를 '개발자'가 아니라

이전글은 아래에2026.06.23 - [AI(바이브코딩)/앱인토스] - [토스 미니앱 - 내일 주가 예측 1] AI로 출시 이주만에 유저 1,000+명 돌파한 앱 만들기1. 자료 조사2. 하네스 구축 및 스킬 MCP 세팅3. 아이디어

synapsis9.tistory.com

3년만에 Genesis G70에서 BMW M340i로 기변을 하기까지

Chris.Koo — Sun, 2 Mar 2025 16:25:27 +0900

어릴때부터 기계를 좋아했다. 레고도 그냥 레고가 아니라 각종 센서와 엑츄에이터들을 결합하여 직접 상황을 인식하고 코딩하고 움직이기까지하는 그런 레고 말이다.

(LEGO Mindstrom 모델) 찍어둔 사진이 없어서 퍼옴

어른이 되고 나서는 관심이 자연스레 차로 가게되었다. 자차가 없기에 쏘카나 그린카같은 단기 렌트 플랫폼에만 가져다 바친돈은 족히 몇백은 될것 같다. 나에게 자동차는 대부분의 사람들이 생각하는 운송수단이 아닌 일종의 머신(?) 개념이였다. 한 3년쯤 그렇게 지냈을까. 일도 열심히 다니고 좋은 조건으로 이직하며 자차에 눈을 들이게 되었다.

내 생애 첫차 Genesis G70

사실 당시 나이가 23살에 불과했기에 외제차는 무리가 있었지만, 단순히 움직이기만 하는 차로는 만족이 안됐기에 고성능 세단인 G70이나 스팅어로 적당히 타협을 봤고 역시 후회하지는 않았다.

G70. 차 번호는 진짜 잘뽑음

22년도 3월에 출고하고 매번 고급유와 주기적으로 손세차 + 왁스 광택 해주면서 병적으로 관리해줬다. 사진보면 알겠지만 그냥 거울이다. 3년내내 거의 저상태로 유지했다. 여담이지만, 잘해주는 만큼 와인딩이나 고속으로 쏠때는 가혹하게 몰아주기도 했다,,

슬슬 차도 질릴때쯤 기변병이 오고 있었으나 현실과 나름 타협하던중 3번의 크고 작은 사고가 연달아 일어나게 된다. 일주일에 한번꼴로 이슈가 생겼다.
첫번째는 블랙아이스낀 교차로에서 바퀴가 잠겨 그대로 오토바이를 받았다(명동 한복판에서 벌어진 인사사고라 경찰도 개입했는데, 과속이나 신호위반도 아니고 블박상 시속 20이여서 경찰아저씨도 별말씀안하심..바퀴잠기니 할 수 있는게 없더라).
그리고 두번째는 주차 해두었는데 다른차가 차를 뺴다가 운전석 휀더부터 앞 범퍼까지 그대로 밀어버려서 반파가 됐다. 블루핸즈 출고하고 일주일도 안되서 다시 입고했을때 상담사분도 이미 출고된 차가 입고됐다고 혼선이 생긴줄 알고 전화도 왔었다ㅋㅋㅋ
세번째는 2번연속의 수리이후 어질어질 하던찰나에 올림픽대로에서 차가 림프모드에 걸려서 풀악셀 쳐도 50km/h 이상 나가질 않았다. 외장은 그렇다 쳐도 이제 동력계통까지 문제가 생기니 그냥 팔아버렸다. (* 보증수리되었으나 시간도 없고 정도 떨어져서 팔음. 차후에 판매시에도 별도의 감가 없었음)

두번째 차가 될뻔한 F80 M3

자기전엔 항상 자동차 수리하는 유투브 채널이나, 자동차 리뷰를 보고 잔다. 퇴근하고 집에 올라가기전에도 목장갑을 낀채로 괜히 엔진룸을 열고 이것저것 만져본다. 그만큼 차를 좋아하고 이젠 꿈에 그리던 M3로 눈이 가게되었다. 원래 E92 M3 자연흡기 8기통의 맛을 보고 싶었는데, 실내를 보니 너무 구식이더라(내부 따지면서 차 좋아한다고 하면 안되긴 하는데...), 조수석님의 반대로 F바디 M3를 들일려고 엔카로 매물을 찾아보던 도중 "엔카믿고" 라는 서비스가 있더라. 3일동안 타보고 맘에 안들면 환불하는 시스템인데 니즈에 딱 맞았다.

바빠서 중고차 단지 돌아다닐 여유는 없는데, 원하는 곳으로 배송도 해준다카더라. 그리하여 내 사무실로 배송을 받았다.

F80 M3 실내사진 야무진 카본

인수 받은날 찍은 F80 M3 외부사진

진짜 신세계였다. 여태 내가 탔던 차는 그냥 애들 장난 이였다. 400마력 후반대의 힘으로 바닥에 뿌리는 토크와 DCT 미션의 조화는 정말 엑셀링을 할때마다 웃음이 나오게 했다. 엄청난 강성의 하체, 광폭 타이어 크기에서 나오는 쫀쫀한 그립은 차를 맘대로 잡아돌려도 자세를 결코 잃는법이 없었다. 특히, 고 알피엠에서의 배기 사운드는 정말 예술이였다. 6천 알피엠 정도 꽂아 놓고 터널 같은곳에서 고속으로 달릴때나 신호에 멈추려 다운시프트를 칠때 뿜어져 나오는 모든 주파수의 영역대가 내 귀를 적셨다. 몰론 냉간시동시 동네 전체가 울려서 부모님께 등짝을 맞을뻔한적도 있다. 새벽에 뽀짝뽀짝 이것저것 하고 싶은데 주변에 피해가 갈까봐 시동을 못걸 정도였으니, 진짜 소리 하나 만큼은 컸다.

그래도 정신차리고 할건 해야지.. 중고차인 만큼 검수를 받아보았다. 근데 아니나 다를까 누유, 누수 파티였다. 처음에 발견된 라디에이터 누수는 열이 많은 고성능 엔진 특성상 소모품으로 생각했는데, 문제는 터보차저 누유 였다. 대충 견적 받아보니 천만원 넘는데 차를 받자마자 이만큼 돈을 들이는건 사실 자신이 없었다. 무엇보다 차주가 8번은 바뀐걸로 아는데, 다 뭔짓거리를 했는지 알수도 없는 심산이였다.

결국 환불을 결정하게 된다.

진짜 두번째 차 G20 M340i

이후론 그냥 맘편히 신차 뽑기로 했다. G바디 M3는 여러 후기도 찾아보고 리뷰도 찾아보니(유투브 영상중 한글로 된거는 다봐서 영어로된거 까지 찾아봄) 너무 패밀리카 같은 놈이였다. 그리고 무엇보다 신차가가 1억 4천 정도 하는데 이거 사는순간 완전 카푸어 되는게 자명했다.

그래서 적당히 M340i로 뽑았다. 실키식스 엔진이란 명성에 걸맞게 6기통 B58엔진에 마일드 하이브리드 까지 섞여서 제로백 4.6초대를 보여준다. 그리고 연비가 사기다. 고속도로에선 18km/l 까지 나온다는데 나는 아직 이렇게 까지는 못뽑아봤다. 거기다가 저공해 차량이라 주차장 50% 할인까지 된다(보통 재미와 돈은 비례하는데 이거 완전 책임없는 쾌락이자나..?)
성격이 급한지라 즉시 출고 되는 놈으로 뽑았는데, 다행히 흰색(BMW는 흰색이지)에 모카 시트가 재고가 있어서 바로 계약하고 출고했다.

m340i 후면 샷

인수 받은 다음날 부산찍고 왔고, 길들이기 까지 끝냈다. 끝내고 디퍼 오일+ 엔진오일도 갈았다. 디퍼 오일은 무교환이라는데 개소리 인것 같다. 빼보니 아주 시커먼 철가루들이 가득했다.

M340i 디퍼 오일 빼는 모습

M3로 내 도파민 회로가 망가진 이상 차가 너무 조용해서 현재는 BMW 퍼포먼스 배기를 예약해 두었다. 독일에서 오는데 3개월 정도가 걸린다 그래서 기다리고 있다. 나중에 장착 후기를 남겨보도록 하겠다.

SSR(Server-Side Rendering)의 장점과 단점

Chris.Koo — Sun, 26 Feb 2023 14:57:19 +0900

SSR(Server-Side Rendering)은 클라이언트와 서버의 역할을 분담하여 페이지를 렌더링하는 방식입니다. 이 방식은 다음과 같은 장단점이 있습니다.

장점:

초기 로딩 시간이 빠름 SSR은 서버에서 이미 페이지를 렌더링했기 때문에 초기 로딩 시간이 빠릅니다. 이는 사용자가 페이지를 보기 위해 기다리는 시간을 줄여주어 사용자 경험을 향상시킵니다.
검색 엔진 최적화(SEO) SSR은 서버 측에서 페이지를 렌더링하기 때문에 검색 엔진이 페이지의 콘텐츠를 잘 인식할 수 있습니다. 이는 검색 엔진 최적화를 위해 중요한 요소입니다.
보안성이 높음 SSR은 서버에서 페이지를 렌더링하기 때문에 보안성이 높습니다. 클라이언트에서 보안을 처리할 필요가 없기 때문입니다.
코드 유지 보수가 용이함 SSR은 클라이언트 측에서 페이지를 렌더링하는 CSR(Client-Side Rendering)과 달리 서버 측에서 페이지를 렌더링하기 때문에 코드 유지 보수가 용이합니다.

단점:

서버 리소스가 많이 필요함 SSR은 서버에서 페이지를 렌더링하기 때문에 서버 리소스가 많이 필요합니다. 이는 대규모 트래픽이 발생하는 경우 서버 성능에 영향을 미칠 수 있습니다.
초기 구현 비용이 높음 SSR을 구현하기 위해서는 서버에서 페이지를 렌더링하는 기술에 대한 이해와 경험이 필요합니다. 이는 초기 구현 비용이 높아질 수 있다는 단점이 있습니다.
사용자 인터랙션이 떨어짐 SSR은 페이지 전체를 다시 렌더링해야 하기 때문에 사용자 인터랙션이 떨어질 수 있습니다. 이는 CSR에 비해 사용자 경험을 제한할 수 있다는 단점이 있습니다.

SSR은 초기 로딩 시간과 검색 엔진 최적화를 위해 중요한 방식입니다. 하지만 대규모 트래픽이 발생하는 경우에는 서버 리소스가 많이 필요하므로 적절한 방식을 선택하는 것이 중요합니다.

CSR(Client-Side Rendering)과 SSR(Server-Side Rendering)의 차이점은 무엇인가?

Chris.Koo — Sun, 26 Feb 2023 14:56:14 +0900

CSR(Client-Side Rendering)과 SSR(Server-Side Rendering)은 모두 웹 애플리케이션의 페이지 렌더링 방식을 의미합니다. 하지만 두 방식은 다음과 같은 차이점이 있습니다.

클라이언트와 서버의 역할 분담 CSR은 클라이언트 측에서 동적으로 페이지를 렌더링하는 방식으로, 서버는 필요한 자원을 클라이언트에게 전달하는 역할만 수행합니다. 반면에 SSR은 서버 측에서 동적으로 페이지를 렌더링하고, 클라이언트는 렌더링된 페이지를 전달받아 화면에 표시하는 역할을 수행합니다.
초기 로딩 시간 CSR은 초기 로딩 시간이 느리다는 단점이 있습니다. 이는 클라이언트가 페이지를 렌더링하기 위해 필요한 자원을 모두 다운로드하고 초기화하는 시간이 필요하기 때문입니다. 반면에 SSR은 서버에서 이미 페이지를 렌더링했기 때문에 초기 로딩 시간이 빠릅니다.
검색 엔진 최적화(SEO) CSR은 검색 엔진이 페이지의 콘텐츠를 인식하는 데 어려움이 있습니다. 이는 초기 로딩 시점에 콘텐츠가 동적으로 생성되기 때문입니다. 반면에 SSR은 서버 측에서 렌더링이 되기 때문에 검색 엔진이 페이지의 콘텐츠를 잘 인식할 수 있습니다.
성능 CSR은 사용자의 동작에 따라 페이지의 일부분만 다시 렌더링할 수 있기 때문에 성능이 좋습니다. 반면에 SSR은 페이지 전체를 다시 렌더링해야 하기 때문에 성능이 상대적으로 떨어질 수 있습니다.

CSR과 SSR은 각각 장단점이 있기 때문에 어떤 방식을 선택할지는 애플리케이션의 특성과 요구사항에 따라 달라집니다. 예를 들어, 초기 로딩 시간이 중요한 경우에는 SSR을 사용하고, 성능이 중요한 경우에는 CSR을 사용하는 것이 적절할 수 있습니다.

SSR(Server-Side Rendering)이란 무엇인가?

Chris.Koo — Sun, 26 Feb 2023 14:55:44 +0900

SSR(Server-Side Rendering)은 서버 측에서 동적으로 HTML 페이지를 생성하여 클라이언트에게 전달하는 기술입니다. 이는 클라이언트 측에서 동적으로 페이지를 렌더링하는 CSR(Client-Side Rendering)과는 대조적인 방식으로 작동합니다.

SSR은 웹 애플리케이션의 성능을 개선하는 데 도움이 되며, 특히 초기 로딩 시간을 단축하여 사용자 경험을 향상시킵니다. 이는 클라이언트가 페이지를 렌더링하기 위해 필요한 자원을 다운로드하고 초기화하는 데 필요한 시간을 줄여줍니다.

또한 SSR은 SEO(Search Engine Optimization) 측면에서도 이점을 제공합니다. 검색 엔진은 페이지의 콘텐츠를 읽어들이기 위해 HTML 코드를 스캔하는데, CSR에서는 초기 페이지 로딩 시점에 콘텐츠가 동적으로 생성되기 때문에 검색 엔진이 인식할 수 없는 경우가 있습니다. 하지만 SSR에서는 서버 측에서 렌더링이 되기 때문에 검색 엔진이 페이지의 콘텐츠를 잘 인식할 수 있습니다.

SSR을 구현하는 방법에는 여러가지가 있지만, 대표적인 방법으로는 Node.js 기반의 프레임워크인 Next.js와 Nuxt.js가 있습니다. 이 외에도 Angular, React, Vue.js 등의 프레임워크에서도 SSR을 구현할 수 있습니다.

SSR은 웹 개발 분야에서 중요한 기술 중 하나이며, 더 나은 사용자 경험과 검색 엔진 최적화를 위해 많은 기업들이 적극적으로 도입하고 있습니다.

클레이튼 대납 기능 구현하기 - klaytn fee delegation

Chris.Koo — Fri, 17 Jun 2022 17:29:24 +0900

가스비?

Web3에서는 생소할수도 있는 가스비 라는 개념이 있다. 블록체인 네트워크에 특정 action(송금, 민팅 등)을 실행시키고, 검증시키는 댓가로 일정한 수수료(가스비)를 낸다. 보통 수수료하면 1,000원, 2,000원 정도를 생각할 수 있다. 하지만 블록체인, 특히 이더리움 같은 경우는 민팅시 사람들이 많이 몰려서 몇십만원 까지 수수료를 낸적도 있었다. 상품가격 보다 수수료가 더 비싸지는 기이한 현상이 발생한 것 이다.

아더디드 NFT를 구매하기 위해 ETH 가스비를 지불해야했는데, 구매 경쟁이 심해지면서 가스비가 최대 5ETH에 이르기도 하였음. 구매자들은 총 1억 2300만달러(약 1,550억원)를 가스비로 지불한것으로 알려졌다.
https://twitter.com/yugalabs/status/1520612364839661568?s=20&t=gfvmJTH-t-oB74ya74eTRQ

트위터에서 즐기는 Yuga Labs

“We are aware that some users had failed transactions due to the incredible demand being forced through Ethereum’s bottleneck. For those of you affected, we appreciate your willingness to build alongside us – know that we’ve got your back and will

twitter.com

클레이튼 네트워크 같은 경우에는 가스비는 고정이 되어있어서 그나마 가스비 폭등에서 비교적 자유롭다 (22.06.17 기준 250ston). 그렇지만, UX 관점에서 볼때 가스비는 아직 많이 생소한것은 사실이다. 예를들어, 배달의민족에서 음식을 주문할때 우리가 명시적으로 배민 서버 비용을 매번 청구받지 않는것 처럼 말이다. 이에 클레이튼은 회사 혹은 개발 주체단에서 수수료를 대신 내 줄 수 있는 Fee delegation이라는 기능을 지원한다.

다음은 NFT 민팅을 예시로 작성된 코드다. caver-js를 사용한다.

구현

Client Side

먼저, 트랜잭션을 만들어준다

const senderTransaction = {
  type: "FEE_DELEGATED_SMART_CONTRACT_EXECUTION",
  from: walletAddress,
  to: deployedAddress,
  data: contract.methods
    .mint(caver.utils.toBN(mintAmount))
    .encodeABI(),
  gas: 1000000,
  value: caver.utils.toPeb((+mintAmount * tokenPrice).toString(), "peb"),
};

그다음 트랜잭션을 유저의 private key로 sign 해준다. kaikas 같은 경우는 sign 승인을 할 수 있는 팝업창이 뜰 것이다.

const { rawTransaction: senderRawTransaction } =
  (await caver.klay.signTransaction(
    senderTransaction
  )) as RLPEncodedTrasactionWithRawTransaction<RLPEncodedTransaction>;

마지막으로 sign된 트랜잭션을 서버로 보내준다.

const { txHash: txHash } = (
    await axios.post("/api/gas-station/", {
      senderRawTransaction: senderRawTransaction,
    })
  ).data;
console.log(txHash)

여기 까지가 클라이언트가 할 일이다. 이후 대납은 서버에서 이루어진다.

Server Side

서버에서는 트랜잭션을 사람이 sign 하거나 송금할 수 없기 때문에, 미리 인메모리 월렛에 private key를 넣어두고 request가 오면 자동으로 대납을 진행해준다. Node나 Lambda로 light하게 짜면된다.

인메모리 월렛에 대납용 계정 추가

const caver = new Caver("https://api.baobab.klaytn.net:8651");
caver.klay.accounts.wallet.add(
  process.env.GAS_STATION_ADDRESS_PRIVATE_KEY || "",
  process.env.GAS_STATION_ADDRESS
);

Client로부터 받은 transaction에 signing 후 송금

const { senderRawTransaction: senderRawTransaction } = request.body;

const { transactionHash: txHash } = await caver.klay.sendTransaction({
  senderRawTransaction: senderRawTransaction,
  feePayer: process.env.GAS_STATION_ADDRESS,
});

클라로 다시 response

return response.status(200).json({
  txHash: txHash,
});

전체 코드

클라이언트

type RLPEncodedTrasactionWithRawTransaction<T> = Partial<T> & {
  rawTransaction: string;
};

const caver = new Caver(window.klaytn);
const contract = caver.contract.create(ABI as AbiItem[], deployedAddress);

const senderTransaction = {
  type: "FEE_DELEGATED_SMART_CONTRACT_EXECUTION",
  from: walletAddress,
  to: deployedAddress,
  data: contract.methods
    .mintMetaHuman(caver.utils.toBN(mintAmount))
    .encodeABI(),
  gas: 1000000,
  value: caver.utils.toPeb((+mintAmount * tokenPrice).toString(), "peb"),
};

const { rawTransaction: senderRawTransaction } =
  (await caver.klay.signTransaction(
    senderTransaction
  )) as RLPEncodedTrasactionWithRawTransaction<RLPEncodedTransaction>;

const { txHash: txHash } = (
    await axios.post("/api/gas-station/", {
      senderRawTransaction: senderRawTransaction,
    })
  ).data;
console.log(txHash)

서버

// /api/gas-station.ts

const caver = new Caver("https://api.baobab.klaytn.net:8651");
caver.klay.accounts.wallet.add(
  process.env.GAS_STATION_ADDRESS_PRIVATE_KEY || "",
  process.env.GAS_STATION_ADDRESS
);

const { senderRawTransaction: senderRawTransaction } = request.body;

const { transactionHash: txHash } = await caver.klay.sendTransaction({
  senderRawTransaction: senderRawTransaction,
  feePayer: process.env.GAS_STATION_ADDRESS,
});

return response.status(200).json({
  txHash: txHash,
});

리스트에서 랜덤으로 원소 뽑기 - python list random choices

Chris.Koo — Thu, 26 May 2022 10:53:54 +0900

import random

selected = random.choice(someList)
print(selected)

번외 확률을 가진 리스트에서 원소를 뽑는 방법이다.

import random

selected = random.choices(
    someList, # 원소
    probabilityList # 원소의 확률
).pop()
print(selected)

Pillow 이미지처리 multiprocessing으로 성능 올리기

Chris.Koo — Thu, 26 May 2022 10:37:43 +0900

17+ 개의 PNG 레이어들을 랜덤으로 병합하여 10,000개의 이미지를 만들어내는 프로젝트를 진행중이다. 처음 single-thread 방식으로 구현하였을때 6시간이 걸리길래 식겁한 경험이 있다.

이를 단 20분으로 줄인 방법을 설명하고자 한다.

다음은 Pillow 라이브러리를 이용해 이미지 레이어를 합성하는 예시이다.

def merge_image_layer(self, trait):

    image_layer_path = self.parse_image_directory(trait) # layer PNG image directories
    stack = Image.new('RGBA', (self.width, self.height)) # create new image canvas

    for layer, path in image_layer_path.items():
        image_layer = Image.open(path).convert('RGBA')
        stack = Image.alpha_composite(stack, image_layer) # merge

    stack = stack.convert('RGB') # remove alpha to compress

    stack.save(f'./images/{trait["token_id"]}.jpeg') # save as jpeg

이를 10,000번 혹은 그 이상을 반복한다면 당연히 시간복잡도는 기하급수적으로 늘어날것이다.

현재 개발기기로는 M1 pro를 사용중에 있는데 무려 CPU가 10개나 된다. 백번 활용해보자.

아래와 같이 파이썬에 내장된 multiprocessing 라이브러리를 활용

해 구현하였다.

tqdm은 progress bar를 콘솔창에 표시하는 라이브러리 이다.

print(f"multi threading with {multiprocessing.cpu_count()} CPUs")

pool = Pool(processes=multiprocessing.cpu_count())
for _ in tqdm.tqdm(pool.imap_unordered(self.merge_image_layer, traits), total=len(traits), unit=" image"):
    pass
pool.close()
pool.join()

pillow를 통한 in-memory 이미지 합성의 속도는 향상시킬수 있어도 생각했던 것처럼 이미지 IO Thread Lock으로 인해서 어어엄청 빨라지지는 않는다. 그래도 6시간 걸리던거 20분이면 만족한다..