소개
저는 제조업의 SCM 분야에서 일하고 있습니다. 업무를 하다 보면 국가별 수출통제나 관세정책이 바뀌었을 때 내용을 빠르게 확인해야 하는 경우가 있습니다.
관련 정보는 정부 공고와 기사 등에 흩어져 있고, 발표일과 시행일도 다릅니다. 단순히 뉴스를 모으는 것보다 다음 내용을 한 화면에서 확인하고 싶었습니다.
- 어떤 정책이 바뀌었는지
- 언제부터 영향을 주는지
- 어떤 원재료와 HS Code가 관련됐는지
- 공식 발표인지, 아직 확인이 필요한 정보인지
이 아이디어를 바탕으로 Codex와 함께 RegRadar라는 작은 프로젝트를 시작했습니다.
이번 작업에서 가장 의미 있었던 부분은 기능 자체보다 Skill, 플러그인, MCP가 각각 무엇인지 알게 되고 실제 프로젝트에 적용해 본 것이었습니다. 처음에는 Codex에 요구사항을 길게 전달하는 방식이었지만, 도구를 하나씩 사용하면서 프로젝트 범위와 결과물이 조금씩 정리됐습니다.
---
## 진행 방법
### 1. 먼저 작은 Mock 화면부터 만들었습니다
처음에는 인터넷 수집이나 실제 LLM 연결까지 한 번에 만들지 않았습니다.
Streamlit으로 다음 기능만 있는 Mock 화면부터 시작했습니다.
- 산업 선택
- 정책 문서 본문 입력
- Mock 분석 실행
- 정해진 데이터 구조로 결과 출력
이후 중국어 원문과 한국어 Mock 번역문을 함께 보여주고, 날짜·수치·HS Code가 번역 과정에서 바뀌지 않는지 확인하는 구조를 추가했습니다.
### 2. 실제로 사용한 핵심 프롬프트
프로젝트의 방향을 정하는 데 가장 중요했던 실제 프롬프트는 아래 내용이었습니다.
```text
중국발 수출통제 대응이 1순위라서 그것으로 시작해도됨.
회사 데이터를 입력하지않고 산업에 임팩트를 주는 항목에 대해 여기서 정리해줘야함.
LLM에는 실제 데이터는 허용하지않는다.
```
그리고 관세정책의 목적도 다음과 같이 전달했습니다.
```text
이 프로젝트는 중국 수출통제가 메인이긴하지만, 중국/미국 관세정책 탐지도 중요하다.
관세정책이 바뀌기전에 통관을 진행해서 관세를 절감해야해.
```
이 프롬프트를 기준으로 회사의 재고·공급사·가격 같은 실제 데이터는 제외하고, 공개된 정책과 산업 영향만 다루도록 범위를 정했습니다.
### 3. Skill을 이용해 생각을 정리했습니다
이번에 가장 많이 배운 부분입니다.
처음에는 Skill이 단순한 명령어라고 생각했습니다. 실제로 사용해 보니 특정 작업을 어떤 순서와 기준으로 진행할지 정리한 작업 방식에 가까웠습니다.
제가 실제로 사용한 Skill은 다음과 같습니다.
| Skill | 활용한 내용 |
|---|---|
| find-skills | 현재 프로젝트에 도움이 될 Skill을 찾아보는 데 사용 |
| grill-me / grilling | 애매한 요구사항을 한 질문씩 정리하고, Hermes를 단일 운영창구로 둘지 등의 결정을 구체화 |
| write-post | 지금까지의 대화와 프로젝트 기록을 모아 사례글 작성 |
특히 grilling 방식이 유용했습니다. 기능을 계속 추가하는 대신 “누가 최종 판단을 하는가?”, “비공식 자료는 어디까지 허용할 것인가?”처럼 한 번에 한 가지 결정을 정리할 수 있었습니다.
### 4. Product Design 플러그인으로 구조를 다시 살펴봤습니다
product-design:ideate를 사용해 현재 시스템 구조를 점검했습니다.
이 과정에서 화면에 많은 정보를 늘어놓는 것보다, 사용자가 먼저 확인해야 할 내용을 위로 올리는 것이 중요하다는 점을 확인했습니다. 이후 화면을 다음처럼 나눴습니다.
- 최신 규제 브리프
- 공식 소스 점검
- 문서 분석
- 오늘의 검토
- 분석 이력
플러그인을 사용했다고 완전히 새로운 제품이 만들어진 것은 아닙니다. 다만 이미 만든 기능을 사용자 흐름 기준으로 다시 생각하는 데 도움이 됐습니다.
### 5. MCP는 등록과 연결 구조를 익혔습니다
MCP는 Codex가 외부 도구와 연결되는 방식이라는 것을 이번에 처음 알게 됐습니다.
Smithery 라고하는 MCP를 등록하고 상태를 확인했습니다.
등록 후 enabled=true 상태까지 확인했습니다. 다만 로그인과 실제 기능 호출은 하지 않았고, RegRadar 데이터도 전송하지 않았습니다.
따라서 이번 프로젝트에서 MCP를 실제 정보수집에 사용했다고 볼 수는 없습니다. 이번에는 MCP를 어떻게 등록하고 연결 상태를 확인하는지 익힌 단계였습니다.
### 6. 현재 만들어진 결과
현재 RegRadar에서는 다음 내용을 확인할 수 있습니다.
- 공개 정책을 정리한 규제 브리프 화면
- 중국어 문서를 넣어보는 Mock 분석 화면
- 중국어 원문과 한국어 Mock 번역 결과
- 정책과 관련된 원재료·HS Code 표시
- 공식자료와 확인이 필요한 자료를 구분하기 위한 기본 규칙
- 프로젝트 기록과 후속 작업을 위한 핸드오프 문서
자동 크롤링, 실제 메일 전송, 클라우드 배포는 아직 진행하지 않았습니다. 중국어 번역도 현재는 제한된 용어집과 문장 패턴을 사용하는 Mock입니다.
---
## 결과와 배운 점
### 배운 점
이번 프로젝트를 통해 Codex는 단순히 코드를 작성하는 도구만은 아니라는 점을 알게 됐습니다.
- Skill은 작업하는 방법을 정리하는 데 도움이 됐습니다.
- 플러그인은 기존 작업을 다른 관점에서 검토하는 데 도움이 됐습니다.
- MCP는 외부 기능을 연결할 수 있는 구조라는 것을 알게 됐습니다.
가장 큰 변화는 더 많은 기능을 만든 것이 아니라, 무엇을 만들고 무엇을 아직 만들지 않을지를 구분할 수 있게 된 것입니다.
### 시행착오
처음에는 전기차 판매량, 보조금, 크롤링, 메일, 배포까지 계속 범위를 넓혔습니다. 그러다 보니 정작 어떤 결과가 필요한지 흐려졌습니다.
또 작업이 중간에 멈췄는데 이유를 바로 알 수 없는 경우도 있었습니다. 이후에는 작업이 중단되면 원인, 완료된 범위, 해결방법을 바로 알려달라는 원칙을 정했습니다. 이 원칙 덕분에 오류가 생겨도 어디서 다시 시작해야 하는지 확인하기 쉬워졌습니다.
### 나만의 팁
- 처음부터 완성형을 요청하기보다 Mock 범위를 명확히 적는 것이 좋았습니다.
- “해야 할 것”과 함께 “하지 말아야 할 것”을 프롬프트에 적는 것이 효과적이었습니다.
- 기능이 많아질 때는 grilling처럼 한 번에 한 가지 결정만 확인하는 방식이 도움이 됐습니다.
- Skill·플러그인·MCP는 이름만 나열하지 말고, 실제 사용한 것과 등록만 한 것을 구분해야 합니다.
### 앞으로의 계획
다음에는 자동화 범위를 바로 넓히기보다 현재 결과가 실제로 읽기 쉽고 필요한 정보를 빠르게 보여주는지 먼저 확인하려고 합니다.
그다음 공개자료 수집 방법과 LLM 연결을 검토할 예정입니다. 메일 전송과 클라우드 배포는 분석 결과가 충분히 안정된 뒤 진행하려고 합니다.
감사합니다.
