고수준의 문제해결에 집중하기 위해

들어가며: 협업의 진화를 위한 여정

Product Manager의 정책 문서 혹은 기획서는 왜 시간이 지나면 '죽은 문서'가 될까요? 플렉스팀은 이 고질적인 문제의 해답을 'AI 가상 구성원'에서 찾았습니다. 플렉스팀 Product Group은 Product Manager, Product Designer, Product Engineer가 하나의 스쿼드로 움직이며 탁월한 제품을 만들기 위해 모였습니다. 그러나 목표를 향한 열정만큼, 현실의 벽 또한 높았습니다.

각 분야 전문가들이 사용하는 언어와 도구는 본래 매우 다릅니다. 빠르게 변화하는 시장에 대응하기 위해 제품 출시에 집중하다 보니, 문서화는 우선순위에서 밀려나고 지식이 체계적으로 관리되기 어려웠습니다. 이렇게 서로 다른 생각과 결과물 사이의 간극을 메우는 과정은 눈에 보이지 않는 막대한 비용을 발생시켰습니다.

이 글은 바로 플렉스팀에서 일하는 과정을 지켜본 고민의 결과물이자, 이 모든 문제를 해결하기 위해 도입한 새로운 접근법에 대한 이야기입니다.

플렉스팀이 이 문제를 파고드는 이유

왜 플렉스팀 내부의 일하는 방식에 대해 이렇게 깊이 파고들고, 심지어 AI까지 도입하며 해결하려 할까요? 단순히 문서화 시간을 줄이고 내부 효율을 높이기 위해서만은 아닙니다. 우리 고객의 문제를 가장 잘 해결하는 방법은, 우리가 먼저 그 문제를 겪고 해결책을 만들어보는 것이라 믿기 때문입니다.

이 글을 읽는 Product Manager, Product Designer, Product Engineer와 같은 메이커라면 누구나 공감할 것입니다. 파편화된 정보, 끝없는 동기화 비용, 소통의 비효율은 우리 모두의 문제입니다. 우리는 이 문제를 해결하는 과정을 통해 얻은 학습과 기술을 고객을 위한 제품에 그대로 녹여낼 것입니다.

예를 들어, 플렉스팀의 채용 프로세스 일부를 생각해 봅시다. 수많은 이력서 속에서 우리 팀에 꼭 맞는 인재를 찾기 위해, 채용 담당자는 많은 시간을 이력서를 검토하고 맥락을 파악하는 데 씁니다. 만약 AI가 채용 공고의 맥락과 지원자들의 이력서를 깊이 이해하여, 핵심 정보를 빠르게 짚어주고, 추가 확인이 필요한 포인트를 제안하는 조력자 역할을 한다면 어떨까요? 제출해 주신 이력서를 더 깊이 해석하고, 그 너머의 이야기를 듣기 위해 후보자와의 심층 인터뷰와 같은 본질적인 업무에 더 많은 시간과 노력을 기울일 수 있습니다.

이 멋진 경험을 고객에게 제공하기 위해, 우리는 먼저 내부적으로 AI가 어떻게 여러 문서(기획서, 코드, 디자인)의 맥락을 연결하고 이해하는지 치열하게 실험하고 증명해야 했습니다. 플렉스팀의 내부 문제가 곧 고객 문제의 축소판인 셈입니다.

우리가 마주한 현실적인 문제들

제품 개발은 마치 여러 악기가 모여 하나의 교향곡을 연주하는 것과 같습니다. 하지만 현실에서는 각 연주자가 서로 다른 악보를 보고 있는 경우가 많습니다.

고수준 언어와 저수준 언어의 간극

여기서 말하는 고수준 언어란 모든 직군이 쉽게 이해할 수 있는 보편적인 언어를 의미합니다. 반면 저수준 언어는 각 직군에 특화되어 해당 분야의 전문가만 온전히 이해할 수 있는 전문적인 언어를 뜻합니다.

이러한 언어의 차이는 우리 팀에서 다음과 같이 나타납니다. Product Manager와 Product Designer는 '사용자 스토리'나 '제품 정책'과 같은 고수준의 언어로 협업 플랫폼과 디자인 도구에 명세를 작성합니다. 반면, Product Engineer는 '함수'와 '클래스'라는 저수준의 언어로 코드 저장소에 코드를 작성합니다.

여기서 근본적인 문제가 발생합니다. 문서와 디자인은 모든 직군이 함께 보며 논의할 수 있지만, 코드는 사실상 Product Engineer만 온전히 이해할 수 있습니다. 심지어 Product Engineer 직군조차 서버, 웹, 모바일 등으로 나뉘어, 각자 담당하는 영역의 코드를 중심으로 소통합니다.

이러한 정보 접근성의 비대칭과 기술적 파편화 때문에, Product Manager와 Product Designer가 의도한 고수준의 기획이 Product Engineer의 코드라는 저수준의 언어에 온전히 투영되지 못하는 결과로 이어집니다.

끝없이 발생하는 정보 동기화의 어려움

문제는 정보의 파편화에서 시작됩니다. 문서와 디자인 도구에 기록된 정보는 시간이 지나며 컨텍스트가 유실되기 쉽습니다. 프로젝트가 1년, 2년 장기화 될수록 문제는 더욱 심각해집니다. 과거에 논의했던 특정 정책이나 디자인 결정을 찾기 위해 몇 시간씩 히스토리를 '발굴'해야 하는 일이 비일비재해지고, '혹시 이 내용 어디 있었는지 아세요?'라는 질문이 팀의 소통 채널을 가득 채웁니다.

이러한 상황 속에서 구체적인 동기화 어려움도 발생합니다:

• 문서와 코드: 처음에는 일치했던 기획 문서도 바쁜 개발 일정 속에서 코드의 변경 사항을 즉시 반영하지 못합니다. 결국 문서는 '죽은 정보'가 되고, 코드를 직접 봐야만 현재 상태를 알 수 있게 됩니다.
• 코드와 작업 관리: Product Engineer가 코드를 작성했지만, 프로젝트 관리 도구에 상태를 업데이트하지 않는 경우가 자주 발생합니다. 프로젝트 관리 도구는 현실을 제대로 반영하지 못하는 허울뿐인 계획표가 되어버립니다.

이처럼 서로 다른 지식을 가진 팀원들이 각자의 공간에서 작업하는 한, 우리는 영원히 '동기화'라는 숙제를 안고 갈 수밖에 없습니다.

앞서 언급한 모든 문제들, 즉 정보의 파편화, 소통의 비효율, 그리고 히스토리의 유실은 결국 하나의 현상으로 귀결됩니다. 바로 제품 구현의 최종 단계에 있는 Product Engineer가 조직 전체의 병목이 되는 현상입니다.

하지만 이것은 결코 Product Engineer 개인의 역량이나 책임의 문제가 아닙니다. 이는 우리가 수년간 당연하게 여겨온 제품 개발 프로세스 자체의 구조적인 문제이자, 비효율적인 과거의 업무 방식이 만들어낸 필연적인 결과입니다.

이 문제를 엔지니어링 관점에서 바라본다면?

이러한 단절과 불일치는 분산 데이터베이스 시스템에서 흔히 볼 수 있는 문제와 닮아있습니다.

복제 지연 (Replication Lag)

데이터베이스에서 원본(Primary)의 변경 사항이 복제본(Replica)에 즉시 반영되지 못하고 '지연'되는 현상을 말합니다. 팀에서 '원본' 데이터는 공식적인 문서입니다. 문제는 이 새로운 정보가 공식 기획 문서에는 전혀 기록되지 않거나, 일부만 소통 채널에 파편적으로 남는다는 점입니다. 결국 어떤 팀원은 구두 합의를, 다른 팀원은 메시지 대화를, 또 다른 팀원은 낡은 문서를 각기 다른 '진실'로 인지하게 됩니다.

스플릿 브레인 (Split Brain)

데이터베이스에서 두 개의 노드가 서로 자신을 원본(Primary)이라고 주장하며 데이터 불일치가 발생하는 최악의 상황을 일컫습니다. 우리 조직에서는 이 현상이 더욱 교묘한 형태로 나타납니다. 하나의 '제목' 아래, 각 직군이 서로 다른 '표현'을 진실로 믿는 것입니다.

예를 들어, 디지털 워크플로우 개선 기능이라는 태스크가 있다고 가정해 봅시다.

• Product Manager에게 이 제목은 '사용자의 업무 효율을 50% 향상'시키는 핵심 목표를 의미합니다.
• Product Designer에게는 '직관적인 3단계 설정 과정'을 담은 디자인을 의미하고,
• Product Engineer에게는 '새로운 데이터 구조 설계'라는 구조적 과제로 해석됩니다.

이처럼 모두가 같은 '제목'을 보고 이야기하지만, 머릿속에 그리는 '표현'과 '진실'은 제각각입니다. 하나의 주제를 두고 여러 개의 뇌가 각자 다른 생각을 하는 것과 같은 이 상황이야말로, 우리가 겪는 더 무서운 '스플릿 브레인' 문제입니다.

해결의 실마리: LLM의 진짜 잠재력

이 고질적인 문제들을 해결하기 위해, 플렉스팀은 LLM을 단순히 '코드를 생성하는 도구'로 바라보지 않았습니다. 그보다 저수준 언어(코드)와 고수준 언어(기획, 디자인) 모두를 깊이 있게 이해할 수 있다는 잠재력에 주목했습니다.

많은 AI 도구들이 코드 생성을 통해 Product Engineer의 '업무 일부'를 대체하는 데 집중할 때, 우리는 다른 방향을 보았습니다. LLM의 진짜 힘은 '대체'가 아닌 '연결'과 '이해'에 있다고 믿었습니다. 즉, LLM이 기획 문서의 맥락을 이해하고, 동시에 코드의 구조를 파악하여 그 둘 사이의 관계를 추론할 수 있다면, 앞서 말한 '복제 지연'과 '스플릿 브레인' 문제를 해결할 수 있는 강력한 '조력자'가 될 수 있다는 확신이 들었습니다.

LLM은 더 이상 인간을 대신해 코딩하는 조수가 아닙니다. 파편화된 정보를 연결하고, 서로 다른 언어와 생각을 번역하며, 팀 전체에 일관된 컨텍스트를 제공하는 '지능형 허브(Intelligent Hub)'가 될 수 있는 것입니다.

실마리의 적용 - AI 가상 구성원의 탄생

LLM을 '지능형 허브'로 사용하자는 실마리를 어떻게 현실에 적용할 수 있을까요? 팀은 또 다른 '도구'를 추가하는 방식으로는 근본적인 문제를 해결할 수 없다고 생각했습니다.

문제의 본질은 '프로세스'에 있었기 때문입니다. 정보의 파편화, 언어의 불일치, 동기화의 누락은 일회성 이벤트가 아니라, 제품 개발이라는 흐름 속에서 끊임없이 발생하는 일이었습니다. 이를 해결하기 위해서는 수동적으로 사용되길 기다리는 도구가 아니라, 프로세스에 직접 참여하여 지루하고 반복적인 업무를 쉼 없이 수행하는 '능동적인 주체(Active Agent)'가 필요했습니다.

이러한 고민 끝에 'AI 가상 구성원(AI Virtual Member)'이라는 아이디어를 떠올렸습니다. LLM(Large Language Model)에게 단순히 명령을 내리는 것이 아니라, 팀의 동료로서 역할을 부여하는 것입니다.

이 AI 가상 구성원의 주된 임무는 고수준 언어와 저수준 언어 사이를 오가며 내용을 비교하고, 변경 사항을 추적하여 알리고, 파편화된 정보를 연결하여 팀 전체에 공유하는 것입니다.

솔루션: 복잡한 시스템을 위한 새로운 AI 가상 구성원

빌링 시스템처럼 복잡하고 민감한 영역은 특별한 관리가 필요합니다. 이러한 도메인 특성을 고려하여, 우는 특화된 AI 가상 구성원을 도입했습니다.

AI 가상 구성원, 브룩 포드(Brooke Ford)입니다.

브룩 포드는 인간의 페르소나를 부여받은 AI 가상 구성원이자, 복잡하고 민감한 빌링 시스템을 전담하는 스페셜리스트입니다. 그의 이름은 '시냇물(Brooke)'과 '나루터(Ford)'의 조합으로, 두 단어 모두 '흐름(Flow)'을 상징합니다. 이는 기업의 현금 흐름을 원활하게 관리하는 역할과도 완벽하게 일치합니다.

이 AI 가상 구성원은 24시간 365일, 자신의 전문 분야에서 아래와 같은 임무를 수행할 수 있으며 팀의 생산성을 극대화합니다:

'복제 지연' 해결사

"협업 채널에서 논의된 정책, 왜 문서에는 반영이 안 됐죠?"

이 AI 가상 구성원은 문서 시스템, 코드 저장소, 프로젝트 관리 도구 등 공식적인 채널뿐만 아니라 슬랙(Slack) 대화까지 모니터링하여 정보의 최종 '원본'을 추적합니다. 특정 정보가 일부 채널에만 기록되고 다른 곳에는 누락되는 '복제 지연'이 발생하면, 이를 감지하고 담당자에게 동기화를 요청하거나 관련 태스크를 생성합니다. 이를 통해 모든 팀원이 항상 최신 정보를 기반으로 일하게 만들어, 잘못된 의사결정의 위험을 원천적으로 차단합니다.

'스플릿 브레인' 통합 전문가

"'워크플로우 개선' 기능, 지금 어디까지 진행됐나요?"

이 질문에 AI 가상 구성원은 Product Manager, Product Designer, Product Engineer의 관점을 모두 통합하여 답변합니다. '워크플로우 개선'이라는 하나의 제목 아래 흩어져 있던 문서의 기획 목표, 디자인 도구의 최신 디자인 시안, 코드 저장소의 관련 코드 브랜치를 모두 연결하여 하나의 대시보드처럼 보여줍니다. 덕분에 팀원들은 각자 다른 용어를 사용하더라도 모두가 같은 맥락과 현황을 공유하게 되어, 조직의 뇌가 여러 개로 나뉘는 '스플릿 브레인' 현상을 치료합니다.

'고수준-저수준 언어' 전문 번역가

"이 기획 의도, 코드로 정확하게 구현됐나요?"

AI 가상 구성원은 인간의 언어(고수준)와 컴퓨터의 언어(저수준)를 모두 이해하는 전문 번역가입니다. 예를 들어, 문서에 명시된 '서비스 정책 적용 로직'이라는 고수준의 정책을 읽고, 개발 환경에 구현된 코드의 비즈니스 로직이 이 정책의 모든 예외 상황을 정확하게 처리하는지 검증합니다. 만약 코드 로직이 기획 의도와 다르다면, 그 차이점을 구체적으로 지적하여 두 언어 사이의 간극에서 발생하는 치명적인 오류를 막아줍니다.

마치며: 단순한 효율을 넘어, '팀 문화'를 바꾸다

이 AI 가상 구성원은 단순히 도구들을 연결하는 자동화 스크립트가 아닙니다. 팀의 소통 방식과 일하는 문화를 바꾸는 새로운 협업 패러다임입니다.

실제로 팀에서는 놀라운 변화가 시작되었습니다. 엔지니어 뿐만 아니라 다른 직군들도 더 적극적으로 '프롬프트 엔지니어링'을 시도하기 시작한 것입니다. "이 기능과 관련된 모든 정책 변경 히스토리를 알려줘", "현재 코드 기준으로 이 정책의 예외 케이스는 뭐야?" 와 같이, 과거에는 엔지니어에게 의존해야 했던 질문들을 이제는 AI 가상 구성원에게 직접 던지며 필요한 정보를 스스로 얻습니다.

이는 단순히 질문 몇 개를 덜 하는 수준의 변화가 아닙니다. 모든 구성원이 정보에 동등하게 접근하고, 스스로 문제를 해결하려는 '주도성'이 높아지는 문화적 전환입니다. 최고의 인프라는 스펙이 좋거나 복잡한 시스템이 아니라, 투명하게 공유하고 막힘없이 소통하는 '팀 문화' 그 자체라고 믿습니다. AI 가상 구성원은 바로 이 문화를 만드는 가장 강력한 촉매제가 되어주고 있습니다.

AI 가상 구성원이 지루하고 반복적인 궂은일을 도맡아 처리하는 동안, 팀은 본질적인 목표와 창의적이고 전략적인 의사결정에 집중할 수 있습니다. 이렇게 강화된 협업 구조와 팀 문화 속에서 팀은 더 넓은 관점과 시야를 바탕으로 더 빠른 실행력과 높은 완성도의 결과물을 지속적으로 만들어 낼 수 있습니다. 그리고 그 속에서 그 어느 때보다 강하게 개인은 팀의 일원으로서 성장하고 기여하게 될 것입니다.

최고의 역량을 발휘하는 동료들이 모여 시너지를 낼 때, 팀의 속도와 결과물의 수준은 이전과 비교할 수 없이 높아집니다.

당신의 팀에도 '죽은 문서'가 쌓여있나요? 끝없는 동기화 회의에 지쳐있나요? 그렇다면 이제 새로운 동료를 맞이할 때입니다. 지루하고 반복적인 일은 AI에게 맡기고, 당신과 팀은 더 가치 있고 복잡한 문제 해결에 몰입하세요. 플렉스팀의 시도가 여러분 팀의 변화를 시작하는 첫걸음이 되기를 바랍니다.