BUILDING LOG / 04
만들면서, 기록합니다
개발자로서 각 제품을 왜 시작했고, 어떻게 만들었고, 출시하며 무엇을 배웠는지 프로젝트 단위로 남깁니다.
ALL POSTS — 55
55 / 55개의 글
- AI영상 1편
AppForge 회고: 빌드 성공과 제품 완성 사이에 있던 것들
앱 자동화 도구 AppForge를 실제로 사용하며 발견한 실행 오류와 품질 병목. 생성·검증·수정 루프, 증거 기반 완료 조건, 사람이 맡아야 할 출시 경계를 정리한다.
- AI영상 2편
Toris Studio 회고: 로컬 TTS와 영상 검증을 하나의 작업 흐름으로
ClubLog 영상과 쇼츠를 제작하며 정리한 Toris Studio의 작업 흐름. 장면 데이터, 로컬 Qwen3-TTS, 포맷별 편집, 음성·출력 검증, 게시 준비와 실제 발행의 경계를 돌아본다.
- AI
Orca를 고정 도구로 선택한 이유: Paseo와 cmux를 함께 써 본 기록
Paseo·cmux·Orca를 실제 작업 흐름에서 비교하며, 인지적 단절과 작업 기억의 과부하를 줄이기 위해 왜 오픈소스인 Orca를 고정 도구로 선택했는지 정리한다.
- Projects
프로젝트 회고 30편을 정리하고 남은 세 가지 기준
교육 플랫폼, 전자계약, 여행 추천, 모바일 앱 경험을 30편으로 돌아보며 얻은 기준. 상태의 경계, 실패 뒤의 복귀, 근거가 남는 완료를 정리한다.
- Projects
AI 개발 도구를 고를 때 프로젝트를 닫는 기능까지 보는 이유
Orca를 사용하며 느낀 편집 화면과 여러 프로젝트 전환의 중요성. 생성 속도보다 검토·중단·복귀의 비용으로 개발 도구를 평가한 기록.
- Projects
앱 업데이트를 내보내며: 설치된 버전은 저장소와 함께 움직이지 않는다
바로화장실과 WakeProof 업데이트 경험을 계기로 웹 배포와 앱 배포의 차이를 돌아본다. 설치 사용자, 기존 설정, 출시 후 확인 범위를 생각한다.
- Projects
성능 점수보다 다시 설명할 수 있는 측정 기록을 남기기
블로그와 모바일 화면에서 이미지 최적화·코드 분할을 다뤘던 경험. 과거 측정값과 현재 상태, 실험 결과와 실사용 성능을 나눠 기록하는 기준.
- Projects
블로그를 직접 만들고 남은 자산은 프레임워크보다 글이었다
Next.js로 시작한 Toris Blog와 현재 Astro 구조를 돌아본다. 마크다운, URL, 메타데이터를 오래 유지하는 것이 기술 교체보다 중요한 이유.
- Projects
보상을 넣기 전에, 어떤 행동을 늘릴지부터 물었다
교육 플랫폼의 포인트와 bubbleBible의 보상 설계를 함께 돌아본다. 기록 가능한 행동과 제품이 지향하는 가치를 구분하는 회고.
- Projects
bubbleBible에서 다시 읽으러 오는 사람을 생각했다
bubbleBible의 모바일 우선 읽기 경험을 돌아본다. 첫 방문의 기능 소개보다 읽을 위치와 다음 행동을 분명하게 만드는 것이 중요했다.
- Projects영상 1편
SnapMate를 돌아보며: 사진 한 장의 완료 시점은 언제일까
그룹 사진 공유 앱 SnapMate 경험을 바탕으로 촬영, 업로드, 갤러리 반영을 구분한다. 미디어 파일과 게시 정보가 함께 완성되어야 하는 이유.
- Projects영상 1편
밈캐치에서 검색 결과 다음 화면을 고민한 이유
밈캐치의 목록·카테고리·해시태그·상세 탐색을 돌아본다. 검색어와 일치하는 결과를 찾는 것과 표현의 사용 맥락을 이해하는 것은 다른 과제였다.
- Projects
YM Guide의 운영 부채는 추천보다 데이터 갱신에 있었다
청년 정책 큐레이션을 만들며 겪은 수동 갱신의 한계. 추천 정확도와 정보의 최신성, 빈 결과와 수집 실패를 분리해 돌아본다.
- Projects
1/N 정산에서 나머지 1원을 누가 갖는가
LOVETRIP의 예산·정산 기능을 돌아보며 금액의 합계 보존과 분배 규칙, 저장 시점의 정합성을 정리한다. 설명용 정수 분배 예제를 포함한다.
- Projects
추천에 먼저 필요했던 것은 모델보다 설명 가능한 규칙이었다
LOVETRIP의 코스 추천과 YM Guide의 정책 추천을 돌아본다. 후보 필터링, 점수화, 결과 설명을 구분하며 배운 초기 제품의 판단 기준.
- Projects
LOVETRIP에서 외부 응답을 그대로 화면에 보내지 않은 이유
여행 정보의 여러 데이터 소스를 내부 장소 모델로 변환했던 경험. 수집과 서비스의 경계를 나눠 외부 변경을 다루는 방법을 돌아본다.
- Projects
앱·API·어드민을 한 저장소에 두면 무엇이 쉬워지고 어려워질까
21앤 모노레포에서 도메인 타입을 공유했던 경험. 코드 재사용의 장점과 공유 변경의 파급 범위를 함께 돌아본다.
- Projects
전자서명을 직접 만들지 않고도 어려운 일은 남았다
21앤에서 모두싸인 연동을 선택했던 경험. 외부 서비스를 사용하면 줄어드는 구현과 여전히 제품이 책임져야 하는 상태·실패 경계를 돌아본다.
- Projects
예쁜계약에서 배운 것: 화면보다 계약의 상태가 먼저였다
21앤 전자계약 플랫폼에서 앱·병원 관리자·통합 관리자가 같은 계약을 다루던 경험. 사용자별 화면과 공통 상태 규칙을 나누는 판단을 돌아본다.
- Projects
데드링크 검수 배치: 실패 응답을 곧바로 삭제 사유로 삼지 않기
콘텐츠 관리와 데드링크 검수 자동화 경험을 돌아본다. 외부 링크의 일시 실패와 실제 종료를 구별하고 사람이 판단할 근거를 남기는 기준.
- Projects
관리자 OTP를 붙이며 인증 이후의 질문을 배웠다
잇다 SM의 관리자 OTP 인증 업무를 돌아본다. 인증 화면의 성공과 서버에서 보호되는 작업 범위는 별도로 확인해야 했다.
- Projects
7월 1일 이후라는 조건: 정책 시행일을 코드에 넣으며 배운 것
포인트 정책의 시행일과 서버 환경별 조건을 구현한 경험. 날짜 비교 한 줄 뒤에 숨어 있는 기준 시간과 정책 버전의 문제를 돌아본다.
- Projects
포인트 지급은 더하기가 아니라 상태 전이였다
콘텐츠 공개·비공개·삭제에 따른 포인트 지급과 차감 조건을 다룬 경험. 이전 상태와 처리 이력이 왜 금액 계산보다 먼저였는지 돌아본다.
- Projects
프론트엔드에서 Spring까지: 화면 뒤의 흐름을 맡게 됐다
잇다 SM 프로젝트에서 Spring과 MyBatis까지 업무 범위를 넓힌 경험. API를 기다리는 입장에서 데이터 흐름 전체를 설명하는 입장으로 바뀐 과정을 돌아본다.
- Projects
레거시를 한 번에 바꾸지 않은 이유
셈웨어에서 내장 라이브러리 의존을 API 기반으로 옮겼던 경험. 운영 중인 기능을 이해하고 되돌릴 수 있는 단위로 나누는 것이 먼저였다.
- Projects
React 프로젝트에서 Node 스크립트를 실행하며 만난 경계
ES 모듈과 ts-node, tsconfig 충돌을 겪으며 브라우저 코드와 파일 생성 스크립트의 실행 환경을 분리해서 생각하게 된 경험.
- Projects
JSON 생성 스크립트도 제품 코드였다
교육 콘텐츠를 ViewerData로 변환하고 public/data에 저장했던 Node.js 작업을 돌아본다. 변환 경계와 입력 검증이 화면 오류를 줄이는 출발점이었다.
- Projects
표지 한 장이 번호를 흔들었다: index에 너무 많은 의미를 담았던 경험
교육 뷰어에서 표지를 제외한 학습 번호와 퀴즈 번호를 계산한 경험. 배열 위치와 사용자에게 보여 줄 번호를 분리하는 기준을 돌아본다.
- Projects
페이지가 바뀌면 클릭 연결도 바뀌어야 했다
교육 콘텐츠의 useClickable과 페이지 전환 작업을 돌아보며 이벤트 등록·해제, 오래된 상태 참조, React 밖의 DOM을 다룰 때의 경계를 정리한다.
- Projects
새로고침을 견디는 풀이 상태와 다시 들어올 수 있는 경기 기록
교육 플랫폼의 sessionStorage와 배구 기록판의 재진입 문제를 함께 돌아본다. 데이터가 저장되는 것과 사용자가 작업을 이어 가는 것은 다른 요구였다.
- AI영상 1편
앱 17개와 웹 서비스 3개를 만들며 배운 것: 작업 기억을 지켜야 했다
앱 17개와 웹 서비스 3개를 만들며 겪은 인지적 단절과 작업 기억의 과부하를 돌아본다. 도구를 더 추가하기보다 작업 맥락을 줄이고 이어 가는 방법을 정리한다.
- Projects
장면을 바꾸면 사라지는 도구: Drawer 저장 시점을 돌아보다
AlgeoMath 도구의 getData를 장면 전환 시 호출하며 겪은 문제를 바탕으로, React의 정리 함수와 사용자 데이터 저장의 책임을 구분한다.
- Projects
scene1과 UUID 사이: 교육 뷰어에서 ID의 역할을 다시 생각했다
교육 뷰어의 장면 ID와 콘텐츠 ID를 구성하며 마주한 식별자 문제. 순서, 참조, 표시 번호를 같은 값으로 처리하면 왜 수정이 어려워지는지 돌아본다.
- Projects
교육 콘텐츠를 만들며 배운 것: 원본과 풀이 상태를 나누는 이유
React 교육 콘텐츠 플랫폼에서 문제 데이터와 사용자의 풀이 상태를 분리했던 경험을 돌아본다. 화면보다 먼저 정해야 했던 데이터의 수명과 초기화 경계에 관한 기록.
- AI
AI 생산성 — 2026 코딩 에이전트 지형과 도구 선택 기준
2026년 AI 코딩 에이전트 시장은 모델 경쟁에서 하네스(스캐폴딩) 경쟁으로 재편됐다. 1인 스튜디오 토리스가 대표이자 개발자 관점에서 4단계 진화와 Claude Code·Codex 비교, 도구 선택 기준을 정리했다.
- AI
AI 생산성 극대화 — Claude Code와 Codex를 함께 쓰는 법
토리스는 Claude Max와 ChatGPT Pro를 둘 다 구독한다. 월 400달러를 인건비로 정당화하는 작업 라우팅, 하네스 자산 공유, 병렬화, 상호 검증 — 두 에이전트로 생산성을 극대화하는 실전 운영법.
- AI영상 2편
AI 생산성 — OpenAI Codex의 진화와 대안을 검증하는 기준
2026년 Codex는 CLI·클라우드 에이전트·IDE·API 네 표면을 아우르는 OpenAI의 코딩 에이전트 플랫폼이다. Claude Code를 주력으로 쓰는 토리스가 대안 검증과 리스크 헤지 관점에서 진화를 정리했다.
- AI
AI 생산성 — Claude Code를 개발 워크플로의 중심에 두는 이유
Claude Code는 서브에이전트·스킬·MCP·훅을 갖춘 에이전트 오케스트레이션 런타임으로 진화했다. 매일 이 도구로 제품을 만드는 1인 스튜디오 토리스의 대표이자 개발자 관점에서 2026년 초 동향을 정리했다.
- AI
AI 생산성 — 하네스 엔지니어링, 에이전트 성과를 좌우하는 기반
하네스 엔지니어링은 컨텍스트 관리, 도구 오케스트레이션, 검증 루프, 권한 게이팅으로 모델을 감싸는 설계다. 모델은 상한선을 정하고 신뢰성은 하네스가 결정한다 — 토리스가 에이전트 운영에 적용하는 원칙이다.
- Projects
[Case Study] 마케팅 조직의 유일한 풀스택 — 21앤 1년의 의사결정과 운영 기록
개발 조직이 얇은 마케팅 중심 회사에서 풀스택 한 명이 PG 불가 판단, 모두싸인 전자계약 연동, 비용 설계, 외부 연동 운영을 어떻게 끌고 갔는지 — 의사결정과 조율 과정을 중심으로 정리한 케이스 스터디.
- Projects
[Case Study] 21앤 전자계약 플랫폼 — PG 없이 설계한 병원·모델 B2B2C 계약·정산 시스템
병원과 모델을 연결하는 B2B2C 플랫폼에서 PG 대신 은행 API·전자서명(모두싸인) 중심으로 계약·포인트·정산을 설계한 과정. 규제 제약, 스택 선택의 트레이드오프, 이해관계자 조율까지 정리한 케이스 스터디.
- Projects
[케이스 스터디] CryptoTrade.gg - 온체인 트레이딩 이력 조회 서비스의 설계와 트레이드오프
토리스가 만든 온체인 트레이딩 이력 조회 서비스 CryptoTrade.gg의 문제 정의, 기술 설계, 커뮤니티 피드백 루프를 정리한 기술 케이스 스터디
- Projects
[케이스 스터디] bubbleBible — 매일의 말씀 습관을 만드는 모바일 우선 PWA 설계기
습관 형성과 공동체 나눔이라는 두 축으로 설계한 성경 플랫폼 bubbleBible의 PWA 전략, 게이미피케이션 설계, 실시간 커뮤니티 아키텍처를 정리한 기술 케이스 스터디
- Projects
[케이스 스터디] PEPEBear - Solana 기반 커뮤니티 플랫폼의 온체인/오프체인 설계
토리스가 Solana 위에 구축한 커뮤니티 플랫폼 PEPEBear의 지갑 UX, 온체인/오프체인 데이터 분리, 커뮤니티 검증 루프를 정리한 기술 케이스 스터디
- Projects
[케이스 스터디] love-trip — 커플 여행 계획을 한 화면으로 모은 제품 설계기
흩어진 여행 정보를 하나의 추천 플로우로 통합한 love-trip의 제품 가설, 모노레포 아키텍처, 외부 API 의존성 관리 전략을 정리한 기술 케이스 스터디
- Projects
[케이스 스터디] ym_guide — 청년 정책 정보의 탐색 비용을 줄이는 큐레이션 제품 설계기
청년정책 OPEN API 위에 질문 기반 추천 레이어를 얹어 정책 탐색 비용을 줄인 ym_guide의 제품 가설, 데이터 가공 전략, 추천 시스템 설계를 정리한 기술 케이스 스터디
- Projects
[케이스 스터디] Toris Blog - 우리 회사의 기술 블로그를 우리가 만든 방식
토리스가 자사 기술 블로그를 직접 설계·구축·운영하며 내린 기술 결정과 파일 기반 CMS 트레이드오프를 정리한 도그푸딩 케이스 스터디
- Projects
[Case Study] 셈웨어 4개월 — 리뉴얼·교육 플랫폼·레거시 마이그레이션, 그리고 SM 풀스택 전환
셈웨어에서 4개월간 수행한 웹사이트 리뉴얼, 교육 콘텐츠 플랫폼, 레거시 API 마이그레이션과 잇다 SM 프로젝트 풀스택 전환까지 — 제약 조건과 설계 판단, 협업 조율을 중심으로 정리한 케이스 스터디.
- Learning
[React] React Server Components 보안 취약점 (CVE-2025-55184, CVE-2025-55183) 및 Reac2Shell 공격 벡터
React Server Components의 DoS(CVE-2025-55184)·소스 코드 노출(CVE-2025-55183) 취약점과 이를 결합한 Reac2Shell 공격 벡터를 분석하고, 패치·완화 조치와 보안 모범 사례를 정리합니다.
- Learning
[React] React Server Components 심각한 보안 취약점 (CVE-2025-55182)
React Server Components의 인증 없는 원격 코드 실행(RCE) 취약점 CVE-2025-55182(CVSS 10.0) 분석과 대응 가이드. 영향받는 버전, Next.js·React 패치 방법, 우리 스택 점검 체크리스트를 정리합니다.
- Learning
Next.js 기반 Web3 제품 스택 — 토리스 엔지니어링 노트
토리스가 PEPEBear·CryptoTrade.gg 등 Web3 제품을 만들며 검증한 Next.js 스택 노트. Hardhat·OpenZeppelin·thirdweb·ethers.js로 컨트랙트를 배포하고 NFT·포인트 시스템을 구축한 판단을 정리했다.
- Learning
DeFi 서비스 아키텍처 노트 — 제품 관점에서 본 구성 요소
DEX·대출·스테이킹 등 DeFi 핵심 구성 요소를 제품 관점에서 정리한 토리스 엔지니어링 노트. Solidity 컨트랙트 구조와 Next.js 연동, 재진입 방지 같은 보안 판단 기준까지 다룹니다.
- Projects
토리스가 제품을 만드는 방식 — 1인 스튜디오의 개발 워크플로
기획부터 운영까지 Toris가 실제로 쓰는 도구·자동화·품질 게이트를 공개한다. 표준 스택으로 선택 비용을 없애고, 타입 체크·CI 테스트·Sentry 모니터링이 리뷰어의 빈자리를 메우는 1인 스튜디오 워크플로와 그 트레이드오프 정리.
- Projects
실험 노트: 블로그 챗봇과 OpenAI API — 무엇을 검증하려 했고 무엇을 배웠나
개인 블로그에 OpenAI API 기반 챗봇을 붙인 실험 기록. Next.js API Route 하나와 system 프롬프트만으로 충분했고, RAG는 임베딩 비용·복잡도 대비 효과가 작아 철회했다. 최소 구성 설계와 시크릿 관리 교훈까지 정리.
- Learning
Supabase + Next.js — 토리스가 MVP를 빠르게 출시하는 표준 스택
토리스가 밈캐치·YM Guide·LOVETRIP 등 실제 제품에 적용해 온 Supabase + Next.js 실무 기준. PostgreSQL, 인증, RLS, 실시간 구독, 스토리지 구성을 프로덕션 관점에서 정리했다.