❯ git log --oneline reframe/ (18 commits)
c1a7f혜택탭을 포인트탭으로2025.06 – 2026
-혜택탭을 개편해서 출석률을 올려 주세요.
+들어오면 끈끈한데 그 입구를 소수만 밟습니다. 문제가 잔존이 아니라 유입 아닐까요?
한 일
- 타겟을 앱테크 헤비 유저에서 대출을 보러 왔다가 그냥 떠난 다수로 바꿨습니다. 앱테크러를 키우는 프로젝트가 아니라고 못 박았어요
- 출석을 보상 창고에서 연속 기록으로 재설계하고 화면 위계를 뒤집었습니다
- 북극성을 진입으로 고정하고 미션과 상점은 하위 지표로 내렸어요
- 가설 세 개에 각각 기각 조건을 붙여서 틀렸을 때 접을 수 있게 만들었습니다
남은 것
- 지표 정의가 한 곳으로 모여서 주간 판단이 회의 없이 돌아갑니다
- 재방문 병목이 수령이 아니라 진입이라는 사실을 데이터로 확인했어요
# rule: 지표를 늘리기 전에 무엇 하나로 결정할지 먼저 정한다.
c2a7fAI 소비 분류 서비스의 북극성 다시 놓기2026.07 –
-게이미피케이션을 붙여서 DAU를 올려 주세요.
+이 서비스가 실제로 답해 주는 사용자의 Job은 무엇인가요?
한 일
- Job을 넷으로 쪼개고 화면의 카드가 그중 무엇에 답하는지 하나씩 대응시켰습니다
- 북극성을 DAU가 아니라 정리 완료율로 바꾸고 분모 함정 세 건을 코드로 확인했어요
- 지표 대시보드를 사용자 동선 순서대로 재배치해 읽는 순서를 고정했습니다
남은 것
- 매일 열게 만드는 장치보다 한 번에 끝나게 만드는 개선이 먼저라는 합의를 얻었어요
- 측정 체계를 코드와 실측으로 다시 세워 지표 신뢰도를 회복했습니다
# rule: 비율을 강요하는 지표는 제품이 아니라 우리 욕심을 측정한다.
c3a7f전 카드 알림에서 워치리스트로2026.07
-카드 이상치를 모든 카드에 대해 알려 주세요.
+이 알림을 보고 누가 무엇을 결정하나요?
한 일
- 임계치가 카드별이 아니라 회사별 하나로 전 카드에 같이 적용되고 있다는 걸 먼저 찾았습니다
- 대상 키를 자산 종류와 자산 아이디로 나눠 설계해 계좌와 대출까지 같은 구조로 확장 가능하게 했어요
- 지금 안 쓰는 금액 기준 컬럼을 미리 비워 두고 확보해서 다음에 DB 변경 없이 켤 수 있게 했습니다
- 고객사 채널로 나가는 경로는 기존 봇에 얹어 새 인프라 없이 붙였어요
남은 것
- 알림 소음이 사라져서 받는 사람이 실제로 읽는 채널이 됐어요
- 대상 지정 구조라 다른 자산 종류로도 확장할 수 있습니다
# rule: 알림은 정보가 아니라 결정을 위한 도구다. 결정이 없으면 보내지 않는다.
c4a7fAI DLC와 참모 시스템2025 –
-AI 도구를 팀에 도입해 주세요.
+도구가 바뀌어도 남는 건 무엇인가요? 우리가 일을 정의하고 검증하는 구조입니다.
한 일
- 사람의 판단과 AI에게 넘기는 실행 사이의 경계를 문서로 못 박았어요
- 판단 근거를 규칙 파일과 에이전트로 외화해 내가 없어도 같은 결론이 나오게 했습니다
- 작업 단위마다 독립 검증을 한 번 거치는 절차를 넣어 자기 평가를 증거로 대체했어요
남은 것
- 사내 발표를 거쳐 팀의 기본 작업 방식으로 정착했습니다
- 새로 합류한 사람이 맥락을 따라잡는 시간이 크게 줄었어요
# rule: 한 줄의 코드보다 한 줄의 프레이밍이 더 큰 레버리지를 만든다.
c5a7f교환처를 늘리라는 요청 앞에서2026.07
-포인트로 바꿀 수 있는 상품을 늘려 주세요.
+고를 게 없어서 안 바꾸는 걸까요, 바꿀 이유가 없어서 안 바꾸는 걸까요?
한 일
- 스테이징 백오피스를 직접 호출해 실제로 열려 있는 상품과 브랜드를 세어 봤습니다
- 공급 카탈로그를 전부 여는 대신 카테고리와 최저 교환가 기준을 정해 선별해서 열었어요
- 브랜드 필터를 만들려면 목록을 매번 전부 훑어야 해서, 목록 조회 API를 새로 요청했습니다
남은 것
- 교환처 개수가 아니라 첫 화면에서 바꿀 만한 것이 보이는지가 문제였다는 걸 확인했어요
- 운영이 상품을 직접 올리고 내릴 수 있게 되어 다음 개편이 기획 없이도 돌아갑니다
# rule: 개수를 늘리라는 요청은 대개 고를 수 없다는 신호다.
c6a7f매일 알림을 보내자는 요청2026.06 – 07
-알림을 매일 보내서 다시 오게 만들어 주세요.
+이 알림을 법적으로 보낼 수 있나요? 그리고 받는 사람이 원하나요?
한 일
- 정보성과 광고성의 경계를 확인하고, 광고성은 별도 동의가 있어야만 보내도록 조건을 걸었습니다
- 기기 알림을 켜는 미션이 곧 광고 수신 동의가 되지 않는다는 점을 문서로 남겼어요
- 발송 대상 조건을 직접 쿼리로 정의해 운영과 그로스가 같은 기준을 쓰게 했습니다
남은 것
- 동의 없이 나갈 수 있었던 발송을 사전에 막았습니다
- 알림 정책이 규칙으로 남아서 이벤트마다 다시 논의하지 않아요
# rule: 보낼 수 있는가와 보내도 되는가는 다른 질문이다.
c7a7f다 만들기 전에 멈춘 기능2025.06
-세금계산서로 이체하는 기능을 개발해 주세요.
+재무 담당자는 실제로 어떤 순서로 일하나요? 우리가 놓친 단계는 없나요?
한 일
- 개발을 잠시 보류하고 실제 사용자인 재무 담당자들을 인터뷰했습니다
- 기존 가설을 항목별로 검증하고 업무 흐름에서 빠진 단계를 찾았어요
- 인터뷰에서 나온 제약을 기획서의 조건으로 옮겼습니다
남은 것
- 만들고 나서 안 쓰이는 기능이 될 위험을 개발 전에 걷어냈어요
- 이후 기획은 가설을 먼저 적고 인터뷰로 지우는 순서로 자리 잡았습니다
# rule: 만들다 멈추는 비용이 만들고 버리는 비용보다 싸다.
c8a7f정률 캐시백을 폐기하고 상시 이벤트를 만든 일2026.08 –
-대출을 다시 보게 하려면 캐시백 쿠폰을 주면 될까요?
+남의 프로모션에 자리를 의존하는 한 공백은 반복됩니다. 우리가 통제하는 상시 이벤트를 만드는 게 맞지 않나요?
한 일
- 정률 캐시백은 폐기했습니다. 기존 요율도 이미 역마진이었고 올리는 안은 손실을 두 배로 만드는 설계였어요
- 확정 보상과 추첨을 2층으로 나눠 비용 상한을 설계로 잡았습니다
- 진입구는 기존 자리를 재사용해 서버 변경을 한 줄로 줄였고, 대상은 전 고객으로 두고 문구만 갈랐어요
- 혜택 다음은 화면이 아니라 상태라고 보고, 사람이 멈추는 자리 넷을 각각 세워 재진입하면 그 상태가 열리게 했습니다
남은 것
- 지표만 보면 유리한 안을 버린 결정도 근거와 함께 기록으로 남겼어요
- 프로모션 공백이 생겨도 우리 자리로 메울 수 있는 구조가 됐습니다
# rule: 비용 상한은 협상이 아니라 설계로 잡는다.
c9a7f정확도를 올리는 대신 고치는 비용을 낮춘다2026.07 –
-AI 분류 정확도를 올려 주세요.
+분류가 맞아도 노동입니다. 거래가 뭔지 모르니까요. 고치는 비용을 낮추는 게 먼저 아닐까요?
한 일
- 한 달치 거래를 끝까지 직접 분류해 보고 어디서 손이 멈추는지 기록했습니다. 사내에서 끝까지 해 본 사람이 없었어요
- 간편결제와 결제대행은 구조적으로 미분류가 된다는 걸 확인하고, 정확도 목표에서 분리했습니다
- 고객이 가르친 것을 기억으로 쌓고, 규칙 범위는 고객이 직접 고르게 했어요. 넓게 유도하면 틀린 규칙이 대량으로 쌓입니다
- 제안은 승인 전 자동 적용을 금지하고, 저장 전 변경 미리보기를 필수로 넣었습니다
남은 것
- 정확도라는 목표를 고치는 비용이라는 목표로 바꿨습니다
- 화면 두 개가 서로 다르게 만들어져 생긴 표기 문제를 발견해 가장 싼 수리 항목으로 분류했어요
# rule: 미리보기가 없으면 규칙 편집은 도박이 되고, 도박이면 아무도 안 고친다.
c10a7f데이터를 더 달라는 요청을 다시 쓴 일2026.08
-필요한 데이터를 더 받을 수 있게 요청해 주세요.
+상대 팀 입장에서 이 요청의 비용은 얼마인가요? 목적을 못 대는 항목은 왜 넣나요?
한 일
- 요청 6건을 효과가 큰 순이 아니라 효과 나누기 비용 순으로 다시 줄 세웠습니다
- API 단위로 목적을 적었고, 목적을 대지 못하는 항목은 일부러 요청에서 뺐어요
- 1순위는 개발 없이 응답 필드 하나를 더하는 것으로 잡았습니다. 데이터가 없는 것과 동의가 빠진 것을 구분하려고요
남은 것
- 상대 팀 비용이 거의 0인 항목을 앞에 놓아 통과 가능성을 올렸어요
- 요청 문서가 그대로 우선순위 근거가 되어 재논의가 줄었습니다
# rule: 남의 팀에 요청할 때는 그 팀의 비용부터 계산한다.
c11a7f설명하는 온보딩을 버렸다2026.07
-서비스를 설명하는 온보딩 화면을 만들어 주세요.
+설명하는 화면에 고객 데이터가 한 번도 안 나옵니다. 순서를 뒤집으면 어떨까요?
한 일
- 이론을 설명하는 캐러셀을 폐기하고, 자기 데이터를 먼저 보여 주는 순서로 바꿨습니다
- 자랑하던 자동 분류가 실제로는 규칙 기반이라 사실이 아니었던 문구를 걷어냈어요
- 화면 수가 늘어나는 것은 감수했습니다. 한 번에 하는 작업량이 줄어드니까요
남은 것
- 놀람이 먼저 오고 정리 욕구가 따라오는 순서를 만들었습니다
- 온보딩이 설명이 아니라 첫 경험이 됐어요
# rule: 설명으로 설득하지 말고 자기 데이터로 놀라게 한다.
c12a7f전사 성과 공유 방식 개편에 자원했다2026.06 –
-각 팀이 지표와 계획을 정리해서 공유합니다.
+개별 지표는 잘 정리돼 있는데, 그것들을 하나로 꿰는 목표의 위계와 인과가 안 보입니다.
한 일
- 제 제품 밖의 일이라 요청이 없었지만 개편 조직에 자원해서 들어갔어요
- 읽고 나서 회사의 제일 상위 목표와 그 아래 하위 목표, 각 팀이 지금 하는 일이 이어지지 않는다는 것을 문제로 제기했습니다
- 현황 공유를 더 잘하는 쪽과 목표 구조를 다시 세우는 쪽이 다른 일이라는 것을 갈라, 어느 트랙을 먼저 할지 물었어요
- 목표 단위로 묶는 통합 문서와 대시보드를 만들어 베타로 돌리기 시작했습니다
남은 것
- 전사 성과 공유의 문제 정의가 형식 개선에서 목표 위계로 옮겨졌어요
- 제품 밖의 프로세스도 같은 방법으로 다룰 수 있다는 걸 확인했습니다
# rule: 내 담당이 아니어도 구조가 안 보이면 그것부터 말한다.
c13a7fPO가 API 설계를 먼저 써서 넘겼다2026.07
-기획서를 주시면 API는 개발에서 정리하겠습니다.
+이 API를 다음에 누가 어떤 상황에서 만지나요? 그걸 기준으로 모양을 정하는 게 맞지 않을까요?
한 일
- 화면 요청서 대신 API 명세 초안을 제가 써서 개발자에게 검토를 받았습니다
- 주차마다 흩어져 있던 운영 호출을 하나로 묶어, 금액과 내용을 바꿀 때 한 번만 쏘면 되게 설계했어요
- 설명 문구를 꼼꼼히 달아 달라고 요청했습니다. 사람이 읽기 위해서가 아니라, AI가 요청 본문을 만들고 사람이 눈으로 검토만 하게 하려고요
남은 것
- 운영 작업이 여러 번 호출에서 한 번으로 줄었습니다
- 기획과 개발 사이의 왕복이 줄고, 애매한 요청이 코드가 되는 일을 막았어요
# rule: PO의 산출물은 요청서가 아니라 만들 사람이 그대로 쓸 문서다.
c14a7f담당자의 반복 작업을 보고 기능 가설을 세웠다2025.07
-세금계산서 기반 자동 이체 기능을 고도화해 주세요.
+그 일을 하는 사람의 하루에서 가장 오래 걸리는 게 무엇인가요?
한 일
- 실제 업무를 따라가 보니 같은 데이터를 회계용과 자금 집행용 두 포맷으로 중복 작성하고 있었어요
- 포맷을 새로 강제하지 않고, 이미 쓰는 파일 하나만 올리면 신청 정보까지 채워지는 방향으로 설계했습니다
- 가설과 검증 방법을 문서로 먼저 적어 이해관계자에게 돌렸어요
남은 것
- 기능 목록에서 출발하던 것을 사람의 반복에서 출발하게 바꿨습니다
- 몇십 분 걸리던 반복과 실수 위험을 줄이는 쪽으로 우선순위가 옮겨졌어요
# rule: 자동화의 출발점은 기능이 아니라 남의 반복이다.
c15a7f원인을 잘못 짚은 진단을 전건 대조로 뒤집었다2026.07
-복제해 온 상품 데이터가 원본과 달라서 상품이 안 보입니다.
+정말 데이터가 틀렸을까요? 의심하기 전에 전건을 대조해 보겠습니다.
한 일
- 공급 값과 가격, 유효 기간, 판매 상태를 전건 대조해 100% 일치한다는 것을 확인했어요
- 진짜 원인은 자동으로 내려간 상품을 되살릴 경로가 없다는 것이었습니다
- 해결을 데이터가 아니라 배치와 운영 화면 쪽으로 옮기고, 확인 결과를 담당자에게 그대로 공유했어요
남은 것
- 엉뚱한 곳을 의심하며 쓸 시간을 아꼈습니다
- 복제 데이터를 못 믿겠다는 막연한 불신도 같이 걷혔어요
# rule: 원인 후보가 둘이면 말로 다투지 말고 전건을 센다.
c16a7f내 레포 밖으로 내려가서 원인을 찾았다2026.07
-탭을 다시 열어도 화면이 갱신되지 않습니다. 웹 문제 같아요.
+이 화면을 담는 그릇을 만들고 재사용하는 쪽은 앱입니다. 그쪽 코드를 보겠습니다.
한 일
- 앱 소스를 읽어 화면 캐시를 들고 있는 자리가 하나뿐이라는 것을 줄 단위로 짚었습니다
- 웹에서 억지로 우회하는 대신, 원인이 있는 자리에서 고치자고 제안했어요
- 재현 조건과 근거를 정리해 담당 팀에 그대로 넘겼습니다
남은 것
- 웹에 이상한 우회 코드를 남기지 않았습니다
- 다른 팀 코드를 읽고 근거를 대면 논의가 짧아진다는 것을 확인했어요
# rule: 내 저장소에 없다고 내 문제가 아닌 것은 아니다.
c17a7f회고의 질문을 바꿨다2025 – 2026
-스프린트 회고를 정례로 돌립시다.
+잘한 점과 못한 점을 세는 회고가 지금까지 무엇을 바꿨나요?
한 일
- 회고 질문을 두 개로 교체했습니다. 세운 가설이 맞았는지, 고객이 실제로 무엇을 말했는지요
- 2~3주 개발한 뒤 1주 QA 하던 주기를 1주 구현하고 바로 릴리즈한 다음 1주 관찰하는 주기로 바꿨어요
- 코드 리뷰의 정의도 컨벤션 확인에서 비즈니스 로직 정합성으로 옮겼습니다
- 이 방식을 팀 방법론 문서로 만들어 새로 온 사람의 온보딩에 그대로 썼어요
남은 것
- 회고가 소감 공유에서 가설 판정으로 바뀌었습니다
- 격주로 열네 차례 넘게 돌면서 결정과 보류, 액션을 문서로 남겼어요
# rule: 회고는 무엇을 느꼈는지가 아니라 무엇이 틀렸는지를 판정하는 자리다.
c18a7f심의 항목을 제가 만들어 배포 일정을 지켰다2026.03
-보안 심의에서 요구한 기능이 있는데 개발 인력이 다른 일에 묶여 있습니다.
+이걸 미루면 심사 일정이 밀립니다. 제가 만들면 되는 범위인가요?
한 일
- 탈퇴 요청과 비밀번호 재확인, 데이터 내보내기 버튼을 제가 AI와 함께 직접 구현했어요
- 개발자들은 그 주의 핵심 기능에 그대로 붙어 있게 남겨 뒀습니다
- 심사 대상 화면을 스테이징 기준으로 맞추고, 남은 항목은 재논의 날짜를 박아 뒀어요
남은 것
- 심사 일정과 배포 일정을 둘 다 지켰습니다
- PO가 손을 대도 되는 범위가 어디까지인지 팀 안에서 선이 생겼어요
# rule: 일정은 사람을 기다려서 지켜지지 않는다. 내가 할 수 있는 범위면 내가 한다.