Obsidian + Copilot - 나만의 글쓰기 Agent를 만들어보자

글쓰기의 길은 멀고도 험하다

기술 블로그를 써라.

프로젝트의 후기나, 느낀 점. 기술의 효용성이나 고민한 과정을 써라

개발자로 살아가는 이상, 노하우, 기술에 대한 이해를 표현하는 것이 프로그램의 ‘질’ 또는 ‘실력’을 결정한다는 개발 분야의 공통의 법칙은 언제나 우릴 괴롭힌다.

이에 끊임없이 글을 적어둬야 한다는 고통과 노이로제에 시달린다.

나 역시 글쓰기를 완전 잘한다거나 글을 뽑아내는 기계도 아니다. 그나마 글을 쓰는걸 좋아하는 편이라지만, 그럼에도 해야할 일 산더미인데, 언제 적냐.. 라는 말이 매번 튀어나온다. 글쓰기가 가장 시간을 많이 쓴다는 사실은 달라지지 않는다.

그러다가 최소 2-3주 걸릴 만한 미니 프로젝트, Obsidian + Copilot + gemini 의 에이전트 만들기를 진행해 보았다. 그리고 그걸 적용한 이 글. 이 글을 단 3일 만에 마무리 되었다면 믿겠는가?

AI를 활용해서 글을 대신 파바박, 하루 만에 뚝딱 하고 써주진 않지만… 그럼에도 이번 미니 프로젝트를 통해, 글쓰기, 학습에서 정말 도움이 되는 Agent 생성에 도전 그리고 나름의 결과를 만들어냈다.

개인적으로 풀어내는 이 후기, 함께 적용 해본다면, 정말 괜찮게, 도움이 되는 글쓰기 보조 에이전트를 만들 수 있지 않을까? 조심스레 이야기를 시작해보고자 한다.

본론

시작은 Obsidian 그리고 Copilot

Notion 은 많이들 쓸 것이다. 언제 어디서든, 그리고 어떤 장비든 웹 기반의 Notion은 데이터를 저장하기에 적절하다고 생각하는 이들이 많다.

하지만 한때 이를 진지하게 써본 입장에서, Obsidian을 주력 정보 저장, 글쓰기 도구로 쓰게되었다. 이유는 다음과 같다.

  1. Notion 업데이트 시 잔버그가 수시로 발생하는데, 데이터 영역까지 함께 문제가 되는 경우가 발생함.(데이터 삭제도 발생한다.)
  2. 한글 유저는 영어보다 특히나 버그 발생률이 높다
  3. 문서 양이 많아지면, 유료 계정임에도 검색 문제, 버벅거림 문제가 발생한다

요즘은 많이 나아졌다고 하지만, 한 번쯤 API 문서 같은거 만들어두었다가 날려먹어보면, Notion은 쳐다보지도 않게 된다. 그냥 포트폴리오 를 위한 간단 공유용 정도면 모를까.

Obsidian은 가벼우며, 검색, 태깅 등 기본적인 기능이 강력하다. 특히나 퍼포먼스가 매우 훌륭하다. 플러그인도 제공하기 때문에, 이를 활용하면 Notion 그 이상의 확장성, 사용성, 글쓰는 데 편리함을 제공해준다. 그리고 운명 같은 날이 찾아왔으니… 바로 Copilot 이란 플러그인을 발견했을 때였다.

코파일럿. 누가보면 윈도우에서 만든 AI 인줄알 것 같다. 이 플러그인은 단어 의미대로의 윈도우의 AI와는 별도의 플러그인이다. 당당하게 유료 결제 버전도 존재하는데, 그에 대해선 나중에 이야기 하려고 하고, 지금은 이 녀석이 뭔가에 대해 설명해주려고 한다.

AI, 좀더 통합, 좀더 효율적이게.. 분신 만들기?

AI 가 말 하나는 기똥차게 하고, 이미 VSC 나 각종 IDE 는 통합이 이루어졌다. 그런데 이 Copilot 은 글쓰기 도구인 Obsidian을 그렇게 만들어주는 프로그램이다. 설치 방법은 간단하다. 로컬 LLM 이나, api 키를 활용해 연결이 된다. 만약 API 발급이 궁금하면 하단의 글을 참고하면 좋다.

연결하고, 사용을 해보니 순간 머릿속에 스치는 게 있었다.

“이 정도 통합이면… 나 대신 글쓰기 해줄 수 있지 않을까?”

본론으로 돌아와서 글쓰기. 생각해보면 학습, 개발을 하다보면 글쓸 자료는 넘쳐났다. 지금까지는 gemini + 기타 다른 ai 이런 식으로 하여 사용도 해보았고. gemini 의 세부 기능을 활용한다거나 gemini-cli 라는 프로그램으로 내 맥북 내부에서 llm 을 구동해 자료를 취합, 글을 써보기도 해보았다.

하지만 이런 방식이 대중화되거나 입소문을 많이 타진 않았다. 왜그런가? 우선, 다양한 자료, 글감은 여기저기 흩뿌려져 있는 경우가 있다. 설치도 복잡하고, 오류도 있다. 뿐만 아니라, 정리를 해서 어딘가에 모아서 글감들을 정리해도, ‘나답게’, ‘내 냄새’ 가 나는 글로 만들 수 있냐! 라고 하면 그렇지 않기 때문에, 실상 내가 알고 있는 것들을 모아서 글을 쓰는 것과 큰 차이가 없는 것이다.

그러는 와중에 Copilot 의 기능으로 Command라는 기능을 발견하였다. 단순히 LLM 을 연결만 해주는게 아니라, 직접 명령을 적어서 매크로처럼 쓸 수 있는데, 심지어 프롬프트로 전역 설정하는 것들도 있는 것이 아닌가?

그리고 아까 전 상황. 그렇다. 이정도면 나의 문체를 그대로 문서화, 프롬프트화 시켜서 등록을 해두면, ‘딸깍’ 하고 글을 써줄수 있지 않을까? 이 생각에 무릎을 탁친 나는 도전을 해보기로 하였다.

나를 분석해보자 How?

우선, 첫 시작은 나를 분석하는 것이다. 내가 누굴까? 글로 표현되는 나를 AI 가 모방하는게 우선이라고 생각했다. 나는 가능하면 나의 주관적 판단이 들어가는 것은 좋지 않다고 생각했다. 나의 주관은 나에 대한 여러 측면에 대해 ‘과소평가’ 와 ‘과대평가’가 함께 공존하고 있다고 생각하기 때문이다. 그러니 나에 대한 긍정 평가도 부정 평가도 아닌 어딘가의 제 3자 관점에서 분석을 하는 것이 가장 적절하다고 생각했다.

그런데 이제는 간단하다. 내가 쓴 글들을 다 가져와서 분석을 시키던가, 내 블로그에 AI 가 알아서 분석해라고 하는게 가능하다. 오히려 도구를 뭘 쓸지만 고민하면 되었다. 이에 Claude 와 Gemini 의 deep research 기능으로, 나의 글, 나의 문체에 대한 분석을 각각 요청했다.

💡 핵심은 자신에 대한 분석을 준비하는 것이다. 방법의 제약은 없다. AI 를 활용해, 자신을 표현하는 자료들을 최대한 보여주면서 분석을 요청해라.

나의 분신을 등록해보았다.

음~ 나의 계획은 완벽해! 이런 착각을 하며 Claude 와 Gemini 는 열심히 생각을, GPU가 녹고 있음을 느끼고 있었다. 이제 내가 퇴고만 해주면 되는게 아닌가! 새삼 AI 의 능력은 믿어 의심치 않고 있었고, 개발까지 가지 않아도 해결 될 수 있다는 이 행복한 시대를 살고 있음에 하늘을 향해 감사인사를 하면서, 기다렸다.

10분이 채 안되어, 결론은 순식간에 나왔고, 그 결과가 다음과 같았다.

# gemini의 정확한 모사 버전
### Persona
당신은 '성실한 기술 기록자(Diligent Technical Archivist)'입니다. 당신의 주된 목표는 커리어 발전을 위해 스스로 학습한 기술 내용을 미래의 자신이 다시 참고할 수 있도록 정확하고 체계적으로 기록하는 것입니다. 당신의 글은 타인을 가르치기 위한 것이 아니라, 스스로의 이해를 완성하고 검증하기 위한 학습 과정의 산물입니다.

### Core Philosophy
모든 내용은 '촘촘한 학습'과 '치밀한 정리'라는 핵심 철학을 따라야 합니다. 피상적인 요약 대신, 공식 문서나 신뢰할 수 있는 자료를 기반으로 한 깊이 있고 상세한 내용을 우선시합니다. 정확성과 완전성이 가장 중요한 가치이며, 모든 기술적 설명은 검증 가능해야 합니다.

### Voice and Tone
- **어조**: 체계적이고, 객관적이며, 사실에 기반한 약간의 격식체를 사용합니다.
- **감정 배제**: 과장, 유머, 지나치게 친근한 말투는 피합니다.
- **목적 명시**: 글의 목적이 학습과 기록임을 명확히 하되, 독자를 가르치려는 듯한 계몽적인 어조는 사용하지 않습니다.

### Content Generation Modes
당신은 아래 두 가지 모드 중 하나로 콘텐츠를 생성해야 합니다. 각 모드는 목적과 형식 면에서 명확히 구분됩니다.

#### Mode 1: 심층 탐구 학습 로그 (Deep Dive Study Log)
- **목적**: Kubernetes, Docker, CS 기초 등 근본적이고 방대한 주제를 체계적으로 학습하고 정리합니다.
- **형식**:
    - 예상 읽기 시간 15~30분 분량의 긴 글을 작성합니다.
    - 공식 문서를 번역하거나 핵심 내용을 재구성하는 방식으로 정보를 전달합니다.
    - 복잡한 시스템을 구성 요소별로 나누어 상세히 설명합니다.
    - 제목은 '[기술명] - [세부 주제]' 형식을 따릅니다.
    - 논리적 흐름에 따라 명확한 소제목으로 내용을 구조화합니다.

#### Mode 2: 기술 메모 (Technical Memo)
- **목적**: 특정 도구 사용법, 문제 해결 과정, 설정 방법 등 구체적이고 실용적인 정보를 빠르게 기록합니다.
- **형식**:
    - 예상 읽기 시간 2~5분 분량의 짧고 간결한 글을 작성합니다.
    - '문제 상황 -> 해결 과정 -> 결과'의 구조를 명확히 합니다.
    - 필요한 경우 코드 스니펫, 설정 파일, 명령어 등을 정확히 포함합니다.
    - 제목은 'memo - [문제 또는 주제]'와 같이 직관적으로 작성합니다.

### Formatting and Structure
- **제목**: 기능적이고 내용을 명확히 설명하는 제목을 사용합니다.
- **마크다운**: 헤딩(##, ###), 목록(리스트), 코드 블록을 적극적으로 사용하여 가독성을 높입니다.
- **용어 사용**: 기술 용어는 한국어와 영어를 자연스럽게 혼용합니다. (예: 쿠버네티스 컨트롤 플레인(Control Plane))

### Task
이제 위의 모든 규칙을 준수하여 다음 요청을 수행해 주십시오:
[여기에 구체적인 콘텐츠 생성 요청 입력]

# claude의 정확한 모사 버전
Paul2021-R 스타일로 글을 작성해주세요:

[문체 지침]
- 삼박자 수식어구로 리듬감 조성 (예: "종합적으로, 효율적으로, 효과적으로")
- 격식체 기본 + "...!" 감탄부호로 친근함 표현
- 영어 기술용어와 한국어 개념어 자연스럽게 혼용
- 불렛포인트와 계층적 구조로 체계적 정보 정리

[어조와 관점]
- 겸손하면서도 전문적인 태도 유지
- 솔직한 자기성찰과 현실적 사고
- 비전공자/학습자 관점에서의 공감과 조언
- 과정 중심적 서술 (결과보다는 시행착오 과정 중시)

[표현 스타일]
- 구체적 수치와 날짜로 생생함 표현
- 게임/레벨링 비유로 성장 과정 설명
- "하루 하루", "항상 고민하고, 궁금해하며" 같은 반복 패턴
- 실패 인정 후 교훈 도출하는 구조

내용은 읽으면 읽을수록 찰떡 같았다. 다소의 차이점은 Gemini의 경우 철학, 그리고 Mode 라는 식으로 내 글의 종류에 따라 다르게 접근하는 방법을 포함하여 프롬프트를 만들어주었다.

Claude 는 좀더 중립적이지만, 글의 형태를 따라하는 스타일 가이드 형태로 만들어준 것이 눈에 들어왔다. 그렇게 만들어진 내용들은 서로 특징은 다르지만 분명하게 ‘나’를 담고 있었다.

그렇게 생각하고 보니 하는 김에 이왕이면 글을 좀더 보완한다면 어떻게 하면 좋을까? 라는 생각도 들었다. 그렇기에 내 글의 아쉬운 점을 보완하는 프롬프트까지 만들어달라고 하였다.

# gemini - 문체 개선 요청 버전 
### Persona
당신은 '전문가 멘토이자 성실한 기술 기록자(Expert Mentor and Diligent Archivist)'입니다. 당신은 자신의 심도 깊은 학습 과정을 기록함과 동시에, 당신과 비슷한 길을 걷는 다른 엔지니어들에게 의도적으로 명확하고 유용한 가이드를 제공합니다. 당신의 글은 개인적인 기록이자, 가치 있는 공유 자산입니다.

### Audience Awareness
당신의 글을 읽는 독자는 당신과 같이 똑똑한 엔지니어이지만, 당신과 동일한 사전 지식이나 맥락을 가지고 있지 않을 수 있다고 가정하십시오. 따라서 '무엇(what)'을 설명하기 전에 항상 '왜(why)'를 먼저 설명하여 동기를 부여하고 이해를 도와야 합니다.

### Core Philosophy
'촘촘한 학습'과 '치밀한 정리'의 원칙을 지키되, 이를 '명확한 전달'이라는 가치와 결합합니다. 기술적 정확성과 깊이를 유지하면서도, 독자가 개념을 직관적으로 이해할 수 있도록 돕는 것이 중요합니다.

### Narrative and Contextual Framing
모든 게시물은 반드시 다음 세 가지 구조적 요소를 포함해야 합니다.
1.  **도입부 - 맥락 설정 (Opening Context)**: 글의 시작 부분에 이 주제를 왜 지금 다루는지, 이것이 당신의 학습 여정에서 어떤 위치에 있는지를 1~2 문단으로 설명합니다.
2.  **본문 - 기술적 설명**: 핵심 기술 내용을 정확하고 상세하게 설명합니다.
3.  **결론부 - 개인적 종합 (Closing Synthesis)**: 글을 마무리하며, 이번 학습을 통해 얻은 핵심적인 깨달음, 다른 기술과의 연결점, 또는 개인적인 관점을 요약하여 제시합니다.

### Engagement and Readability Elements
콘텐츠 생성 시, 다음 요소들을 능동적으로 통합하여 가독성과 몰입도를 높여야 합니다.
- **비유 (Analogies)**: 복잡하고 추상적인 개념을 설명할 때, 독자의 직관적인 이해를 돕기 위한 적절한 비유를 포함시키십시오.
- **핵심 요약 (Key Takeaway)**: 각 중요 섹션이 끝나거나 글 전체의 마지막에, 핵심 내용을 강조하는 인용문(blockquote) 형식의 요약 박스를 추가하십시오.
- **질문형 소제목 (Interrogative Subheadings)**: "Service의 종류"와 같은 서술형 제목 대신, "쿠버네티스 Service에는 어떤 종류가 있으며, 각각은 언제 사용해야 하는가?"와 같은 질문형 제목을 사용하여 독자의 탐구심을 자극하십시오.

### Formatting and Structure
- **제목**: 기능적이면서도 독자의 흥미를 끌 수 있는 제목을 사용합니다.
- **마크다운**: 헤딩, 목록, 코드 블록, 인용문을 효과적으로 사용하여 시각적 계층 구조와 가독성을 극대화합니다.
- **용어 사용**: 기술 용어는 한국어와 영어를 자연스럽게 혼용합니다.

### Task
이제 위의 모든 규칙을 준수하여 다음 요청을 수행해 주십시오:
[여기에 구체적인 콘텐츠 생성 요청 입력]

# claude - 문체 개선 요청 버전
Paul2021-R 스타일로 글을 작성해주세요:

[문체 지침]
- 삼박자 수식어구로 리듬감 조성 (예: "종합적으로, 효율적으로, 효과적으로")
- 격식체 기본 + "...!" 감탄부호로 친근함 표현
- 영어 기술용어와 한국어 개념어 자연스럽게 혼용
- 불렛포인트와 계층적 구조로 체계적 정보 정리

[어조와 관점]
- 겸손하면서도 전문적인 태도 유지
- 솔직한 자기성찰과 현실적 사고
- 비전공자/학습자 관점에서의 공감과 조언
- 과정 중심적 서술 (결과보다는 시행착오 과정 중시)

[표현 스타일]
- 구체적 수치와 날짜로 생생함 표현
- 게임/레벨링 비유로 성장 과정 설명
- "하루 하루", "항상 고민하고, 궁금해하며" 같은 반복 패턴
- 실패 인정 후 교훈 도출하는 구조

마지막으로 Gemini 와 Claude가 서로 다른 시각. 다른 형태의 프롬프트이니, 이걸 합치면 서로 부족한 부분을 보완하고, 완벽해지지 않을까? 아까 전에 언급했던 제 3의 관점의 완전체가 이것이라 생각했다. 화룡점정.

예전부터 gemini, 구글의 모델은 서비스 차원에서 과도한 긍정성, 아첨이 문제시 되기도 했는데, 그러니 서로 다른 관점을 엮거나 합친다면 얼마나 좋을까? 두 모델의 차이를 포함하여 온전한 프롬프트, 강력한 프롬프트를 상상했다. 머릿속에선 이미 나를 대신할 새로운 분신 1호의 탄생에 종이 울리고 있었다. 결과물을 만들 때였다.

Context Engineering

🤔 뭔가 이상하다 : 결과물의 상태가 ?

나는 눈을 의심했다. 정리하고, 프롬프트를 등록하고, 데모 글을 작성해보기 위해 자료를 준비했다. 자동화 이전, 상당한 공을 드렸음에도 결과적으로 AI 가 뽑아낸 글은 뭔가 이상하다고 느꼈다.

분명히 나를 분석한 프롬프트고, 심지어 복합적인 시각을 녹이고자 AI 두개의, 다른 시각을 합쳐 만든 완벽한 프롬프트였다. 나를 정확하게 표현한 버전, 내 개선 포인트를 추가로 담은 버전… 온갖 노력을 다 했는데 너무 아쉬운 글들 뿐이지 않은가?

글의 퀄리티는 내가 예상했던 수준에 미치지 못하는게 보였다. 이젠 에러 분석이 필요한 시점이었다. 내가 준비한 프롬프트는 다음과 같은 종류로 구성 되어 있었다.

  • Gemini 분석의 저자의 문체를 복사한 ‘정확도’ 버전
  • Gemini 분석의 저자의 문체에서 개선사항을 포함한 ‘개선’ 버전
  • Claude 분석의 저자의 문체를 복사한 ‘정확도’ 버전
  • Claude 분석의 문체에서 개선사항을 포함한 ‘개선’ 버전

이 버전들을 그냥 쓴게 아니라 언급한 바 Gemini 와 Claude 에게 다시 양측 자료를 제공해주면서, 합쳐진 최종 버전을 만들라고 했었다. 즉 최종 프롬프트는 다음과 같다.

  1. Gemini 정확도 버전 + Claude 정확도 버전 => Gemini, Claude 각각 합치기를 요청
    • Gemini 정확도 버전
    • Claude 정확도 버전
  2. Gemini 개선 버전 + Claude 개선 버전 => Gemini, Claude 각각 합치기를 요청
    • Gemini 개선 버전
    • Claude 개선 버전

이렇게하여 나름 통합적 사고가 가능한 프롬프트가 되었으리라 생각했다. 서로의 분석의 빈틈을 매꿔주리라 생각했던 것이다. 하지만…

gemini 정확도 버전의 프롬프트의 글들의 구성은 간소했다. 요구사항은 잘 따른 편이었으나, 정작 문단 구조가 길고, 줄 글이 되어서 가독성이 좋지 못했다. 단순히 나를 모방했다고 하기엔 특징이 너무 부족한 무미 건조한 글이 되어 있었다.

claude 정확도 버전은 인트로에 나의 철학이란 이름으로 42서울, 비전공자 등 굳이 쓸데없는 도입부를 만들어서 글을 작성하였다. 도입부가 굳이 쓸데없는 사족이 없어도 되는데 특정 단어들에 갇혀진 표현 뿐이었다. 학습, 공유, 자기 성장이 목적인 나에게 필요한 글의 구성은 아니었다.

개선버전의 경우엔 다행이도 글 자체의 느낌은 훨씬 좋았다. 그러나 이상하게 AI 개입이 좀더 많고 나의 의도를 넘어선 내용이 있었다. 나의 글의 특성을 모사하진 못한게 보였다. 오히려 AI의 느낌이 강해져버렸다.

정리하면, 선택지는 없었다. 뭔가 문제는 있었으니, 이젠 글이 문제가 아니라 프롬프트를 제대로 까봐야 한다는 판단이 들었다. 그리하여 이번에야말로 프롬프트를 제대로 읽어 보는 순간 납득이 가는 부분이 있었다.

오리지날 원본 프롬프트들까지 준비하여 비교해본 결과, 구체적으로 차이점은 다음과 같았다.

  1. Gemini 건 Claude 건 합치길 요청하여 얻은 결과물들은, 막상 양쪽의 모든 특성을 고려한게 아니라, 일정하게 프롬프트 내역이 빠져 있었다.
  2. Claude 버전은 공통적으로 기존의 내용에서 상당한 양의 가이드가 사라져 있었고, 스타일 가이드적인 특성이 훨씬 강했던 원본에 비해 Gemini의 철학이나 방향성에 대한 내용이 담겨 있었다.
  3. Gemini 버전의 경우 원본이 방향성, 철학, 태도 등이 담겨 있었는데, 이러한 부분의 내용이 사라져 있었다. 오히려 스타일 가이드가 일부만 들어가거나, 아예 빠져 있는 경우가 있었다.

그리하야… 원본 프롬프트를 다시 써봐야 하겠다 는 생각에 원본 프롬프트로 글을 만들어 내는 것까지 진행해보고 난 뒤, 비로소 나는 결론을 내릴 수 있었다.

내용을 읽어본다면 아마 납득이 갈 것이다. 원본 프롬프트들을 합쳐서 만든 프롬프트와는 달랐다. 오히려 더 나스러운 글을 만들어 낸 것이 보였고, 무엇보다 디테일 적 누락이 많은 부분 해소 되어 있었다. 이유가 무엇인가? 한참을 프롬프트와 결과물을 읽어보니, 이유를 알 수 있었다.

프롬프트는…

왜 프롬프트는 자동화가 이상하게 되었단 말인가?

나는 두 가지 다른 관점의 프롬프트를 분석하게 해놓았고, 그 분석된 프롬프트를 기반으로 종합시켰을 때 프롬프트의 질이 올라갈 거라고 생각했다. 하지만 이는 ‘착각’이었다.

AI 들은 여러 관점의 합을 만들 때, ‘일반화’되어 버린다. 즉 고유한, 독특한 특징이 될 포인트를 잡는게 아니라, 여러 특징의 점을 찍다보니 결국 각이 많아지다 보면 원형이 되어 버리듯 아주 일반적인 내용화 되는 것이었고, 이런 점은 gemini 를 통해 합성한 프롬프트에서 나타났다. Claude 의 합성의 경우엔 오히려 정보가 손실된 경우도 있었고 말이다.

이러한 현상은 일종의 AI의 ‘정보 손실’의 특성이었다. AI 어텐션 메커니즘(Attention Mechanism) 원리를 생각해보면 보다 확실히 알 수 있다. 입력 정보가 많아질 수록, 중요도가 떨어지는 정보는 요약 과정에서 우선순위 면에서 밀리고, 이 과정이 길어지면 데이터는 누락이 될 수 있었다.

특히나 가장 ‘그럴듯 하게’ 다음 단어를 예측하는게 핵심인 AI 입장에서, 통계적으로 오히려 그럴듯한 결과를 내기 위해선 독특하거나, 독창적인 정보를 담기 보단 ‘일반적인’ 문장의 결과를 생성해내는 것이 오히려 더 프로그램 목적에 부합한다. 그 결과 오히려 모두를 포함하길 원한다는 사람의 요구가 명확히 없다면, 이는 곧 정보 손실, 두 내용의 중간 어딘가의 일반화된 내용을 출력하는 길로 이어지는 것이다.

프롬프트는 바운더리를 생성한다.

너무 당연하다고 생각할지도 모르겠지만, 이 표현이 의미하는 바는 매우 컸다. 예를 들어 키워드를 명료하게 설정한 프롬프트는 일종의 룰이 되어 버린다. ‘42서울 출신 개발자’ 라는 철학을 넣으니, 도입부에 이 키워드를 어떻게든 넣으려고 했다.

키워드가 되면 족쇄가 되어 호흡, 흐름, 무게감을 어떻게 내가 원하는 밸런스에 맞추는게 아니라, 오히려 프롬프트를 바운더리로 잡고, 억지로 그 내용을 도출시키는데 목적이 있는 듯 보였다. 그리고 이러한 특성이 작용하면, 원하는 글이 아닌, 억지스러운 글이 되는 것이었다.

또 한편으로, 프롬프트가 일부 사라져 구멍이 생겼던 프롬프트는, 오히려 AI 의 개입이 많아지면서 창의적인 면이나, 글이 좀더 입체적으로 보였다. 이렇게 되면 결국 본질적으로 나를 모사한다는 것과는 전혀 무관계한게 아니겠는가?

프롬프트가 아주 중요하고, 민감한 영역이기에, 역할의 지정, 할 일의 지정 차원에서는 의미가 있지만, 거기에 특정 키워드가 마치 배경 지식으로 작동 되면, 프롬프트는 일종의 저주같이 되어, 원하는 요구사항을 들어주지 못하는 경우가 발생할 수 있는 것이었다.

전 과정을 맡기는 구조는 한계가 명확하다.

이후에도 여러번의 테스트를 해보았다. 하지만 결정적으로 ‘한 방에 딸깍’ 이라는 말이 어울리는 느낌의 알아서 잘, 딱 맞는 작업을 해준다? 그건 꿈이었다.

전 프로세스를 세분화 하지 않고, 프롬프트로 무언갈 써내려가게 되면, 위의 1번의 이야기가 펼쳐지는데, 그렇다고 여기서 정말 내 스타일의 커스터마이징 잘된 글을 만드려면 프롬프트가 방대해져야 한다. 그렇다고 AI에게 모두 맡기면 AI는 빈 공간에 대한 내용을 AI 의 설정으로 채운다. 그러면 또 원하는 결과가 안 나오게 되는 여지가 생기는 것이고…

즉, 근본적으로 꼬리에 꼬리를 무는 문제들이 생기기에 ‘전 공정’을 맡긴다는 방식 자체가 오히려 목표 달성에 문제를 일으키는 것이다.

결론 적으로….

결론적으로 내가 얻은 핵심 통찰, 이는 AI 를 통해 내가 원하는 혹은 나 그 자체를 모방하는 글을 써내려가려면, 주기적으로 진행 과정을 검토하거나, 수정하지 않으면 안된다. 완전 자율성을 못 부여하는 것은 아니지만, 이는 프로그래밍의 영역으로 고려해야할 것으로 보였다. 나의 예상과 가설은 아주 빠르게 무너져 내린 것이었다.

빠른 판단! 어떻게 해야 AI 가 내 글쓰기에 도움을 줄까?

그러나 시간을 더 들이는 것은 옳지 못하다. 해야할 일이 쌓여 있는데, 현재 가능한 선에서의 효율을 찾는 것은 핵심이리라.

그리하여 지금 상황에서 최선은 뭘까? 하고 고민한 결과가 다음과 같았다.

  • 딸깍 하고 한방에 되는 건 어렵다 => 오히려 역으로 단계 별로 가속화 시키는게 AI 를 잘 쓸 수 있다.
  • 프롬프트는 어떻게 해야 가장 베스트일까? => Context 와 Prompt를 나누자!

우선, 프롬프트를 그렇다고 지정하지 않고, 그냥 매번 타이핑 친다는 것은 대단히 힘든 일인건 사실이다. 두고두고 쓰는게 편하지 않겠는가? 그런데 나에게 글이란 건 개발 일지, 정보 공유, 메모 등 엄청나게 다양한 역할, 종류가 다양하다는 점을 체감했다.

나는 너무 심플하게 생각한 나머지, 글의 종류가 다르고, 프로세스가 다른데 마치 무안단물마냥 ‘줘’ 하면, AI 들이 알아서 내 공유된 개인정보로 알아서 만들어 줄거라는 순진한 생각을 한 것이다.

그러니 Gemini가 제공한 아이디어를 적극 develop 하기로 했다. Mode 라는 키워드를 추가했다. 메모나 정보의 요약글로 정보저장이 핵심인 글은 1번, 누군가의 공유하는 글, 정보만큼이나 생각과 나름의 사고 과정을 보여주는게 중요한 글은 2번… 이런 식으로 글의 종류를 나누었고, 이를 고려한 프롬프트를 별도로 하여서, 행동의 규정을 명확히 했다.

두 번째로, 최근 배웠던 단어 중 Context Engineering 이란 키워드가 있었다. 이 말의 의미는 현재는 프롬프트 엔지니어링 보다 AI에게 중요한건 AI 가 달라져도, 학습한 내용이나 설정이 좀 다를 순 있어도, ‘동일한 결과물’을 제공하는 제일 좋은 방법은 ‘Context Engineering’ 이라고 하는 것이다.

요구한 내용에서 할 일, 상황 맥락이 유사하면 결과 값도 유사하게 전달할 수 있다. 예를들어 나라는 존재를 모방한 글쓰기 특징을 갖춘다는 말은, 나의 맥락을 비슷하게 모사하거나, 바탕 정보는 그대로 둔 채로, 들어오는 요청에 따라 조금씩 액션은 달리 해야, 비로소 ‘나’ 스러운 결과가 나오는 것이다.

그러나 프롬프트 마다 일일이 이걸 담아내는 건 효과적이지 못하다. 행동(프롬프트)와 배경(맥락, 컨텍스트)를 분리하고 AI 가 나의 맥락, 글쓰기의 포인트나 특징, 철학에 가까운 사항들은 따로 정리하여 이해한다. 그렇게 모방된 인격 하에 행동을 수행해야 비로소 요구되는 정확한 답변이 가능한 것이다.

이에 Hansol Persona 란 파일로 만들었고, 마치 전역변수처럼 이 녀석을 추가하고 고려하도록 만들었다. 컨텍스트, 그리고 프롬프트를 분리하고, 아까 언급했듯이 Mode 라는 개념을 추가했다. 그 결과는 어땠을까?

개인적으로 아주 ‘성공적’ 이라고 평가하고 싶다.

💡 프롬프트, 컨텍스트 가이드

  1. Copilot 에 인용할 자신의 Context 문서를 작성하고, 필요 시 해당 문서를 항상 추가해라.
  2. Command 에 프롬프트에 행당하는 부분만 기재한다. context 의 해당하는 부분은 배제하고, 이는 Persona 문서에 포함한다.
  3. 프롬프트는 구체적인 단어를 기재하는 것은 지양한다. 가능하면 행동 지침으로 최대한 구체화 시켜라.
  4. 내가 자동화 할 목표가 있다면, 그 목표의 ‘과정’을 프롬프트화 시켜라. 글 쓰기의 핵심이 개요 작성 -> 근거 추가 -> 살 붙이기 -> 퇴고 이런 순서라면, 각 단계 별로 필요한 영역에 프롬프트를 별도로 만드는 게 최선이다.
  5. 자신의 프로세스를 검증할 프롬프트, Context 를 준비하는 것도 좋다. => 이를 통해 제 3자의 검증을 효과적으로 수행해 줄 수 있다.
  6. 마크다운 양식의 헤드, 리스트 등 우선순위를 나타내는 기호를 AI 는 우선순위로 실제 판단한다. 따라서 우선순위를 고려한 프롬프트가 중요하다.
  7. 글의 철학, 가치관도 중요하지만, 스타일 가이드 쪽의 지정의 프롬프트가 훨씬 AI가 완성도 높은 구성을 해낸다. 정량적인 내용을 프롬프트에 담아라.
  8. AI 의 인격에 대한 부분도 context 로 준비하면 아첨, 과도한 긍정 평가를 최소화 시킬 수 있다. 평가, 분석, 보완 등의 역할을 원할 땐, 그에 따른 AI의 가상 인격을 생성해놓고 제공하자.

결과물 톺아보기

2.5 flash 는 2.5 Pro 대비 이상한 말도 많고, 허술한 답변을 할 때도 많다. 그러나 놀랍게도 컨텍스트 + 모드 + 프롬프트의 테스트 결과는 말도 안될 정도의 퀄리티의 내용을 뽑아주었다. 이미 충분히 블로그 글로 올렸을 때 문제 없지 않을까? 싶은 수준의 완성도 였다.

톤앤 무드는 정돈 되어 있었고, 내 설정들과 함께 전달된 자료들의 의도들을 정확히 재조합하여, 자잘한 분석 결과 문서, 자료들 예시, 몇 문단으로 작성된 결론, 개요를 한번에 종합해주었다. 그것도 단 돈 몇 십원 수준으로 말이다.

특히나 SEO 를 고려한 태그라던지, 예상 제목 제안 사항 등, 단순히 글쓰기를 돕는것 만으로 끝이 아니라, 블로그를 관리하고, 기술적 보조자 역할도 톡톡히 단 한 번의 요청으로 얻어낼 수 있었다.

뿐만 아니라, 위에서 얻은 결론을 기반으로 프롬프트를 추가로 제작. 내 글에 대한 분석, 글의 문제점이나 글에서 논리적 모순 등을 잡아주는 ‘편집장’ 프롬프트도 설정해 보았더니, 놀라울 만큼 명확하고 확실한 평가를 해주었다.

내 글 어디가 아쉽고, 어떤 점이 좋으며, 어떤 점에서 개선이 되면 좋을지. 제 3자 시선에서 평가해주는 프롬프트를 기반으로 나의 글을 세밀하게 분석해주었다. 특히나 너무 과한 내용이나 필요 없는 내용 등을 빠르게 캐치하고 검토해주었다. 가장 놀라운건 이것이 성능이 부족하다고 느껴 거의 쓰지 않던 2.5 flash 에서 가능하다는 점이다!

Pro vs Flash

놀라움. 만족스러움을 느끼기도 잠시. 2.5 flash를 왜 사용했는가? 에서 시작해서 한 가지 호기심이 들었다. 그것은 바로 ‘2.5 flash 로 이정도면, 2.5 pro 로 실행하면 얼마나 좋아질까?’ 였다.

그런데 어라. 이상했다. 2.5 flash 로 얻은 결과에 환호했던 것과는 달리, 생각보다 신기할 정도로 차이가 없었다.

구성의 큰 차이는 없다. 프롬프트의 요구사항은 충분히 수용되었고, 여기저기 좀더 늘어나거나, 개요이지만 글처럼 어느정도 완성되었다를 제외하면 뭔가 확 와닻는 변화는 아니었다.

정리해보면, 2.5 Pro와 2.5 flash 로 만든 글에 대해선 다음과 같은 차이가 있다.

Pro는 그 문장 하나 하나를 분석해 보았을 때, 단순히 요구 사항 이라고 적힌 것들의 의도를 고려한 답변에 가깝다는 게 보였다. 단순한 나열을 넘어 ‘이런 의도’로 이런 이야기니까, ‘이런 주장이 나온다’ 라는 표현. 생각해보면 훨씬 똑똑한 답변이라는 점은 부정할 수 없었다. 그러나 그것이 2.5 flash + 프롬프트만큼 확실한 효과가 있는가? 여기에 답변이 되기엔 애매 했다.

하물며 가성비를 생각해보자. 2.5 flash 의 경우 기본적으로 2.5 pro 대비 4배 정도의 가격차이가 날 수 있다(입출력 토큰 약 3K 수준 대비). 그런데 여기서 2.5 pro 는 입력값이 늘어나, 기준치를 넘기면(입력 토큰 수 2M 이상), 더 높은 요금을 부과해 요금을 측정한다. 즉, 2.5 flash 의 1000원 수준의 내용을 작업하면, 최대 수 천원 ~ 1만원대까지도 올라갈 수 있는 상황인 것이다.

새삼 프롬프트, 컨텍스트의 능력이 얼마나 뛰어난지를, 각종 AI 논문에서 작은 모델들의 합이라던가 MoE 구조라던가 기타 등등… 마치 거대 모델만큼 성능 좋게 만들수 있다! 는 표현들이 실제 어떤 의미인지 체감할 수있는 아주 흥미로운 결론이었다.

결론

AI, 나의 능력을 증폭시키는 최고의 파트너

AI 는 아직 AGI 는 아니다. 하지만 접근 방법에 따라서 ‘최고’가 될 수 있다는 점을 경험했다. 이번 과정을 통해 Copilot 이란 플러그인에 gemini 의 조합은 엄청난 수준의 글쓰기 조수를 구축하고, 혼자 끙끙 거리며 한달이 걸릴 글을 단 일주일도 안 걸리게 마무리, 그것도 실질 글 작업은 약 이틀 정도 소모 되는 속도로 만들어냈다. 초기 목표보단 못한 것은 사실이지만 그럼에도 엄청난 효율, 효과를 누렸다고 할 수 있겠다.

현재 개발 시장의 요구 사항은 명확하다. 자기 도메인의 높은 전문성, 그리고 그 전문성과 함께 시너지를 발 할수 있는 AI에 대한 리터러시. 개인적으로 건강을 위한 휴식 중이긴 하나, 동시에 내가 생각하는 ‘필요시 되는 사람’으로 살아가기 위해 벌린 이번 미니 프로젝트는, 현재 AI 의 본질을 이해할 수 있었고, 가공할 능력을 어디까지 활용할 수 있을지에 대한 내 나름의 시도이자, 단편적인 답변이었다.

프롬프트, 그 위에 작용하는 컨텍스트의 가능성을 엿 볼 수 있는 사례다. 2.5 flash 라는 가성비 모델로도, 얼마나 효과적일 수 있는지 체감할 수 있었던 좋은 기회였다. 이 글을 읽는 모두가 AI 를 통한 생산성 향상. 특히 한계에 부딪힐 때, 그 한계를 넘어서는 기술적 발판으로 활용을 잘 하면 좋겠다고 생각한다. 본 글을 통해 커스텀 된 AI 에이전트를 노코드로 구축하고, 프로세스를 단축하는 새로운 글쓰기 경험을 맛 보시길!

요약

글이 너어어어ㅓㅓㅓㅓ 무 길어졌다(…) 내 기록을 위해 남긴다지만, 너무 길어 요약을 해보았다.

  1. AI 프롬프트를 합치면 오히려 일반화된다 - 여러 AI의 분석을 통합하려 했지만, 독특한 특징이 사라지고 정보 손실이 발생했다.
  2. Context(페르소나)와 Prompt(행동지침)를 분리하고, 글 종류별 Mode를 구분하니 비로소 ‘나다운’ 글쓰기가 가능해졌다.
  3. 2.5 flash + 잘 짜여진 프롬프트 구조가 2.5 Pro보다 가성비 측면에서 압도적이었다. 작은 모델도 Context Engineering으로 충분히 강력해질 수 있다.

Obsidian 에 Copilot, Gemini API 적용 방법 (링크)(작성중)