쉬운 설명
요리에 한번 비유해 볼까요? 좋은 재료와 정확한 레시피를 쥐여주더라도, 손님에게 어떤 요리를 먼저 내놓을지, 접시에 어떻게 담아야 먹음직스러워 보일지는 전혀 다른 문제죠. 라이너 팀이 만든 'Pencil'은 AI에게 단순한 디자인 규칙만 알려주는 데서 멈추지 않았습니다. 먼저 무엇을 보여줄지 꼼꼼히 계획하게 하고, 그다음 실제로 디자인하게 한 뒤, 마지막으로 완성된 결과를 꼼꼼히 점검하도록 만들었어요. 일을 세 단계로 쪼개고 각각 전담 역할을 맡긴 셈입니다. 여기에 더해 매번 똑같은 자료를 처음부터 다시 찾지 않도록, 자주 쓰는 정보를 파일 하나에 미리 깔끔하게 정리해 두었습니다.
요약
라이너의 Pencil 제작기 2편에서는 AI 에이전트가 화면을 직접 디자인하는 과정을 다루고 있습니다. 먼저 디자인 시스템(색상, 글꼴, 여백, 컴포넌트 규칙 등)을 에이전트가 읽을 수 있게 정리한 문서가 바로 DESIGN.md인데요. 이 문서 덕분에 에이전트는 우리 브랜드만의 스타일을 매번 어림짐작하지 않아도 됩니다. 하지만 똑같은 재료를 쓰더라도 지금 만드는 화면에서 무엇을 먼저 보여줄지, 사용자가 어떤 행동을 편하게 느끼게 할지는 매번 달라지기 마련이죠. 그래서 규칙만 잔뜩 쥐여준다고 해서 완성도 높은 화면이 보장되지는 않는다고 설명합니다. 라이너 팀은 이 문제를 해결하기 위해 작업을 '기획', '디자인', '리뷰'의 세 단계로 나누고, 각 skill(기능)이 이를 순서대로 맡도록 했습니다. 즉, Pencil은 이러한 skill들을 하나로 엮어낸 'Product Design 하네스(작업 제어 틀)'인 셈이죠.
특히 가장 까다로웠던 과정은 바로 '리뷰' 단계였습니다. "좀 더 자연스럽게 고쳐줘" 같은 애매한 표현은 에이전트에게 제대로 통하지 않기 때문인데요. 그래서 '어디가 왜 어색한지'와 '구체적으로 무엇을 어떻게 바꿔야 하는지'를 명확한 관찰 및 수정 지시로 풀어내 skill로 만들었다고 해요. 또 시간과 비용을 아끼기 위해, Figma MCP로 매번 똑같은 맥락을 다시 읽어오지 않도록 컴포넌트의 고유 key와 속성 정보를 JSON 같은 정적 파일에 미리 정리해 두었습니다. 앞으로는 슬랙(Slack)에서 Pencil Hermes Agent를 불러 간단한 시각화 작업을 바로 요청할 수 있게 확장할 계획이라고 합니다. AI를 그저 '규칙을 주입하는 대상'이 아니라 '역할과 절차를 정교하게 설계해야 하는 파트너'로 바라본 점이 참 돋보입니다.
활용 포인트
이 방식은 꼭 디자인 분야가 아니더라도 얼마든지 응용할 수 있어요. 예를 들어 AI에게 발표 자료를 부탁할 때 한 번에 "자료 하나 만들어줘"라고 요청하기보다는, 1단계에서 발표를 들을 청중과 핵심 메시지, 정보의 우선순위부터 먼저 정리하게 해보세요. 그런 다음 2단계에서 그 기획을 토대로 초안을 작성하게 하고, 3단계에서는 별도의 프롬프트를 통해 "중요한 내용이 한눈에 먼저 들어오는가?", "불필요하게 겹치는 내용은 없는가?" 같은 체크리스트로 꼼꼼히 검토하게 만드는 식이죠. 개발자라면 코드를 짜는 지침과 작성된 코드를 리뷰하는 지침을 따로 나누어 운영해 볼 수도 있습니다.
여기서 핵심은 리뷰 지침을 줄 때 "자연스럽게 다듬어줘"처럼 두루뭉술하게 말하지 않는 것입니다. "제목과 본문의 글자 크기 차이가 작다면 제목을 더 키우거나 본문 사이의 간격을 넓혀라"처럼, 무엇을 확인해야 하는지(관찰)와 어떻게 고쳐야 하는지(수정 방법)를 짝지어 구체적으로 적어주는 것이 좋습니다. 또한 팀에서 자주 쓰는 컴포넌트나 용어를 JSON이나 마크다운 파일로 미리 정리해 두면, 에이전트가 매번 외부 도구에서 같은 정보를 다시 조회하느라 시간과 비용을 낭비하는 일도 줄일 수 있습니다.
주의 사항
다만 이 글은 한 팀의 실제 작업 경험담인 만큼, 모든 상황에서 똑같은 효과가 난다고 장담하기는 어렵습니다. 단계를 쪼개면 그만큼 거쳐야 할 과정이 늘어나므로, 아주 가벼운 작업을 할 때는 오히려 번거롭게 느껴질 수 있거든요. 또 미리 만들어 둔 JSON 같은 정적 파일은 디자인 시스템이 바뀔 때마다 잊지 않고 함께 업데이트해 주어야 합니다. 그러지 않으면 옛날 정보를 바탕으로 엉뚱한 결과물을 만들어낼 위험이 있습니다. 아울러 슬랙(Slack) 연동은 지금 당장 쓸 수 있는 기능이 아니라, 앞으로 확장해 나갈 계획이라는 점도 참고해 두시면 좋겠습니다.
자체 검증
원문과 내용을 꼼꼼히 대조해 본 결과, 핵심 주장은 모두 사실과 일치합니다. DESIGN.md에 토큰과 브랜드 분위기, 레이아웃 원칙 등이 담겨 있다는 점, 작업 단계를 기획·디자인·리뷰로 나눈 점, 리뷰 지침을 구체적인 규칙으로 만든 점, 그리고 Figma 컴포넌트 key를 바탕으로 JSON 파일을 정리했다는 점 모두 원문에 정확히 나와 있습니다. 슬랙(Slack) 연동 역시 원문에서 "~하려고 합니다"라고 언급된 향후 계획이 맞습니다. 다만 '활용 포인트' 섹션에서 소개해 드린 발표 자료 제작 단계나 리뷰 지침 문장 예시는 원문 내용을 바탕으로 제가 직접 응용해 작성한 예시입니다. 또한 원문에는 시간이나 비용이 구체적으로 얼마나 줄어들었는지 수치가 적혀 있지 않아, 그 효과의 크기까지는 객관적으로 확인할 수 없었습니다.
태그
#AI #AI에이전트 #디자인시스템 #DESIGN.md #Figma #하네스 #워크플로우 #Liner