당근에서 주최하는 내부 세미나 PEConf에 초대를 받았다. (감사합니다!)
Product Engineer를 위한 커뮤니티로, 제품을 만드는 사람들이 어떤 시행착오를 겪고 어떤 결과를 꿈꾸는지,
그 과정에서 배운 것을 나누는 공간이다.
여기서 말하는 Product Engineer란 단순히 직함이 아니라,
제품에 몰입하며 일하는 사람을 의미한다.
2019년에 세리프 만수르가 Atlassian에서 Product Engineer라는 개념을 정리했고,
게르게이 오르스가 Product Minded Engineer라는 관련 개념을 퍼뜨렸다.
2023년에 리 로빈슨(Vercel)이 Product and Platform Engineers라는 글을 쓰고,
Vercel의 직함을 Fullstack Engineer에서 Product Engineer로 바꾸면서 PE라는 말이 더 널리 퍼지게 되었다.
AI로 구현의 장벽을 낮추고, 더 제품적인 일에 시간을 쓰자
by. Arawn (박용권님)
AI로 인해 구현 비용이 낮아지고 있다.
(링크드인에서는 흔히 "코드가 싸지고 있다"라고 말한다.)
이럴수록 맥락과 판단의 가치가 올라간다.
맥락을 이해하고, 문제를 정의하고, 이를 해결하여
"흐름을 제어하는 사람"이 앞으로 지향해야 할 엔지니어 방향이라고 본다.
구현을 깔끔하게 끝내고, '더 좋은 제품'에 몰입하자.
우리 사용자들은 무엇을 불편해하는가?
속도만 빨라지고, 일이 쉬워지지 않는다.
흥미로운 데이터가 있었다.
4월부터 12월까지 코드량과 PR 수는 계속 선형으로 증가하는데,
배포 지수는 10월에 고점을 찍고 점점 떨어지기 시작한다.
코드를 생산하는 속도가 빨라지면서, 우리가 관리해야 할 맥락과 판단의 수가 함께 증가한 것이다.
운영과 관리 포인트가 늘어나는 셈이다.
더 많은 일을 하는 것보다,
더 많은 맥락을 이해하고 끝까지 책임지는 게 중요해졌다.
나는 이 부분에 굉장히 많이 공감했다.
정말 "That's what I'm saying!'이라고 외치고 싶을 정도로.
AI가 생산성을 올려주고 코드 구현 속도를 줄여준 것은 맞다.
하지만 인간이 책임지고 팔로업할 맥락도 동시에 증가했다.
그냥 만들어서 배포하고 끝낸다고, 배포한 기능 개수가 많아졌으니 생산성이 올라간 것일까?
그렇게 보기는 좀 어렵다고 생각한다.
AI가 구현의 리소스를 줄여줬기 때문에, 인간은 '사용자를 위한 디테일'에 시간을 더 쓸 수 있게 된 것이다.
예전에는 "ETA가 다가와서", "리소스가 부족해서" 못하던 디테일 잡기를 이제는 할 수 있는 시간을 확보한 것이다.
그리고 유저들은 바로 이런 디테일로 붙잡을 수 있다고 생각한다.
제품 엔지니어링의 피드백 루프를 가속하는 AI 하네스
by. Moel (김동욱님)
작년 10월까지만 해도 한 달에 6건의 업무를 처리했지만,
이번 달에는 QA 9건, CS 2건, 새 기능 1건을 개발했다고 한다.
코딩은 빨라졌는데, 전체가 빨라진 건 아니다
AI로 코딩하는 시간은 줄었지만, QA 시간까지 합치면 오히려 더 느려진다.
배포 -> 디버깅 -> 수정 사이클에 에너지를 소모하게 된다.
여기서 문제가 되는 건, 작업 티켓에 명시된 업무 내용은 '맥락'을 가지고 있지만,
AI는 과거 인사이트 없이 이를 처음부터 파헤치기 시작한다는 점이다.
작업 끝에서 얻은 교훈을 다음 작업의 입력으로
이 흐름이 바로 'AI 하네스'가 된다.
과거의 실수를 까먹고, 매번 규칙을 재학습하고, 세션 간 작업 맥락이 단절되는 것을 막는다.
실제 작업 흐름
1. 일을 시작하면 Agent.md와 Lesson 파일을 읽어서 과거 맥락을 로드한다.
2. 프로젝트별 컨텍스트를 확인하고, repo 상태와 Linear 티켓을 연결한다.
3. dedicated worktree를 생성해서 구현을 시작한다.
4. 작업이 끝나면 교훈을 Lesson으로 저장하고, PR을 올린다.
월요일부터 당장 해볼 수 있는 것
다음주부터 당장 따라하려면 무엇을 해야하는가, 아래 세 가지를 말씀해주셨다.
1. 무엇을 했는지 - 오늘 마무리한 작업의 핵심
2. 무엇을 배웠는지 - 1번에서 배운 교훈
3. 다음의 제약 조건 - 2번을 바탕으로 lesson 작성하기
AI가 별로였던 것이 아니라, 매일 리셋되어 빈손으로 업무를 시작하는 게 문제였던 것이다.
하네스의 세 가지 핵심
1. 기억의 외부화: 개인의 기억에 의존하지 않고, 시스템적으로 기록한다.
2. 선제적 제약: 미리 피해야 하는 함정을 명시한다.
3. 안정성 보장: 이전 작업 종료 시점을 그대로 이어서 오늘 작업 시작 시점에 가져올 수 있다.
사소한 교훈들이 모여 복리처럼 쌓이고, 이들이 든든한 시니어 동료처름 느껴진다는 말이 인상적이었다.
실제로 작업 티켓 해결을 월 6건에서 40건으로, CS 해결을 1건에서 14건으로, 해결 속도를 3일에서 45분으로 단축시켰다고 한다.
Q&A에서 인상 깊었던 내용
Q. 교훈이 쌓이면 양이 방대해져서 읽기 어려워지지 않나?
한글 대신 영어로 정리하면 byte 수를 많이 줄일 수 있다고 한다.
한글로 된 맥락을 Opus 4.6에 넣었을 때 대화 시작 후 바로 max에 도달해서 대화 압축이 일어나는 것을 보고 영어로 변경했다고.
대화 맥락을 추출해서 title+description 3줄로 정리하고 index를 붙인다.
(필기본을 복기한 것이라 정확하지 않을 수 있음)
각 교훈이 3줄 밖에 안되므로, 40개의 교훈을 다 합쳐도 120줄밖에 안된다.
1M context를 쓰면서 정합성이 올라가서 이제는 덜 신경써도 되게 되었다고 한다.
Q. 팀 작업에도 하네스를 적용한 사례가 있는가?
Lesson이 충분히 완성되면 skill화해서 repo에 저장한다.
원본 Lesson 파일은 삭제하고, skill만 남겨서 context 양을 관리한다고 한다.
유사한 나의 경험 - AI 룰 세팅
나는 올해 초 우리 스쿼드의 레포 AI 룰 세팅을 자발적으로 진행했다.
매번 작업할 때마다 각 세션에 필요한 맥락을 찾아서 먹이는 것에 지쳐있었다.
AI 룰에 대한 갈망은 계속 있었지만, 주니어인 내가 해도 되는 건가 고민하고 있었다.
그런데, 당장 실무 병목을 해결하는데 그런 체면이 중요한가!
AI 룰을 거창하게 생각하지 말고, 실무 병목을 해결하기 위한 목적으로 차근차근 접근하자.
개발자들은 한 레포에서 오래 일하다보면 서로 암묵적인 코딩 컨벤션이 생긴다.
코드 리뷰를 반복하고 토론하다보면, 그게 인간의 뇌에 맥락으로 남아 다음부터는 그 사항을 지키며 짜는 것이다.
AI 룰은 그 인간 뇌의 맥락을 문서로 풀어내는 것이다.
문서화 과정에서 우리 팀의 모호했던 코딩 컨벤션은 추가 토론을 거쳐 정리하기도 했다.
이 과정에서 우리 팀의 코딩 컨벤션이 더 탄탄해졌다. 오히려 좋아.
그리고, 이 강연을 들은 다음 날 팀에 AI 하네스 이야기를 했다.
레거시에 얽힌 KTLO를 해결하면서 생긴 Lesson을 적재해서 교훈 루프를 만들기.
어쩌다보니 AI 룰에 하네스를 추가하는 것도 내가 하게 되었다.
역시 쫄지 말고, 그냥 하면 된다.
[AI 홍수 시대, 프론트엔드 개발자가 Rule을 설계해야 하는 이유] https://developer-dreamer.tistory.com/210
7년차 FE, 0년차 리드
by. Root님 (실명을 메모하지 못했다...)
Root님은 2018년에 엔지니어 커리어를 시작, 2021년에 당근에 입사해 FE 엔지니어로 활동 중인 7년차(사실 8년차) FE이다.
재작년에 아파트팀에 합류했고, 작년부터 제품 리드를 겸임하고 있다.
당근 아파트 커뮤니티는 같은 아파트에 사는 주민끼리 소통하는 폐쇄형 커뮤니티이다.
주차 문제, 공공장소 사용 규칙, 물물교환 같은 것들을 이웃끼리 나누는 공간이다.
커뮤니티실 엔지니어는 단순 구현을 넘어 제품을 함께 만들어가는 역할이다.
FE가 API 설계나 스펙을 주도적으로 디자인해서 백엔드에 요청하고,
이벤트 로깅도 프론트엔드가 주도적으로 관리한다.
간단한 기능은 PR을 작성하고 직접 개발해서 배포까지 한다.
FE 개발자, 리드가 되다
작년 8월, 아파트 팀에는 많은 변화가 있었다고 한다.
팀 해체 가능성까지 나오는 상황에서, 제품 리드를 자원했다고 한다.
남은 3분기 (사실상 한 달 반) 동안
유의미한 제품 결과물과 지표를 달성하고, 사용자 경험을 개선해야 한다.
기존과 달리 책임을 지고 최선의 결정을 내려야 하는 부담이 생겼다.
PO 신입 인턴이라고 생각하자
우리가 무엇에 집중해야 하는지에 대한 명확한 답이 없다.
소수의 사람들로 가설을 검증하고 방향을 제시해야 한다.
이미 이 서비스는 3번의 실패를 겪고 4년이 된 상황이었다.
이 상황에서 4년 간의 히스토리 문서를 모두 읽고, 커뮤니티실 내의 다른 서비스도 분석했다.
당근의 다른 제품들의 히스토리까지 분석했다고 한다.
(나는 이 대목에서 문서가 남아있어 다행이라는 생각을 했다... 문서화의 중요성)
다른 리더, PM에게 조언을 구하고 그들의 행동을 따라했는데,
팀 내 PM이 매일 아침 데이터를 확인해서 전날 특이점과 트렌드를 파악하는 것을 보았다고 한다.
쿼리 작성이나 데이터 분석에서 부족한 점은 AI로 보완해가며 독자적으로 데이터를 보기 시작했다.
데이터 분석에 AI를 활용하다
1. 행동 데이터 분석 - Amplitude MCP
Amplitude는 유저들의 화면을 녹화본처럼 리플레이할 수 있는 툴이다.
Amplitude MCP를 사용하면 자연어로 원하는 지표를 분석할 수 있다고 한다.
이탈율 퍼널을 분석하고, 사용자들이 자주 쓰는 기능을 정리해볼 수 있다.
(이건 처음 알았다! 흥미로움)
2. 데이터 심화 분석 - BigQuery MCP, 스키마 정보 문서
활성화된 아파트의 특징이나 글과 댓글 패턴을 분석하고,
DB 테이블 컨텍스트를 문서화해서 아파트에 특화된 데이터 맥락을 만든다.
3. AI 멘토 - PO, DA 에이전트
조언을 구하거나, 슬랙과 노션 히스토리를 검토하거나, 아이디어를 의심해달라고 요청한다.
첫 번째 결론, 그리고 실패
유저들은 정보를 원한다. 그리고 의외로 질문에 대한 답변 비율이 높다.
질문의 40%가 2분 내에, 70%가 30분 내에 답변이 달린다.
무조건 1분 내 답변이라는 슬로건으로 AI 답변 시스템을 구축했다.
질문이 올라오면 과거 데이터를 검색해 AI가 답변하고, 모르면 유저에게 답변을 유도하는 것이다.
하지만, 기대만큼 성과가 나오지 않았다고 한다.
사실 나는 이 부분에서 어라 그런 결론은 조금 위험할수도...!라는 생각이 들었다.
아파트 커뮤니티에 올렸다는 건 '내 이웃주민, 같은 동 주민'에게 특별히 물어보고 싶어서 였을 것이다.
같은 아파트라는 내적 친밀감에서 형성된 상태에서 누군가에게 넌지시 말을 걸어보고 싶었을 것 같다.
그런데 글을 올리자마자 달린 칼답이 AI라면, 어쩌면 조금 김이 빠질 수도 있을 것 같다.
결국 정보는 소소한 대화에서 나오는 부산물이지, 각잡고 만들어 내는 것이 아니라는 결론에 도달했다고 한다.
예를 들면, "아 ㅇㅇ 식당에서 청모했는데 음식 괜찮더라구요"라는 글에서도 정보를 얻을 수 있지만,
이 정보가 "ㅇㅇ 식당 청모하기 좋나요?"라는 질문에서 탄생한 것은 아니다.
방향을 바꿔보자.
가벼운 소통을 많이 하도록 유도하고,
그 대화 데이터를 가공해서 우리가 맥락을 정리하자.
난 이 방향은 듣자마자 굉장히 좋다는 생각이 들었다.
자연스럽게 대화를 유도해서 쌓이는 데이터 베이스에서 맥락을 뽑아 전달하는 게 더 잘 맞는 AI 활용안 같았다.
이 방향에서 다양한 후속 기획이 나왔다고 한다.
입주 공고 사진을 업로드하면 AI가 요약해주고,
채팅 내용을 일일 요약으로 제공하고,
대화를 글로 전환할 수있도록 AI가 문장을 다듬어주는 식이다.
대화를 활성화하고 정보를 잘 축적하는 데 집중하는 전략이었다.
익명 게시판 - 대나무 숲에서 아이디어를 얻다
"아파트 윗집이 시끄러운데... 어디다 말은 하고 싶은데, 신원이 특정될까 무섭고..."
익명 게시판을 만들어보면 어떨까?
프론트 UI는 그냥 게시판이라 금방 만들지만, 서버는 익명 처리를 어떻게 하지?
제대로 만들면 백엔드 구현에 2-3주를 태워야 할 것 같은데, 이게 너무 아깝다.
제대로 만들면 작성자/댓글 익명 처리, 프로필 노출 방지, 알림 처리 등 복잡한 서버 작업이 필요하다.
스펙을 줄이고 줄여서, AI와 n8n으로 해볼 수 없을까?
대나무숲이라는 것이 있다.
계정주에게 글을 보내면, 계정주(제3자)가 글을 게시해주는 방식이다.
나는 이때도 오! 좋은 생각이다라는 생각이 들었다.
서버에서 각잡고 익명 게시판 로직을 만드는 것보다,
그냥 게시자 계정을 하나 둬서 간접적으로 익명을 만드는 게 구현이 더 간단하니까.
역시 좋은 기획은 시행착오에서 나오는구나.
Front에서 익명의 글을 쓰면, LLM으로 정책 위반 여부를 확인하고, 대나무 숲 계정으로 게시물을 발행한다.
n8n 워크플로우를 적극 활용해서 백엔드 로직을 만들었다고 한다.
n8n은 BigQuery, 배치잡, Slack 메시지 등 다양한 플러그인을 제공하고,
AI로 쉽게 코드를 생성할 수 있으며, UI 기반이라 비개발자도 수정이 가능하다.
결국 14일 예상 작업이 1일로 줄었고, 빠르게 유저 니즈를 확인했다고 한다.
SSR 기반 렌더링 서버를 API 서버로 활용하고, DB에 직접 접근하는 등
프론트엔드에서 빠르게 검증한 뒤 서버로 이전하는 방식을 취했다.
제품 검증을 위해 직무 경계를 넘나든다.
PE로서의 성장
[반복 학습을 통한 제품 직감력]
가설을 세우고 부딪히고, 사용자 데이터를 얻어낸다.
가설 - 실험 - 데이터 - 학습 - 가설 ...
결국 실패할수록 직감이 강해진다.
많은 실패를 해봐야 한다.
프론트엔드 엔지니어로서 기획 이해, 개발, 배포, 이벤트 책임은 기본이고,
여기에 결과 분석, 유저 데이터 흐름 추적, 새로운 아이디어 도출이라는 무한 루프를 구축하게 된다.
[직무 경계를 넘어서]
제품 리드가 되며 엔지니어 개인 성장보다 팀 목표와 지표 달성을 우선으로 두게 되었다.
FE 엔지니어링의 정의가 기술적인 목표보다는 팀의 목표를 달성하는 것으로 변화했다.
이렇게 직무 경계를 넘어서 많은 시도를 하면서
속도를 높이고, 시야가 넓어지며, 제품과 기술적 트레이드오프에 대한 설계 능력이 올라갔다고 한다.
좋아하는 것과 책임지는 것은 다르다
과거에도 제품을 좋아하고, 창업을 시도하고, 아이디어를 제안하며 적극적으로 참여해왔고 한다.
하지만, 좋아하는 것과 책임지는 것은 완전히 다르다.
그 책임의 부담 속에서 본래의 직무를 넘어서 데이터 분석, 빠른 실행, 틀 벗어나기 같은 시도를 하게 됐다고 한다.
현재는 이 경험을 팀원들과 공유해서,
모든 팀원이 1인처럼 일하며 제품에 기여할 수 있는 환경을 만들고,
누구나 필요한 것을 만들고 데이터를 분석하며 원하는 지표와 성과를 낼 수 있는 환경을 조성하는 것을 목표로 하고 있다고 한다.
이 세션이 굉장히 인상깊었고, 직접 손을 들어 질문을 했다.
아래는 내 질문과 연사자분의 답변이다.
Q. 제품을 빠르게 MVP로 검증한 후 '작동한다'라고 판단해서 실제 제품 수준의 설계로 마이그레이션하는 판단 기준이 궁금하다.
MVP를 아무리 n8n으로 짠다고 해도, 마이그레이션 가능한 수준을 고려해 설계했다고 한다.
기획하다 보면 "잘될 것 같다"라는 직감이 드는데, 그런 제품들은 조금이라도 잘되는 낌새가 보이면 바로 옮겼다고 한다.
Q. 직감이라 함은 추상적이면서도 기획에서 중요한 부분 같다. 어디에서 얻는 편인가?
실패를 통해 얻는다. 이번에 거의 50번 실패한 것 같다.
인상 깊었던 다른 질문도 있다.
Q. 엔지니어와 PM 마인드셋에 대한 괴리감은?
애매하게 하면 커리어가 꼬인다! 할 거면 끝까지 해보자! 라는 마음이었다고 한다.
AI를 통해 엔지니어로서 시너지를 내면서 부족한 제품 결정력을 높이는 방향으로 가고 있다고 한다.
제품 중심 엔지니어로 발전하려면, 제품에 관심을 가지고, 목적과 의도를 이해하고, 의견을 적극 제시하고,
작은 것부터 성과를 내며 신뢰를 쌓아가는 것이 중요하다고 했다.
유사한 나의 경험
최근 나는 배포한 기능의 데이터와 액션 로그를 매일 분석해봤다.
사실 나는 내가 만든 기능을 유저들이 쓰는 게 좋아서 개발자가 된 사람이다.
배포 직후 바로 DB 켜서 10초에 한 번씩 새로고침하며 늘어나는 row를 보는 게 내 취미일 정도.
그 전부터 해보고 싶었는데, mongoDB는 쿼리를 치기 좀 까다롭고, 리대시는 보기 불편해서 좀 장벽이 있었다.
그런데, 이번에 배포한 기능은 RDB라 쿼리 조회가 쉬웠고,
또, 비슷한 시기에 회사에서 Databricks를 도입하며 사용법 세션을 열었는데, 꽤나 쓰기 쉬웠다.
Claude가 짜준 Query로 조회한 데이터를 다시 Claude에게 먹여서 차트를 뽑고,
Databricks로 분석하고 싶은 내용을 자연어로 입력해 데이터를 뽑기도 했다.
그렇게 발견한 인사이트는 '배포 3일 이후부터 떨어지는 진입율과 복귀율을 높이기 위해 넛지 구현이 필요하다'는 것이었다.
팀에 이 차트를 바탕으로 해당 제안을 레이징해서 바로 구현+배포를 했고,
배포 직후 바로 유저의 복귀율을 4.4배 올릴 수 있었다.
FE 개발자가 데이터를 독자적으로 분석해 결론을 도출하고, 실제로 성과로 증명한 것이다.
유저가 만나는 화면을 개발하는 FE 개발자는 결국 데이터 드리븐한 사고를 해야하는구나, 그런 생각이 들었다.
사실 작년 초 입사 직후 내가 자발적으로 맡았던 가장 큰 아젠다가
엑셀 시트의 200개 이상의 로깅 중 누락된 것이 있는지 하나씩 검증하고 수정하는 것이었다.
기능 개발 사이 짬을 내어 꼬박 2주 동안 꾸준히 30개씩 누락 점검을 해서 데이터 로깅 정합성을 잡았다.
그리고 그 이후로 자연스럽게 로깅에 대한 오너십(?)이 생겨서 다른 스쿼드에 로깅 세팅을 알려주고 문서화하기도 했다.
그리고, 결국 그게 발전하고 발전해서 로깅 병목을 해소하기 위한 FigLog(로깅 플러그인)를 만드는 결과로 이어졌던 것 같다.
시작은 우연으로부터.
[로깅, 엑셀 시트 말고 Figma에서 하면 안 되나? - FigLog 개발기] https://developer-dreamer.tistory.com/232
마무리하며
세 세션은 모두 결국 같은 이야기를 하고 있었다.
AI가 구현을 빠르게 해주는 시대에
엔지니어의 가치는 맥락을 이해하고, 문제를 정의하고, 끝까지 책임지는 것에 있다는 것이다.
코드를 짜는 속도가 아니라, 무엇을 만들어야 하는지 판단하는 능력.
그게 Product Engineer라는 말의 본질인 것 같다.
네트워킹에서는 당근과 오늘의집 FE/BE분들을 만나 이야기를 나눴다.
각자 업무에서 AI를 어떻게 쓰고 있는지, 사이드 프로젝트에는 어떻게 쓰고 있는지 교류했다.
거의 1시간 이상 이야기를 했는데, 나올 때는 교보빌딩 앞문이 잠길 정도로 늦은 시간이었다.
오랜만에 생동감있는 대화를 하고 나니 뭔가 살아있는 느낌이 들었다.
역시 주기적으로 네트워킹을 해야한다...
그리고 세션을 들으며, 세션 내용과 비슷한 내 경험들이 떠올랐다.
문득 다음엔 내가 이 자리에서 정보를 공유하는 입장이 되어보고 싶다는 생각이 들었다.
네트워킹 시간 후 퇴장을 하다 마주친 Arawn님께 조금 고민하다 질문을 드렸다.
그런데, 외부 연사자로도 세션을 꾸려볼 생각이라고 말씀해주셨다.
오! 뭔가 두근두근 마음 속에서 끓어오르는 느낌이 들었다.
작성: 2026.03.27 22:39
'개발 컨퍼런스' 카테고리의 다른 글
| [토스 컨퍼런스] TOSS MAKERS CONFERENCE 25 후기 (1) | 2025.10.09 |
|---|---|
| [FECONF25] 플러그인 시스템 기반의 유연한 React Native CodePush 대안 (0) | 2025.09.14 |
| [FECONF25] 개발자를 위한 모션 그래픽 솔루션: Lottie의 기술 진화와 활용전략 (1) | 2025.08.31 |
| [FECONF25] 모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년 (4) | 2025.08.30 |
| 토스 개발자 컨퍼런스 SLASH24 (7) | 2024.09.02 |
