pxd story

VPC

crsmym — Mon, 12 Oct 2026 14:30:00 +0900

들어가며

최근 웹 서비스, 클라우드, 그리고 AI 애플리케이션 개발에서 인프라 구조를 이해하는 일은 점점 더 중요해지고 있습니다. 예전에는 서버 한 대에 웹 서버와 데이터베이스를 함께 올려 운영하는 경우도 많았지만, 요즘은 서비스 규모가 커지고 구조가 복잡해지면서 네트워크 설계 역시 중요한 요소가 되었습니다.

AWS를 사용하다 보면 EC2, RDS, Load Balancer, NAT Gateway 같은 여러 서비스를 만나게 됩니다. 그리고 이 서비스들을 구성할 때 거의 항상 함께 등장하는 개념이 있습니다. 바로 VPC입니다.

처음에는 VPC라는 용어가 낯설 수 있습니다. Virtual Private Cloud라는 이름도 어렵게 느껴지고, Subnet, CIDR, Route Table, Internet Gateway, Security Group 같은 용어들이 한꺼번에 나오기 때문에 더 헷갈릴 수 있습니다.

하지만 VPC는 어렵게만 볼 개념은 아닙니다.

조금 쉽게 말하면, VPC는 클라우드 안에 만드는 우리 서비스만의 네트워크 공간입니다.

이번 포스팅에서는 VPC를 이해하기 위해 필요한 기본 개념들을 일상의 예시와 함께 정리해보려 합니다.

VPC란?

VPC

정의: VPC는 Virtual Private Cloud의 약자로, 클라우드 안에 논리적으로 분리해서 만드는 나만의 가상 네트워크 공간입니다.

일상 비유: AWS라는 거대한 도시 안에 우리 회사만 사용할 수 있는 독립된 동네를 만드는 것

특징: 이 공간 안에 서버, 데이터베이스, 로드 밸런서 같은 리소스들을 배치하고, 외부 인터넷과 어떻게 연결할지, 내부 리소스끼리는 어떻게 통신할지 정할 수 있습니다.

AWS 전체를 하나의 거대한 도시라고 생각해보면, VPC는 그 도시 안에 있는 우리 회사의 독립된 구역이라고 볼 수 있습니다.

그 안에는 여러 건물이 있을 수 있습니다.

웹 서버 = 사용자가 방문하는 매장
API 서버 = 실제 업무를 처리하는 사무실
데이터베이스 = 중요한 정보를 보관하는 금고
로드 밸런서 = 방문객을 적절한 창구로 안내하는 안내 데스크

이 리소스들을 아무 곳에나 배치하는 것이 아니라, 어떤 리소스는 외부에서 접근 가능하게 하고, 어떤 리소스는 내부에서만 접근 가능하게 나누어야 합니다.

이런 구조를 만들기 위한 기본 공간이 바로 VPC입니다.

왜 VPC가 필요할까?

웹 서비스를 하나 만든다고 생각해보겠습니다.

사용자는 브라우저를 통해 서비스에 접속합니다.

서비스는 API 서버에 요청을 보내고, API 서버는 데이터베이스에서 데이터를 가져옵니다.

흐름만 보면 단순합니다.

사용자 → 웹 서버 → API 서버 → 데이터베이스

하지만 실제 운영 환경에서는 모든 서버가 외부 인터넷에 그대로 노출되면 안 됩니다.

웹 서버나 로드 밸런서는 외부 사용자의 요청을 받아야 합니다.

하지만 데이터베이스는 외부 사용자가 직접 접근하면 안 됩니다.

API 서버도 가능하다면 외부에 직접 노출하기보다는 로드 밸런서를 통해서만 접근하게 하는 것이 좋습니다.

즉 리소스마다 공개 범위가 달라야 합니다.

로드 밸런서: 외부 사용자 접근 가능
API 서버: 로드 밸런서를 통해서만 접근
데이터베이스: API 서버에서만 접근
내부 배치 서버: 외부 접근 불필요

일상적으로 비유하면 회사 건물과 비슷합니다.

회사 1층 로비는 외부 방문객이 들어올 수 있습니다.

하지만 사무실 내부, 서버실, 문서 보관실은 아무나 들어가면 안 됩니다.

클라우드에서도 마찬가지입니다.

외부에 열어야 하는 공간과 내부에 숨겨야 하는 공간을 구분해야 합니다.

VPC는 이 구분을 가능하게 해주는 기본 틀입니다.

CIDR

정의: VPC 안에서 사용할 IP 주소 범위를 정하는 방식입니다.

일상 비유: 우리 회사 동네에서 사용할 주소 체계를 정하는 것

특징: VPC를 만들 때 가장 먼저 정하는 값 중 하나이며, 이 범위 안에서 Subnet을 나누고 서버들의 내부 IP가 할당됩니다.

VPC를 만들 때 보통 이런 값을 보게 됩니다.

10.0.0.0/16

처음 보면 숫자와 슬래시 때문에 어렵게 느껴질 수 있습니다.

하지만 처음에는 이렇게 이해하면 충분합니다.

이 VPC 안에서는 10.0으로 시작하는 주소 범위를 사용하겠다.

예를 들어 VPC 주소 범위를 10.0.0.0/16으로 정했다면, 그 안에 있는 서버들은 이런 내부 주소를 가질 수 있습니다.

10.0.1.10 → 웹 서버
10.0.2.20 → API 서버
10.0.3.30 → 데이터베이스

CIDR은 결국 VPC 안에서 사용할 내부 주소 범위를 정하는 개념입니다.

Subnet

정의: VPC라는 큰 네트워크 공간을 더 작은 구역으로 나눈 것입니다.

일상 비유: 회사 부지를 사무동, 연구동, 창고, 보안 구역처럼 나누는 상황

특징: EC2, RDS 같은 리소스는 보통 특정 Subnet 안에 배치됩니다.

예를 들어 VPC 전체 주소 범위를 이렇게 잡았다고 해보겠습니다.

VPC: 10.0.0.0/16

이 VPC 안을 여러 Subnet으로 나눌 수 있습니다.

Public Subnet A:  10.0.1.0/24
Private Subnet A: 10.0.2.0/24
Public Subnet B:  10.0.3.0/24
Private Subnet B: 10.0.4.0/24

Subnet을 나누는 이유는 역할이 다른 리소스를 같은 공간에 섞어두지 않기 위해서입니다.

현실에서도 도시를 만들 때 상가 지역, 주거 지역, 공장 지역, 보안 구역을 나누듯이 클라우드에서도 역할에 따라 공간을 나눕니다.

외부 사용자가 접근해야 하는 로드 밸런서 → Public Subnet
외부에서 직접 접근하면 안 되는 API 서버 → Private Subnet
중요한 데이터를 저장하는 데이터베이스 → Private Subnet

즉 Subnet은 VPC 안에서 리소스의 위치와 역할을 나누기 위한 구역입니다.

Public Subnet과 Private Subnet

Public Subnet

정의: 인터넷과 직접 연결될 수 있는 Subnet입니다.

일상 비유: 외부 손님이 들어올 수 있는 회사 로비나 매장 입구

특징: 보통 Internet Gateway로 향하는 경로가 Route Table에 설정되어 있습니다.

Public Subnet에는 보통 외부 요청을 받아야 하는 리소스를 둡니다.

Load Balancer
Bastion Host
외부 공개용 웹 서버

다만 Public Subnet에 있다고 해서 모든 리소스가 자동으로 인터넷에 공개되는 것은 아닙니다.

외부에서 접근하려면 보통 다음 조건들이 함께 필요합니다.

VPC에 Internet Gateway가 연결되어 있어야 함
Subnet의 Route Table에 Internet Gateway 경로가 있어야 함
리소스에 Public IP가 있어야 함
Security Group에서 필요한 포트가 열려 있어야 함

즉 Public Subnet은 “외부와 연결될 수 있는 길이 있는 구역”이지, 무조건 모두에게 공개된 구역은 아닙니다.

Private Subnet

정의: 인터넷에서 직접 접근할 수 없도록 내부에 숨겨둔 Subnet입니다.

일상 비유: 회사 내부 사무실, 서버실, 금고방처럼 외부 손님이 직접 들어올 수 없는 공간

특징: 외부에서 직접 들어오는 길은 막고, 필요한 경우 NAT Gateway를 통해 내부에서 외부로 나가는 요청만 가능하게 구성합니다.

Private Subnet에는 보통 중요한 리소스를 둡니다.

Application Server
Database
Cache Server
Batch Server
Worker Server

데이터베이스를 예로 들어보겠습니다.

사용자가 웹사이트를 이용한다고 해서 데이터베이스에 직접 접속할 필요는 없습니다.

사용자는 웹 서버나 API 서버에 요청을 보내고, API 서버가 데이터베이스와 통신하면 됩니다.

사용자 → Load Balancer → API Server → Database

이 구조에서 사용자는 Load Balancer까지만 접근합니다.

API 서버와 데이터베이스는 내부에 숨겨둘 수 있습니다.

이렇게 구성하면 보안 측면에서 훨씬 안전합니다.

Route Table

정의: 네트워크 트래픽이 어디로 가야 하는지 알려주는 경로 규칙입니다.

일상 비유: 동네 안에 설치된 도로 표지판 또는 내비게이션

특징: Subnet과 연결되어 있으며, 어떤 목적지로 가는 트래픽을 어디로 보낼지 결정합니다.

VPC 안에 서버를 만들었다고 해서 트래픽이 자동으로 원하는 곳으로 이동하는 것은 아닙니다.

트래픽도 길을 알아야 합니다.

예를 들어 이런 Route Table이 있다고 해보겠습니다.

10.0.0.0/16 → local
0.0.0.0/0   → Internet Gateway

이걸 말로 풀면 이렇게 볼 수 있습니다.

10.0.0.0/16 범위의 주소는 VPC 내부에서 처리한다.
그 외 모든 목적지는 Internet Gateway로 보낸다.

여기서 0.0.0.0/0은 쉽게 말해 “나머지 모든 곳” 정도로 이해하면 됩니다.

Route Table이 중요한 이유는 길이 없으면 트래픽이 갈 수 없기 때문입니다.

서버가 켜져 있고 Security Group이 열려 있어도, Route Table에 경로가 없으면 통신이 되지 않을 수 있습니다.

현실에서도 건물이 아무리 잘 지어져 있어도, 그 건물로 가는 도로가 끊겨 있으면 갈 수 없습니다.

VPC에서도 마찬가지입니다.

Internet Gateway

정의: VPC가 외부 인터넷과 통신할 수 있게 해주는 출입구입니다.

일상 비유: 우리 회사 동네와 외부 도로를 연결하는 정문

특징: Public Subnet에서 인터넷으로 나가거나, 인터넷에서 Public Subnet의 리소스로 들어오기 위해 사용됩니다.

VPC는 기본적으로 독립된 네트워크 공간입니다.

그 공간이 외부 인터넷과 통신하려면 출입구가 필요합니다.

그 역할을 하는 것이 Internet Gateway입니다.

하지만 Internet Gateway를 VPC에 연결했다고 해서 모든 리소스가 바로 인터넷과 연결되는 것은 아닙니다.

Internet Gateway 연결
Route Table 경로 설정
Public IP 할당
Security Group 포트 허용

이 조건들이 함께 맞아야 외부에서 접근할 수 있습니다.

Internet Gateway는 정문입니다.

하지만 정문이 있다고 해서 모든 방의 문이 열려 있는 것은 아닙니다.

NAT Gateway

정의: Private Subnet 안에 있는 리소스가 외부 인터넷으로 요청을 보낼 수 있게 도와주는 서비스입니다.

일상 비유: 외부에 직접 나갈 수 없는 내부 직원 대신 심부름을 다녀오는 담당자

특징: Private Subnet의 리소스가 외부로 나갈 수는 있게 하지만, 외부에서 Private Subnet으로 직접 들어오게 하지는 않습니다.

Private Subnet의 서버도 가끔 외부 인터넷이 필요할 때가 있습니다.

OS 패키지 업데이트
Docker 이미지 다운로드
외부 API 호출
라이브러리 설치
보안 패치 다운로드

하지만 이런 이유로 Private Subnet의 서버를 인터넷에 직접 노출하는 것은 좋지 않습니다.

이때 사용하는 것이 NAT Gateway입니다.

흐름은 대략 이렇습니다.

Private Subnet의 서버
  ↓
NAT Gateway
  ↓
Internet

즉 서버가 직접 밖으로 나가는 것이 아니라, NAT Gateway가 외부 요청을 대신 처리해주는 방식입니다.

중요한 점은 NAT Gateway가 외부에서 Private Subnet으로 들어오기 위한 문은 아니라는 것입니다.

NAT Gateway는 내부 리소스가 외부로 나가기 위한 통로입니다.

Security Group

정의: EC2, RDS, Load Balancer 같은 리소스 단위에 적용하는 가상 방화벽입니다.

일상 비유: 각 건물 출입문 앞에 있는 보안 담당자

특징: 어떤 IP 또는 어떤 리소스가 어떤 포트로 들어올 수 있는지 제어합니다.

예를 들어 웹 서버의 Security Group은 이렇게 설정할 수 있습니다.

80번 포트  → 전체 허용
443번 포트 → 전체 허용
22번 포트  → 내 사무실 IP에서만 허용

데이터베이스의 Security Group은 더 엄격하게 설정할 수 있습니다.

3306번 포트 → API 서버에서만 허용
외부 인터넷 → 직접 접근 불가

이렇게 하면 사용자는 웹 서버에는 접근할 수 있지만, 데이터베이스에는 직접 접근할 수 없습니다.

Security Group의 중요한 특징은 stateful이라는 점입니다.

쉽게 말하면 요청과 응답의 관계를 기억한다는 뜻입니다.

서버가 외부 API에 요청을 보냈다면, 그 요청에 대한 응답은 자연스럽게 다시 서버로 돌아올 수 있습니다.

요청과 응답의 흐름을 기억하기 때문입니다.

Network ACL

정의: Subnet 단위로 적용하는 네트워크 접근 제어 규칙입니다.

일상 비유: 동네 입구에 있는 검문소

특징: Security Group보다 더 넓은 범위인 Subnet 단위에서 인바운드, 아웃바운드 트래픽을 허용하거나 차단합니다.

Security Group이 각 건물의 출입문 보안이라면, Network ACL은 동네 입구의 검문소에 가깝습니다.

Security Group = 건물 출입문 보안
Network ACL    = 동네 입구 검문소

Network ACL의 중요한 특징은 stateless라는 점입니다.

Security Group은 요청과 응답의 관계를 기억하지만, Network ACL은 기억하지 않습니다.

그래서 들어오는 규칙과 나가는 규칙을 각각 따로 봐야 합니다.

처음에는 이렇게 기억하면 좋습니다.

Security Group은 리소스 단위의 방화벽
Network ACL은 Subnet 단위의 방화벽
Security Group은 stateful
Network ACL은 stateless

Availability Zone

정의: 하나의 리전 안에 있는 물리적으로 분리된 데이터센터 구역입니다.

일상 비유: 같은 도시 안에 있지만 서로 떨어져 있는 여러 지점의 사무실 또는 창고

특징: 장애에 대비하기 위해 리소스를 여러 Availability Zone에 나눠 배치할 수 있습니다.

AWS에서 VPC는 특정 리전 안에 생성됩니다.

예를 들어 서울 리전을 사용한다면, VPC는 서울 리전 안에 만들어집니다.

그리고 그 리전 안에는 여러 Availability Zone이 있습니다.

운영 환경에서는 보통 Public Subnet과 Private Subnet을 여러 AZ에 나눠 구성합니다.

AZ A
- Public Subnet A
- Private Subnet A

AZ C
- Public Subnet C
- Private Subnet C

이렇게 구성하는 이유는 장애에 대비하기 위해서입니다.

모든 서버를 하나의 구역에만 배치했는데 그 구역에 문제가 생기면 서비스 전체가 영향을 받을 수 있습니다.

반대로 여러 AZ에 나눠두면 한쪽에 문제가 생겨도 다른 쪽에서 서비스를 계속할 가능성이 높아집니다.

전체 흐름 예시

간단한 웹 서비스를 하나 만든다고 가정해보겠습니다.

요구사항은 다음과 같습니다.

사용자는 웹사이트에 접속할 수 있어야 함
외부 요청은 Load Balancer가 받아야 함
Application Server는 외부에 직접 노출하지 않음
Database는 Application Server에서만 접근 가능해야 함
Application Server는 외부 API 호출이나 패키지 업데이트가 가능해야 함

이 구조를 VPC로 표현하면 대략 이렇게 볼 수 있습니다.

VPC: 10.0.0.0/16

Public Subnet
- Load Balancer
- NAT Gateway

Private Subnet
- Application Server
- Database

사용자의 요청 흐름은 이렇게 됩니다.

사용자
  ↓
Internet
  ↓
Internet Gateway
  ↓
Load Balancer
  ↓
Application Server
  ↓
Database

Private Subnet의 Application Server가 외부 인터넷으로 나가야 할 때는 이렇게 됩니다.

Application Server
  ↓
NAT Gateway
  ↓
Internet

보안 규칙은 대략 이런 식으로 잡을 수 있습니다.

Load Balancer
- 80, 443 포트: 전체 인터넷에서 허용

Application Server
- 애플리케이션 포트: Load Balancer에서만 허용

Database
- DB 포트: Application Server에서만 허용

이 구조의 핵심은 단순합니다.

외부 사용자는 Load Balancer까지만 접근합니다.

Application Server와 Database는 외부에 직접 노출하지 않습니다.

Private Subnet의 서버가 외부로 나갈 필요가 있을 때는 NAT Gateway를 사용합니다.

핵심 구분

VPC를 처음 공부할 때는 여러 용어가 한꺼번에 나오기 때문에 헷갈리기 쉽습니다.

그래서 각 개념을 역할 중심으로 구분해보면 이해가 조금 쉬워집니다.

VPC
→ 클라우드 안에 만드는 우리 서비스의 독립된 네트워크 공간

CIDR
→ VPC 안에서 사용할 주소 범위

Subnet
→ VPC 안을 역할별로 나눈 구역

Public Subnet
→ 인터넷과 직접 연결될 수 있는 구역

Private Subnet
→ 외부에서 직접 접근하지 못하게 숨겨둔 구역

Route Table
→ 트래픽이 어디로 가야 하는지 알려주는 경로 규칙

Internet Gateway
→ VPC와 인터넷을 연결하는 정문

NAT Gateway
→ Private Subnet의 리소스가 외부로 나가도록 도와주는 대리인

Security Group
→ 리소스 단위의 방화벽

Network ACL
→ Subnet 단위의 방화벽

Availability Zone
→ 장애에 대비하기 위해 나눠진 데이터센터 구역

실무에서의 고려사항

1) 데이터베이스는 가능하면 Private Subnet에 두기

데이터베이스는 외부 사용자에게 직접 노출될 이유가 거의 없습니다.

일반적으로는 Application Server만 데이터베이스에 접근하도록 구성하는 것이 좋습니다.

사용자 → Load Balancer → Application Server → Database

2) Public Subnet에는 꼭 필요한 리소스만 두기

Public Subnet은 인터넷과 직접 연결될 수 있는 구역입니다.

따라서 아무 리소스나 Public Subnet에 두는 것은 좋지 않습니다.

보통 외부 요청을 받아야 하는 Load Balancer나 Bastion Host 정도를 Public Subnet에 두고, 실제 Application Server는 Private Subnet에 두는 구성이 많이 사용됩니다.

3) Private Subnet의 외부 통신은 NAT Gateway로 처리하기

Private Subnet의 서버도 외부 API 호출이나 패키지 업데이트가 필요할 수 있습니다.

이때 서버를 Public Subnet으로 옮기기보다는 NAT Gateway를 통해 외부로 나가게 구성하는 것이 좋습니다.

4) Security Group은 최소한으로 열기

Security Group은 필요한 포트만 열어야 합니다.

나쁜 예시:
3306 포트를 전체 인터넷에 허용

좋은 예시:
3306 포트를 Application Server에서만 허용

특히 SSH, DB 포트처럼 민감한 포트는 전체 인터넷에 열어두지 않는 것이 좋습니다.

마치며

정리해보면, VPC는 클라우드 안에 만드는 우리 서비스만의 독립된 네트워크 공간이라고 볼 수 있습니다. 처음에는 CIDR, Subnet, Route Table, Internet Gateway, NAT Gateway, Security Group, Network ACL 같은 용어들이 한꺼번에 나와 어렵게 느껴질 수 있지만, 각각의 역할을 일상적인 비유로 이해하면 훨씬 덜 복잡하게 느껴집니다.

VPC는 회사의 사유지와 비슷합니다.

CIDR은 그 사유지 안에서 사용할 주소 체계이고, Subnet은 역할별로 나눈 구역입니다.

Route Table은 길 안내 표지판이고, Internet Gateway는 외부로 나가는 정문입니다.

NAT Gateway는 내부 리소스를 대신해 외부 요청을 처리하는 심부름 담당자이며, Security Group은 각 건물의 출입문 보안, Network ACL은 동네 입구의 검문소라고 볼 수 있습니다.

결국 VPC를 이해한다는 것은 단순히 서버를 어디에 둘지 정하는 문제가 아닙니다.

외부에 어떤 문을 열어둘지, 어떤 리소스는 내부에 숨길지, 어떤 길로 트래픽을 보내야 할지, 누가 어떤 포트로 접근할 수 있는지를 설계하는 일입니다.

처음부터 모든 네트워크 이론을 완벽하게 이해할 필요는 없다고 생각합니다.

다만 VPC를 볼 때마다 다음 질문을 던져보면 좋을 것 같습니다.

외부에서 직접 접근이 가능해야 할까?
내부에서만 접근하면 될까?
인터넷으로 나가는 길이 필요할까?
누가 어떤 포트로 접근할 수 있어야 할까?

이러한 질문들에 답하다 보면 VPC는 막연하게 어려운 네트워크 용어 묶음이 아니라, 서비스를 안전하고 안정적으로 운영하기 위한 기본 설계 도구로 보이기 시작할 것입니다.

읽어주셔서 감사합니다.

서비스 아이디어 발굴부터 프로토타입까지, AI와 함께 일해본 기록 - 2편

Haeun Choi — Thu, 1 Oct 2026 07:50:36 +0900

1편에서는 아이데이션 과정에서 AI Persona를 활용해 여러 사용자의 관점에서 아이디어를 바라보고, 고도화의 힌트를 얻었던 경험을 이야기했습니다.

이번 편에서는 아이디어가 어느 정도 구체화된 이후, UX 리서처로서 Figma Make를 활용해 직접 프로토타입까지 만들어본 경험을 이야기해보려고 합니다.

평소에는 서비스 아이디어와 UX 컨셉을 구체화하는 데 집중했다면, 이번에는 AI를 활용해 그 아이디어를 실제 화면으로 옮기는 과정까지 직접 경험해 봤습니다. 그 과정에서 컨셉 단계와는 또 다른 고민이 필요했고, 동시에 AI 프로토타이핑을 활용해 아이디어를 다시 바라보고 고도화하기도 했습니다.

이번 글에서는 UX 리서처의 관점에서 AI 프로토타이핑을 해보며 무엇을 새롭게 고민했고, 어떤 방식으로 활용할 수 있었는지를 정리해보려고 합니다.

Figma Make가 임의로 채우는 ‘빈칸’ 줄이기

처음에는 아이디어의 배경과 컨셉, 주요 사용 장면 정도만 전달하면 Figma Make가 어느 정도 알아서 화면으로 풀어줄 것이라고 생각했습니다.

하지만 실제 결과를 받아보니 정보 구성이 다소 엉성하거나, 팀이 중요하게 생각한 내용이 빠지기도 했고, 컨셉은 맞지만 우리가 의도했던 경험과는 다른 화면이 나오기도 했습니다.

돌이켜보면 아이디어나 UX 컨셉을 정의할 때와 실제 화면을 만들 때 필요한 구체성의 수준 자체가 달랐습니다.

컨셉 단계에서는 주요 기능을 중심으로 시스템이 어떤 정보를 바탕으로 무엇을 판단하며, 어떤 경험을 제공할 것인지 정도를 정의해도 충분했습니다. 하지만 실제 화면으로 구현하기 위해서는 그보다 훨씬 더 구체적인 정의가 필요했습니다.

1. 컨셉과 화면 사이의 빈칸 채우기

프로토타이핑 단계에서 가장 크게 느낀 차이는 아이디어나 UX 컨셉을 정의할 때와 실제 화면을 만들 때 필요한 구체성의 수준이 다르다는 것이었습니다.

아이디어를 발전시키는 단계에서는 주요 기능을 중심으로 시스템이 어떤 정보를 활용해 무엇을 판단하고, 어떤 경험을 제공할 것인지 정도를 정의해도 충분했습니다. 이 단계에서는 서비스 전체의 구조와 핵심 가치가 명확한지가 더 중요했기 때문입니다.

예를 들어 여러 조건과 데이터를 종합해 시스템이 사용자를 대신해 최적의 시점과 방법을 판단하고 조정해 주는 서비스라면, 컨셉 단계에서는 어떤 정보를 활용하고 무엇을 자동으로 판단·조정하는지 정도만 정의해도 아이디어를 설명할 수 있었죠.

하지만 이를 실제 화면으로 옮기려고 하니 훨씬 더 많은 것을 결정해야 했습니다.

사용자는 현재 어떤 상태를 확인해야 하는지
시스템이 무엇을 대신 판단했는지, 어디까지 보여줄지
왜 그런 판단을 했는지, 어떤 정보로 설명할지
어떤 메시지가 있어야 현재 상황을 이해할 수 있는지
사용자는 확인만 하면 되는지, 직접 수정하거나 개입할 수도 있어야 하는지
상세한 정보는 언제, 어느 수준까지 보여줄지

처럼 시스템이나 서비스 차원에서 정의했던 기능을 실제 사용자 경험으로 전달하기 위해 필요한 정보와 행동을 하나씩 다시 정의해야 했습니다.

Figma Make에 프롬프트를 작성할 때도 단순히 “이 화면에서는 ○○ 기능을 보여준다” 정도로는 부족했습니다. 각 씬을 다시 여러 화면으로 세분화하고, 화면마다 최상단에서 무엇을 보여줄지부터 각 섹션에 어떤 정보와 메시지가 들어가야 하는지까지 구체적으로 작성해야만 원하는 수준의 화면 결과를 받을 수 있었습니다.

결국 컨셉 단계에서는 “서비스가 무엇을 해줄 것인가”를 중심으로 생각했다면, 프로토타입 단계에서는 한 단계 더 나아가 “사용자는 그것을 화면에서 무엇을 통해 이해하고, 어떻게 확인하고, 필요할 때 개입할 것인가”까지 구체화해야 했습니다. 직접 프로토타입을 만들어보면서 컨셉을 실제 사용자 경험으로 연결하기 위해 생각보다 훨씬 많은 콘텐츠와 정보가 정의되어야 한다는 것을 체감했습니다.

2. 컨셉을 어떤 UI로 표현할지까지 고민하기

정보와 콘텐츠를 구체적으로 정의한 뒤에는 또 다른 고민이 생겼습니다. 그 정보를 실제 화면에서 어떤 UI로 표현할 것인가였습니다.

평소 UX 리서처로 리서치 프로젝트를 할 때는 사용자 문제를 정의하고 서비스 아이디어와 컨셉을 구체화하는 데 집중하기 때문에, 실제 화면의 표현 방식까지 깊게 고민할 일은 많지 않습니다. 하지만 직접 프로토타입을 만들다 보니, 컨셉 단계에서는 자유롭게 나열할 수 있었던 기능과 정보를 한정된 화면 안에서는 모두 같은 깊이로 보여줄 수 없다는 것부터 고민해야 했습니다.

어떤 정보를 가장 먼저 보여줄지, 무엇은 상세 영역으로 내려야 할지, 어떤 기능을 사용자가 바로 조작할 수 있게 할지 등 정보의 우선순위와 위계를 결정해야 했습니다.또 같은 정보라도 카드, 그래프, 진행 상태 등 어떤 UI 형태로 표현하느냐에 따라 화면의 인상과 강조되는 지점이 크게 달라졌습니다.

물론 정보 구성을 충분히 구체적으로 입력하면 Figma Make가 기본적인 UI는 알아서 만들어줬습니다. 다만 몇 번 사용해보니, 화면의 목적이나 정보가 달라도 결과물이 전반적으로 비슷한 UI 형태로 생성되는 경우가 대부분이었죠. 기능적으로는 문제가 없더라도 AI가 선택한 UI 패턴이 항상 저희가 생각한 최선의 표현 방식은 아니었습니다.

그래서 원하는 UI가 있을 때는 말로 하나씩 설명하기보다 다른 서비스의 레퍼런스 이미지를 직접 보여주는 방식을 활용했습니다. 예를 들어 움직이는 대상의 실시간 위치와 진행 현황을 표현하고 싶을 때는 배달 앱의 라이더 현황 화면을 캡처해 전달했습니다. 그러면 Figma Make가 레퍼런스를 참고해 의도한 형태에 훨씬 가깝게 구현해 줬습니다. “토글 UI를 활용해 줘”, “바 그래프를 도넛 그래프로 바꿔줘”처럼 세세하게 설명하는 것보다 “이 화면의 UI 구성을 참고해 줘”라고 이미지를 함께 전달하는 편이 훨씬 빠르고 정확했습니다.

이 과정을 통해 디자이너들이 다양한 서비스와 디자인 레퍼런스를 많이 참고하는 이유도 체감할 수 있었습니다. 말로 설명하기 어려운 표현 방식과 정보 구조를 레퍼런스 하나로 훨씬 명확하게 전달할 수 있었기 때문입니다.

AI 프로토타이핑을 컨셉 고도화에 활용하기

Figma Make를 활용하면서 유용했던 점은 아이디어를 빠르게 화면으로 만들어보고 다시 논의할 수 있었다는 것이었습니다. 직접 화면으로 옮기는 과정에서 컨셉 단계에서는 충분히 정의하지 않았던 부분까지 고민하게 됐고, 구현된 형태를 보며 아이디어를 다시 검토할 수도 있었습니다.

이 경험을 바탕으로 UX 리서처의 관점에서 AI 프로토타이핑을 활용하며 중요하다고 느낀 점을 세 가지로 정리해봤습니다.

Lessons Learned 1. 컨셉을 화면으로 옮기려면 한 번 더 ‘번역’이 필요하다.

아이디어 단계에서는 주요 기능과 제공 가치만으로도 컨셉을 설명할 수 있지만, 실제 화면으로 옮기려면 그 기능이 사용자에게 어떻게 전달될지까지 구체화해야 했습니다. 사용자가 어떤 정보를 봐야 하는지, 어떤 메시지를 통해 상황을 이해해야 하는지, 무엇을 확인하거나 직접 조정할 수 있어야 하는지까지 정의해야 비로소 화면으로 연결할 수 있었습니다.

AI가 UI를 만들어준다고 해도 컨셉과 화면 사이의 구체적인 UX 경험까지 자동으로 해결되는 것은 아니었습니다.

Lessons Learned 2. AI가 임의로 판단해야 하는 ‘빈칸’을 최대한 줄여야 한다.

컨셉만 설명하고 나머지를 알아서 만들어달라고 하면 빠르게 결과를 얻을 수는 있지만, 각 화면에 어떤 정보가 어떤 순서로 들어가야 하는지 구체적으로 정의하고, 원하는 표현 방식이 있다면 레퍼런스 이미지까지 함께 전달했을 때 훨씬 원하는 결과에 가까워졌습니다.

결국 무엇을 보여줄지는 텍스트로 구체적으로 정의하고, 어떻게 보여줄지는 레퍼런스를 활용해 AI가 임의로 채워야 할 영역을 줄이는 것이 중요했습니다. 결과를 반복해서 수정하기보다 처음부터 구체적인 인풋을 주는 편이 훨씬 효율적이었습니다.

Lessons Learned 3. 빠른 프로토타이핑을 아이디어 검토와 고도화의 반복에 활용할 수 있다.

화면으로 만들어보면 서비스의 핵심 가치가 충분히 드러나는지, 어떤 정보가 부족한지, 실제 서비스 경험으로 연결했을 때 어색한 부분은 없는지를 더 구체적으로 살펴볼 수 있었습니다. 특히 AI를 활용하면 화면을 처음부터 직접 구현하는 것보다 훨씬 빠르게 대략적인 형태를 만들어볼 수 있기 때문에, 컨셉 → 프로토타입 → 검토 → 컨셉 보완의 과정을 부담 없이 반복해볼 수 있었습니다.

그래서 UX 리서처가 미래 서비스 컨셉을 만들 때도 AI 프로토타이핑을 단순한 화면 제작 도구가 아니라, 아이디어를 빠르게 눈에 보이는 형태로 만들어보고 다시 고도화하는 방법으로 활용해볼 수 있겠다고 느꼈습니다.

마치며

돌이켜보면 1편에서 다룬 AI Persona도, 이번 Figma Make를 활용한 프로토타이핑도 결국 고민하고 판단하는 주체는 사람이라는 점에서는 같았습니다.

AI Persona는 새로운 관점과 질문을 만들어주는 데 도움을 줬고, Figma Make는 생각한 내용을 빠르게 형태로 만들어 다시 바라보는 데 도움을 줬습니다. 하지만 그 결과를 어떻게 해석하고 무엇을 선택할지는 여전히 사람의 몫이었습니다.

그래서 중요한 것은 AI를 많이 사용하는 것이 아니라, 프로젝트의 단계와 목적에 맞춰 적재적소에 활용하는 것이라고 생각합니다. 퍼소나든 프로토타이핑이든 사람의 고민을 대신하기보다, 고민의 폭과 깊이를 더하고 결과물의 완성도를 높이는 데 활용하는 것이 AI를 잘 사용하는 방법이라고 느꼈습니다.

SEO와 GEO 운영 루틴

doworld — Mon, 21 Sep 2026 07:50:41 +0900

SEO/GEO는 발행으로 끝나지 않는다. 글을 올리고 색인되고 몇 주가 지나면 그때부터 운영이 시작된다.

어떤 글은 검색 결과에 보이지만 클릭되지 않는다. 어떤 글은 클릭은 오지만 전환이 없다. 어떤 글은 10위 근처에서 오래 멈춘다. 어떤 글은 예전에는 잘 됐지만 지금은 정보가 낡았다. 그리고 이제는 하나가 더 붙는다. 검색 결과에는 보이는데 AI 답변에는 전혀 언급되지 않을 수 있다.

그래서 운영 루틴은 검색 성과와 AI 답변 노출을 함께 본다.

검색 성과: 노출, 클릭, CTR, 순위, 전환, 색인
AI 답변 노출: 브랜드 언급, 인용 URL, 설명 정확도, 경쟁 브랜드, 수정 필요 항목

SEO가 검색 결과에서 발견되는 상태를 관리한다면, GEO는 AI 답변 안에서 브랜드와 콘텐츠가 어떻게 쓰이는지 확인하는 작업까지 포함한다.

새 글보다 기존 글이 먼저일 때가 많다

SEO를 시작하면 대부분 새 글을 더 쓰려고 한다. 하지만 실무에서는 기존 글 리라이트가 더 빠르게 성과를 만들 때가 많다.

이유는 단순하다.

이미 인덱싱되어 있다
이미 노출 데이터가 있다
어떤 쿼리로 보이는지 확인할 수 있다
제목 문제인지 본문 문제인지 판단할 힌트가 있다
내부 링크와 구조를 조금만 보강해도 개선 여지가 있다
AI 답변에서 잘못 설명되는 지점을 원문 수정으로 바로잡을 수 있다

새 글은 가설에 가깝다. 기존 글은 데이터가 있는 자산이다.

예를 들어 어떤 글이 월 5,000회 노출되는데 CTR이 0.5%라면 제목과 메타를 먼저 의심할 수 있다. 평균 순위가 9~15위 사이에 오래 있다면 본문 깊이, FAQ, 비교표, 내부 링크가 부족할 수 있다. AI가 브랜드를 잘못 설명한다면 공식 설명, FAQ, 제품 페이지, 외부 프로필 수정까지 검토할 수 있다.

리라이트는 문장을 예쁘게 다듬는 일이 아니다. 병목을 찾고 고치는 운영 작업이다.

SEO에서 먼저 볼 데이터

검색 성과를 볼 때는 적어도 네 가지를 확인한다.

1. Search Console

Search Console은 검색 성과를 보는 기본 창구다.

문서 단위로 아래 항목을 본다.

노출수
클릭수
CTR
평균 순위
실제 노출 쿼리
페이지별 성과
색인 상태

여기서 봐야 할 질문은 이것이다.

이 문서는 어떤 검색어에서 보이고 있고, 사용자는 왜 클릭하거나 클릭하지 않는가?

의도한 키워드와 실제 노출 쿼리가 다를 수 있다. AI SEO 전략을 노리고 쓴 글이 실제로는 ChatGPT 블로그 노출로 보인다면 본문을 조정할지, 별도 글을 만들지 판단한다.

2. GA4 또는 전환 데이터

검색 유입이 있다고 끝은 아니다. 들어온 사용자가 무엇을 하는지도 본다.

확인할 항목은 아래와 같다.

SEO 유입 후 체류와 참여
다음 페이지 이동
가입, 문의, 구매, 다운로드 같은 전환
CTA 클릭
문서별 전환 기여
이탈 구간

트래픽은 많지만 전환이 약한 글은 제목보다 다음 행동 설계가 문제일 수 있다. 내부 링크, CTA, 관련 사례, 제품 연결부를 다시 본다.

3. 실제 검색 결과

리라이트 전에는 검색 결과를 다시 본다. 예전에는 통하던 형식이 지금도 통한다는 보장은 없다.

확인할 것은 아래와 같다.

상위 문서가 가이드인지, 리스트인지, 비교표인지
FAQ, 영상, 포럼, 지도, 쇼핑 결과가 강해졌는지
경쟁 문서의 제목이 어떻게 바뀌었는지
상위 문서가 더 깊어졌는지
사용자 의도가 정보형에서 비교형이나 거래형으로 이동했는지

검색 결과가 바뀌었는데 기존 문서 구조를 그대로 두면 밀릴 수 있다.

4. 사이트 구조와 기술 상태

문서 자체가 괜찮아도 사이트 구조 때문에 성과가 안 날 수 있다.

확인할 항목은 아래와 같다.

내부 링크가 충분한가
허브 문서에서 연결되는가
같은 키워드를 노리는 문서가 여러 개인가
canonical이 올바른가
중복 URL이 있는가
색인 제외나 noindex 문제가 있는가
페이지 속도와 모바일 표시가 괜찮은가

특히 캐니벌라이제이션은 제목 수정으로 해결되지 않는다. 문서 역할을 다시 나누거나 통합한다.

AI 답변 노출도 따로 기록한다

GEO 운영에는 AI 답변 테스트가 들어간다. 아직 Search Console처럼 표준화된 대시보드는 없다. 그래서 직접 질문을 정하고 반복 관찰한다.

테스트 질문은 세 종류로 나누면 좋다.

질문	유형예시
카테고리 추천	SEO/GEO 분석 도구 추천해줘
문제 해결	AI 답변에 브랜드가 나오게 하려면 무엇을 봐야 해?
브랜드 확인	GEONIQ은 어떤 서비스야?
비교 질문	GEONIQ과 일반 SEO 도구는 뭐가 달라?
출처 질문	SEO/GEO를 배울 만한 신뢰할 자료 알려줘

기록 양식은 단순하면 된다.

질문 / 플랫폼 / 날짜 / 브랜드 언급 여부 / 인용 URL / 설명 정확도 / 경쟁 브랜드 / 수정 필요 액션

확인할 항목은 아래와 같다.

우리 브랜드가 언급되는가
설명이 맞는가
출처로 어떤 URL이 쓰이는가
경쟁 브랜드는 누구인가
오래된 정보나 잘못된 설명이 있는가
답변에 필요한 원문이 우리 사이트에 있는가

AI 답변은 매번 달라질 수 있다. 한 번의 결과만 보고 결론을 내리면 안 된다. 같은 질문을 같은 조건으로 반복해서 보고, 변화 추세를 기록한다.

리라이트가 필요한 신호

모든 글을 계속 고칠 필요는 없다. 먼저 신호를 본다.

신호	의미	먼저 볼 것
노출은 높은데 CTR이 낮다	보이지만 클릭되지 않음	제목, 메타, 검색 의도
6~20위권에 오래 머문다	보강 여지가 있음	본문 깊이, 구조, 내부 링크
예전엔 좋았는데 하락한다	정보나 경쟁력이 낡음	최신성, 경쟁 문서, 검색 결과 변화
실제 노출 쿼리와 본문이 어긋난다	의도 불일치	제목, H2 구조, 문서 목적
비슷한 문서끼리 충돌한다	내부 경쟁 가능성	문서 통합, 역할 재분배
AI가 브랜드를 잘못 설명한다	공식 정보와 외부 설명이 부족함	제품 설명, FAQ, 외부 프로필
AI 답변에 경쟁사만 나온다	답변 후보 신호가 약함	비교 문서, 외부 신뢰, 인용 가능한 원문

리라이트가 답이 아닌 경우도 있다.

발행한 지 얼마 안 돼 데이터가 너무 적다
기술 문제가 커서 문서 수정만으로 해결되지 않는다
기존 글을 고치기보다 별도 검색 의도의 새 문서가 낫다
비즈니스 가치가 낮아 고쳐도 얻을 것이 작다

운영은 고칠 글과 놔둘 글을 구분하는 일에서 시작한다.

리라이트 판단 기준

문제를 여섯 가지 중 어디에 넣을지만 정해도 수정 방향이 빨라진다.

문제	증상	먼저 고칠 것
CTR 문제	노출은 많은데 클릭이 낮다	Title, Meta Description, 서론 첫 문장
순위 정체	6~20위권에 오래 머문다	아웃라인, 소주제, 비교표, 예시, FAQ, 내부 링크
의도 불일치	실제 노출 쿼리와 문서 내용이 어긋난다	문서 목적, 제목, 서론, H2 구조
최신성 문제	예전엔 좋았지만 최근 하락한다	최신 정보, 사례, 스크린샷, 수정일, 관련 FAQ
구조 문제	길지만 읽기 어렵고 답이 늦다	초반 답변, H2/H3 재배치, 중복 삭제
AI 답변 설명 문제	AI가 브랜드를 빼거나 틀리게 설명한다	공식 설명, 제품 페이지, FAQ, 비교 문서, 외부 프로필

운영 글에서 필요한 것은 긴 리라이트 매뉴얼이 아니라, 어떤 문제를 어떤 수정으로 연결할지 정하는 기준이다.

우선순위는 기회와 가치로 정한다

모든 글을 다 고칠 수는 없다. 우선순위를 정한다.

간단한 기준은 아래와 같다.

우선순위 = 기회 크기 × 비즈니스 가치 × 개선 가능성

각 항목은 이렇게 보면 된다.

항목	질문
기회 크기	노출, 순위, 검색량, AI 답변 질문 수요가 충분한가
비즈니스 가치	가입, 문의, 구매, 브랜드 신뢰에 도움이 되는가
개선 가능성	제목, 구조, 내부 링크, 최신화, 공식 설명 수정으로 바뀔 여지가 있는가

우선순위가 높은 문서는 아래와 같다.

노출이 높은데 CTR이 낮은 문서
전환 가능성이 높은데 성과가 약한 문서
허브 문서인데 품질이 약한 문서
6~20위권에서 정체된 문서
하락세가 뚜렷한 문서
AI가 자주 답하는 질문과 연결된 문서
브랜드 설명 오류를 바로잡을 공식 문서

가장 약한 글부터 고치는 것은 좋은 운영이 아니다. 성과를 만들 가능성이 큰 글부터 고쳐야 한다.

주간, 월간, 분기 루틴으로 나눈다

운영 루틴은 복잡하면 오래가지 못한다. 주간, 월간, 분기로 나눈다.

주간 체크

주간에는 큰 사고와 빠른 변화를 본다.

신규 발행 문서 색인 여부 확인
급격한 하락 문서 확인
CTR이 비정상적으로 낮은 문서 확인
404, noindex, canonical 같은 기술 이슈 확인
내부 링크 누락 확인
AI 답변 테스트 질문 3~5개 확인
브랜드 설명 오류 여부 기록

주간 체크는 깊은 분석이 아니라 조기 경보에 가깝다.

월간 리포트

월간에는 문서 단위로 판단한다.

좋은 월간 리포트는 숫자 나열이 아니라 다음 액션을 정하는 문서에 가깝다.

기본 구조는 아래와 같다.

이번 달 변화
성과 좋은 문서
성과 저조한 문서
새로 떠오르는 쿼리
CTR 낮은 문서
순위 정체 문서
AI 답변 언급 변화
브랜드 설명 오류
리라이트 후보
기술 이슈
다음 달 액션

리포트 마지막에는 반드시 “다음 달에 무엇을 고칠 것인가”가 있다.

분기 점검

분기에는 개별 글보다 구조를 본다.

토픽 클러스터별 성과 점검
중복 문서 통합 판단
허브 문서 업데이트
내부 링크 구조 점검
오래된 문서 정리
브랜드 엔티티 설명 일관성 점검
AI 답변 테스트 질문 세트 갱신
경쟁 브랜드 변화 확인

SEO/GEO는 글 단위로 시작하지만 시간이 지나면 구조 관리가 된다. 분기 점검에서는 문서군 전체를 본다.

운영 로그를 남긴다

리라이트와 AI 답변 테스트는 기록이 없으면 반복 학습이 안 된다.

간단한 로그만 있어도 충분하다.

날짜	문서/질문	문제	수정	확인 지표	다음 확인일
2026-04-29	GEO란 무엇인가	AI 답변에서 브랜드 설명 누락	FAQ와 서비스 설명 보강	AI 언급 여부, 인용 URL	2026-05-13
2026-04-29	Technical SEO/GEO	CTR 낮음	Title, Meta 수정	CTR, 평균 순위	2026-05-13

수정한 날짜, 수정 이유, 기대한 변화, 다음 확인일을 남겨야 한다. 그래야 나중에 어떤 수정이 효과가 있었는지 볼 수 있다.

SEO/GEO 운영 루틴 요약

이 글에서는 운영 루틴의 뼈대만 남긴다.

주기	목적	핵심 확인
주간	조기 경보	신규 문서 색인, 급락, 404/noindex/canonical, AI 답변 오류
월간	문서별 개선	노출·클릭·CTR·순위, 전환, 리라이트 후보, 다음 달 액션
분기	구조 관리	토픽 클러스터, 중복 문서, 허브/내부 링크, 브랜드 설명 일관성

이 정도만 고정해도 SEO/GEO 운영은 일회성 발행에서 반복 개선으로 넘어간다.

GEONIQ으로 확인하면

GEONIQ이 SEO/GEO 운영에서 보려는 것은 검색 성과와 AI 답변 노출을 같은 루틴 안에서 확인하는 것이다.

검색 결과에서는 어떤 쿼리로 보이는가?
클릭과 전환은 이어지는가?
AI 답변에서는 브랜드가 언급되는가?
언급된다면 설명은 정확한가?
어떤 문서를 고치면 검색과 AI 답변 모두에 도움이 되는가?

이 질문을 주기적으로 보면 SEO/GEO는 일회성 발행이 아니라 운영 루틴이 된다.

정리

SEO/GEO는 계속 쓰는 일이 아니라 계속 고치는 일에 가깝다. 새 글을 발행하는 것도 필요하지만, 이미 데이터가 쌓인 글을 보고 병목을 고치는 일이 더 빠른 성과를 만들 수 있다.

검색 성과는 Search Console, GA4, 검색 결과, 기술 상태로 본다. AI 답변 노출은 브랜드 언급, 인용 URL, 설명 정확도, 경쟁 브랜드, 수정 필요 항목으로 본다.

운영 루틴은 복잡하면 오래가지 못한다. 주간에는 사고를 잡고, 월간에는 문서별 액션을 정하고, 분기에는 구조를 정리한다.

검색과 AI 노출을 함께 점검하려면

GEONIQ은 사이트 URL을 기준으로 검색 성과와 생성형 AI 답변 언급을 함께 확인한다. 순위와 트래픽만 보는 대신, 어떤 질문에서 브랜드가 언급되고 어떤 설명으로 인용되는지 운영 루틴 안에서 점검하는 데 초점을 둔다.

이 글은 https://geiniq.ai/와 https://tech.pxd.co.kr/ 에서도 보실 수 있습니다.

서비스 아이디어 발굴부터 프로토타입까지, AI와 함께 일해본 기록 - 1편

Haeun Choi — Mon, 14 Sep 2026 16:05:39 +0900

최근 흥미로운 프로젝트를 진행했습니다. 바로 일본 시장을 대상으로 스마트홈과 모빌리티 영역의 새로운 서비스 아이디어를 발굴하고, 이를 프로토타입으로 구체화하는 프로젝트였습니다.

프로젝트를 진행하면서 아이디어를 더 다양한 관점에서 바라보고, 빠르게 구체화하기 위해 AI를 두 가지 방식으로 활용해 봤습니다.

1. 아이데이션 단계에서 AI Persona를 활용해 보기
2. AI 기반 프로토타이핑 툴을 활용해 아이디어를 빠르게 화면으로 구체화하기

이번 편에서는 그중 첫 번째인 AI Persona를 아이디어 발굴과 고도화 과정에서 어떻게 활용했는지를 이야기해보려고 합니다. Figma Make를 활용해 프로토타입을 제작했던 경험은 2편에서 이어서 다뤄보겠습니다.

사용자 조사 없이 아이디어를 만들다가 부딪힌 장벽

보통 신규 서비스 아이디어를 만드는 프로젝트에서는 사용자 조사를 통해 사용자의 삶의 방식과 페인포인트, 니즈를 파악하고 이를 기반으로 아이데이션을 진행합니다.

이번 프로젝트에서도 데스크 리서치를 통해 기존 서비스에 대한 사용자들의 불편한 점, 만족하는 점, 기대하는 점 등을 파악했습니다. 하지만 실제 사용자를 직접 만나 이야기를 들으며 다양한 삶의 맥락이나 감정, 행동의 동기까지 이해할 수는 없었기 때문에 아이디어를 깊게 발전시키는 데 한계가 있었습니다.

수십 개의 시드 아이디어를 만든 뒤 다시 살펴보니 표현과 기능은 달라도 비슷한 페인포인트를 해결하는 아이디어가 반복되기 시작했습니다. 그러면서 두 가지 의문이 생겼습니다. 실제 일본 사용자들도 이 아이디어를 보고 가치를 정말 느낄까? 그들에게는 무엇이 필요할까?

팀원들끼리 계속 비슷한 자료를 보면서 아이디어를 만들다 보니 생각도 점점 비슷한 방향으로 모였습니다. 그렇다고 중간에 일본 사용자 조사를 새로 진행할 수도 없는 상황이었죠. 그래서 사용자 조사를 대체하려는 목적이 아니라, 우리의 사고를 조금 더 확장하고 다른 관점에서 아이디어를 바라보기 위한 도구로 AI Persona를 활용해 보기로 했습니다.

다른 삶의 시선을 담은 AI 퍼소나 만들기

AI Persona를 활용함으로써 팀이 얻고 싶었던 것은 “일본 사용자는 이렇게 생각할 것이다.”라는 답이 아니라,“이런 삶을 사는 사람이라면 이런 생각을 할 수도 있겠구나.”라는 관점이었습니다.

그래서 Persona를 정의할 때도 단순히 나이, 성별, 직업 같은 인구통계 정보만 넣지 않았습니다.

예를 들어,

맞벌이를 하며 혼자 귀가하는 어린 자녀의 안전을 걱정하는 사람
혼자 거주하는 고령의 부모를 떨어진 곳에서 원격으로 돌보는 사람
공동주택에 거주하며 EV로 장거리 통근하고 충전 문제를 자주 경험하는 사람

서로 다른 삶의 조건을 가진 퍼소나를 설정했습니다.

또한 주변 사람들에게 실제로 겪은 불편이나 걱정을 물어보거나, 뉴스 기사와 기존 사례에서 접한 생활 장면을 참고해 스마트홈과 모빌리티 관점에서 그 사람의 판단에 영향을 줄 만한 하나의 구체적인 스토리를 각 Persona에 추가했습니다.

실제 스토리를 바탕으로 현재 어떤 서비스를 사용하고 있는지, 신규 구독료에 얼마나 민감한지, 집 안 센서나 카메라에 어떤 거부감이 있는지, 앱이 하나 더 생기는 것을 얼마나 귀찮아하는지, 평소 어떤 문제를 가장 큰 스트레스로 느끼는지 등 실제 의사결정에 영향을 줄 수 있는 조건들까지 구체적으로 정의했습니다.

답변 방식 역시 구체적으로 설계했습니다. 단순히 “이 기능은 좋습니다.” “프라이버시가 걱정됩니다.”라고 결론만 말하지 않도록 프롬프트를 작성했습니다. 대신 모든 판단에 구체적인 생활 장면이나 과거 경험을 근거로 포함하도록 프롬프트를 설계했습니다.

예를 들어 프라이버시가 걱정된다고 답한다면, 예전에 홈카메라 설치를 고민했다가 가족의 거부감 때문에 포기했던 경험처럼 왜 그런 판단을 하게 됐는지 그 사람의 생활 맥락까지 함께 설명하도록 했습니다.

즉, 팀이 퍼소나 의견을 읽으면서 “아, 이 사람은 이런 삶을 살아서 이렇게 생각하는구나.”라고 이해할 수 있도록 했습니다. 결국 Persona를 그럴듯하게 만드는 것보다, 그 사람이 어떤 삶을 살고 있고 왜 그런 판단을 하는지를 함께 볼 수 있는 툴을 만들고자 했습니다.

AI Persona의 시선을 빌려 아이디어 고도화의 힌트 찾기

이렇게 만든 Persona에게 실제 아이디어를 넣고 의견을 받아본 뒤, 결과를 아이디어 고도화를 위한 참고자료로 활용했습니다.

특히 도움이 됐던 부분은 크게 세 가지였습니다.

1. 실제 이용자 관점에서 서비스 수용성 점검

예를 들어 아이의 안전한 귀가를 지원하기 위해 학원 버스에서 내린 아이를 순찰 로봇이 집까지 에스코트하는 아이디어가 있었습니다.

처음 저희가 생각했던 핵심 가치는 명확했습니다. 아이 혼자 이동하는 구간에서 유괴나 납치 등의 위험을 줄이고, 보호자에게는 아이가 안전하게 귀가하고 있다는 안심을 주는 것이었습니다.

그런데 맞벌이 부모 Persona에게 이 아이디어를 보여주자 이런 반응이 나왔습니다.

“'학원 버스 하차장에서 세대 엘리베이터까지 순찰 로봇이 에스코트'라는 문구에서 바로 멈췄다. 딸이 로봇 옆에서 걷는 걸 부끄러워하거나 친구들이 놀리면 안 쓰려고 할 것 같다는 생각이 들었다. 초등 2학년은 부모가 좋다고 해도 본인이 싫으면 가방에 태그를 안 달고 나간다.”

팀에서는 당시 서비스의 가치를 아이의 안전을 높이는 것에 집중해서 보고 있었습니다. 로봇이 함께 걸어주면 부모는 안심할 수 있고, 위험 상황도 줄일 수 있으니 당연히 사용할 것이라는 다소 단순한 가정도 있었죠.

하지만 실제 서비스를 사용하는 사람은 부모가 아니라 아이였습니다. 부모에게는 안심되는 기능이어도, 아이가 친구들의 시선을 의식하거나 함께 걷는 경험 자체를 부담스럽게 느낀다면 서비스는 결국 사용되지 않을 수 있습니다. 즉, 보호자에게 전달되는 가치만 보고 실제 이용자의 수용성을 놓치고 있었다는 점을 다시 생각하게 됐습니다.

그래서 로봇이 항상 아이와 함께 이동하는 것을 기본 경험으로 두기보다, 평소에는 이동 상태를 확인하고 필요할 때만 로봇 에스코트를 요청할 수 있는 방향으로 아이디어를 조정했습니다.

2. 신규 기능이 유발할 수 있는 새로운 불안 요인 발견

또 같은 Persona는 과거 아이의 GPS 위치가 건물 안에서 튀면서 실제로는 학교에 있는데 학교 밖으로 이동한 것처럼 보여 괜히 담임에게 연락할 뻔했던 경험을 이야기했습니다.

여기서도 한 가지 힌트를 얻을 수 있었습니다. 안전 서비스라고 해서 정보를 많이 보여주고 알림을 많이 줄수록 과연 좋은 것일까? 란 질문을 던지게 됐죠.

위치나 경로 변화가 있을 때마다 알림을 보내면 오히려 부모가 하루 종일 아이의 위치를 확인하며 불안해질 수도 있었습니다. 안전을 위해 만든 서비스가 오히려 부모의 불안을 계속 자극하는 서비스가 될 수도 있다는 생각을 하게 되었습니다.

그래서 실시간 위치를 계속 보여주기보다 정상 이동, 지연, 경로 이탈, 도착 완료와 같이 상태 중심으로 정보를 제공하고, 평소와 다른 상황에서만 확인이 필요한 구조를 고민하게 됐습니다.

그렇다고 AI Persona의 말을 그대로 기능으로 반영한 것은 아니었습니다. 다만 이런 의견을 통해 “우리가 만든 방식이 오히려 새로운 불편을 만들고 있지는 않은가?” “이 기능이 실제 생활에서 사용되기 위해서는 어떤 조건이 필요한가?”를 다시 생각하며 아이디어의 방향이나 컨셉을 고도화하고 다듬어나갔습니다.

3. 지불 의사를 통해 적절한 ‘서비스의 형태’를 고민

Persona에게 지불 의사에 대해서도 물어봤습니다. “월 몇 엔까지 낼 수 있다”는 숫자 자체를 활용하려는 목적은 아니었고, 오히려 왜 별도 비용을 낼 수 있는지, 왜 별도 구독이라면 부담스럽다고 느끼는지를 참고했습니다.

예를 들어 어떤 Persona는 한 아이디어에 대해 별도 앱 기반의 구독 서비스라면 과하지만, 공동주택 전체에 제공되는 공용 인프라라면 수용할 수 있다고 판단했습니다.

이런 의견을 보면서 “애초에 이 아이디어를 사용자가 직접 가입하는 별도 서비스로 제공하는 것이 맞을까?”라는 질문을 하게 됐습니다.

사용자가 매달 직접 비용을 내고 이용하는 서비스가 적합한지, 아니면 공동주택의 안전이나 이동처럼 거주 환경에 기본적으로 포함되는 인프라 형태가 더 자연스러운지 다시 검토하게 됐습니다. 즉, Persona의 지불 의사는 가격을 정하기 위한 자료라기보다 서비스를 어떤 형태로 제공해야 하는지를 생각해 보기 위한 단서로 활용했습니다.

AI Persona를 ‘답’보다 ‘질문’에 활용하기

사실, AI Persona를 활용하면서 처음엔 “이게 사용자 조사를 대체할 수 있을까?” “과연 얼마나 도움이 될까?”하는 의문이 가득했습니다. Persona가 이야기한 생활 경험이나 과거 에피소드는 실제 누군가에게 일어난 일이 아니라, 우리가 설정한 조건을 바탕으로 AI가 만들어낸 가정인데 이걸 어떻게 믿고 활용할 수 있을까가 계속 걱정이었죠.

그런데 막상 활용해 보니, AI Persona의 가치는 ‘정답을 알려주는 것’보다 막혀 있던 사고를 다른 방향으로 돌리고, 새로운 관점과 질문을 만들어주는 데 있었습니다. 그래서 이번에는 AI Persona를 활용하면서 배우고 느낀 점을 세 가지로 정리해보려고 합니다.

Lessons Learned 1. 가정 기반 퍼소나는 시드 아이디어 단계에서 사고를 확장하는데 도움이 된다.

AI Persona에도 여러 유형과 활용 방식이 있지만, 이번처럼 가정을 기반으로 만든 Persona는 시드 아이디어를 발굴하고 고도화하는 초기 단계에서 관점과 사고를 넓히는 데 유용했습니다.

실제 사용자를 만나기 어려운 상황에서 “이런 삶을 사는 사람이라면 어떻게 생각할까?”를 빠르게 가정해 보며, 놓친 사용 장면이나 우려 요인을 발견하고 아이디어를 가볍게 점검할 수 있었습니다.

다만 이들은 실제 사용자가 아니기 때문에, Persona의 의견이나 지불 의사·선호도를 실제 사용자 데이터처럼 받아들이거나 이를 근거로 아이디어 방향을 결정하는 것은 위험하다고 생각됩니다.

결국 가정 기반 Persona는 답을 얻기보다, 우리가 미처 생각하지 못한 방향까지 사고의 범위를 넓히는 용도로 활용할 때 가장 효과적이지 않을까 싶습니다.

Lessons Learned 2. 아이디어에 대한 단순 ‘좋다/싫다’ 평가보다 왜 그렇게 생각하는지를 볼 수 있게 설계하는 것이 중요하다.

Persona에게 단순히 “이 아이디어에 점수 몇 점 주실래요?”, “얼마까지 지불할 수 있나요?”라고 물었다면 아이디어를 발전시키는 데 활용하기 어려운 답이 나왔을 것 같습니다.

오히려 유용했던 것은 왜 그렇게 판단했는지, 그 사람의 생활 맥락까지 함께 드러나도록 프롬프트를 설계한 것이었습니다. 판단의 배경을 알아야 그 안에서 어떤 기능을 바꿀지, 무엇을 줄일지, 어떤 방식으로 제공할지에 대한 힌트를 얻을 수 있었기 때문입니다.

결국 구체적인 답변을 얻기 위한 설계가 중요한 이유는 더 그럴듯한 가상 사용자를 만들기 위해서가 아니라, 그 판단이 나온 맥락을 이해하고 아이디어를 다시 바라보기 위한 재료를 얻기 위해서입니다.

Lessons Learned 3. 결국 고민하고 판단하는 것은 사람이 해야 한다.

AI Persona를 활용한다고 해서 아이디어 고도화까지 AI에게 맡길 수 있었던 것은 아닙니다. Persona가 새로운 우려를 이야기했다고 해서 기능을 바로 추가하지도, 어떤 기능을 싫어한다고 해서 곧바로 삭제하지도 않았습니다.

결과는 어디까지나 아이디어를 다시 바라보기 위한 하나의 참고자료로만 활용했습니다. 그 의견이 실제로 중요한 문제인지, 아이디어의 핵심 가치와 충돌하지는 않는지, 그렇다면 어떤 방식으로 풀어내는 것이 적절한지는 결국 팀이 다시 판단하고 고민해야 했습니다.

돌이켜보면 AI Persona가 가장 크게 도와준 부분은 “이 아이디어는 이렇게 고치세요”라고 답을 주는 것이 아니라, “이런 점은 생각해 봤나요?”라고 새로운 질문을 던져준 것이란 생각이 듭니다.

마치며

개인적으로는 이번 경험 전까지 AI Persona 활용에 꽤 회의적인 편이었습니다. 하지만 직접 활용해 보면서 생각이 많이 바뀌었습니다. AI Persona가 무엇을 대신 해주는 도구인지보다, 어떤 목적으로 써야 하고 어떤 상황에서 특히 효과적인지를 확실히 체감할 수 있었습니다.

앞으로 비슷한 프로젝트를 진행한다면, AI Persona를 활용해 아이디어 초기 단계에서 익숙한 관점에 갇히지 않았는지 점검하고, 놓친 질문을 찾아보는 데 다시 활용할 것 같습니다.

다음 편에서는 두 번째 제약이었던 ‘디자이너 없이 리서처들이 프로토타입까지 만들어야 했던 상황’에서 Figma Make를 어떻게 활용했는지, 그리고 실제로 사용해 보며 얻은 경험과 인사이트를 이어서 나눠보겠습니다.

AI 전사 도입 시대, 스마트워커 되기 - 강의 후기

강은영 — Thu, 10 Sep 2026 07:50:39 +0900

들어가며

얼마 전 "AI 전사 시대, 스마트워커로 살아남는 법"라는 강의를 듣고 왔습니다. 하루 만에 Claude Code의 핵심과 실무 활용법을 쭉 훑어보는 알찬 시간이었어요.

강의를 듣는 내내 머릿속에 계속 맴돌던 핵심 문장이 하나 있었습니다.

"이제는 내가 직접 일하기보다, AI 인부 5~10명을 관리하는 현장 감독이 되어야 한다."

코드를 직접 짜는 개발자뿐만 아니라, 저 같은 비개발자나 일반 실무자도 '관리자 마인드'로 AI를 대할 때 비로소 일의 생산성이 폭발한다는 이야기였죠. 오늘은 강의에서 인상 깊었던 핵심 인사이트와 실습에서 배운 유용한 실무 팁을 함께 정리해 보았습니다.

1. 시대의 변화: 프롬프트 입력에서 '현장 감독'으로

예전의 AI 활용이 "프롬프트 하나 잘 던지는 기술"이었다면, 이제는 여러 AI 에이전트에게 역할을 나누어 맡기고 결과를 검수하는 '관리자의 역량'이 중요해졌습니다.

일반 챗봇: '뇌'만 있어서 질문에 답을 알려주는 수준
Claude Code: '뇌 + 손'이 결합되어 실제 파일 실행 및 환경 제어까지 끝내는 AI Agent

[스마트워커의 새로운 태도]

실행 (Execution): 사람이 직접 하던 타이핑/작업을 AI에게 전권 위임
반복 (Routine): 매번 수동으로 하던 일을 스킬 및 템플릿으로 자동화
역할 (Role): 단순 실무 수행자에서 기획, 맥락 제공, 최종 판단자로 전환

2. 먼저 용어부터 깔끔하게 정리하기

헷갈리기 쉬운 AI 용어들은 '포함 관계'로 이해하면 한눈에 들어옵니다.

AI (인공지능): 가장 큰 범주
생성형 AI (Generative AI): 글·그림·영상을 만들어내는 기술 (예: ChatGPT)
LLM (대형 언어 모델): 생성형 AI의 언어 처리 엔진 (예: GPT-4, Claude, Gemini)
AI Agent: 스스로 목표를 세우고 외부 도구를 활용해 실행까지 완수하는 주체

Claude Code는? LLM을 강력한 엔진 삼아, 스스로 행동하는 'AI Agent'처럼 동작하는 도구입니다.

3. Claude Code의 핵심 강점 4가지

깊은 업무 맥락 이해 (@ 태그 & CLAUDE.md) 매번 같은 회사/업무 배경을 길게 설명할 필요 없이 @ 태그로 폴더나 파일을 지정하고, 프로젝트 가이드북 역할을 하는 CLAUDE.md를 통해 업무 맥락을 유지합니다.
자율적인 문제 해결 능력 탐색 ➔ 실행 ➔ 에러 감지 ➔ 코드/로직 수정 ➔ 재실행을 스스로 반복합니다.
외부 도구 생태계 연결 (MCP) MCP(Model Context Protocol)를 통해 Slack, Google Workspace, 캘린더 등 사내 툴과 직접 연동됩니다.
반복 업무의 명령어화 (스킬) 자주 하는 작업 흐름을 '스킬'로 저장해 두고 단 한마디로 자동 실행합니다.

4. 일을 잘 시키는 상사의 지혜: 플랜 모드와 모델 선택

AI에게 일을 잘 시키는 핵심은 "좋은 상사처럼 일하는 것"입니다.

실행 전 방향을 맞추는 Shift + Tab (플랜 모드) 무작정 실행부터 하게 두지 않고 Shift + Tab을 눌러 플랜 모드로 진입하세요. AI가 먼저 전체 실행 계획을 제시하고, 내가 검토/승인한 뒤에만 작업에 착수합니다.

진행 여부 확인(Prompt) 팁 작업 중 "Do you want to proceed?"라는 질문이 계속 나와 흐름이 깨진다면, "Yes, and don't ask again for..." 선택지를 이용해 승인 팝업 없이 더 빠르게 작업을 맡길 수 있습니다.

난이도별 Claude 모델 선택 가이드

Haiku: 가벼운 데이터 정리 및 단순 요약
Sonnet: 일상적인 대부분의 실무 및 코드/문서 작성
Opus: 복잡한 추론이나 아키텍처 설계
Fable: 가장 까다롭고 깊은 맥락 이해가 필요한 고난도 작업

5. 나만의 워크스페이스(CLAUDE.md) 세팅과 스킬 구축

실습을 진행하며 가장 유용했던 것은 나만의 폴더 구조와 프로필을 설정하는 것이었습니다.

CLAUDE.md 파일 활용하기 VS Code에서 /setup-workspace 명령어를 실행하고 이름, 직무, 관심사 등을 입력하면 나만의 사용자 프로필이 CLAUDE.md로 저장됩니다.

파일/폴더별로 CLAUDE.md 전용 가이드북을 만들 수 있습니다.
다만, 문서가 많아지면 읽을 때 토큰이 소모되므로 필요한 핵심 폴더 위주로 신중하게 생성하는 것이 좋습니다.

아이디어를 앱/서비스로 배포하는 5단계 프로세스 아이디어를 실제 가시적인 서비스로 만드는 과정은 다음과 같이 진행됩니다.

기획 (PRD 작성): AI가 AskUserQuestion으로 질문하며 상세 기획서(PRD)를 함께 완성
맥락 연결: 완성된 PRD 내용을 기반으로 CLAUDE.md 세팅 및 스킬 연동
화면/기능 구현: HTML/CSS 및 로직 구현 (미리보기 화면으로 확인)
검수 및 수정: 로컬 테스트 및 예외 사항 보완
배포: GitHub Push 및 Vercel 등을 통한 실제 자동 배포

6. 롱런을 위한 컨텍스트 관리 꿀팁

대화가 길어질 때 사용할 수 있는 유용한 명령어들입니다.

/compact : 길어진 대화의 핵심 맥락만 압축 정리
/clear : 이전 대화를 비우고 새로운 상태로 시작
/context : 현재 사용 중인 컨텍스트 용량 확인
/resume & /rename : 지난 대화 이어보기 및 대화방 이름 변경
ESC 키 : AI가 엉뚱한 방향으로 실행할 때 즉시 정지 및 방향 전환

마치며

하루라는 짧은 시간이었지만, 이번 강의와 실습을 통해 Claude Code의 기본 기능과 전체적인 동작 흐름을 확실하게 파악할 수 있었습니다. 막연하게 느껴졌던 AI 에이전트 개념이 손에 잡히기 시작했고, 실무에서 기본적으로 어떻게 다루고 활용해야 할지 감을 잡은 것이 가장 큰 성과였습니다.

강의 자료에 적혀 있던 이 문장처럼, 주저하지 말고 직접 실행해 보면서 익혀나가는 게 핵심인 것 같아요. "무엇을 마주쳐도, 일단 해보면 된다 (Action First -> Iterate -> Make It Yours)"

감사합니다.

이 글은 https://tech.pxd.co.kr/ 에서도 보실 수 있습니다.

합성 사용자(Synthetic User)를 보는 세 가지 기준 - Act

Seungyoon Lee — Mon, 7 Sep 2026 03:05:29 +0900

합성 사용자(Synthetic User)를 보는 세 가지 기준
1. Overview [바로가기]
2. Anchor [바로가기]
3. Align [바로가기]
4. Act

Act

합성 사용자는 대부분 질문에 잘 대답하는 사용자에서 출발했습니다. 그런데 합성 사용자에게 UX에 대한 의견을 구하게 되면서 의견을 생성하는 것을 넘어 실제 행동으로 경험을 할 수 있게 해야 합니다. 그래서 점점 궁금해지죠.

이 합성 사용자는 실제 사람의 경험 중에서 어디까지 행동할 수 있는가? (What can this synthetic user actually do?)

Act의 자율성

합성 사용자의 행동 수준은 어떤 스펙트럼을 구성할까요?

답변 Answer

합성 사용자는 백그라운드, 니즈, 목표, 속성, 페인포인트, 선호도 등의 정보를 바탕으로 ‘이 기능을 어떻게 생각하세요?’ ‘무엇이 가장 걱정되나요?’ ‘왜 이 브랜드를 선택하겠어요?’와 같은 질문에 대해서 대답합니다. 또는 인터뷰, 서베이와 같은 리서치에 참여하여 질문에 대답하고 의견을 내기도 합니다. 여러 리서치 회사에서 합성 사용자 패널을 만들어 서베이를 하거나 콘셉트 테스트를 하는 상황을 상상해 보면 됩니다.

사용 Interact

최근 합성 사용자는 실제 제품이나 프로토타입을 직접 조작하기 시작했습니다. 예를 들어 합성 사용자에게 프로토타입을 제공하고 직접 태스크를 수행하게 하는 것입니다. 그러면 합성 사용자가 남긴 세션 정보를 통해 어디를 클릭하는지, 어디에서 뒤로 돌아가는지, 어디에서 머뭇거리는지 클릭 패스, 히트맵과 같은 데이터를 얻을 수 있게 됩니다. 이후 왜 여기서 머뭇거렸는지, 왜 뒤로 돌아갔는지 후속 질문을 던질 수도 있겠지요.

Synthetic Users는 합성 사용자가 실제 화면을 조작하며 발생시킨 클릭, 호버 등의 행동 데이터와 개별 페르소나를 결합해, 화면의 어느 곳에 주의를 둘지 예측한 히트맵을 제공합니다.

합성 사용자의 탐색 흔적 (탐색했을 거라고 추정)

합성 사용자는 점점 ‘어떤 버튼을 누를 것 같다’고 대답하는 존재에서 실제 화면 안에서 버튼을 찾고 탐색하는, 행동하는 존재로 확장되고 있습니다.

자율 탐색 Explore

사용 (Interact)이 "주어진 화면 안에서" 사용하는 것이라면, 자율 탐색 (Explore)은 합성 사용자가 목표를 달성하기 위해 능동적으로 행동하는 것을 의미합니다. 합성 사용자에게 태스크가 아니라 목표를 제시하면 무엇을 할지 스스로 정하고, 필요한 곳을 찾아다녀서 목적을 달성하게 하는 것이지요.

쇼핑으로 비유하면, 사용 (Interact)은 "이 온라인몰에서 검정 백팩 하나 골라봐"에 가깝습니다. 해당 몰에서 최선의 검정 백팩을 고르기 위해 노력하죠. 반면 이 단계의 합성 사용자가 받는 미션은 "출근용 가방이 필요해”에 가깝습니다. 합성 사용자는 여러 사이트를 찾아다니고, 후기를 읽고, 가격을 비교하고, 어떤 건 담아뒀다 결국 사거나 포기합니다. 어디까지 갈지, 무엇을 볼지, 언제 그만둘지를 스스로 정합니다.

기억과 목표를 가진 25명의 AI 에이전트가 스스로 살아가는 마을(Smallville)을 만든 스탠퍼드의 생성 에이전트 연구가 있습니다. 이 연구의 흐름은 이후 Simile로 이어졌습니다. 생성 에이전트 연구와 Simile이 공통적으로 보여주는 문제의식은, AI를 단순히 더 똑똑한 비서로 만드는 것만으로는 인간을 충분히 재현할 수 없다는 점입니다. 중요한 것은 사용자의 가치, 취향, 경험, 행동 패턴을 모델링하고, 특정 상황에서 그 사람이 실제로 어떤 선택을 할지를 재현하는 것입니다.

Simile

Act 스펙트럼

지금까지 살펴본 세 유형은 아래와 같이 정리해 볼 수 있습니다.

응답하는 사용자에서 행동하는 사용자로

합성 사용자의 목표는 가장 똑똑하게 과업을 해결하는 에이전트를 만드는 것이 아니라 특정한 사람이 실제로 선택할 법한 행동을 재현하는 것입니다. 또, 합성 사용자의 다음 단계는 기억과 경험이 누적되면서 스스로 변화하는 모델이 될 가능성이 큽니다. 그래서 Anchor, Align, Act 세 축이 서로 맞물려 돌아가야 합니다.

사람에 근거하고 (Anchor)
실제와 맞춰가며 (Align)
자율적으로 행동하는 (Act)

우리가 만드는 합성 사용자는 어떤 단계에 있나요? AAA: Anchor, Align, Act 프레임으로 한번 평가해 보세요.

참고

Where do synthetic eyes look?, Synthetic Users, https://www.syntheticusers.com/science-posts/where-do-synthetic-eyes-look#gaze-screen-18

Computational Agents Exhibit Believable Humanlike Behavior, Stanford University Human-Centered Artificial Intelligence, https://hai.stanford.edu/news/computational-agents-exhibit-believable-humanlike-behavior

Simile, https://www.simile.com

합성 사용자(Synthetic User)를 보는 세 가지 기준 - Align

Seungyoon Lee — Mon, 7 Sep 2026 02:56:49 +0900

합성 사용자(Synthetic User)를 보는 세 가지 기준
1. Overview [바로가기]
2. Anchor [바로가기]
3. Align
4. Act [바로가기]

Align

합성 사용자가 실제 사용자 데이터에 잘 닿아 있다고 해서, 실제 사용자처럼 반응하는 것은 아닙니다. 실제 인터뷰, 설문, 고객 데이터, 행동 로그를 기반으로 만들어졌더라도 새로운 질문이나 새로운 제품 상황에서 전혀 다른 반응이 나오기 때문입니다. 그래서 두 번째로 이런 질문이 떠오릅니다.

이 합성 사용자는 얼마나 실제 사람같이 반응하는가?(How well does this synthetic user align with reality?)

예를 들어 여러 EV 배터리를 비교해 본 사용자는 "배터리에서 무엇이 가장 중요한가"에는 그 경험을 근거로 일관되게 답합니다. 하지만 "구독형 배터리 교체 서비스가 나오면 가입하겠는가"처럼 겪어보지 않은 새로운 상황에는, 그럴듯한 답을 자신 있게 내놓더라도 그것이 실제 사용자의 선택과 같으리란 보장이 없습니다.

그래서 그럴듯하게 응답하느냐(plausibility)를 넘어, 실제 사용자의 응답과 얼마나 일치하느냐(alignment)를 확인해야 합니다.

Align의 깊이

현실과 얼마나 일치하는지 확인하는 스펙트럼에 대해서 알아봅니다.

그럴듯함 (Plausible)

가장 기본적인 수준은 결과를 사람이 읽고 “그럴듯하다”라고 판단하는 것입니다. 아이데이션 단계에서는 그럴듯한 답변을 하는 것만으로도 어느 정도 유용한 결과를 얻을 수 있습니다. 하지만 아직은 실제 사람이 이렇게 이야기할지 아닌지는 모르는 상태입니다.

전문가 검토 (Expert-reviewed)

좀 더 나아가서는 합성 사용자의 응답을 UX 리서처나 도메인 전문가가 검토할 수 있습니다. 예를 들어, 기존 인터뷰에서 보던 패턴과 비슷한가? 지나치게 전형적인 답변은 아닌가? 너무 논리적인가? 기존 리서치 근거와 맞지 않는 점은 없는가? 등에 대한 검증을 할 수 있습니다. 한편, 전문가의 검토는 합성 사용자의 잘못된 답변을 가리는데 도움이 되지만 여전히 실제 사용자의 응답과 일치하고 있는지를 알기는 아직 어렵습니다.

응답 일치 (Human response-aligned)

합성 사용자와 실제 사람에게 동일한 질문을 하고 결과를 비교하는 방식입니다. 예를 들어 EV 브랜드 선호도를 묻는 질문을 합성 퍼소나와 동일한 특성을 가진 실 사용자에게 동시에 묻는 방식입니다. 두 결과가 얼마나 유사한지 비교하는 과정을 통해 합성 사용자 응답의 정합성을 맞춰 나가게 되고 이 단계부터 합성 사용자가 얼마나 현실을 반영하고 있는지 기준을 가지게 됩니다.

퀄트릭스는 자체 합성 패널과 실제 패널을 동일한 인구 통계 조건으로 매칭한 뒤 같은 질문에 대한 응답을 비교했습니다. 이렇게 합성 패널의 응답이 실제 패널과 얼마나 가까운지 측정함으로써 합성 응답의 정합성을 검증합니다.

행동 일치 (Behavior-aligned)

UX 리서치에서는 사용자의 행동이 중요합니다. 실제 사용자와 합성 사용자 모두 “이 기능은 쉽게 사용할 수 있을 것 같아요.”라고 말할 수 있지만, 이 기능을 실제로 사용해 보는 태스크를 수행할 때에는 다른 행동을 보여줄 수도 있기 때문입니다.

합성 사용자와 실제 사용자의 말은 일치할 수 있지만 행동은 일치하지 않을 수 있다는 말입니다. 그래서 합성 사용자를 평가하려면 태스크 성공 여부, 내비게이션 경로, 에러 여부, 백버튼(백트래킹), 포기, 소요 시간, 클릭/터치 횟수 등과 같은 항목을 비교 테스트 해야 합니다.

Userbrain은 합성 사용자와 실제 사용자에게 요금제 프로토타입에서 동일한 태스크를 수행하게 했습니다. ‘월 20명의 테스터를 이용할 때 가장 저렴한 옵션'을 찾으라는 태스크에서 실제 사용자는 5명 중 3명이 정답을 맞힌 반면, 합성 사용자는 모두 정답을 맞혔습니다. 실제 사용자가 겪은 실패를 재현하지 못하고 보다 이상적으로 성공한 것입니다.

User Brain의 테스트에 쓰인 화면 프로토타입

닐슨노만그룹(NN/g)은 실제 사용자와 진행했던 연구에 합성 사용자를 붙여, 합성 사용자가 생성한 응답을 실제 인터뷰 결과와 비교했습니다. 그 결과, ‘업무 방식’과 같은 일반적인 질문에 대해서는 실제 사용자와 유사한 답변을 했지만, 실제 경험을 묻는 대목에서 크게 차이가 있음을 발견했습니다. 예를 들어, 온라인 학습에서 실제 사용자들은 강의가 좋았지만 코스를 끝까지 마치지는 않았는데, 합성 사용자는 언급한 코스를 모두 완료했다고 응답했습니다.

닐슨노만그룹은 합성 사용자가 '의견'은 그럴듯하게 만들어내도 '실제로 무엇을 했는지'에 대한 행동 데이터는 만들어내지 못한다고 합니다. 말은 사람처럼 들려도 실제 행동과 경험은 검증 없이 어긋날 수 있다는 것, 이것이 행동 일치를 따로 확인해야 하는 이유입니다.

NN/g의 비교 연구를 설명한 유튜브 Synthetic Users: AI “Participants”

변화 일치 (Continuous alignment)

사용자의 생각과 행동은 고정되어 있지 않습니다. 새로운 기능에 익숙해지거나, 제품을 반복해서 사용하거나, 시장 환경이 변하면서 응답과 행동도 달라질 수 있습니다. 따라서 합성 사용자도 특정 시점의 사용자 데이터를 그대로 유지하는 것이 아니라, 새롭게 관찰된 현실을 다시 반영해야 합니다.

예를 들어 새 EV 충전 예약 기능이 출시되기 전과 후의 사용자의 의견에 대해서 변화가 있을 수 있습니다. 새 기능이 출시되기 전에는 합성 사용자와 실제 사용자가 서로 같은 의견으로 시작하지만, 실제 사용자가 제품을 사용해 본 후 기대와 다른 방향으로 사용하게 된다면, 이후 합성 사용자도 의견을 업데이트할 수 있도록 해야 할 것입니다.

변화 일치는 단순히 최신 데이터를 추가하는 것이 아니라, 실제 사용자의 생각과 행동이 어떻게 변했는지를 다시 관찰하고 그 변화를 합성 사용자에 반영하면서 지속적으로 정합성을 맞춰가는 과정이라고 할 수 있습니다.

Sentia Labs는 합성 사용자로 제품을 시뮬레이션한 뒤, 출시 후에는 실제 고객 데이터를 바탕으로 모델을 다시 수정하는 닫힌 루프(closed loop)를 사용합니다. 이렇게 되면 합성 사용자는 특정 시점에 만들어진 퍼소나가 아니라 실제 사용자와 시장 변화에 따라 계속 갱신되는 사용자 모델에 가까워집니다.

Sentia Labs에서 합성 사용자의 모델을 업데이트 하는 과정

Align 스펙트럼

지금까지 살펴본 다섯 가지 유형은 아래와 같이 정리해 볼 수 있습니다.

그런데, 어디까지 행동하는가?

Anchor는 합성 사용자가 어디에서 왔는가, Align은 합성 사용자의 응답과 행동이 실제로 현실과 맞는가에 대한 이야기였습니다.

이제 실제 사람과 같은 합성 사용자를 만들었다면, 그 합성 사용자는 어디까지 행동할 수 있을까요? 묻는 말에 잘 대답하면 그걸로 충분할까요? 합성 사용자가 어떤 역할까지 할 수 있는지 다음 글, Act에서 알아보겠습니다.

참고

Testing Synthetic Data Against Academic Benchmarks: A Replication Study, Greenbook, https://www.greenbook.org/insights/data-science/testing-synthetic-data-against-academic-benchmarks-a-replication-study

We Ran an Experiment with Synthetic Users: Here’s What We Found, User Brain, https://www.userbrain.com/blog/synthetic-users-experiment

Synthetic Users: If, When, and How to Use AI-Generated “Research”, NN/g, https://www.nngroup.com/articles/synthetic-users

Synthetic Users: AI “Participants,” NN/g, https://www.youtube.com/watch?v=q_fdcbwHJKQ&t=6s

Sentia Labs, https://www.sentialabs.ai/synthetic

합성 사용자(Synthetic User)를 보는 세 가지 기준 - Anchor

Seungyoon Lee — Mon, 7 Sep 2026 02:39:44 +0900

합성 사용자(Synthetic User)를 보는 세 가지 기준
1. Overview [바로가기]
2. Anchor
3. Align [바로가기]
4. Act [바로가기]

Anchor

AI가 생성한 사용자의 많은 특성은 실제 고객에게서 관찰된 것이 아니라 모델이 이미 학습한 사람에 대한 일반적인 패턴에서 채워집니다. ‘30대 직장 여성’이라는 조건만 있어도 AI는 수많은 다양한 합성 사용자를 생성할 수 있습니다. 우리가 입력하지 않은 정보가 자연스럽게 채워지면 어느 순간 이 모든 것들이 근거 있는 실제 데이터처럼 느껴집니다. 그래서 합성 사용자를 볼 때 다음 질문을 합니다.

이 사용자는 실제 무엇에 근거하고 있는가? (What is this synthetic user anchored in?)

사용자의 실제 데이터에 닻을 내린다는 의미로, Anchor라고 부르려고 합니다.

Anchor가 닿는 위치

모든 합성 사용자가 동일한 수준의 근거를 가지고 만들어지는 것은 아닙니다. 얼마나 현실의 데이터에 깊게 닿아 있는지에 대한 스펙트럼이 존재합니다.

가정 기반 (Assumption)

일단 프롬프트만으로 만들어진 합성 사용자가 있습니다. 우리가 성별, 나이, 목적 정도의 정보를 프롬프트로 입력하면 나머지는 AI가 채우는 방식입니다.

예를 들어, “40대 일본 남성, EV 구매를 고민 중, 새로운 충전 환경 구축 프로젝트에 필요”라고 정의하면 AI는 그에 맞는 관심사, 걱정, 구매 기준 등을 척척 생성해 냅니다. (아래 더보기에서는 ChatGPT가 바로 생성한 합성 사용자 프로필을 볼 수 있습니다.)

합성 사용자 타카시 사토

이름: Takashi Sato / 佐藤隆志
나이: 46세
거주지: 일본 요코하마시
직업: 중견 제조기업 영업기획 매니저
가족: 아내, 고등학생 자녀 1명
주거: 약 12년 된 분양 맨션, 지하 공용주차장 이용
차량: 7년 된 하이브리드 SUV 보유
연간 주행거리: 약 10,000–12,000km
평일 출퇴근은 전철 중심, 자동차는 주말·가족 이동·장보기·여행에 주로 사용

현재 상황
다음 차량으로 EV를 진지하게 검토하고 있다. 자동차 자체에 대해서는 긍정적이다. 정숙성, 유지비, 최신 기술, 집에서 충전할 수 있다는 점에 매력을 느낀다. 하지만 현재 거주하는 맨션에는 자신의 주차구역에 개인 충전기가 없으며, 향후 충전기가 설치되더라도 “실제로 내가 필요할 때 사용할 수 있을까?”에 대한 확신이 없다. 그에게 EV 구매의 가장 큰 문제는 차량 가격보다 오히려 충전 환경의 불확실성이다.

EV에 대한 태도
“EV 자체는 이제 충분히 괜찮다고 생각해요. 문제는 차가 아니라, 충전을 얼마나 신경 쓰면서 살아야 하느냐인 것 같아요.”
신기술을 좋아하지만 얼리어답터는 아니다. 기술적으로 새롭다는 이유만으로 구매하지 않고, 이미 충분히 안정적으로 작동한다는 확신이 생긴 뒤 구매하는 편이다.

충전과 관련한 핵심 니즈

충전을 별도의 일로 만들고 싶지 않다.
귀가해서 주차하면 자연스럽게 충전되고, 다음에 차를 사용할 때 필요한 만큼 충전되어 있기를 원한다.
충전 가능 여부를 미리 알고 싶다.
집에 도착한 뒤 “충전기가 다 사용 중”이라는 사실을 발견하는 상황을 싫어한다. 필요하다면 예약이나 자동 배정 기능을 선호한다.
매번 완충할 필요는 없다.
자신의 다음 이동 일정에 필요한 만큼만 충전되어 있으면 된다고 생각한다.
충전 비용을 통제하고 싶다.
심야 전력이나 저렴한 시간대를 자동으로 활용해 전기요금을 최소화해 주기를 기대한다.
문제가 생겼을 때 자신이 해결하고 싶지 않다.
충전기 고장, 결제 오류, 다른 차량의 장시간 점유 같은 문제를 관리사무소나 시스템이 알아서 처리해 주기를 원한다.

Typical Scenario
금요일 오후, 회사에서 집으로 돌아가는 전철 안에서 주말 가족 일정이 확정된다.
토요일 오전에는 자녀를 학원에 데려다주고, 오후에는 쇼핑몰, 일요일에는 가족과 약 150km 떨어진 곳으로 당일 여행을 갈 예정이다.
Takashi는 차량 앱을 확인한다.
현재 배터리는 38%.
시스템은 그의 캘린더와 평소 이동 패턴을 기반으로 다음 날 오전까지 약 80% 충전이 필요하다고 판단한다. 하지만 현재 맨션 충전기는 다른 차량들이 사용 중이다.

Takashi가 원하는 경험은:
“충전기를 찾아서 예약하고 충전 시간을 계산하는 것”이 아니라
“일요일 여행을 위해 필요한 충전이 준비되어 있습니다.”
라는 결과만 확인하는 것이다.
시스템이 알아서 충전 가능한 시간을 찾아 배정하고, 전력 사용량이 낮은 새벽 시간에 충전을 시작해 비용까지 최적화해 주기를 기대한다.

Pain Points
현재 내연기관 차량

주유소 방문은 귀찮지만 5분이면 끝난다는 확신이 있음
장거리 여행에서도 어디서 주유할지 크게 고민하지 않음

EV로 바꿀 경우 예상되는 불안

맨션 충전기를 다른 주민과 공유해야 하는 문제
충전기 설치 후 이용자가 늘어났을 때의 대기
다른 사람이 충전 후 차량을 이동하지 않는 상황
충전기 고장 여부를 출발 직전에 알게 되는 상황
급하게 차량을 사용해야 할 때 충전량 부족
여러 충전 사업자별 앱과 결제 방식
“오늘 밤 충전해야 하나?”를 계속 판단해야 하는 정신적 부담

그가 가장 피하고 싶은 것은 Range Anxiety보다 Charging Management Anxiety에 가깝다.

Decision Criteria for Buying an EV
Takashi가 EV 구매를 결정하려면 다음 질문에 모두 어느 정도 확신이 필요하다.
“집에 돌아오면 충전할 수 있는가?” → 충전기 숫자보다 충전 접근성의 예측 가능성
“내가 충전에 대해 계속 생각해야 하는가?” → 가능하면 자동화
“여러 사람이 사용해도 공정하게 운영되는가?” → 예약·우선순위·사용시간 관리
“전기요금이 예상 가능한가?” → 비용 가시성과 자동 최적화
“갑자기 차가 필요해도 괜찮은가?” → 최소 필요 배터리 확보 또는 긴급 충전

아이데이션 단계에서는 가정 기반 합성 사용자의 의견도 충분히 유용합니다. 새로운 관점이 필요하거나 아이디어를 생성하기 위한 목적이라면 반드시 실제 사람과 꼭 같은 합성 사용자의 의견까지는 필요 없을 것입니다. 저도 얼마 전 끝난 스마트홈 프로젝트에서 생성형 AI로 간단히 만든 합성 사용자를 생성하여 새로운 아이데이션을 평가하여 큰 도움을 받은 적이 있습니다.

스마트 홈 관련 아이데이션에서 퍼소나가 평가하고 의견을 제시하는 과정을 통해 프로젝트 팀의 아이디어를 확장하고 새로운 관점을 얻을 수 있었습니다.

인구 통계 기반 (Population-anchored)

다음 단계는 특정 인구집단의 구조와 분포를 반영하는 것입니다.

인구 센서스, 인구통계, 서베이, 시장 조사 데이터 등을 특정 인구 집단 안에 어떤 특성을 가진 사람들이 얼마나 존재하는지를 근거로 하여 사용자를 만들어 냅니다. 예를 들어 NVIDIA의 Nemotron-Personas-Korea처럼 한국의 인구, 지역, 사회적 분포를 반영해 대규모 합성 퍼소나를 생성한 사례가 있습니다.

NVIDIA Nemotron-Personas-Korea 일부

실제 인구 통계 정보를 기반하여 합성 사용자를 만들었지만, 고객/사용자의 세세한 취향, 태도, 지식을 반영하고 있지는 않습니다. 예를 들어 일본 EV 잠재 구매자를 실제 인구 통계에 맞춰 구성했다고 해도,’늘 붐비는 공용 충전기’에 대해 어떤 의견을 가지고 있는지에 대해서는 명확한 의견을 가지고 있다고 하기 어렵습니다. 물론 AI는 상당 부분 필요한 의견을 생성해 낼 수 있기는 합니다.

그래서 이 인구 분포에 있는 사용자들의 구체적인 특성을 드러내기 위해서 좀 더 사용자의 실제 정보를 바탕으로 합성 퍼소나를 생성해야 할 필요성을 느끼게 됩니다.

고객 데이터 기반 (Customer-anchored)

일반적인 인구집단의 특성만 반영하는 것이 아니라, 실제 사용자나 고객이 과거에 무엇을 말하고 어떻게 반응했는지, 직접 관찰된 사용자 데이터를 활용할 수도 있습니다.

예를 들면 다음과 같은 실제 고객의 데이터를 활용합니다. 인터뷰 스크립트, 서베이 응답, 고객의 소리, NPS 등의 코멘트, 기존에 만들었던 퍼소나 등 말입니다.

제품을 직접 운영하는 기업이라면 실제 고객의 인터뷰, CRM, 고객센터 기록, 제품 사용 데이터 등을 활용할 수 있고, 반대로 자체 제품을 보유하지 않은 리서치 회사라면, 실제 패널이 여러 조사에서 남긴 반복 응답과 행동 데이터를 축적하여 이를 근거로 합성 사용자를 만들 수도 있습니다.

예를 들어, 리서치 준비부터 AI 퍼소나로 UX 검증까지 리서치를 돕는 ReOpsAI는 pxd가 다년간 금융 프로젝트를 수행하며 만난 사용자의 생생한 목소리를 근거로 만든 퍼소나를 제공합니다.

ReOpsAI의 AI 퍼소나 소개

Synthetic Users는 고객사가 보유한 인터뷰, 고객 상담 기록 등의 고유 데이터를 합성 사용자가 참고하도록 연결합니다. 또한 센서스와 사회조사 등 인구집단 데이터도 합성 사용자의 근거로 활용한다고 설명합니다.

Synthetic Users 소개 화면

가령 자체 패널을 장기간 운영하는 회사의 5,000명의 패널에 대해 EV 구매 의향, 가격 민감도, 충전 불안, 주거 형태, 보유 차량, 브랜드 선호, 실제 구매 여부 등이 축적되어 있다면, 합성 사용자는 단순히 “40대 남성은 아마 이렇게 생각할 것이다”라고 가정하기보다 실제로 비슷한 특성을 가진 사람들이 과거에 어떻게 응답했는지를 바탕으로 새로운 응답을 생성하게 됩니다.

이렇게 만들어진 합성 사용자는 인터넷에 존재하는 평균적인 소비자를 흉내 내는 대신 우리 조직이 실제로 관찰해 온 사용자의 의견과 행동을 바탕으로 새로운 질문에 대답하게 됩니다.

합성 사용자는 이제 조직이 축적해 온 고객에 대한 지식을 미래 지향적인 모델로 바꿀 수 있다는 것입니다. 예를 들어 지난 수백 건의 인터뷰, 서베이, FGI, 사용성 평가의 결과가 축적되어 있다면 이제 아카이브에서 꺼내 살아 숨 쉬는 사람으로 만들어 낼 수 있습니다.

고객 행태 기반 (Behavior-anchored)

인터뷰와 서베이에는 사용자가 ‘말한’ 것이 들어 있습니다. 그런데 ‘말한 것’만으로 충분할까요?

UX 리서처가 사람을 직접 관찰하는 이유는 사람들이 자신이 하는 행동을 항상 정확하게 설명하지 못하기 때문입니다. 예를 들어, 사용자는 “저는 EV를 구매할 때 충전 가능 시간”이 제일 중요해요”라고 이야기할 수 있지만 실제로는 디자인을 보고 구매할 수도 있으니까요.

“서술”에서 “행동”으로 Anchor를 확장시키는 것이 필요합니다.

이 단계에서는 클릭 스트림, 내비게이션, 스크롤, 검색, 구매 이력, 태스크 실패로 백하기, 이탈, 에러 등 실제 사용자의 행동 데이터가 필요합니다.

이 데이터는 “사용자가 무엇을 중요하게 생각한다고 말하는가”보다 특정 상황에서 실제로 무엇을 했는가를 보여줍니다. 우리가 원하는 것은 인터뷰에 그럴듯하게 답하는 사용자가 아니라 이 화면에서 무엇을 먼저 보고, 어떤 옵션을 선택하고, 무엇을 놓치고, 어디에서 멈추고, 어떤 실수를 하고, 언제 포기하는지를 재현하는 사용자이기 때문입니다.

업데이트 기반 (Living Evidence)

사람은 변합니다. 시장도 변하고, 제품도 변하고, 기술도 변합니다. 2년 전 사용자가 AI 기능을 받아들이던 방식과 지금 사용자가 받아들이는 방식이 다를 수 있습니다.

실제 데이터를 바탕으로 합성 사용자를 만들었다고 해서 그 합성 사용자가 계속 현실을 반영한다고 볼 수는 없습니다. 그래서 Anchor의 가장 오른쪽에는 지속적인 업데이트로 근거를 생생하게 만드는 업데이트 기반의 합성 사용자가 있습니다. 실제 사용자 변화와 함께 변화하는 모델인 것입니다.

예를 들어 Cresta의 합성 사용자는 기업의 실제 고객 상담 데이터를 바탕으로 고객의 행동 패턴을 모델링하고, 이를 “진화하는 고객 퍼소나 (evolving customer personas)”로 설명합니다. 고객이 실제 상담에서 어떤 언어를 사용하고, 어떤 상황에서 불만을 제기하거나 재확인하고, 어떻게 반응하는지를 지속적으로 반영함으로써 고객 모델을 최신 상태로 유지하려는 접근입니다.

Cresta의 합성 고객 소개

Anchor 스펙트럼

지금까지 살펴본 다섯 가지 유형은 아래와 같이 정리해 볼 수 있습니다.

그런데, 실 사용자처럼 반응하는가?

실제 사용자 데이터를 다양하게 사용한다고 해서 좋은 합성 사용자가 자동으로 만들어지는 것은 아닙니다. 실제 데이터를 학습했더라도 모델이 새로운 상황에서 잘못된 행동을 예측할 수 있습니다. 그래서 다음 질문이 필요합니다.

실제 사용자에 기반해 만들었다면, 정말 실제 사용자처럼 반응하는가?

이 질문에 답하는 것이 Align입니다.

참고

When synthetic users fail: A cross-domain benchmark of llm-simulated human survey responses, https://arxiv.org/pdf/2607.26348

NVIDIA Nemotron-Personas-Korea, https://huggingface.co/datasets/nvidia/Nemotron-Personas-Korea

Generating, running and sharing synthetic research, Synthetic Users, https://www.syntheticusers.com/post/generating-running-and-sharing-synthetic-research-really

ReOpsAI, https://reopsai.com

Cresta, https://cresta.com/synthetic-customers

합성 사용자(Synthetic User)를 보는 세 가지 기준

Seungyoon Lee — Mon, 7 Sep 2026 01:47:42 +0900

지난해, 한 콘퍼런스에서 합성 퍼소나에 대한 발표를 듣고 적잖이 충격을 받았던 기억이 납니다. 바로 피엑스디 내부 팀에서는 ReOpsAI에서 금융 관련 AI 퍼소나를 만들었고 관련 프로젝트도 진행했으니 빠르게 이 새로운 변화를 경험하고 있는 것 같습니다.

ReOpsAI 의 AI 퍼소나

합성 사용자, 무엇이 다른가?

지난 몇 년 사이 AI 퍼소나, 합성 퍼소나, 합성 사용자, 합성 패널, 디지털 트윈 같은 말들이 빠르게 늘었습니다. 이름만 보면 다 비슷해 보입니다. 사용자의 특성을 AI에 부여하고, 질문을 던지고, 그 사람이 어떻게 생각하거나 행동할지를 알아보는 방식이니까요.

하지만 조금만 들여다보면 서로 다른 문제에 답하고 있다는 걸 알 수 있습니다. OpenAI의 리서처 Saeideh Bakhshi는 합성 사용자를 입력되는 데이터의 성격, 결과물이 제공하는 의미 등에 따라 6가지로 분류했습니다. 그런데 이 이름들의 경계는 생각보다 뚜렷하지 않고 빠르게 변화하고 있으므로 이 글에서는 ‘합성 사용자’는 넓은 개념의 용어로 접근하려고 합니다.

하지만 다양한 합성 사용자를 어떤 관점으로 봐야 하는가는 중요합니다. 여러 형태의 합성 사용자의 능력과 가치를 어떤 기준으로 봐야 할 것인지, 이번 글에서는 Anchor(근거), Align(정합), Act(행동)이라는 3가지 주제를 얘기해보려고 합니다.

합성 사용자를 보는 세 가지 기준

[Anchor] 합성 사용자는 무엇을 근거로 만들어졌는가?

합성 사용자를 볼 때 가장 먼저 물어야 할 것은 ‘이 사용자가 무엇에 근거하는가’입니다.

LLM에게 ‘EV를 구매하려고 하는 퍼소나를 만들어줘’라고 하면 구매 동기, 기대사항 등 그럴듯한 정보를 만들어냅니다. 그 과정에서 실제로 존재하지 않은 근거가 어느새 진짜처럼 보이기도 합니다.

합성 사용자를 만들어내기 위한 근거가 사용자에게 얼마나 깊이 있게 닿아있느냐, 즉 근거의 직접성에 따라 합성 사용자의 모습이 달라집니다. 이 글에서는 프롬프트에서 시작하는 가정 기반(Assumption), 인구 통계 기반(Population-anchored), 고객 정보 기반 (Customer-anchored), 고객 행태 기반(Behavior-anchored), 나아가 실제 데이터가 계속 갱신되는 업데이트 기반(Living Evidence)으로 구분했습니다. 후자로 갈수록 모델의 상상에서 실제 사용자를 관찰하게 됩니다.

[Align] 합성 사용자의 반응은 얼마나 실제 사용자와 일치하는가?

고객 정보에 잘 근거한 합성 사용자를 만들었습니다. 그런데 이 합성 사용자가 실제 사용자처럼 반응한다고 보장할 수 있을까요? 그럼 우리는 ‘이 사용자의 반응이 얼마나 실제와 일치하는가’를 확인해야 합니다.

합성 사용자의 반응이 ‘사람 같은가(plausible)’와 ‘실제 사용자와 일치하는(aligned)’는 전혀 다른 이야기입니다. 따라서 합성 사용자를 리서치나 의사결정에 쓰려면 현실과 맞는지 확인하는 과정이 필요합니다.

합성 사용자를 무엇과 대조해서 확인하는가에 따라 합성 사용자의 정합성을 판단할 수 있습니다. 이 글에서는 그럴듯함(Plausible), 전문가 검토(Expert-reviewed), 응답 일치(Human response-aligned), 행동 일치(Human behavior-aligned), 변화 일치(Continuous alignment)로 구분했고 후자로 갈수록 현실을 직접적이고 반복적으로 대조하게 됩니다.

[Act] 합성 사용자는 실제로 무엇을 할 수 있는가?

사람은 말과 행동이 다릅니다. 그래서 합성 사용자가 UX에서 더 의미 있는 도구가 되려면, 질문에 대답하는 것을 넘어 ‘제품과 서비스를 행동으로 경험할 수 있어야’ 합니다.

합성 사용자가 얼마나 자율성을 가지느냐에 따라 사용자에 대답(Response), 제품을 사용(Interact), 자율 탐색(Explore)으로 구분했습니다.

[AAA] Anchor, Align, Act

정리하면 합성 사용자는 이 세 가지 질문으로 볼 수 있습니다. 무엇에 근거하는가(Anchor), 현실과 얼마나 맞는가(Align), 실제로 어디까지 행동하는가(Act).

다만 이 스펙트럼을 단순한 성숙도 단계로 볼 필요는 없습니다. 모든 합성 사용자가 세 축의 가장 오른쪽까지 갈 필요도 없습니다. 아이데이션에 필요한 합성 사용자와 실제 제품 행동을 예측하기 위한 합성 사용자에게 요구되는 근거와 검증, 행동 능력은 다르기 때문입니다. 중요한 것은 합성 사용자를 어디에 사용할 것인지에 맞춰 필요한 수준의 Anchor, Align, Act를 갖추는 것입니다.

그렇다면 현재 합성 사용자 관련 서비스들은 AAA의 어느 위치에 있을까요?

합성 사용자 관련 서비스를 제공하는 LLM이 만드는 퍼소나, ReOpsAI, Synthetic Users, Simile는 대략 어떤 서비스를 제공하고 있을까를 매핑해 봤습니다.

● 해당함 ❘ △ 부분적으로 해당함 ❘ 빈칸 = 해당 없음

이 세 기준은 서로 독립적이면서 유기적입니다. 데이터가 풍부해도(Anchor), 실제로 행동하지는 못할 수 있고(Act), 능숙하게 행동해도 그것이 실제 사람과 비슷한지는 또 다른 문제(Align)입니다. 그래서 좋은 합성 사용자는 AAA가 모두 최대치인 사용자가 아니라, 하려는 의사결정에 필요한 만큼의 Anchor, Align, Act를 갖춘 사용자일 것입니다.

이어지는 세 편의 글에서 각 기준을 하나씩 들여다보겠습니다.

합성 사용자(Synthetic User)를 보는 세 가지 기준
1. Overview
2. Anchor [바로가기]
3. Align [바로가기]
4. Act [바로가기]

참고

Synthetic users are not one method, Saeideh Bakhshi, https://saeidehbakhshi.substack.com/p/synthetic-users-are-not-one-method

ReOpsAI, https://reopsai.com

Synthetic Users, https://www.syntheticusers.com

Simile, http://www.simile.com

화면 설계서의 디스크립션을 대신 써 주는 Figma 플러그인을 만들었습니다

문한별 — Thu, 27 Aug 2026 07:50:05 +0900

UX 디자이너로서 화면 설계서를 작업해 본 분이라면 아실 겁니다. 화면을 그리는 일은 그래도 할 만합니다. 손이 가긴 해도 눈에 보이는 결과가 쌓이니까요. 문제는 그 옆에 붙는 디스크립션입니다.

버튼 하나에 번호를 매기고, 번호마다 “이건 무슨 버튼이고, 누르면 어떻게 되고, 어떤 조건에서 비활성화되는가”를 한 줄씩 적어 내려갑니다. 화면 하나에 요소가 스무 개면 스무 번. 화면이 쉰 장이면… 세는 것도 일입니다. 게다가 초벌을 넘겼다고 끝이 아닙니다. 개발을 하면서, 정책과 화면이 바뀔 때마다 몇 주에서 몇 달을 고칩니다. 이 팔로업이 사실 규격서 작업에서 가장 오래 걸리는 일입니다.

그러다 문득 궁금해졌습니다. 이 반복 작업의 절반 이상을 AI가 대신해 줄 수 있지 않을까요?

그래서 만들기 시작했습니다. 이름은 SpecSaver입니다. 스펙 쓰는 시간을 세이브하겠다는 포부를 담았지요. Figma로 작업된 화면 설계서 내의 Key screen을 분석해, 각 화면의 디스크립션을 자동으로 생성해 주는 플러그인입니다. 실제로 써 보면 체감이 꽤 큽니다. 화면 한 장의 디스크립션 초안을 손으로 쓰면 보통 30분에서 1시간은 잡아야 하는데, SpecSaver로 초안을 뽑고 검토, 보완까지 마치면 10분 안팎으로 줄어듭니다. 물론 화면 복잡도와 검토 꼼꼼함에 따라 편차는 있습니다. 중요한 건 0에서 문장을 쥐어짜는 시간이, 이미 있는 초안을 다듬는 시간으로 바뀐다는 점입니다.

만들면서 기준으로 삼은 건 하나였습니다. 기획자가 실제로 일하는 방식에서 출발하자. 없던 일을 새로 시키는 도구가 아니라, 이미 하고 있는 일을 덜어주는 도구여야 한다고 봤습니다.

그려진 화면을 이미지로 봅니다

사실 SpecSaver의 첫 버전은 화면을 지금과 다른 방식으로 읽었습니다. 선택한 화면의 레이어 구조를 읽었습니다. Figma 파일 안에는 화면을 이루는 레이어들이 이름표를 달고 트리로 쌓여 있는데, 그 트리를 훑어 “여기는 버튼, 저기는 입력창”을 찾아내는 방식이었죠. 텍스트와 좌표를 정확히 가져올 수 있어서 나쁘지 않았습니다.

바쁜 기획자에게 레이어 정리까지 시키는건 쉽지 않다

문제는 이 방식이 디자이너 또는 기획자가 레이어를 얼마나 깔끔하게 정리했는지에 통째로 의존한다는 것이었습니다. 현실의 Figma 파일은 그렇게 단정하지 않습니다. 레이어 이름이 ‘Frame 42085672169’로 남아 있는 경우가 태반이고, 눈으로 보면 분명히 하나의 ‘검색 영역’인데 레이어 구조상으로는 뿔뿔이 흩어져 있기도 합니다. 그러면 도구는 “여기가 한 덩어리다”를 알아채지 못하고 엉뚱하게 쪼개거나 놓칩니다.

여기서 선택지가 갈렸습니다. 실무자에게 “도구가 잘 읽게 레이어를 깔끔하게 정리해 주세요”라고 요구할 것인가? 저는 그건 순서가 틀렸다고 봤습니다. 도구가 사람의 작업 방식에 맞춰야지, 사람이 도구에 맞춰 없던 일을 더 하게 만들면 안 되니까요.

그래서 SpecSaver 2는 읽는 방식을 바꿨습니다. 레이어 트리 대신, 다 그려진 화면을 이미지 자체로 인식할 수 있게 했습니다. 사람이 화면을 눈으로 훑으며, 이건 로그인 버튼, 저건 체크 박스… 이렇게 인식하듯이요. 이렇게 하니 레이어가 정리돼 있든 엉망이든 상관없이, 시각적으로 묶인 영역을 사람과 비슷하게 인식했습니다. 화면을 이미지로 이해하는 멀티모달(비전) 모델이 쓸 만해지면서 가능해진 전환입니다. 물론 더 비싸고 느리지만요.

AI가 펼쳐놓고, 사람이 완성합니다

아주 흔한 화면 하나를 예로 들어 보겠습니다. 아이디 입력창, 비밀번호 입력창, 자동 로그인 체크박스, 로그인 버튼, 비밀번호 찾기, 회원가입 링크가 있는 평범한 로그인 화면입니다. 이 화면을 넘겼을 때 SpecSaver가 하는 일을 네 단계로 나눠 보겠습니다.

1단계. SpecSaver가 화면을 통째로 봅니다

SpecSaver는 선택한 프레임 전체를 한 번에 보고 구조를 분석합니다. 그리고 화면 위의 요소들을 찾아 정해진 규칙대로 번호를 매기고, 유형을 판단합니다.

SpecSaver가 로그인 화면을 분석한 뒤 번호 배지를 생성한 모습

이렇게 정리된 번호는 버튼 한 번만 클릭하면 캔버스에 배지로 얹힙니다. 디스크립션을 쓰기 위해 손으로 하나하나 번호 배지를 찍어 본 분이라면, 이것만으로도 절반은 왔다는 느낌이 들 겁니다.

2단계. 사람이 한 번 봅니다

여기서 바로 디스크립션으로 넘어가지 않습니다. AI가 뽑은 구조를 사람이 먼저 검토합니다.

SpecSaver의 분석 항목 편집 모드

번호 순서가 마음에 안 들면 바꿉니다. 로그인 버튼을 자동 로그인 체크박스보다 먼저 설명하고 싶다면 리스트를 끌어 순서를 조정하면 됩니다. 이름을 바꾸거나 유형을 고칠 수 있습니다. 필요 없는 항목은 지웁니다.

AI가 한 번에 많이 뽑되, 최종 구조는 사람이 확정합니다.

3단계. 맥락을 넣고 초안을 생성합니다

구조가 확정되면 SpecSaver가 수초 내에 상세한 디스크립션을 생성해 냅니다. 생성 전에 미리 두 가지를 함께 넣어두면 디스크립션의 결과를 조절할 수 있습니다.

SpecSaver에서 화면 밖 맥락을 주입하는 두 가지 경로

하나는 배경 자료입니다. 프로젝트 전체의 골격이 되는 사업기획서, 기능정의서 같은 정책 문서를 첨부해 두면, “어떻게 동작하는가”의 근거로 삼습니다.

다른 하나는 해당 화면에 특정된 컨텍스트입니다. “로그인 실패 시 5회까지만 시도할 수 있다” 같은, 화면에는 안 보이지만 반드시 들어가야 할 정책을 미리 적어두면 초안이 그 내용을 반영합니다. 화면으로 “무엇이 어디 있는가”를 보고, 입력된 컨텍스트와 문서로는 “어떻게 동작하는가”를 읽는 셈입니다.

그렇게 나온 초안은 대략 이런 모습입니다.

SpecSaver에서 생성된 디스크립션

4단계. 사람이 또 한 번 봅니다

마지막은 다시 사람입니다. 디스크립션의 내용 편집 모드로 진입해서 [확인 필요]를 채우고, 어색하거나 보충이 필요한 문장을 다듬습니다. 편집 모드에서는 화면 설계할 때 자주 쓰는 ‘TBD, 참조 페이지’와 같은 입력을 도와주는 칩(Chip)이 제공되고, 가독성을 위한 문장 들여 쓰기 같은 디테일도 지원합니다.

정리하면 이렇습니다. AI가 화면을 보고 → 사람이 구조를 다듬고 → AI가 초안을 쓰고 → 사람이 내용을 완성합니다. AI 한 번, 사람 한 번. 이 리듬이 SpecSaver의 핵심입니다.

피그마 캔버스에 생성된 디스크립션 표 (화면 우측)

디스크립션은 표 형태와 리스트 형태 중에서 고를 수 있도록 했습니다. 팀이나 고객사가 쓰는 규격서 양식에 맞추기 위해서입니다.

조금 더 안을 들여다보면

이 네 단계는, 뜯어보면 두 번의 AI 호출로 이뤄집니다. 화면을 보고 구조를 뽑는 분석 호출, 그리고 확정된 구조에 맥락을 얹어 문장을 만드는 생성 호출입니다. 그 사이에 사람의 검토가 끼어 있는 구조죠.

두 호출은 모두 중간 서버를 한 번 거쳐 나갑니다. 이유는 둘입니다. 하나는 팀의 화면 설계서 작성 가이드와 프롬프트를 클라이언트에 노출하지 않고 서버 뒤에 숨기기 위해서고, 다른 하나는 모델 교체·재시도 같은 통제를 한곳에서 하기 위해서입니다. 작은 디테일 하나 더 붙이면, 작업마다 모델이 ‘생각하는 깊이’를 다르게 줬습니다. 구조를 빠르게 훑는 분석에는 얕게, 문장을 짓는 생성에는 조금 더 깊게. 필요 이상으로 뜸 들이지 않도록요.

실무자는 작업 도중에 멈추면 안 됩니다

여기엔 눈에 잘 안 띄는 고민이 하나 더 있습니다. AI를 부르는 도구는 AI 서버 사정에 휘둘립니다. 요즘처럼 다들 AI를 쓰는 시기엔 서버가 몰려서(과부하) 응답이 느려지거나 아예 실패하는 일이 생깁니다. 그런데 생성 버튼을 눌렀는데 그대로 멈춰버리는 경험은 실무자의 흐름을 가장 확실하게 끊는 일입니다.

그래서 안전장치를 겹겹이 넣었습니다. 요청이 실패하면 1초, 2초, 4초로 간격을 늘려가며 몇 번 다시 시도하고(지수 백오프), 그래도 안 되면 메인으로 쓰는 최신 모델 대신 더 가벼운 모델로 자동으로 갈아탑니다. 생성처럼 오래 걸리는 작업은 결과를 한꺼번에 기다리게 하지 않고 만들어지는 대로 흘려보내되(스트리밍), 첫 응답이 90초, 중간 응답이 20초를 넘게 끊기면 하염없이 매달려 있지 않도록 스스로 중단하며 상태를 안내합니다.

여기서도 한 가지를 지킵니다. 더 가벼운 모델로 자동 전환 됐을 때 대체 모델로 넘어갔다는 사실을 숨기지 않습니다. 품질이 평소와 다를 수 있으니 “지금은 대체 모델로 만든 결과”라고 배너로 알려줍니다. 뒤에서 설명할 [확인 필요]와 같은 태도입니다. 불확실한 것도, 평소와 다른 상태도 사람에게 숨기지 않고 드러내는 것입니다.

화면은 저장되지 않습니다

AI 도구를 쓸 때 가장 먼저 드는 걱정이 이겁니다. “내가 넘긴 화면과 정보가 어딘가에 저장되거나, 모델 학습에 쓰이는 건 아닐까?” 실무에서 다루는 화면은 대개 미공개 서비스이고 보안이라 민감한 부분이니까요.

먼저, SpecSaver는 화면 이미지를 서버에 저장하지 않습니다. 화면은 분석에 필요한 그 순간에만 중간 서버(프록시)를 거쳐 AI로 전달되고, 응답이 오면 그 자리에서 사라집니다. 실제로 서버에는 이미지를 담아둘 저장소 자체가 붙어 있지 않고, 이미지가 로그로 기록되는 경로도 없습니다. 화면이 향하는 곳은 오직 하나, Google의 Gemini 뿐입니다. 다른 어떤 제3의 서버로도 보내지 않습니다.

그다음이 중요한데, AI 호출은 사용자가 직접 넣은 API Key로 이뤄집니다. SpecSaver는 각 사용자가 자기 Google Gemini Key를 설정에 입력해 쓰는 구조입니다(BYOK, Bring Your Own Key). 즉 화면은 SpecSaver의 어떤 공용 계정이 아니라, 개인 소유의 Key를 통해 Google의 Gemini로 직접 갑니다.

그러면 “학습에 쓰이느냐”는 결국 사용자가 넣은 Key의 등급에 달립니다. Google의 유료 Gemini API는 프롬프트·응답을 제품 개선(모델 학습 포함)에 사용하지 않는다고 약관에 명시합니다. 반면 무료 등급은 제출한 내용이 제품·서비스 개선에 사용될 수 있고, 사람 검토자가 볼 수도 있습니다. (유럽경제지역·스위스·영국 사용자는 무료 등급에도 유료 약관이 적용됩니다.)

따라서 민감한 자료를 다룬다면, Gemini Key를 유료 등급으로 쓰길 권합니다. 학습 사용 여부의 최종 결정은 그 Key가 쥐고 있기 때문입니다. 정책은 바뀔 수 있으니, 민감한 작업 전에는 Google의 최신 Gemini API 약관을 한 번 확인하시는 편이 안전합니다.

100% 완성된 디스크립션을 제공하지 않는 이유

여기서 이상하게 느끼는 분이 계실 겁니다. 기왕 AI를 붙일 거면, 화면을 넣으면 완성된 설계서가 뚝 나오게 하면 안 되나요? 버튼 한 번에 규격서 완성. 데모로 보여주면 제일 그럴듯한 그림입니다.

만들면서 저도 그런 유혹을 받았습니다. 그런데 조금만 따져보니 그건 안 되는 방향이었습니다.

완성본을 받으면, 사람은 그냥 받아들입니다

연구자들이 반복해서 관찰한 현상이 있습니다. 사람과 AI가 함께 일하는 팀이 종종 AI 혼자 할 때보다 못한 결과를 낸다는 것입니다. 사람이 자기 판단을 AI 결과에 더하는 게 아니라, AI가 준 걸 그냥 받아들이기 때문입니다. 틀린 답까지 같이 통과시키는 것이죠.

그럼 차라리 사람을 빼고 AI가 완성본을 한 번에 뽑는 게 낫지 않냐고요? 그 결론이 성립하려면 전제가 하나 필요합니다. AI가 절대 안 틀려야 합니다. 그래야 사람이 안 봐도 되니까요. 그런데 디스크립션은 정확히 그 전제가 성립하지 않는 일입니다. 뒤에서 다시 이야기하겠지만, “이 버튼을 누르면 무슨 일이 벌어지는가”는 화면에 없는 정보라 AI가 구조적으로 틀릴 수밖에 없습니다. 틀릴 수밖에 없는 일에서 완성본을 한 번에 뱉으면, 그 틀린 부분을 사람이 그대로 받아들일 위험만 커집니다.

그러니 문제는 사람이 낀 것이 아니라 낀 사람이 판단을 안 한 것입니다. 하버드의 부친차(Buçinca) 연구진이 내놓은 처방도 사람을 빼라가 아니라 그 반대였습니다. 사람이 곧바로 수용하지 못하도록, 중간에 스스로 판단하게 만드는 장치. 이른바 인지적 강제 장치(cognitive forcing function) 를 끼워 넣으면, 틀린 AI 제안에 휩쓸리는 일이 줄어든다는 것입니다. 완성본을 툭 던지는 도구는 정확히 그 반대로 작동합니다. 받아들이기 가장 쉬운 형태로 결과를 내밀어, 사람이 판단을 건너뛰게 만들기 때문입니다.

SpecSaver’s human-in-the-loop workflow

SpecSaver가 ‘AI 한 번, 사람 한 번’의 리듬을 고집하고, 분석과 생성 사이에 사람의 검토 단계를 일부러 끼워 넣은 건 이 때문입니다. 검토를 권하는 게 아니라 구조적으로 거치게 만든 것입니다. 완성본을 받아 대충 넘기다 보면, 남는 건 빠르게 만들었지만 뭐가 맞고 뭐가 틀렸는지 모르는 설계서일 뿐이니까요.

화면은 무엇은 알아도 어떻게는 모릅니다

이유는 하나 더 있습니다. 화면 이미지가 알려주는 건 딱 하나입니다. 무엇이 어디에 있는가. 버튼이 여기 있고, 입력창이 저기 있다. 여기까지는 AI가 꽤 잘 봅니다.

하지만 디스크립션의 진짜 알맹이는 그게 아닙니다. 이걸 누르면 무슨 일이 벌어지는가, 어떤 조건에서 막히는가, 왜 이렇게 동작하는가. 이건 화면 어디에도 안 적혀 있습니다. 기획자의 머릿속과 기획서에 있습니다.

앞의 로그인 버튼을 다시 봅시다. “버튼을 누르면 로그인이 된다”까지는 화면만 봐도 짐작이 갑니다. 그런데 “실패하면 어떻게 되는가”는 화면에 없습니다. 5회 실패하면 잠기는지, 그냥 에러 메시지만 뜨는지는 정책의 영역입니다.

그럴듯한 거짓말이 제일 위험합니다

AI가 이 빈칸을 그럴듯하게 채우면 어떻게 될까요. 그럴듯한 거짓말이 됩니다. 화면만 보고 “이 버튼을 누르면 홈으로 이동합니다”라고 자신 있게 써놨는데, 실제로는 이전 화면으로 돌아가는 버튼일 수 있습니다. 검토하는 사람이 그 문장을 믿어버리면, 틀린 설계서가 그대로 나갑니다. 매끄럽게 쓰인 문장일수록 더 잘 통과되겠지요.

그런데 스탠퍼드 연구진(Vasconcelos 외, 2023)은 반대 방향의 실마리도 보여줍니다. AI가 무엇을 근거로 그렇게 판단했는지를 드러내면, 사람이 맹목적으로 따르는 정도가 줄어든다는 것입니다. 핵심은 판단의 근거와 불확실성을 감추지 않고 보여주는 데 있습니다.

그래서 SpecSaver는 화면만으로 단정할 수 없는 자리는 확신하는 척 채우지 않고, [확인 필요]로 남깁니다. 채워야 할 빈칸이 어디인지를 사람에게 짚어주는 것입니다. 비슷한 발상은 코드 자동완성 도구 연구에서도 나옵니다. 같은 스탠퍼드 그룹이 참여한 2024년 연구(ACM TOCHI)는, AI가 짜준 코드에서 확신이 낮은 부분을 골라 인라인으로 표시해 주는 방식을 실험했습니다. 개발자들은 이런 표시가 뭉뚱그리지 않고, 짚어주되, 과하지 않을 때 가장 쓸모 있다고 평가했습니다. [확인 필요]가 노리는 것도 똑같습니다. 문장을 매끄럽게 다 채워 넘기는 대신 여기가 불확실하다를 콕 집어 사람 앞에 놓아두는 것입니다.

금지해야 할 것은 추론 자체가 아니라 추론을 숨기는 것입니다. AI가 합리적으로 추측하는 건 괜찮습니다. 다만 다른 그럴듯한 답이 열려 있다면, 확신한 얼굴로 하나만 써 놓지 말고 “여기는 확인이 필요하다”라고 함께 적어두는 것입니다. 판단의 기준을 “내가 확신하는가”(주관)에서 “다른 그럴듯한 답이 존재하는가”(객관)로 바꾼 셈입니다.

결국 이 모든 결정은 한 가지 고민으로 이어집니다. 자동화를 너무 밀어붙이면 사람이 판단을 놓고, 반대로 사람이 다 붙들고 있으면 도구가 아무것도 덜어주지 못합니다. SpecSaver는 이 자동화와 통제감 사이의 균형을 맞추려고 했습니다. 지겨운 절반은 도구에 맡기되, 판단이 필요한 자리에서는 사람이 반드시 개입하게. 그 경계를 어디에 그을지가, 사실 이 도구를 만드는 내내 가장 오래 붙든 질문이었습니다.

진짜 오래 걸리는 일, 팔로업

앞에서 잠깐 말했지만, 규격서 작업에서 가장 시간을 잡아먹는 건 초벌이 아니라 이후의 팔로업 과정입니다. 한 번 쓰고 끝이 아니라, 몇 주에서 몇 달에 걸쳐 계속 고치고 고도화하는 일입니다.

이 팔로업에도 나름의 규칙이 있습니다. 수정한 부분은 빨간 글씨로 표시하고, 삭제한 부분은 취소선을 긋고, 수정한 페이지에는 변경 이력을 남깁니다. 손으로 하면 빠뜨리기 쉽고, 빠뜨리면 “이번에 뭐가 바뀐 거냐”는 질문이 돌아옵니다.

SpecSaver의 디스크립션 수정 검토 상세 화면

SpecSaver는 이 팔로업을 돕습니다. 업데이트해야 할 내용을 입력하면 선택한 기존 디스크립션 표 내에서 수정이 필요한 부분을 모두 찾아낸 뒤에 어떻게 수정이 되는지 미리 보여줍니다. 원본과 나란히 비교해서 보여주고, 확정하면 실제 디스크립션에 반영합니다. 기존 디스크립션에서 바뀐 부분을 빨간색으로 하이라이트하고, 삭제하는 정의에 취소선을 그어 기존 디스크립션 표에 반영합니다. 그리고 가장 중요한 것. 이전 버전에서 표시했던 바뀐 부분의 하이라이트는 보통 상태로 되돌려 놓습니다. 그래야만 이번에 고친 최신 내용만 하이라이트 할 수 있으니까요.

지금 그리고 앞으로의 계획

SpecSaver는 현재 사내에서 실무에 적용해 보는 단계입니다. 우리 팀의 실제 프로젝트에 매일 테스트하면서, 어떤 화면에서 잘 되고 어떤 상황에서 부족한지를 보고 있습니다. 도구를 팀 밖에 내놓기 전에, 먼저 충분히 써보려고 합니다.

앞으로 다듬어 갈 방향은 대략 이렇습니다. 지금 가장 공들이는 건 팔로업 고도화입니다. 버전 태그와 변경 이력을 캔버스에 남기고, 그 이력을 따로 뽑아낼 수 있게 만드는 일입니다. 그 밖에 규격서 표 양식을 더 갖추고, 여러 화면을 한 번에 처리하는 배치 작업, 도구 자체가 자기 초안의 누락·[확인 필요]를 점검하는 '자가 검증' 같은 것들을 로드맵에 두고 있습니다. 외국어 지원, Gemini 외 클로드, 챗GPT 같은 다양한 모델 선택도 고려 중이고요.

한 가지 방향은 특히 눈여겨보고 있습니다. SpecSaver는 표준화된 규칙에 맞춰 커스터마이즈 할 수 있습니다. 어떤 어체로 쓸지, 어떤 항목을 어떤 위계로 담을지, 무엇을 [확인 필요]로 남길지와 같은 규칙을 바꾸면 같은 화면에서도 전혀 다른 결의 디스크립션이 나옵니다. 여기에 플러그인 설정으로 조절할 수 있는 것들(표 양식, 번호 체계, 유형 분류 등)까지 더하면, 결국 각 기업마다 고유한 UX 규격서 표준에 맞춰 도구를 통째로 맞춤할 수 있다는 뜻이 됩니다.

화면설계서 양식은 회사마다, 심지어 프로젝트마다 다릅니다. 기존 규격서 스타일을 가이드로 녹이고 설정을 그 팀에 맞게 잡아주면, 범용 도구가 아니라 회사의 화면설계서를 쓰는 도구가 됩니다. 아직 구체적인 제공 형태를 정한 단계는 아니지만, SpecSaver가 팀 밖으로 나간다면 이런 커스터마이즈가 하나의 축이 될 수 있다고 보고 있습니다.

마치며

만들면서 계속 스스로에게 물었던 건 “이것이 기획자의 역할을 얼마나 대체하나?”였습니다. 답은 아니오입니다. 그리고 그래서는 안 된다고 생각합니다.

디스크립션 작성에는 두 종류의 일이 섞여 있습니다. 하나는 번호를 매기고 요소를 나열하는, 판단이 거의 없는 노동입니다. 다른 하나는 이 화면이 이렇게 동작해야 하는 이유를 정하고, 이 페이지에서 어디까지 설명하고 다음 페이지로 넘겨야 읽는 사람이 보기 더 좋을지에 대한 판단 그 자체인 일입니다. 전자는 AI가 덜어줄 수 있습니다. 후자는 여전히 사람 몫이고, 앞으로도 그럴 것입니다.

돌아보면 이 도구의 크고 작은 결정들은 대부분 한 방향을 봅니다. 레이어를 정리하라고 요구하는 대신 화면을 눈으로 읽고, 번호 배지를 대신 찍고, 서버가 몰려도 작업이 멈추지 않게 하고, 몇 달짜리 팔로업을 거들고, 확신할 수 없는 자리는 숨기지 않고 드러내는 것. 전부 기획자의 작업 흐름을 끊지 않으려는 선택이었습니다.

이건 저희 팀에서도 계속 나오는 이야기입니다. 같은 pxd의 동료가 쓴 글들도, 결국 ‘AI를 잘 부리는 기술’보다 ‘자기 일에 대한 사람의 판단력’이 진짜 변수라는 결론에 닿습니다. AI 앞에서 “이건 괜찮고 이건 아니다”를 가르는 기준은 프롬프트를 잘 쓰는 법이 아니라 사용자를 관찰하고 맥락을 이해해 온 경험에서 나옵니다.

SpecSaver가 하는 일도 딱 거기까지입니다. 그 판단력을 대신하려는 게 아니라, 판단력이 발휘될 자리를 비워두는 것. 지겨운 절반을 덜어주고, 아낀 시간을 단순 노동이 아닌 진짜 고민에 쓰게 하는 것.

그거면 충분하다고 생각합니다. 적어도 지금은요.

써보고 싶으시다면

앞서 말씀드린 대로 SpecSaver는 지금 사내에서 다듬는 중이라, 아직 외부에서 바로 쓰실 수는 없습니다. 그럼에도 “우리 팀 작업에도 이런 게 필요하다” 싶거나, 제품이 궁금하시다면 편하게 문의를 남겨 주세요.

프로덕트 문의: xdax@pxd.co.kr

참고 자료

연구

Buçinca, Z., Malaya, M. B., & Gajos, K. Z. (2021). To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making. Proceedings of the ACM on Human-Computer Interaction, 5(CSCW1). Harvard University. https://doi.org/10.1145/3449287
Vasconcelos, H., Jörke, M., Grunde-McLaughlin, M., Gerstenberg, T., Bernstein, M. S., & Krishna, R. (2023). Explanations Can Reduce Overreliance on AI Systems During Decision-Making. Proceedings of the ACM on Human-Computer Interaction, 7(CSCW1). Stanford University. https://doi.org/10.1145/3579605
Vasconcelos, H., Bansal, G., Fourney, A., Liao, Q. V., & Vaughan, J. W. (2024). Generation Probabilities Are Not Enough: Uncertainty Highlighting in AI Code Completions. ACM Transactions on Computer-Human Interaction. https://doi.org/10.1145/3702320

함께 보면 좋은 pxd 글

이예진 (2026). 「AI와 협업하는 최선의 워크플로우 찾기」. pxd story. https://story.pxd.co.kr/1914