이 글은 웹셀러(디.패밀리)가 실제로 겪은 피그마 로컬 폰트 누락 버그를 AI와 함께 추적한 디버깅 회고입니다. 막혀 있던 며칠을 푼 건 더 좋은 프롬프트가 아니라 문제를 정확히 짚은 한 번의 질문 전환이었습니다. 시점은 2026년 5월 31일~6월 1일 기준입니다.

증상 — 로컬 폰트만 전부 "누락"으로 떴다

2026년 5월 31일 아침, 맥에서 피그마 데스크톱을 켜자 직접 설치해둔 로컬 폰트가 일제히 누락(missing)으로 표시됐습니다. 이상한 건 폰트 목록에 이름은 멀쩡히 보였다는 점입니다. 프리텐다드, 지마켓 산스 같은 폰트를 골라 적용해도 글자는 바뀌지 않고, 다시 보면 누락 표시가 붙었습니다. 그런데 맥 시스템 폰트는 정상 적용됐습니다. 로컬 폰트는 다 죽고 시스템 폰트만 살아 있는 비대칭이 첫 단서였지만, 그때는 그 의미를 읽지 못했습니다.

1단계 — 증상만 보고 표준 해법을 쏟아부었다

증상이 "폰트 누락"이었으니 자연스럽게 폰트와 그 주변을 의심했습니다. AI에게 상황을 던지고 함께 시도한 목록은 이렇습니다.

• 피그마 재설치
• 맥 quarantine(격리) 속성 제거
• 폰트 캐시 삭제
• LaunchServices 데이터베이스 재구축
• 재부팅(두 번)
• 남아 있던 헬퍼 상태 초기화
• 메뉴 막대 설정 토글

하나하나 "이게 원인일 수 있다"는 가설이 붙어 있었고, AI도 막힘없이 다음 시도를 제안했습니다. 한 번은 캐시를 지우고 재부팅한 직후 AI가 "이제 해결됐을 겁니다"라고 단언하기까지 했지만, 다시 켜보니 그대로 누락이었습니다. 이때 세운 가설 중 하나가 "5월 31일 맥 보안 자산 갱신이 앱 실행 환경을 조였다"였는데, 결과적으로 틀린 추측이었습니다. 시도 목록만 길어지고 한 발짝도 못 나갔습니다. 지금 보면 문제는 분명합니다. 우리는 표면 증상만 쫓았을 뿐, 피그마가 로컬 폰트를 실제로 어떻게 불러오는지 그 동작 원리를 몰랐습니다.

2단계 — 증상 대신 동작 원리를 봤다

질문을 바꿨습니다. "피그마는 대체 내 로컬 폰트 폴더의 파일을 어떻게 읽어오는가?" 구조는 이랬습니다. 피그마 렌더러는 샌드박스 안에서 돌기 때문에 로컬 폰트 폴더를 직접 읽지 못합니다. 그래서 피그마는 별도의 작은 헬퍼 프로세스(FigmaAgent)를 띄워, 폰트 파일을 읽어 그 실제 바이트를 로컬 웹 서버로 넘겨줍니다. 그것도 하나가 아니라 둘입니다. http는 127.0.0.1:44950, https는 :44960으로 동시에 띄웁니다. 데스크톱 앱이든 브라우저판이든 둘 다 이 헬퍼에 의존합니다.

여기서 첫 단서가 풀렸습니다. 시스템 폰트가 멀쩡했던 건 헬퍼를 거치지 않고 OS가 직접 로드하기 때문입니다. 헬퍼를 안 타는 경로만 정상이었던 것입니다. "헬퍼를 타는 폰트는 다 죽고 안 타는 폰트만 산다"는 건 폰트 파일도 캐시도 아니라 헬퍼-서버 경로 자체가 끊겼다는 신호였습니다. 그제서야 질문이 분명해졌습니다. "폰트 바이트를 넘겨주는 그 포트가 지금 열려 있긴 한가?"

3단계 — 데이터가 흐르는 경로를 직접 찔러봤다

추측을 멈추고 실제 경로를 확인했습니다. 헬퍼가 쓴다는 포트가 떠 있는지부터 봤습니다.

lsof -iTCP:44950 -sTCP:LISTEN