Pencil vs Figma 고찰: code to design, design to code의 세상

Jung Wish·2026년 2월 21일
post-thumbnail

https://www.pencil.dev/

회사에서 팀장님이 추천하신 Pencil 을 최근에 사용해봤다. Figma의 AI 퀄리티는(Figma Make도 그렇고 MCP도 그렇고)생각보다 만족스럽지 않았는데 Pencil은 이 문제점을 본인들만의 Context Engineering 기술로 보완해낸듯 보인다.

Figma가 사실상 업계의 표준이 되었고 디자이너들의 의존성이 매우 높은편인데,
앞으로 더 develop되서 디자인 편의성까지 보완된다면 Figma는 애매한 포지션으로 남을 수도 있을 것 같다. 일단 너무 비대해지고 무거워진 Figma보다 속도가 빠른게 속시원(?)하다. 실제 회사 디자이너분들은 아직까지는 Pencil에서 Figma에서만큼의 디자인을 만들어내기에는 조금 부족해보여요라는 평가를 주셨다.

개인적인 생각으로는,

  • Design to Code / Code to Design 측면에서는 지금은 Pencil이 더 우세한 듯 보인다.
  • 디자인에 전문적이지 않은 사람들에게 프로토타입을 짜기 좋아 보인다.

Google의 stitch나 Lovable이나 여러가지가 있다고 들었고 맛보기로 몇 번 써보긴 했는데 개인적으로 가장 AX/UX적으로 경험이 좋은것은 Pencil이었다. 현재 무료로 풀려있고 주요 채팅과 design <-> code 기능은 Claude Code나 Codex 등 구독하고 있는 서비스가 있다면 바로 사용 가능하다.

chat을 쓸때마다 디자인 프레임을 마치 스캔(?)하듯이 동작하는게 꽤나 신기하다. 진짜 사람이 일하는 것처럼 동작한다.

Figma Frame을 copy&paste해서 .pen에 옮길 수 있다. copy paste 속도가 너무 빨라서 엄청 놀랐다. 물론 복잡도가 높은 화면은 100% 퀄리티로 가져오진 않고 약간의 조정이 필요하다.

Figma MCP에게 느끼는 아쉬움?

Figma MCP 등장 이후 Design to Code 퀄리티 및 마크업 속도가 비약적으로 빨라졌고, 덕분에 퍼블리싱 하는 노동 강도가 많이 줄었다.

하지만 최근 어그로성 글과는 다르게(모든 개발자 및 디자이너 멸망설) 실무에서 쓰다보면 Figma MCP에 대한 아쉬움이 오히려 더 크다. 이유는 다음과 같다.

  1. MCP Context는 디자이너 설계에 영향을 많이 받는다.

보통 디자이너 분들은 동일한 화면에 대한 추가 Interactive 요소(Modal, Alert, Snackbar)나 UX를 추가할때 같은 디자인 프레임을 Ctrl+V 해서 쓰시는 경우가 많다.

이때, 기존 원본 화면에 layout/style 속성(variable을 지정하지 않았거나 소위말해 하드코딩처럼 하드디자인(?)을 곁들인)이나 Frame 명칭등에 크게 신경쓰지 않고 디자인을 했다면 Figma MCP에서 전달하는 Context가 설계에 영향을 받기 때문에 당연히 context의 퀄리티가 좋지 않다.

이 문제는 근데 Pencil도 마찬가지다. Pencil에서 초기 디자인 초안을 Chat을 통해 만들면 되서 이 점에서도 Pencil이 사용성 측면에서 한수 위라고 생각한다.

  1. 복잡도가 있는 화면의 경우 Context가 방대한데, Chunking해서 받을 수 없다.

MCP 정보는 너무 무거울수록 세션 Context를 많이 잡아먹게 되서, 실질적인 효용성이 많이 떨어진다. 대시보드 처럼 복잡도가 조금만 높아져도 할루시네이션 발생 확률이 높고 구현 퀄리티 질이 많이 떨어진다.

현재 공식 Figma MCP 상에서는 context를 끊어서 받을 수도 없고 context 최적화도 좀 아쉬운 느낌이다. Claude Code는 Response context 제한이 있기 때문에 만약 Figma에서 내려주는 응답이 너무 길면 모든 내용을 받는게 아니라 잘라서 받게 된다. (이 부분은 Anthropic 업데이트가 워낙 빨라서, 더 개선되었을 수도 있는데, 결국 Context를 제공하는 MCP 측이 context engineering 개선을 해주는게 맞는 방향이라 생각한다)

  1. Variable를 한번에 제대로 반영하기 어렵다.

현재 Variable의 경우 MCP에 tool이 존재하긴 하지만 선택/요청한 frame 한정으로 variables를 가져오게되며, mode 정보가 포함되어 있지 않다.

Figma API를 mcp 서버로 wrapping해서 variables를 가져오려고 해봤는데 안타깝게도 Enterprise 전용에서만 Variable API를 지원해서 포기했다. (우리 회사는 Organizations 플랜만 지원...ㅎ)

  1. 이미지 export나 반영이 어렵다.

curl 도구 또는 Figma API를 통해 가져오라고 사전 context rule에 정해놓으면 그나마 나은데, Figma MCP만을 사용해서 퍼블리싱을 시켜보면 정신 못차리는 경우가 대부분 이미지 쪽이다. 한번에 재사용성이 높은 이미지를 저장해두고 작업하고 싶은데 역시 이 부분도 좀 아쉽다.

  1. Code Connect는 굉장한 기능인 것처럼 홍보하지만, 실질적인 효과는 미미하다.

Figma MCP 도구를 보면 Code Connect를 통해 재사용성 컴포넌트를 효율적으로 코딩할 수 있다는 식으로 안내하는데, 이는 컴포넌트 재사용성이 높은 기업 및 디자인 한정이다. Design System을 구축하더라도 디자인할때 custom design이 하나라도 들어가면 무용지물이며 오히려 관리 포인트가 더 늘어서 나는 개인적으로 불편했다.

  1. 반응형 레이아웃, absolute position 관련 context가 매우 아쉽다.

이건 Figma만의 문제라기 보다는 정보의 모호함에서 오는 문제이긴 하다. 어떻게 Interaction을 json 형태의 정보 구조로 표현할 것인지, 이를 AI Model이 어떻게 제대로 판단하게 할 건지가 중요할 것 같다.

결국 다 적고보니 느끼는건데 Context Engineering이 중요하고, 어떻게 디자인 구조를 AI가 잘 이해할 수 있는 구조로 만들 수 있을까가 현재 Figma 뿐만 아니라 모든 디자인 업계의 AI 도입과 관련해 대두된 문제라고 생각한다.

마무리

원래 Figma에는 Design to Code만 지원했고 Code to Design은 없었는데 Anthropic과 파트너십을 체결한 후 Code to Design Tool이 추가되었다.
https://www.linkedin.com/posts/claude_you-can-now-push-what-youre-building-in-activity-7429913281445793793-VoWp?utm_source=share&utm_medium=member_ios&rcm=ACoAAC2C6GcBcJg6sbZXzFCexN90ngTbUJKPPYY

두서없이 적다보니 어떻게 마무리를 지어야할지 모르겠네..

어쨌든 클라리언트쪽 작업을 많이 하다보니 디자인을 코드화 하는 과정에 대한 AI쪽 트렌드를 쫓아가려고 많이 노력중이다. 작년부터는 퍼블리싱 자체를 AI Agent에게 모두 일임하도록 하는 과제를 수행중이다보니 기존 Figma에 느꼈던 내용을 개인적인 감상으로 적어보았다. 수명을 다하는 그날까지 나를 포함한 업계 사람들 화이팅...(이상한 결론)

profile
Frontend Developer, 올라운더가 되고싶은 잡부 개발자, ISTP, 겉촉속바 인간, 블로그 주제 찾아다니는 사람

0개의 댓글