제품 화면에서 에이전트 그래프를 역추론한다 — Perplexity 리버스 엔지니어링

"Perplexity 클론"이라는 이름이 붙은 예제를 열면 시선이 대개 결과물로 간다. 검색이 되는가, 답변이 그럴듯한가. 그런데 완성도로만 보면 이런 클론은 거의 항상 원본에 못 미치고, 그 격차를 확인하는 것만으로는 남는 것이 없다.

값이 있는 것은 클론이 아니라 그 앞에 있는 절차다 — 완성된 제품의 화면만 보고 그 안에서 도는 에이전트 그래프를 되짚어 그리는 일. 클론은 그 추론이 맞았는지 확인하는 검증 수단일 뿐이다. 이 글은 그 절차를 다섯 단계로 세우고, Perplexity에 적용해 State·노드·조건분기까지 그린다. 앞 시리즈에서 부품을 다 만들었으니 이제 제품을 해체할 차례다.

시작하기 전에 선을 하나 긋는다. 화면에서 본 것과 거기서 끌어낸 결론은 종류가 다른 진술이다. 상용 제품의 내부 구현은 공개돼 있지 않으므로, 이 글이 원 제품에 대해 말하는 것은 전부 관찰과 추론이며 내부 동작의 확인이 아니다. 이 구분을 문장 안에서 화살표로 갈라 놓는 것이 이 절차의 첫 규율이다.

용어 정리

절차의 뼈대

이 절차가 붙잡으려는 문제는 다섯 축으로 갈린다.

다섯 축 중 앞의 셋이 이 글의 범위이고, 뒤의 둘(다중 실행·진행 표시)은 UI 계층에서 결판나므로 다음 편에서 다룬다.

리버스 엔지니어링 5단계

절차에 이름을 붙여 두면 다음 제품에도 그대로 쓸 수 있다. 아래 R1~R5는 위 도식이 실제로 밟은 순서를 단계로 고정한 것이다.

R4 행의 서술 형태가 이 절차 전체의 어투다 — 화살표 왼쪽이 화면에서 본 것, 오른쪽이 거기서 끌어낸 결론이다.

도식은 여섯 노드인데 표는 다섯 행이다. 두 곳에서 어긋난다. 도식의 「제품 관찰」 하나가 표에서는 R1(입력)과 R2(출력)로 갈라지고, 반대로 표의 R5 하나가 도식에서는 「구현으로 검증」과 「차이 관찰」 둘로 갈라진다. 뒤쪽이 더 중요하다 — 구현을 돌려 보는 것과 차이를 기록하는 것은 다른 작업이고, 대개 후자가 생략된다. 도식에만 있는 점선 화살표(차이 → 관찰)가 그 생략을 막는 장치다.

이 절차의 산출물은 그래프가 아니라 차이 목록이다. R5까지 갔는데 원본과 무엇이 다른지 적지 못했다면 R1의 관찰이 얕았던 것이다.

그래서 절차가 직선이 아니라 순환이다. 차이가 곧 다음 관찰 대상이고, 관찰이 늘면 그래프가 정교해지며, 정교해진 그래프가 다시 새 차이를 드러낸다. 한 바퀴로 끝나는 리버스 엔지니어링은 관찰이 부족했다는 뜻일 때가 많다.

각 단계에서 던지는 질문

다섯 질문 모두 화면에서 답할 수 있는 형태라는 점이 핵심이다. 내부 문서나 소스 접근을 전제하지 않는다.

관찰을 아키텍처로 옮기는 번역 규칙

일곱 행이 전부 "화면 요소 → 그래프 요소"의 단방향 사전이고, 이 사전이 있으면 R3의 번역이 창작이 아니라 조회가 된다.

이 표에서 가장 많이 값을 하는 행은 첫 번째다. 토글과 드롭다운은 설계자가 "여기서 흐름이 갈린다"고 이미 선언해 놓은 자리이기 때문이다.

제품 팀이 사용자에게 선택지를 노출하기로 했다는 것은, 그 선택이 뒤쪽 처리를 실제로 바꾼다는 뜻이다. 바꾸지 않는다면 컨트롤을 둘 이유가 없다. 그래서 UI의 분기 지점은 아키텍처 분기 지점의 가장 신뢰할 만한 대리 지표다.

Perplexity 동작 분해 — 관찰과 추론

관찰의 출발점은 제품이 스스로 밝힌 설명이다. 2026년 7월 기준 공개 화면과 소개 문구를 근거로 한다 — Focus 구성과 UI는 제품 업데이트에 따라 바뀔 수 있다.

Perplexity는 웹 검색 결과를 기반으로 사용자의 질의에 최신 정보를 활용한 답변을 생성한다.

특히 Focus 기능을 통해 정보의 소스를 정하고, 해당 소스 안에서의 검색 결과를 받아볼 수 있다.

Focus 6종

여섯 중 넷만 구현했고, 빈 둘은 성격이 다르다 — Writing은 도구가 필요 없어서 쉬운 쪽이고, Social은 쓸 만한 공개 API를 찾는 것부터가 일이라 어려운 쪽이다.

다섯 단계와 이 구현의 대응

두 번째 열이 이 표의 전부다. 왼쪽은 누구나 화면에서 재현할 수 있는 사실이고, 오른쪽은 거기서 끌어낸 가설이며, 둘 사이의 화살표가 그 경계다.

도식은 다섯 노드, 표도 다섯 행으로 일치한다. 도식이 순서만 말하고 표가 근거를 말하는 관계다.

이 구현이 다섯 단계 중 실제로 만든 것은 가운데 셋(검색·선별·생성)뿐이다. 양 끝단인 질의 분해와 후속 질문은 비어 있다.

그리고 그 공백이 실패가 아니라 R5의 산출물이다. 무엇을 안 만들었는지 정확히 적어 두면 그것이 다음 확장 과제 목록이 되고, 클론의 완성도를 과장하지 않게 된다. "다 만들었다"는 말이 나오는 순간 차이 목록이 사라진다.

LangGraph 설계 — 노드·상태·조건분기

설계의 출발점

Perplexity는 기본적으로 웹 검색을 기반으로 답변을 생성하므로, 웹 검색 도구를 결합한 단일 에이전트 시스템으로 구현할 수 있다.

그러나 Focus 기능을 구현하려면 논문 검색, 영상 검색 등 더 다양한 도구를 결합해야 한다.

핵심은 "멀티 에이전트가 아니라 단일 에이전트 + 다중 도구"라는 판단이다. 소스가 늘어난다고 에이전트를 늘리지 않는다. 단일 에이전트의 경계에서 정리한 일곱 신호에 비춰 보면, 여기서 늘어난 것은 도구의 이질성이지 책임의 충돌이 아니다. 검색·논문·수식·영상 넷은 전부 "질문에 근거를 대준다"는 하나의 목표를 향한다.

그래프 구조

Focus 표는 여섯 행인데 도식은 네 갈래다. 빠진 둘이 Writing과 Social이고, 이것이 도식과 표를 나란히 놓아야 보이는 정보다 — 표는 제품이 제공하는 것을, 도식은 구현이 도달한 곳을 그린다. 두 그림의 차이가 곧 R5의 차이 목록 한 줄이 된다.

설계 결정 세 가지

세 결정이 전부 같은 방향을 향한다 — 판단을 모델에서 걷어내 코드와 UI로 옮긴다.

이 방향은 공짜가 아니다. 세 행의 「대가」 열을 이어 붙이면 하나의 문장이 된다 — 사용자가 소스를 잘못 고르면 시스템은 그것을 바로잡을 수단이 없다.

모델에게 라우팅을 맡겼다면 잘못된 선택을 모델이 흡수해 줬을 것이다. 결정론을 택한다는 것은 정확도의 책임을 사용자에게 넘긴다는 뜻이고, 그 교환이 성립하려면 사용자가 무엇을 고르는지 알아야 한다. Focus처럼 의미가 자명한 컨트롤에서만 이 교환이 유리하다.

라우팅 주체 네 가지

네 방식은 비용을 어디에 낼 것인가로 갈린다 — 1행은 사용자의 인지에, 2·3행은 토큰에, 4행은 지연에 낸다.

원 제품에서 화면으로 확인할 수 있는 것은 여기까지다. Focus를 고르지 않아도 답변이 나오고, 고르면 그 소스로 한정된 결과가 온다. 즉 선택이 비어 있을 때도 무언가가 소스를 정한다.

그것이 표의 어느 행인지는 화면에 드러나지 않는다. 모델이 분류하는지, 규칙이 기본값을 주는지, 여러 소스를 동시에 때리고 합치는지는 밖에서 구분되지 않기 때문이다. 말할 수 있는 것은 1행 단독은 아니라는 것뿐이고, 이 구현은 그중 결정론적인 절반만 만든 것이다.

여기까지가 관찰에서 그래프까지다. 컨트롤이 State 필드가 되고, 등장 순서가 실행 순서가 되고, Focus 하나가 분기 키가 됐다.

그런데 R2에서 목록화한 출력 표면 중 아직 손대지 않은 것이 남아 있다. 본문 문장 끝의 [1], [2] 다. 이 번호가 Sources 카드의 특정 항목을 가리킨다는 관찰은 적어 뒀지만, 지금 그래프는 그 대응을 만들어 낼 방법이 없다 — 도구가 문자열 한 덩어리를 반환하는 순간 어느 문장이 어느 문서에서 왔는지가 사라지기 때문이다. 다음 편에서 코드를 마저 조립하고, 인용 정합성이 왜 프롬프트 문제가 아니라 상태 설계 문제인지를 본다.