저는 어떤 일이든 그 목적과 본질적인 이유를 고민하는 편입니다.
단순히 실행하는 것보다, 왜 이 작업이 필요한지, 그리고 그것이 어떤 의미와 가치를 만들어낼 수 있는지를 끊임없이 자문하고 정리하는 과정을 중요하게 생각합니다.
화면(프론트엔드)에서 시작해 서버·DB·배포(풀스택)를 지나, 지금은 아이디어를 실제 운영되는 제품으로 만드는 일(Builder)을 합니다. 짓는 데서 멈추지 않고, 지은 것을 지키는 규율까지가 제 일이라고 생각합니다.
팀이 사용자 경험 중심의 인터페이스를 정교하게 설계하고 실험하려면, 안정적이고 신뢰할 수 있는 기반(foundation)이 필요하다고 믿습니다.
삶도 마찬가지입니다. 나를 지탱하는 내면의 기반이 단단할수록, 더 깊고 의미 있는 방향으로 움직일 수 있다고 생각합니다.
Frontend → Full-stack → Builder
Frontend
2022 –화면과 사용자 경험에서 시작 — 관제 대시보드, 지도 플랫폼, 디자인 시스템.
→Full-stack
2026 –DB 스키마·인증·배포 인프라·장애 대응까지 — 한 서비스의 전 구간을 단독 담당.
→Builder
현재아이디어를 실제 운영되는 제품으로 — 기획·구현·배포·운영·확산까지 제품 단위로 완결. 짓는 것에서 멈추지 않고 런북·백업·모니터링으로 지키는 규율까지.
Builder는 Anthropic의 Boris Cherny가 제시한 미래의 다섯 직무(Prototyper · Builder · Sweeper · Grower · Maintainer) 중 "아이디어를 진짜 제품으로 만들어내는 사람"입니다. 저는 Maintainer의 규율을 가진 Builder를 지향합니다.
How I Work
배포는 기능이 아니라 사이클 단위
구현에서 멈추지 않고 변경 내역·사용 매뉴얼·사용자 공지·피드백 답글까지 닫아야 한 번의 배포로 칩니다. 실서비스 10영업일 10릴리스 동안 이 사이클을 유지했습니다.
사고를 제도화한다
장애와 실수는 사람 탓이 아니라 절차의 구멍으로 봅니다. 배포 순서 신호 규칙, 기능 간 파급 지도, 백업 복원 리허설 — 한 번 겪은 문제는 런북 규칙으로 바꿔 재발을 구조적으로 차단합니다.
원리까지 소유한다
도구를 쓰면 왜 그렇게 동작하는지까지 파고듭니다. 네트워크 경로는 추측 대신 실측하고, 발표 자료에는 재현 가능한 사실만 싣습니다.
AI는 공정의 일부
시안·구현·문서·운영까지 AI 페어링을 숨기지 않는 공개된 방법론으로 씁니다. 대신 방향 결정과 최종 검증은 언제나 사람의 몫으로 남깁니다.
이 섹션은 두 달간의 Claude Code 세션 기록을 AI에게 역으로 분석시켜 도출했습니다. 분석 과정 읽기
프로젝트 상세 · 성과 · 기술 스택 보기