새로운 기능을 만들 때 가장 어려운 질문 중 하나는 ‘사용자가 정말 이 기능을 원할까?’입니다. 팀 안에서는 필요하다는 의견이 쉽게 모이지만, 실제 사용자가 같은 문제를 중요하게 생각하는지는 별도로 확인이 필요합니다. 가격을 바꾸거나, 랜딩 페이지 문구를 고칠 때도 마찬가지입니다. 출시한 뒤 지표가 떨어지거나, 고객 문의가 쌓인 다음에야 잘못된 가정을 발견하면 수정 비용이 그만큼 커질 수밖에 없습니다.
그렇다고 매번 사용자 조사를 진행하기는 어렵습니다. 참여자를 모집하고, 일정을 맞추고, 질문을 준비하고, 답변을 정리하는 과정이 필요하기 때문입니다. 시간이 촉박한 팀은 결국 동료 몇 명에게 의견을 물으며 인터뷰를 건너 뛰거나, 가상의 사용자와 인터뷰를 진행하는 방식을 활용하게 됩니다. 인터뷰를 진행한다 하더라도, 적절한 대상자를 찾는 건 또 다른 문제로 다가오죠. 실제로 제가 운영하는 오픈 채팅방에도 갖가지 프로젝트에 대한 설문조사 또는 인터뷰 요청내용이 종종 올라오는데요. 가끔 보면 채팅방에 모여있는 대상과 맞지 않는 프로젝트의 내용이 포함되기도 합니다.

‘august’는 이러한 문제를 디지털 트윈(Digital Twin)이라는 방식으로 접근하는 서비스입니다. august의 공식 설명에 따르면, Digital Twin은 일반적인 페르소나가 아니라, 실제 사용자 한 명의 행동 데이터를 바탕으로 만든 합성 사용자 모델에 가깝습니다. 제품팀은 이 Twin에게 일대일 질문을 하거나, 여러 Twin을 모아 포커스 그룹과 설문을 진행할 수 있습니다. 가격이나 새 화면을 보여주고 반응을 예측하는 식입니다.
- august는 범용 AI에게 가상의 사용자를 연기하게 하는 대신, 실제 사용자 행동 데이터를 바탕으로 만든 합성 사용자 모델(Digital Twin)에게 신기능·가격·화면을 먼저 보여주는 사용자 조사 서비스입니다.
- 제품팀은 한 명의 Twin과 대화하며 특정 사용자의 맥락을 확인하거나, 여러 Twin을 포커스 그룹·설문으로 비교하면서 출시 전에 어떤 가정을 확인해야 할지 좁힐 수 있습니다.
- 무료 계정에서는 Representative Twin으로 질문 입력·대상 선택·응답 비교의 흐름을 경험할 수 있습니다.
august의 핵심은 질문을 잘 만드는 AI가 아니라 질문을 받을 대상에 있습니다. 일반적인 AI 페르소나는 ‘온라인 쇼핑을 자주 하고 가격에 민감한 사용자’처럼 몇 가지 특징을 입력해 만듭니다. 그럴듯한 답을 얻을 수는 있지만, 특정 사용자가 실제로 무엇을 클릭했고 어떤 정보를 비교했으며, 어떤 순간에 구매를 포기했는지까지 반영하기는 어렵습니다.
august는 이 대상을 개별 사용자의 행동 데이터로 만든 디지털 트윈(Digital Twin)으로 바꿉니다. 공식 홈페이지는 Twin이 상호작용과 행동에서 의사결정 방식과 성향을 만들고, 각 상호작용을 기억으로 남긴다고 설명합니다. 그 위에 사용자의 고차원적인 생각과 동기를 정리한 반영 정보가 쌓인다는 구조입니다.

서비스에서 Digital Twin을 활용하는 방법은 크게 세 가지입니다.
하나는 1:1 인터뷰, 또 하나는 포커스 그룹 인터뷰 마지막으로 설문조사입니다. 로그인한 뒤 Twins 화면을 먼저 살펴봤는데, 처음부터 제가 연결한 사용자 데이터가 나타난 것은 아니고 서비스에서 미리 설정해둔 Robin H., Avery N., Jamie T. 같은 가상의 사용자를 볼 수 있었습니다. 총 다섯 명이 등록되어 있으며, 어떤 일을 하는지 최근 흥미있는 분야는 무엇인지 등 간단한 정보를 함께 확인할 수 있게 구성된 모습입니다. 원하는 대상을 선택하면 보다 상세한 정보를 확인할 수 있으며, 바로 인터뷰를 시작할 수 있습니다.
서비스를 통해 우리는 상황에 따라 하나의 Twin과 대화하거나, 여러 Twin을 묶어 조사할 수 있습니다. 일대일 대화는 특정 사용자의 맥락을 깊게 확인할 때 어울립니다. 예를 들어, 가격을 본 뒤 구매를 망설이는 이유, 새 기능을 찾지 못하는 이유, 랜딩페이지에서 신뢰하지 못한 문장을 질문하는데 적합합니다.
여러 명을 한 번에 살펴보고 싶다면 포커스 그룹이나 설문을 사용할 수 있습니다. 공식 홈페이지의 예시에는 ‘창업자를 위한 AI inbox를 사용해 볼래?’라는 질문을 12명의 참가자에게 보여준 결과가 나옵니다. 9명이 사용해 보고 싶다고 답했지만, 동시에 글이 너무 기계적으로 느껴진다는 의견도 나타났습니다. 흥미로운 부분은 단순히 찬반 비율만 보여주는 데서 끝나지 않는다는 점입니다. 응답을 묶어 보면 참가자들이 불편해하는 진짜 문제는 메일을 분류하는 방식보다, 너무 많은 스팸 메일 자체일 수 있다는 해석이 함께 제시됩니다.
이런 흐름은 제품팀이 ‘기능을 추가하면 좋아할 것’이라는 가정을 세우는 대신, 어떤 문제를 해결해야 반응이 달라지는지 다시 묻는데 많은 도움이 된다고 생각합니다.

august는 별도의 리서치 도구에서 결과를 확인하는 방식만 제안하지 않습니다. 예를 들어, PM이라면 Claude에서 새 기능의 PRD를 작성한 뒤, august MCP를 통해 Digital Twin의 피드백을 받을 수 있습니다. 디자이너는 Figma에서 만든 목업을 Figma 플러그인으로 보여주고, 개발자는 GitHub Pull Request에 대한 제품·UX 리뷰를 받을 수도 있습니다.
이 구조의 장점은 피드백이 작업 흐름과 떨어지지 않는다는 데 있습니다. PRD를 다 쓰고 나서 별도의 문서로 의견을 모으는 것이 아니라, 필요한 순간에 바로 질문할 기회를 잡을 수 있기 때문입니다. 화면을 넘기기 전에 어떤 요소를 오해할지 확인하고, 코드가 병합되기 전에 사용자에게 보이는 변화가 어떤 문제를 만들 수 있는지 살펴보는 식입니다.
GitHub App은 각 PR에 고객 Twin 패널의 리뷰를 남기는 방식입니다. 공식 안내에 따르면 리뷰는 병합을 막지 않는 조언 형태이며, 새 커밋이 올라오면 이전 리뷰는 이전 내용으로 접힙니다. 다만 이를 사용하려면 Twin이 준비된 august 조직과 저장소 접근 권한이 필요합니다. 단순히 GitHub App을 설치하는 것만으로 모든 저장소의 코드가 검토되는 구조는 아닙니다.
august의 공개 홈페이지에는 서비스를 실제로 어떤 질문에 사용할 수 있는지 보여주는 예시가 포함되어 있습니다. 한 화면에는 트레일 러닝화를 240달러에 구매하겠냐는 질문과 함께, 제품의 소재와 기술적 근거를 더 알고 싶다는 Twin의 답변이 표시됩니다. 단순히 ‘비싸다’라고 말하는 것이 아니라, 과거에 비싼 신발을 구매했다가 만족하지 못했던 경험과 기술 정보에 대한 요구를 연결한 형태입니다.
다른 화면에서는 실제 행동 데이터에서 만들어진 기억과 성향의 예시를 볼 수 있습니다. 장바구니를 포기했다가 할인 후 다시 구매한 행동, 여러 신발을 비교한 뒤 무게를 기준으로 필터링한 행동이 기억으로 정리되어 있습니다. 그 위에 가격에 민감하지만 품질을 중시하고, 마케팅 문구보다 구체적인 성능 근거를 신뢰한다는 반영 정보가 제시됩니다.
이 사례를 통해 알 수 있는 것은 august가 말하는 답변의 방향입니다. 사용자의 일반적인 취향을 만들어내는 것보다, 과거 행동을 근거로 다음 선택을 추정하려는 시도를 계속하기 때문입니다. 반대로 아직 알 수 없는 것도 있습니다. 이 정보가 실제 사용자 한 명의 전체 행동을 얼마나 충분히 담고 있는지, 새로운 제품이나 전혀 다른 상황에서도 같은 수준의 판단을 하는지는 사례로 확인하기 어렵습니다.
그래서 직접 질문을 던져보기로 했습니다. 인터뷰 메뉴로 진입 후 처음 입력한 질문은 “새로운 제품 기능을 평가할 때 Digital Twin의 응답을 믿으려면 무엇이 필요할까?”입니다. Interview 화면의 질문 입력창에 내용을 넣고 Start interview를 누르자, august가 질문에 맞는 대상을 자동으로 골랐고, Robin H.과의 인터뷰 화면이 열렸습니다.
화면에는 Robin이 30개 세션, 4개 조직 맥락, 358개의 경로 관찰을 바탕으로 만들어졌다는 정보가 표시됐습니다.

답변은 막연하지 않게 구체적인 조건을 바탕으로 전달되었습니다. 사용자가 실제로 자주 이용하는 화면과 작업 흐름을 짚고, 기능이 어느 화면을 바꾸는지 명확해야 한다고 말했습니다. 또 기능 도입 전후에 미리 보기 화면을 오가는 횟수가 줄어드는지, 저장 상태가 분명해지는지, 프로젝트 사이를 더 빠르게 이동할 수 있는지를 보여줘야 신뢰하겠다고 설명했습니다. 반대로 “유용하다”처럼 일반적인 답변만 나오면 신뢰하기 어렵다는 내용도 포함되었습니다.

이 답변에서 확인한 august의 장점은 결과를 찬반으로만 끝내지 않는다는 점입니다. 질문 속 기능을 특정 화면과 작업 흐름에 연결해, 제품팀이 다음에 확인할 질문을 만들어 준다는 점도 매력적인 부분이었습니다.
두 번째 질문은 실제 제품 개선 상황에 가깝게 바꿨습니다. “프로젝트 목록에 프로젝트를 한 번에 복제하는 기능이 추가된다면 무엇을 기대하고, 무엇 때문에 망설일 것 같나요?”라고 물었습니다. 이번에는 자동 선택 대신 Avery N.을 직접 골랐습니다. Avery의 화면에는 22개 세션, 6개 조직 맥락, 515개의 경로 관찰이 표시됐습니다.
Avery는 프로젝트 복제에서 확인해야 할 범위를 나눠 설명했습니다. 구성 요소와 스타일, 연결된 데이터 라이브러리 참조가 함께 복사되는지, 어느 계정으로 복사되는지, 게시 상태는 어떻게 되는지가 중요하다고 했습니다. 특히 여러 고객 조직을 오가는 사용자라면 현재 열려 있는 계정으로 조용히 복사되는 것보다, 대상 계정을 직접 선택하는 단계가 필요하다고 답했습니다. 복제 결과는 바로 공개되지 않고 미게시 상태로 만들어 미리 보고 정리할 수 있어야 한다는 조건도 덧붙였습니다.

앞서 Robin에게서 받은 “기능이 실제 작업 화면에서 어떤 변화를 만드는지 보여줘야 한다”는 답변과 비교하면, Avery는 복제 기능이라는 구체적인 상황에서 범위·계정·게시 상태라는 위험 요소를 더 분명하게 꺼낸 모습입니다. 두 답변이 완전히 다른 결론을 내린 것은 아니지만, 같은 질문을 모든 대상에게 던지는 대신 특정 사용자 프로필을 선택해 맥락이 다른 반응을 비교할 수 있다는 점은 분명히 확인할 수 있었습니다.


추가로 그룹 인터뷰도 진행해봤습니다. 온보딩 과정의 어려움으로, 팀이 특정 도구를 처음 사용하던 상황을 제공해 어떤 순간에 작업이 지연/중단되었으며, 어떤 부분에서 어려움을 겪었는지 질문했습니다. 다섯 명은 순서대로 자신의 생각을 말했고, 모더레이터는 이들의 답변을 하나로 요약해 다음에 무엇을 어떻게 물어보면 좋을지 제안해 줍니다.

august는 Digital Twin이 범용 Claude보다 특정 고객의 행동을 더 잘 예측한다고 설명합니다. 공식 평가 글에서는 한 전문 소매업체의 고객 47명을 대상으로, 실제 방문 세션의 뒷부분을 네 개의 후보 중에서 고르는 실험을 진행했다고 밝힙니다. Twin은 앞부분을 전혀 보지 않은 조건에서 66.0%를 기록했고, 기본 Claude는 25.5%, 다른 사람의 Twin은 19.1%였습니다.
세션의 첫 세 행동을 보여준 조건에서는 Twin 57.4%, 기본 Claude 38.3%로 소개됩니다. 이 숫자는 Twin이 특정 사람의 과거 행동을 알고 있을 때 범용 모델보다 유리할 수 있다는 점을 보여주는 자료입니다. 다른 사람의 Twin을 넣었을 때 점수가 낮아졌다는 결과도, 모든 Twin이 같은 답변을 만드는 것은 아니라는 설명을 뒷받침합니다.
하지만 이 평가가 제품팀의 모든 질문에 대한 정확도를 뜻하지는 않습니다. 실험은 특정 조직의 고객과 특정한 행동 예측 과제를 대상으로 했습니다. 제품 아이디어의 선호도, 가격에 대한 태도, 화면의 이해도처럼 정답을 하나로 정하기 어려운 질문에는 같은 방식의 숫자를 적용하기 어렵습니다. august의 FAQ도 여러 사례 연구가 진행 중이며, 자신의 Twin으로 직접 질문해 보는 것이 가장 좋은 확인 방법이라고 안내합니다.
august는 이미 사용자 행동 데이터가 쌓여 있고, 그 데이터를 바탕으로 제품 결정을 반복해서 내려야 하는 팀에 어울립니다. 새 기능을 만들 때마다 고객을 다시 모집하기 어렵지만, PRD·화면·가격안을 자주 바꾸는 SaaS 팀이라면 활용 장면을 만들기 쉽습니다. 특히 “이 버튼을 누를까?”보다 “이 사용자가 이 상황에서 어떤 선택을 할까?”를 알고 싶은 팀에 적합합니다.
PM은 기능 요구사항을 정리한 뒤 놓친 가정이 있는지 확인할 수 있습니다. 디자이너는 화면을 구현하기 전에 사용자 행동에 막힐 만한 부분을 찾을 수 있습니다. UX 리서처는 실제 조사 질문을 만들기 전에 여러 가설을 비교할 수 있습니다. 개발자는 GitHub PR에 대한 제품·UX 관점의 의견을 참고해, 사용자에게 보이는 문제를 미리 살필 수 있습니다.

비용 구조도 초기 실험을 시작하려는 팀을 고려한 모습입니다. 공식 홈페이지에 따르면, 구독료나 선불 비용 없이 시작할 수 있고, 가입 시 카드 없이 100 크레딧을 제공합니다. 이후 결제 수단을 추가하면 500 크레딧, 첫 번째 커스텀 Twin이 준비되면 1,000 크레딧을 추가로 받을 수 있습니다. 500 크레딧은 25달러이며, 일대일 대화는 약 20 크레딧, 포커스 그룹은 약 250 크레딧, 설문은 약 800~1,200 크레딧이 필요합니다. 실제 사용량은 질문의 길이와 복잡도에 따라 달라질 수 있습니다.
가장 먼저 확인할 부분은 데이터입니다. august의 핵심 가치는 실제 사용자의 행동을 바탕으로 한 Twin에 있지만, 그만큼 어떤 데이터를 연결했는지가 결과에 영향을 줍니다. 충분한 행동 기록이 없거나 특정 사용자 집단만 데이터에 포함되어 있다면, 결과 역시 그 범위를 벗어나기 어렵습니다. 인구통계나 평균적인 고객상만으로 실제 고객의 반응을 대신하는 제품으로 이해하면 안 됩니다.
개인정보와 보안도 중요한 조건입니다. 개인정보 처리방침은 계정 정보, 조직 멤버십, 질문과 포커스 그룹 지시문, 업로드 이미지, Figma 링크 등이 처리될 수 있다고 설명합니다. 또한 기밀·민감·규제 대상 개인정보는 조직에서 사용을 승인하지 않았다면 제출하지 말라고 안내합니다. 실제 고객 데이터를 연결하기 전에는 조직의 보안 정책과 데이터 처리 조건을 먼저 확인해야 합니다.
비용을 계산할 때는 질문의 횟수만 세어서는 안 됩니다. 일대일 대화와 포커스 그룹, 설문은 사용하는 크레딧이 크게 다릅니다. 짧은 가설을 여러 번 확인하는 방식과 많은 Twin을 한 번에 조사하는 방식의 비용이 다르기 때문입니다. 초기에는 한두 개의 구체적인 질문으로 답변의 유용성을 확인한 다음 범위를 넓히는 편이 적절합니다.
마지막으로 Twin의 답변을 실제 사용자 의견으로 바꾸어 말하지 않아야 합니다. 서비스 약관도 AI 결과가 부정확하거나 불완전하거나 실제 고객 행동을 대표하지 않을 수 있다고 명시하고 있습니다. 가격을 올려도 되는지, 개인정보를 수집해도 되는지, 중요한 접근성 문제를 무시해도 되는지처럼 사람의 판단이 필요한 결정은 Twin의 답변만으로 내릴 수 없습니다. 실제 사용자 인터뷰·사용성 테스트·제품 지표와 함께 해석해야 합니다.
august는 사용자 조사를 없애는 도구라기보다, 조사에 들어가기 전 제품팀이 더 나은 질문을 준비하도록 돕는 도구에 가깝습니다. 일반적인 AI 페르소나에게 “이런 사용자는 어떻게 생각할까?”라고 묻는 대신, 실제 행동 데이터를 바탕으로 만든 Digital Twin에게 특정 가격·화면·기능을 보여주고 반응을 살펴보려 합니다. 이 방식이 제대로 작동한다면 제품팀은 막연한 찬반 의견보다 사용자의 과거 행동과 연결된 반응을 참고할 수 있습니다.
이번에 공개 화면과 로그인한 Free tier를 통해 확인한 범위에서는 Digital Twin, 인터뷰, 포커스 그룹, Figma·GitHub 연동, 사용량 기반 가격 구조가 비교적 선명하게 제시되어 있습니다. 대표 Twin을 선택해 실제 질문과 답변을 주고받는 흐름도 경험할 수 있었습니다. 반면 제 사용자 데이터를 연결한 Twin, 화면 자극물을 첨부한 반응, 포커스 그룹의 이견 비교는 아직 직접 확인하지 못했습니다. 공개 홈페이지의 예시와 공식 평가 수치, 대표 Twin 인터뷰 결과를 하나의 성능 지표로 묶을 수 없는 이유입니다.
다시 말해 현재 무료 계정에서 경험한 august는 완성된 사용자 조사 결과를 보여주는 서비스라기보다, 자체 데이터로 Twin을 만들었을 때 어떤 질문을 던질 수 있는지 미리 보여주는 단계에 가깝습니다. 이 접근이 실제 업무에 도움이 되는지는 결국 팀이 가진 데이터로 Twin을 만들고, 그 답변을 실제 사용자 반응과 비교해 본 뒤에야 판단할 수 있습니다.
결국 august에 맡길 수 있는 일은 출시 전 가정을 빠르게 펼쳐 보고, 어떤 질문을 실제 사용자에게 물어야 하는지 좁히는 작업입니다. 최종적으로 무엇을 만들지, 누구의 데이터를 사용할지, 답변을 실제 의사결정에 어느 정도 반영할지는 제품팀이 판단해야 합니다. 실제 사용자 반응을 기다릴 시간이 부족한 팀이라면 좋은 보조 수단이 될 수 있지만, 데이터의 범위와 Twin의 답변을 검토할 여유가 없는 팀이라면 도입 전에 더 신중한 확인이 필요합니다.
<참고>
ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.