R&D 연구개발 제안서 AI 협업 워크플로우

Table of Contents

히스토리
@junghan — 글을 정리하여 다시 적는 과정
정부 R&D 제안서 AI 협업 워크플로우

히스토리

[2026-03-06 Fri 22:55] @junghan — 정말 문서 작업은 후루룩이다. 하루 종일 텍스트하고 놀지 않는가? 프롬프트? 잠시만 후루루룩 A4용지 10장.
[2026-03-06 Fri 13:07] 생성 — 정부 R&D 제안서 AI 협업 워크플로우 정리

@junghan — 글을 정리하여 다시 적는 과정

[2026-03-07 Sat 09:34] 바로 아래 FAQ 콜아웃은 협업 워크플로우를 생각하며 직접 힣이 손으로 타이핑 한 것 입니다.

Faq

이 문서는 과제 제안서의 인간(물론 AI에게 써달라고 했겠지만)이 적은 초안을 메타 형식으로 가져와서 전체적인 구성에 일관성을 더하여 다시 작성하고 양식에 맞게 변환하여 전달하는 방식에 대한 것이다. @memex-kb 는 나의 확장된 도구 세트로서 내가 단일 ‘org’ 포멧으로 변환하여 어느 포멧이든 재변환하는 모든 워크플로우 로직을 포함한다. 여기에는 토큰 세이빙을 하고 일관성을 위한 고민들이다. 변환 과정의 재현성은 매우 귀하다. 이것은 내용과 상관 없는 양식에 대한 것이다.

이제 내용의 측면으로 가보자. 작성 과정에 한 글자도 인간이 손을 대지 않는다. 프롬프트만으로 해야 재현성이 보장이 된다. 프롬프트로 모든 정보를 주기는 어렵다. 그래서 ‘지식 베이스’의 역할이 중요하다. 어떤 문서로 나에게 들어오면 거의 비슷한 색깔의 문서가 나온다. 물론 목적에 따라서 프롬프트 차원에서 방향을 논의 한다. 아래의 글의 예는 개발자가 연구개발 제안서의 초안을 AI로 만들어서 전달해왔다. 행정담당자는 AI를 돌려보았고 이건 연구개발에 적합하지 않다고 한다. 다시 써줘야 하는 것이다. 그림도 넣어줘야 한다. 레퍼런스도 없다. 스토리라인도 없다. 행정담당자는 회사 관련 내용도 좀 적어달라고 한다. 좋다.

개발계획서를 연구계발 3개년도 계획서로 만든다

인력지원 사업이므로 해당 인력의 스토리라인이 필요하다. A씨의 이야기가 배치 되어야 한다.

회사 이름으로 내는 것이기에 회사의 배경도 적어 준다.

3차년도 연구개발 내용은 일단 나의 지식 베이스에서 키워드를 중심으로 고민해온 이야기를 꺼내서 잠시 이야기 나눈다.

내 코드베이스에는 3rd로 클론한 것까지 같이 보고, bib 파일로 변환한 ‘github-star’ 리스트도 볼 수 있다. 여기까지 할 정도는 아니다.

그림은 위한 프롬프트를 만들고 나노바나나도 만들어 넣는다. 물론 다 org 포멧 안의 것이다. 행정 담당자에게 확인할 사항을 별도 문서로 남긴다.

org 문서에 모든 섹션이 정리가 되면, run.sh build를 한다. odt 변환 시 hwp 제안서 포멧에 적용가능한 style 시트를 거쳐서 생성된다. doc는 세트로 생성된다.

hwp는 필요 시 doc->hwp 변환을 한다. 이게 안전하다. hwpx를 끄적이는 것은 별로 효과적이지 않더라. 행정담당자는 hwp 고수가 많다. 내용만 싹 채워주고, 본인이 귀찮게 작성해야 할 부분가지 (예를 들어 표까지) 다 넣어서 주면 약간의 hwp의 수고로움은 본인의 키보드 워크로 감당한다.

구글 워크스페이스 스킬로 메일 전달해주고, google docs로도 공유 한다. 이는 내용 상 협의가 필요한 경우 유용하다. 물론 일정은 구글 캘린더에 미리 적어 놓았다. 모든 것은 스킬 cli에서 처리가 되어야 한다. 에이전트에게 mcp 로딩의 부담 주고 싶지 않다.

마치 커밋 후, 어젠다 타임스탭프를 찍듯 마찬가지로 타임스탬프로 어젠다에 남긴다. 여기에 구글 채팅 스페이스로 바로 메시지를 같이 쓴다. 같은 내용 만든김에 커맨드 하나 호출해주는 것이니 서로 편하다. 커밋 - 타임스탬프 - 채팅 스페이스 올리는 모든 텍스트가 같다. 에이전트는 스킬을 나눠 쓰는 것 뿐이다.

더 할게 있는가? 아! 슬랙! 슬랙에 남겨줘야지! 슬랙에도 보내준다. 보내줄 때는 이메일 보낸 내용 + 추가 검토 사항을 적어서 보낸다. 보낼 때는 내용은 커밋 메시지 처럼 박히더라도 위에는 약간 손을 댄다. 오타는 더 좋다.

왜? 너무 비인간적으로 느껴 질 수 있다. 이 전과정이 사실 내가 개입할 필요가 없을 수도 있다. 아마 그렇게 될 것이다.

인간은 시간 속에 메어 있다. 상대가 나에게 연결을 요청하는 것은 시간을 사용했다는 말이다. 모든 것을 자동화한다면, 그 것은 연결이 아니다. 나 또한 시간으로 답해야 한다.

그렇다면, 연결 요청이 100건이 왔다면? 이건 나에게 감당이 안되는 일이다. 그렇게 할 수 없다. 나 또한 시간이 유한하기 때문이다.

그래서 연결은 되도록 받지 않는다. 특히 스몰토크로 요청 한다면 그 메시지는 바로 에이전트로 전달되어 자동 답변 된다.

답변 내용은 이러할 것이다. “API 사비스 이즈 언어붸일러블”

정부 R&D 제안서 AI 협업 워크플로우

[2026-03-06 Fri 13:07] 힣봇이 작성 함

정부 R&D 제안서를 Org-mode + CLI 파이프라인으로 작성하고, 비개발자 실무자와 협업하여 제출한 과정을 기록한다.

핵심 교훈: Org-mode는 “나만 쓰는 포맷”이 아니라 팀 협업의 소스 오브 트루스가 될 수 있다.

배움 1: “개발”을 “연구”로 리프레이밍하는 패턴

문제

대무문 연구자가 아닌 엔지니어가 실무에서 하는 일은 목적은 개발이다. 그런데 정부 R&D 과제로 신청하면 “개발/운영이지 연구가 아니다”라는 피드백을 받는다. 내용은 같은데 프레이밍이 다르다.

해법: 학술 용어로 축을 세운다

실무 표현	R&D 리프레이밍	학술 근거
서버에서 UI 내려주기	Server-Driven UI, 동적 프론트엔드	Airbnb SDUI (2021)
클라우드-로컬 이중화	에이전트 협업, Failover	Google A2A Protocol (2025)
보안 설정 화면 개선	Usable Security, Privacy Dashboard	SOUPS Conference, NIST IR 8259

핵심은 이미 하려던 일에 학술 프레임을 씌우는 것 이지, 없는 연구를 만들어내는 게 아니다. 기존 실무와 1:1 대응되면서 R&D 톤을 확보한다.

정량목표는 반드시 보수적으로

100%를 넣으면 안 된다. 달성 못하면 감점이다. 95%를 넣고 100% 달성하는 게 낫다.

항목	위험한 목표	안전한 목표
성공률	100%	≥95%
정확도	90%	≥80%
응답시간	≤0.5초	≤1.0초

배움 2: Org → ODT 파이프라인이 Pandoc을 대체한다

왜 Pandoc이 아닌가

Pandoc은 범용 도구로서 훌륭하지만, 한국어 정부 문서에는 한계가 있다:

한글 캡션 (그림, 표) 미지원
reference.odt 스타일 적용이 불완전
테이블 헤더 배경색/테두리 미적용
CSL 참고문헌 URL 렌더링 문제

Emacs org-odt-export 파이프라인

[Org-mode]
    │  emacs --batch -l proposal-export.el
    ▼
[ODT] ← reference.odt 스타일 정확 적용
    │  odt_postprocess.py (테이블 헤더/테두리 보정)
    ▼
[ODT 보정]
    │  LibreOffice --headless --convert-to doc
    ▼
[DOC] → 메일 첨부 전송

./run.sh build 한 줄이면 끝난다. 재현 가능하고, 스타일 일관되고, 이미지·참고문헌·테이블이 모두 정확하다.

공개 샘플: memex-kb/samples/org-to-odt

배움 3: AI-인간 협업 루프 — 한 세션의 전체 흐름

역할 분담

역할	담당	작업
R&D 설계	AI + 작성자	연구축 리프레이밍, 참고문헌, 본문 작성
이미지	작성자 (이미지 생성 도구)	AI가 프롬프트 생성 → 사람이 이미지 생성
빌드	AI (CLI)	org→odt→doc 자동 변환
행정	관리 담당자	시스템 입력, 분류 선택
검토	AI	내용/분류/목표치 검토 → Google Docs 코멘트
전달	AI (CLI)	gog gmail send로 DOC 첨부 메일 발송

시퀀스

기존 초안 분석
denotecli로 관련 지식베이스 탐색
연구축 리프레이밍 (학술 근거 매핑)
org 파일 작성 (본문 + 테이블 + 참고문헌)
이미지 프롬프트 생성 → 다이어그램 생성
./run.sh build → org→odt→doc
gog docs insert → Google Docs에 검토 의견 삽입
관리 담당자 피드백 → 정량목표 조정
gog gmail send → DOC 첨부 메일 발송

전체 과정에서 브라우저를 열지 않았다. Org-mode에서 작성하고, CLI로 빌드하고, CLI로 검토하고, CLI로 전달했다.

핵심 도구 체인

도구	용도
Org-mode	문서 소스 오브 트루스
Emacs org-odt-export	고품질 ODT 변환
odt_postprocess.py	테이블 스타일 보정
LibreOffice CLI	ODT → DOC
gog (Google Workspace CLI)	Docs 코멘트, Gmail 발송, Drive 업로드
denotecli	지식베이스 탐색

배움 4: 작은 회사의 R&D 제안서 — 솔직함이 전략이다

억지로 말 지어내면 우습게 된다.

자체 기술 축적이 적은 소규모 회사에서 “원천 기술 보유”를 주장하면 심사위원이 바로 안다.

대신 강조할 것:

실사용자 기반 — 데이터와 고객이 있다.
생존 이력 — 창업자가 오래 이어왔다.
젊은 조직 — 빠른 실행, 유연한 전환이 가능하다.
성장 가능성 — AI 시대에 실증 데이터 위에 기술을 쌓을 준비가 되었다.

없는 걸 만들지 말고, 있는 걸 정확히 말하는 게 설득력이다.

junghanacs🧠