feat: 디자인 토큰 자동화 파일 구성

[wlrnjs]

Pull Request

관련 이슈

• issue [TASK] 피그마 디자인 토큰 자동화 구현 #44

작업 내용

• 피그마 디자인 토큰 자동화 워크플로우 및 style-dictionary 세팅 진행했습니다.

참고 사항

• 세팅만 진행했으며, 아직 monitor-web과 연결되지는 않았습니다.
• PR 머지 후 figma 테스트 필요합니다

체크리스트

• 기능이 정상 동작하는지 확인
• 불필요한 코드/주석 제거

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
finditem-monitoring	Ready	Preview, Comment	May 11, 2026 4:11pm

[junye0l]

수고하셨습니다!

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

이 PR은 피그마 디자인 토큰을 자동화된 방식으로 관리하기 위한 초기 설정을 도입합니다. Style Dictionary를 활용하여 디자인 토큰을 중앙에서 정의하고, 이를 CSS 변수, JavaScript 모듈, 그리고 Tailwind CSS 프리셋과 같은 다양한 개발 환경에서 활용할 수 있는 형식으로 자동 생성합니다. 이는 디자인과 개발 간의 일관성을 보장하고 수동 작업을 줄이는 데 기여할 것입니다.

Highlights

• 디자인 토큰 자동화 워크플로우 설정: 피그마 디자인 토큰을 활용한 자동화 워크플로우를 설정했습니다.
• Style Dictionary 통합: Style Dictionary를 프로젝트에 통합하여 디자인 토큰을 관리하고 다양한 형식으로 변환하도록 구성했습니다.
• 다양한 형식의 토큰 생성: CSS 변수, JavaScript 토큰 및 Tailwind CSS 프리셋을 자동으로 생성하도록 설정했습니다.
• Gitignore 업데이트: 생성된 디자인 토큰 파일들이 Git에 의해 추적될 수 있도록 .gitignore 파일에 예외 규칙을 추가했습니다.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/build-design-tokens.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

---

디자인 토큰, 일관된 색과 글꼴, 자동화된 꿈.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request establishes a design tokens package utilizing Style Dictionary, providing source tokens and auto-generated outputs for CSS, JS, and Tailwind. The reviewer recommends removing the dist directory from the repository to prevent committing build artifacts and suggests reclassifying build-specific tools as development dependencies.

[gemini-code-assist]

빌드 결과물인 dist/ 디렉토리를 Git 저장소에 직접 포함시키는 것은 권장되지 않습니다. 현재 turbo.json 설정에서 dist/**를 빌드 출력물(outputs)로 관리하고 있으므로, Turbo의 캐시 기능을 통해 환경 간에 빌드 결과물을 공유할 수 있습니다. dist/ 폴더를 Git 추적에서 제외하여 저장소의 크기를 줄이고 불필요한 머지 충돌을 방지하는 것이 좋습니다.

[gemini-code-assist]

style-dictionary와 @tokens-studio/sd-transforms는 디자인 토큰을 빌드하는 과정에서만 사용되는 도구이므로, 런타임 의존성(dependencies)이 아닌 개발 의존성(devDependencies)으로 분류하는 것이 적절합니다.

Suggested change

	"dependencies": {
	"@tokens-studio/sd-transforms": "^1.2.0",
	"style-dictionary": "^4.0.0"
	}
	"devDependencies": {
	"@tokens-studio/sd-transforms": "^1.2.0",
	"style-dictionary": "^4.0.0"
	}

References

1. In a monorepo, it is acceptable to keep dependencies in a single project's package.json initially. This suggestion correctly reclassifies them within the project scope rather than moving them to the root.