Figma보다 Claude로 더 많이 디자인하는 시대 — 1인 디자이너가 본 임계점의 조건

디자인 워크플로의 지각변동

전통적인 1인 디자인 팀의 작업 흐름은 대체로 비슷했다. 문제를 명세 문서로 정리하고, Figma에서 정적 또는 인터랙티브 목업을 만들고, 개발팀과 함께 구현 가능성을 검토한다. 그러나 Jane Street의 한 디자이너는 최근 이 흐름 자체를 뒤집고 있다. 명세 단계에서 Claude를 호출하고, 빌드와 서버를 띄운 채 에디터 안에서 직접 프로토타입을 만든다. Figma로 옮겨가는 횟수는 지난 2개월 사이 눈에 띄게 줄었다.

이 변화는 단순한 도구 교체가 아니다. ‘디자인’이라는 작업 단위 자체가 재정의되고 있다는 신호다. 명세와 목업이 결과물이던 시대에서, ‘동작하는 코드베이스 프로토타입’이 결과물이 되는 시대로의 이동이다.

‘오래된 LLM 회의감’에서 ‘필수 지원 도구’로

그 디자이너는 한때 Copilot, Cursor, Gemini로 게임을 수정하거나 제품 브리프·와이어프레임을 만들며 “AI는 이미 잘 아는 일에 보조를 붙이는 정도”라는 인식을 가지고 있었다. 그러나 Jane Street의 사내 기술 스택인 OCaml과 Bonsai 프레임워크는 외부 학습 데이터가 충분하지 않아, 기존 도구들이 거의 도움이 되지 않았다.

반면 Claude는 이 낯선 스택 위에서 결정적 역할을 했다. 함수 시그니처를 설명하면 모듈 구조를 제안하고, Bonsai 컴포넌트의 라이프사이클을 짚어주며, 사내 라이브러리의 변경 영향까지 추적한다. 디자이너 입장에서는 ‘모르는 것을 가르쳐 주는 도구’에서 ‘모르는 것 위에서 함께 만드는 도구’로 인식이 바뀐 셈이다.

워크플로의 6단계 — 프롬프트 한 줄이 PR이 되기까지

그의 현재 작업 흐름은 다음 여섯 단계로 요약된다. (1) 문제를 자연어로 설명한다. (2) 에디터에서 빌드·서버·Claude를 동시에 실행한다. (3) 프롬프트를 통해 코드를 생성하고 화면에 즉시 반영한다. (4) 동작하는 프로토타입을 직접 사용해 보며 반복 수정한다. (5) 만족스러운 결과는 개발 환경에 배포해 사용자 피드백을 모은다. (6) 마무리가 되면 일반 feature(PR)로 본 저장소에 제출한다.

이 과정에서 목업 단계는 의도적으로 생략된다. 정적인 화면보다 실제 응답 지연, 빈 상태, 에러 메시지가 사용자 경험에 더 큰 영향을 준다는 판단이다. 버튼 문구, 단축키, 확인 다이얼로그 같은 UI 디테일만 50회 이상 수정하는 일도 흔하며, 매번 재컴파일 없이 에디터에서 즉시 끝낸다.

사례 — JSQL+LLM 프로토타입, 2000줄 diff

대표적인 사례는 JSQL 입력에 LLM 프롬프팅을 결합한 프로토타입이다. 사용자가 자연어로 데이터 조회 의도를 입력하면, 시스템이 JSQL을 생성·실행하고 결과를 LLM이 정리해 돌려주는 흐름이다. 이 프로토타입은 며칠간 실제로 운영 환경에서 사용되며 안정성을 검증받았다.

이외에도 사용자 대상 프로토타입, 데이터 모델 프로토타입, 사내 라이브러리 변경 시뮬레이션 등 약 6개의 프로토타입이 AI로 작성됐고, 일부 PR은 2000줄이 넘는 diff를 발생시켰다. 특히 최근 들어서는 신규 앱을 Figma 단계 없이 처음부터 Claude로 설계·구현하는 경우도 나타나고 있다.

임계점의 세 조건

흥미로운 점은 이 전환이 단번에 일어난 것이 아니라는 사실이다. 디자이너는 세 가지 조건이 동시에 충족돼야 임계점을 넘을 수 있었다고 진단한다. 첫째, 모델 개선이다. 1년 전 Claude로 같은 작업을 시도했다면 출력의 일관성과 컨텍스트 유지 능력이 부족했을 가능성이 크다. 둘째, 도구 숙련도다. 에디터 안에서 빌드·테스트·LLM 호출을 한 번에 묶는 파이프라인을 자유자재로 다루는 법을 익혀야 한다. 셋째, 적절한 범위 선택이다. 처음부터 대규모 제품에 적용하지 않고, ‘UX 사소한 불편 수정’처럼 리스크가 낮은 작업부터 시작해 점진적으로 범위를 확장했다는 점이다.

이 세 조건 중 하나라도 빠지면 AI 디자인 도구는 여전히 ‘가끔 써 보는 도구’에 머무른다. 임계점은 도구 자체가 아니라, 모델·사람·작업 범위의 교차점에서 만들어진다.

잔존 과제

물론 이 새로운 흐름이 모든 문제를 해결하지는 않는다. 첫째, 프로토타입의 완성도 환상이다. 동작하는 코드가 곧 제품이 아니듯, AI가 만들어 준 프로토타입은 외형은 매끄럽지만 엣지 케이스나 예외 흐름이 빈약할 수 있다. 둘째, 리뷰 방식의 재설계가 필요하다. 디자이너와 개발자가 같은 화면을 보며 정렬하던 전통적 리뷰 문화는, 에디터 안의 PR 코멘트로 이동하면서 비동기·텍스트 중심의 협업 형태로 변하고 있다. 셋째, 창의적 탐색의 비용이다. AI는 ‘합리적인 다음 단계’를 빠르게 제시하지만, 의도적으로 틀린 시도를 통해 새로운 디자인 언어를 발견하는 과정은 여전히 사람의 몫이다.

결론 — 디자인 단위의 재정의

Figma를 Claude로 ‘대체’하는 것이 핵심은 아니다. 진짜 변화는 디자인이라는 행위의 경계가 ‘고정된 화면’에서 ‘동작하는 코드’로 확장되었다는 점에 있다. 1인 디자이너가 본 임계점은 도구 비교의 프레임을 넘어, “어떤 문제일 때 AI와 함께 작업하는 것이 합리적인가”라는 더 본질적인 질문으로 우리를 이끈다. 임계점의 세 조건을 의식적으로 관리하는 팀일수록, 그 질문에 대한 답을 빠르게 축적해 갈 수 있을 것이다.