혼자 개발한다는 건 개발자이면서 동시에 PM, 운영자, 그리고 때로는 비서까지 겸해야 한다는 뜻이다. 매일 아침 Notion을 열고, 흩어진 데이터베이스를 훑으며 '오늘 뭐가 급하지?'를 파악하는 데 15분. 그 15분은 단순한 시간 낭비가 아니라, 혼자 일하는 사람이 매일 치러야 하는 인지적 세금이다. 팀이 있다면 누군가 정리해주겠지만, 1인 개발자에겐 그 누군가가 없다.
최근 MCP(Model Context Protocol) 생태계에서 이 문제를 정면으로 겨냥하는 사례들이 연달아 등장하고 있다. 단순한 도구 소개가 아니다. AI가 UI를 그리고, 데이터를 쓰고, 작업을 예약하는 방식으로 개발자의 워크플로우 자체를 재설계하고 있다는 신호다.
에디터 안에서 UI가 살아 움직인다
Dev.to에 공개된 'Chief of Staff' 프로젝트는 그 변화를 가장 직관적으로 보여준다. 에티오피아 아디스아바바에서 혼자 오픈소스 SDK를 운영하며 스타트업을 병행하는 24세 개발자가 만든 이 MCP 앱은, VS Code 또는 Claude 채팅창에 "Give me my morning briefing"이라고 입력하면 라이브 React 대시보드가 채팅 인터페이스 안에 렌더링된다. 링크가 아니다. 스크린샷도 아니다. 실제 데이터가 바인딩된 인터랙티브 UI다.
여기서 주목할 지점은 단순히 '예쁜 요약'이 아니라는 것이다. 대시보드 안의 체크박스를 클릭하면 Notion에서 해당 태스크가 완료 처리된다. '지연된 태스크 재스케줄' 버튼을 누르면 AI가 우선순위를 판단해 날짜를 재배치하고, 그 이유를 reason 필드에 기록한다. 에디터를 떠나지 않은 채로 실행까지 완료된다. 이것이 기존 'AI + Notion' 조합과의 결정적 차이다. 기존엔 AI가 요약을 읽어줬다면, 이제는 AI가 대신 처리한다.
기술적으로도 흥미로운 선택이 있다. Generative UI 레이어는 React 컴포넌트를 단일 HTML 문자열로 컴파일해 MCP 툴 응답으로 반환하는 방식을 쓴다. FocusCard, TaskRow, GoalProgress, AgentAction 같은 컴포넌트 카탈로그를 AI가 실제 Notion 데이터로 채워 구성하는 구조다. 더불어 데이터베이스 ID를 하드코딩하지 않고 속성 형태(progress 필드 유무, status·due date 필드 유무)를 읽어 워크스페이스 구조를 동적으로 파악한다. 어떤 Notion 구조에도 적응한다는 뜻이다.
출근길 명령, 퇴근 전 결과물
Claude의 새 기능 Dispatch는 또 다른 방향에서 같은 문제를 건드린다. 브런치 아티클에서 소개된 이 기능은 Claude Desktop과 연결된 전용 채팅 채널을 스마트폰에서도 그대로 쓸 수 있게 해준다. 출근길 지하철에서 "어제 이메일 중 중요한 거 5개 요약하고 오늘 캘린더 일정이랑 묶어서 Documents 폴더에 저장해줘"라고 말해두면, 사무실에 도착했을 때 브리핑 문서가 준비돼 있다.
여기에 /schedule 명령어 기반의 Scheduled Tasks 기능도 추가됐다. 매일 오전 8시에 브리핑을 생성하거나, 주간 회의록을 자동으로 정리하는 작업을 cron job처럼 예약할 수 있다. 컴퓨터가 켜져 있어야 한다는 제약이 있고, 작업 완료 알림이 오지 않는다는 점은 현재 한계지만, '비동기 위임'이라는 인터랙션 패턴 자체가 새롭다. 급한 작업보다는 '미리 시켜두고 결과를 확인하는' 흐름에 맞는 도구다.
버그 트래커도, 수동 분류도 사라진다
MCP가 개발 워크플로우를 바꾸는 또 다른 사례는 더 소박하지만 실용적이다. Dev.to에서 공개된 'AI Bug Tracker with Notion MCP'는 에러 메시지를 API 엔드포인트로 전송하면, AI가 자동으로 Frontend/Backend/Database/API로 분류하고 수정 제안과 함께 Notion 데이터베이스에 구조화해 저장한다. 수동 버그 로깅과 분류 작업이 사라지는 구조다. 규모는 작지만, Notion을 경량 백엔드 데이터베이스로 전환하는 패턴을 명확히 보여준다.
'AI가 도와주는 개발'에서 'AI가 운영하는 워크플로우'로
세 사례를 관통하는 핵심은 하나다. MCP는 AI가 도구를 읽는 것에서 쓰는 것으로 전환시킨다. 데이터를 요약해서 보여주는 것이 아니라, 실제로 Notion에 태스크를 생성하고, 파일을 저장하고, 오류를 분류해 기록한다. 에이전트가 결과를 보고하는 것이 아니라 작업을 완료한 채로 기다린다.
1인 개발자 관점에서 이 변화의 의미는 단순히 '생산성 향상'이 아니다. 기존에는 도구 간 컨텍스트 전환과 수동 정리가 불가피했다. MCP 기반 에이전트는 그 스위칭 비용 자체를 설계 단계에서 제거할 수 있게 해준다. Chief of Staff가 '팀 없이도 비서를 갖는 것'이라고 표현한 이유가 여기에 있다.
물론 아직 현실적인 마찰도 있다. Dispatch의 알림 부재, MCP 앱의 UI 렌더링 환경 의존성, 버그 트래커의 LLM 미통합 같은 한계들이다. 하지만 이 한계들은 프로토콜 성숙도의 문제이지, 방향성의 문제가 아니다.
앞으로 주목해야 할 질문은 '어떤 MCP 도구를 쓸 것인가'가 아니다. '내 워크플로우의 어느 지점을 에이전트가 대신 닫아야 하는가'를 설계하는 일이 1인 개발자의 다음 핵심 역량이 될 것이다. 대화창이 대시보드가 되고, 출근길 명령이 퇴근 전 결과물이 되는 시대—MCP는 그 설계의 문법이 되고 있다.