AI로 일하는 개발팀은 무엇이 다를까?

PM팀 / Dan

"이 과제가 목표에 얼마나 기여하는가?" 이게 항상 가장 먼저 오는 질문입니다.

PM은 매년 전사 목표를 기준으로 스쿼드 OKR을 주도적으로 설계합니다. Objective가 "어디로 갈 것인가"라면, Key Result는 "도착했는지 어떻게 알 것인가"입니다. 그래서 KR은 기능 커버리지, 핵심 전환율처럼 측정 가능한 지표로 설정합니다. 매주 "지금 우리가 어디에 있는지"를 수치로 확인할 수 있어야 하니까요.

이 OKR이 로드맵의 모든 우선순위 판단의 출발점입니다. 할 수 있는 일은 항상 많지만, KR을 가장 빠르게 움직이는 과제가 무엇인지를 기준으로 보면 우선순위가 명확해집니다.

그리고 이 판단을 감이 아닌 데이터로 만들기 위해 노력합니다. 매주 AI Agent를 활용해 핵심 지표를 자동 수집하고, 지표 변동에 대한 인사이트를 분석합니다. "이번 주 타겟 고객군의 전환율이 전주 대비 하락했고, 특정 단계에서 이탈이 집중되고 있다" 같은 인사이트가 다음 Discovery 우선순위를 조정하는 직접적인 근거가 됩니다.

임팩트는 배포 순간이 아니라 KR 지표가 실제로 움직이는 시점에 발생한다고 생각합니다. OKR을 세우고, 매주 데이터로 추적하고, 그 결과를 로드맵에 피드백하는 사이클을 꾸준히 돌리는 것이 Focus On Impact의 실천입니다.

가장 본질적으로 달라진 걸 한 문장으로 말하면, "사람은 문제 정의와 판단에 집중하고, 실행은 AI Agent가 수행하는 구조로 바뀌었다"입니다.

모두싸인 제품 그룹은 Agentic Software Development 방식을 도입했습니다. 단순히 AI를 보조 도구로 쓰는 게 아니라, "사람은 판단, Agent는 실행"이라는 구조를 제품그룹 차원에서 체계적으로 설계해가고 있습니다.

실제 PM 업무에서 달라진 건 크게 세 가지입니다.

첫째, 지표 추적 방식이 달라졌습니다. 이전에는 쿼리를 직접 돌리고, 데이터를 정리하고, 표를 만드는 데 반나절 가까이 썼습니다. 지금은 AI Agent가 핵심 지표 수집부터 주간 싱크 페이지 삽입까지 자동으로 수행합니다. 달라진 건 시간만이 아닙니다. 예전에는 표를 만드는 것 자체가 일이라 "숫자가 왜 움직였는가"를 깊이 고민할 여유가 부족했는데, 지금은 AI가 지표 변동 인사이트까지 함께 분석해주기 때문에 저는 그 인사이트를 검증하고 로드맵 우선순위에 반영하는 판단에만 집중할 수 있게 됐습니다.

둘째, VOC를 다루는 방식이 완전히 바뀌었습니다. 이전에는 고객의 목소리를 하나씩 읽고 분류하는 데 상당한 시간을 썼습니다. 지금은 AI Agent가 기존 Discovery Idea와 자동으로 비교해 수용·중복·기각을 판정하고, 판정 근거와 점수까지 이슈 트래커에 기록합니다. 저는 그 판정이 맞는지 검토하고, 정말 중요한 문제에 대해 고객을 직접 만나 근본 원인을 파악하는 데 시간을 씁니다. 분류 작업자에서 판단자로 역할이 바뀐 셈입니다.

셋째, Discovery 실행 자체도 달라졌습니다. 이전에는 Problem Brief 초안 작성, 솔루션 대안 비교를 모두 PM이 직접 수행했습니다. 지금은 AI Agent 팀이 초안 작성부터 솔루션 방향 탐색, 대안 비교표 생성, 기술 검토까지 수행합니다. 기능 정책서를 쓸 때도 AI가 실제 코드를 탐색해 문서에는 없지만 코드에만 존재하는 제한값이나 예외 처리 로직을 추출해줘서, 예전에는 놓쳤던 규칙들이 훨씬 정확하게 반영됩니다.

결국 가장 크게 달라진 건 시간의 쓰임새입니다. VOC 분류, 초안 작성, 지표 취합 같은 실행성 업무에 쓰던 시간을, "이 문제가 정말 지금 풀어야 할 만큼 중요한가"를 판단하고 고객을 직접 만나는 데 쓸 수 있게 됐습니다. 실행 속도가 올라가면 잘못된 방향으로의 속도도 함께 올라갑니다. 그래서 AI의 진짜 레버리지는 실행 속도가 아니라 판단 품질이라고 생각합니다.

"한 번에 서명" 기능을 기획할 때 스쿼드 안에서 두 관점이 정면으로 부딪혔습니다. 이 기능은 문서 내 여러 서명란에 한 번의 액션으로 모두 서명할 수 있게 하는 것으로, 계약서 장 수가 많은 엔터프라이즈 고객들이 주로 요청한 기능이었습니다.

관점 A는 "빠른 서명 과정에서의 편의를 제공해야 한다"는 것이었습니다. 서명란이 30~40개인 계약서에서 하나씩 클릭하는 반복 작업은 요청자와 서명자 모두에게 비효율이고, 일부 경쟁사는 이미 제공하고 있었습니다.

관점 B는 "서명자의 권리 보호를 위해 이 기능을 제공하면 안 된다"는 것이었습니다. 각 서명란 주변의 내용을 검토하지 않고 서명할 수 있다는 법적 리스크가 있고, 모두싸인이 그에 대한 윤리적 책임을 질 수 있다는 우려였습니다.

논의 끝에 기능을 제공하되, 서명자의 안전을 포기하지 않는 방향으로 결론을 냈습니다. 그리고 세 가지 안전장치를 설계했습니다. 서명자가 한 번에 서명할지 개별로 할지 스스로 선택하게 하는 것, 기능 사용 전 명확한 안내를 제공하는 것, 그리고 내부 법률 검토를 통해 리스크를 헤징하는 것이었습니다.

결론이 나온 뒤에는 전원이 완전히 커밋했습니다. "기능 자체를 제공하지 말아야 한다"는 의견을 가졌던 구성원도, 합의된 안전장치 스펙을 꼼꼼히 구현하는 데 집중했습니다. 의견은 결정 전에 모두 꺼내고, 결정 이후에는 전력으로 실행하는 것 — 이게 저희가 Disagree and Commit을 실천하는 방식입니다.

"진본확인씰" 기능이 대표적입니다.

모두싸인은 원래 디지털 서명으로 문서의 진본을 전자적으로 증명하고 있었습니다. 기술적으로는 충분했지만, 문제는 "눈에 보이지 않는다"는 것이었습니다. 특정 고객사가 위변조 여부와 체결 시점을 육안으로 확인할 수 있도록, 진본확인 마크를 PDF에 직접 삽입해달라는 요청을 했습니다. TSA 기반의 시점증명과 진본확인 마크를 삽입하면서도 디지털 서명의 무결성을 유지해야 하는, 기술적으로 까다로운 과제였습니다.

요구사항은 초기에 명확하지 않았고, 일정은 촉박했습니다. 모든 요건을 갖추고 전체 배포하기에는 시간이 부족했습니다. 그래서 먼저 해당 고객사에서만 사용할 수 있는 방식으로 기능을 제공했습니다. 완벽하지는 않았지만, 고객이 가장 필요로 하는 핵심 — "문서에 진본확인 마크가 보이고, 체결 시점이 증명되는 것" — 을 충족했습니다. 이 경험을 바탕으로 요구사항을 정교하게 다듬고 기술을 고도화해, 지금은 전체 고객에게 제공하고 있습니다.

빠르게 가더라도 품질의 하한선은 지켜야 합니다. Private 배포 단계에서도 디지털 서명의 무결성이 깨지지 않는지, 문서 출력 시 마크가 유지되는지 같은 핵심 기준은 타협하지 않았습니다. 빠른 실행과 안정성은 양립할 수 있고, 그 열쇠는 "어디까지 빠르게 가고, 어디는 절대 타협하지 않는가"를 명확히 정의하는 것입니다.

4번에서 말씀드린 "한 번에 서명" 기능의 후속 이야기입니다. 배포 후 성과 리뷰 결과는 우려했던 것과 정반대였습니다.

서명자가 기능을 불안해할 것이라는 예상과 달리, 한 번에 서명 옵션이 제공된 문서에서 서명자의 60% 이상이 이 기능을 선택했습니다. 계약서, 고용·인사·노무 문서에서는 채택률이 더 높았고, 기능을 한 번 사용한 요청자는 꾸준히 반복 사용했습니다. 현재는 타겟 요청자의 50% 이상이 한 번에 서명을 활성화하고, 80% 이상의 서명자가 이를 이용하고 있습니다.

실제 서명 시간도 크게 단축됐습니다. 한 번에 서명을 사용한 서명자는 평균 83초 만에 완료한 반면, 미사용 서명자는 255초가 걸렸습니다. 약 67%의 시간이 단축된 것입니다.

그리고 가장 중요한 결과 — 배포 후 서명자로부터의 법적 리스크 관련 문의가 단 0건이었습니다. 기획 단계에서 가장 크게 우려했던 시나리오가 전혀 발생하지 않았고, 오히려 서명자들이 문서의 중요도에 따라 기능 사용 여부를 스스로 판단하는 패턴이 확인됐습니다.

이 결과를 바탕으로 기능 공개 범위를 확대하고, 요금제 페이지에 "고급 입력란 설정"이라는 새로운 기능 카테고리를 신설해 가격 패키징 전략까지 도출했습니다. 편의와 안전 사이에서 안전을 포기하지 않겠다는 원칙이, 더 넓은 확장의 기반이 된 경험이었습니다.

고객의 목소리는 크게 두 가지라고 생각합니다. 말로 하는 목소리와 말하지 않는 목소리입니다. 둘 다 듣지 않으면 제품은 고객에게 닿지 못하는데, 듣는 방식은 완전히 다릅니다.

말로 하는 목소리는 두 경로로 들어옵니다. 하나는 CXM과 CSM이 고객과 직접 소통하며 쌓는 VOC입니다. 저는 Claude Code로 VOC 매칭 전용 스킬을 직접 만들었는데, 새로 들어온 VOC를 기존 Discovery Idea 목록과 자동으로 비교합니다. 단순 키워드 매칭이 아니라 "주체의 일치", "단계의 일치", "행위의 일치"를 구조적으로 분석합니다. 전자서명 도메인에서는 "발송"과 "서명"이 키워드로는 비슷해 보여도 주체와 단계가 완전히 다르거든요. 비교 결과에 따라 AI가 각 VOC를 수용·중복·기각으로 판정하고, 판정 근거와 유사도 점수를 이슈 트래커에 남깁니다. 이렇게 정성적인 목소리가 점수와 빈도로 정량화되면, 동일한 문제에 VOC가 3건 들어오는 것과 30건 들어오는 것의 차이가 로드맵 우선순위에 직접 반영됩니다.

다른 하나는 Discovery 시작 시점의 고객 인터뷰입니다. "왜 그 작업을 하시는지", "지금은 어떻게 해결하고 계신지", "그게 안 되면 어떤 문제가 생기는지"를 질문하면서, 고객이 말한 요청 뒤에 있는 근본 문제를 찾아냅니다.

말하지 않는 목소리는 데이터로 듣습니다. 고객이 불편을 인지하지 못하거나 말로 표현하지 못하는 문제는 데이터를 통해서만 발견할 수 있습니다. 매주 AI Agent로 핵심 지표를 추적하면서 퍼널의 어느 지점에서 고객이 막히는지, 어떤 단계에서 이탈이 집중되는지를 분석합니다. 고객은 "서명이 불편해요"라고 말하지 않았지만, 데이터가 "여기서 고객이 멈춥니다"라고 말해주는 거죠.

결국 말로 하는 목소리와 말하지 않는 목소리, 두 가지가 OKR과 연결될 때 비로소 제품에 반영됩니다. 고객이 말한 문제와 말하지 못한 문제를 모두 OKR의 언어로 번역해서, 가장 임팩트가 큰 순서로 풀어가는 것이 Customer Centric의 실천이라고 생각합니다.

첫째는 올해 스쿼드 OKR의 달성입니다. OKR을 세우는 건 시작일 뿐이고, 진짜 어려운 건 한 해 동안 목표를 놓치지 않고 꾸준히 추적하는 것입니다. 매주 KR 지표를 확인하면서 "지금 우리가 목표 대비 어디에 있는지"를 정확히 파악하고, 지표가 기대만큼 움직이지 않으면 원인을 분석해 로드맵 우선순위를 조정하는 것. 연말에 "OKR을 달성했고, 그 과정에서 고객의 문제가 실제로 해결됐다"고 말할 수 있는 상태를 만들고 싶습니다.

둘째는 Agentic SD의 전방위적 확장입니다. 지금은 일부 Discovery 영역에서 AI Agent가 운영되고 있는데, 이를 PM의 모든 업무로 확장하고 싶습니다. OKR에서 시작해 지표 추적, Discovery, Delivery, 정책 갱신을 거쳐 다시 지표 추적으로 돌아오는 전체 파이프라인을 더 촘촘하게 자동화하는 게 목표입니다.

모두싸인에서 PM은 목표를 세우고, 성공의 기준을 정의하며, 그 달성을 책임지는 사람입니다. 문서를 많이 쓰는 게 성과가 아니라, 기준을 명확하게 세우는 것이 성과입니다.

지금은 AI Agent가 실행을 담당하는 시대가 열리고 있어서, PM에게 요구되는 역량의 무게중심도 바뀌고 있습니다. 요구사항을 꼼꼼히 쓰는 능력보다, 이 문제가 정말 풀어야 할 만큼 중요한지 판단하는 능력, 무엇이 성공인지 측정 가능하게 정의하는 능력, 그리고 고객 앞에서 직접 질문을 던지며 근본 문제를 찾아내는 능력이 더 중요해졌습니다.

도구를 두려워하지 않고, 목표에 집요하며, 고객의 문제에 진심인 분과 함께 일하고 싶습니다.