에이전트가 코딩의 대부분을 담당하는 시대에 디자인 워크플로우 구축하기

저는 일부 제품들을 @figma와 @paper로 가져와서 다듬는 작업을 하며 디자인 부채(design debt)를 갚아나가고 있습니다. 지금은 둘 다 사용하면서 우리에게 어떤 것이 더 잘 작동할지 보고 있습니다.

에이전트가 이제 코딩의 대부분을 담당하고 있기 때문에 (당연하죠), 현재의 프로덕션 환경들을 디자인 도구로 가져와 시각적인 작업을 하고, 그 변경 사항을 에이전트가 기존 코드에 다시 반영할 수 있는 워크플로우를 찾으려고 노력 중입니다.

순수하게 디자인만 하는 도구로는 Figma가 더 좋지만, 질문은 Paper가 AI 기능이 많이 활성화된 사용 사례(use case)에는 더 좋은지 여부입니다.

지금까지는 답이 '예'인 것 같습니다. 대부분의 웹 프로젝트에서 @paper를 사용했을 때 더 깔끔한 디자인을 얻고 있으며, 심지어 일부 iOS 화면들을 재현하는 작업에서도 더 나은 성능을 보여주었습니다 (Paper가 오른쪽에 있습니다).

Paper는 캔버스에 HTML과 CSS를 사용하기 때문에 에이전트가 웹사이트와 동일한 레이아웃 및 스타일링 개념으로 작동합니다. 이는 기존 사이트를 Paper로 가져오고, 변경하고, 브라우저로 다시 가져올 때 편차가 적다는 것을 의미해야 합니다.

Figma의 MCP는 에이전트에게 [내용 생략]을 제공합니다.

Paper의 주요 문제는 일반적인 에이전트 설정이 컴퓨터에 데스크톱 앱이 열려 있어야 한다는 것입니다. 로컬 MCP 서버를 통해 작동하기 때문에, 에이전트 도구들이 파일 작업을 하려면 해당 기기에 접근해야 합니다.

로컬에서 작업하는 경우에는 큰 문제가 아니지만, [내용 생략]인 것 같습니다.

Figma의 경우, 호스팅된 MCP 서버가 있기 때문에 원격으로 디자인 파일을 작업할 수 있습니다. 또한 디자인을 생성하고 편집할 수도 있어서, 에이전트에게 시각적 작업을 맡기고 그 변경 사항을 데스크톱 앱에 의존하지 않고 코드에 다시 가져올 수 있습니다.

Paper에서 제가 지금까지 발견한 다른 한계점들은 다음과 같습니다. 내보내기(exporting)를 하거나 에이전트가 구축하도록 하지 않는 이상 캔버스 외부에서 디자인을 미리 볼 방법이 없다는 점, 그리고 단일 텍스트 레이어 내에서 텍스트 스타일을 혼합할 수 없다는 점입니다. 따라서 한 단어는 흐리게 처리하고 나머지는 [내용 생략]할 수는 없습니다.

저는 여전히 두 가지를 모두 테스트하고 있으며, 많은 부분이 에이전트가 어디에서 실행되느냐에 달려 있습니다. Paper의 결과는 저희 웹 작업에 유망하지만, 제 컴퓨터에 앱이 열려 있는 것에 의존하지 않고도 동일한 워크플로우가 가능하기를 바랍니다.