# email-design.md: 이메일 에이전트에게 주는 브랜드 브리프

정식 URL: https://brew.new/ko/blog/email-design-md
글쓴이: Thomas Park
게시일: 2026-06-15
수정일: 2026-09-28

헥스 코드는 이메일 에이전트에게 어떤 파란색을 쓸지 알려 줘요. 하지만 브랜드가 왜 모든 헤드라인 위에 작은 모노스페이스 라벨을 두는지, 왜 구분선을 상자가 아니라 얇은 선으로 쓰는지는 알려 주지 않아요.

Brew의 첫 브랜드 모델이 바로 이 문제를 안고 있었어요. 수많은 값을 담았는데도, 브랜드를 한눈에 알아보게 하는 디테일은 놓쳤어요.

## 거의 모든 것에 필드가 있던 객체

처음에는 브랜드를 구조화된 데이터처럼 다뤘어요. 색상, 타이포그래피, 에셋, 그리고 수많은 스타일 속성을 모델링했어요. 크롤러가 필드를 채우면, 생성 과정에서 이 필드들을 모아 이메일 에이전트에게 줄 맥락을 만들었어요.

결과물은 색상과 폰트가 맞아도 여전히 평범해 보일 수 있었어요. 새 브랜드가 들어올 때마다 스키마가 예상하지 못한 디테일이 하나씩 생겼어요. 필드를 계속 추가할 수도 있었지만, 더 쓸모 있는 질문은 디자이너라면 같은 브랜드를 다른 사람에게 어떻게 설명할까였어요.

디자이너라면 가이드를 쓸 거예요. 중요한 곳에는 정확한 값을, 도움이 되는 곳에는 예시를 넣고, 그 사이의 결정은 글로 풀어 설명하겠죠.

그래서 추출 에이전트에게 요청하는 결과물을 바꿨어요.

## 문서가 곧 브리프

그렇게 만든 문서가 `email-design.md` 파일이에요. 특정 브랜드가 이메일에서 어떻게 보여야 하는지 설명하는, 수정할 수 있는 마크다운 문서예요.

다음은 줄여서 보여 주는 가상의 예시예요.

```markdown
# Acme email design

## Voice

Write for engineers who want the setup instructions first.
Use short explanations and name the product action precisely.

## Signature details

- Put a small monospace label above the main headline.
- Use thin dividers between sections, without drop shadows.
- Reserve the accent color for the primary action.
- Use one product screenshot when it explains the task.

## Assets

Use the approved logo URL from the asset list.
Do not invent product images or customer logos.
```

이 문서에는 정확한 색상 값 옆에 “강조 색상은 이메일당 한 곳에만 쓴다” 같은 규칙을 함께 담을 수 있어요. 덕분에 저희가 하나하나 예상하지 못한 경우에도 에이전트가 따를 지침이 생겨요.

![브랜드 대화 옆에 수정할 수 있는 email-design.md를 띄운 Brew 화면.](/blog/email-design-md-editor.png)

*브랜드 지침이 그대로 보여요. 수정한 내용은 다음 브리프의 일부가 돼요.*

여기서 마크다운이 유용한 이유는 특별한 입력 폼 없이도 사람이 읽고 수정할 수 있기 때문이에요. 제목으로 문서를 구조화할 수 있고, 새 디자인 규칙을 추가할 때 데이터베이스 필드를 새로 만들 필요도 없어요. 실용적인 이유로 고른 형식이에요. 마크다운이 JSON보다 항상 토큰을 적게 쓴다거나, 모든 모델이 주로 마크다운으로 학습했다는 주장은 아니에요.

## 이메일에 필요한 별도의 디자인 지침

웹사이트와 이메일은 렌더링 제약이 달라요. 폰트, 레이아웃, 다크 모드 지원은 메일 클라이언트마다 제각각이에요. 브라우저 미리보기에서 제대로 보이는 디자인도 받은편지함에서 따로 테스트해야 해요.

그래서 브랜드 문서에는 대체 폰트, 컨테이너 너비, 테이블 레이아웃에 맞는 레시피, 밝은 배경과 어두운 배경에 맞는 선택처럼 이메일에 특화된 지침이 들어가요. 이런 지침은 에이전트가 적절한 결정을 내리도록 돕지만, 모든 클라이언트에서 똑같이 렌더링된다고 보장하지는 않아요.

이미지에는 다른 요건이 있어서, Brew는 이미지 지침용으로 `image-style.md` 파일도 따로 써요. 하나의 디자인 토큰 목록으로 모든 매체를 설명하려 하기보다, 두 관심사를 명시적으로 나누는 편이 더 쉬워요.

## 이미 신뢰하는 자료에서 출발하기

운영 중인 웹사이트는 유용한 근거지만, 늘 기준이 되지는 않아요. 지난 캠페인이나 브랜드 팀이 더 이상 쓰지 않는 스타일 실험이 남아 있을 수 있거든요.

Brew는 도메인과 함께 제공받은 브랜드 가이드, 로고, 이미지, 기타 참고 자료를 활용할 수 있어요. 업로드한 브랜드 지침과 웹사이트에서 추론한 내용이 다르면 업로드한 지침이 우선해요. 생성된 문서는 꼭 검토하세요. 원본 자료가 불완전하거나 서로 맞지 않는 부분은 특히 꼼꼼히 보세요.

![웹사이트 입력란과 참고 파일을 올리는 영역이 있는 브랜드 설정 폼.](/blog/email-design-md-ingest.png)

*도메인과 승인된 파일은 추출 과정에 서로 다른 종류의 근거를 제공해요.*

버튼 모양이 틀렸다면 지침을 바꾸세요. 보이스가 너무 딱딱하다면 모호한 형용사를 예시 문장으로 바꾸세요. 아무도 수정하고 싶어 하지 않는 필드로 가득 찬 거대한 객체보다, 이런 수정이 훨씬 논의하기 쉬워요.

## 이번 변화로 증명되는 것과 증명되지 않는 것

이 문서는 승인된 에셋 위치, 제품명, 디자인 결정을 생성 맥락에 직접 넣어 줘요. 그만큼 모델이 추측해야 하는 빈틈이 줄어들어요. 그렇다고 잘못된 결과가 사라지지는 않아요.

이 작업을 하는 동안 이메일 에이전트의 다른 부분도 함께 바꿨어요. 통제된 비교 없이 전반적인 품질 향상을 파일 형식 덕분으로만 돌리지는 않겠어요. 제가 말할 수 있는 건 그보다 좁아요. 브랜드 브리프를 살펴보고, 고치고, 다시 쓰기가 더 쉬워졌다는 거예요.

생성된 이메일은 여전히 사실 확인과 시각적 검토가 필요해요. 브리프와 대조해 주장을 확인하고, 링크를 테스트하고, 받은편지함에서 결과를 살펴보세요. 이 인계 과정은 [이메일 에이전트 브리프 가이드](/ko/blog/how-to-brief-an-email-agent)에서 다뤄요.

## 연결된 에이전트도 쓸 수 있는 같은 맥락

이제 Brew의 [MCP 서버](/ko/mcp)를 쓸 수 있어요. 호환되는 어시스턴트는 문서화된 도구를 통해, 앱과 같은 브랜드 맥락으로 Brew를 다룰 수 있어요. 연결 방법은 [MCP 출시 소식](/ko/blog/brew-mcp)과 [설정 문서](https://docs.brew.new/api-reference/mcp/overview)에서 설명해요.

저는 브랜드 지침이 머물 분명한 자리가 생긴 점이 마음에 들어요. 이메일이 어딘가 어색하면 문장 하나를 짚어서 고치고 다시 시도하면 돼요. 모델에게 “좀 더 브랜드에 맞게 해 주세요”라고 한 번 더 부탁하는 것보다 훨씬 쓸모 있는 대화예요.