AI 빌더(builders)들이 기묘하고 새로운 문제에 직면하고 있습니다.

코딩 부분은 점점 덜 외로워지고 있습니다.

훌륭한 에이전트(agent)는 저장소(repository)를 조사하고, 현재 문서(docs)를 읽고, 브라우저를 열고, 테스트를 실행하며, 로그를 요약하고, 사용자가 모든 세부 사항을 채팅창에 붙여넣기를 기다리지 않고도 프로젝트를 진전시키는 데 도움을 줄 수 있습니다.

이것은 실질적인 변화입니다.

이것이 바로 MCP가 중요한 이유이기도 합니다. MCP는 AI 애플리케이션이 외부 시스템(도구, 데이터 소스, 워크플로우 및 애플리케이션 컨텍스트)에 연결할 수 있는 표준화된 방법을 제공합니다. AI 어시스턴트를 단순한 텍스트 박스로 취급하는 대신, 실제로 작업이 일어나는 장소에 연결할 수 있습니다.

빌더들에게 이는 보통 다음과 같은 스택(stack)을 의미합니다:

• 저장소 컨텍스트 (repo context)
• 브라우저 컨텍스트 (browser context)
• 문서 컨텍스트 (documentation context)
• 데이터베이스 컨텍스트 (database context)
• 이슈 및 프로젝트 컨텍스트 (issue and project context)
• 디자인 또는 제품 컨텍스트 (design or product context)

이러한 것들이 연결되면, 에이전트는 함수의 자동 완성(autocomplete) 그 이상을 할 수 있습니다.

제품을 운영하는 데 도움을 줄 수 있습니다.

하지만 에이전트가 유용해질수록, 또 다른 병목 현상(bottleneck)이 더 눈에 띄게 됩니다.

당신의 AI는 당신이 배포(ship)하는 것을 도울 수 있습니다.

하지만 그것은 여전히 누가 관심을 가져야 하는지는 알지 못합니다.

첫 번째 에이전트 병목 현상은 컨텍스트였습니다

AI 빌더들이 느꼈던 첫 번째 좌절감은 주로 컨텍스트(context)의 부재에 관한 것이었습니다.

모델은 당신의 코드베이스(codebase)를 알지 못했습니다. 당신이 사용 중인 프레임워크(framework)의 정확한 버전을 알지 못했습니다. 브라우저의 에러를 볼 수 없었습니다. 스키마(schema)를 조사할 수 없었습니다. 이슈 스레드(issue thread)를 복사해서 붙여넣지 않는 한 읽을 수 없었습니다.

그래서 명백한 해결책은 에이전트를 더 많은 접점(surfaces)에 연결하는 것이었습니다.

그것이 바로 도구 계층(tool layer)입니다.

이것은 많은 수동 전달 과정을 제거해주기 때문에 유용합니다:

• "여기 파일들이 있습니다."
• "여기 스크린샷이 있습니다."
• "여기 최신 문서 페이지가 있습니다."
• "여기 데이터베이스 스키마가 있습니다."
• "여기 실패한 테스트 출력 결과가 있습니다."

만약 에이전트가 이러한 것들을 스스로 안전하게 가져올 수 있다면, 사용자는 컨텍스트를 패키징하는 데 시간을 덜 쓰고 의사결정을 내리는 데 더 많은 시간을 쓸 수 있습니다.

이 부분은 에이전트 스택(agent stack)에서 점점 더 명확해지고 있는 부분입니다.

에이전트에게 적절한 시스템에 대한 통제된 접근 권한을 부여하십시오.

에이전트가 읽고, 추론하고, 테스트하고, 행동하게 하십시오.

민감한 작업에 대해서는 인간이 루프 안에 머물도록(human in the loop) 유지하십시오.

그것만으로도 아무것도 없는 빈 채팅창보다는 이미 더 나은 워크플로우(workflow)입니다.

더 빠른 배포는 두 번째 병목 현상을 드러냅니다

하지만 더 빠르게 배포한다고 해서 수요가 자동으로 창출되는 것은 아닙니다.

사실, 그것은 수요 문제를 더 명확하게 만들 수도 있습니다.

만약 당신이 주말 사이에 프로토타입(prototype)을 구축할 수 있다면, 다음 문제는 더 빨리 찾아옵니다:

• 누가 이것을 테스트해야 하는가?
• 누가 이 문제의 고통스러운 버전을 겪고 있는가?
• 누가 이와 인접한 무언가를 만들고 있는가?
• 누가 예의 바른 격려가 아닌, 진지한 피드백을 줄 수 있는가?
• 누가 디자인 파트너(design partner)가 될 수 있는가?
• 누가 정확히 이런 종류의 작업을 위해 채용을 진행 중인가?
• 누가 내가 제공할 수 있는 것을 찾고 있는가?

이것들은 코딩에 관한 질문이 아닙니다.

이것들은 매칭(matching)에 관한 질문입니다.

그리고 초기 빌더(builders)들에게 매칭은 종종 실질적인 제약 사항이 됩니다.

작동하는 데모(demo), 멋진 README, 깔끔한 랜딩 페이지(landing page), 그리고 영리한 MCP 통합(integration)을 갖추고 있더라도, 적절한 사람들이 그것을 찾지 못했다면 여전히 막혀 있을 수 있습니다.

제품은 존재합니다.

수요는 다른 곳에 있습니다.

현재의 기본 답변은 여전히 매우 수동적입니다:

• X(구 트위터)에 게시
• LinkedIn에 게시
• Discord에서 질문
• Show HN 작성
• 사람들에게 DM 보내기
• 디렉토리(directories) 탐색
• 스프레드시트 유지
• 친구들에게 소개 요청

이 모든 방법이 효과가 있을 수도 있습니다.

하지만 이 방법들은 소음이 심하고, 공개적이며, 반복적이고, 실제 필요(need)에 맞지 않는 경우가 많습니다.

수요는 콘텐츠와 같지 않습니다

초기 단계의 많은 수요는 공개적인 게시물이 되기를 원하지 않습니다.

"베타 사용자를 찾습니다"라는 문장은 공개적으로 사용하기에 괜찮습니다.

하지만 유용한 버전은 대개 더 구체적입니다:

저는 이미 Claude Code나 Cursor를 사용 중인 팀을 위한 에이전트 워크플로우(agent workflow) 도구를 구축하고 있습니다. 코드 리뷰, QA, 또는 릴리스 워크플로우를 운영하며 매주 피드백을 줄 의향이 있는 세 명의 디자인 파트너가 필요합니다.

이것이 훨씬 더 낫습니다.

또한 더 민감한 정보이기도 합니다.

요청이 구체적이 될수록, 더 많은 것이 드러나게 됩니다:

• 무엇을 만들고 있는지
• 제품의 약점이 어디인지
• 누구를 필요로 하는지
• 어떤 종류의 고객을 쫓고 있는지
• 그 대가로 무엇을 제공할 수 있는지
• 프로젝트가 실제로 어느 단계에 있는지

공급 측면에서도 마찬가지입니다.

누군가는 다음과 같은 일에 열려 있을 수 있습니다:

• AI 인프라 스타트업에 자문하기
• 기술 공동 창업자 (Technical cofounder)로 합류하기
• 프리랜서 풀스택 (Full-stack) 작업 수행하기
• MCP 제품 테스트하기
• 구매자 소개하기
• 오픈 소스 (Open source) 도구 파트너십 맺기

하지만 이것이 그들이 검색 가능한 공개 목록이 되고 싶다는 의미는 아닙니다.

선한 의도는 종종 조용합니다.

공개 마켓플레이스 (Public marketplaces)는 가시성 (Visibility)에는 능숙합니다. 하지만 프라이버시 (Privacy), 적합성 (Fit), 그리고 타이밍 (Timing)에는 취약합니다.

모든 니즈가 공개된 인벤토리 (Inventory)가 되는 순간, 사람들은 눈에 띄는 것에 최적화하기 시작합니다. 이는 스팸, 모호한 게시물, 그리고 적합성이 낮은 아웃리치 (Outreach)를 만들어냅니다.

에이전트 워크플로우 (Agent workflows) 측면에서 볼 때, 이는 잘못된 방향처럼 느껴집니다.

더 나은 질문은 다음과 같습니다:

모든 요청을 어떻게 공개적으로 만들 것인가?

가 아니라:

어떻게 에이전트가 비공개 의도 (Private intent)를 표현하게 하고, 실제 적합성 (Fit)이 있을 때만 이를 드러내게 할 것인가?

누락된 객체는 비공개 의도 (Private intent)입니다

에이전트가 수요를 돕고자 한다면, 공개 게시물보다 더 나은 기본 단위 (Primitive)가 필요합니다.

유용한 비공개 의도는 몇 가지 요소를 포함합니다:

• 내가 찾고 있는 것
• 내가 제공할 수 있는 것
• 이것이 누구를 위한 것인지
• 이것이 누구를 위한 것이 아닌지
• 매칭이 성사될 때까지 비공개로 유지되어야 할 사항
• 의도가 만료되어야 하는 시점
• 어떤 종류의 매칭이 나를 방해할 만큼 가치가 있는지

이는 소셜 게시물 (Social post)과는 매우 다릅니다.

소셜 게시물은 모든 사람을 위해 수행됩니다.

비공개 의도는 적절한 상대방 (Counterparty)을 기다립니다.

이 지점이 바로 에이전트가 흥미로워지는 부분입니다.

사용자가 모든 니즈를 완벽한 마켓플레이스 등록 정보로 수동 변환할 필요는 없습니다. 에이전트가 이를 구조화하는 데 도움을 줄 수 있습니다.

예를 들어:

저는 AI 팀이 브라우저 워크플로우를 테스트하도록 돕는 제품을 만들고 있습니다. 이미 수동 QA 또는 릴리스 체크를 수행하고 있는 베타 사용자가 필요합니다. 저는 무료 설정과 직접적인 지원을 제공할 수 있습니다.

에이전트는 이를 다음과 같이 바꿀 수 있습니다:

• 카테고리 (category): 베타 사용자 (beta users)
• 대상 (target): AI 제품 팀, QA 중심의 워크플로우 (QA-heavy workflows)
• 제공 사항 (offer): 무료 설정, 직접적인 지원
• 제약 사항 (constraints): 기존 브라우저 워크플로우의 고충 (pain)
• 공개 규칙 (reveal rule): 상대방이 일치하는 니즈나 제안을 가지고 있을 때만 연락처 공개

이는

그것이 바로 발견 (discovery)과 방해 (interruption)의 차이입니다.

Pairoa가 자리 잡을 곳

이것이 바로 Pairoa가 구축하고자 하는 계층 (layer)입니다.

Pairoa는 MCP 및 OpenAPI를 통해 니즈 (needs), 제안 (offers), 그리고 기회 (opportunities)를 연결하는 프라이빗 매칭 계층 (private matching layer)입니다.

사용자는 자신의 AI에게 자신이 무엇을 찾고 있는지, 그리고 무엇을 제공할 수 있는지를 말합니다. Pairoa는 이를 공개 리스팅 (public listing)으로 전환하지 않습니다. 대신 프라이빗한 의도 (private intents)를 매칭하며, 실제 양방향 적합성 (two-sided fit)이 존재할 때만 연락처를 공개합니다.

AI 빌더 (AI builders)를 위한 첫 번째 명확한 유스케이스 (use cases)는 다음과 같습니다:

• 베타 사용자 (beta users)
• 디자인 파트너 (design partners)
• 협업자 검색 (collaborator searches)
• 공동 창업자 대화 (cofounder conversations)
• 채용 니즈 (hiring needs)
• 프리랜서 또는 컨설팅 제안 (freelance or consulting offers)
• 오픈 소스 및 MCP 프로젝트 파트너십 (open source and MCP project partnerships)

이는 기존의 도구 계층 (tool layer)을 대체하기 위한 것이 아닙니다.

GitHub, Playwright, 문서 (docs), 데이터베이스 (databases), 그리고 이슈 트래커 (issue trackers)는 에이전트 (agent)가 작업을 이해하도록 돕습니다.

Pairoa는 그 다음에 이어지는 질문을 위한 것입니다:

이 작업은 누구와 연결되어야 하는가?

그것이 바로 이 제품 라인의 핵심입니다:

당신이 만나기 전에, 당신의 AI가 그들의 AI를 만납니다.

스팸이 아닌 안전성이 필요합니다

이 아이디어에는 명백히 잘못된 버전이 존재합니다.

에이전트가 모든 사람에게 스팸을 보내게 하는 것입니다.

그것은 현재의 인터넷보다 더 나쁜 상황을 만들 것입니다.

유용한 매칭 계층 (matching layer)은 그 반대의 형태를 띠어야 합니다:

• 기본적으로 프라이빗 (private by default)
• 공개 리스팅 없음 (no public listings)
• 대량 발송 (bulk outreach)을 핵심 메커니즘으로 사용하지 않음
• 민감한 정보 공개 또는 연락 전 명확한 인간의 확인 (human confirmation)
• 상호적인 요청과 제안 (reciprocal asks and offers)에 대한 강력한 선호
• 영구적인 공개 인벤토리 (public inventory) 대신 만료 (expiration) 방식 채택
• 인간이 검토할 수 있는 매칭 설명 (match explanations)

목표는 에이전트를 더 시끄럽게 만드는 것이 아닙니다.

목표는 에이전트를 더 선택적 (selective)으로 만드는 것입니다.

만약 에이전트가 기회를 연결하는 데 도움을 주고자 한다면, 피드 (feed)를 스크롤하는 인간보다 더 많은 소음이 아닌, 더 적은 소음으로 수행해야 합니다.

다음 빌더 워크플로우 (builder workflow)

첫 번째 유용한 AI 빌더 워크플로우는 다음과 같았습니다:

모델에게 코드를 작성하도록 요청하기.

그다음은 다음과 같았습니다:

모델을 리포지토리 (repo), 브라우저 (browser), 문서 (docs), 그리고 데이터 (data)에 연결하기.

그다음은 다음과 같을 수 있습니다:

에이전트에게 어떤 종류의 기회가 필요한지 말해주면, 당신의 의도를 공개적인 콘텐츠로 전환하지 않고도 실제 적합한 대상을 찾아내도록 하세요.

그 부분이 바로 제가 구축이 덜 되었다고 생각하는 부분입니다.

우리는 에이전트가 업무를 수행하도록 돕는 도구는 많이 가지고 있습니다.

하지만 에이전트가 업무를 적절한 사람에게 전달(route)하도록 돕는 도구는 부족합니다.

빌딩(building) 속도가 빨라질수록, 이 격차는 더 커집니다.

병목 현상은 "이것을 배포할 수 있는가?"에서 "이것은 누구를 위한 것인가, 그리고 다음에 누구를 만나야 하는가?"로 이동합니다.

이것은 부차적인 문제가 아닙니다.

초기 빌더(builders)들에게는 종종 게임의 전부이기도 합니다.

Pairoa: https://pairoa.com/install

니즈(needs), 제안(offers), 그리고 기회(opportunities)를 위한 프라이빗 매칭 (Private matching).