기존 프로젝트로 Hermes 스킬을 만들었다 — 한 번 만든 연구 자동화를, 다시 쓸 수 있는 작업 방식으로 바꾸는 법

📝 한줄 요약

이미 자료를 넣으면 연구자 프로필과 연구계획서 초안까지 만들어 주는 프로젝트가 있었습니다. 그런데 한 번 잘 돌아간 앱이 곧바로 “다음에도 믿고 쓸 수 있는 작업 방식”이 되는 건 아니었습니다. 이번에는 기존 Research Navigator 프로젝트를 바탕으로, Hermes가 매번 같은 순서와 기준으로 움직일 수 있는 연구 워크플로우 스킬을 만들었습니다. 핵심은 AI에게 더 긴 지시를 주는 일이 아니라, 언제 진행하고 언제 멈추며 무엇을 확인해야 하는지를 남기는 일이었습니다.

바쁘시면 이것만 읽어도 돼요:

• 작동하는 프로젝트가 있어도, 작업 순서·승인 기준·재개 지점이 남지 않으면 다음 실행에서 다시 흔들린다

• 그래서 자료 등록부터 감사까지를 10개 Hermes 스킬과 파일 기반 상태로 나눴다

• 자동화는 “AI가 알아서 확정한다”가 아니라, 승인된 범위에서 반복 실행하고 근거가 없으면 멈춘다는 뜻으로 만들었다

• 실제 자료로 처음부터 다시 돌리니, 결과 JSON 구조가 바뀌며 화면에 [object Object]가 보이는 문제도 발견됐다

• 결과를 예쁘게 숨기지 않고, API 경계에서 사람이 읽는 형태로 바꾸고 테스트·브라우저 검증까지 했다

🎯 이런 분들께 도움돼요

• 이미 한 번 만든 AI 프로젝트를 반복해서 쓸 수 있는 업무 방식으로 바꾸고 싶은 분

• AI에게 큰 프롬프트 하나를 던지는 대신, 단계·승인·검증을 나누고 싶은 분

• 민감한 문서나 연구자료를 다루면서도 자동화의 편리함을 얻고 싶은 분

• AI 결과가 그럴듯해도 “이게 확인된 사실인가?”를 구분하고 싶은 분

😫 문제 상황 (Before)

기존 프로젝트는 꽤 많은 일을 할 수 있었습니다. 자료를 넣으면 연구자 프로필을 만들고, 연구 아이디어를 뽑고, 설계를 만들고, 필요한 장비를 정리하고, 연구계획서 초안까지 이어졌습니다.

하지만 여기에는 빈틈이 있었습니다. 작업은 앱과 그때그때의 대화 속에서 잘 흘러갔지만, 다음에 다시 실행할 때도 같은 기준으로 움직인다는 보장은 없었습니다.

• 자료를 외부 AI에 보내도 되는 범위는 어디까지인가?

• 프로필에 확인되지 않은 경력을 넣지 않으려면 어디에서 멈춰야 하나?

• 장비 검색 결과를 실제 예약 가능성처럼 말하지 않으려면 어떤 표시가 필요한가?

• 중간에 멈췄다면 다음 날 어디서 다시 시작해야 하나?

이 질문의 답이 프롬프트와 대화 안에만 있으면, 프로젝트는 한 번의 성공 사례로 끝납니다. 저는 그 프로젝트를 Hermes에서 계속 쓸 수 있는 작업 습관으로 바꾸고 싶었습니다.

🛠️ 사용한 도구

• Hermes Desktop — 작업 순서, 승인 기록, 로컬 파일 확인, 대시보드 검증

• Hermes Skills — 반복할 연구 단계를 각각의 작업 규칙으로 분리

• Codex 실행(omx exec) — 승인된 범위에서 프로필·아이디어·설계·계획서 산출물 생성

• Node 테스트와 브라우저 — 대시보드 API와 실제 표시 결과 검증

여기서 Hermes의 스킬은 “AI에게 더 똑똑한 답을 시키는 마법 주문”이 아닙니다. 특정 작업을 할 때 지켜야 하는 순서, 출력 형식, 위험한 지점, 확인 기준을 적어 둔 재사용 가능한 작업 매뉴얼에 가깝습니다.

🔧 작업 과정

1. 프로젝트의 기능을 그대로 옮기지 않고, 작업의 책임을 나눴다

처음에는 기존 프로젝트의 흐름을 하나의 큰 스킬로 만들 수도 있었습니다. 하지만 그러면 다시 긴 프롬프트 하나가 모든 결정을 떠안게 됩니다.

그래서 역할을 나눴습니다.

그리고 이 단계를 묶어 주는 상위 스킬을 따로 만들었습니다. 상위 스킬의 역할은 글을 잘 쓰는 것이 아니라, 다음 단계로 가도 되는지 판단하는 것입니다.

2. “자동 진행”의 뜻을 다시 정했다

연구 자동화에서 가장 위험한 말은 “AI가 다 알아서 해준다”일 수 있습니다.

연구자료에는 경력증명, 계약 문서, 학위자료처럼 민감한 내용이 섞일 수 있습니다. 장비 검색에는 실제 보유 여부와 예약 가능성의 차이가 있습니다. 연구계획서에는 활성 공고나 최신 문헌 없이 확정하면 안 되는 내용이 있습니다.

그래서 자동 진행의 뜻을 이렇게 바꿨습니다.

한 번 승인한 동일 자료·동일 처리 범위에서는 반복해서 진행한다. 하지만 새 민감 문서, 외부 AI 전송, 웹 검색, 예약·결제·제출 같은 새로운 영향이 생기면 멈춰서 확인한다.

이 규칙은 run.json이라는 실행 장부에 남습니다. 브라우저가 기억하는 상태가 아니라, 실행 폴더 안의 파일이 “지금 어느 단계까지 끝났는지”를 알려 줍니다.

그래서 중간에 멈춰도 “대화 기억을 더듬어서 이어가기”가 아니라, 상태 파일과 산출물을 확인하고 이어갈 수 있습니다.

3. 새 run을 실제로 끝까지 다시 돌렸다

스킬을 만들었다고 바로 믿지 않았습니다. 기존 자료를 같은 범위에서 다시 처리해 새 실행을 만들었습니다.

자료 116건을 등록하고, 텍스트를 추출하고, 스캔본을 이미지화한 뒤, 연구자 프로필·아이디어 후보·연구설계·장비 계획·ZEUS 근거·연구계획서·내부 심사·최종 감사까지 연결했습니다.

결과는 “완벽한 계획서”가 아니었습니다.

• 장비 21개 중 필수 17개를 정리했지만, 실제 접근성은 전부 미검증

• 내부 심사는 74점에서 81점으로 올랐지만, 근거 공백 때문에 더 점수를 올리려는 문장 수정은 멈춤

• 최종 감사는 WARN

처음에는 경고가 아쉬워 보일 수 있습니다. 하지만 여기서 WARN은 “실패”보다 훨씬 정직한 결과입니다. 활성 NRF 공고, BNNT 합성 조건, 안전 설비, 실제 장비 접근, 최신 문헌, 예비 데이터가 확인되지 않았는데 “준비 완료”라고 쓰지 않았기 때문입니다.

AI가 확신하는 문장보다, 확인하지 못한 것을 확인하지 못했다고 남기는 구조가 필요했습니다.

4. 결과를 한 번에 보기 위해 로컬 대시보드를 만들었다

사용자 요청은 간단했습니다.

"그럼 이러한 결과물을 한번에 볼수 있는 대시보드를 만들어줘 너가 스킬을 실행하면 자동으로 갱신되는"

대시보드는 실행 결과를 모아 보여 주지만, 연구 산출물을 공개 서비스에 실으면 안 됩니다. 그래서 로컬에서만 열리는 대시보드로 만들었습니다.

스킬이 파일을 저장하면 대시보드는 8초마다 그 파일을 다시 읽어 최신 상태를 보여 줍니다. 프로필, 설계 목표, 장비 공백, ZEUS 근거, 계획서, 심사 이력, 감사 결과를 한 화면에서 볼 수 있습니다.

중요한 건 이 대시보드가 연구자료의 원문을 인터넷에 보여 주는 창이 아니라는 점입니다. 로컬 개발 플래그가 모두 있어야 작동하고, 배포 환경에서는 연구 산출물 API 자체가 404로 닫히게 했습니다.

5. 진짜 사용해 보니 [object Object]가 나왔다

여기서 예상하지 못한 장면이 나왔습니다. 새로 만든 스킬은 기존 프로젝트보다 더 풍부한 JSON을 만들었습니다. 예를 들어 예전에는 프로필 요약이 한 줄 문자열이었다면, 이제는 문장·근거 상태·출처를 함께 담은 묶음이었습니다.

그런데 대시보드는 예전 형식만 알고 있었습니다. 그래서 화면에 이렇게 나왔습니다.

[object Object]

심사 이력도 실제로는 두 번 있었는데, 파일 형식이 배열로 바뀌면서 화면은 “심사 이력이 없습니다”라고 말했습니다.

이건 AI가 결과를 못 만든 문제가 아니었습니다. 만든 결과의 구조와, 그 결과를 보여 주는 화면의 약속이 달라진 문제였습니다.

수정할 때도 화면에서 억지로 객체를 글자로 바꾸지 않았습니다. API에서 최신·기존 산출물을 모두 사람이 읽는 형태로 바꾸도록 했습니다.

• 프로필 객체에서는 요약 문장을 꺼내고

• 가설 객체에서는 핵심 가설을 꺼내고

• 목표 객체 배열에서는 목표 문장만 모으고

• 장비 공백에서는 “무엇이, 왜 미확정인지”를 한 문장으로 만들고

• 심사 이력은 배열형과 묶음형 모두 읽게 했습니다

그다음 실제 브라우저에서 [object Object]가 사라졌는지, 심사 점수 74/100·81/100이 보이는지 확인했습니다.

✅ 결과 (After)

Before vs After

실제 검증

• 새 run의 9개 단계 완료 확인

• 내부 심사: 74/100 → 81/100

• 최종 감사: WARN

• 전체 앱 테스트: 459 passed / 0 failed

• 실제 API·브라우저 검증: 객체 문자열 없음, 심사 이력 정상 표시, 콘솔 오류 없음

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 기존 프로젝트를 버리지 않고, 반복되는 판단만 꺼내 스킬로 만들기

   • 앱 전체를 다시 만들 필요는 없었습니다. 이미 작동하던 흐름에서 “매번 다시 판단해야 하는 부분”을 찾아 스킬로 분리했습니다.

2. AI의 글쓰기와 작업 순서를 분리하기

   • 좋은 문장을 생성하는 것과, 다음 단계로 넘어가도 되는지 판단하는 것은 다른 일입니다. 후자는 상태 파일과 검증기로 맡겼습니다.

3. ‘확인 필요’를 실패로 보지 않기

   • 근거가 부족하면 결과를 비워 두거나 경고를 남기는 편이, 그럴듯한 확정 문장을 만드는 것보다 낫습니다.

4. 새 스킬은 반드시 실제 자료로 다시 실행하기

   • 문서상으로는 맞아 보여도, 실제 run에서는 JSON 구조와 화면 계약이 어긋날 수 있습니다.

5. 버그를 화면에서 덮지 말고 데이터 경계에서 고치기

   • [object Object]는 CSS 문제가 아니라 API가 데이터 계약을 정리하지 않은 문제였습니다. 원인을 API 경계에서 해결하니 기존·신규 산출물을 함께 지원할 수 있었습니다.

이렇게 하면 안 돼요

1. “자동화니까 다음 단계도 AI가 확정해도 된다”라고 생각하지 않기

   • 자동 실행 범위와 외부 영향 범위는 분리해야 합니다.

2. “대시보드에 보이니까 데이터도 맞겠지”라고 믿지 않기

   • 실제 파일, API 응답, 브라우저 표시를 각각 확인해야 합니다.

3. 경고를 없애기 위해 근거 없는 문장을 추가하지 않기

   • WARN을 없애는 방법은 문장을 세게 쓰는 것이 아니라, 실제 공고·장비·문헌·예비 근거를 확보하는 것입니다.

🌍 다른 업무에 적용한다면?

• 인사·경력 문서 정리: 업로드 → 사실 추출 → 확인 필요 항목 → 이력서 초안 → 감사처럼 단계화할 수 있습니다.

• 지원사업·제안서 준비: 공고 확인 전에는 범용 초안으로 두고, 공고가 확인되면 그때만 요구 형식에 맞게 좁힐 수 있습니다.

• 사내 반복 보고: 자료 수집·초안·검토·승인·배포를 각 스킬로 나누면, 담당자가 바뀌어도 같은 규칙으로 이어갈 수 있습니다.

• 민감 문서 자동화: 원문을 공개 서버에 올리지 않고, 로컬 run과 로컬 대시보드로 관찰할 수 있습니다.

🚀 앞으로의 계획

이번 작업으로 “기존 프로젝트를 Hermes 스킬로 옮기는 방법”은 실제 run에서 검증했습니다. 다음은 WARN을 문장으로 지우는 일이 아니라, 활성 공고·장비 접근·안전 조건·최신 문헌 같은 실제 근거를 확인해 계획서의 빈칸을 채우는 일입니다.

그리고 대시보드는 감사 결과가 Markdown 원문처럼 보이는 부분을 더 읽기 쉬운 요약으로 다듬을 수 있습니다. 다만 이것도 화면만 바꾸기 전에, 어떤 정보가 실행 판단에 필요한지부터 정리할 예정입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 기존 프로젝트에서 스킬 후보 찾기

지금 있는 프로젝트에서, 매번 반복되지만 대화·프롬프트 안에 흩어져 있는 작업 규칙을 찾아줘.
각 규칙을 다음으로 나눠줘.

1. 작업 단계, 2) 필요한 입력, 3) 만들어야 할 산출물, 4) 다음 단계로 가기 전 검증, 5) 반드시 사람 승인이 필요한 외부 영향 작업.
   앱 기능을 그대로 복제하지 말고, 재사용 가능한 스킬 단위로 제안해줘.

프롬프트 2: 자동 진행 범위 정하기

이 워크플로우에서 자동으로 진행해도 되는 범위와, 반드시 멈춰서 확인해야 하는 범위를 분리해줘.
새 민감 문서, 외부 AI 전송, 웹 검색, 로그인, 예약, 결제, 발송, 제출은 별도 범주로 표시해줘.
“자동화”가 근거 없는 확정이나 외부 실행을 뜻하지 않도록 승인 규칙을 작성해줘.

프롬프트 3: 대시보드 데이터 계약 점검

파일 기반 워크플로우 산출물을 대시보드로 보여 주고 있다.
최신 산출물 JSON과 API 응답, 프런트엔드 렌더러를 비교해 객체형·배열형·문자열형 데이터 계약이 어긋난 곳을 찾아줘.
[object Object], 비어 있는 목록, 잘못된 “없음” 표기가 재발하지 않도록 API 경계의 정규화 규칙과 회귀 테스트를 제안해줘.