🏆 AI스터디 23기 3주차 베스트 사례 큐레이션 - 개발&에이전트

📚 23기 에이전트하네스

✍️ 스킬 하나 만들었더니 9개가 얽혔다-문장 분석 AI에 ‘한 번에 하나만 고르는 라우터’를 만든 과정

유피테르

하려던 것 📝

• 복잡한 AI 스킬들을 의미 체계로 라우팅한 사례

• 문장과 글을 깊이 분석하는 AI 스킬을 만들고 인접한 9개 스킬이 언제 연결되어야 하는지를 재설계하고자 하였음

• 사용자의 “글 분석” 요청이 실제로는 다양한 작업을 포함하여 AI가 요청하지 않은 일을 수행하거나 스킬 선택에 어려움이 발생하는 문제를 해결하고자 하였음

• 기존의 스킬 목록 중심 접근 방식으로는 실제 업무 흐름에서 어떤 스킬부터 시작하고 언제 다음 스킬로 넘어가야 할지 알기 어려운 문제를 해결하고자 하였음

• 서로 다른 폴더와 용도에 흩어진 관련 스킬을 하나의 의미 체계로 연결하고, 과잉 분석 없이 현재 요청의 산출물에 맞는 스킬 하나만 선택하는 라우터(분기 도구)를 구축하고자 하였음

활용한 툴 ⚒️

• Hermes Agent / TARDIS : 스킬 조사·작성·실행·검증·범주화 조율에 활용함

• Hermes Skill 시스템 : 반복 가능한 분석 절차와 라우팅 규칙 저장에 활용함

• 기존 로컬 스킬 (포정해우, 식소사번, 상앙식 차등반응, 법률 검토, Humanizer 등) : 역할 비교에 활용함

• Hermes Skills Hub와 공개 저장소 : Copy Editing, Summsi, Word Counter 등 외부 후보 조사에 활용함

• 스킬 패밀리 레지스트리 : 스킬 범주·책임·조건부 연결을 사람이 읽고 프로그램도 검사할 수 있는 목록으로 저장에 활용함

• 검증 스크립트와 새 Hermes 세션 : 형식·참조·실제 라우팅을 독립적으로 시험에 활용함

진행 세부 내용 🔍

1️⃣ 문법 교정기가 아니라 ‘근거 중심 판독기’를 만들었다 - `sentence-text-analysis`라는 이름의 새 스킬을 만들었음. - 문장층부터 검증층까지 8개 층위를 구분하여 근거 중심의 판독기로 설계하였음. - 판단 전에 정확한 구절을 근거로 제시하고, 텍스트에서 직접 보이는 것과 해석한 것을 분리하는 등 4가지 핵심 원칙을 적용하였음. - 막연한 "문장이 어색하다"는 평가를 "근거 구절 → 관찰 가능한 문제 → 가능한 해석 → 독자 영향 → 최소 수정 → 보존 여부"와 같은 구체적인 형식으로 변화시켰음.

2️⃣ 실제 예문에서 ‘뜻을 바꾸지 않는지’ 시험했다 - 새 Hermes 세션을 열어 서로 다른 실패 유형을 시험하였음. - 지시어 중의성, 표본 확대 등 8개 유형의 재검증용 사례를 만들었으며, 대표 사례 2개를 시험하여 스킬이 대상을 임의로 확정하지 않고 가능성을 분리하는 등 정확하게 작동함을 확인하였음. - `민수는 준호에게 보고서를 전달한 뒤 그가 수정해야 한다고 말했다` 예문에서 `그가`의 대상을 임의로 확정하지 않고 두 가능성을 나누어 최소 수정안을 제안하는 결과를 얻었음. - `세 명의 이용자가 새 절차를 불편해했다. 따라서 이 제도는 모든 이용자에게 실패했다` 예문에서 `세 명`에서 `모든 이용자`로 범위가 확대된 점과 `불편함`에서 `제도 실패`로 판단 강도가 높아진 점을 분리하여 "알 수 없음"으로 남겨 논리 비약을 판단하였음.

3️⃣ 유사 스킬을 찾았더니 기능은 많았지만 관계가 보이지 않았다 - `유사한 스킬을 검색해서 리스트업해봐` 프롬프트를 사용하여 로컬 스킬, Hermes Skills Hub, 공개 저장소를 함께 살폈음. - 포정해우, Humanizer, Copy Editing 등 6개 후보 스킬의 강점과 새 스킬과의 관계를 분석하였음. - 조사 결과, 새 스킬과 완전히 같은 범위의 외부 스킬은 찾지 못했으며, 대부분은 문체, 요약, 가독성, 교육 평가처럼 한 영역에 집중하는 경향을 보였음.

4️⃣ 전환점 — “식소사번 스킬은 어디 있어?” - 사용자의 `식소사번 스킬은 어디있어?`라는 질문을 통해 기존 목록 중심 접근의 한계를 발견하였음. - 식소사번 스킬은 실제로 설치되어 있었으나, ‘비슷한 기능’만 찾고 ‘다음 단계의 관계’를 보여주지 못한 분류 실패였음을 깨달았음. - 문제는 스킬의 부재가 아니라, 서로 다른 폴더와 용도에 흩어진 스킬들을 하나의 의미 체계로 보여주지 못한 것이었음을 파악하였음.

5️⃣ 폴더를 옮기지 않고 의미상 5개 범주를 만들었다 - `이런 관련스킬을 범주화시킬수는 없나?`라는 요청에 따라 기존 스킬 경로와 파일은 그대로 두고, 별도의 의미 레지스트리를 만들었음. - 텍스트 판독, 사실개발·정보추출, 잠재기준·차등반응, 법률 논증·검토, 표현·문체·정보구조 편집 등 5개 범주를 정의하고 9개 설치 스킬을 포함시켰음. - 범주화의 목적은 보기 좋은 목록이 아니라, 현재 요청에 맞는 하나의 1차 스킬을 고르는 것이었음.

6️⃣ “관련 스킬을 모두 불러오지 않는다”는 라우터를 만들었다 - 사용자의 승인을 받은 뒤 `text-reasoning-router`를 만들었음. - `현재 요청에서 당장 필요한 산출물을 판별 → 1차 스킬 하나 선택 → 실행 → 실제 인계 조건 발견 시에만 다음 스킬 추가`의 핵심 원칙을 설정하였음. - '계약서', 'AI', '증인' 등의 주제어만으로 전문 스킬을 자동 호출하지 않고, 주제어가 아니라 이번 단계에서 사용자가 받아야 할 산출물을 기준으로 라우팅하는 원칙을 수립하였음. - '계약 조항의 수식 범위'는 문장·글 분석으로, '이 조항이 판례상 무효인지 검토'는 법률 검토로 라우팅하는 등의 예시를 통해 산출물 기반 라우팅 방식을 구현하였음.

7️⃣ 스킬 간 연결에 이름과 조건을 붙였다 - 스킬이 관련되어 있다는 정보만으로는 실행 순서를 정할 수 없어, 12개의 조건부 인계에 관계 유형과 발동 조건을 각각 붙였음. - '문장·글 분석'에서 '문제가 문장보다 문서 전체 배열에 있음' 조건으로 '가치우선 재배열' 스킬로, '결론을 좌우하는 사실이 사람에게만 있음' 조건으로 '식소사번' 스킬로 연결하는 등의 대표 연결 규칙을 설정하였음. - 법률용어가 있다는 이유만으로 법률 검토를 시작하지 않는 등 잘못된 자동 연결을 막는 규칙도 추가하였음.

8️⃣ 실제 경계 사례 8개로 라우터를 시험했다 - 새 Hermes 세션에서 헷갈리기 쉬운 8개 요청을 `text-reasoning-router`로 분류하여 시험하였음. - '계약 조항의 수식 범위'는 문장·글 분석으로, '모순을 확인할 반대신문 질문'은 식소사번으로, '뜻을 유지한 AI 문체 제거'는 Humanizer로 분류되는 등 모든 시험 요청이 기대한 1차 스킬과 일치하는 결과를 얻었음. - 포정해우에서 이미 문서 전체 구조와 결정적 정보공백을 찾았고, 그 정보가 회의 참석자의 직접 경험에만 있는 상황도 별도로 시험하여, 라우터가 포정해우를 다시 실행하지 않고 식소사번을 선택함을 확인하였음.

9️⃣ 잘못된 참조가 조용히 지나가지 않도록 고장 상황을 시험했다 - 스킬 이름 변경이나 삭제 시 발생하는 문제 방지를 위해 검증 스크립트를 만들었음. - 검증기는 모든 범주에 실제 스킬이 하나 이상 있는지, 9개 구성 스킬이 실제로 설치돼 있는지, 모든 연결의 출발점과 도착점이 존재하는지 등 7가지 항목을 확인하도록 하였음. - 존재하지 않는 가짜 스킬(`missing-sentinel-skill`)을 임시로 레지스트리에 넣어 검증기가 이를 즉시 탐지하고 실행을 중단하는 것을 확인하여 정상 차단되었음.

📚 23기 데이터대시보드

✍️ 재테크 공부는 처음이라... 일단 PRD부터 만들었습니다.

잔마왕

하려던 것 📝

• AI를 활용하여 기업 실적 발표 전후 주가 분석 및 시각화 파이프라인 구축 사례

• 재테크 공부와 AI를 접목하는 도전을 시작함.

• 공공 데이터 활용을 통해 의미 있는 분석을 할 수 있을지 고민함.

• 학습 목적으로 부동산 데이터의 단위 금액이 너무 크다고 판단하여 주식/거시경제 분석으로 방향을 전환함.

• 기업 재무데이터와 주가를 엮는 팩터 분석을 통해 데이터 수집, 시각화, 분석 과정을 익히고자 함.

• 기업 실적 발표 시점 전후 주가 움직임을 파악하고, 이를 시각화하는 것을 목표로 설정함.

활용한 툴 ⚒️

• Claude Code: PRD 문서 기반 파이프라인 개발 및 오류 수정에 활용함.

• Claude: PRD 문서 작성, DART API 사전 준비 가이드 요청, 종목 추천, 가이드 문서 작성에 활용함.

진행 세부 내용 🔍

• 1️⃣ 과제 선택 및 표본 설계

• 시도한 방법: AI를 재테크 공부에 접목하고자, 부동산 분석에서 주식/거시경제 분석으로 방향을 전환함. '기업 재무데이터와 주가를 엮는 팩터 분석'을 최종 주제로 선정함.

• 얻은 결과: 파일럿 프로젝트로 5개 종목, 최근 3년(12개 분기)을 분석 기간으로 설정함. 삼성전자, NAVER, KB금융, LG화학, 오리온 등 성격이 다른 5개 종목을 Claude에게 추천받아 선정함.

• 2️⃣ PRD (제품 요구사항 문서) 작성

• 시도한 방법: Claude Code에게 개발을 맡기기 전, 요구사항을 명확히 하기 위해 PRD 작성을 결정하고 AI에게 생성을 요청함.

• 사용한 프롬프트: PRD 문서 기반으로 프로그램을 만들어 달라는 요청을 수행함. (게시글에 명시된 구체적인 프롬프트는 없음)

• 얻은 결과: 종목 선택, 데이터 수집, 분석, 시각화 기능, 비기능 요구사항, 마일스톤(M1~M6), 리스크 항목 등을 포함한 PRD 문서를 완성함.

• 3️⃣ DART API 사전 준비

• 시도한 방법: 재무데이터 소스로 DART를 활용하기 위해 필요한 사전 준비 작업을 Claude에게 문의하고 가이드에 따라 실행함.

• 얻은 결과: opendart.fss.or.kr 회원가입 및 인증키 신청을 완료함. DART의 8자리 고유번호인 `corp_code` 매핑을 위해 `corp_code.xml`을 준비하고, `dart-fss` 또는 `OpenDartReader` 라이브러리 사용을 결정함. 정기보고서 재무정보 및 공시서류검색 API 그룹을 파악하고 응답 형식 특이사항을 확인함.

• 4️⃣ 파이프라인 개발 (삼성전자 단일 종목)

• 시도한 방법: PRD 문서를 Claude Code에 입력하여 개발을 요청하고, 삼성전자 1종목으로 전체 파이프라인(M1~M4)을 완성하는 것을 목표로 설정함.

• 발생한 문제와 해결 방법:

- `data.go.kr` API가 403 Forbidden 오류를 반환하여 사용 불가 문제가 발생함. `FinanceDataReader`를 대안으로 사용하여 주가 및 KOSPI 지수 데이터를 수집하도록 계획을 변경하여 해결함. - DART `corp_code`가 CSV 캐싱 시 앞자리 0이 사라지는 문제 발생. pandas 캐싱 시 `dtype=str`을 명시하여 `corp_code`를 문자열로 유지함으로써 해결함. - DART 분기 실적 계산 로직 오류: 반기보고서의 특정 필드를 잘못 해석하여 숫자가 비정상적으로 계산됨. DART 응답 원본을 확인하여 필드 의미를 정확히 파악하고, 4분기는 사업보고서 금액에서 3분기 누적치를 역산하는 방식으로 로직을 수정하여 해결함. - DART 계정명 불일치 문제: '당기순이익'이 분기/반기보고서에서 다른 계정명으로 잡힘. 계정명 후보 목록을 두고 순서대로 시도하는 방식으로 코드를 개선함.

• 얻은 결과: `earnings_cli.py --stock 005930` 한 줄로 실행 가능한 파이프라인을 성공적으로 구축함. DuckDB에 공시, 종목 시세, KOSPI 지수 등 3종의 raw 테이블을 캐싱함. 이벤트 윈도우(D-5~D+5) 평균 CAR 곡선, 서프라이즈 그룹별 비교, 산점도 등 Plotly 인터랙티브 HTML 3종을 시각화함. 9개 분기 이벤트 기준 평균 CAR 1.10%, 표준편차 2.37% 등의 구체적인 분석 결과를 얻음.

• 5️⃣ 실행 가이드 문서 작성

• 시도한 방법: 완성된 파이프라인의 실행 방법이 다소 복잡하여, 사용 편의성을 위해 AI에게 가이드 문서 생성을 요청함.

• 얻은 결과: AI가 생성한 가이드 문서를 통해 사용자가 구축된 파이프라인을 쉽게 실행할 수 있도록 지원함.

📚 23기 AI결과물검수

✍️ 근거가 없으면 기권하라고 만든 시스템인데, 그 논문의 수치 120개 중 27개는 근거를 못 찾았습니다

Fri-mer

하려던 것 📝

• AI 검수 시스템의 보이는 신호에 속아 병목을 겪은 사례

• AI 에이전트(Claude Code)가 서로 지적하고 인정하는 모습을 검증으로 착각하여 불필요하게 단계가 늘어나는 문제가 발생함을 인지함

• 자신이 작성한 사례글에서 측정 오류 71건이 발생했으나, 이 모두 사람의 수동 검수로 잡혔음을 인지함

• AI 검증 과정의 비효율성을 해소하고, 측정 오류를 효과적으로 식별하며, 사람이 병목이 되는 상황을 개선하고자 함

• 기존 연구 저장소의 평가 하네스 시스템을 분석하여 문제 해결의 단서를 찾고, 효과적인 AI 활용 및 검수 시스템 구축 방안을 모색하고자 함

활용한 툴 ⚒️

• Claude Code: 코드 작성 및 수정, 스터디 사례글 분석

• Python 3: 사례글 "시행착오" 항목 세기, 측정 오류 유형 분석, 문체 위반 검사, 지식 베이스 구축 (AKM 과제)

• re (정규식): 텍스트에서 특정 패턴(시행착오 항목) 추출 및 개수 세기에 활용함

• CrossRef: 인용 검증 케이스의 정답(Ground truth) 가져오는 데 활용함

진행 세부 내용 🔍

• 1️⃣ 사례글의 "시행착오" 항목 세기

• Python 정규식을 사용하여 자신이 작성한 사례글의 "시행착오" 항목을 찾아 개수를 셈

• `m = re.search(r'\\*\\*시행착오\\*\\*(.*?)(?=\\*\\*앞으로의 계획\\*\\*|\\Z)', text, re.S)` 및 `n = len(re.findall(r'^\\s*-\\s', m.group(1), re.M))` 코드를 활용함

• 정규식으로 `-`로 시작하는 줄만 세어, 여러 줄 항목이나 하위 목록을 정확히 세지 못하는 문제가 발생했으며, 이는 '대략의 수'임을 인지함

• 총 33편의 사례글에서 71건의 시행착오 항목이 발견되었으며, 편당 평균 2.2건의 시행착오가 발생했음을 확인함

• 2️⃣ 어떤 종류였나

• 발견된 71건의 시행착오를 유형별로 분류함

• '기준이 너무 느슨했다', '검색어가 다른 것에 걸렸다', '총계가 구성을 감췄다', '사본을 개수로 셌다', '경계 검출이 뒤를 삼켰다', '폴더를 내용으로 착각' 등의 6가지 유형으로 분류됨

• 3️⃣ 이 71건은 어떻게 잡혔나

• 71건의 시행착오가 어떤 방식으로 발견되었는지 분석함

• '숫자가 기대보다 잘 나와서 의심', '한 항목만 크게 튀어서 의심', '아는 개수와 안 맞아서 확인', '문맥을 열어 봐서'와 같이 사람의 직관과 수동적인 재확인을 통해 모두 잡혔음을 확인함

• 4️⃣ 자동으로 잡히는 것은 무엇이었나

• 측정 오류 외에 도구가 자동으로 잡아낸 항목이 있는지 확인했음

• 문체 점검의 경우, 검사 스크립트 도입 전 44건의 문체 위반이 있었으나, 도입 후 0건으로 줄었음을 확인함

• 문체는 규칙이 명확하여 코드로 옮길 수 있었으나, 측정 오류는 '숫자가 이상하면'과 같이 규칙으로 옮기기 어려웠음을 인지함

• 5️⃣ 범위를 넓혀 보니 정답지가 이미 있었다

• 스터디 폴더와 경제 파이프라인 외에 본업인 연구 저장소 두 곳의 평가 하네스를 분석하여 비교했음

• 연구 저장소에는 'reproducibility_pilot', 'critic_pilot', 'citation\_verifier' 총 3개의 평가 하네스가 존재함을 발견했으며, 이 하네스에는 58건의 케이스 중 55건이 기대값(expected)을 가지고 있었음을 확인함

• 검사기를 검사하는 `mutation_check.py` 스크립트도 3개 존재하며, CrossRef에서 정답을 가져오는 인용 검증 케이스도 발견하여 '정답지가 없다'는 초기 가설과 상반되는 결과였음을 인지함

• 6️⃣ 그 하네스는 실제 사건을 몇 건 잡았나

• 연구 저장소의 케이스 중 실제 사건을 재현한 것과 하네스가 이를 잡아낸 비율을 분석했음

• 실제 사건 케이스 8건 중 스코어러가 잡은 것은 2건에 불과했으나, 못 잡은 6건은 `expected_is_a_miss`라는 필드로 '못 잡는다'고 명시되어 있었음을 확인함

• 이는 발표 사례에서 언급된 '사람이 확인하세요'라는 표시와 같은 역할을 하고 있었음을 인지함

• 7️⃣ 그러면 무엇이 진짜 없는 것인가

• 연구 저장소와 자신이 진행한 사례글 측정 방식을 비교하여 차이점을 분석했음

• 사례글 측정에는 정답지, 못 잡는 것의 표시, 검사기 검사 장치가 없음을 확인했으며, 이 차이는 '틀렸을 때 무슨 일이 벌어지는가' 즉, 결과의 무게와 정확히 일치함을 깨달음

• 8️⃣ 발표 사례의 해법과 대 보기

• 발표 사례에서 제시된 해법(규칙이 명확한 것은 코드 게이트로, 판단이 애매한 것은 사람에게 넘긴다는 표시, 정답이 있는 것은 정답지와 대조)과 자신의 상황을 비교했음

• 자신의 71건의 측정 오류는 '판단이 애매한 것'에 속하나, 이를 '사람에게 넘긴다는 표시'를 해둔 적이 없음을 확인함

• 9️⃣ 같은 자리에서 막힌 사람이 또 있었다

• 스터디 채팅 로그를 다시 읽어보며, 유사한 문제를 겪는 다른 참가자들의 사례를 확인했음

• '문항 뽑고 답 달아 검증'하는 수동 정답지 생성 사례와, '인박스에 몇백 개 쌓이고 수동 의사결정으로 인해 병목'이 발생하는 사례를 확인했으며, 이는 자신의 71건의 수동 검수와 같은 구조임을 통해 사람이 판단 칸에 서면 병목이 발생함을 재확인함

• 🔟 공식 과제로 A·B·C를 돌려 보기

• AKM 2주차 과제에 맞춰 '첫 작업에서 남긴 판단이 두 번째 작업에 실제로 쓰였는지'를 검증하기 위해 실제 작업(강의 자막으로 사례글 작성 후 채팅 로그로 갱신)을 프롬프트 A·B·C 구조로 분석했음

• MY_TASK, MY_FIRST_SOURCES, MY_NEW_SOURCE, MY_CONTEXT, MY_OUTPUT_ROOT 다섯 가지 값으로 작업 내용을 정의함

• 채팅 읽기 전 쓴 사례글에서 '다시 쓸 판단 6개'를 Knowledge v1으로 추출했으며, Knowledge v1을 먼저 읽은 후 채팅을 읽자, '인용 전 발화자 확인', '자격증명 검사', '구어체 그대로 인용' 등의 판단이 사전에 적용되어 읽는 순서가 달라졌음을 확인함

• Knowledge v1의 6개 판단 중 5개가 v2에서 재사용되었고, 1개는 새 Source(채팅)로 인해 수정되었음을 확인했으며, '비용이 낮은 것과 문턱이 없는 것은 다르다'는 판단이 채팅 로그를 통해 틀렸음이 드러났고, 해당 부분만 수정했음

• 기존 Source 재독 없이 작업이 이루어졌음을 확인하며, smarthome-case-v1.md 등 최종 작업 결과물 파일을 산출하였고, 최종 판정은 PASS로 결정됨

📚 23기 24시간AI서버

✍️ 비개발자와 AI가 도장(道藏) 원문 검색기를 함께 만든 과정

nomadmeve

하려던 것 📝

• AI 에이전트와 대화하며 도교 원문 검색 도구를 개발한 사례

• 도교 원문을 연구에 활용하기 위함.

• 도장 원문에서 경전명, 저자를 찾고 본문 검색 및 실제 원문 행 위치까지 확인할 수 있는 도구를 구현하고자 함.

• API, Docker, Cloudflare, local LLM 같은 기술들의 연결을 이해하고, 자신의 연구 과제에 적용 가능한 도구를 만들고자 함.

활용한 툴 ⚒️

• Hermes Agent의 Pulses: 전체적인 개발 흐름 정리, 구현 및 검증 작업의 분리, 사용자 대화 기반의 개발 협업에 활용함.

• Qwen Code, Codex, AGY의 AI review lane: 코드 작성 및 수정, 개발 과정 중 발생하는 오류를 독립적으로 검토하여 찾아내고 해결하는 데 활용함.

• local Ollama 모델: Reader 기능 내에서 특정 문단을 한국어로 번역하는 보조 기능에 활용함.

• 자동 테스트, 실제 브라우저, 휴대폰 확인, 독립 AI 검토: 개발된 기능이 올바르게 작동하는지 확인하고 문제점을 발견하며 개선하는 데 활용함.

진행 세부 내용 🔍

1️⃣ “AI가 바로 답하는 도구”보다 원문 검색 1단계부터 만들기로 함 - 시도한 방법: AI 에이전트 Pulses의 조언에 따라, AI가 내용을 요약해주는 최종 단계 대신 원문 검색 및 위치 확인 기능을 제공하는 기본 검색 도구를 먼저 개발하기로 결정함. - 얻은 결과: 원문 목록, 경전명/저자/본문 검색 기능, 그리고 검색 결과에서 원문의 상대경로와 물리적 행 위치를 확인할 수 있는 초기 DaoCanon API를 구현함. 원문 파일은 수정하지 않고 검색 결과와 AI 해석은 원문을 가리키는 보조 층으로 설정함.

2️⃣ “양이 많으니 느리지 않을까?”라는 질문에서 corpus 실측이 시작됨 - 시도한 방법: 검색 속도에 대한 우려를 표하자 Pulses는 즉시 괜찮다고 답하는 대신, 약 1,700여 개의 Markdown 파일로 구성된 실제 DaoCanon corpus를 조사함. - 얻은 결과: 조사 결과에 따라 검색 결과에 단순한 제목 대신 경전마다 고유한 ID, 상대경로, 물리 행 위치를 포함시켜 사용자가 검색 결과가 어느 원문인지 정확히 되짚을 수 있도록 기능을 개선함.

3️⃣ 테스트가 다 통과했는데도, AI 검토가 여러 번 실패를 찾아냄 - 발생한 문제: 검색 API와 화면의 자동 테스트가 모두 통과했음에도 독립 검토 AI가 화면이 실제 API에 없는 정보를 보여주거나, URL 경로 처리 문제, 화면 업데이트 시점 불일치, 작은 화면에서 원문 경로 사라짐, 가로 스크롤 생성 등 여러 문제점을 찾아냄. - 해결 방법: Pulses는 구현 worker의 보고를 그대로 믿지 않고 테스트와 화면을 재검토하여 구현 방식을 수정함. 사용자 또한 중간 결과를 직접 확인하고 불명확한 부분을 다시 질문하여 수정 과정을 거침. - 얻은 결과: 단순한 목업이 아닌 실제 원문을 검색하고 다시 열 수 있는 기능을 갖춘 화면으로 DaoCanon을 발전시킴.

4️⃣ “검색 결과에서 경전으로 들어가고 싶다”는 한 문장이 Reader를 엶 - 시도한 방법: 검색 결과가 나오지만, 결국 경전 원문을 읽고 싶은데 목록에서 멈추는 것에 대한 부족함을 느껴 Pulses에게 검색 결과에서 경전으로 바로 들어갈 수 있는 기능 추가를 요청함. - 얻은 결과: Pulses는 사용자의 "더블클릭" 요청을 바탕으로 클릭 및 키보드 Enter로도 진입 가능하게 구현함. 제목/저자 검색은 경전의 첫 행으로, 본문 검색은 실제 일치한 행으로 이동하는 Reader 기능을 구현하여 연구 메모가 원문 확인으로 이어지도록 함.

5️⃣ Docker와 공개 접속은 “먼저 열기”가 아니라 “한 단계씩 확인하기”였음 - 시도한 방법: Cloudflare나 Caddy 같은 공개 접속 기술을 먼저 시도하기보다, 원문 검색 및 Reader 완성 → Docker로 실행 단위 정리 → Tailscale로 휴대폰 확인 → Cloudflare Tunnel 공개 경로 구성의 순서로 단계를 나누어 진행함. - 발생한 문제: 초기 Caddy basic auth는 사용자 이름과 비밀번호를 모두 요구하여 사용성이 불편했음. - 해결 방법: 사용자 편의를 위해 비밀번호만으로 로그인할 수 있는 단일 비밀번호 로그인 gate를 별도로 만들어 보안과 사용성을 함께 고려한 해결책을 적용함.

6️⃣ 번역 기능은 “원문을 바꾸지 않는 보조”로 만듦 - 시도한 방법: 간체-번체 변환 기능과 특정 문단을 복사하여 한국어로 번역하는 기능 추가를 요청함. - 발생한 문제: 번역된 글자가 원문 검색 근거와 섞일 경우 원문 출처가 모호해질 수 있다는 문제점을 인지함. - 해결 방법: "표시는 바꿀 수 있으나, 검색·행 위치·인용 근거는 원문에 남긴다"는 원칙을 세워 간체/번체 변환은 Reader의 보이는 글자만 변경하고, 한국어 번역은 원문을 자동으로 고치지 않고 local Ollama 모델로 특정 문단만 번역하는 보조 기능으로 구현함.

7️⃣ 모델을 비교하고, 다음 날 번역 장애를 함께 해결함 - 시도한 방법: 네 개의 로컬 모델을 직접 비교하여 `gemma4:12b`와 `gemma4:26b`를 운영 모델로 선정함. - 발생한 문제: 다음 날 "한국어로 번역" 버튼 클릭 시 "요청을 완료하지 못했습니다. API 상태를 확인해 주세요." 메시지가 반복적으로 발생함. - 해결 방법: Pulses와 함께 Docker 컨테이너 내의 번역 서비스에서 host의 Ollama로 이어지는 연결 경로, 그리고 재부팅 후 사라진 방화벽 예외를 차례로 확인하여, 컨테이너에서 Ollama로 가는 좁은 연결 경로가 막힌 것이 원인임을 찾아냄. 해당 경로에 영구 규칙을 적용하여 번역 기능을 다시 정상화함.

📚 23기 스마트홈AI

✍️ 선풍기에 영혼 불어넣기 — 조립보다 길었던 AI·아두이노 연결기

준PM

하려던 것 📝

• Gemini AI와 Arduino를 연동하여 감정 반응형 선풍기를 구현한 사례

• 음악에 반응하고 사용자의 스트레스 지수를 분석하여 바람으로 조절하는 분노조절선풍기를 만드는 것이 목적임.

• 방구석에 있던 USB 선풍기에 Gemini AI를 얹을 아이디어를 구체화하고, Arduino UNO 및 필요한 부품을 준비하는 것이 배경이었음.

• 부품 배송 지연에도 불구하고 MOSFET을 제외한 나머지 파이프라인(PC-시리얼 통신-Arduino-OLED/LED)을 완성하여 단계적으로 검증하고, AI가 물리적인 장치에 표정을 짓고 음악에 반응하게 하는 것을 해결하고자 함.

활용한 툴 ⚒️

• Gemini (2.5 Flash): 사용자 텍스트 감정 분석 및 음악 비트 감지 결과에 따른 선풍기 표정 결정 목적으로 활용함.

• Python (sounddevice, NumPy, google-genai, serial): Gemini API 연동, 음악 RMS 계산, Arduino와 시리얼 통신 제어 목적으로 활용함.

• Arduino UNO: OLED 및 LED 제어, PC로부터 시리얼 명령 수신 목적으로 활용함.

• Arduino IDE (2.3): 펌웨어 업로드, 라이브러리 설치 (Adafruit SSD1306, Adafruit GFX), I2C 진단 스케치 작성 목적으로 활용함.

• Adafruit SSD1306, Adafruit GFX, Adafruit BusIO 라이브러리: OLED 디스플레이 제어 목적으로 활용함.

진행 세부 내용 🔍

1️⃣ MOSFET은 없지만, 할 수 있는 것부터 시작함 - 시도한 방법과 접근 방식: 주문한 MOSFET 모듈의 배송이 지연되어, 해당 부품을 제외한 나머지 파이프라인(PC → 시리얼 통신 → Arduino → OLED/LED)을 먼저 검증하기로 결정함. 실제 팬 속도 대신 Arduino 13번 내장 LED를 켜고 끄는 방식으로 펌웨어를 제작하여 출력부를 대체함. - 발생한 문제와 해결 방법: MOSFET 부품 지연으로 실제 팬 제어가 불가능했으나, LED를 임시 출력으로 사용하여 소프트웨어와 통신 문제를 먼저 해결할 수 있도록 작업 흐름을 조정함. - 얻은 결과나 피드백: 하드웨어 부품 지연에도 불구하고 소프트웨어와 통신 문제를 먼저 파악하고 해결할 수 있었으며, 나중에 MOSFET이 도착하면 마지막 출력부만 연결하면 되는 구조를 확립함.

2️⃣ OLED 선 네 가닥, 드디어 AI가 표정을 지음 - 시도한 방법과 접근 방식: 도착한 0.96인치 OLED 모듈을 암-수 점퍼선 네 개를 사용하여 Arduino UNO에 직접 연결함 (GND-GND, VCC-5V, SCL-A5, SDA-A4). Arduino IDE에 `Adafruit SSD1306` 및 `Adafruit GFX` 라이브러리를 설치하고, PC에서 `200,MUSIC` 또는 `255,ANGRY`와 같은 `속도,표정` 형태의 명령을 받아 OLED에 표정 태그를 표시하고 내장 LED를 제어하는 펌웨어를 업로드함. - 사용한 프롬프트나 코드: OLED-Arduino 연결 배선 (GND-GND, VCC-5V, SCL-A5, SDA-A4)을 적용함. PC에서 `200,MUSIC`, `255,ANGRY`, `0,IDLE` 형식의 한 줄 명령을 Arduino로 전송함. - 얻은 결과나 피드백: 펌웨어 업로드 직후 OLED에 `AI FAN / Waiting PC...` 메시지가 성공적으로 나타나, AI가 물리적인 얼굴을 얻는 첫 번째 단계가 완료됨.

3️⃣ Python 파일은 왜 실행조차 안 됐을까 - 시도한 방법과 접근 방식: Gemini와 Arduino를 연결하기 위한 PC Python 스크립트를 실행하여 테스트를 시작함. - 발생한 문제와 해결 방법: - 음악 RMS 계산에 사용하는 NumPy가 Anaconda의 Intel MKL 라이브러리와 충돌하여 `_multiarray_umath` DLL 로드 오류가 발생함. `pip uninstall -y numpy` 후 `pip install --force-reinstall numpy mkl mkl-service` 명령으로 재설치하여 문제를 해결함. - Python 코드가 `PORT = 'COM3'`으로 설정되어 있었으나, 실제 Arduino 호환 보드는 `USB-SERIAL CH340`으로 COM7 포트에 연결되어 있었음. Windows의 포트 목록을 확인하여 실제 포트 번호(COM7)를 알아내고, 포트를 특정 번호로 고정하지 않고 CH340 또는 USB 시리얼 장치를 자동 탐지하도록 코드를 수정함. - 콘솔 출력 시 오류를 알리는 `❌` 이모지가 Windows CP949 콘솔에서 `UnicodeEncodeError`를 일으켜, 이모지를 `[OK]`, `[오류]`, `[안내]`와 같은 안전한 텍스트로 교체하여 해결함.

4️⃣ 한 번은 열리는데 두 번째는 안 열린다: CH340의 함정 - 발생한 문제와 해결 방법: COM 포트를 올바르게 지정한 후에도 프로그램을 종료하고 다시 실행하면 `Cannot configure port`, `can't set com-state` 오류가 발생함. USB를 뺐다가 다시 꽂으면 COM8이라는 새 번호로 첫 연결은 성공하지만, 닫았다가 다시 열면 동일한 문제가 반복됨. - 시도한 방법과 접근 방식: Windows 장치 상태와 드라이버를 확인한 결과, CH340 드라이버 3.9.2024.9 버전과 특정 CH340 칩의 호환 문제임을 파악함. Arduino 공식 도움말에서 이전 버전 `3.7.2022.1` 설치를 안내하는 것을 확인하고 해당 드라이버를 받아 설치함. - 얻은 결과나 피드백: 이전 버전 드라이버 설치 후, 같은 COM8 포트를 연속으로 두 번 열어 `0,IDLE` 명령을 성공적으로 전송함. Python 코드 문제가 아닌 USB 시리얼 드라이버 호환 문제였음을 확인하며, 하드웨어 프로젝트에서 운영체제 드라이버 관리의 중요성을 학습함.

5️⃣ Gemini는 대답했지만, 새 API 키로 대답한 건 아니었음 - 시도한 방법과 접근 방식: Gemini API 키를 소스 코드에 직접 노출하지 않기 위해 Windows 사용자 환경변수 `GEMINI_API_KEY`에 저장하여 사용함. - 발생한 문제와 해결 방법: 테스트 중 SDK가 `Both GOOGLE_API_KEY and GEMINI_API_KEY are set. Using GOOGLE_API_KEY.` 경고를 출력하며, 기존에 설정된 `GOOGLE_API_KEY`를 새 키보다 우선 사용하는 문제가 발생함. - 사용한 프롬프트나 코드: 테스트 문장으로 `I am frustrated because of a bug.`을 입력하여 Gemini의 감정 분석을 시도함. - 얻은 결과나 피드백: 프로그램 실행 중 기존 `GOOGLE_API_KEY`를 제외하고 `GEMINI_API_KEY`를 확실히 사용하도록 수정하고, 새로 연 터미널이 아니어도 Windows 사용자 환경변수 저장소에서 키를 직접 읽을 수 있도록 보완함. Gemini 2.5 Flash가 테스트 문장을 스트레스 80%, 팬 속도 200, 표정 `ANGRY`로 판단하여 `200,ANGRY` 명령이 COM8로 전송되고 OLED와 내장 LED가 반응하는, 사용자 감정 기반 첫 번째 모드가 완성됨.

6️⃣ 음악이 들려오쟎아, 넌 왜 반응하지 않니 - 시도한 방법과 접근 방식: 음악 비트 감지 모드를 테스트함. - 발생한 문제와 해결 방법: - 음악을 틀어도 오류는 없었지만 Arduino가 아무 반응이 없었음. 기존 음량 계산 방식(`np.linalg.norm(indata) * 10`)과 임계값(15)이 현재 PC 마이크의 실제 신호에 비해 너무 높았고, `sounddevice.InputStream`이 스피커 재생음이 아닌 마이크로 들어오는 소리를 듣는다는 점을 간과함. - RMS 계산 방식을 표준 `rms = float(np.sqrt(np.mean(np.square(indata))))`으로 변경하고, 이 PC에서 측정한 마이크 잡음과 실제 소리 크기를 바탕으로 기본 임계값을 `0.0002`까지 낮춤. - 프로그램이 침묵하지 않도록 현재 입력 장치와 실시간 음량을 1초마다 보여주게 수정하여 디버깅을 용이하게 함. - 사용한 프롬프트나 코드: `rms = float(np.sqrt(np.mean(np.square(indata))))`으로 RMS 계산 로직을 변경함. - 얻은 결과나 피드백: 실제 음악을 틀어 테스트하자 RMS 값이 기준을 넘었고 `MUSIC` 명령이 Arduino로 정상 전달되어 두 번째 모드(음악 반응)가 정상 작동함. 음악이 멈춘 뒤 0.7초가 지나면 `0,IDLE`을 보내 OLED와 출력 상태도 자동으로 초기화되도록 구현함.

7️⃣ 끝난 줄 알았는데 OLED가 까맣다: 기록과 실물은 다를 수 있다 - 발생한 문제와 해결 방법: 두 모드가 터미널에서는 정상 작동했으나, 완성된 상태를 사진으로 확인하던 중 실제 OLED 화면이 꺼져있는 것을 발견함. 배선 확인, MOSFET 연관성 검토(독립된 부품 확인), OLED 패널 불량, I2C 주소 불일치, 펌웨어 문제 가능성을 점검함. 프로젝트 폴더에 Arduino의 `.ino` 원본 파일이 없어 현재 보드에 업로드된 스케치를 재현할 수 없는 문제가 발생함. - 시도한 방법과 접근 방식: - Arduino IDE에 포함된 CLI와 설치된 라이브러리(Arduino AVR 코어, `Adafruit SSD1306`, `Adafruit GFX`, `Adafruit BusIO`)를 확인하고, OLED 전용 진단 스케치를 직접 작성하여 COM8에 업로드함. 이 스케치는 A4/A5의 모든 I2C 주소를 검색하고 발견된 장치를 SSD1306으로 초기화한 뒤 화면에 테스트 문구와 카운터를 표시하도록 함. - 진단 스케치 실행 결과 `I2C_FOUND:0x3C`, `DIAG_RESULT:OLED_INIT_OK`, `HOST_RESULT:OLED_COMMUNICATION_OK`가 명확히 나타났고, OLED 화면에 `OLED TEST OK`, 주소 `0x3C`, 증가하는 숫자가 표시되어 OLED 하드웨어, 전원, 배선 모두 정상임을 확인함. - 진단이 끝난 뒤 Python 명령 규격(`200,ANGRY` 등)과 연결되는 제어 펌웨어 `smart_fan_controller.ino`를 새로 작성하여 OLED 표정, 상태 문구, 속도 숫자 및 막대 표시, 내장 LED 제어 기능을 구현함. 처리한 명령은 `ACK:200,ANGRY`처럼 PC로 회신하도록 함. - 얻은 결과나 피드백: 진단용 스케치와 실제 제어 스케치를 모두 `아두이노` 프로젝트 폴더에 저장하여 원본 펌웨어를 보관하는 중요성을 학습함. 복원된 펌웨어로 다섯 가지 명령을 연속으로 보낸 결과 모든 명령이 확인되었고 마지막에는 다시 대기 화면으로 돌아오는 것을 확인함.

📚 23기 내업무에이전트

✍️ 23기 내업무에이전트_2주차 과제_AI한테 작업 기록을 남겼더니 생긴 일

달리는거북

하려던 것 📝

• AI를 활용하여 사내 실적 관리 대시보드를 구축하고 보안을 강화한 사례

• 스터디 과제로 실질적인 업무 활용이 가능한 대시보드를 만들고자 함.

• 팀별 사업 계획, 달성률, 인건비 등을 한 화면에서 볼 수 있는 대시보드를 구축하고자 함.

• 회사 자료의 보안 문제로 인해 지정된 사용자만 접근 가능하도록 제한하고자 함.

• AI와의 장기 작업 시 매번 맥락을 다시 설명하는 비효율성을 개선하고자 작업 기록 시스템을 구축하고자 함.

활용한 툴 ⚒️

• Claude Code (모델: Claude Opus) : 터미널 환경에서 코드 작성 및 명령 실행, 웹 화면 메뉴 탐색, 시스템 구조 제안, 작업 기록 자동 생성 등 프로젝트 전반에 걸쳐 활용함.

진행 세부 내용 🔍

• 1️⃣ 캡처 이미지를 활용한 웹 화면 메뉴 탐색

• 가짜 데이터로 웹 화면을 구축하고 데이터베이스를 연결하는 작업을 수행함.

• 배포 설정 과정에서 웹 화면의 특정 메뉴(variables)를 찾지 못하여 작업이 중단되는 문제에 직면함.

• "I can't find menu "vairables" I captured screen and download this in "download folder""라는 프롬프트를 사용하여 AI에게 상황을 설명하고 캡처 파일을 제공함.

• AI가 다운로드 폴더에 저장된 캡처 파일을 직접 열람하여 화면 내용을 분석하고, 다음에 클릭할 버튼을 정확히 지시하여 문제를 해결함.

• 2️⃣ 이중 잠금장치 구현 및 로그인 테스트 제한 경험

• AI의 제안에 따라 실제 데이터를 넣기 전에 이중 잠금장치부터 구현하는 보안 우선 접근 방식을 채택함.

• 로그인하지 않으면 화면 진입이 불가하고, 로그인하더라도 명단에 없으면 데이터 접근이 불가하도록 두 겹의 보안 시스템을 구축함.

• 로그인 기능 구현 후 로그인 링크 클릭 시 대시보드로 이동하지 않고 로그인 화면으로 돌아오는 문제가 발생하여 코드를 수정함.

• 사용 중인 무료 서비스의 로그인 메일 확인이 하루 2번으로 제한되어, 수정된 로그인 기능의 정상 작동 여부를 즉시 확인할 수 없었으나 AI가 "코드는 고쳤지만 눈으로 확인은 못 했습니다"라고 기록에 남겨 신뢰를 주었음.

• 3️⃣ AI 작업 기록 창고 자동 생성

• AI와 작업 중 지난 맥락을 매번 새로 설명하는 데 지쳐, 자동으로 갱신되는 작업 기록 창고를 만들기로 결정함.

• 스터디장님의 가이드에 따라 다음 프롬프트를 활용하여 기록 시스템을 구축함: "> 오늘 한 작업을 기록으로 남겨줘. 다음에 네가 읽고 바로 이어서 일할 수 있을 정도로 적어줘. 1) 오늘 실제로 한 일(확인까지 끝난 것) 2) 했지만 눈으로 확인 못 한 것 — 반드시 "확인 불가"로 표시 3) 겪은 문제와 해결 방법 4) 다음에 이어서 할 일 확인하지 않은 것을 확인한 것처럼 쓰지 마라."

• 목차, 시간순 기록, 원문 보관함, 주제별 정리 페이지로 구성된 7개 페이지의 기록 창고가 AI에 의해 자동으로 생성되었으며, 미확인 항목은 "확인 불가"로 명시함.

• AI가 저장소의 공개 상태를 먼저 지적하고, 기록이 외부에 공개되지 않도록 제외 설정과 경고 문구까지 넣어주는 능동적인 역할을 수행함.

📚 23기 반려에이전트

✍️ 헤르메스에 제미나이 Notebook 연동하기

엘레나

하려던 것 📝

• Hermes 에이전트 기능을 활용해 Gemini Notebook을 연동하여 작업 가능성을 탐색한 사례

• Hermes로 할 수 있는 작업들을 깊이 있게 이해하고 탐색하는 것을 목적으로 함.

• Hermes의 잠재적인 활용 가능성을 더욱 확장하고자 하는 고민이 배경이 됨.

• Gemini Notebook에 Hermes Agent 관련 소스를 축적하고 이를 Hermes와 연동하여 다양한 활용 방안과 새로운 작업 가능성을 발견하고자 함.

활용한 툴 ⚒️

• Gemini Notebook: Hermes Agent 관련 리서치 소스 추가 및 소스 기반의 질문 답변에 활용함.

• Hermes Agent (Hermes): Gemini Notebook과 연동하여 소스 기반 질의응답 및 작업 수행에 활용함.

• Grabbit 크롬 확장 프로그램: YouTube에서 'Hermes Agent use cases' 관련 영상 소스를 검색하고 추가하는 데 활용함.

진행 세부 내용 🔍

1️⃣ Hermes Agent 관련 자료 수집 및 통합 - 시도한 방법: Gemini Notebook을 활용하여 'Hermes Agent'에 대한 정보를 리서치하고 소스를 추가함. - 시도한 방법: Grabbit 크롬 확장 프로그램을 사용하여 유튜브에서 'Hermes Agent use cases' 관련 영상 소스를 검색하고 Gemini Notebook에 통합함. - 얻은 결과: Hermes Agent의 개념 및 활용 사례에 대한 다양한 자료가 Gemini Notebook에 축적됨.

2️⃣ Hermes Agent 활용 가능성 탐색 - 시도한 방법: Gemini Notebook에 추가된 소스를 기반으로 Hermes Agent로 수행할 수 있는 작업들을 채팅을 통해 문의함. - 얻은 결과: NotebookLM을 Hermes Agent와 연동하여 사용할 수 있다는 중요한 정보를 확인함.

3️⃣ NotebookLM 스킬 연동 지시 - 사용한 프롬프트: `NotebookLM 스킬 사용하고 싶어!` - 얻은 결과: Hermes Agent가 사용자의 기본 봇 프로필(도라에몽)에 스킬을 설치하도록 안내하는 피드백을 제공함.

4️⃣ NotebookLM 스킬 설치 및 로그인 - 사용한 프롬프트: `도라에몽에 설치해줘!` - 사용한 프롬프트: `로그인 진행해줘.` - 얻은 결과: NotebookLM 스킬이 성공적으로 설치되고, 로그인 절차를 통해 Hermes Agent와 NotebookLM의 연동이 완료됨을 확인함. 연동 후 다양한 작업을 수행할 수 있는 기능을 사용할 수 있게 됨.

5️⃣ 연동된 NotebookLM 기반 정보 활용 - 사용한 프롬프트: `에몽아 헤르메스 에이전트 노트북 자료를 근거로 강의용 핵심 요약과 아이디어를 만들어줘.` - 얻은 결과: NotebookLM에 저장된 '헤르메스 에이전트' 관련 자료를 기반으로 강의용 핵심 요약 및 아이디어를 성공적으로 생성함을 확인함. - 사용한 프롬프트: `에몽아 '헤르메스 에이전트' Notebook을 기반으로 헤르메스에서 활용할 수 있는 새로운 기능을 소개해줘. 내가 시도해본 내용이 아닌 전혀 새로운 내용으로, 노트북LM과 같은 스킬도 좋아` - 얻은 결과: NotebookLM의 소스 정보를 활용하여 Hermes에서 적용 가능한 새로운 기능들을 효과적으로 제안함을 확인함.