Figma의 Dev Mode MCP 서버 사용을 위한 5가지 팁

새로운 직장에서의 첫날을 떠올려 보세요. 아마 익숙한 패턴을 따랐을 겁니다. 새로운 팀원을 만나고, 온보딩 자료를 받고, 맡은 일을 어떻게 접근할지 고민하기 시작했겠죠. 이제 구조나 맥락 없이, 단지 새로운 도구와 정보만 쏟아지고 이를 이해할 지도가 없는 상황을 상상해 보세요.

이것은 우리가 AI 에이전트에 원시적이고 구조화되지 않은 디자인 데이터를 전달할 때 기대하는 것과 비슷합니다. Figma의 Dev Mode MCP 서버는 디자인 파일에서 컨텍스트를 AI 에이전트로 가져와, 보다 효율적이고 정확한 디자인-코드 업무 흐름을 가능하게 합니다. 마치 효과적인 온보딩 경험이 잘 정리된 문서와 명확한 기대치에 의존하듯, 입력 데이터를 개선하기 위한 조치를 취하면 최종 출력 품질 역시 높일 수 있습니다. 여기에서는 AI 에이전트가 팀의 실제 요구에 더 일관되고 정확하게 맞는 코드를 생성하도록 돕는 5가지 실용적인 팁을 공유합니다.

1. 견고한 디자인 구조로 시작하기

디자인과 코드 각각의 세계에는 저마다의 구조 정의가 있습니다. 디자인에서 구조란 보다 전체적인 그림을 의미합니다. 각 요소의 배치, 레이아웃 속에서 요소들이 어떻게 조화를 이루는지, 그리고 전체적으로 제공되는 사용자 경험까지 포함됩니다. 반면 코드에서 구조는 구체적인 규칙, 구성, 문법을 의미하며, 코드를 효과적으로 컴파일하고 작동시키기 위해 반드시 따라야 하는 요소들입니다. 구조에 대한 "정답"은 없지만, 이러한 차이를 이해하고 가능한 한 디자인과 코드 사이의 간극을 연결하는 것이 중요합니다.

디자인과 코드를 정렬하는 방법

디자인을 코드로 더 쉽게 변환하기 위한 구조화 방법은 다음과 같습니다.

• 외부에서 내부로 접근하기: 요소의 가장 바깥쪽 레이어는 무엇인가요? 카드인가요, 웹페이지의 한 섹션인가요? 무엇이든 상관없습니다. 가장 바깥 레이어부터 시작하여, 그 안에 추가 요소들을 계층적으로 중첩시키는 방식으로 작업하세요.
• 레이어에 이름을 지정하기: 해당 디자인이 무엇을 나타내고 있는지, 무엇으로 구성되어 있는지 생각하세요. 예를 들어, 양식 상자에서는 입력, 버튼, 링크 등 요소에 라벨을 붙이면 더 나은 결과를 얻을 수 있습니다.
• 컴포넌트 사용하기: 컴포넌트는 디자인-코드 변환을 돕는 것뿐만 아니라, 향후 디자인에서 반복 가능한 패턴을 만드는 데에도 유용합니다.

두 개의 양식 상자 이야기

이제 이러한 원칙들이 실제로 어떻게 적용되는지 예시를 보여드리겠습니다. 여기에는 두 개의 양식 상자가 있습니다.

언뜻 보기에는 이 두 양식이 매우 비슷해 보입니다. 배치 방식도 같고, 포함된 요소도 동일하며, 전체적으로 전달하는 내용도 같습니다. 디자인 관점에서 두 양식 모두 "올바르게" 구조화되어 있지만, 하나는 코드에 최적화되어 있고, 다른 하나는 그렇지 않습니다. 이제 레이어 구조를 자세히 살펴보겠습니다.

왼쪽 양식에서는 컴포넌트 레이어마다 명확한 구조와 구체적인 이름이 지정되어 있습니다. 반면 오른쪽 양식에서는 요소들이 하나의 레이어에 함께 그룹화되어 있습니다. 레이어 이름과 구조를 구체적으로 지정하는 것이 시각적인 디자인에는 큰 영향을 주지 않더라도, 왼쪽 양식과 같이 구조화되어 있으면 AI 에이전트가 더 높은 품질과 관련성 있는 코드를 생성하는 데 훨씬 유리합니다.

오른쪽 양식의 디자인에서는 AI 에이전트가 모든 요소를 하나의 div 요소로 해석하고, 포함된 모든 요소를 단일 컨테이너 안에 넣으려 할 가능성이 높습니다. 그 결과, 여백과 레이아웃 문제 등이 발생할 수 있으며, 개발자가 다시 돌아가 수동으로 수정해야 하는 상황이 생기게 됩니다.

2. 공유된 변수 언어에 일치시키기

최근 디자인-개발자 핸드오프 가이드에서 우리는 팀 간 공유된 언어를 통한 정렬의 중요성에 대해 이야기했습니다. 여러 측면에서, Dev Mode MCP 서버는 디자이너와 AI 에이전트 간의 핸드오프 도구로 생각할 수 있습니다. 디자이너와 개발자 간의 핸드오프와 마찬가지로, AI 에이전트로의 핸드오프도 스타일이나 변수와 같은 항목에 대한 공유된 언어를 만드는 것에 달려 있습니다. 이렇게 하면 AI 에이전트가 조직에서 설정한 디자인 패턴과 일치하도록 보장할 수 있습니다.

변수를 코드로 번역하기

MCP 서버의 출력을 최적화하는 좋은 방법 중 하나는 변수에 코드 구문 설정을 활용하는 것입니다. 디자인에서 코드 문법이 포함된 변수를 사용하면, 변수 값과 해당 문법이 모두 코드 출력의 일부로 AI 에이전트에 전달됩니다. 다음은 AI 에이전트가 디자인 컨텍스트를 더 잘 이해하고, 보다 일관된 출력을 생성하도록 돕는 방법입니다.

• 명명 규칙 적용: 새로운 변수가 기존 디자인 시스템의 변수와 일치하도록 설정하세요.
• 구문 전달: 특정 프레임워크에서는 코드에서 변수를 사용할 때 다른 구문이 필요하므로, AI 에이전트가 올바른 구조로 변수를 처리할 수 있도록 알려주세요.
• 반응형 만들기: AI 코드 생성 시 하드코딩 크기를 피하세요. 컴포넌트가 올바른 브레이크포인트에 맞춰 구조화되도록 AI 에이전트에 지시하세요.

변수 변경 사항을 대규모로 적용하기

일반적으로 값의 하드코딩은 피하는 것이 좋습니다. 하드코딩을 하면 유지해야 할 영역이 더 커지고 관리가 복잡해질 수 있기 때문입니다. 예를 들어, 향후 브랜드를 리프레시하면서 색상 팔레트나 글꼴 스타일을 바꾸게 되면, 여러 웹 요소를 일일이 업데이트해야 할 수 있습니다. 변수를 사용하면 이러한 변경이 훨씬 간단해집니다. 스타일시트만 업데이트하면, 해당 변수가 사용된 모든 곳에 새로운 값이 적용됩니다. AI가 대량의 코드를 생성할 수 있는 상황에서는, 이러한 수준의 일관성을 유지하는 것이 매우 중요합니다.

새로운 공통 언어 강화하기

하지만 생성을 넘어 감사 측면은 어떨까요? Dev Mode MCP 서버를 사용하면 디자인 변수와 코드베이스 간에 불일치가 발생했을 때 이를 식별할 수도 있습니다. 서버에는 get_variable_defs라는 도구가 제공됩니다. 이 도구를 사용하면 선택한 영역의 변수를 코드베이스의 스타일시트와 비교하고, 일관된 패턴 사용을 강제할 수 있습니다.

3. 주석을 통해 디자인 의도 전달하기

디자인은 종종 더 동적인 것을 시각적으로 정적인 형태로 표현한 것입니다. 시각적 디자인에서 보이는 것 외에도, 코드로 변환할 때 고려해야 하는 보이지 않는 상태가 있습니다. 여기에는 상태 로직, 반응형, 접근성 가이드라인 등이 포함됩니다. 협업자가 디자인에서 상태 로직을 추론할 수는 있지만, LLM은 그렇게 작동하지 않습니다. LLM은 MCP 서버를 통해 제공된 원시 데이터를 보고, 프롬프트에서 주어진 작업을 수행합니다. 사용자가 이를 해결하는 한 가지 방법은 점점 더 복잡한 프롬프트를 만드는 것이지만, 흥미롭게도 LLM은 프롬프트가 더 간결하고 구체적인 문장일 때 성능이 더 좋게 나타나는 경향이 있습니다.

LLM을 위한 도구 팁으로서의 주석

주석은 AI 에이전트에 컨텍스트를 제공하는 핵심 도구입니다. 주석을 통해 디자인에서 바로 보이지 않는 디자인 의도를 전달할 수 있습니다. Dev Mode MCP 서버의 응답에는 카테고리를 포함한 주석 데이터가 포함됩니다. 다음은 코드 생성을 안내하기 위한 몇 가지 샘플 주석입니다.

• 애니메이션 및 호버 효과 표시: 테이블 행에 확대(zoom) 효과를 적용하거나, 호버 시 배경이 블랙 200으로 변경되도록 지정할 수 있습니다.
• 상태 변화 전달: 사용자가 버튼 값에 해당하는 페이지에 있을 경우, 내비게이션 버튼이 비활성화되어야 한다는 점을 명시하세요.
• 콘텐츠 출처 지시: 특정 섹션이 CMS에서 동적으로 가져오는 것임을 주석으로 표시하고, 일정 크기 이후에는 페이지 매김을 사용하도록 지침을 제공하세요.

디자이너와 도구 모두의 윈-윈

주석을 통해 AI 에이전트에 의도를 전달하는 것 외에도, 이러한 방식은 디자이너의 시간을 절약할 수 있습니다. 앞서 언급한 내비게이션 버튼 예를 보세요. 내비게이션 패널에 옵션이 몇 개 있느냐에 따라, 각 상태별로 디자인을 개별적으로 만들어야 할 수도 있습니다. 하지만 주석을 사용하면, AI 에이전트가 디자인 컨텍스트 내에서 이러한 상태들을 자동으로 생성하도록 할 수 있습니다.

4. 규칙으로 가드레일 만들기

주석은 디자인 의도를 전달하고 원하는 기능을 표현하는 데는 훌륭하지만, 실제 코드에서 레이아웃이 어떻게 작동하는지나 백엔드 데이터 구조가 어떻게 구성되는지를 전달하는 데는 적합하지 않습니다. 바로 이런 부분에서 규칙이 필요합니다. 주석이 툴팁과 같아 프레임마다, 반복마다 달라질 수 있는 지침을 제공한다면 규칙은 데이터를 해석하고 작업을 수행하는 프레임워크를 만드는 핸드북과 같습니다. 어떤 것을 규칙으로 만들고, 어떤 것을 단순한 프롬프트 지시로 둘지 결정할 때는 스스로에게 물어보세요. "이 유형의 요청을 할 때마다 AI 에이전트가 항상 이 정확한 행동을 수행하길 원하는가?"

규칙을 구조화하는 방법

Cursor, Windsurf, VS Code(Copilot 지침이라고도 불림)와 같은 편집기용 규칙은 비교적 쉽게 만들 수 있습니다. 규칙 파일을 일반 마크다운으로 작성하고, 지정된 디렉토리에 저장한 뒤, 규칙이 호출되는 방식을 수동 또는 자동으로 설정하면 됩니다. 규칙 파일에서 지정할 수 있는 항목에는 다음과 같은 것들이 있습니다.

• 기존 컴포넌트 사용: 에이전트에게 기존 코드를 찾을 위치를 알려주고 중복을 방지합니다.
• 선호하는 레이아웃 원시 및 스타일 지침: 이미 반응형 디자인을 보장하기 위한 조치를 취했으므로, 그것들이 사용되고 있도록 합니다.
• 통합할 데이터 원본: 코드베이스 내의 데이터 구조를 전달하는 것이 프롬프트만 사용하는 것보다 더 쉽습니다.
• 파일 조직 및 명명 규칙: 새로운 코드가 작성될 때, 기존 디렉토리 구조를 준수하도록 합니다.

5. 반복을 두려워하지 않기

AI 에이전트를 팀의 새로운 엔지니어로 생각해본다면, 실제 엔지니어가 작업하는 방식을 이해하는 것이 중요합니다. AI 에이전트는 한 번의 시도로 문제를 해결하지 못할 가능성이 높으며, 프롬프트는 종종 대화의 시작점에 불과합니다. 대부분의 경우, 첫 번째 프롬프트로 어느 정도 괜찮은 결과를 얻을 수 있지만, 일부 문제를 수정하기 위해 AI 에이전트에 조정 후 재프롬프트를 해야 할 가능성이 높습니다. 이것은 전혀 나쁜 일이 아닙니다! AI 에이전트가 올바른 정보를 보고 있는지 확인하기 위해 도구 호출을 다시 실행하게 하거나, 빌드 방식을 바꾸기 위해 프롬프트를 조정할 수 있습니다. Dev Mode MCP 서버를 사용하면, 프롬프트를 반복하고 다듬는 과정에서 AI 에이전트가 디자인 컨텍스트를 확보하게 되어, 보다 관련성 높은 출력을 생성할 수 있습니다. 이러한 컨텍스트 덕분에, 필요한 에이전트 호출의 수를 줄이면서 성공 기준을 달성할 수 있습니다.

AI 환경이 계속 변화하고 있다는 점을 기억하세요

AI 기술의 발전 속도는 놀라울 정도로 빠릅니다. 이러한 급속한 변화는 흥미롭지만, 오늘 존재하는 기능이 내일은 동일하지 않을 수 있다는 점을 기억하는 것이 중요합니다. 베타 기간 동안, 우리는 훌륭한 사용자 피드백과 변화하는 사양 덕분에 이미 여러 개선 사항과 새로운 기능을 도입했습니다. 더 나은 디자인 기반 코드 생성을 위해, 변화에 유연하게 대응하는 것이 중요합니다.