AI 프롬프트 모듈화 설계 — 반복 요청을 시스템으로 만드는 법

AI에게 매번 같은 말을 반복하고 있다면

AI와 대화한 내용을 정리할 때마다 이런 요청을 하고 있지 않은가?

"마크다운으로 정리해줘"
"SEO 고려해서 블로그용으로 만들어줘"
"개인정보 빠졌는지 확인해줘"
"파일명은 영문으로, 태그는 이렇게..."

매번 같은 규칙을 타이핑하는 건 시간 낭비다. 이 글에서는 AI 프롬프트를 모듈 단위로 분리하고, 용도별로 조합해서 쓰는 시스템을 설계하는 방법을 공유한다.

이 글에서 다루는 것

프롬프트 모듈화란 무엇인지
어떤 기준으로 모듈을 나누는지
실제 모듈 구조와 조합 예시
유지보수와 확장 전략

문제: 프롬프트 복붙 지옥

옵시디언에 메모를 저장하고, 블로그에도 올리고, 업무일지도 정리하려면 각각 다른 형태의 마크다운이 필요하다.

처음에는 용도별로 프롬프트를 하나씩 만든다. 옵시디언용, 블로그용, 업무용. 그런데 이 프롬프트들을 쓰다 보면 공통 규칙이 보인다.

"한국어로 작성, 기술 용어는 영문 유지"
"코드 블록에 언어 식별자 포함"
"가독성 좋게, 정확한 정보만"

이 공통 규칙이 프롬프트마다 중복된다. 하나를 수정하면 나머지도 전부 수정해야 하는 상황이 온다.

해결: 프롬프트를 모듈로 분리한다

소프트웨어 개발의 DRY 원칙(Don't Repeat Yourself)을 프롬프트에 적용한다. 공통 규칙은 한 곳에서 관리하고, 용도별 규칙만 따로 분리한다.

모듈 분류 기준

모듈은 세 가지 유형으로 나뉜다.

Base 모듈 — 모든 프롬프트에 공통으로 적용되는 규칙이다. 언어 설정, 출력 포맷, 가독성 기준, 톤 등이 여기에 들어간다. 어떤 조합을 만들든 Base는 반드시 포함된다.

용도별 모듈 — 특정 산출물 형태에 맞는 규칙이다. 옵시디언 메모는 제텔카스텐 구조와 YAML frontmatter가 필요하고, 블로그는 SEO와 독자 친화적 재구성이 필요하다. 업무일지는 티켓 번호와 요청자 정보가 필요하다. 각각 별도 모듈로 관리한다.

횡단관심사 모듈 — 여러 용도에 걸쳐 조건부로 적용되는 규칙이다. 예를 들어 보안 체크(개인정보·회사정보 필터)는 "공개 목적 산출물이 포함될 때만" 적용된다. 개인 메모에는 불필요하지만 블로그에는 필수다.

실제 모듈 구조

이 시스템에서 사용하는 모듈은 5개다.

| 모듈 | 역할 | 포함 내용 | |---|---|---| | Base | 공통 규칙 | 언어(한국어+영문 기술용어), 출력 포맷, 정확성, 가독성, 톤 | | Obsidian | 옵시디언 메모 | 제텔카스텐 구조, YAML, 원자성, 위키링크, 폴더 추천 | | Blog | 블로그 글 | SEO, frontmatter, 콘텐츠 재구성, 톤 조절 | | Work | 업무일지 | 티켓 기반 구조, 업무 유형별 섹션 | | Security | 보안 필터 | 개인/회사 정보 식별, 익명화, 검수 체크리스트 |

모듈을 조합하는 법

모듈을 조합하면 용도별 프롬프트가 된다. 자주 쓰는 조합 5개를 미리 합쳐서 독립 프롬프트로 만들어두면, 실사용 시에는 복사 한 번으로 끝난다.

| 용도 | 조합 | 산출물 | |---|---|---| | 메모 정리 | Base + Obsidian + Security | 옵시디언 메모 1개 이상 | | 메모 + 블로그 | Base + Obsidian + Blog + Security | 메모 1개+ & 블로그 1개 | | 업무 기록 | Base + Work | 업무일지 1개 | | 업무 + 블로그 | Base + Work + Blog + Security | 업무 1개 & 블로그 1개 | | 기존 글 변환 | Base + Blog + Security | 블로그 1개 |

주목할 점은 보안 모듈의 적용 조건이다. 블로그가 포함되면 보안 모듈이 들어가고, 개인 보관 전용이면 빠진다. 이렇게 조건부로 조합할 수 있는 것이 모듈 분리의 장점이다.

각 모듈에 넣을 내용

Base 모듈 핵심

- 언어: 한국어 출력, 기술 용어 영문 유지
- 포맷: 파일 제공 가능하면 .md, 아니면 코드블록 + 파일명 안내
- 정확성: 불확실하면 "모른다"고 명시
- 가독성: 짧은 문단, 핵심 먼저, 빈 섹션 금지
- 톤: 기본은 깔끔하고 명확, 콘텐츠 유형에 따라 조절

Blog 모듈 핵심

블로그 모듈에서 가장 중요한 건 재구성 규칙이다. AI 대화 내용을 그대로 옮기면 블로그 글이 아니라 대화 로그가 된다. 콘텐츠 유형별로 구조를 지정해야 한다.

기술/트러블슈팅: 문제 → 환경 → 원인 → 해결 → 핵심 교훈
튜토리얼: 목표 → 사전 준비 → 단계별 가이드 → 주의사항 → 요약
리뷰: 개요 → 경험 → 장단점 → 결론
일상/생각: 맥락 → 본문 → 마무리
레시피: 소개 → 재료 → 과정 → 팁

SEO 규칙도 프롬프트에 넣어두면 매번 신경 쓸 필요가 없다. 제목 60자 이내, description 120~155자, 주요 키워드를 제목·첫 문단·H2에 자연스럽게 배치하는 정도면 충분하다.

Security 모듈 핵심

보안 모듈은 두 단계로 동작한다.

1단계: 체크리스트 기반 스캔 — 실명, 회사명, 내부 URL, IP, 파일 경로, DB 테이블명, API 키 등을 체크한다.

2단계: 패턴 기반 탐지 — 체크리스트에 없더라도 "민감해 보이는" 패턴을 AI가 능동적으로 감지한다. 예를 들어 공개 사이트가 아닌 URL 패턴, IP 주소 형태, 한국어 이름 패턴 등이다.

그리고 블로그 파일 끝에 HTML 주석으로 최종 검수 체크리스트를 넣어둔다. AI가 아무리 잘 걸러도 사람이 최종 확인하는 단계는 반드시 필요하다.

유지보수 워크플로우

모듈 하나를 수정하면, 해당 모듈을 사용하는 조합형 프롬프트만 업데이트하면 된다.

Module-Blog에 series 필드 추가
  → Blog을 쓰는 조합 3개만 수정
  → Obsidian만 쓰는 조합 2개는 영향 없음

수정 자체도 AI에게 맡길 수 있다. "이 모듈이 변경되었으니 해당 조합형을 업데이트해줘"라고 요청하면 된다.

새로운 조합이 필요할 때도 기존 모듈로 대부분 커버된다. 예를 들어 "레시피를 정리하면서 블로그에도 올리고 싶다"는 시나리오는 Base + Obsidian + Blog + Security 조합에 상황별 지시문만 한 줄 추가하면 된다.

설계할 때 신경 쓸 점

모듈 경계를 명확하게 나눠야 한다. "이 규칙이 Base에 들어가야 하나, Blog에 들어가야 하나?" 판단 기준은 단순하다. 모든 산출물에 적용되면 Base, 특정 형태에만 적용되면 용도별 모듈, 조건부로 적용되면 횡단관심사다.

조합형 프롬프트의 토큰 길이를 고려해야 한다. 모듈을 전부 합치면 프롬프트가 길어진다. AI의 context window를 고려하여 불필요한 설명은 줄이고, 규칙은 간결하게 작성한다.

완벽하게 만들고 시작하려 하지 않는다. 실제로 사용하면서 빠진 규칙, 불필요한 규칙, 모순되는 규칙이 보인다. 그때마다 해당 모듈만 수정하면 되니, 일단 만들고 쓰면서 개선하는 게 낫다.

정리

AI 프롬프트도 소프트웨어처럼 설계할 수 있다. 반복되는 규칙을 모듈로 분리하고, 용도에 따라 조합하면 유지보수가 쉬워지고, 새로운 요구사항에도 유연하게 대응할 수 있다.

핵심은 세 가지다:

공통 규칙은 Base 모듈 하나에서 관리
용도별 규칙과 횡단관심사를 분리
자주 쓰는 조합은 독립 프롬프트로 미리 합쳐두기