저는 전맹 시각장애인 사업가입니다. 방금 첫 '바이브 코딩' 제품을 1,700달러에 팔았습니다.

나는 앞이 전혀 보이지 않는 시각장애인이고, WCAG를 활용한 디지털 접근성, 3D 프린팅을 이용한 물리적 접근성, 그리고 AI 개발 관련 사업을 직접 운영하고 있어.

최근에 다른 시각장애인 사업가를 위해 Claude로 접근성 솔루션을 하나 만들었거든.

그걸 방금 1,700달러에 팔았어.

근데 나한테 진짜 흥미로운 건 1,700달러라는 돈 자체가 아니야. Claude 덕분에 내가 뭘 만들 수 있었는지, 그리고 단순히 "접근성 좋은 앱 하나 만들어줘"라고 말하는 것과는 실제 작업 과정이 얼마나 달랐는지가 핵심이지.

난 두 살 때부터 앞이 안 보였어. 그래서 평생을 나 같은 사람을 위해 설계되지 않은 기술을 어떻게든 써먹으려고 꼼수를 부리며 살았지. 학교 다닐 때 독학으로 HTML, CSS, JavaScript를 배웠고, 수년간 스크린 리더와 보조 공학 기기를 다루는 데 도가 텄어.

지금은 접근성 관련 일이 내 본업이기도 해.

Claude랑 작업할 때 이 분야 지식이 엄청나게 중요하다는 걸 깨달았지.

얼마 전에 다른 시각장애인 사업가가 연락을 해왔어. 상담 치료 쪽 일을 하는데, 맥북의 VoiceOver로 쓰기엔 너무 불편한 저널 시스템을 쓰고 있더라고.

그 시스템에 공식 API가 있길래 딱 아이디어가 떠올랐지.

기존 인터페이스를 굳이 접근성 좋게 뜯어고칠 필요가 있을까? 그냥 아예 우회해버리면 되잖아.

Claude를 써서 API를 통해 저널 시스템과 직접 통신하는 별도의 인터페이스를 만들었어.

이제 사용자가 이렇게 입력하면 돼.

"다음 주에 예약된 일정이 뭐야?"

그럼 필요한 정보를 바로 얻을 수 있지.

결국 목표는 사용자가 접근성 꽝인 인터페이스를 일일이 헤매지 않고, 그냥 평소 쓰는 언어로 필요한 기능을 바로 쓰게 만드는 거야.

근데 여기서 '바이브 코딩(vibe coding)'이라는 용어가 사람들한테 좀 잘못된 인상을 줄 수 있다고 생각해.

난 그냥 Claude한테 "이거 접근성 좋게 만들어줘"라고 퉁치지 않았거든.

Claude가 코드를 짜고, API를 분석하고, 버그 잡고, 리팩토링하고 기능을 구현하는 속도는 진짜 미쳤어. 하지만 Claude는 스크린 리더를 쓰는 사람이 뭘 느꼈을 때 '아, 이거 진짜 편하다'라고 생각하는지는 자동으로 알지 못해.

그 부분은 내 전문 지식이 필요하거든.

예를 들어, VoiceOver가 실제로 인터페이스를 어떻게 훑는지 내가 이해하고 있어야 해. 뭐가 클릭 가능한 텍스트가 아니라 버튼이어야 하는지, 컨트롤 라벨은 어떻게 달아야 하는지, 동작 후에 포커스는 어디로 가야 하는지, 에러나 상태 메시지는 어떻게 읽어줘야 하는지, 헤딩으로 인터페이스 구조는 어떻게 잡아야 하는지, 키보드 조작은 어떻게 해야 하는지, 그리고 UI를 더 넣는 게 오히려 독이 되는 상황은 언제인지까지 다 알아야 한다고.

접근성이라는 게 자동 검사 도구에서 에러 안 뜰 때까지 ARIA 라벨 덕지덕지 붙이는 게 아니거든.

내 작업 방식은 훨씬 이런 식이야.

사용자가 실제로 뭘 해야 하는지 정의한다.

Claude가 설계와 구현을 돕는다.

고객이 쓰는 것과 똑같은 보조 공학 기기로 테스트한다.

기술적으로는 돌아가는데 스크린 리더로 쓰기엔 어색하거나, 비효율적이거나, 헷갈리는 부분을 찾아낸다.

Claude한테 접근성 관점에서 문제를 설명하고 내가 원하는 상호작용을 묘사한다.

Claude가 구현을 수정한다.

다시 테스트한다.

이걸 계속 반복하는 거지.

가끔은 최고의 접근성 해결책이 기존 인터페이스를 아예 안 따라 하는 것일 때도 있어.

비장애인 개발자가 그 저널 시스템을 보면 "이 메뉴랑 탭들을 어떻게 접근성 좋게 만들지?"라고 고민하겠지.

근데 내 관점은 이거였어. "애초에 시각장애인 사용자가 왜 이 메뉴랑 탭들을 일일이 다 거쳐야 하지?"