최안나

서비스를 오픈했는데, 성공했는지는 아직 모른다 - 숫자가 성과가 되기까지 확인해야 할 세 가지

2026-09-06T12:00:12Z

며칠 전, 연동 서비스를 오픈했다. 서비스는 정상적으로 열렸고 주문도 들어왔다. 오픈 후 5일간 일평균 주문은 예상보다 30% 이상 많았다. 첫 숫자만 보면 성공적인 출발이었다. 하지만 PM인 나는 아직 “성공했다”고 말할 수 없었다. 예상보다 좋은 숫자를 의심해야 했다 가장 먼저 눈에 띈 것은 거래액이었다. 오픈 초기 거래액은 예상치의 약 2배였다

SQL을 잊은 PM이 3시간 만에 쿼리를 만들었다 - [PM × AI] 문법은 AI가, 업무 판단은 PM이

2026-08-30T11:00:07Z

나는 어느 정도로 쿼리를 짤 수 있는가? SELECT * FROM 테이블; 이게 현재 전부였다. SQLD 자격증을 딴 적은 있다. 데이터베이스의 기본 개념과 키 컬럼을 이용해 테이블을 연결한다는 원리는 알고 있다. 하지만 자격증을 취득한 지 오래된 지금, LEFT JOIN과 INNER JOIN의 차이부터 다시 찾아봐야 했다. 그런 내가 AI를 활용해

주문 연동 프로젝트에서 PM이 확인할 3가지 - 상태, 확정 시점, 실패 복구까지—주문 연동의 빈틈을 찾는 방법

2026-08-23T11:00:09Z

갑작스럽게 외부 플랫폼과의 주문 연동 프로젝트를 맡게 됐다. 프로젝트 중간에 투입됐지만, 해당 주문 도메인을 가장 잘 이해하고 있는 내가 전체 프로세스의 빈틈을 찾아 정책으로 채워야 했다. 외부 플랫폼과의 주문 연동은 단순히 API를 연결하는 작업이 아니다. 고객에게는 하나의 주문처럼 보이지만, 실제로는 서로 다른 상태와 정책을 가진 두 시스템이 함께 움

12년차 PM, AI 앞에서 다시 신입이 되었다 - 40분 뒤에도 내가 원하던 결과는 나오지 않았다

2026-08-17T11:00:09Z

“40분이면 충분합니다.” AI는 자신 있게 말했다. 내가 만들고 싶었던 것은 매일 예약·취소 데이터를 가져와 구글시트에 업데이트하고, 그 결과를 슬랙으로 알려주는 자동화봇이었다. 누가 어떤 정보를 왜 봐야 하는지도 명확했다. 코드까지 AI가 작성해준다니 금방 끝날 것 같았다. 하지만 40분이 지나도 데이터 한 건 가져오지 못했다. API 키는 어디서

정책서 정리, AI한테 맡겼다가 완전히 망했다 - PM이 일주일간 부딪혀본 나만의 'LLM 위키' 만들기

2026-08-09T11:00:12Z

시작은 이런 고민에서였다 PM으로 일하다 보면 머릿속에만 있는 정책들이 있다. "이 케이스는 왜 이렇게 처리하기로 했더라?", "이 엣지 케이스는 예전에 어떻게 정리했더라?" 지금까지 쌓아온 정책들이 문서 여기저기, 혹은 내 기억 속에만 흩어져 있다는 걸 느낄 때마다 답답했다. 특히 예약·결제처럼 엣지 케이스가 많은 도메인을 맡고 있으면, "정책을 한눈에,

AI를 잘 쓰는 사람들은 '선'을 긋는다 - 백엔드 개발자에게 배운, 사람과 AI의 역할 나누는 법

2026-08-02T11:00:14Z

이번 주, 이틀 간격으로 사내에서 진행하는 AI 관련 강의를 두 번 들었다. 하나는 Gemini 기초 강의로, 강사는 현업 조직에서 일하시는 분이었다. 다른 하나는 Claude Code 기초 강의(PM ver)로, 강사는 백엔드 개발자였다. 평소 나는 매일 AI를 활용하고 있지만, 단순 질문-답변 형태가 대부분이었다. 혹은 데이터를 입력해 주요 수치를 확

그 링크, 그냥 빼시죠 - 선택지를 다시 설계하는 PM의 일

2026-07-26T11:00:12Z

상품을 소싱해와서 판매 중에 있다. 하지만 상품 정보가 너무 많아, 고객들에게 편의성을 제공하기 위해 해당 정보를 가공해서 상품 상세 페이지에 노출해준다. 정확한 원천 상품 정보는 특정 버튼 링크를 통해서 확인할 수 있다. 근데 해당 링크를 통해 들어가서 확인하면, 그 판매처의 다른 페이지로 인입될 수 있어 우리 서비스에서 고객이 이탈할 가능성이 있다.

코드리뷰 후 개발자가 찾아왔다 - 오픈 직전, 자동 취소에서 발견한 정책의 빈틈과 PM의 의사결정

2026-01-25T13:00:04Z

프로젝트 막바지에 가까워질수록, 일은 오히려 더 촘촘해진다. 초기 기획 단계에서 세웠던 정책은 개발 과정에서 한 번씩 재검토되고, 개발 방향은 실제 구현과 운영 맥락을 반영하며 미세하게 조정된다. QA 단계에 들어서면 운영팀과의 싱크를 맞추며, 놓친 부분은 추가 개발로 보완한다. 그렇게 여러 번의 조정을 거쳐, 어느덧 프로젝트는 오픈을 앞두고 있었다. 과

작아 보였던 작업이 전체 구조를 바꾸기까지 - 가상계좌가 바꿔놓은 예약과 결제의 흐름

2026-01-11T13:00:08Z

연말 임베딩 프로젝트로 한창 바쁘던 시절, 자연스럽게 다음 프로젝트까지 확정됐다. 새 프로젝트의 배경은 꽤 명확했다. 현재 내가 담당하고 있는 도메인은 고액 결제가 잦은 편인데, 금융 정책 변경으로 기존 결제 수단만으로는 예약 건당 평균 금액조차 결제할 수 없는 상황이 된 것이다. 이 문제를 해결하려면 새로운 결제 수단이 필요했다. 그렇게 논의가 시작된

시니어 PM의 독서 노트

2026-01-03T00:00:19Z

연말이 되자 연차 소진 기간이 왔다.조금 숨을 고를 수 있는 시기라, 연차를 쓰기 직전에 읽고 싶은 책들을 몇 권 골라두었다. 그중에서도 특히 기억에 남았던 책 몇 권을 정리해보려고 한다. ‘추천 도서 리스트’라기보다는, 지금 시점의 내가 어떤 책을 읽고 어떤 생각을 했는지에 가까운 기록이다. 1. 로지컬 씽킹 PM은 개발, 사업, 마케팅, CS,

끝났다고 생각한 순간, 일이 다시 시작됐다 - 쿠폰, 최종혜택가, 그리고 생각보다 컸던 작업 범위와 영향들

2025-12-20T12:52:30Z

도메인 임베딩 프로젝트가 오픈되고, 한동안은 마음이 조금 놓였다.큰 배포는 끝났고, 이제 연말까지는 비교적 차분하게 갈 수 있겠다는 기대가 있었다. 그러넫 갑자기 올해 말까지는 없을 거라 예상했던 쿠폰 이벤트를 진행한다고 한다. 기존에는... 고객에게 각각 등록된 판매가 / 할인가만 보여주고, 쿠폰 할인은 "쿠폰 할인 50,000원”처럼 별도의 영역으

포트폴리오를 펼치며 시작된 25년 연말 회고

2025-12-06T14:05:31Z

오랜만에 포트폴리오 파일을 열었다. 바쁘게 지내다 보면 늘 ‘나중에 정리해야지’ 하면서도 막상 손이 잘 가지 않는데, 연말 평가 시즌이 다가오니 올해의 일들을 한 번은 정리해야겠다는 마음이 들었다. 그동안 프로젝트 중간에 메모해둔 내용도 있고, 지금쯤 다시 꺼내보면 올해의 흐름이 좀 더 선명하게 보이지 않을까 싶었다. 2025년의 마지막 달이 시작되면서

네 달의 프로젝트, 그리고 내가 얻은 것들

2025-11-29T14:16:31Z

드디어 약 4개월 동안 진행했던 프로젝트가 오픈했다. 처음 이 프로젝트에 투입되었을 때는 솔직히 생각이 많았다. 임베딩 프로젝트 특성상 기존 것을 잘 가공해 새 브랜드에서 자연스럽게 보여주면 되는 일이었기에, 내게는 어떤 배움이 남을까 하는 의문도 있었다. 하지만 막상 프로젝트를 진행해보니, 기능이나 기술적으로 새로웠던 작업은 아니었음에도 PM으로 한

PM이 리더를 보며 성장하는 순간들

2025-11-25T00:30:39Z

정책을 세울 때 대다수 수많은 고민 끝에 결정된다. 도메인의 특성, 고객군의 기대치, 유관부서의 이해관계, 그리고 공통 영역이라면 다른 도메인과의 정합성까지. 어느 하나 막힘없이 지나가는 일은 잘 없다. 그래서 정책을 고민할 때 혼자 오래 붙들어 두기보다는, 주변에 적극적으로 묻는 편이다. 상황과 고민을 다른 사람에게 설명하다 보면 시야가 넓어지고, 느낌

새벽 2시, 배포 기록

2025-11-16T11:31:31Z

준비하던 임베딩 프로젝트를 운영 환경에 먼저 배포하는 날이었다. 새 서비스를 오픈하더라도 기존 서비스에는 어떤 영향도 있어서는 안 됐기 때문에, 새 서비스의 진입은 일단 막아두고 기존 서비스를 운영 환경에서 배포 후 점검하기로 했다. 배포일 새벽 1시 50분. 개발 리더, 백엔드 두 분, 프론트 두 분, PM 리더, 그리고 나.총 7명이 새벽에 사무실에

해커톤은 늘 계획대로 되지 않지만, 그래서 더 재밌다

2025-11-08T14:04:30Z

드디어 해커톤이 끝났다. 이 여운이 다 사라지기 전에 얼른 기록해둔다. 해커톤 신청기 AI 해커톤 공고를 봤을 때, 맘 한켠에 참여는 하고 싶었다. 다만 사람을 모으고 신청하는 일이 귀찮게 느껴졌다.그런데 마감 직전, 팀 개발자들이 해커톤 참여한다기에 나도 뒤늦게 끼어 참여하게 됐다. 팀 구성 처음엔 PM인 나와 백엔드 개발자 두 명이 모였다. 여기

QA를 앞둔 시기, PM의 가장 바쁜 순간

2025-11-02T14:06:14Z

지금 진행 중인 임베딩 프로젝트는 특별한 의사결정이 아니라면 거의 모든 과정을 내가 직접 보고 있다. 8월에 시작한 프로젝트가 어느덧 3개월을 지나, 다음 주부터는 두 번째 환경에서의 QA가 시작된다. 프로젝트를 진행하며 쉴 틈 없이 준비했다고 생각했지만, 역시 가장 바쁜 시기는 QA를 앞둔 지금이다. 개발이 끝난 기능을 하나하나 확인하고, 정책이나 상세

복직 후 6개월, 다시 브런치를 켜며

2025-10-19T14:15:07Z

복직한 지 벌써 6개월이 지났다. 그 사이 나름 많은 일이 있었다. 복직하자마자 빌링 시스템 교체를 진행했다. 그리고 준비 중이던 신규 플랫폼 전환도 완료했고, 약 한 달간 안정기를 거치며 예약·정산 프로세스를 정착시켰다. 이제 좀 숨 돌리나 싶었는데, 갑작스럽게 임베딩 프로젝트 리딩 역할을 맡게 되었다. 정신없이 달리다 보니 어느새 반년. 문득, “나는

그냥 아무 브런치가 돼 - 브런치 글 발행하기 어려워하는 나에게

2023-11-11T09:09:26Z

브런치의 시작은 지인이 참여하는 글쓰기 스터디에 우연히 참여하게 되면서였다. 내가 하고 싶은 이야기를 한 편의 글로 정리했고, 스터디 사람들은 내 글의 첫 독자가 되어 그들의 피드백을 받아 더 나은 글로 다듬어 발행하기 시작했다. 이러한 과정이 설레고 재밌었다. 그래서 이곳에 내 경험과 생각이 담긴 글을 꾸준히 쌓아가고자 했다. 근데 어느 순간, 이 과

ISTJ을 위한 책, <데일 카네기 자기관리론>

2023-08-20T17:35:08Z

현재 내가 다니는 IT회사, 내가 속한 조직의 대다수 개발자들은 나랑 같은 MBTI인 ISTJ 이다. 이들과 함께 업무하면서도 일하는 방식, 질문이나 요청하는 스타일 등이 나와 닮았다고 종종 느끼곤 했다. 그리고 스프린트가 끝내는 회고를 진행하면서, 이를 다시 한번 실감하곤 한다. (혹시 ISTJ가 궁금하다면 유미의 MBTI들 - ISTJ 를 추천한다. 출