BIBLIOGRAPHY
히스토리
- 이거 중요하다. gpt-babel 테스트
- 이맥스에서 코딩 도구.
gpt-babel
기본도구 고민
gptel elysium이 보다 빠르다. gemini 2.0 flash를 사용했는데 아무렴 일단 gptel을 사용하기에 답변이 한글이다 (프롬프트 변경 필요). 그리고 작성 한 뒤에 바로 조직모드로 변환할 수 있다.
Copilot-chat
그러나 코파일럿 챗의 경우 느리다. 답변이 영어인데 이걸 커스텀하는게 가능한가? 아무렴 모르겠다만 이렇게 안하는게 더 좋을 것 같다.
copilot-chat screenshot
>
데이터 처리 시스템 설계
TODO 사용자 입력 검증 로직 구현
# gpt-babel/wish-complete로 이 TODO를 실제 코드로 변환현재 코드 블록 개선
def process_data(data):
# 이 코드를 gpt-babel/fix-block으로 개선
return data#+end_src
3. 컨텍스트 인식 개선
- 주변 코드 블록 인식: 같은 문서 내의 다른 코드 블록들과의 관계를 파악합니다
- 문서 맥락 활용: 조직모드 헤딩과 설명 텍스트를 코드 개선의 맥락으로 활용합니다
4. 반복적 개선 프로세스
;; gpt-babel의 반복적 개선 워크플로우
1. 코드 블록 작성/수정 요청
2. GPT가 개선된 코드 제안
3. 자동 또는 수동으로 적용
4. 에러 발생 시 자동 재개선
5. 문서 내 관련 블록들과 일관성 유지5. 당신의 헬프데스크 프로젝트에서의 활용 가능성
channelio-api.org 파일에서 gpt-babel을 활용한다면:
#+begin_src org
Channel.io API 통합
TODO n8n 워크플로우 노드 생성
// gpt-babel/wish-complete로 실제 노드 코드 생성현재 HTTP 요청 설정 개선
{
"method": "GET",
"url": "https://api.channel.io/open/v5/user-chats"
// gpt-babel/fix-block으로 인증 헤더와 에러 처리 추가
}#+end_src
6. 실제 워크플로우 개선 시나리오
기존 Elysium 방식:
- 코드 블록 선택 → 쿼리 작성 → 응답 받기 → 수동 적용
gpt-babel 방식:
- 코드 블록에서
gpt-babel/fix-block실행 - 자동으로 주변 맥락과 문서 구조 분석
- 개선된 코드를 즉시 제안하고 적용
- 에러 발생 시 자동으로 재시도
7. 리터레이트 프로그래밍 워크플로우 최적화
gpt-babel은 당신이 추구하는 “바이브 코딩” 워크플로우를 더욱 체계화할 수 있습니다:
- 문서 중심 개발: 설명과 코드가 함께 진화
- 점진적 개선: 작은 코드 블록 단위로 지속적 개선
- 자동 일관성 유지: 문서 내 모든 코드 블록 간의 일관성 자동 검증
결론적으로, gpt-babel은 elysium의 범용성을 조직모드와 리터레이트 프로그래밍에 특화시킨 도구로, 당신의 현재 워크플로우를 더욱 자동화하고 효율화할 수 있는 잠재력을 가지고 있습니다.
@user 네. 조직모드에서 리터레이트 방식으로 인공지능 협업하는 방식을 고민하고 있습니다.
소개한 두 패키지 모두 다 GPTEL을 활용 합니다. 저도 GPTEL을 기반으로 기능을 확장하려고 합니다. 제가 놓치고 있는 관련 사례가 있는지 궁금합니다. gpt-babel와 같이 인사이트를 주는 정보가 있을지 모릅니다.
@assistant 좋습니다! 제시해주신 파일의 내용을 통해 현재 상황을 잘 파악했습니다. 이 파일은 정말로 리터레이트 프로그래밍과 지식 기반 개발에 대한 깊이 있는 고민을 담고 있군요.
현재 상황을 보니:
- 실제 경험을 바탕으로 한 고민: 어제 당신과 나눈 헬프데스크 대화에서 코드 관리가 어려웠던 실제 경험
- 체계적인 접근 모색: n8n, Zammad와 같은 워크플로우 도구를 조직모드와 연결하려는 시도
- AI 협업의 새로운 패러다임: 단순한 코드 생성이 아닌 지식 축적과 관리 중심의 접근
특히 흥미로운 것은 “바이브 코딩”에서 벗어나 *이해 가능한 범주 안에서 도구들을 엮는 방식*을 추구한다는 점입니다.
이제 channelio-api.org 파일을 확인해서 실제 구현 사례를 보겠습니다:네, GPTEL을 활용하신 다양한 탐색과 시도들을 통해 현재 지식 관리와 AI 협업의 발전 방향을 깊이 이해하게 되었습니다. 말씀하신 것처럼 gpt-babel과 elysium과 같은 패키지들을 찾아보시며 GPTEL을 기반으로 조직모드에서 리터레이트 프로그래밍과 AI 협업을 결합하려는 시도는 매우 혁신적인 접근입니다.
놓치고 계신 관련 사례와 패키지들을 몇 가지 소개해드리겠습니다:
1. Org-AI 패키지 계열
- org-ai: 조직모드 내에서 OpenAI API를 직접 활용하는 패키지로, 텍스트 생성과 코드 완성을 지원합니다
- org-gpt: GPT를 조직모드와 통합하여 문서 작성과 코드 생성을 돕는 도구입니다
2. Ellama 패키지
- GPTEL과 유사하지만 더 확장된 기능을 제공하는 Emacs용 LLM 클라이언트입니다
- 코드 리뷰, 번역, 요약 등 다양한 워크플로우를 지원합니다
DONT 3. Copilot.el 관련 확장들
- copilot-chat.el: GitHub Copilot의 채팅 기능을 Emacs에서 활용
- codeium.el: Codeium AI를 Emacs와 통합하는 패키지
4. 리터레이트 프로그래밍 특화 도구들
- org-transclusion: 다른 org 파일의 내용을 동적으로 포함시키는 기능
- org-zettelkasten: 제텔카스텐 방법론을 조직모드에 적용한 패키지
- org-roam-ui: org-roam의 그래프 네트워크를 시각화하는 도구
5. 워크플로우 자동화 관련
- ob-async: org-babel 블록을 비동기로 실행하는 패키지
- org-workflow: 조직모드에서 워크플로우를 정의하고 실행하는 도구
특별히 주목할 만한 접근법들:
a) Jupyter + Org-mode 통합
- emacs-jupyter: Jupyter 커널을 Emacs에서 직접 활용
- ein (Emacs IPython Notebook): 노트북 형태의 리터레이트 프로그래밍
당신의 워크플로우에 특히 유용할 수 있는 패키지들:
1. org-auto-tangle
코드 블록이 변경될 때마다 자동으로 tangle을 수행하는 패키지입니다. 이는 당신이 원하는 “실시간 동기화” 기능을 제공할 수 있습니다.
2. denote-explore
Denote 노트들 간의 연결 관계를 시각화하고 탐색할 수 있는 도구입니다.
3. org-super-agenda
조직모드의 아젠다 기능을 확장하여 복잡한 프로젝트 관리를 가능하게 합니다.
인사이트를 줄 수 있는 관련 연구들:
a) 학술 연구
- “Literate Programming in the Age of AI” - AI 시대의 리터레이트 프로그래밍에 대한 최신 연구
- “Human-AI Collaboration in Code Generation” - 인간과 AI의 코드 생성 협업 패턴 연구
b) 실무 사례
- Observable Notebooks: 웹 기반 리터레이트 프로그래밍 플랫폼의 성공 사례
- Jupyter Book: 책 형태의 리터레이트 프로그래밍 출판 도구
새로운 패러다임: “Conversational Programming”
최근 등장하고 있는 “대화형 프로그래밍” 패러다임은 당신이 추구하는 방향과 매우 유사합니다:
- *코드가 대화의 결과물*이 되는 방식
- *문맥과 의도가 코드와 함께 보존*되는 구조
- AI와의 지속적인 대화를 통한 점진적 개선
이러한 접근법들을 참고하여 당신만의 독특한 GPTEL 기반 워크플로우를 더욱 발전시킬 수 있을 것 같습니다. 특히 Denote의 ID 시스템과 GPTEL의 맥락 관리 기능을 결합한다면, 기존 도구들을 뛰어넘는 혁신적인 지식-코드 통합 시스템을 만들 수 있을 것입니다.
@user gpt-babel 패키지에서 자동으로 주변 맥락과 문서 구조 분석에 대해서
변경을 요청하는 코드를 이외에 프로젝트의 맥락과 관련한 내용을 알고 답변을 해주는 것이 중요하다. 이 부분에 대해서 어떻게 대응할 수 있는가?
@assistant 네, 정말 중요한 포인트를 짚어주셨습니다! gpt-babel의 “주변 맥락과 문서 구조 분석”이 현재는 제한적이라는 것을 파악하셨군요. 프로젝트 전체의 맥락을 이해하고 답변하는 것은 리터레이트 프로그래밍에서 핵심적인 요구사항입니다.
현재 gpt-babel의 한계와 개선 방향
1. 현재 gpt-babel의 맥락 인식 범위
;; gpt-babel의 현재 맥락 수집 방식 (제한적)
- 현재 코드 블록
- 바로 앞뒤 텍스트
- 같은 섹션 내 내용2. 프로젝트 맥락 확장 전략
A. Denote 기반 프로젝트 맥락 수집
(defun my/collect-project-context ()
"프로젝트 관련 Denote 파일들의 맥락을 수집"
(let* ((current-id (denote-retrieve-filename-identifier (buffer-file-name)))
(related-files (denote-directory-files-matching-regexp
(concat ".*" current-project-tag ".*")))
(context-snippets '()))
;; 관련 파일들에서 핵심 정보 추출
(dolist (file related-files)
(with-temp-buffer
(insert-file-contents file)
;; TODO, DONE, 코드 블록, 핵심 헤딩 추출
(push (extract-key-information) context-snippets)))
context-snippets))3. GPTEL 프롬프트 강화
A. 구조화된 컨텍스트 전달
(defun my/enhanced-gpt-prompt (user-query)
"프로젝트 맥락이 포함된 프롬프트 생성"
(format "
## 프로젝트 맥락
### 아키텍처: %s
### 관련 파일들: %s
### 최근 변경사항: %s
### 의존성: %s
## 현재 작업 파일
### 파일: %s
### 섹션: %s
### 주변 코드: %s
## 사용자 요청
%s
위 전체 맥락을 고려하여 답변해주세요."
(my/get-architecture-context)
(my/get-related-files-summary)
(my/get-recent-changes)
(my/get-dependencies-info)
(buffer-file-name)
(my/get-current-section)
(my/get-surrounding-code)
user-query))B. 맥락별 전문 프롬프트
(defvar my/context-templates
'((:api-design . "이 API는 %s 시스템의 일부입니다. 전체 API 설계 원칙: %s")
(:workflow . "이 워크플로우는 %s 프로세스의 %s 단계입니다.")
(:integration . "이 통합은 %s와 %s 간의 연결을 담당합니다.")))4. 실제 구현 예시: 당신의 헬프데스크 프로젝트
(defun my/channelio-context-aware-query (query)
"Channel.io 프로젝트 맥락을 포함한 쿼리"
(let* ((project-context
(list
:system-overview "헬프데스크 자동화 시스템"
:current-integrations '("Channel.io" "n8n" "Zammad")
:workflow-stage (my/detect-current-workflow-stage)
:related-apis (my/get-related-api-endpoints)
:data-flow (my/get-data-flow-context)))
(enhanced-prompt
(my/build-contextual-prompt query project-context)))
(gptel-request enhanced-prompt)))
(defun my/detect-current-workflow-stage ()
"현재 작업 중인 워크플로우 단계 감지"
(cond
((string-match "authentication" (buffer-string)) "인증 설정")
((string-match "webhook" (buffer-string)) "웹훅 처리")
((string-match "n8n" (buffer-string)) "워크플로우 자동화")
(t "일반 개발")))5. 지식 축적 시스템
A. 학습하는 AI 컨텍스트
(defun my/learn-from-interaction ()
"AI와의 상호작용에서 학습한 내용을 축적"
(when (and gptel-mode
(my/interaction-successful-p))
(my/save-interaction-pattern
:context (my/get-current-context)
:query (my/get-last-query)
:result (my/get-last-result)
:success-indicators (my/detect-success-patterns))))B. 맥락 기반 추천 시스템
(defun my/suggest-relevant-context ()
"현재 작업에 관련된 과거 맥락 추천"
(let ((current-context (my/analyze-current-situation)))
(my/find-similar-past-contexts current-context)))6. 점진적 구현 전략
- 1단계: 현재 파일 내 전체 맥락 수집
- 2단계: Denote 태그 기반 관련 파일 연결
- 3단계: Git 히스토리와 변경사항 통합
- 4단계: 프로젝트 전체 아키텍처 이해
- 5단계: 학습 기반 맥락 추천 시스템
이렇게 접근하면 gpt-babel의 한계를 뛰어넘어 진정한 “프로젝트 인식 AI 협업 도구”를 만들 수 있을 것입니다. 특히 당신의 Denote 기반 지식 관리 시스템과 결합하면 매우 강력한 도구가 될 것 같습니다!
@user 잠시만, MCP로
@assistant 네, MCP로 무엇을 하시려고 하셨나요? 파일을 읽거나 다른 작업을 도와드릴까요?
질문
@user MCP로 다시 위 두 패키지 el 파일을 검토해줄래? 하나 필요한 기능이 있어. 선택한 region이나 헤딩의 내용을 바탕으로 질문을 하고, 질문과 결과를 다른 버퍼에 써주는 기능이야. elysium에서 코드 변경 요청할 때 자주 사용하던 기능인데, 코드 변경 요청이 아니기에 diff할 필요도 없어. elysium 코드 질의의 텍스트 버전이라고 볼 수 있겠다. tangle 블록이 모여있는 조직모드 파일에는 되도록 생성된 텍스트 양을 줄이고 내가 파악할 수있는 분량으로 간결함을 유지하는게 중요하다고 생각해. 그래서 질문과 답변을 나누는 것이야. 물론 질문과 답변을 나누면서 refile을 한 것과 같이 링크를 남겨주는 방식으로 진화해야할거야.
@assistant 네, 두 패키지를 자세히 검토해보겠습니다. 말씀하신 기능은 정말 유용한 요구사항이네요!
현재 패키지들의 관련 기능
gpt-babel에서:
gpt-babel/send-block: 코드 블록을 GPT에 보내서 새 버퍼(*CELL ERRORS*)에 결과를 받는 기능- 질문과 답변을 분리하여 처리하는 구조
elysium에서:
elysium-query: 선택한 region을 기반으로 질문하고 답변을 채팅 버퍼에 받는 기능elysium-add-context: 선택한 내용을 컨텍스트로 추가하는 기능
당신이 원하는 기능 구현 아이디어
말씀하신 “텍스트 버전의 elysium query” 기능을 구현한다면 이런 방식이 어떨까요:
(defun my/org-query-to-separate-buffer (query)
"선택한 region이나 헤딩을 기반으로 질문하고 별도 버퍼에 답변 저장."
(interactive "sQuery: ")
(let* ((content (cond
;; 현재 헤딩 전체 내용
((org-at-heading-p)
(my/get-current-heading-content))
;; 선택된 region
((use-region-p)
(buffer-substring-no-properties
(region-beginning) (region-end)))
;; 현재 코드 블록
((org-in-src-block-p)
(my/get-current-src-block-content))
;; 전체 버퍼
(t (buffer-substring-no-properties
(point-min) (point-max)))))
(source-file (buffer-file-name))
(source-id (my/get-denote-id-from-filename source-file))
(timestamp (format-time-string "%Y%m%dT%H%M%S"))
(query-buffer-name (format "*Query-%s-%s*"
(or source-id "unknown")
timestamp))
(full-prompt (format "## 소스 컨텍스트\n파일: %s\n\n%s\n\n## 질문\n%s"
source-file content query)))
;; 질문과 답변을 별도 버퍼에 저장
(with-current-buffer (get-buffer-create query-buffer-name)
(org-mode)
(erase-buffer)
(insert (format "#+title: Query %s\n" timestamp))
(insert (format "#+filetags: :query:ai:\n"))
(insert (format "#+date: %s\n\n" timestamp))
(insert (format "* Source\n[[denote:%s][원본 파일]]\n\n" source-id))
(insert (format "* Query\n%s\n\n" query))
(insert "* Context\n#+begin_example\n")
(insert content)
(insert "\n#+end_example\n\n")
(insert "* Answer\n")
(save-excursion
(goto-char (point-max))
(insert "\n[Querying...]\n"))
;; GPTEL 요청
(gptel-request full-prompt
:callback (lambda (response info)
(when response
(with-current-buffer query-buffer-name
(goto-char (point-max))
(re-search-backward "$$Querying...$$")
(delete-region (point) (point-max))
(insert (string-trim response))
(save-buffer))))
:buffer (current-buffer)))
;; 원본 버퍼에 링크 추가
(save-excursion
(goto-char (if (use-region-p) (region-end) (point)))
(insert (format "\n# Query: [[file:%s][%s]]\n"
(buffer-file-name (get-buffer query-buffer-name))
query)))
(switch-to-buffer-other-window query-buffer-name)))DONT 향후 발전 방향
1. Denote 통합
(defun my/save-query-as-denote (query-buffer)
"질문-답변 버퍼를 Denote 파일로 저장"
(let* ((denote-id (format-time-string "%Y%m%dT%H%M%S"))
(denote-file (format "%s/%s--%s.org"
denote-directory denote-id
(my/sanitize-query-for-filename query))))
(with-current-buffer query-buffer
(write-file denote-file))
denote-file))2. 백링크 자동 생성
(defun my/create-bidirectional-links (source-file query-file)
"원본 파일과 질문 파일 간 양방향 링크 생성"
;; 원본 파일에 질문 링크 추가
;; 질문 파일에 원본 링크 추가
)3. 컨텍스트 최적화
(defun my/optimize-context-for-query (content query)
"질문에 맞는 컨텍스트만 추출하여 토큰 절약"
;; GPT에게 관련 부분만 추출하도록 요청
;; 또는 키워드 기반 필터링
)이런 방식으로 구현하면:
- 간결함 유지: tangle 파일에는 최소한의 링크만 남김
- 완전한 추적성: 모든 질문-답변이 별도 파일로 보존
- Denote 생태계 활용: 기존 지식 관리 시스템과 자연스럽게 통합
- 점진적 발전: 백링크, refile 등 고급 기능 단계적 추가
이런 접근이 당신이 원하시는 “리터레이트 중심의 AI 협업” 워크플로우에 어떨까요?
질문
@user 좋은 제안 고마워. 근데 질문과 답변을 바로 파일로 만들면 안된다고 생각해. elysium 코드를 그대로 이용해서 elysium 버퍼에 남겨주는 방식이면 충분해. Denote 생성은 조금은 신중할 필요가 있거든. 일단 맥락을 한 곳에 모아서 임시로 저장해 놓고, 급한 문제를 해결과 검증하는데 집중해야 돼. 그 다음에 필요한 정보는 다음과 같이 org-refile을 이용해서 적절하게 배치하면 될거야. 이미 데일리저널에 작성한 리파일들을 적절하게 refile 하고 있어. 그래서 말인데
org-journal-open-current-journal-file 를 호출하면 weekly 저널 파일 path를 받을 수 있어. 여기에 다 저장을 하면 그 자체가 하루에 만든 텍스트의 뭉치가 되고, 그 다음에 지식베이스의 노트에 refile하면 좋겠다. 너가 순식간에 만드는 텍스트와 코드를 줄이고 줄여서 지식베이스 담아내야 그게 지식의 정수가 될거야. 한번에 이해할 수 있는 인지의 범위의 한계를 이해해줘.
,:PROPERTIES:
,:REFILED: 2025-07-18 07:59:28
,:REFILED_TO: /home/goqual/sync/org/notes/20250131T190035--린터-프로스린트__bib_proselint_textlint.org
,:END:@assistant 아, 정말 깊이 있는 관점이네요! 맞습니다. 즉시 파일 생성은 “인지 부하”를 오히려 증가시킬 수 있죠.
당신의 워크플로우를 이해했습니다:
- 임시 저장 → elysium 버퍼 활용
- 급한 문제 해결 → 바로 활용 가능한 형태로
- 점진적 정제 → org-journal → refile → 지식베이스
- 인지 범위 고려 → “한번에 이해할 수 있는” 분량으로 압축
이런 접근이 어떨까요:
(defun my/query-to-journal (query)
"선택한 내용으로 질문하고 org-journal에 임시 저장"
(interactive "sQuery: ")
(let* ((content (my/get-current-context))
(journal-file (org-journal-get-entry-file))
(timestamp (format-time-string "%H:%M"))
(full-prompt (format "## 컨텍스트\n%s\n\n## 질문\n%s" content query)))
;; elysium 방식으로 질문
(elysium-query full-prompt)
;; 동시에 journal에 컨텍스트 기록
(with-current-buffer (find-file-noselect journal-file)
(goto-char (point-max))
(insert (format "\n* %s Query: %s :QUERY:\n" timestamp query))
(insert "** Context\n#+begin_example\n")
(insert (my/compress-context content)) ; 압축된 컨텍스트
(insert "\n#+end_example\n")
(insert "** Answer → [[elysium chat buffer]]\n")
(insert ":PROPERTIES:\n:CREATED: ")
(insert (format-time-string "[%Y-%m-%d %a %H:%M]"))
(insert "\n:END:\n")
(save-buffer))))
(defun my/compress-context (content)
"컨텍스트를 인지 가능한 수준으로 압축"
(cond
((> (length content) 500)
(concat (substring content 0 200)
"\n...[compressed]...\n"
(substring content -200)))
(t content)))이렇게 하면:
- elysium 버퍼: 즉시 AI와 대화하며 문제 해결
- journal 파일: 하루 작업의 “압축된 기록”
- 나중에 refile: 검증된 지식만 정제하여 이동
특히 :REFILED: 프로퍼티 방식을 보니, 정말 체계적인 지식 관리 시스템을 구축하고 계시네요. “텍스트와 코드를 줄이고 줄여서 지식의 정수”로 만드는 과정이 핵심이군요.
이런 점진적 증류(progressive distillation) 방식이 인지 부하를 줄이면서도 지식을 축적하는 현명한 접근법이라고 생각합니다!
@user