아임웹에는 두 명의 구성원으로만 운영되는 실험적인 스쿼드가 있습니다. 반복되는 고객 문의 응대부터 주문 관리까지 자동화해, 브랜드가 성장에 집중할 수 있도록 돕는 CS 에이전트 스쿼드입니다. 0에서부터 제품을 만들어야 하는 상황이었지만, 이 스쿼드는 꾸려진 지 3주 만에 첫 제품을 출시했습니다. CS 에이전트 스쿼드의 수민님과 정민님은 작은 스쿼드이기에 오히려 다양한 아이디어를 과감하게 실험하며 일하는 것이 가능하다고 말합니다. 규모의 제약에 갇히지 않고, 직무의 경계를 넘나들며 제품을 만드는 두 사람의 이야기를 들어봤습니다.
- 나수민 | Product Owner
제품이 해결해야 할 고객 문제와 방향성을 정의하고, AI를 활용해 필요한 기능을 직접 개발합니다. - 이정민 | Back-end Engineer
AI와 효율적으로 협업할 수 있는 개발 환경과 기술 구조를 설계하며, 제품 구현 전반을 책임집니다.
고객 문의에 답하고 주문 취소까지 처리하는 CS Agent 화면
Chapter 1. AI 시대, 작은 규모에서 발견한 더 큰 커리어의 가능성
소규모 스쿼드, 오히려 AI를 제대로 활용할 기회
정민 처음에는 다른 스쿼드에 지원했는데, 입사를 앞두고 CS 에이전트 스쿼드 합류를 제안받았어요. 소규모 인원이 AI를 적극 활용해 새로운 제품을 빠르게 만드는 스쿼드가 될 거라고 하셨죠. 제가 AI에 관심이 많고, 업무에도 적극적으로 활용하고 싶어 하는 모습을 보고 제안을 주신 거였어요. 걱정보다는 기대감이 컸습니다. 아임웹에 오고 싶었던 이유도 AI로 하고 싶은 일을 마음껏 해볼 수 있을 것 같아서였거든요. 지금은 AI를 적극적으로 쓰는 회사가 많지만, 그때까지만 해도 AI를 불신하거나 아직 적극적으로 도입하지 않은 회사가 더 많았어요. 아임웹은 이미 AI를 도입해서 매우 활발하게 쓰고 있었고요. 그런 환경에서 제가 바라던 방식으로 일해볼 기회가 생긴 거죠.
수민 저도 비슷했어요. AI를 둘러싸고 많은 변화가 일어나는 상황에서 더 다양한 도전을 해보고 싶었어요. 아직은 AI나 LLM을 일부 전문가의 영역으로만 보는 조직이 많아요. AI를 제품에 녹여내고 싶어도 조직 전체의 합의가 충분하지 않으면 시도하기 어렵고요. CS 에이전트 스쿼드는 AI를 활용한 제품을 ‘0 to 1’으로 만들어볼 수 있다는 점에서 끌렸습니다. 실험적인 방식으로 스쿼드를 운영한다는 설명은 들었지만, 사실 두 명이서 제품 출시까지 하게 될 줄은 몰랐어요. (웃음) 하지만 자연스럽게 ‘둘이서 어디까지 해볼 수 있을까?’ 하는 생각으로 이어지더라고요. 자율성과 오너십을 갖고 일하는 방식을 다양하게 실험해 볼 수 있는 거잖아요. 최소 규모로 시작한 우리가 어디까지 해낼 수 있을지 궁금해졌어요.
‘직무’가 아닌 ‘문제’를 중심으로 역할을 나누다
정민 회사에서의 직무명은 PO와 BE지만, 직무에 갇히지 않고 일하고 있어요. CS 에이전트 스쿼드 안에서는 프로덕트 엔지니어(Product Engineer)로서 제품 구현 전반을 맡고 있죠. 입사 안내를 받을 때부터 규모가 작은 만큼 백엔드뿐 아니라 프론트엔드를 포함한 개발 전반을 맡게 될 거라는 이야기를 들었어요. AI 시대에 엔지니어로 커리어를 이어가려면 제품 전체를 이해하고 만들 수 있어야 한다고 생각해서 오히려 반가웠죠. 또 이렇게 일하면 두 명이서도 업무 속도를 최대한으로 끌어올릴 수 있어요.
수민 대부분 조직에서는 직무별 역할이 명확하게 정해져 있잖아요. PO는 고객 문제를 정의하고, 우선순위를 조율하고, 이해관계자와 의견을 맞추는 일을 맡죠. 일반적인 제품 개발 과정에서는 화면 하나를 만들 때 기획, 디자인, 개발, QA, 배포를 순서대로 거쳐요. 기획 의도를 문서로 써서 디자이너에게 전달하고, 시안을 받아 조율하고, 수정본을 엔지니어에게 넘기면, 다시 개발 일정과 QA, 배포 순서를 기다리는 식이죠. 이렇게 단계마다 넘기고 기다리는 시간이 쌓이면 그 사이에 처음 의도와 다르게 전달되는 일도 생겨요. 직무의 경계를 없애는 건 둘 사이의 불필요한 대기 시간을 없애보려는 시도이기도 했어요. 지금은 제가 화면도 직접 설계하고, 필요한 데이터도 직접 확인하고, 작은 기능은 직접 개발까지 해요. 문제를 정의하는 일과 문제를 해결하는 일 사이에 놓여 있던 대기 시간이 사라진 거예요.
정민 직무 간 경계가 명확하지 않으면 협업이 더 복잡해지거나 감정적으로 불편해지는 경우도 있는데요. 저희는 이렇게 서로의 일을 도와주는 걸 오히려 반겨요. 그 대신 각자 어디까지 직접 진행하고, 어떤 일에 상대의 확인을 받아야 하는지 정리한 업무 규칙 문서를 만들었습니다. 문제 정의, PRD(제품 요구사항 문서), 사용자 흐름, 화면, 문구, 종결 조건은 제가 임의로 바꾸지 않고, 스텝 명세, 이벤트 정의, 코드는 수민님이 임의로 바꾸지 않기로 했죠. 그렇지만 상대가 맡은 부분에 절대 손댈 수 없다는 뜻은 아니에요. 상대 영역을 수정해야 한다면 답이 올 때까지 멈춰 있는 게 아니라 PR(Pull Request)을 올려 리뷰를 요청하고 하던 일을 계속해요. 일하는 방식에 대한 합의가 되어 있고, 서로를 신뢰하기에 가능한 업무 방식이에요.
Chapter 2. 기획하는 엔지니어, 개발하는 PO가 되기까지
둘이서 더 많은 일을 해내기 위해 설계한 AI 협업 체계
정민 스쿼드를 처음 시작하면서 첫 제품을 3주 안에 만들겠다는 목표를 세웠지만, CS 에이전트는 둘 다 경험이 없는 도메인의 제품인 데다가 백엔드, 프론트엔드, 인프라, 데이터 수집 경로, UI/UX까지 저희가 해결해야 할 일이 많았어요. 그래도 AI가 있는데 못 할 게 있나 싶어서 조사, 분석, 구현, 테스트까지 AI를 이용해 진행하는 체계를 세팅했어요. 사람은 ① 아직 결정하지 않은 내용을 정할 때, ② 개발에 착수하기 전에 AI의 결과물을 승인할 때, ③ 운영 배포를 확인할 때만 개입하도록 했죠.
수민 정민님이 세팅해 주신 AI 협업 체계 덕분에 코드 베이스를 살펴보고 구현 방법을 조사하며 제품 개발 프로세스를 시작하고 있어요. 에이전트가 조사 결과와 설계안을 제가 읽고 판단할 수 있는 수준으로 정리해 사내 페이지에 올려주면, 그 내용을 읽고 정민님에게 착수 승인을 요청해요. AI 에이전트 제품은 겉으로 보이는 대화 뒤에 검색과 판정 같은 단계가 여러 겹 쌓여 있어서, 이를 잘 이해하지 못하면 기획이 막연해지기 쉬운데요. 지금은 AI를 활용해서 현재 구현 방식과 요구 사항을 반영하기 위한 최적의 설계를 직접 조사하며 일할 수 있어서 좋아요. AI와 함께 일하면서 제품에 대한 기술적인 이해도도 크게 높아졌습니다.
믿을 수 있는 하나의 기준으로 설계한 AI 개발 워크플로
정민 첫 제품을 출시하고 다음 단계로 넘어가면서 문제가 하나 생겼어요. 이전에 잘 되던 기능이 작동하지 않거나, 수정한 화면이 이전 상태로 돌아가는 일이었죠. 알고 보니 AI가 노션의 내용을 보고 개발했다가, 지라에 있는 내용을 보고 다시 수정한 거였어요. 정보가 흩어져 있으니 AI가 어떤 걸 기준으로 삼아야 할지 알기 어려웠던 거예요. 그래서 수민님과 상의해 깃허브 저장소 한 곳에 사람과 AI가 함께 참고할 단일 진실 공급원(SSoT)을 만들기로 했어요. 이제는 AI가 작업을 시작할 때마다 기준 문서를 작업 내용과 대조해야 다음 단계로 넘어가고, 별도 사본을 만들지 못하게 해서 사람과 AI가 항상 같은 원본을 기준으로 작업해요.
상품 관련 문의 대응 기능을 만들 때도 문서와 코드가 하나의 기준을 따르도록 함께 갱신하며 개발했어요. 주문이나 클레임 관련 문의만 처리했던 기존 기능을 상품 자체에 대한 질문에도 답할 수 있게 확장하는 작업이었는데요. 한 달 동안 작업을 티켓 76건으로 나눠서 진행했고, 그 과정에서 기획 문서가 145번 개정됐어요. 제품을 운영하면서 알게 된 내용을 기획 문서에 반영하고, 그 내용을 바탕으로 제품을 다시 수정하는 식으로 돌아간 거죠. 이 기준을 세우는 과정이 비개발자인 수민님께는 낯선 방식이었을 텐데 기꺼이 받아들여 주셔서 감사했어요.
수민 둘이서 높은 생산성을 유지하며 일하기 위해 꼭 필요한 기반 작업이라고 생각했어요. 각자의 기억이나 역량에 기대는 부분을 줄이고, 시스템과 워크플로를 중심으로 업무가 굴러가길 바랐죠. 그래야 속도와 완성도를 함께 높일 수 있을 테니까요. 원래 배우고 직접 써보면서 익숙하지 않은 걸 하나씩 제 것으로 만드는 과정을 좋아하기도 해요.
서로의 일을 대신하는 구조를 만들다
정민 입사 첫날 함께 밥을 먹으면서 수민님도 개발하고 저도 기획할 수 있는 스쿼드가 되면 좋겠다는 이야기를 나눴어요. 이제는 저장소에 에이전트가 지켜야 할 규칙도 충분히 갖춰졌고, 엔지니어인 저도 에이전트가 조사하고 설계한 내용을 읽고 승인하는 방식으로 일하고 있었으니, 수민님도 개발에 참여해보실 수 있을 것 같았죠. 그렇게 한 달 전쯤부터 수민님도 직접 개발에 참여할 수 있는 환경을 본격적으로 마련하기 시작했습니다.
수민님 쪽 에이전트가 메신저 스레드에 승인 요청을 올리면, 제가 조사 결과와 설계안을 읽고 승인해요. 그러면 수민님 세션에서 개발이 진행돼 PR이 올라오고, 이후에는 제 에이전트가 검증을 맡아요. 수정할 부분이 있으면 에이전트끼리 스레드에서 내용을 주고받으며 수정과 검증을 반복합니다. 마지막에 코드를 병합하고 배포하는 건 제가 진행해요. 지금은 수민님께서 간단한 UI 수정, 소규모 기능이나 고객사가 사용하는 관리자 기능을 직접 개발하고 계세요. QA에서 제가 놓친 부분도 직접 수정하시고요. 한 번은 워크플로의 핵심인 정합성 검사 스크립트까지 직접 고치셨더라고요. 수민님이 개발에 참여하시면서 제가 들이는 시간과 자원이 크게 줄어들었어요. 과거에는 작은 수정 요청도 다 저에게 들어오다 보니 작업의 맥락이 끊기는 일이 많았는데요. 이제는 그런 부분을 수민님이 빠르게 처리해 주세요.
수민 정합성 검사 스크립트는 기획 문서와 실제 코드, 지라 티켓에 적힌 내용이 서로 맞는지 확인하는 장치인데요. 고객사 관리자 화면을 설계하다가 작업이 막혀서 에이전트에게 원인을 찾게 했더니, 이 검사 스크립트가 고객사 사이트에 들어가는 CS 에이전트 채팅 화면에 맞춰져 있었더라고요. 새로 만든 관리자 화면은 검사 대상이 아니었던 거죠. ‘이건 고쳐야겠다’ 싶어서 관리자 화면도 함께 확인하도록 검사 범위를 넓혔습니다.
정민 반대로 제가 기획이나 디자인을 제안할 때도 있어요. 처음에는 빠른 제품 출시를 위해 단순한 기본 디자인을 사용했는데, 특정 섹션에 적용된 디자인이 제 눈에 영 마음에 들지 않더라고요. 그래서 제가 먼저 디자인안을 만들어 수민님께 보여드리고 디자인 방향을 수정한 적이 있습니다. 기획서와 실제 구현이 어긋나지 않게 PRD 수정안도 제가 작성해서 수민님께 리뷰를 요청했고요. 이후에는 아예 날 잡고 화면을 함께 살펴보면서 AI가 참조할 수 있는 디자인 룰을 만들었죠. 이렇게 이제는 둘 중 한 명이 없어도 남은 사람이 웬만큼 일을 이어갈 수 있는 상태가 됐어요. 앞으로는 이 ‘웬만큼’을 ‘완전히’로 바꾸고 싶어요. 한 명이 휴가를 가더라도 다른 한 명이 그 일을 완전히 대신할 수 있는 수준까지 가도록 워크플로를 다듬는 게 목표입니다.
개발 착수 요청부터 승인, 테스트 실패 수정까지 에이전트가 이어가는 슬랙 스레드
Chapter 3. 고객의 질문에서 배우고, 더 나은 AI 에이전트로 답하다
실제 상담에서 문제점을 찾고, 개선과 검증은 하루 안에 빠르게
수민 AI 에이전트는 사용자가 어떤 말을 어떤 맥락에서 하느냐에 따라 결과가 달라지는데, 그 조합을 출시 전에 모두 예상하기는 어려워요. 실제 고객 질문의 상당수가 열 자도 안 되는 짧은 단어 몇 개라는 것도, 지식을 많이 갖췄다고 답변까지 잘하는 건 아니라는 것도 출시한 뒤에 알게 됐죠. 그래서 저희는 빠르게 제품을 내보내고, 고객의 문의가 실제로 해결됐는지 확인하면서 부족한 부분을 개선해 나가고 있어요. 처음에는 제가 직접 상담 내용을 질문 단위로 나누고, 해결되지 않은 상담을 유형별로 구분했어요. 데이터가 어느 정도 쌓인 뒤에는 제가 만든 기준에 따라 AI가 이를 분류하도록 했고요. 지금은 AI가 대화를 읽고 분류 후보를 붙여두면 제가 확인해 확정해요. 제품을 수정한 뒤에는 AI가 고객사의 지식베이스를 읽고 만든 질문으로 실제로 나아졌는지 평가합니다. 지식에 답이 있는 질문에는 제대로 답하는지 확인하고, 답이 없는 질문도 일부러 섞어 없는 답을 지어내지는 않는지 살펴봐요.
최근에는 이렇게 평가하다가 한 고객사의 택배사를 잘못 안내하는 걸 발견했어요. 몇 년 전 게시판에 남아 있던 답변을 현재 안내보다 우선해서 참고하고 있더라고요. 그날 바로 지식을 다시 넣고, 같은 질문에 제대로 답하는지 확인했어요. 이렇게 CS 에이전트의 문제점을 찾아 수정하고 답변을 평가하는 과정은 보통 하루 안에 끝나요. 하지만 앞으로는 AI의 도움을 받아 이 과정을 더 빠르게 운영하고 싶어요.
개발 속도가 빨라질수록 품질을 지키는 기준은 더 정교하게
정민 하루 평균 22건의 PR을 머지할 정도로 개발 속도가 빠르지만, 개발을 승인하기 전에 조사 결과와 설계안을 읽는 데에는 꼭 시간을 들이고 있어요. 수민님이 검토하고 전달해 주신 내용도 꼼꼼히 확인하고요. 제 승인을 토대로 에이전트가 구현과 테스트를 진행하기 때문에, 뒤에 이어질 작업의 품질을 정하는 일이라고 생각하고 철저하게 검토하고 있습니다. 결국 제가 한 승인들이 제품 곳곳에 반영되는 거잖아요. 예전에는 어떻게 설계하고 구현할지만 고민했다면 지금은 무엇을 어디까지 만들지, 어떤 기준을 세울지까지 고민하게 됐어요. 제 판단이 제품 전체에 녹아있는 것을 느낄 때 뿌듯함이 커집니다.
수민 그렇다고 저희가 모든 일을 빠르게만 처리하는 건 아니에요. 화면을 수정하거나 지식을 보강하는 일은 되돌릴 수 있으니 빠르게 진행하지만, 구매자의 개인정보처럼 한 번 나가면 되돌릴 수 없는 영역은 오히려 검토 절차를 늘려서 출시 전에 여러 번 확인해요. 이렇게 해야 고객이 믿고 사용할 수 있는 CS 에이전트를 만들 수 있어요.
정민 에이전트가 정해진 기준 안에서 작업하도록 가드레일을 손보는 데도 시간을 씁니다. 당장 기능 하나를 완성하는 데는 도움이 안 되는 것처럼 보일 수도 있어요. 그래도 공통 규칙이나 검증 절차를 보완해두면 다음 작업에도 그 기준이 계속 적용되거든요. 제품을 더 안정적으로 개발하려면 이런 기반을 다듬는 데 꾸준히 시간을 들여야 한다고 생각해요.
Chapter 4. 소규모 스쿼드의 실행력을 뒷받침하는 아임웹의 개발 환경
정민 아임웹에서는 일하다가 인프라 때문에 ‘이건 안 되겠구나’ 하고 막히는 경우가 거의 없어요. 새 서비스를 띄우려면 서버 자원과 접근 설정을 새로 마련해야 하는데, 여기는 그 절차가 저장소 문서에 정리돼 있어서 에이전트가 읽고 그대로 실행하면 필요한 설정이 자동으로 생성돼요. 저는 요청이 올라갔는지, 잘 반영됐는지만 확인하면 되죠. 인프라 엔지니어의 검토가 필요한 경우에도 응답이 워낙 빨라서 업무가 막힌다는 느낌이 없어요. 다른 회사였으면 하루이틀은 걸리겠다 싶은 일도 아임웹에서는 1시간을 넘긴 적이 없습니다. 데이터 저장소를 새로 요청했을 때도 봇이 곧바로 티켓 발급과 담당자 배정을 완료했고, 1시간 만에 개발 환경과 운영 환경이 마련됐고요. 게다가 인프라팀에서 제가 요청한 내용을 검토하시고, 장애 대비 구성이나 백업처럼 미처 요청하지 못한 부분까지 먼저 챙겨서 제안해 주시더라고요.
기존 인프라만으로 해결하기 어려운 일은 CTO 형섭님이 직접 도와주시기도 해요. 최근에는 자체 LLM 서버와 OCR 서버를 구축해 주셨는데, 다른 일로 바쁘실 텐데도 3일 만에 바로 쓸 수 있게 해주셨어요. 보통 다른 팀이 만든 건 수정 권한이 없어 개선하고 싶어도 요청 후 기다리는 게 일반적인데, 아임웹에서는 누구나 수정하고 개선할 수 있도록 열어둬요. 그러니 저희도 자연스럽게 더 나은 방향을 고민하게 되죠. 저는 이런 문화까지도 좋은 인프라의 일부라고 생각해요.
수민 저희가 디자이너 없이 제품을 구현할 수 있었던 것도 사내 디자인 시스템과 생산성팀이 만든 도구 덕분이에요. 원하는 내용을 자연어로 설명하면 아임웹 디자인 시스템을 기반으로 피그마 문서가 만들어지고, 엔지니어를 위한 주석까지 붙여주는 도구인데요. 이걸로 CS 에이전트의 고객사 관리자 화면 16종을 이틀 만에 만들었어요. 이전 경험에 비추어 보면 2주 정도는 걸렸을 작업이에요. 저희처럼 디자이너 없이 일하는 소규모 스쿼드도 아임웹다운 화면을 만들 수 있고, 디자인 조직은 저희 요청을 해결하기 위해 시간을 쓰는 대신 맡은 제품에 더 집중할 수 있어 서로에게 더 좋은 구조라고 생각해요.
이런 환경이 갖춰져 있으니 직무 밖의 일을 시도할 때도 두려움이나 부담이 덜해요. ‘이 정도는 나도 한번 해볼 수 있겠다’는 생각이 자연스럽게 들거든요. 저희가 직무 경계를 넘나들며 일할 수 있는 것도 그 덕분이 아닐까 싶어요. 앞으로도 저희의 실행력을 뒷받침하는 아임웹의 좋은 개발 환경을 바탕으로 CS 에이전트의 해결률을 더 높여가고 싶어요. 우리가 만든 제품으로 고객이 반복적인 문의를 처리하는 데 쓰던 시간을 브랜드의 성장을 고민하는 데 쓸 수 있었으면 좋겠습니다.
imweb Corp.
아임웹에는 두 명의 구성원으로만 운영되는 실험적인 스쿼드가 있습니다. 반복되는 고객 문의 응대부터 주문 관리까지 자동화해, 브랜드가 성장에 집중할 수 있도록 돕는 CS 에이전트 스쿼드입니다. 0에서부터 제품을 만들어야 하는 상황이었지만, 이 스쿼드는 꾸려진 지 3주 만에 첫 제품을 출시했습니다. CS 에이전트 스쿼드의 수민님과 정민님은 작은 스쿼드이기에 오히려 다양한 아이디어를 과감하게 실험하며 일하는 것이 가능하다고 말합니다. 규모의 제약에 갇히지 않고, 직무의 경계를 넘나들며 제품을 만드는 두 사람의 이야기를 들어봤습니다.
제품이 해결해야 할 고객 문제와 방향성을 정의하고, AI를 활용해 필요한 기능을 직접 개발합니다.
AI와 효율적으로 협업할 수 있는 개발 환경과 기술 구조를 설계하며, 제품 구현 전반을 책임집니다.
고객 문의에 답하고 주문 취소까지 처리하는 CS Agent 화면
Chapter 1. AI 시대, 작은 규모에서 발견한 더 큰 커리어의 가능성
소규모 스쿼드, 오히려 AI를 제대로 활용할 기회
정민 처음에는 다른 스쿼드에 지원했는데, 입사를 앞두고 CS 에이전트 스쿼드 합류를 제안받았어요. 소규모 인원이 AI를 적극 활용해 새로운 제품을 빠르게 만드는 스쿼드가 될 거라고 하셨죠. 제가 AI에 관심이 많고, 업무에도 적극적으로 활용하고 싶어 하는 모습을 보고 제안을 주신 거였어요. 걱정보다는 기대감이 컸습니다. 아임웹에 오고 싶었던 이유도 AI로 하고 싶은 일을 마음껏 해볼 수 있을 것 같아서였거든요. 지금은 AI를 적극적으로 쓰는 회사가 많지만, 그때까지만 해도 AI를 불신하거나 아직 적극적으로 도입하지 않은 회사가 더 많았어요. 아임웹은 이미 AI를 도입해서 매우 활발하게 쓰고 있었고요. 그런 환경에서 제가 바라던 방식으로 일해볼 기회가 생긴 거죠.
수민 저도 비슷했어요. AI를 둘러싸고 많은 변화가 일어나는 상황에서 더 다양한 도전을 해보고 싶었어요. 아직은 AI나 LLM을 일부 전문가의 영역으로만 보는 조직이 많아요. AI를 제품에 녹여내고 싶어도 조직 전체의 합의가 충분하지 않으면 시도하기 어렵고요. CS 에이전트 스쿼드는 AI를 활용한 제품을 ‘0 to 1’으로 만들어볼 수 있다는 점에서 끌렸습니다. 실험적인 방식으로 스쿼드를 운영한다는 설명은 들었지만, 사실 두 명이서 제품 출시까지 하게 될 줄은 몰랐어요. (웃음) 하지만 자연스럽게 ‘둘이서 어디까지 해볼 수 있을까?’ 하는 생각으로 이어지더라고요. 자율성과 오너십을 갖고 일하는 방식을 다양하게 실험해 볼 수 있는 거잖아요. 최소 규모로 시작한 우리가 어디까지 해낼 수 있을지 궁금해졌어요.
‘직무’가 아닌 ‘문제’를 중심으로 역할을 나누다
정민 회사에서의 직무명은 PO와 BE지만, 직무에 갇히지 않고 일하고 있어요. CS 에이전트 스쿼드 안에서는 프로덕트 엔지니어(Product Engineer)로서 제품 구현 전반을 맡고 있죠. 입사 안내를 받을 때부터 규모가 작은 만큼 백엔드뿐 아니라 프론트엔드를 포함한 개발 전반을 맡게 될 거라는 이야기를 들었어요. AI 시대에 엔지니어로 커리어를 이어가려면 제품 전체를 이해하고 만들 수 있어야 한다고 생각해서 오히려 반가웠죠. 또 이렇게 일하면 두 명이서도 업무 속도를 최대한으로 끌어올릴 수 있어요.
수민 대부분 조직에서는 직무별 역할이 명확하게 정해져 있잖아요. PO는 고객 문제를 정의하고, 우선순위를 조율하고, 이해관계자와 의견을 맞추는 일을 맡죠. 일반적인 제품 개발 과정에서는 화면 하나를 만들 때 기획, 디자인, 개발, QA, 배포를 순서대로 거쳐요. 기획 의도를 문서로 써서 디자이너에게 전달하고, 시안을 받아 조율하고, 수정본을 엔지니어에게 넘기면, 다시 개발 일정과 QA, 배포 순서를 기다리는 식이죠. 이렇게 단계마다 넘기고 기다리는 시간이 쌓이면 그 사이에 처음 의도와 다르게 전달되는 일도 생겨요. 직무의 경계를 없애는 건 둘 사이의 불필요한 대기 시간을 없애보려는 시도이기도 했어요. 지금은 제가 화면도 직접 설계하고, 필요한 데이터도 직접 확인하고, 작은 기능은 직접 개발까지 해요. 문제를 정의하는 일과 문제를 해결하는 일 사이에 놓여 있던 대기 시간이 사라진 거예요.
정민 직무 간 경계가 명확하지 않으면 협업이 더 복잡해지거나 감정적으로 불편해지는 경우도 있는데요. 저희는 이렇게 서로의 일을 도와주는 걸 오히려 반겨요. 그 대신 각자 어디까지 직접 진행하고, 어떤 일에 상대의 확인을 받아야 하는지 정리한 업무 규칙 문서를 만들었습니다. 문제 정의, PRD(제품 요구사항 문서), 사용자 흐름, 화면, 문구, 종결 조건은 제가 임의로 바꾸지 않고, 스텝 명세, 이벤트 정의, 코드는 수민님이 임의로 바꾸지 않기로 했죠. 그렇지만 상대가 맡은 부분에 절대 손댈 수 없다는 뜻은 아니에요. 상대 영역을 수정해야 한다면 답이 올 때까지 멈춰 있는 게 아니라 PR(Pull Request)을 올려 리뷰를 요청하고 하던 일을 계속해요. 일하는 방식에 대한 합의가 되어 있고, 서로를 신뢰하기에 가능한 업무 방식이에요.
Chapter 2. 기획하는 엔지니어, 개발하는 PO가 되기까지
둘이서 더 많은 일을 해내기 위해 설계한 AI 협업 체계
정민 스쿼드를 처음 시작하면서 첫 제품을 3주 안에 만들겠다는 목표를 세웠지만, CS 에이전트는 둘 다 경험이 없는 도메인의 제품인 데다가 백엔드, 프론트엔드, 인프라, 데이터 수집 경로, UI/UX까지 저희가 해결해야 할 일이 많았어요. 그래도 AI가 있는데 못 할 게 있나 싶어서 조사, 분석, 구현, 테스트까지 AI를 이용해 진행하는 체계를 세팅했어요. 사람은 ① 아직 결정하지 않은 내용을 정할 때, ② 개발에 착수하기 전에 AI의 결과물을 승인할 때, ③ 운영 배포를 확인할 때만 개입하도록 했죠.
수민 정민님이 세팅해 주신 AI 협업 체계 덕분에 코드 베이스를 살펴보고 구현 방법을 조사하며 제품 개발 프로세스를 시작하고 있어요. 에이전트가 조사 결과와 설계안을 제가 읽고 판단할 수 있는 수준으로 정리해 사내 페이지에 올려주면, 그 내용을 읽고 정민님에게 착수 승인을 요청해요. AI 에이전트 제품은 겉으로 보이는 대화 뒤에 검색과 판정 같은 단계가 여러 겹 쌓여 있어서, 이를 잘 이해하지 못하면 기획이 막연해지기 쉬운데요. 지금은 AI를 활용해서 현재 구현 방식과 요구 사항을 반영하기 위한 최적의 설계를 직접 조사하며 일할 수 있어서 좋아요. AI와 함께 일하면서 제품에 대한 기술적인 이해도도 크게 높아졌습니다.
믿을 수 있는 하나의 기준으로 설계한 AI 개발 워크플로
정민 첫 제품을 출시하고 다음 단계로 넘어가면서 문제가 하나 생겼어요. 이전에 잘 되던 기능이 작동하지 않거나, 수정한 화면이 이전 상태로 돌아가는 일이었죠. 알고 보니 AI가 노션의 내용을 보고 개발했다가, 지라에 있는 내용을 보고 다시 수정한 거였어요. 정보가 흩어져 있으니 AI가 어떤 걸 기준으로 삼아야 할지 알기 어려웠던 거예요. 그래서 수민님과 상의해 깃허브 저장소 한 곳에 사람과 AI가 함께 참고할 단일 진실 공급원(SSoT)을 만들기로 했어요. 이제는 AI가 작업을 시작할 때마다 기준 문서를 작업 내용과 대조해야 다음 단계로 넘어가고, 별도 사본을 만들지 못하게 해서 사람과 AI가 항상 같은 원본을 기준으로 작업해요.
상품 관련 문의 대응 기능을 만들 때도 문서와 코드가 하나의 기준을 따르도록 함께 갱신하며 개발했어요. 주문이나 클레임 관련 문의만 처리했던 기존 기능을 상품 자체에 대한 질문에도 답할 수 있게 확장하는 작업이었는데요. 한 달 동안 작업을 티켓 76건으로 나눠서 진행했고, 그 과정에서 기획 문서가 145번 개정됐어요. 제품을 운영하면서 알게 된 내용을 기획 문서에 반영하고, 그 내용을 바탕으로 제품을 다시 수정하는 식으로 돌아간 거죠. 이 기준을 세우는 과정이 비개발자인 수민님께는 낯선 방식이었을 텐데 기꺼이 받아들여 주셔서 감사했어요.
수민 둘이서 높은 생산성을 유지하며 일하기 위해 꼭 필요한 기반 작업이라고 생각했어요. 각자의 기억이나 역량에 기대는 부분을 줄이고, 시스템과 워크플로를 중심으로 업무가 굴러가길 바랐죠. 그래야 속도와 완성도를 함께 높일 수 있을 테니까요. 원래 배우고 직접 써보면서 익숙하지 않은 걸 하나씩 제 것으로 만드는 과정을 좋아하기도 해요.
서로의 일을 대신하는 구조를 만들다
정민 입사 첫날 함께 밥을 먹으면서 수민님도 개발하고 저도 기획할 수 있는 스쿼드가 되면 좋겠다는 이야기를 나눴어요. 이제는 저장소에 에이전트가 지켜야 할 규칙도 충분히 갖춰졌고, 엔지니어인 저도 에이전트가 조사하고 설계한 내용을 읽고 승인하는 방식으로 일하고 있었으니, 수민님도 개발에 참여해보실 수 있을 것 같았죠. 그렇게 한 달 전쯤부터 수민님도 직접 개발에 참여할 수 있는 환경을 본격적으로 마련하기 시작했습니다.
수민님 쪽 에이전트가 메신저 스레드에 승인 요청을 올리면, 제가 조사 결과와 설계안을 읽고 승인해요. 그러면 수민님 세션에서 개발이 진행돼 PR이 올라오고, 이후에는 제 에이전트가 검증을 맡아요. 수정할 부분이 있으면 에이전트끼리 스레드에서 내용을 주고받으며 수정과 검증을 반복합니다. 마지막에 코드를 병합하고 배포하는 건 제가 진행해요. 지금은 수민님께서 간단한 UI 수정, 소규모 기능이나 고객사가 사용하는 관리자 기능을 직접 개발하고 계세요. QA에서 제가 놓친 부분도 직접 수정하시고요. 한 번은 워크플로의 핵심인 정합성 검사 스크립트까지 직접 고치셨더라고요. 수민님이 개발에 참여하시면서 제가 들이는 시간과 자원이 크게 줄어들었어요. 과거에는 작은 수정 요청도 다 저에게 들어오다 보니 작업의 맥락이 끊기는 일이 많았는데요. 이제는 그런 부분을 수민님이 빠르게 처리해 주세요.
수민 정합성 검사 스크립트는 기획 문서와 실제 코드, 지라 티켓에 적힌 내용이 서로 맞는지 확인하는 장치인데요. 고객사 관리자 화면을 설계하다가 작업이 막혀서 에이전트에게 원인을 찾게 했더니, 이 검사 스크립트가 고객사 사이트에 들어가는 CS 에이전트 채팅 화면에 맞춰져 있었더라고요. 새로 만든 관리자 화면은 검사 대상이 아니었던 거죠. ‘이건 고쳐야겠다’ 싶어서 관리자 화면도 함께 확인하도록 검사 범위를 넓혔습니다.
정민 반대로 제가 기획이나 디자인을 제안할 때도 있어요. 처음에는 빠른 제품 출시를 위해 단순한 기본 디자인을 사용했는데, 특정 섹션에 적용된 디자인이 제 눈에 영 마음에 들지 않더라고요. 그래서 제가 먼저 디자인안을 만들어 수민님께 보여드리고 디자인 방향을 수정한 적이 있습니다. 기획서와 실제 구현이 어긋나지 않게 PRD 수정안도 제가 작성해서 수민님께 리뷰를 요청했고요. 이후에는 아예 날 잡고 화면을 함께 살펴보면서 AI가 참조할 수 있는 디자인 룰을 만들었죠. 이렇게 이제는 둘 중 한 명이 없어도 남은 사람이 웬만큼 일을 이어갈 수 있는 상태가 됐어요. 앞으로는 이 ‘웬만큼’을 ‘완전히’로 바꾸고 싶어요. 한 명이 휴가를 가더라도 다른 한 명이 그 일을 완전히 대신할 수 있는 수준까지 가도록 워크플로를 다듬는 게 목표입니다.
개발 착수 요청부터 승인, 테스트 실패 수정까지 에이전트가 이어가는 슬랙 스레드
Chapter 3. 고객의 질문에서 배우고, 더 나은 AI 에이전트로 답하다
실제 상담에서 문제점을 찾고, 개선과 검증은 하루 안에 빠르게
수민 AI 에이전트는 사용자가 어떤 말을 어떤 맥락에서 하느냐에 따라 결과가 달라지는데, 그 조합을 출시 전에 모두 예상하기는 어려워요. 실제 고객 질문의 상당수가 열 자도 안 되는 짧은 단어 몇 개라는 것도, 지식을 많이 갖췄다고 답변까지 잘하는 건 아니라는 것도 출시한 뒤에 알게 됐죠. 그래서 저희는 빠르게 제품을 내보내고, 고객의 문의가 실제로 해결됐는지 확인하면서 부족한 부분을 개선해 나가고 있어요. 처음에는 제가 직접 상담 내용을 질문 단위로 나누고, 해결되지 않은 상담을 유형별로 구분했어요. 데이터가 어느 정도 쌓인 뒤에는 제가 만든 기준에 따라 AI가 이를 분류하도록 했고요. 지금은 AI가 대화를 읽고 분류 후보를 붙여두면 제가 확인해 확정해요. 제품을 수정한 뒤에는 AI가 고객사의 지식베이스를 읽고 만든 질문으로 실제로 나아졌는지 평가합니다. 지식에 답이 있는 질문에는 제대로 답하는지 확인하고, 답이 없는 질문도 일부러 섞어 없는 답을 지어내지는 않는지 살펴봐요.
최근에는 이렇게 평가하다가 한 고객사의 택배사를 잘못 안내하는 걸 발견했어요. 몇 년 전 게시판에 남아 있던 답변을 현재 안내보다 우선해서 참고하고 있더라고요. 그날 바로 지식을 다시 넣고, 같은 질문에 제대로 답하는지 확인했어요. 이렇게 CS 에이전트의 문제점을 찾아 수정하고 답변을 평가하는 과정은 보통 하루 안에 끝나요. 하지만 앞으로는 AI의 도움을 받아 이 과정을 더 빠르게 운영하고 싶어요.
개발 속도가 빨라질수록 품질을 지키는 기준은 더 정교하게
정민 하루 평균 22건의 PR을 머지할 정도로 개발 속도가 빠르지만, 개발을 승인하기 전에 조사 결과와 설계안을 읽는 데에는 꼭 시간을 들이고 있어요. 수민님이 검토하고 전달해 주신 내용도 꼼꼼히 확인하고요. 제 승인을 토대로 에이전트가 구현과 테스트를 진행하기 때문에, 뒤에 이어질 작업의 품질을 정하는 일이라고 생각하고 철저하게 검토하고 있습니다. 결국 제가 한 승인들이 제품 곳곳에 반영되는 거잖아요. 예전에는 어떻게 설계하고 구현할지만 고민했다면 지금은 무엇을 어디까지 만들지, 어떤 기준을 세울지까지 고민하게 됐어요. 제 판단이 제품 전체에 녹아있는 것을 느낄 때 뿌듯함이 커집니다.
수민 그렇다고 저희가 모든 일을 빠르게만 처리하는 건 아니에요. 화면을 수정하거나 지식을 보강하는 일은 되돌릴 수 있으니 빠르게 진행하지만, 구매자의 개인정보처럼 한 번 나가면 되돌릴 수 없는 영역은 오히려 검토 절차를 늘려서 출시 전에 여러 번 확인해요. 이렇게 해야 고객이 믿고 사용할 수 있는 CS 에이전트를 만들 수 있어요.
정민 에이전트가 정해진 기준 안에서 작업하도록 가드레일을 손보는 데도 시간을 씁니다. 당장 기능 하나를 완성하는 데는 도움이 안 되는 것처럼 보일 수도 있어요. 그래도 공통 규칙이나 검증 절차를 보완해두면 다음 작업에도 그 기준이 계속 적용되거든요. 제품을 더 안정적으로 개발하려면 이런 기반을 다듬는 데 꾸준히 시간을 들여야 한다고 생각해요.
Chapter 4. 소규모 스쿼드의 실행력을 뒷받침하는 아임웹의 개발 환경
정민 아임웹에서는 일하다가 인프라 때문에 ‘이건 안 되겠구나’ 하고 막히는 경우가 거의 없어요. 새 서비스를 띄우려면 서버 자원과 접근 설정을 새로 마련해야 하는데, 여기는 그 절차가 저장소 문서에 정리돼 있어서 에이전트가 읽고 그대로 실행하면 필요한 설정이 자동으로 생성돼요. 저는 요청이 올라갔는지, 잘 반영됐는지만 확인하면 되죠. 인프라 엔지니어의 검토가 필요한 경우에도 응답이 워낙 빨라서 업무가 막힌다는 느낌이 없어요. 다른 회사였으면 하루이틀은 걸리겠다 싶은 일도 아임웹에서는 1시간을 넘긴 적이 없습니다. 데이터 저장소를 새로 요청했을 때도 봇이 곧바로 티켓 발급과 담당자 배정을 완료했고, 1시간 만에 개발 환경과 운영 환경이 마련됐고요. 게다가 인프라팀에서 제가 요청한 내용을 검토하시고, 장애 대비 구성이나 백업처럼 미처 요청하지 못한 부분까지 먼저 챙겨서 제안해 주시더라고요.
기존 인프라만으로 해결하기 어려운 일은 CTO 형섭님이 직접 도와주시기도 해요. 최근에는 자체 LLM 서버와 OCR 서버를 구축해 주셨는데, 다른 일로 바쁘실 텐데도 3일 만에 바로 쓸 수 있게 해주셨어요. 보통 다른 팀이 만든 건 수정 권한이 없어 개선하고 싶어도 요청 후 기다리는 게 일반적인데, 아임웹에서는 누구나 수정하고 개선할 수 있도록 열어둬요. 그러니 저희도 자연스럽게 더 나은 방향을 고민하게 되죠. 저는 이런 문화까지도 좋은 인프라의 일부라고 생각해요.
수민 저희가 디자이너 없이 제품을 구현할 수 있었던 것도 사내 디자인 시스템과 생산성팀이 만든 도구 덕분이에요. 원하는 내용을 자연어로 설명하면 아임웹 디자인 시스템을 기반으로 피그마 문서가 만들어지고, 엔지니어를 위한 주석까지 붙여주는 도구인데요. 이걸로 CS 에이전트의 고객사 관리자 화면 16종을 이틀 만에 만들었어요. 이전 경험에 비추어 보면 2주 정도는 걸렸을 작업이에요. 저희처럼 디자이너 없이 일하는 소규모 스쿼드도 아임웹다운 화면을 만들 수 있고, 디자인 조직은 저희 요청을 해결하기 위해 시간을 쓰는 대신 맡은 제품에 더 집중할 수 있어 서로에게 더 좋은 구조라고 생각해요.
이런 환경이 갖춰져 있으니 직무 밖의 일을 시도할 때도 두려움이나 부담이 덜해요. ‘이 정도는 나도 한번 해볼 수 있겠다’는 생각이 자연스럽게 들거든요. 저희가 직무 경계를 넘나들며 일할 수 있는 것도 그 덕분이 아닐까 싶어요. 앞으로도 저희의 실행력을 뒷받침하는 아임웹의 좋은 개발 환경을 바탕으로 CS 에이전트의 해결률을 더 높여가고 싶어요. 우리가 만든 제품으로 고객이 반복적인 문의를 처리하는 데 쓰던 시간을 브랜드의 성장을 고민하는 데 쓸 수 있었으면 좋겠습니다.
직무의 경계를 넘어, 제품 전체를 만드는 경험을 함께할 동료를 찾습니다.
아임웹 적극 채용 중