Aside Browser와 Aside MCP: 로그인된 업무 브라우저를 코딩 에이전트에 연결하기

코딩 에이전트가 코드와 저장소만 볼 때, 막히는 지점은 종종 코드 밖에 있습니다. 실패한 CI 로그, 로그인 뒤의 feature flag 대시보드, 스테이징 화면, 내부 문서처럼 브라우저에만 있는 증거가 그렇습니다.

먼저 결론부터 말하면, Aside는 AI가 탭 하나를 대신 조작하는 도구라기보다 로그인된 웹사이트에서 작업을 수행하는 브라우저를 CLI·REPL·MCP로 코딩 에이전트에 연결하려는 제품입니다. 코드 변경은 기존 coding agent가 맡고, 코드 밖의 증거 수집과 브라우저 검증을 Aside에 나누면 작업 경계가 훨씬 선명해집니다.

이 글에서 다루는 내용:

• Aside Browser가 기존 브라우저 MCP와 구분되는 지점
• aside mcp로 코딩 도구에 브라우저 작업을 연결하는 최소 설정
• Aside Skills로 팀의 브라우저 검증 절차를 재사용하는 방법
• CI·스테이징·대시보드 작업에서 안전하게 요청을 나누는 방법

위 이미지는 Aside의 공식 개발자 안내 ↗가 설명하는, 에디터 밖의 브라우저 증거를 개발 workflow로 되돌리는 흐름을 보여줍니다.

Aside의 공식 소개 영상 ↗은 실제 웹사이트·계정·browser history를 넘나드는 복잡한 작업이라는 제품의 출발점을 짧게 보여줍니다. 영상은 MCP 설정을 대신하지 않으므로, 이 글의 CLI·MCP 구성과 함께 보는 것이 좋습니다.

브라우저를 “증거 수집 레이어”로 쓰기

Aside 공식 홈페이지 ↗는 제품을 “사람과 에이전트를 위해 재구성한 브라우저”로 소개합니다. 핵심은 개별 SaaS 연동을 늘리는 대신, 사용자가 이미 로그인한 웹사이트와 계정을 브라우저에서 직접 다룬다는 점입니다.

개발자 관점에서는 이것이 코드 에이전트의 대체재라기보다, 저장소 밖 상태를 확인하는 보완재에 가깝습니다. 공식 개발자 안내 ↗는 실패한 CI, private dashboard, feature flag, Datadog trace, staging screenshot처럼 브라우저에 있는 증거를 가져오는 일을 주요 사용 사례로 제시합니다.

%% TD: 모바일에서도 각 단계의 책임 경계가 세로로 읽히도록 배치한다.
flowchart TD
    A[코딩 에이전트<br/>코드·테스트·diff] --> B[Aside MCP]
    B --> C[Aside Browser<br/>로그인된 웹·내부 도구]
    C --> D[로그·스크린샷·링크·검토 메모]
    D --> E[개발자 검토·승인]
    E --> A

여기서 중요한 출력은 “작업 완료”라는 말이 아니라 검증 가능한 증거입니다. 예를 들면 첫 실패 단계와 로그 URL, 이전 green run과의 차이, 스테이징 캡처, 변경하지 않은 설정의 현재 값이 됩니다. 이 방향은 기존 Chrome DevTools MCP가 브라우저 런타임을 디버깅 데이터로 여는 방식과 닿아 있지만, Aside는 업무용 웹 도구와 그 안의 증거 수집까지 범위를 넓힙니다.

CLI·MCP·REPL은 같은 브라우저를 다른 방식으로 연다

Aside의 개발자 문서 ↗는 세 인터페이스를 제공합니다. 선택 기준은 “브라우저를 쓸 것인가”가 아니라, 누가 작업을 지시하고 얼마나 결정론적으로 검사해야 하는가입니다.

Aside MCP 최소 연결

공식 문서는 Developer settings에서 CLI를 설치할 수 있다고 안내하며, 터미널 설치 명령도 제공합니다. 설치가 끝난 뒤 aside mcp는 Aside를 다른 agent 또는 coding tool에 MCP server로 연결합니다.

# from: https://docs.aside.com/help/developers
curl -fsSL https://releases.aside.com/install.sh | bash

mcp.json을 지원하는 클라이언트라면 공식 문서의 구성은 다음과 같습니다. Developer settings가 구체적인 CLI 경로를 찾았다면 command에 그 경로를 쓰라는 점도 함께 확인해야 합니다.

// mcp.json
// from: https://docs.aside.com/help/developers
{
  "mcpServers": {
    "aside": {
      "command": "aside",
      "args": ["mcp"]
    }
  }
}

연결 뒤에는 넓은 “브라우저를 확인해줘”보다 산출물을 한정한 요청이 효과적입니다. 예를 들어 공식 개발자 사용 사례 ↗처럼, 실패한 GitHub Actions run을 열어 첫 실패 단계와 마지막 성공 run의 차이를 찾고 관련 로그 링크를 넣은 PR comment 초안만 만들게 할 수 있습니다. 게시나 설정 변경은 요청에서 명시적으로 제외합니다.

이 PR의 실패한 CI run을 열어 첫 실패 단계를 찾고,
마지막 성공 run과 비교해 관련 로그 링크를 포함한 진단 초안을 작성해줘.
댓글 게시, 재실행, 설정 변경은 하지 마.

이 분리는 OpenAI Codex Record & Replay에서 다룬 시연 기반 자동화와도 잘 맞습니다. 반복되는 browser check는 절차로 다듬고, 저장소 수정과 테스트 해석은 coding agent가 책임지게 하면 각 도구가 가진 문맥을 과도하게 섞지 않게 됩니다.

Aside Skills로 팀의 브라우저 절차를 고정하기

Aside의 공식 개발자 안내에서 말하는 Skills는 매 프롬프트에 반복해서 쓰기에는 긴 브라우저 절차를 팀 규칙으로 적어두는 장치입니다. release checklist, rollout 중 확인해야 할 dashboard, internal admin page 검사 방법, 유효한 QA screenshot의 기준처럼 사람마다 달랐던 판단을 작업 시작점에 넣는 용도입니다.

중요한 점은 Skill이 브라우저에 무제한 권한을 주는 기능이 아니라는 것입니다. 공식 예시 ↗는 staging QA skill을 사용해 preview URL에서 signup flow를 확인하고 desktop·mobile screenshot, selector·layout·console issue를 보고하되, ticket을 만들기 전에는 멈추도록 요청합니다. 즉 Skill에는 검사 절차와 산출물 기준을 넣고, 외부 상태를 바꾸는 행동은 별도 승인으로 남기는 편이 좋습니다.

팀에서 /aside-browser처럼 호출할 작업 규칙을 만들 때는 다음 네 가지를 먼저 정하면 충분합니다.

1. 대상과 범위: 어떤 preview URL, dashboard, 내부 도구를 여는지 적습니다.
2. 검증 항목: 확인할 사용자 흐름, viewport, 로그 또는 지표를 제한합니다.
3. 반환 형식: screenshot, 링크, QA note, 변경 제안처럼 리뷰 가능한 결과물을 정합니다.
4. 중단 경계: 게시, ticket 생성, 설정 저장, 권한 변경 같은 행동 전에는 멈추게 합니다.

예를 들어 staging QA skill의 요청은 다음처럼 쓸 수 있습니다. 이는 공식 예시의 안전 경계를 한국어 workflow에 맞춰 압축한 것입니다.

이 PR의 staging QA skill을 사용해 preview URL에서 signup flow를 확인해줘.
desktop과 mobile screenshot을 남기고 selector·layout·console issue를 QA note로 정리해줘.
ticket 생성, 댓글 게시, 설정 변경은 하지 마.

이 방식은 MCP가 브라우저 접근을 제공하고, Skill이 어떤 순서와 기준으로 접근할지를 제공하는 분업입니다. 반복 QA를 자동화하더라도 결과를 개발자가 검토하는 구조는 유지할 수 있습니다.

개발 workflow에서 유용한 세 가지 패턴

1. 실패한 CI의 “첫 증거”만 가져오기

CI가 실패했을 때 브라우저 작업의 목표를 원인 확정이 아니라 증거 패킷으로 제한합니다. Aside의 개발자 안내는 failing job, first failing step, log URL, 마지막 정상 실행과의 차이를 출력 항목으로 제시합니다. 이 자료를 받은 뒤 코드 에이전트가 diff와 테스트를 읽으면, 추측으로 시작할 가능성을 줄일 수 있습니다.

2. 스테이징 QA를 코드 리뷰의 부속물로 만들기

공식 사례에는 desktop·mobile 폭에서 onboarding flow를 통과하고 스크린샷과 짧은 QA note를 남기는 흐름이 있습니다. 코드 리뷰 전에 “어디가 깨졌다”는 보고 대신, 재현 경로와 화면 증거를 함께 남기는 방식입니다. 모바일 앱 검증을 별도 실행 레이어로 다룬 Agent Device와 마찬가지로, 실행 결과를 코드와 분리해 검토할 수 있습니다.

3. 대시보드는 읽고, 변경은 사람에게 남기기

feature flag, Cloudflare DNS, Supabase metrics처럼 운영 상태가 있는 화면에서는 요청을 두 단계로 나눕니다. 먼저 현재 값·관련 문서·스크린샷·변경 제안을 수집하고, 실제 저장·롤아웃·게시 작업은 사람의 검토 뒤에 수행합니다. Aside 홈페이지도 결제·게시·메시지 같은 민감 행동은 확인을 기다린다고 설명하지만, 중요한 설정에서는 프롬프트에도 같은 제한을 명시하는 편이 안전합니다.

로그인된 브라우저를 연결할 때의 경계

Aside는 공식 홈페이지 ↗에서 credentials가 agent에게 노출되지 않은 채 autofill되고, credential use가 기록된다고 설명합니다. 다만 이 설명이 곧 모든 workflow의 안전을 보장하지는 않습니다. 특히 다음 원칙은 도구와 무관하게 남습니다.

• 읽기 작업과 변경 작업을 같은 요청에 섞지 않습니다.
• 게시·결제·권한 변경·운영 설정은 “초안 또는 변경안만 준비”로 먼저 요청합니다.
• 반환값을 링크, 스크린샷, 짧은 note처럼 필요한 범위로 제한합니다.
• 개인 정보나 비밀값이 결과에 포함될 수 있는 작업은 결과 공유 대상을 먼저 정합니다.

마무리

Aside Browser와 Aside MCP의 흥미로운 점은 AI에게 브라우저 제어 하나를 더 주는 데 있지 않습니다. 코드 저장소 바깥에 있는 실제 운영 증거를, 로그인된 업무 환경에서 가져와 coding workflow의 입력으로 만든다는 데 있습니다.

처음 도입한다면 CI triage나 staging screenshot처럼 읽기 전용이고 결과가 명확한 작업부터 시작하는 편을 권합니다. 그다음 반복되는 확인을 절차화하되, 게시와 설정 변경은 끝까지 사람의 승인 경계 안에 남겨두면 됩니다.

관련 글:

• Chrome DevTools MCP — 브라우저 런타임·네트워크·콘솔을 디버깅 데이터로 연결하는 MCP
• OpenAI Codex Record & Replay — 반복 업무를 재사용 가능한 workflow로 정리하는 관점
• Agent Device — 모바일 실행 결과를 에이전트 workflow에 붙이는 방법

참고 자료

• Aside 공식 홈페이지 ↗ — 브라우저·메모리·credential 처리와 민감 작업 승인 설명
• Use the CLI, MCP, and REPL ↗ — CLI, MCP 구성, REPL 공식 문서
• Aside for Developers ↗ — CI·스테이징·대시보드 중심의 개발자 사용 사례
• Introducing Aside ↗ — 공식 대표 영상