AI는 고쳤다는데 화면은 그대로? 한 개발자가 확인 장치를 붙였다

AI가 수정했다고 답했는데 화면에는 변화가 없다면, 디자이너는 어디부터 찾아야 할까. Penpot 커뮤니티에 10월 4일 올라온 한 개발자의 도구는 이 틈을 겨냥했다. 게시자 Pdasilem은 자신이 만든 비공식 MCP 서버를 공개하며 실제 변경 적용을 확인하는 방식을 설명했다.

개발자의 설명에 따르면 도구는 전달받은 인수를 검사하고 Penpot에 수정이 적용됐는지도 살핀다. 오류가 있으면 드러내고 편집 전에 맞는 페이지를 연다. AI의 말과 실제 파일 사이에 확인 절차를 둔 것이다. 이는 제작자의 작동 설명이며 독립 시험 결과는 아니다.

다음 날인 10월 5일에는 디자인 시스템을 코드로 내보내는 기능을 추가했다고 밝혔다. 색과 글자 설정, 여러 테마의 디자인 토큰을 CSS나 Tailwind, TypeScript, SwiftUI 같은 형식으로 전달하는 기능이다. 화면을 바꾸는 일에서 다른 작업 환경으로 넘기는 일로 범위를 넓혔다.

여기서 공식과 비공식을 섞지 않아야 한다. Penpot이 새 정식 기능으로 출시했다는 발표가 아니라 한 개발자가 커뮤니티에 소개한 프로젝트다. 내보내기 도구 그룹은 기본으로 꺼져 있고 일부 연결 프로그램에서는 켠 뒤 다시 연결해야 할 수 있다는 조건도 적혀 있다.

이 소식이 디자인 쪽에서 흥미로운 이유는 코드 형식의 개수 때문만은 아니다. 같은 색을 화면에서는 파랑, 개발 파일에서는 별도 숫자로 관리하면 둘 중 하나가 바뀌었을 때 차이를 추적해야 한다. 설정을 연결해 넘기려는 시도는 그 경계에 놓여 있다.

가상의 앱에서 기본 테마와 어두운 테마를 만든다고 해 보자. 버튼의 색만 바꾸면 끝나는지, 눌렀을 때와 비활성 상태도 맞는지 살펴야 한다. 코드가 생성됐다는 사실만으로 모든 상태가 디자인의 의도대로 작동한다는 결론을 내릴 수는 없다.

이 프로젝트가 드러내는 문제는 화면을 조작하는 AI의 답변만으로 작업 상태를 알기 어렵다는 것이다. 개발자는 페이지를 열고 변경 적용을 검사하는 절차를 도구에 넣었다고 설명했다. 요청을 이해한 것, 명령이 실행된 것, 실제 파일이 바뀐 것을 나누려는 시도다.

도구를 실제 프로젝트에 넣는 결정은 더 많은 확인이 필요하다. 게시자가 말한 속도와 안정성을 모든 환경으로 일반화할 수 없고, 권한과 호환성도 따로 살펴야 한다. 이번 기사에서는 설치를 실행하거나 작업 파일을 연결해 성능을 시험하지 않았다.

내보내기 기능도 같은 경계를 다룬다. 디자인 도구의 색과 서체가 개발 환경의 코드로 옮겨갈 때 무엇이 유지되는가다. 5일의 후속 공개는 처음의 편집 확인 도구에 인수인계 경로를 더했다. 다만 그 코드가 모든 프로젝트의 상태와 예외를 보존하는지는 검증되지 않았다.

이번 비공식 도구는 AI 디자인의 완성을 선언하지 않는다. 대신 고쳤다는 말 다음에 확인할 것, 넘겼다는 말 다음에 맞춰 볼 것을 보여준다. 에이전트가 작업하는 화면에서도 마지막에 믿을 것은 성공 문구 하나가 아니라 실제로 남은 변경이다.