우아한형제들에서 개최하는 웹프론트개발그룹 오픈 밋업 1회차에 참석했다!
이번의 참석 계기는 다른 때와는 조금 달랐다!
이 밋업 신청을 할 때 연사자 신청도 할 수 있었는데, 난 용기있게 연사자 신청을 해봤다
(난 1년차지만 그런거 굴하지 않아!!!!)
신청 내용은 figlog 개발기였다.
https://developer-dreamer.tistory.com/232
로깅, 엑셀 시트 말고 Figma에서 하면 안 되나? - FigLog 개발기
Part1. 시작 - 두 갈래의 질문시작은 코드 리뷰였다. 새 레포에 로깅 인프라를 세팅하는 PR을 올렸더니,같은 팀 프론트엔드 동료가 리뷰 코멘트를 남겼다.매번 eventName, placement를 한땀한땀 넣는 거
developer-dreamer.tistory.com
그냥 얌전히 참석자 신청만 할까...아니면 그래도 도전해볼까 고민하다가
마감 마지막 날에 자정을 1시간 앞두고 '에라잇!!'하고 제출 버튼을 눌렀다.
아쉽게도 연사자 선정은 안됐었다.
그런데!!! 연사 신청 내용이 정말 인상깊었다면서,
웹프론트엔드그룹장 마광휘님께서 직접 초대장을 보내주셨다!!!!!!!
그렇게 참여하게 되었다
역시 망설여질 때는 그냥 눈 딱 감고 도전하는 게 또 새로운 기회를 열어준다.
오프닝 - 웹프론트개발그룹장 마광휘님
"왜 우리는 밖으로 나왔는가"
기존에도 우아한 형제들은 우아콘을 중심으로 외부와 소통을 해왔다. 하지만, AI 시대 변화 속도가 너무 빨라서 조금 더 자주 외부 인원과 만나서 인사이트를 자주 공유해야 겠다는 판단을 했다고 한다.
외부 개발자로부터 AI 관련 인사이트를 얻고, 네트워킹을 통해 채용까지 이어지는 그림을 그리고 계신다고 했다. (ㅎㅎ)
입장 시 받은 기념품은 단순 키링이 아니라고 하셨다. 아, 혹시 NFC인가?했더니 진짜였다.
태깅을 하니 바로 채용 사이트가 떴다 (ㅋㅋㅋ)
밋업 준비 과정 자체도 AI를 최대한 활용해서 슬라이드, 운영 시스템, 이미지까지 99% 다 만들었다고 한다.
하지만, 1%를 남겨둔 이유, AI가 완전히 대체할 수 없는 그 영역.
'우리의 취지'를 드러내기 위해서라고 했다.
이 오픈 밋업은 분기마다 개최할 예정이며,
7~8월에는 배민의 웹/앱 디자인 시스템을 주제로 두 번째 오픈 밋업을 진행할 예정이라고 한다.
내가 책상을 떠나도 코드는 돌아간다 - 송요창님
부러움에서 시작된 질문
X(트위터)는 실리콘밸리 개발자들이 아침에 세션 5~8개를 열어놓고 자동으로 돌린 후 밤에 리뷰를 한다고 한다.
요창님은 이게 너무 부러웠다고 한다. 내가 없을 때도 일이 돌아가게 하려면 어떻게 해야할까?
AI 모델의 성능은 계속 좋아진다.
낯선 레거시 코드도 빠르게 읽어주고, 크롬 익스텐션도 바이브 코딩으로 뚝딱 만들어낼 수 있다.
하지만 여전히 남은 문제는 '우리가 책상에 없으면 스스로 돌아가지 않는다는 것'이다.
무식하게 시작했더니 망했다
단순히 클로드 코드를 반복 실행하는 스크립트를 짰다. 결과는? 예상대로 좋지 않았다.
루프를 돌 때마다 기억을 잃고, 실패 사유를 보고하지 않고, 중간에 멋대로 끊겨서 일을 완수하지 않는다.
'일 값은 받아가는데 보고는 안해, 완수도 안해, 코딩 컨벤션도 매번 까먹어'
어떻게 보면 '정말 위험한 신입 개발자'가 된 셈이다.
석촌호수 마구간
(*젤다에 나오는 마구간이라는 개념이 있다.
마구간은 근처의 지역명을 따서 지어지고, 그래서 본사 근처의 석촌 호수를 따서... 석촌호수 마구간)
(설명을 듣고 뒤늦게 눈치채서 반응하지 못했다... 죄송ㅠㅠ)
요창님의 결론은 명확했다.
'에이전트를 더 잘 쓰는 게 아니라, 에이전트를 위한 환경을 만드는 게 중요하다.'
코드 작성과 리뷰를 분리했다.
만드는 에이전트와 리뷰하는 에이전트를 따로 두고, 크리티컬한 이슈는 즉시 수정하도록 했다.
모노레포 환경에서 엉뚱한 앱을 수정하는 문제는 워크트리로 격리해서 해결하고, 태스크가 유실되는 문제는 REST 큐에 담아 관리한다.
플래닝 단계에 사람의 승인을 넣는다.
처음에는 에이전트가 2분 만에 '이거 맞나요?'라고 물어보고 검토하기 전에 넘어가버렸다.
이제는 드래프트 PR을 올리면 사람이 '괜찮네'라고 승인을 해야 진행한다.
리뷰 단계의 중요성
'자기가 만든 결과물을 평가하라고 하면 에이전트는 그 결과를 칭찬하는 경향이 있다.'
- Anthropic 연구 결과 인용
그래서 '실패를 흡수하고 다시 극복하게 만드는 매커니즘이 중요하다고 했다.
실제 시연과 병렬처리의 힘
플래닝에 1분 25초, 전체 약 6분 소요.
사람이 코드 리뷰 두 개를 순차적으로 처리하면 꽤 걸리지만,
에이전트 2개를 동시에 돌리니 최장 2분 39초가 걸렸다고 했다.
이렇게 에이전트가 알아서 일을 하는 동안 인간은 자리를 비울 수 있다.
(운동을 하러 갈 수 있다...크흡)
기술 수용 곡선과 조직의 현실
하지만, 새로운 툴을 만들었다고 바로 운영에 반영되진 않는다.
장애 상황에서 코드를 이해할 수 없으면 대응이 가능한가.
기계가 하는 코드 리뷰에 의미가 있냐.
이런 상황에서 요창님은 기술 수용 곡선 개념을 이야기했다.
AI에 관심있는 사람들은 이노베이터와 얼리어답터에 해당하고,
대다수 60%는 검증될 때까지 움직이지 않는다.
구글처럼 큰 회사도 파워 유저 20%, 미사용자 20%, 관망자 60%로 동일한 패턴이라고 했다.
그래사, 내가 제시한 기술의 '가능성'이 아니라
내 기술을 '검증 가능한 흐름'으로 만들어서 실제로 성과를 가시화해서
다른 사람들이 이를 '믿고 사용할 수 있도록' 하라고 했다.
그리고, 그 '검증 가능한 흐름'이 될 때까지...
내가 만든 새로운 '기술'이 하는 이상한 짓들 정도는 좀 감수하자...고 하셨다.
AI 시대, 디자인시스템은 어떻게 살아가는가 - 이상철님 (디자인 시스템 플랫폼 팀)
3줄 이상 읽으시나요? 안 읽거든요~
디자인 시스템은 본질적으로 합의의 연속이다.
사용처 개발자, 디자인 시스템 개발자, 디자이너가 논의하는 과정에서 방대한 문서가 생긴다.
하지만... 문서를 만들면 뭐하나... 사람은 이 텍스트 덩어리의 고작 20% 밖에 읽지 않는다.
F 패턴으로 첫 줄 한 번, 쭉 내려가다, 중간에 한 번.. 또 한 번... 이렇게 파편적으로 읽는다.
그리고 이건 작년 말에 나에게 발생했던 일인데...
대학교 개발 동아리에 맨 위 3줄에 허위 사실 써놓고, 10번째 줄에서 그 사실이 거짓이라는 본문을 썼는데,
개발자 친구들은 모두 위 3줄만 읽고 '엥??? 진짜임?'이라고 슬랙에 댓글을 남겼다.
ㅋㅋ;; 아무튼 방대한 문서는 서로에게 좋지 않다.
사용처를 사람이 아닌 AI 에이전트로 재정의하자
AI 시대가 되면서 사용처의 패러다임이 전환됐다.
사용처 디자이너는 클로드 디자인으로, 개발자는 클로드 코드로 작업한다.
디자인 시스템은 사용처를 사람이 아닌 'AI 에이전트'로 봐야 한다.
에이전트를 위한 디자인 시스템 구축에는 세 가지 포인트가 필요하다.
맥락의 정제, 코드의 개방, 패턴의 제공
에이전트 서버 구축 - 흩어진 데이터를 한 곳으로
LangChain 기반의 Nest 서버를 구축하고, 아마존 Bedrock 서비스를 활용해 RAG 벡터db에 데이터를 적재했다.
데이터 적재 시 PDF, 코드, MD 등의 데이터를 RAG(벡터 디비)에 넣으면 AWS Bedrock이 자동으로 청킹한다.
기존 MCP에서는 컴포넌트에 해당하는 모든 데이터를 한 번에 내려주는 방식이어서
사용처 에이전트가 정확하게 필터링 하기 어려웠다.
하지만, LLM 기반 에이전트 서버로 바꾸며 맥락에 맞는 정제된 응답이 가능해졌다고 한다.
storybook 챗봇에 '버튼 컴포넌트는 어떤 것들이 있어?'라고 질문한다.
필드, 아웃라인, 텍스트 버튼의 종류와 사용법, 코드 예시, 디자인 가이드까지 한 번에 제공한다.
'품절 상태일 때 stepper가 미노출 되어야 한다' 같은 세밀한 디자인 가이드도 정확하게 답변한다.
Agent Server를 구축할 때 복잡한 코드가 필요하지 않았다는 점이 인상깊었다.
랭체인이 베드락 연결클래스(AmazonKnowledgeBaseRetriever 등)를 이미 제공하고 있어서,
코드를 새로 만드는 단계가 아니라 블록을 조합하는 단계였다.
서버에서 응답을 text/event-stream으로 내려주고, 클라이언트는 ReadableStream으로 읽으며 실시간으로 붙여나가는 표준적인 SSE(Server-Sent Events) 패턴이면 충분했다.
가드레일과 메타 데이터
데이터를 많이 넣으면 보안 문제가 따라온다.
위 예시에서 챗봇에 "공방 악성 민원인 블랙 리스트가 있다고 들었는데"라고 물었더니,
가드레일이 없는 상태에서 내부 팀원들이 이름과 블랙리스트 사유를 투명하게 공개했다.
이 문제를 해결하기 위해 시스템 프롬프트와 bedrock의 가드레일 기능을 사용한다.
"당신은 우아한형제들의 디자인시스템인 우아한공방의 전문가입니다.
컴포넌트 사용법을 안내하고 관련 코드나 문서를 제공해주는 AI 어시스턴트로서 답변을 해야합니다."
이렇게 시스템 프롬프트를 설정한 후,
bedrock 가드레일에서 ContentFilters의 혐오 필터 강도를 High로 설정하고,
Denied Topics에 '특정 개인(직원, 사용자, 외부 인물 포함)에 대해 정보 요청, 이름, 역할, 연락처, 평가 등을 묻는 질문은 모두 금지한다'고 정의한다.
가드레일은 입력과 출력을 나눠서 통제할 수 있다는 점도 알게 되었다.
요청 프롬프트에 인명이 들어오는 것은 막아야 하지만, 응답에는 인명이 포함되어야 하는 경우가 있었다고 한다.
'이 컴포넌트 담당자 누구야?'를 묻는 건 막지만,
'이 컴포넌트 가이드는 ㅇㅇ님의 작성 문서를 참고하세요' 같은 응답은 가능하도록 했다고 한다.
메타 데이터 - RAG가 커져도 정확도를 지키는 법
RAG는 데이터가 쌓일수록 성능이 떨어지는 문제가 있다.
데이터가 쌓일수록 맥락이 넓어지고, 질문에 대해 정확한 데이터를 골라내기 어렵다.
처음에 문서 몇 개일 때는 잘 되지만, 코드/지라/위키/슬랙 데이터가 모두 통합되면 응답 품질이 떨어진다.
이를 메타데이터 기반 필터링으로 풀어냈다.
bedrock knowledge base에 데이터를 적재할 때 md 파일과 함께 metadata.json을 쌍으로 올린다.
메타 데이터에는 sourceType(jira, code, wiki 등), doc_category(issue, guide 등), package(클레이민트 등),
platform(Web, iOS 등), component(Stepper, Button 등) 같은 키가 정의되어 있다.
쿼리 시점에 AmazonKnowledgeBaseRetriever에 메타데이터 키를 지정하면,
전체 데이터를 뒤지는 게 아니라 해당 카테고리의 데이터만 필터링해서 검색한다.
이렇게 하면 '특정 컴포넌트 적용법'을 질문했을 때,
슬랙 대화나 지라 이슈가 아니라 해당 컴포넌트의 코드와 디자인 가이드 문서만 정확히 가져올 수 있다.
코드 리뷰부터 프로토타이핑까지 - 디자인 시스템은 가속기다
Cursor에 '이 코드가 우형 공방의 디자인 가이드를 잘 따르고 있는지 검사해줘'라고 요청한다.
MCP가 호출되어 Haptic 미적용 같은 이슈를 감지하고, 수정 코드까지 자동으로 제안한다.
PM이 클로드 데스크탑에서 '공방 디자인 시스템을 활용해 프로토타입을 구성해줘'라고 하면
실제로 공방의 시맨틱 토큰과 컴포넌트를 활용한 결과물이 나온다.
"AI 시대의 디자인 시스템은 가속기다. 그리고, 맥락과 패턴이 이를 뒷받침한다."
AI로 완성하는 고객 여정 대동여지도 - 이재희님
화면을 만드는 사람은 화면 밖 고객을 이해해야 한다
올해 초 새로운 부서로 이동하며 재희님은 신규 유저 확보와 이탈 유저 복귀라는 목표를 잡았다.
문제는 타겟 고객이 이 조직에서 만드는 화면을 쓰지 않는 유저들이라는 것이다.
그래서, 재희님은 이들을 이해하기 위해 데이터를 직접 보기 시작했다.
처음에는 LLM에게 로그 스키마를 보여주고, 바로 SQL을 생성시켰다.
하지만 자꾸 에러가 발생해서 분석을 이어나가기 어려웠다.
나도 최근에 databricks로 쿼리 생성 및 분석을 시도하고 있는데
데이터 탐색 범위를 제대로 짚어주지 않으면 방대한 쿼리를 생성해 스캐닝을 시도하다 타임아웃으로 자주 실패했었다.
비슷한 사례인지는 잘 모르겠지만, 뭔가 저 사진 한 장 너머로 느껴지는 고통에 공감이 됐다.
용병 3명을 고용하자
DA, BE, FE 에이전트 셋을 고용해 전반적인 데이터 분석 대시보드를 구축했다고 한다.
1. DA 에이전트
datahub MCP로 테이블을 조회하고, trino mcp로 쿼리를 실행한다.
서비스 코드, 파티션 키 차이 같은 도메인 지식은 스킬과 룰로 학습시킨다.
예를 들어 "4월 한 달간 B마트에서 처음 주문한 신규 고객의 세그먼트 통계를 추출해줘"라고 질문하면,
여러 쿼리를 조합해 인사이트를 제공한다.
하지만, 토큰을 많이 쓰고, MCP 실행 결과가 캐싱되지 않고, 쿼리를 실행 가능한 형태로 저장하지 않는 문제가 있었다.
2. BE 에이전트
DA 에이전트가 만든 쿼리를 Redash 같은 데이터 집계 도구에 API로 등록하고 캐싱을 제공한다.
Redash MCP를 직접 만들어서 쿼리 업로드도 자동화한다.
3. FE 에이전트
Redash 대시보드는 독립된 쿼리들의 나열이고, 마크다운 문서는 인터랙티브 하지 않는 문제가 있다.
Redash 대시보드와 마크다운 문서의 장점을 합치기 위해 FE 에이전트를 도입했다.
드롭다운에서 "40대 여성"을 선택하면 그 값이 다음 쿼리의 파라미터가 되어 검색어 Top10이 나오고,
거기서 "아이스크림"을 고르면 구매 전환율과 장바구니 이탈률이 나오는 구조이다.
<쿼리 체이닝>이 가능하게 되는 것이다.
이후 실제 FE 에이전트가 만든 대시보드도 보여주셨다.
실제 배민 내부 데이터와 연관되어 있어서 공개적인 글에 언급하긴 어렵지만,
고객의 구매 여정을 처음부터 끝까지 따라가는 체인 형태의 flowchart가 인상깊었다.
이 세션을 들은 후, 실무에서 바로 우리 고객의 flowchart를 만들어서 팀원들에게 공유했다.
(팀원들은 이제 이런 데이터 차트까지도 만들 수 있냐며 긍정적인 반응을 보였다.
아무래도 난 원래 FE 개발자니까...ㅋㅋ)
항상 내가 개발한 기능이 처음 기획에서 세웠던 가설에 맞게 실제로 연속 구매 행동이 일어나고 있는지 궁금했었다.
이 세션에서 얻은 아이디어 덕분에 구매 데이터와 플레이 데이터를 각 유저별 시간순으로 조합해 금방 flowchart를 만들 수 있었다.
고객에 대한 이해도와 UX 해상도를 높이는 좋은 계기가 되었다.
1년 전까지만 해도 개발 세션을 들으러 다니면 '오우 정말 멋진 기술인걸'이라는 생각은 바로 드는데,
'이걸 그래서 어떻게 따라하지'라는 생각이 드는 순간 벽이 느껴졌었다.
하지만, AI가 급속도로 발전함에 따라 세션에서 주워듣는 아이디어 조각들을 기억해두기만 해도,
실무에서 얼추 비슷하게 구현할 수 있는 시대가 된 것 같다.
얼마 전 링크드인에서 어떤 조각글을 봤던 기억이 떠올랐다.
'이제 좋은 아이디어를 가진 사람들은 입을 다물게 되었다.
AI가 발전함에 따라 아이디어가 비싸지고 실제 액션이 싸졌기 때문이다.
아이디어만 알면 구현하는 건 어렵지 않아졌다.'
중간 휴식을 가진 후, 외부 연사 세션이 시작되었다!
AI 시대, 리팩터링은 더 이상 노가다가 아니다 - 최원섭님(레몬베이스)
Strawberry의 r은 몇 개인가?
AI는 방대한 지식을 즉시 활용하거나, 반복 작업의 초안을 빠르게 생성하는데 능하다.
하지만, AI는 본질적으로 확률을 기반으로 동작한다는 치명적인 단점이 있다.
Strawberry에 r이 몇 개인가요?라는 질문에 매번 다른 응답을 내놓는다.
50m 거리의 세차장은 걸어가는 게 나을까요?라는 질문에 53개의 모델 중 42개의 모델이 그렇다고 대답한다.
(세차장은 차가 있어야 하므로 아무리 가까운 거리라도 차를 타고 가야하는데도 불구하고...)
따라서, 확률적인 추론을 하는 AI가 매번 정답을 내놓기를 바라는 것보다
매번 같은 답을 내놓는 함수를 AI로 만드는 편이 더 낫다.
AI에게 코드를 고치라고 하지 말고, 코드를 고치는 도구를 만들게 하라
레몬베이스의 사내 디자인 시스템에는
시맨틱 컬러를 주입하는 레거시 방식과 Tailwind 클래스명을 사용하는 새로운 방식이 수백~수천 개 파일에 공존하고 있었다.
보이스카우트 룰로는 한계가 있었다.
리팩토링은 항상 우선순위에서 밀리고, 자주 수정되는 모듈만 깨끗해진다.
대규모 정리 PR은 리뷰 책임이 모호했다.
AI에게 직접 시켰더니 15~20분 만에 수십 개의 파일이 바뀌었다.
하지만, 두 가지 벽에 부딪혔다.
컨텍스트 한계 - 수백 개 파일을 LLM에 전부 넣을 수 없었고, 쪼개면 일관성이 깨진다.
검증 비용의 한계 - AI가 대량으로 수정한 코드는 사람이 작성한 것보다 더 의심하게 되어 오히려 시간이 늘어난다.
이때 동료 엔지니어 조언이 전환점이 되었다.
"R을 세도록 요청하지 말고, R을 세는 함수를 만들게 하세요"
확률적인 작업을 AI에게 시키는 것보다,
AI가 결정적인 도구를 만들게 하고 그 도구를 실행하는 게 훨씬 낫다.
이 조언은 다른 회사의 FE 개발자인 나에게도 꽤 영향력있는 조언이 됐다.
AI가 만든 결과물을 어떻게 신뢰할 수 있는가?에 대한 고질적인 질문에 대해 고찰하는 계기가 되었다.
코드모드: AST 기반의 결정적 변환
코드모드(Codemod)는 코드를 조작하는 코드이다.
문맥을 이해하는 고급 Find & Replace이다.
AST(추상 구문 트리)를 기반으로 동작하기 때문에 입력이 같으면 항상 같은 출력을 보장한다.
역할을 셋으로 나눈다.
AI - 패턴을 분석하고 코드모드 변환 로직을 작성한다.
코드모드 - AST 기반으로 결정적 변환을 실행한다.
사람 - 5%의 예외 케이스만 판단한다.
전수 조사부터 검증까지 5단계 프로세스로 진행한다.
1단계 - AI를 이용해 Before/After 명세를 작성한다.
2단계 - 예외 케이스를 파악한다.
3단계 - 코드모드를 작성한다 (테스트 포함)
Dry Run으로 사전 확인하고, 변환을 실행한다.
AI에게 "타이포그래피를 Tailwind로 바꿔줘"라고 하면 누락되는 부분이 있지만,
Before/After 매핑 파일(MD)을 함께 전달하면 훨씬 좋은 코드모드 스크립트가 나온다.
리뷰 방식의 전환
기존에는 마이그레이션 pr을 확인할 때 수백 개의 파일의 모든 diff를 봐야 했다.
같은 패턴이 반복되니 휙휙 넘기다 놓치는 경우도 많았다.
하지만, 코드모드 방식에서는 테스트의 input/output, 핵심 변환 로직만 리뷰하면 된다.
리뷰어의 피로도는 줄고, 패턴에 대한 이해도는 올라간다.
이에 대한 부수 효과로
코드 일관성 확보, 온보딩 비용 감소, 다음 마이그레이션을 위한 노하우 축적이 있었다고 한다.
또, 팀 동료들도 코드모드를 자신의 작업에 가져다 쓰기 시작하며 전사에도 긍정적 영향력을 끼쳤고
백엔드 팀에서도 대규모 테스트 코드 최적화에 활용했다.
단, 이에 대한 단점도 있었다고 솔직하게 말씀하셨다.
여전히 인간이 수동으로 작업해야 하는 영역이 있으며,
AST라는 개념에 대한 진입 장벽으로 러닝 커브가 존재한다.
또, 마이그레이션 과정에서 conflict 관리가 매끄럽지 못했다고 했다.
AI에게 100번 시키는 게 아니라 한 번 쓸 도구를 만들게 시키자
이 마지막 슬라이드가 나에게 꽤 큰 영감을 줬다.
AI에게 "이거 대충 해줘"라고 하는 게 아니라,
"A 작업을 하려면 B 형태로 자동화 구조를 짤 수 있다"라는 것까지 인간이 사고를 마친 후
"이 자동화를 위한 도구를 짜줘"라고 AI에게 시킨다.
내가 요즘 경계하는
"당신 혹시 AI에게 생각을 외주 주고 있진 않나요?"를 다시 한번 상기하는 계기가 됐다.
PM이 AI로 프론트엔드를 어디까지? - 정덕범님 (LINE Planet PM)
LINE Planet
라인플래닛은 라인의 통화 기능을 다른 서비스에서 쓸 수 있도록 솔루션화한 SDK 제품이다.
PM인 덕범님은 이 제품을 어떻게 설명할지 고민하다가,
라인 LIFF(웹뷰) 위에서 동작하는 데모 앱을 직접 AI로 바이브코딩 해보기로 했다.
PM의 작업 프로세스
먼저 유저 플로우부터 살펴보기로 했고, PlantUML로 전체 흐름을 시각화했다.
라인 로그인 -> 룸 이름 입력 -> 카메라/마이크 권한 체크 -> 프리뷰 -> 통화 -> 종료
이 플로우가 AI든 엔지니어든 QA든 이해하기 쉬운 공통 산출물이 된다.
플로우에서 핵심 페이지 9개를 뽑고,
각 화면의 와이어프레임 생성 프롬프트를 클로드에게 요청했다.
싱글 페이지 단위로 다운받아 프로덕션 코드에서 다음 단계를 진행하는 게 팁이라고 한다.
마크업 뿐 아니라 인터랙션까지 잘 처리해줘서 기대 이상이었다고 한다.
99.9%가 그대로 프로덕션에
PM의 레포지토리와 엔지니어의 프로덕션 레포지토리를 분리하기로 했다.
엔지니어는 "동작하는 것 정도는 참고하고 코드를 리라이트하겠다"고 했으나,
결과적으로는 프론트엔드 코드는 99.9%를 그대로 사용했다고 한다.
(간단한 레이아웃 UI는 사실 바이브코딩으로 만들어도 유지보수가 가능한 수준으로 나오기 때문이 아닐까 싶었다.)
엔지니어는 플랫폼 킷 엔진, 로그인 로직, 백그라운드 블러 같은 기술적 깊이가 필요한 기능을 구현했다.
챌린지와 교훈
웹뷰 디버깅이 처음이라 헤맸고(Eruda 라이브러리로 해결),
AI 자동화 테스트는 웹뷰 환경에서 어려웠고,
LIFF 플랫폼에서 WebRTC 호환 이슈도 발견했다.
SDK를 AI가 잘 모르기 때문에 모범 사례 (워킹 레포지토리, 사내 NPM 문서)를 충분히 제공하는 것이 중요했다.
(이건 자체 DS 시스템을 AI에 잘 먹이기 위해 노력했던 두 번째 세션과도 비슷한 내용인 것 같다.
사내 자체 라이브러리는 오픈소스가 아니기 때문에 정보 기반을 잘 쌓는 게 중요하다.)
PM이 만든 이 데모가 1회성이 되지 않도록 유지보수 전략도 제시했다.
PM이 만든 레포지토리가 Readme이자 사양서 역할을 하게 되었고,
다국어 네이밍 컨벤션도 AI로 공통화했다.
피그마 Dev Mode 대신 이 레포지토리를 직접 참고하도록 전환했는데,
다른 플랫폼(Android, iOS) 엔지니어들이 테스트해보니 품질 차이가 거의 없었다고 한다.
그래서 PM이 만든 이 결과물은 뭘까?
덕범님은 본인이 만든 결과물을 기획서와 개발의 중간 어디쯤으로 묘사했다.
아마 좀 더 인터랙티브한 기획서라고 표현할 수 있지 않을까? 그런 생각이 들었다.
밋업이 끝난 후 링크드인에서 덕범님이 올리신 본 발표 관련 포스팅을 발견해서 링크도 함께 걸어두겠다.
👉'우형 FE 밋업' 행사 발표에서 못다한 이야기 - 정덕범님 링크드인
네트워킹
강연이 끝난 후 9시 반이 되었다.
연사자분 중 요창님께 질문을 드리고 있었는데, 우연히 광휘님이 테이블 근처를 지나고 계셨다.
헉!! 황급히 인사를 드리며 초대해주셔서 감사하다고 말씀드렸다.
광휘님이 '주니어 연차에 이 정도의 깊은 인사이트를 가지고 있어서 놀랐다'며
내 연사 신청 글에 대한 감상을 짧게 말씀해주셨다.
사실 그게 정말정말 기뻤다.
진짜 내 연사 글에 감명을 받아 초대장을 보내주신거라니!!!!
앞으로도 더 열심히 해야겠다는 생각을 했다.
일반 참가자 테이블 쪽으로 내려가 대화를 나누다보니 어느새 11시 반이 되어 있었다.
그 과정에서 대학 후배가 일하고 있는 회사의 동료분도 만나고,
3년 전 부산에서 열린 정션 아시아 해커톤에 참가하셨던 분도 만났다.
(나도 그 해커톤에 참가했으니 어쩌면 우연히 지나가다 마주쳤을수도 ㅎㅎ)
역시 세상은 참 넓으면서도 좁다는 생각이 들었다.
그리고, 지금의 인연이 어디까지 닿을지 모르니 항상 행동거지를 바르게 해야겠다는 자각도 다시 한번했다...
롯데타워가 자정에 강제 소등이 되기 때문에 지금 바로 퇴장해야 한다고 하여, 아쉬움을 뒤로하고 건물 밖으로 나왔다.
(그리고 그때까지도 꽤 많은 사람이 남아 있었다! 역시 밋업의 꽃은 네트워킹이다.)
사실 건물 밖으로 나오는 중에도 나는 추가 네트워킹을 진행했다. 하하.
그리고 그게 나에게 엄청난 도움과 인연으로 이어졌다. 정말 감사합니다!!
역시 기회는 도전하는 자에게 닿는 것 같다.
네트워킹 때 저와 대화 해주신 모든 분들께 감사드립니다!
덕분에 많은 인사이트 얻고 성장할 수 있었습니다 ㅎㅎ
기회되면 또 뵈어요!!!
마무리하며
다섯 개의 세션을 전부 정리하려다보니 업로드 기한이 꽤 미뤄졌다.
밋업은 4월 24일이었는데, 6월 1일에 업로드하다니... 대지각생
사실 나는 우아한형제들 본사에 가본다는 것 자체가 정말 좋은 경험이었다.
매일 법카를 배민에 연결해서 시켜 먹으면서도, 이 본사가 잠실에 있을 거라는 생각은 안해봤으니...
회사가 롯데타워에 있고 무려 창밖으로 석촌호수가 보인다는 사실 자체가 정말 쩔었다. 진짜.
그동안 여러 네트워킹에 다니면서 다양한 빅테크 개발자분들을 만났는데,
우아한형제들 개발자분은 이번 밋업을 계기로 처음 뵙게 되었다.
그래서 새로운 관점의 시야를 이번에 많이 얻어갈 수 있어서 좋았다!!
기술적으로 인상깊었던 건 DS의 AI 사용 최적화를 위해 RAG 개념까지 나왔던 두 번째 세션,
아이디어가 인상깊었던 건 데이터를 기반으로 UX를 분석한 세 번째 세션,
나에 대한 성찰을 하게 됐던 건 AI는 확률 기반 추론 도구라는 인사이트를 준 네 번째 세션이었다.
최근 나는 데이터를 자발적으로 분석하기 시작했는데,
우연히 이 시기에 밋업을 듣게 되어 세 번째 세션이 꽤 기억에 오래 남았다.
최근 당근 PEConf에서도 DA가 아닌 직군이 데이터를 보고 새로운 기획적 시각을 얻는 사례를 봤었다.
AI가 발전한 지금, 이제는 누구나 데이터를 볼 수 있는 환경이 되었다.
그 말은 즉슨, 누구나 데이터를 봐야한다는 뜻일수도 있다.
데이터를 보는 개발자가 되기로 했다
나는 유저에 대한 이해도를 높이려면, 유저의 제품 사용 시나리오를 처음부터 끝까지 한 flow로 볼 수 있어야 한다고 생각한다.
이를 위해서는 데이터 로깅을 더 촘촘하게 해야하고, 제품이 출시된 직후부터 유저 행동을 관찰하기 시작해야 한다.
Databricks(자연어 데이터 분석 툴)가 회사에 도입된 후로 최소 내가 개발한 기능은 내가 데이터를 추적하기로 마음먹었다.
작년 토스 컨퍼런스에서 자동 로깅 시스템을 소개한 개발자 두 분은
로깅에 대한 중요성을 알리기 위해 '로깅도 제품이다'라는 사내 캠페인을 진행했다고 했다.
나는 <로깅도 제품이다>라는 문장이 꽤 오래 기억에 맴돌았다.
내가 FigLog라는 제품을 만든 것도 그 문장의 영향으로 볼 수 있다.
로깅 달고 내보내면 끝이 아니다.
진짜 의도한 대로 유저 로깅이 수집되고 있는지 추적해야 하고,
처음에 생각했던 로깅 항목에서 더 보완해야할 부분이 있는지 신경써야 한다.
기능을 내보내고 한참 후에 그제서야 분석하려고 하면, 그건 사후조치 밖에 되지 않는다.
팀의 규모와 인력에 따라 이걸 모두 꼼꼼히 따져서 보완할 수 있을수도 있고,
혹은 그런 리소스조차 허용되지 않을수도 있다.
모든 상황이 이상에 가까울수는 없지만,
그저 주어진 환경에서 더나은 제품을 위해 리소스가 닿는대로 시도해보는 것은 나쁘지 않다고 생각한다.
우리가 새로운 기능을 만드는 데는 리소스가 들어간다.
그리고 그 기능은 유저경험을 증진시키기 위해 만드는 것이다.
그럼 리소스를 효율적으로 사용하려면 유저가 원하는 기능을 만들어야 한다.
그걸 위해서는 유저경험을 가장 잘 보여주는 행동 데이터를 주시해야 한다.
내가 최근 여러 컨퍼런스에서 얻은 인사이트와 실무 경험을 종합해서 내린 결론이다.
컨퍼런스에 가서 많은 이야기를 쏟아내고, 또 많은 인사이트를 쏟아 붓고 나면
뭔가 혈이 뚫리는 것 마냥 기운이 되살아나는(?) 기분이 든다.
역시 엔지니어는 서로 긍정적인 영향을 주고받을 때 생기가 도는 존재 같다. (?)
올해 또 재밌는 컨퍼런스에 참석할 수 있는 기회가 오길 바라며!
작성: 2026.06.01. 01:25
'개발 컨퍼런스' 카테고리의 다른 글
| 당근 PEConf에 다녀왔다 - Product Engineer로 일한다는 것 (0) | 2026.03.27 |
|---|---|
| [토스 컨퍼런스] 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 |
