비개발자 관점으로 써봤더니 설치부터 막혔다 — E2E 테스트가 가르쳐준 것들

아키텍처를 바꿨으니 직접 써볼 차례였다

이전 포스팅에서 비개발자 E2E를 기획하다가 아키텍처를 바꾸게 됐습니다. 6단계 설치를 2단계로 줄이는 uvx 전환이었습니다.

전환을 끝내고 생각했습니다. “이제 진짜 비개발자에게 건네도 될까?”

확신이 없었습니다. 그래서 건네기 전에 직접 테스트하기로 했습니다. 개발자인 제가 비개발자를 상정하고, 플러그인 레포와 분리된 빈 디렉토리에서 처음부터 시작했습니다.

버그 몇 개 정도 나올 줄 알았습니다. 생각보다 많은 디테일에서 오류가 터졌습니다.

설치의 벽 — 의존성은 해결했는데 설정이 남았다

4편에서는 비개발자 설치 경로 자체가 없다는 걸 발견했습니다. 이번은 그 다음 문제입니다. uvx로 의존성 장벽을 없앤 뒤, 새로 드러난 설정 UX의 문제입니다.

테스트의 첫 단계는 PyPI 배포였습니다. uvx로 실행하려면 패키지가 먼저 올라가야 하니까요. v0.1.0 태그를 push하고, uvx slack-to-notion-mcp를 실행했습니다. 서버가 정상 기동됐습니다. 첫 번째 관문은 통과.

uvx 전환으로 git clone, Python 설정, 매 세션 --plugin-dir은 사라졌습니다. 의존성 문제는 해결된 겁니다.

하지만 설치는 의존성만이 아니었습니다.

토큰 설정 UX가 오히려 퇴보한 상태였습니다.

claude mcp add의 현실

uvx 기반 등록 명령은 이렇게 생겼습니다.

claude mcp add slack-to-notion \
  --transport stdio \
  -e SLACK_USER_TOKEN=xoxp-... \
  -e NOTION_API_KEY=secret_... \
  -e NOTION_PARENT_PAGE_ID=https://notion.so/... \
  -- uvx slack-to-notion-mcp

비개발자 관점에서 보면 문제가 여러 개였습니다.

• --transport stdio — stdio가 뭔가
• -e — 환경변수 플래그를 모름
• -- — 인자 구분자를 모름
• \ 줄바꿈 — 복사하면 깨지기 쉬움
• 토큰 3개를 명령어에 한 번에 삽입해야 함

이전의 .env 파일 방식은 메모장으로 열어서 값만 바꾸면 됐습니다. uvx로 의존성 자동화를 얻은 대신, 토큰 설정 경험을 잃은 셈이었습니다.

대화형 setup.sh로 해결

명령어 한 줄을 외우게 하는 대신, 대화형 스크립트가 하나씩 물어보도록 만들었습니다.

Slack 토큰을 입력하세요 (xoxb- 또는 xoxp-로 시작): ___ Notion API Key를 입력하세요: ___ Notion 페이지 링크를 입력하세요: ___

입력할 때마다 형식을 검증하고, 잘못되면 이유를 알려주고 다시 물어봅니다. 복잡한 명령어를 모르더라도 설치가 끝납니다.

설치 블로커 — Notion이 키 형식을 바꿨다

대화형 스크립트를 만들고 직접 테스트하는데, Notion API Key 입력에서 멈췄습니다.

✗ 올바른 형식이 아닙니다. secret_ 로 시작해야 합니다.

정상 발급된 키인데 거부당했습니다. Notion이 Internal Integration Secret 형식을 secret_에서 ntn_으로 바꾼 것이었습니다.

코드에서 secret_만 허용하고 있었으니 무한 재입력 루프에 빠져 설치 자체가 불가능했습니다.

외부 API의 변경이 우리 도구의 설치를 막은 사례였습니다. secret_과 ntn_ 둘 다 허용하도록 수정했습니다.

단위 테스트가 있었다면 이런 류의 검증 로직은 일찍 잡을 수 있었을 겁니다. 하지만 검증 함수에 대한 단위 테스트가 없었습니다. E2E에서 처음 발견된 버그였습니다.

자연어로 써보다

설치를 넘기고 나서야 본격적인 사용 테스트를 시작했습니다. 테스트 워크스페이스에 소셜, 개발, 마케팅, 프로덕트 채널을 만들어두고 비개발자가 실제로 입력할 법한 문장으로 시나리오를 돌렸습니다.

“어떤 Slack 채널이 있는지 보여줘”로 시작해서, “마케팅 채널에서 최근 대화 보여줘”로 메시지를 확인하고, “마케팅 채널의 말차 사탕 스레드를 분석해서 Notion에 정리해줘”로 핵심 기능인 스레드 분석과 Notion 생성까지 이어갔습니다. 마지막으로 “앞으로 마케팅 분석은 타겟 고객과 액션 아이템 위주로 정리해줘”로 선호도 저장까지 테스트했습니다.

전 시나리오 통과. 채널 ID나 thread_ts 같은 기술적 값을 모르더라도 자연어만으로 전체 흐름이 동작했습니다.

설치에서 그렇게 막혔던 것이 무색할 정도로 사용 자체는 깔끔했습니다.

테스트에서 발견한 것들

E2E 전체를 통해 발견한 이슈를 정리합니다.

해결된 이슈

이슈	문제	해결
비개발자 설치 불가	bash + git clone 구조	uvx 전환
PyPI 미배포	uvx 실행 불가	v0.1.0 배포
토큰 설정 UX	claude mcp add 명령어 장벽	대화형 setup.sh
ntn_ 프리픽스 거부	Notion API 키 형식 변경 미반영	둘 다 허용
설정 경로 안내 부정확	실제 저장 위치와 불일치	경로 수정 + 재실행 안내

후속 이슈 (미해결)

이슈	내용
Notion 테이블 미변환	파이프 문자가 마크다운으로 변환되지 않음
메시지 포맷 개선	작성자·시간 표시, 분석 방향 예시 제안

해결된 이슈 5건은 전부 설치 과정에서 나왔고, 미해결 2건만이 사용 단계의 문제였습니다. 사용보다 설치에서 훨씬 많은 것이 깨졌습니다.

돌아보며

솔직히 놀랐습니다. “비개발자도 쓸 수 있게 만들었다”고 생각했는데, 실제로 비개발자 입장에서 따라가보니 첫 화면에서 막혔습니다.

머릿속으로 “비개발자는 이렇게 쓰겠지”라고 짐작하는 것과, 실제로 빈 디렉토리에서 처음부터 따라가보는 것은 달랐습니다. 시뮬레이션해봐야 보이는 것들이 있었습니다.

단위 테스트도 부족했습니다. Notion API Key 형식 검증처럼 단순한 로직도 테스트가 없으니 외부 변경에 무방비였습니다. “동작하니까 넘어가자”가 아니라 “동작하는지 확인하는 코드”가 있어야 했습니다.

결국 개발자 테스트에서 잡은 것, E2E에서 잡은 것, 비개발자 관점에서 잡은 것이 모두 달랐습니다. 한 겹의 테스트로는 충분하지 않았습니다.

1편에서 프로세스를 만들고, 2편에서 사고방식을 바꾸고, 3편에서 도구를 만들고, 4편에서 테스트가 설계를 바꾸고, 5편에서 사용자 관점까지 도달했습니다.

“건네도 될까”라는 질문에 아직 완전히 답하지 못했습니다. 후속 이슈들을 정리하고, 실제 비개발자에게 건네보는 것은 다음 실전의 몫으로 남겨둡니다.

---

이 글은 Claude의 도움을 받아 작성했습니다.