글
서비스를 만들며 쌓인 기록
제품 범위를 정하고 경험과 시스템을 만들며, 출시 후 확인한 판단을 구체적인 사례와 함께 기록합니다.
대표 글
LumX를 만드는 이유
LumX는 직접 만들고 운영하거나 검증하는 제품, 기획부터 다음 판단까지의 과정과 현장에서 확인한 배움을 함께 쌓는 제품 아카이브입니다.
이름과 값이 같이 있으면 이름을 믿는다
추천색 표에는 navy, crimson 같은 그럴듯한 이름이 있었고, 아무도 값을 보지 않았습니다. 색만 바꾸지 않고, 계절 설명을 숫자 규칙으로 옮겨 모든 색을 검사하게 했습니다.
늘 울리는 경보는 없는 것보다 나쁘다
CI의 빨간불이 내 잘못이 아닌 날이 반복되면 사람은 빨간불을 읽지 않습니다. 남의 서버와 알려 주지 않은 예외가 두 제품의 CI를 그렇게 만들었습니다.
오류를 내지 않는 결함
잘린 알림 문구와 랜드마크 뒤에 숨은 나무는 오류를 내지 않았습니다. 하나씩 고치는 대신 그릇을 고치고, 있는지가 아니라 보이는지를 재게 했습니다.
«보상이 없다»를 «보상이 작다»로 읽지 않는다
초를 다 꽂은 뒤 아무 반응이 없다는 문제에 목표를 키워 답했다가 틀렸습니다. 고칠 것은 보상의 크기가 아니라 행동과 반응 사이의 거리였습니다.
기능을 접는 일은 결정 하나가 아니다
잘 만든 기능을 지우며 배웠습니다. 코드와 데이터는 따로 판단하고, 기능은 품질이 아니라 원리로 재판하고, 반쯤 도는 것은 남기지 않는다는 것을.
매일 오는 제품의 가장 중요한 필드는 날짜다
서버는 매일 새 문제를 만들었는데 화면은 다음 날에도 어제 결과를 띄웠습니다. 진행 상태에 날짜가 없었고, 그런 죽음은 로그에 남지 않습니다.
숫자가 적을 때는 숫자를 보여 주지 않는다
푼 팬 1명 중 100%가 맞혔다는 문장은 참이지만 아무것도 알려 주지 않습니다. 표본이 작을 때는 숫자 대신 빈칸을 보여 주기로 했습니다.
UI 문구는 명세다
화면이 한 약속을 코드가 지키지 않을 때, 문구를 낮추는 쪽이 늘 더 쌉니다. 두 제품에서 약속을 그대로 두고 동작을 고친 이유를 적었습니다.
고정된 시각 하나가 제품 전체를 동기로 만든다
아무 때나 오라고 만든 하루짜리 파티에 밤 10시 단체 사진을 하나 두었습니다. 알림과 예고가 전부 그 시각을 중심으로 섰고, 제품은 두 말을 하고 있었습니다.
데모는 조립하지 말고 연기하게 한다
홍보 클립을 만들 때 상태를 코드로 세워 찍는 대신, 도구가 실제로 걸어가 화면을 읽게 했습니다. 그 스크립트가 공짜 통합 검사가 됐습니다.
스냅 거리는 하나의 값이 아니다
별과 별을 잇는 선이 열 쌍 중 넷에서 지나가던 별을 물었습니다. 답은 스냅 반경 하나가 아니라 둘이었습니다 — 의도한 자리에서는 넉넉하게, 지나가는 중에는 좁게.
아무도 세지 않던 문
연습 모드는 기록을 건너뛰어서 무해해 보였습니다. 그런데 오늘 문제를 그대로 열고 정답까지 알려 줬습니다. 연습 세 번이면 본 게임 만점이었습니다.
규칙이 지키던 것은 대리 변수였다
규칙은 비회원에게 아무것도 열지 않았습니다. 지키려던 것은 남의 데이터였습니다. 소유권으로 다시 그으니 규칙은 더 안전해졌고, 제품에는 문이 생겼습니다.
두 표본이 반대로 말해서, 아무것도 바꾸지 않았다
운영 데이터는 한 신호가 우연 이하라고 말했고, 고칠 준비는 끝나 있었습니다. 정답 라벨이 있는 골든셋은 정반대를 말했습니다. 어느 쪽도 결론을 내지 못해 아무것도 옮기지 않았습니다.
규칙을 마케팅에만 걸어 두고 있었다
선수 사진을 쓰지 말라는 규칙은 마케팅 브리프에 있었습니다. 그런데 제품은 같은 사진을 공개 도메인에서 모든 방문자에게 보여주고 있었습니다.
조용한 폴백은 조용한 거짓말이 된다
없는 값 하나를 try/catch가 삼켰고, 그 자리에 떨어진 대체 그림이 다섯 달 뒤 제품 소개 자료에 실렸습니다. 폴백은 «아직»과 «틀렸다»를 갈라야 합니다.
문을 걷어내기 전에, 그 문이 몰래 지키던 것을 세어 봤다
가입 게이트를 없애야 퍼널이 열린다는 건 분명했습니다. 그런데 그 문은 유료 AI 호출의 유일한 상한이기도 했습니다. 걷어내기 전에 상한을 먼저 옮겨 지었습니다.
관찰할 수 있는 순간이 출시 시점이다
주변 개발자들은 아무도 써보지 않은 서비스에 회원 탈퇴 흐름부터 설계합니다. 기준을 완성도가 아니라 관찰 가능성으로 옮기면 훨씬 일찍 내보낼 수 있습니다.
바이브 코딩은 일을 의사결정으로 옮긴다
에이전트끼리 주고받으며 완성도 있는 서비스에 스스로 도달할 것이라 기대했습니다. 실제로는 어떤 저장소에도 답이 들어 있지 않은 질문 앞에서 멈춥니다. 결과를 가르는 것은 그 순간을 몇 번 알아차렸고, 그때마다 얼마나 옳게 골랐는가입니다.
Clad를 공개하며 얻는 것
Clad의 작업을 공개하는 목적은 진척을 과시하는 데 있지 않습니다. 제품 판단을 검증받고, AI 분석의 한계를 숨기지 않으며, 실제 반응을 다음 변경으로 연결하기 위해서입니다.
Clad를 만든 이유와 제품의 경계
Clad는 전문가를 대체하거나 사진 한 장으로 정답을 약속하는 서비스가 아닙니다. 퍼스널 컬러가 궁금한 사람이 이해하기 쉬운 첫 분석과 활용 가능한 팔레트를 얻도록 돕는 제품입니다.
Clad의 분석 전후 경험을 설계한 방법
퍼스널 컬러 모델이 예측을 만들더라도 사진 품질과 결과 설명, 추천의 연결 방식이 부족하면 사용자는 결과를 신뢰하거나 활용하기 어렵습니다.
AI 전환은 운영 설계에서 시작합니다
AI를 실제 업무에 정착시키려면 반복 작업을 찾는 데서 멈추지 않고 판단 주체, 품질 기준, 예외 처리, 개선 주기까지 다시 설계해야 합니다.
클라우드 엔지니어링 경험을 제품에 쓰는 법
운영 경험은 장애와 비용, 복구를 미리 생각하게 해줍니다. 동시에 1인 제품에서는 복잡성을 늦추고 현재 위험에 맞는 최소한의 기반만 선택할 줄 알아야 합니다.