[실밸개발자] 바이브코딩 클럽

EXECUTIVE SUMMARY

오늘의 흐름을 먼저 한 번에 보기

요약전날 대화는 PDF/RAG 파싱, AI 포트폴리오, 로컬 AI 인프라, 하네스·Hermes 운영, 지식공유 커뮤니티, 브라우저 에이전트, AI 작업 피로감까지 이어진 고밀도 실무 토론이었습니다. 시스템/중복/가벼운 잡담은 제외하고 Main 8개, Mini 6개, Watch 3개로 재구성했습니다.

구성

Main 8 · Mini 6 · Watch 3

대화량

메시지 990건 · 발화자 94명 · 링크 12건

카테고리

RAG·문서 파싱 1AI 포트폴리오·채용 1로컬 AI·인프라 1하네스·에이전트 운영 1Hermes 운영 설계 1AI 작업 문화·지식공유 1AI 에이전트 브라우저 1AI와 일의 경계 1보안·계정 리스크 1모델·임베딩 1학습 자료 1기획·자연어 인터페이스 1AI 브라우저 후보 1Codex 사용 형태 1장애·한도 1글쓰기 페르소나 1원격제어 기능 변화 1

핵심 카드 빠르게 보기

PDF 파싱 논의는 Docling 병목에서 MarkItDown·Nougat·멀티모달 Markdown 파이프라인 비교로 확장됐다
AI 엔지니어 포트폴리오는 RAG 챗봇 하나보다 AgentOps·상태관리·평가·직무 리서치가 핵심이라는 조언으로 정리됐다
로컬 AI 논의는 메모리 자랑보다 보안·성능·GB300급 투자 대비 성과를 따지는 온프레미스 의사결정으로 모였다
oh-my-claude·슈퍼파워스 질문은 “도구 추천”보다 과제별 하네스와 Spec Driven Development 운영법으로 깊어졌다
헤르메스 프로필 질문은 프로젝트별 기억을 나누되 개발자 피드백과 보완 루프까지 넣어야 한다는 운영 설계로 답이 났다

PDF 파싱 논의는 Docling 병목에서 MarkItDown·Nougat·멀티모달 Markdown 파이프라인 비교로 확장됐다

한줄 결론지수님도 문서/카톡/리포트 파이프라인에서 “파서 하나 선택”보다 샘플셋+정확도 기준+재시도 루프를 먼저 고정하는 쪽이 안전합니다.

왜 중요했나가장 긴 초반 흐름은 문서 파싱을 단순 툴 선택이 아니라 RAG 품질·속도·검증 루프 문제로 재정의한 대화였습니다.

무슨 일이 있었나

발단은 Docling과 MinerU로 PDF를 처리하던 사용자가 속도 병목과 남은 물량을 토로한 질문이었습니다. 답변은 곧 JSON 파싱보다 LLM이 읽기 쉬운 Markdown 파싱, 표·이미지에는 OCR/멀티모달 보강이 필요하다는 방향으로 이동했습니다.

응답 과정에서 MarkItDown, Nougat, Unstructured, 라마파스류 도구가 후보로 언급됐고, 순수 LLM 파싱은 변질 우려가 있으므로 구조화 변환 도구와 검증을 조합해야 한다는 선이 그어졌습니다.

전개는 RAG의 정의까지 넓어졌습니다. “문서를 찾아 넣기”가 아니라 지식 노드, 에이전트 RAG, 평가 데이터셋, NDCG 같은 성능 루프를 함께 설계해야 한다는 설명이 이어졌습니다.

실무 결론은 하나의 파서에 장기간 고착하지 말고 문서 유형별로 변환 후보를 나눠 샘플 평가셋으로 비교하라는 것입니다. 표·이미지·논문·일반 텍스트를 같은 기준으로 밀어붙이면 시간만 녹습니다.

용어 쏙쏙 2개

NDCG검색/추천 결과의 순위 품질을 재는 지표
Agentic RAG검색·출처·검증·행동을 에이전트 루프 안에 넣는 구조

적용 1차 출처 있음

지수님 포인트

지수님도 문서/카톡/리포트 파이프라인에서 “파서 하나 선택”보다 샘플셋+정확도 기준+재시도 루프를 먼저 고정하는 쪽이 안전합니다.

왜 이 액션인가

지수님도 문서/카톡/리포트 파이프라인에서 “파서 하나 선택”보다 샘플셋+정확도 기준+재시도 루프를 먼저 고정하는 쪽이 안전합니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

도구 인텔리전스

MarkItDown high

Wikipatterns/rag_document_parsing_eval.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 14개 보기

00:07DV/Antigravity
추가로, 100에 100 같은 대답을 하게 만들려면 평가 데이터셋을 만들어놓고 반복 수행해서 검증 루프를 만드는게 좋은데요! 이 경우 NDCG Score 라는 메트릭을 정의하고 여기에 맞게 평가 데이터를 준비해서 반복 수행하며 성능 높혀보시는것도 추천드립니다.
00:10우푸/클코
현재 조금 더 트렌디한 기술은, 렝을 활용한 노트라인, 새컨드브레인 구성을 통하여 에이전트 RAG 형태에요 ㅎㅎ
00:16다시시작한 개발자
코덱스랑 대화가좀 필요하겠네요.. 이제 더이상 docling 은 못하겠더라고요.. 한달이상 docling 을 했는데도 문서가 많이 남아서..
00:19우푸/클코
저도 옜날에 RAG할 때는 .. 그냥ㅋㅋ 도클링으로 돌리는게 정통 같은 느낌이었는데
00:21우푸/클코
제 인사이트가 정확하진 않겠지만.. 언스트럭처드 : 단순 텍스트 백터 임배딩 용으로 최고였어요 ㅎ! Nougat : 아직 안써봤지만, 학술 논문에 좋다고 들었어요! 마킷다운 : 요즘 많이 사용하신다고 들 합니당! ㅎㅎ 라마파스..였나.. 라파스였나? : 이거 테이블이나 차트 잘 읽는대요!
00:25우푸/클코
RAG 도메인을 가지고 계신 분을
00:28다시시작한 개발자
다시 ㅋrag 로 오던데.. 탈출 되나요?
00:29우푸/클코
그래도 이게 LLM이나 RAG
00:36우푸/클코
제가 막 이렇게 우다다다다 하는 편이 아닌데.. RAG 도메인을 가지고 계신 분을 최근에 만난적이 없어서 조금 신나서 우다다다다 했습니다ㅠ ㅎㅎ 실례가 있었다면 사과드려요 ㅠㅠㅎ
00:40우푸/클코
RAG는 사람을 위한 챗봇
00:42우푸/클코
RAG도
00:45우푸/클코
RAG를 단순한 검색 파이프라인으로만 이해하면, 앞으로의 AI Agent 구조를 제대로 설계하기 어렵습니다. 제가 최근 집중해서 보고 있는 주제는 Agentic RAG입니다. 핵심은 RAG를 버리는 것이 아니라, RAG의 역할을 재정의하는 것입니다. 기존 RAG가 "문서를 찾아 LLM에 넣는 구조"였다면, Agentic RAG에서 RAG는 AI Agent가 판단하기 위한 evidence layer, verification layer, memory layer가 됩니다. 기존 RAG는 대체로 선형 구조입니다. 사용자의 질문을 embedding하고, Vector DB에서 top-k chunk를 검색한 뒤, 해당 context를 LLM에 넣어 답변을 생성합니다. 이 구조는 사내 문서 검색, FAQ, 정책 조회, 기술 문서 기반 Q&A에서는 여전히 유효합니다. 하지만 검색 결과가 충분한지 판단하지 못하죠. 잘못된 근거를 가져와도 스스로 의심하지 않습니다. 질문을 하위 문제로 분해하지 못합니다. 답변이 실제 근거에 충실한지 검증하지 않습니다. 그리고 사용자의 판단 기준이나 과거 실패에서 학습하지 못합니다. Agentic RAG, 질문을 바로 검색하지 않습니다. 먼저 질문을 하위 문제로 분해하고, 어떤 순서로 어떤 정보를 확인해야 하는지 계획합니다. Retriever는 단순히 Vector DB에서 top-k를 가져오지 않습니다. semantic search, keyword search, metadata filtering, knowledge graph, relational DB, internal API, external source를 목적에 맞게 조합합니다. Context Fusion은 검색된 자료를 그대로 LLM에 전달하지 않습니다. 중복을 제거하고, reranking하고, source attribution을 유지한 상태로 context를 재구성합니다. 중요한 것은 많은 context가 아니라, 판단 가능한 evidence package입니다. Reasoner는 근거를 기반으로 답변을 구성합니다. 단순 요약보다 중요한 것은 비교, 해석, 선택지 판단, 리스크 정리입니다. Critic 또는 Judge는 생성된 답변을 검토합니다. 질문에 충분히 답했는지, 근거가 약한 부분은 없는지, citation이 맞는지, 추가 retrieval이 필요한지 판단합니다. 기준에 미달하면 query rewrite 또는 추가 retrieval loop를 실행합니다. Memory Agent는 성공한 검색 전략, 실패한 질문, 사용자의 선호, critic rejection reason, 최종 답변 품질을 저장합니다. 이 계층이 있어야 시스템은 매번 초기 상태에서 답변하지 않고, 점점 더 조직과 사용자에 맞춰집니다. 이 구조에서 중요한 것은 state, evidence, trace, evaluation이 분리되어 관리된다는 점입니다. 같은 유형의 질문이 다시 들어왔을 때, 이전보다 더 나은 retrieval plan을 세울 수 있는가? 저는 이 지점에서 Enterprise Second Brain이 중요해진다고 봅니다. Second Brain은 단순한 문서 저장소가 아닙니다. 원문, 이미지, 회의록, 의사결정 기록, 프로젝트 맥락, 사람의 판단 기준, 실행 결과, 실패한 검색 trace가 함께 축적되는 지식 운영체계에 가깝습니다. Agentic RAG는 이 Second Brain 위에서 작동할 때 가장 큰 가치를 만듭니다. 단순히 문서를 찾아주는 AI가 아니라, 조직의 지식 구조를 기반으로 판단을 보조하는 AI가 됩니다. 사용자의 질문에 답하는 수준을 넘어, 근거를 검증하고, 누락을 감지하고, 의사결정의 품질을 높이는 방향으로 진화합니다. 다만 저는 처음부터 복잡한 agent graph를 만드는 방식에는 동의하지 않습니다. 실무 적용은 단계적으로 가야 합니다. 첫 번째는 Reliable Knowledge Base입니다. URL, 문서, 이미지, 첨부파일, 메타데이터, source hash, chunk, embedding, citation을 정확하게 저장해야 합니다. 원문과 출처가 보존되지 않은 RAG는 운영 환경에서 신뢰를 얻기 어렵습니다. 두 번째는 Quality-Gated RAG입니다. retrieval quality, reranking score, faithfulness, answer relevance, citation coverage, user feedback, evaluation set을 붙여야 합니다. 이 단계에서 RAG는 데모 수준을 넘어 운영 가능한 시스템이 됩니다. 세 번째가 Agentic Layer입니다. Planner, Critic, Tool Agent, Memory Agent, human approval gate를 붙입니다. 이 단계에서 시스템은 단순 검색을 넘어, 계획하고 검증하고 개선하는 구조가 됩니다. 결국 Agentic RAG의 핵심은 "AI Agent를 붙였다"가 아닙니다. - 답변 품질을 측정할 수 있는가. - 근거를 추적할 수 있는가. - 실패한 질문에서 학습할 수 있는가. - 사용자의 판단 기준을 반영할 수 있는가. - 조직의 지식이 시간이 지날수록 더 잘 구조화되는가. 이 질문들에 답할 수 있어야 합니다. 저는 앞으로의 AI/AX 시스템이 이 방향으로 갈 가능성이 높다고 봅니다. RAG는 사라지는 것이 아니라, AI Agent의 reasoning 구조 안에서 더 중요한 계층이 됩니다. 그리고 Enterprise Second Brain과 결합될 때, 단순한 문서 검색을 넘어 조직의 지식과 의사결정을 연결하는 시스템으로 확장됩니다. 검색 성능만 높은 시스템이 아니라, 근거를 다루고, 판단을 보조하고, 실패에서 학습하며, 조직의 Second Brain과 함께 성장하는 AI 시스템.
01:04다시시작한 개발자
Docling 일단락되니까는 파바박 다써버리더라고요.
01:06우푸/클코
RAG도메인은 냉담하게 이야기 하면, 독립적으로는 살아남을 수 없는 상태가 되었어요 ..ㅎ ㅠ

AI 엔지니어 포트폴리오는 RAG 챗봇 하나보다 AgentOps·상태관리·평가·직무 리서치가 핵심이라는 조언으로 정리됐다

한줄 결론지수님 관점에서도 채용/팀 세팅 조언을 볼 때 “RAG 만들었다”보다 평가·상태·승인·운영 로그가 있는지를 체크리스트로 삼는 게 좋습니다.

왜 중요했나취업 준비 질문은 단순 프로젝트 추천이 아니라 요즘 AI 엔지니어가 보여줘야 할 운영 경험 목록으로 확장됐습니다.

무슨 일이 있었나

발단은 백엔드+AI 취업 준비자가 포트폴리오 방향을 묻고, RAG를 써봤지만 챗봇 이상이어야 할 것 같다고 말한 지점입니다.

응답은 “RAG만 하면 불리할 수 있다”는 현실적인 조언으로 이어졌습니다. RAG는 도구 중 하나이고 데이터 엔지니어링 영역과 겹치므로, 개인 프로젝트에서는 정확도 개선·도메인 적응·평가 메트릭처럼 면접에서 설명 가능한 경험이 중요하다는 의견이 나왔습니다.

DV는 Idempotency, State Machine, Long Running Function, Human in the loop 같은 에이전트 운영 요소를 제시했습니다. 이는 기능 데모보다 장애·재시도·상태관리·사람 승인 같은 실제 제품화 문제를 다뤘는지를 보겠다는 뜻입니다.

전개 끝에는 가고 싶은 회사와 직무 리서치가 최우선이라는 결론이 붙었습니다. “AI 솔루션/시스템 배포”라는 넓은 말보다 특정 직무가 보는 경험에 맞춰 프로젝트를 좁혀야 합니다.

용어 쏙쏙 2개

Idempotency같은 작업을 여러 번 실행해도 결과가 안전한 성질
Human-in-the-loop중요 단계에 사람 검토/승인을 끼우는 설계

위키화 방 발언 기준

지수님 포인트

지수님 관점에서도 채용/팀 세팅 조언을 볼 때 “RAG 만들었다”보다 평가·상태·승인·운영 로그가 있는지를 체크리스트로 삼는 게 좋습니다.

왜 이 액션인가

지수님 관점에서도 채용/팀 세팅 조언을 볼 때 “RAG 만들었다”보다 평가·상태·승인·운영 로그가 있는지를 체크리스트로 삼는 게 좋습니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikipatterns/ai_engineer_portfolio_checklist.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 12개 보기

01:01Niniz Cheering
저는 백엔드+AI 영역으로 취업 준비중인데 괜찮은 포트폴리오/프로젝트가 없는 상태인데 어떻게 준비하는 게 좋을지 짧게나마 조언 부탁드려도 될까요? ㅠㅠ
01:06Niniz Cheering
혹시 요즘 현업에선 RAG를 어떻게 활용중이신가요?
01:07Niniz Cheering
포트폴리오 준비하면서 RAG도 사용하긴 했는데 챗봇이상의 프로젝트여야 할것같은 상황인듯해서요
01:09우푸/클코
알파튜닝 하이브리드 RAG 라는
01:15다시시작한 개발자
근데 포트폴리오로 rag를 하는건 시간이 너무 오래걸리는 작업이 아닐까요??
01:19DV/Antigravity
오히려 AI 엔지니어 생각하시면 RAG는 스케일보다는 모델 관점에서의 정확도 경험 하시는것도 유리해요! 모델 튜닝 통해 NDCG 메트릭 높혔다, Domain Adaptation 했다 등등...
01:25우푸/클코
역시 또 RAG로 돌아와버리기
01:26DV/Antigravity
ㅋㅋㅋ 그쵸 맞아요 일단 가고자 하는 회사와 하고픈 직무 리서치가 최우선입니다
01:27박스에 들어간 춘식이
RAG 좋죠
01:32우푸/클코
그리고, RAG가 최종적으로 TTS로 부드럽게 송출되는 것 까지
01:35Niniz Cheering
네 AI 도움도 많이 받고 있는데, 얼마전에 현재 CTO로 일하고 계신 분께 여쭤보니 RAG 등 이제 좀 오래된 기술이라 하시면서 그것보다 오픈소스나 임베디드가 그나마 취업할 가능성이 높다고 하셔서...
01:41DV/Antigravity
음 제 개인적인 의견은 잡리서치를 좀 더 해보시는게 좋을것 같습니다. 내가 나중에라도 되고 싶은 엔지니어들은 채용 시 어떤 경험들을 보는지 리서치를 해보시는게 좋을것 같아요. 링크드인 적극 활용해보시구요! 특정 영역에 선택과 집중을 하지 않으면 뚫기 어려운 문인데 AI 솔루션, 시스템 배포는 사실 너무 광범위한것 같아요. 제가 들어가는 신입/경력 면접의 경우 대부분의 질문은 에이전트 어디까지 만들어봤는지에 대한 질문들이 주로 구성되어있고 그 질문부터 시작하면 꼬리를 물고 어디든 전문 영역으로 들어갈 수 있어요. 이제는 많은 기술들이 에이전트의 툴로써 사용되니까요.

로컬 AI 논의는 메모리 자랑보다 보안·성능·GB300급 투자 대비 성과를 따지는 온프레미스 의사결정으로 모였다

한줄 결론지수님 운영에서도 로컬/온프레미스는 비용보다 데이터 경계·반복 시뮬레이션·자산화 요구가 있을 때만 우선순위를 높이는 게 맞습니다.

왜 중요했나오전 후반 대화는 Qwen 메모리, 임베딩 모델, 기업분석 RAG, 회사 보안, GB300 서버까지 이어지며 로컬 AI의 현실 조건을 드러냈습니다.

무슨 일이 있었나

발단은 로컬 모델과 메모리 사용량 이야기였습니다. Qwen3 8B VL, 35B/122B 모델, 임베딩 모델 용량 등이 언급되며 “메모리는 남는데 처리속도가 못 따라온다”는 실사용 감각이 공유됐습니다.

응답은 회사 환경과 보안 제약으로 옮겨갔습니다. 코드베이스나 데이터를 회사 밖으로 내보낼 수 없으면 로컬 모델을 쓰는 이유가 생기지만, 단순 비용 절감 목적이라면 클코/코덱스 같은 외부 모델이 더 낫다는 판단이 나왔습니다.

전개 중 GB300/B300 서버와 10만 달러 수준의 장비 이야기가 나왔지만, 오너 관점에서는 몇 달 안에 의미 있는 퍼포먼스가 나와야 한다는 ROI 압박도 같이 붙었습니다.

실무 결론은 “로컬이 멋지다”가 아니라 보안·온프레미스·내 자산화 중 최소 두 조건이 맞을 때만 헤르메스/로컬 조합이 설득력을 갖는다는 것입니다.

용어 쏙쏙 2개

온프레미스회사/개인 내부 인프라에서 직접 운영
GB300/B300NVIDIA 차세대 고성능 AI 서버·GPU 계열 맥락

추적 1차 출처 있음

지수님 포인트

지수님 운영에서도 로컬/온프레미스는 비용보다 데이터 경계·반복 시뮬레이션·자산화 요구가 있을 때만 우선순위를 높이는 게 맞습니다.

왜 이 액션인가

지수님 운영에서도 로컬/온프레미스는 비용보다 데이터 경계·반복 시뮬레이션·자산화 요구가 있을 때만 우선순위를 높이는 게 맞습니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikipatterns/local_ai_onprem_roi.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 13개 보기

10:52자랑하는 라이언 / 클코
RAG 모델 서빙 + OCR으로 사용중입니다 ㅎㅎ 128GB/4TB 모델이 840쯤 하지 않나요...? 로컬 모델 돌리실 것 아니면 너무 비싼 것 같은데...
10:53잘어잘어/클코
Qwen3면 좀 오래된 버전이긴하네요
10:54다시시작한 개발자
저는 m3 256gb 인데 122b 35b 8b qwen 3.5 2개를 올려도 메모리가 남는데;;
10:59잘어잘어/클코
Qwen3는 25년 4월 출시구요
10:59자랑하는 라이언 / 클코
Qwen3-VL-Embedding and Qwen3-VL-Reranker: For the Next Generation of Multimodal Retrieval 2026/01/08
10:59잘어잘어/클코
임베딩 모델이네요
11:11다시시작한 개발자
임베딩 전용 모델 좋습니다. ㅎ
11:35에어갭 / 클코
그래서 지금 M3라도 올려보려고 몸비트는 중이고, GPU가 확충되면 상황이 좀 나아질텐데 몇 달간 보릿고개가 너무 힘드네요
11:49하품하는 죠르디
음 우선 코덱스나 클코는 적은비용으로 접근가능하므로 보완등 특별한 이유가 없으면 로컬 모델로 만족스러운 퍼포먼스를 내기 어렵기 때문에 굳이 쓸 이유는 없을 것 같구요. 그리고 클로드 100불 200불 한도를 다 쓰지 못한다고 활용을 잘 못하는건 절대 아니라고 생각합니다. 200불 계정 여러개 쓴다는 사람들은 단순 산술적으로 생각하면 그만큼 몇배의 결과물을 내야하지만 막상 의미있는 아웃풋을 낸게 있는지 보면 그렇지 않은 경우도 많거든요. Ai 토큰 사용량이 많다고 ai잘 활용한다고 착각하는 경우도 종종있는데 결국 효과적인 아웃풋을 낼수있느냐가 중요한것 같습니다
11:55에어갭 / 클코
로컬 모델을 쓰는 이유는 보안때문이 맞습니다 ㅠ 코드베이스나 데이터를 회사 바깥으로 내는거에 대해 엄격하게 규제하고 있는 상황이구요
12:00렉스/클코
GB300 서버 있는 회사 알려줘 클로드야..
12:02에어갭 / 클코
우리나라에 올해 내로 B300 들어올 회사가... 몇 없을겁니다
12:13우푸/클코
헤르메스 에이전트 공홈에 이런저런 이야기들이 많고, 사용하시는 분들 마다 다 다르긴 하지만ㅎㅎ 저는 기본적으로 몇가지 조건이 있는 걸 정리해보자면 1. 반복 시뮬레이션이 필요할 때, 2. 온프레미스 일 때 (로컬모델 활용), 3. 내 자산으로 만들고 싶을 때, 중에 2개가 성립되면, 헤르메스를 사용해요 ㅎ! 단순히 편의성이나 퍼포먼스 위주라면, 사용하는걸 추천하지 않아용ㅎㅎ

oh-my-claude·슈퍼파워스 질문은 “도구 추천”보다 과제별 하네스와 Spec Driven Development 운영법으로 깊어졌다

한줄 결론지수님에게는 이 흐름이 Hermes skill/cron을 “프롬프트”가 아니라 스펙·검증·중단조건까지 포함한 하네스로 관리해야 한다는 확인 신호입니다.

왜 중요했나오후 핵심 흐름은 에이전트 도구를 무엇 쓰느냐가 아니라, 반복 과제를 어떻게 스펙·스킬·리뷰 루프로 묶느냐였습니다.

무슨 일이 있었나

발단은 oh-my-claude가 sub-agent를 병렬로 잘 돌리지만 토큰을 많이 쓴다는 사용기와, 슈퍼파워스·omc·지스택 중 어떤 하네스가 맞는지 묻는 질문이었습니다.

DV는 과제마다 하네스를 자체 세팅하고, 하나씩 붙여보며 iteration으로 성능을 높이면 나중에는 하네스 세팅을 위한 하네스까지 만들게 된다고 설명했습니다. 반복 작업과 페인포인트를 스킬화하되, 공통 스킬인지 프로젝트 전용인지 사람이 판단해야 한다는 기준도 붙었습니다.

전개는 팀 운영 사례로 확장됐습니다. TL이 초기 하네스를 세팅해 전파하고, 모든 코드 변경은 Spec 기반으로 하며 Spec에 반영되지 않은 변경은 PR에서 거절하는 원칙이 공유됐습니다.

메타하네스 시연과 레퍼런스 이야기도 나왔습니다. 실밸 프레임워크, 세컨브레인, revfactory 영감이 섞인 내부 하네스 사례가 등장하며 커뮤니티 안에서 운영 패턴이 재사용 지식으로 변환되는 모습이 보였습니다.

용어 쏙쏙 2개

SDDSpec Driven Development
하네스AI가 작업할 절차·검증·상태·도구를 묶은 실행 틀

적용 방 발언 기준

지수님 포인트

지수님에게는 이 흐름이 Hermes skill/cron을 “프롬프트”가 아니라 스펙·검증·중단조건까지 포함한 하네스로 관리해야 한다는 확인 신호입니다.

왜 이 액션인가

지수님에게는 이 흐름이 Hermes skill/cron을 “프롬프트”가 아니라 스펙·검증·중단조건까지 포함한 하네스로 관리해야 한다는 확인 신호입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikipatterns/agent_harness_sdd_operations.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 14개 보기

14:22K-외노자/클로드코드
이번에 oh-my-claude를 설치해서 새로운 개인 프로젝트를 진행해보았는데요 확실히 sub-agent들이 parallel로 잘 도는거같아서 플랜에 맞춰 나눈 테스크들이 빠르게 처리되는것 같은데 동시에 토큰이 살살 녹네요.. 근데 이 oh-my-claude를 사용하다보니 (물론 제가 또 이 위에 개인적으로 필요한 skill과 hook을 붙이긴했지만) 이게 진정 내가 하네싱을 짠게 맞나? 라는 생각이 들더라구요. 분명 oh-my-claude를 사용하지 못할 프로젝트들(예를 들면 회사 내 프로젝트들?)이 있으면 이제 아예 처음부터 프로젝트 성격에 맞게 하네스를 깎아 나가야할텐데 오히려 oh-my-claude를 지우고 하나씩 핸드온으로 붙여보는게 맞는건가 하는 의구심이 들더라구요. 비슷한 고민이 있으신분들의 고견을 듣고싶습니다 🙇‍♂️
14:34박스/클코
혹시 요즘도 다들 에이전트에 페르소나 세팅해놓고 쓰시나요? 개인적으로는 요즘 AGENT.md 로 충분하다 싶은데 다른 분들은 페르소나를 이펙티브하게 쓰고 계신지 궁금합니다.
14:35춘/코덱 클코
페르소나는 백그라운드 설명 상세히 하기 귀찮을때 쓰는거 아닌가요
15:04DV/Antigravity
저는 과제 들어갈때마다 하네스 세팅을 자체적으로 합니다. 하나씩 붙혀보고 iteration 돌면서 점진적 성능 개선 경험 한번 해보시면 그 다음부터는 하네스에 어떤걸 세팅할지가 금방 정리가 되어요! 나중엔 하네스 세팅을 위한 하네스도 만들게 됩니다
15:04토르/클코
주말에 진행한 실밸님 라이브에서 우푸님께서 하네스로 구축을 했는데 시간이 지나면서 하네스를 사용하지 않고 llm에 계속 물어보는 1인이었습니다 ㅎㅎ sdd로 구축하고 실밸님이 만들어준 하네스 돌리니까 완성도가 확실히 많이 올라가네요 하네스 이렇게 사용하는거군요…
15:23お金を撒くライアン/클로드코드
https://www.gseek.kr/course/online/computer/programming/coding/python-algorithm-basics
15:23お金を撒くライアン/클로드코드
https://www.gseek.kr/course/online/computer/programming/coding/python-automation-quickstart
15:41영주님/코덱스,클코
우푸님 헤르메스 관련해서 질문 드릴게 있습니다. 우푸님이 말씀하신게 프로젝트 1개당 1개의 헤르메스 프로필을 파서 거기에 지식 맥락을 기록관리 하라고 하셨잖아요? 그래서 저는 제가 개발중인 프로젝트 전용 헤르메스 프로필을 파고, 그 헤르메스 프로필에게 프로젝트 전용 옵시디언 볼트를 마운트 시키고 여기다가 맥락 기록 관리를 시키려고합니다. 그리고 코딩 작업은 헤르메스와 제가 직접 기획하고, 개선 방향을 충분히 얘기한뒤, 헤르메스에게 CODEX에다가 프롬프트 넣어서 작업 진행하라구 하려고 하구요 (코덱스에는 제가 프로젝트 안에 하네스 프레임워크를 설계 해둔 상태) 코덱스 세션에서 작업이 완료되면 훅 기능을 사용해서 옵시디언 볼트에 결과 기록 -> 헤르메스를 통해 결과 보고 받은 뒤 다시 개선점 기획하여 코덱스에게 명령 -> 실행 (반복) 이런식으로 운영하는게 어제 말씀하신 부분이랑 맞을지? 질문 드립니다!!
15:57DV/Antigravity
네네 매뉴얼하게 반복적인 일이 있을때 만들고 만드는 과정은 skill-creator를 사용합니다. 만들고자 하는 skill이 전반적인 하네스 공통인지 아닌지 사람이 판단하는 과정도 한번 있어요. 예를들어 ppt 만드는 스킬은 공통 요소는 아니고, git worktree 관리 스킬은 공통 스킬로 분류합니다. 공통 스킬의 경우 meta harness에 반영해요! 이 흐름을 좀 자동화 하면 좋을텐데ㅜ 아직 거기까지는 가질 못했네요ㅠ 거기까지 가기 위해 지금은 각 하네스에 observability 관측성 붙히고 있어요.
16:27멍한 프렌즈/클코
codex가 좋은데 258k 사이즈가 그지같아요 pro플랜도 258k에요
16:38DV/Antigravity
네 맞아요 md 파일로 관리합니다. 예를들어 application 아키텍쳐 바뀌면 app-architectire.md를 업데이트 하고, 해당 아키텍쳐에 코드 스니펫도 포함시켜요. 실제 코드가 이 아키텍쳐를 따라서 잘 개발됐는가는 Engineer, Architect 서브에이전트가 크로스체크해서 리뷰를 하고 PR 리뷰어는 에이전트와 이 코드를 제출한 사람을 믿고 넘어가요! 대신 E2E 테스트에 변경된 아키텍쳐에 대한 기능 테스트 결과도 첨부해야합니다. 이 md 파일은 초판을 PL이 만들어두고 배포를 하고, 이후 팀 개발을 통해 지속 업데이트를 해요.
16:43실밸개발자/클코
오 ㅎㅎㅎ 너무 궁금합니다 ㅋㅋ 메타하네스 만드는게 진짜 쉽지 않은데 팀에서 인기가 영향력이 아주 크시겠는데요..
16:45DV/Antigravity
md 파일은 사람과 에이전트 모두가 읽습니다. 설계서를 md로 관리하는 이유는 무엇보다도 설계의 변경을 git에서 사람이 확인하고 점검하기 위함이에요. 제가 들어가는 과제 중 이미 존재하는 설계서가 있는 과제일 경우 그 설계서의 내용을 사전에 md로 변환해서 누락없이 올려둡니다. 여러 문서가 md로 존재하는데, prd, adr, infra arch, solution arch, application arch, deployment meta(배포 할 인프라 정보), data spec, e2e test scenario 등등 하나의 기능 업데이트 시 업데이트 해야될 문서가 10개 이상이에요!
17:04실밸개발자/클코
와 ㅋㅋㅋㅋ 제가 거기에 있어서 영광입니다 ㅋㅋㅋ 메타하네스 저도 써봤는데 신기했어요 ㅋㅋ

헤르메스 프로필 질문은 프로젝트별 기억을 나누되 개발자 피드백과 보완 루프까지 넣어야 한다는 운영 설계로 답이 났다

한줄 결론지수님 쪽 Kakao/Hermes 자동화도 방별 리포트 산출 후 QA와 피드백을 위키에 쌓아 다음 cron 프롬프트를 고치는 루프가 핵심입니다.

왜 중요했나헤르메스를 프로젝트별로 어떻게 쓰는지에 대한 질문은 지식 저장소 연결을 넘어 루프 엔지니어링으로 이어졌습니다.

무슨 일이 있었나

발단은 프로젝트 1개당 1개의 Hermes 프로필을 만들고, 프로젝트 전용 Obsidian vault를 마운트해 맥락을 기록관리하면 되는지 묻는 질문이었습니다.

답변은 “좋은 방향”이라고 인정하면서도 개발자 피드백을 추가하라는 쪽으로 보강됐습니다. 단순히 문서를 읽게 하는 것이 아니라, 엔드포인트마다 엔지니어링 보고서를 받고 1~10점과 의견을 함께 받도록 설계한다는 운영 방식이 공유됐습니다.

전개에서는 보고서의 보완사항을 다시 Hermes/Codex에 연결해 개선점을 찾고 실행시키는 루프가 언급됐습니다. 질문자는 이를 루프 엔지니어링으로 이해했고, 대화는 실제로 AI 작업의 평가→보완→재실행 구조를 가리켰습니다.

이어 설계서를 Markdown으로 관리하는 이유도 설명됐습니다. 사람과 에이전트가 모두 읽고, git에서 변경을 확인하며, Architect/Engineer 서브에이전트가 크로스체크할 수 있게 만드는 것이 핵심입니다.

용어 쏙쏙 2개

루프 엔지니어링AI 산출물 평가와 보완 지시를 반복 구조로 설계하는 방식
Ground truth판단 기준이 되는 원본/표준 문서

적용 방 발언 기준

지수님 포인트

지수님 쪽 Kakao/Hermes 자동화도 방별 리포트 산출 후 QA와 피드백을 위키에 쌓아 다음 cron 프롬프트를 고치는 루프가 핵심입니다.

왜 이 액션인가

지수님 쪽 Kakao/Hermes 자동화도 방별 리포트 산출 후 QA와 피드백을 위키에 쌓아 다음 cron 프롬프트를 고치는 루프가 핵심입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikipersonal/kakao/kakao_openchat_pipeline.mdpatterns/hermes_profile_feedback_loop.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 9개 보기

15:41영주님/코덱스,클코
우푸님 헤르메스 관련해서 질문 드릴게 있습니다. 우푸님이 말씀하신게 프로젝트 1개당 1개의 헤르메스 프로필을 파서 거기에 지식 맥락을 기록관리 하라고 하셨잖아요? 그래서 저는 제가 개발중인 프로젝트 전용 헤르메스 프로필을 파고, 그 헤르메스 프로필에게 프로젝트 전용 옵시디언 볼트를 마운트 시키고 여기다가 맥락 기록 관리를 시키려고합니다. 그리고 코딩 작업은 헤르메스와 제가 직접 기획하고, 개선 방향을 충분히 얘기한뒤, 헤르메스에게 CODEX에다가 프롬프트 넣어서 작업 진행하라구 하려고 하구요 (코덱스에는 제가 프로젝트 안에 하네스 프레임워크를 설계 해둔 상태) 코덱스 세션에서 작업이 완료되면 훅 기능을 사용해서 옵시디언 볼트에 결과 기록 -> 헤르메스를 통해 결과 보고 받은 뒤 다시 개선점 기획하여 코덱스에게 명령 -> 실행 (반복) 이런식으로 운영하는게 어제 말씀하신 부분이랑 맞을지? 질문 드립니다!!
16:09우푸/클코
저는 항상 앤드포인트에 이번 엔지니어링의 보고서를 만들어서 받도록 설계하고, 거기서 1점 부터 10점까지, 그리고 의견까지 함께 주어용 ㅎㅎ
16:15영주님/코덱스,클코
감사합니다 우푸님!! 혹시 그러면 보고서 확인하구, 보완 사항같은건 어떻게 활용하시나요? 헤르메스에게 보완사항 확인해서 보완점 찾고 코덱스에게 실행시켜 라고 지시하시는지!? (제 생각엔 이게 루프 엔지니어링 같긴한데 맞나요? ㅎㅎ)
16:31연안/클코
@DV/Antigravity 혹시 여기서 Spec은 레포지토리안에 md파일로 관리하시는걸까요?? 설계서자체를 넣으시는지 아니면 어떻게 하시고 계신지 설명 여쭤봐도 될까요??..
16:38DV/Antigravity
네 맞아요 md 파일로 관리합니다. 예를들어 application 아키텍쳐 바뀌면 app-architectire.md를 업데이트 하고, 해당 아키텍쳐에 코드 스니펫도 포함시켜요. 실제 코드가 이 아키텍쳐를 따라서 잘 개발됐는가는 Engineer, Architect 서브에이전트가 크로스체크해서 리뷰를 하고 PR 리뷰어는 에이전트와 이 코드를 제출한 사람을 믿고 넘어가요! 대신 E2E 테스트에 변경된 아키텍쳐에 대한 기능 테스트 결과도 첨부해야합니다. 이 md 파일은 초판을 PL이 만들어두고 배포를 하고, 이후 팀 개발을 통해 지속 업데이트를 해요.
16:40연안/클코
설계서를 베이스로 md파일을 만든다는 인식일까요?? 저희회사는 설계서엑셀파일자체를 md파일로 변환해서 둘다 업로드하는 형식을 하고있는데, 이같은 md파일이 아닌, 따로 Spec파일(AI가 이해하기 쉬운 스타일)로 관리하신다는건가요?? 질문이 많아서 죄송합니다 ㅠㅠ 그리고 답장 정말 감사합니다.
16:41연안/클코
설계서 관리, Spec관리를 그럼 동시에 하시는거면 2번 작업이 들어가는 인식이맞는지도.. 확인 부탁드립니다 ㅠㅠ 죄송하고 감사합니다
16:45DV/Antigravity
md 파일은 사람과 에이전트 모두가 읽습니다. 설계서를 md로 관리하는 이유는 무엇보다도 설계의 변경을 git에서 사람이 확인하고 점검하기 위함이에요. 제가 들어가는 과제 중 이미 존재하는 설계서가 있는 과제일 경우 그 설계서의 내용을 사전에 md로 변환해서 누락없이 올려둡니다. 여러 문서가 md로 존재하는데, prd, adr, infra arch, solution arch, application arch, deployment meta(배포 할 인프라 정보), data spec, e2e test scenario 등등 하나의 기능 업데이트 시 업데이트 해야될 문서가 10개 이상이에요!
16:47DV/Antigravity
설계서를 초반에 Spec으로 입혀놓고 그 이후엔 Spec만 관리한다고 보시면 될것 같네요!

라이브 후속 대화는 우푸의 Giver 역할과 “질문법/커뮤니티 안전”까지 포함한 지식공유 운영 이슈로 번졌다

한줄 결론지수님이 커뮤니티/스터디를 운영하거나 관찰할 때는 지식공유자의 번아웃·질문 품질·심리적 안전을 별도 Watch 지표로 두는 게 좋습니다.

왜 중요했나기술 질문 사이에 커뮤니티 지식공유자의 피로와 댓글 상처, 테이커식 질문법에 대한 반응이 함께 올라왔습니다.

무슨 일이 있었나

발단은 우푸가 라이브와 커뮤니티에서 지식공유자로 활동할 수 있어 영광이었다고 길게 인사한 메시지였습니다. 여러 참가자가 라이브에서 인사이트를 얻었다고 반응했습니다.

이후 한 사용자가 유튜브 댓글 때문에 상처를 받은 것 같다고 위로했고, Giver 관련 질문을 했던 사람이 미안함과 함께 라이브 중 느낀 쎄한 분위기를 언급했습니다.

대화는 곧 “테이커식 질문법과 커뮤니케이션”이라는 표현으로 이동했습니다. 이는 단순 감정 대화가 아니라, 고급 지식공유자가 계속 기여하려면 질문자의 태도와 운영자가 만드는 안전한 장이 중요하다는 신호입니다.

실무 결론은 커뮤니티 리포트에서 기술 링크만 남기면 안 된다는 것입니다. 누가 어떤 부담을 지고 지식을 공유했는지, 어떤 질문 방식이 장기적으로 커뮤니티 품질을 해치는지도 운영 신호로 봐야 합니다.

추적 방 발언 기준

지수님 포인트

지수님이 커뮤니티/스터디를 운영하거나 관찰할 때는 지식공유자의 번아웃·질문 품질·심리적 안전을 별도 Watch 지표로 두는 게 좋습니다.

왜 이 액션인가

지수님이 커뮤니티/스터디를 운영하거나 관찰할 때는 지식공유자의 번아웃·질문 품질·심리적 안전을 별도 Watch 지표로 두는 게 좋습니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikipatterns/community_giver_safety.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 10개 보기

15:14우푸/클코
안녕하세요 :) 우푸입니다 ! 저 말고도, 더 많은 인사이트를 가지고 계신 분들, 더 실력이 좋고, 경험이 많은 분들이 계시지만, 어쩌다보니 흘러가는 흐름에 운이 좋아 핏이 맞아떨어져 많이도 아니고 반 발자국 앞서 나아가게 되어서, 이런 멋진 커뮤니티에서 예쁘게 지식공유자의 느낌으로 활동을 할 수 있게 되어서 너무 영광이에요! 실밸님께서도 게스트로 초대 해주셔서 어찌저찌 라이브도 막 하게 되었는데ㅎ 우러러 보는 대상, 존경하는 대상과 함께 하는 라이브가 생각보다 너무 떨려서 머리가 하얘지고 너무 고장나서 ㅋㅋ 제가 뭐라고 했는지 기억도 안나네요 증말ㅎ! 모니터링 하면서, 아아아악! 아악! 하면서 봤습니다 ㅋㅋㅋㅋㅋㅋㅋㅋ! 이야기 하고 싶은건 많은데, 긴장은 했지, 고장은 나버렸지! 여러모로 쉽지 않은 데뷔 였네요ㅎㅎ! 그래도 방송 아마추어의 몸부림을 응원해주시고, 함께 해주신 많은 분들에게 마음의 진심을 담아 무한한 감사 말씀을 드려요 ❤️ 정말 쉽지 않네요 ㅋㅋ 방송이라는 것.. ㅎㅎ 근데 저는 유투버도 아니고, 유투브 채널을 성장 시킬 생각도 없어요! ! 맨 처음 라이브 부터 말씀드렸던 거라 유명세 타고 싶냐는 질문을 너무 많이 받아서 속상하네요 ㅋㅋㅋㅋㅋㅋㅋ “실밸님 이용해서 유명해지려고 하시네요. ” -> 아닙니다! 저는 막 유명해지는 것에 욕심이 별로 없어요!! ㅎ “하고싶은말이 뭐에요?” -> 그러게요 ㅠㅠ 너무 많은 걸 전달하고싶은 욕심이 과해서 고장났네요 ㅎㅎ 불편한 시간을 드려서 죄송해요 ㅠ_ㅠ “말 뿐이네” -> 어.. 말하려고 출연한거에요..;; 강의를 하는 시간이 아니었는데 ㅠ 등등 ㅎ 여러 말씀 해주시는 분들도 더러 계셔서 ㅎㅎ 아! 나도 아직 한참 부족하고 모자라는구나! 하고 반성하고 있는 중 이랍니다.ㅎㅎㅎㅎ 그래서 저의 발전을 위해서 더 많은 시간을 쏟아내기 위해서 커뮤니티에서 기버. 즉 지식공유자의 역할을 조금만 내려놓을까 해요! - 많은 분들이 항상 궁굼해 하시던 헤르메스 + 머신러닝을 통한 프로젝트 개발하기 - 예민하지만, 꼭 필요한 웹서버 만들고, 내가 만든 서버 내가 뚫어보고, 보안 시스템 구축해보기 등등, 어렵지 않게 풀어나가려고 많이 고민하고, 혼자 영상도 찍어보고, 너무 어렵다고 영상도 부시고, 여러가지를 반복하고 있었는데, 지식공유자의 활동은 잠시 중단하고 자기개발과 자기발전에 조금 더 힘써보도록 하겠습니다 ㅎㅎ 개인적으로 저하고 친분이 쌓여서 저를 좋아해주시고, 이런저런 유익한 인사이트를 함께 하는 분들에게 더 많은 시간을 투자하고, 저를 믿고 함께 달리기 해주시는 TrusGroup에게 더 집중 해볼게요 !! 언제나처럼 ! 저는 연예인이 아니에요… 그냥 일반인 입니다 ㅎㅎ 편하게 1:1 톡 주셔도 아무런 문제가 없으니, 제가 필요하실 땐 언제든지 편하게 연락 주세요 ㅎㅎ! 지식공유자로써 좋은 인연을 만들어 나아가는 건 너무너무 환영이에요 ㅎㅎ!! 뭐 이별인사가 아니라 ㅋㅋㅋ 저를 불편해하시는 분들이 계시는 거 같아서.대외적인 활동을 조금 줄여나아가겠다는 말씀 올리는 것 이옵니다. 다시 한 번, 응원해주시고 저를 통해 긍정적인 인사이트를 받으셨다고 생각해주신 분들에게는 너무너무너무 영광이고, 감사드려요 ㅎㅎ❤️
15:22팝콘먹다떨어트린네오/클코
제가 아직 부족해서 질문을 잘하진 못하지만 불편하지 않는 분위기를 만들어주셔서 속으로 감사해하고 있었어요 몇몇 사람들로 인해 상처 안받으셨으면 좋겠네요!
15:23우푸/클코
ㅋㅋ악! 상처는 받지 않았어요 ㅎㅎ 뭔가 .. 더 빠르게 올라가야겠구나! 하는 새로운 구체적인 목표가 생겼습니다 ㅎㅎㅎㅎㅎㅎ 언제든지 찾아주셔도 돼요 ㅎ 이 커뮤니티가 있는 한, 지식공유자 이니까요 ㅎㅎ
15:27하품하는 죠르디
우푸님 바쁘실텐데 항상 좋은 지식 공유해주셔서 감사드려요 ^^ 어제 하신 라이브 오늘 짬내면서 봤지만.. 유튜브 댓글 때문에 조금 상처 받으신 것 같긴한데 힘내시길 바랍니다. 아무래도 우푸님 본인이 주최해서 지식 공유의 장을 만드는건 의미가 없다고 말씀하시고 계속 실밸님이 주최한데에서 우푸님이 Giver로서 가지고 있는걸 좀 더 내놓겠다~ 라는 식으로 이야기하셔서 조금 비판적인 댓글이 있지 않았나 생각합니다. 정말 지식 Giver가 되시고 싶은거라면 굳이 이렇게까지? 라는 생각이 드는것도 사실이다보니 ㅎㅎ 그래도 이미 우푸님이 이 방에서 많이 활동하셔서 나중에 미국가셔서 실밸님도 만나시게 되면 커리어적으로도, 지식측면으로도 이 방에 있는 누구보다 실밸님에게 우푸님이 큰 도움을 받고 가장 큰걸 얻어갈 수 있을거라 생각해요. 화이팅입니다! 이 방에 항상 즐거운 기운 공유해주셔서 감사합니다 ^^
15:30하품하는 죠르디
AI도 써보면서 성장하는것처럼 유튜브, 라이브 출연도 해보면서 배우고 성장하는거죠 ㅋㅋ
15:31냥시크/클코,코덱스
우푸님만큼만 말 잘해도 좋을것 같은데요 ㅋㅋ 저도 오늘 팀 세미나 진행했는데 우푸님 실밸님 라이브한거 참고해서 했습니다 ㅋㅋ
15:31냥시크/클코,코덱스
무편집 라이브로 저정도 퀄리티면 어마어마하다 생각합니다.
15:36우푸/클코
상처 받은 사람이 된 거 같아서
15:55찹츄/클코
Giver 와 관련한 질문을 한 제가 더 죄송스럽습니다. 한 건의 댓글 보았습니다 하. 누군가를 지적하고 싶지 않고 그럴 자격도 없는 사람이지만 라이브 중에도 받은 쎄한 느낌이 있었습니다. 혹시 그분이 이방에도 계신다면 말씀드리고 싶습니다. 진심으로 위로의 말을 드리고 싶습니다. 아주 큰 두려움 속에서 떨고 계시는 것 같아서요. 그래서 그 두려움을 표출하는 방법을 잘못 선택하신 것 같습니다. 그럼에도 그 고민과 두려움을 깨고 싶으시다면 이곳에서 왕성하게 활동하시길 바라겠습니다. 우푸님께도 사과와 위로를 드립니다..
16:02어이쿠/클로드
KKSS? 전형적인 테이커식의 질문법과 커뮤니케이션 능력을 가진 사람 이야기 맞죠?

클로드 크롬 한도 질문은 browser-use·Playwright·Nanobrowser·BrowserOS까지 이어진 브라우저 에이전트 선택지 비교가 됐다

한줄 결론지수님도 웹 자동화 요청을 받을 때 “확장 프로그램” 답부터 주지 말고 브라우저 조작·모델 호출·파인튜닝을 먼저 분해하는 체크가 필요합니다.

왜 중요했나저녁 대화는 클로드 인 크롬 한도 문제를 계기로, 브라우저에서 다른 모델을 쓰는 방법과 에이전트 자동화 대안을 정리했습니다.

무슨 일이 있었나

발단은 클라우드 GPU를 쓰는 사용자가 클로드 인 크롬 한도가 너무 부족해 딥시크·GLM·Qwen 등 다른 모델을 크롬 확장으로 쓰고 싶다고 질문한 것입니다.

초기 응답에서는 “LLM 파인튜닝은 크롬으로 하는 게 아니다”라는 혼선 정리가 있었습니다. 사용자는 사이트에 프롬프트를 넣는 작업을 말했고, 질문 범위가 브라우저 조작/확장 프로그램으로 좁혀졌습니다.

대안으로는 Hermes/OpenClaw 같은 에이전트에 browser-use나 Playwright를 물리는 방식이 먼저 제시됐고, 이후 Nanobrowser와 BrowserOS 같은 오픈소스/브라우저형 후보가 추가됐습니다.

실무 결론은 “크롬 확장 하나 찾기”보다 작업이 웹 UI 자동화인지, 모델 파인튜닝인지, API 기반 브라우저 조작인지 먼저 분리해야 한다는 것입니다. 목적이 다르면 적합한 도구가 완전히 달라집니다.

용어 쏙쏙 2개

Playwright브라우저 자동화 프레임워크
browser-useLLM이 브라우저 작업을 수행하도록 돕는 오픈소스 계열 도구

테스트 1차 출처 있음

지수님 포인트

지수님도 웹 자동화 요청을 받을 때 “확장 프로그램” 답부터 주지 말고 브라우저 조작·모델 호출·파인튜닝을 먼저 분해하는 체크가 필요합니다.

왜 이 액션인가

지수님도 웹 자동화 요청을 받을 때 “확장 프로그램” 답부터 주지 말고 브라우저 조작·모델 호출·파인튜닝을 먼저 분해하는 체크가 필요합니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

도구 인텔리전스

browser-use medium

Wikitools/browser_agent_candidates.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 12개 보기

19:05Claude/클로드
저 여러분 안녕하세요 제가 일단 클라우드 GPU 유료 결제를 해서 쓰고있는데 클로드 인 크롬 한도가 너무 모자라서 자꾸 작업중 뚝뚝 끊기는 현상이 발생해서요,그래서 딥시크,지푸,퀀등 여러 AI의 크롬 확장프로그램을 찾아봤는데(서드파티툴도)제대로 되는게 하나도 없었습니다,혹시 여기서 쓸만한 Ai 에이전트 크롬 확장프로그램 아시는분 계신가요?
19:08아웃라이너/클코덱스
클로드 인 크롬 에 한도가 있어요?
19:24Claude/클로드
전 클로드 한도랑 이상한 말같지도않은 검열에 질려서 지금 GCP 크레딧 받아서 모델 파인튜닝 하는중이라….
19:54Claude/클로드
저 혹시 클로드 포 크롬같은 AI 에이전트 크롬 확장프로그램이 있을까요? LLM 파인튜닝하려고하는데 클로드 포 크롬으로 하면 자꾸 한도 걸려서 작업을 할수가 없어서요..GLM 5.2라든가 딥시크 v4라든가 그런걸 쓸수있는 프로그램이 궁금합니다 딥시크나 GLM이라고 쳐서 온갖걸 다 시도해봤는데 제대로 사이트에 코드 쳐주는게 하나도 없더라고요...
20:15이응 / 클코덱스
다른모델 쓰고싶으시면 헤르메스나 오픈클로같은 에이전트에 물려서 browser-use나 Playwright같은거 쓰셔도 됩니당
20:16이응 / 클코덱스
https://github.com/browser-use/browser-use
20:30Claude/클로드
아 저 LLM 파인튜닝이요
20:32Claude/클로드
그래서 크롬 확장프로그램 설치해서 클로드 옆에 열어두고 프롬 넣었었어요
20:32이응 / 클코덱스
네 llm 튜닝은 크롬으로 하는게 아니니까요
20:35이응 / 클코덱스
아 그럼 클로드 크롬 확장쓰셔야할것같네요 ㅎㅎ
21:02이응 / 클코덱스
궁금해서 찾아봤는데 원하시는 크롬확장 제품들이 있네요 ㅎㅎ참고하세요 Nanobrowser — 가장 잘 맞습니다. 오픈소스 크롬 확장으로, 사이드 패널 채팅 + 멀티에이전트 방식이고 OpenAI·Anthropic·Gemini·Ollama에 더해 custom OpenAI-compatible 프로바이더를 지원합니다. WebBrain — MIT 라이선스 오픈소스로 Chrome·Firefox 둘 다 되고, llama.cpp·OpenAI·Claude·OpenRouter를 지원하며 다국어 UI를 갖췄습니다. Browserfly — Chrome 웹스토어 등록 확장으로 BYO key 방식이며 OpenAI·Anthropic·OpenRouter·Ollama 등 OpenAI 호환 프로바이더에 직접 연결됩니다. Kimi 기본 내장 (단, 확장이 아니라 브라우저 자체) BrowserOS — Chromium 포크 브라우저로, Moonshot Kimi·Claude·Gemini·OpenAI·OpenRouter
21:02이응 / 클코덱스
에고 답글이라 짤렸네용 Kimi 기본 내장 (단, 확장이 아니라 브라우저 자체) BrowserOS — Chromium 포크 브라우저로, Moonshot Kimi·Claude·Gemini·OpenAI·OpenRouter(500+ 모델)·Ollama 등 11종 이상을 기본 지원하고 본인 키로 자유롭게 전환됩니다. (BrowserOS) Kimi를 별도 설정 없이 쓸 수 있는 게 장점이지만, Chromium 포크라 기존 크롬 확장은 그대로 호환되지만 브라우저를 통째로 바꿔야 (BrowserOS) 합니다.

토큰·새벽 작업 피로는 AI가 결함을 찾고 인간이 고치는 반복 속에서 “내 의지인가”라는 경계 문제로 번졌다

한줄 결론지수님 자동화도 “더 많이 돌리기”보다 사람이 언제 멈추고 판단할지, 어떤 정보는 넣지 않을지, 피로 비용을 어떻게 볼지까지 운영 기준에 포함해야 합니다.

왜 중요했나저녁 중반에는 생산성 도구 이야기보다 AI를 돌리느라 쉬지 못하는 피로와 인간 주도성 감각이 강하게 드러났습니다.

무슨 일이 있었나

발단은 AI가 나오면 더 편해질 줄 알았지만 실제로는 돌리고 새벽에 일어나 다시 돌린다는 토로였습니다. 토큰을 다 쓰지 않으면 돈을 날리는 기분이라는 반응도 이어졌습니다.

전개는 공상과학적 미래관과 현실 업무 감각이 섞였습니다. AI가 몸은 로봇, 기억은 데이터센터에 저장한다는 상상부터, 외환시장처럼 이미 비인간 시스템이 거대한 결정을 한다는 비유가 나왔습니다.

DV는 주변 사람들이 Gemini에 정보를 가감없이 말한다는 사례와, AI가 결함을 발견하고 사람이 고치면 또 다른 결함을 발견하는 반복 속에서 자신이 부품이 되는 느낌을 공유했습니다.

실무 결론은 AI 운영에서 비용/성능만 볼 게 아니라 인간의 주도권, 휴식, 데이터 노출, 반복 루프의 중단조건까지 같이 설계해야 한다는 것입니다.

추적 방 발언 기준

지수님 포인트

지수님 자동화도 “더 많이 돌리기”보다 사람이 언제 멈추고 판단할지, 어떤 정보는 넣지 않을지, 피로 비용을 어떻게 볼지까지 운영 기준에 포함해야 합니다.

왜 이 액션인가

지수님 자동화도 “더 많이 돌리기”보다 사람이 언제 멈추고 판단할지, 어떤 정보는 넣지 않을지, 피로 비용을 어떻게 볼지까지 운영 기준에 포함해야 합니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikipatterns/human_ai_work_boundary.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 12개 보기

18:00실밸개발자사상팬/딥시크
돌리고 새벽에 일어나고 돌리고
18:01클코마님/클코+코덱스
헉, 제가 쓴줄 알았어요ㅎㅎㅎㅎ 토큰 다 안쓰면 돈 날린 기분 ㅋㅋ
18:02실밸개발자사상팬/딥시크
차라리 페이블이 토큰 다 털어줄때
18:06아웃라이너/클코덱스
주말에도 토큰 아까워서 사이드 프로젝트 3개 돌렸더니 진짜 쉬질 못하네요 ㅠㅠ 이런 걸 스불재라고 하던데..
18:08발렌타인/클코,코덱스
전 그렇게 맨날 새벽 4시까지 하다가
18:23마스트/클코
AI가 초지능을 갖추게 되면 몸은 로봇이고, 기억은 데이터센터에 저장해두겠죠
18:24마스트/클코
유튜브에서 누가 그러더라구요. AI가 이런 질문을 하면 어떻게 할거냐고ㅋㅋ "너가 인간인 것 말고 나보다 나은게 뭐냐?"
18:37킴블/클코
저도 앞으로는 '연결'이 대주제가 되지 않을까 합니다. 개인과 개인, 사람과 디지털, 국가 대 국가가 연결될 것인지, 어디까지 보완의 위험성을 넘어설지, 미국과 중국은 계속 단절을 지향할지, 그렇다면 다시 서방 대 (옛 기준)공산권의 대 세력권 간의 분리가 나타날지, 인간은 AI와 어디까지 연결될지, 연결의 중심 연결점이 더 이상 인간이 아닌 스스로 판단하는 AI라면 인간이 진정한 행위 주체라고 할 수 있을지 생각해 봐야할 것 같습니다.
19:00DV/Antigravity
집사람 뿐만아니라 주변 사람들만 봐도 제미나이에게 모든 정보를 가감없이 말하고 있더라구요😂 집사람 제미나이가 제 직업까지 알고 있던...
19:08DV/Antigravity
개선해서 제출하면 AI는 또 다른 결함을 발견하고, 또 개선하면 또 다른... 이 반복에서 나는 점점 더 부품이 되어가는ㅠ
19:17お金を撒くライアン/클로드코드
클로드 고놈은 인간의 마음이 없어요
19:21お金を撒くライアン/클로드코드
그러나 인간이 한 모범 예시를 좀 많이 넣고 그후에 꾸지람을 가하면... 기막히게 나옵니다

Claude 저가 토큰 리셀은 비용 절감 팁이 아니라 결제사기·계정·데이터 유출 리스크로 받아들여졌다

한줄 결론저가 AI 구독/토큰 제안은 공식 약관·계정 리스크·데이터 보관 여부를 먼저 의심해야 합니다.

왜 중요했나짧지만 구체적인 리스크 신호가 있었습니다.

무슨 일이 있었나

중국 리셀러가 Claude 토큰을 70~90% 저렴하게 판다는 설명이 공유됐고, 결제 사기와 결과/추론 과정 저장 가능성이 함께 언급됐습니다.

반응은 호기심보다 “창의적인 나쁜 생각”과 유튜브 광고형 저가 구독에 대한 경계였습니다.

추적 방 발언 기준

지수님 포인트

저가 AI 구독/토큰 제안은 공식 약관·계정 리스크·데이터 보관 여부를 먼저 의심해야 합니다.

왜 이 액션인가

저가 AI 구독/토큰 제안은 공식 약관·계정 리스크·데이터 보관 여부를 먼저 의심해야 합니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikipatterns/ai_account_resell_risk.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 2개 보기

08:48조이/클코
현재 무슨 일이 벌어지고 있는지 설명하겠습니다. 중국의 리셀러들이 Anthropic 공식 API 가격보다 70~90% 저렴한 Claude 토큰을 판매하고 있습니다. 이들은 여러 개의 Claude Max 계정의 사용량을 묶어서 재판매하고, 결제 사기(payment fraud)를 활용하며, 모델의 출력 결과와 추론 과정(reasoning chains)을 여러 중국 AI 연구소에 다시 판매하는 방식으로 이를 가능하게 합니다. 즉, 사용자 로그와 추론 기록을 제공받는 대가로 모델 사용료를 사실상 보조해 주고, 그 데이터를 학습용 데이터로 판매하기 때문에 원가 이하의 가격으로도 운영할 수 있습니다. 중국에서는 Claude와 ChatGPT가 모두 차단되어 있습니다. 접속하려면 VPN이 필요하고, 중국 은행 카드로는 결제도 할 수 없습니다. 그래서 Claude를 쓰려는 대부분의 사람들은 리셀러를 통해 접근 권한을 구매합니다. 이것이 중국에서 Anthropic 모델을 사용하는 가장 쉽고 저렴한 방법입니다. 이런 리셀러들은 수만 개의 봇 계정을 운영하고 있으며, 이것이 Anthropic이 봇의 대량 생성을 막기 위해 신원 확인(KYC)을 도입한 이유이기도 합니다. 예를 들어 한 리셀러는 Claude Opus 4.8을 공식 API 가격보다 93% 할인된 가격에 제공하고 있습니다. 이것이 DeepSeek와 GLM의 토큰 가격이 매우 저렴한 이유 중 하나이기도 합니다. 중국에서는 이처럼 비정상적으로 싼 Claude 토큰과 경쟁해야 하기 때문에, 사용자들을 유지하려면 가격을 낮출 수밖에 없습니다. 몇 달 전에 이 이야기를 공유했지만 별다른 관심을 받지 못했습니다. 중국의 토큰 재판매 경제(token resale economy)를 설명하는 매우 좋은 글입니다.
08:51라이언/코덱스
요즘 ai 구독 싸게 판다고 유튭 광고 많이 뜨던데 저런건가 봐요 ㄷㄷㄷ

Qwen3 VL Embedding 공유는 로컬 메모리 논의와 문서/이미지 임베딩 후보 확인으로 이어졌다

한줄 결론문서·이미지 기반 RAG에서 임베딩 모델은 LLM 본체와 별도 평가 대상입니다.

왜 중요했나공유 링크와 모델 용량 논의가 연결됐습니다.

무슨 일이 있었나

Qwen3 VL Embedding 링크가 공유되며 임베딩/리랭커 포함 약 34GB라는 설명이 붙었습니다.

기업분석 RAG를 만드는 사용자는 임베딩 전용 모델과 OpenAI/Gemini 임베딩 모델까지 후보로 언급했습니다.

테스트 1차 출처 있음

지수님 포인트

문서·이미지 기반 RAG에서 임베딩 모델은 LLM 본체와 별도 평가 대상입니다.

왜 이 액션인가

문서·이미지 기반 RAG에서 임베딩 모델은 LLM 본체와 별도 평가 대상입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikitools/embedding_model_watch.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 8개 보기

10:59자랑하는 라이언 / 클코
임베딩이랑 리랭커 포함해서 34GB 정도 됩니다
10:59잘어잘어/클코
Qwen3는 25년 4월 출시구요
10:59자랑하는 라이언 / 클코
Qwen3-VL-Embedding and Qwen3-VL-Reranker: For the Next Generation of Multimodal Retrieval 2026/01/08
10:59자랑하는 라이언 / 클코
https://qwen.ai/blog?id=qwen3-vl-embedding
10:59잘어잘어/클코
임베딩 모델이네요
10:59자랑하는 라이언 / 클코
네네 임베딩한다고 아까부터 말씀드린...ㅎㅎ
11:14다시시작한 개발자
혼자서 기업분석 RAG를 만들고있는데..
11:17자랑하는 라이언 / 클코
제미나이나 oai에서도 임베딩 모델 있으니

GSEEK 파이썬 강좌 링크는 입문자용 알고리즘·자동화 학습 자료로 분리 보관할 만하다

한줄 결론초보자 안내용 자료는 메인 기술 논의와 별도 보관하면 나중에 온보딩에 쓰기 좋습니다.

왜 중요했나기술 토론 중 무료 학습 자료 링크가 공유됐습니다.

무슨 일이 있었나

파이썬 알고리즘 기초와 업무자동화 빠른 시작 강좌 링크가 함께 공유됐습니다.

대화의 중심은 아니었지만, 비개발자/입문자에게 전달 가능한 자료로 재활용 가치가 있습니다.

위키화 1차 출처 있음

지수님 포인트

초보자 안내용 자료는 메인 기술 논의와 별도 보관하면 나중에 온보딩에 쓰기 좋습니다.

왜 이 액션인가

초보자 안내용 자료는 메인 기술 논의와 별도 보관하면 나중에 온보딩에 쓰기 좋습니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikilearning/python_onboarding_resources.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 2개 보기

15:23お金を撒くライアン/클로드코드
https://www.gseek.kr/course/online/computer/programming/coding/python-algorithm-basics
15:23お金を撒くライアン/클로드코드
https://www.gseek.kr/course/online/computer/programming/coding/python-automation-quickstart

비개발자용 하네스 구상은 자연어 상담 25~30회로 기획서를 만들고 조직에 남기는 구조를 목표로 했다

한줄 결론지수님 업무 자동화에서도 비개발자 입력을 기획서/스펙으로 바꾸는 대화 설계가 큰 레버리지입니다.

왜 중요했나하네스가 개발자 전용이 아니라 비개발자 업무 구조화로 확장되는 대목입니다.

무슨 일이 있었나

질문은 사람별 프레임워크를 어느 수준까지 제공하는지, 프롬프트를 어떻게 수집·모니터링하는지였습니다.

답변은 비개발자가 챗봇과 25~30회 질의응답으로 원하는 내용을 자연어로 풀고, 이를 기획문서로 만들며, 담당자가 없어도 계속 프로젝트를 구성할 수 있게 하는 목표로 정리됐습니다.

적용 방 발언 기준

지수님 포인트

지수님 업무 자동화에서도 비개발자 입력을 기획서/스펙으로 바꾸는 대화 설계가 큰 레버리지입니다.

왜 이 액션인가

지수님 업무 자동화에서도 비개발자 입력을 기획서/스펙으로 바꾸는 대화 설계가 큰 레버리지입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikipatterns/nondeveloper_harness_intake.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 3개 보기

19:18대송/클코
질문보시고 답변을 여기다하시기 그러시면 따로 1:1로도 보내겠습니다. 라이브중에 사람별 프레임워크를 만들어서 제공해주신다 하셨는데 어느정도 수준까지 제공해주시는건지 하네스 정도인걸까요?? 그리고 중간에 프롬프트도 수집하신다 하셨는데 어떠한 방식으로 수집하셔서 어떻게 모니터링 하시는걸까요?? 저한테 지금 업무에서 필요해 보여사요 ㅎㅎ
19:28우푸/클코
제가 제공해드릴, 하네스를 사용하시는 분들은 개발자분들이 아니세요 ㅎㅎ 최종목표점으로 말씀드리면, 1.사용자는 단순 쳇봇에 하고싶은 내용을 기준으로 개발언어 -> 자연어로 파인튜닝하여 질의/응답을 25~30회 정도 진행 할거에요 ㅎ 뭐가 하고싶은지를 파악할거고, 2. 해당 쳇봇을 통해서 기획문서를 작성할거에요. 사용자에게 보여지는 건 "기획 중 이에요" 정도 뿐이지만 실제로는 사내 클로드가 돌아가는 중 이에요. 첨부파일이나 docs, hwp, pptx 등 다양한 파일도 함께 받아서 멀티모달로 분석해 맥락을 파악 할 예정 이에요 ㅎㅎ 3. 기획 완료 후, 제가 만들어둔 하네스 프레임워크 중, 가장 알맞은 녀석을 골라 깃허브 레포를 생성하고, 회사 서버에 프로젝트를 생성할거에요. <여기가 헤르메스 영역 이에요> 4. 기획이 완성되면, 사용자가 알아볼 수 있을 정도의 기획을 뷰 해줄거고, 수정할 부분은 챗봇으로, 수정할 곳이 없다면 최종 의사결정 버튼을 제공할 예정이에요. 5. 그리고 최종 킥오프 버튼을 통해서 기획안을 보고 Phase를 단계별로 생성, 해당 소스코드를 헤르메스가 파악하고 분석하여 단계 별로 Phase를 실행하게 할거고, 6. Meta 데이터를 통해서 Phase가 종료되는 시점을 헤르메스가 캐치할 수 있도록 해서, 프롬프트를 생성하는게 아니라, Phase별 TDD/소스코드QA/컴퓨터유즈/커밋 작업 후 다음 Phase를 구동시켜주는 루프를 만들고, 7. 사용자가 보는 화면에서는 제공되는 서브 에이전트들이 서로 대화하듯 일하는 채팅창을 제공해서, 현재 어떤 일을 하고 있고, 멈추었는지 아닌지 시각적인 효과를 제공하고, 8. 완성 시, 깃허브를 통해 로컬 PC에 내려받을 수 있도록 하는게 목표에요 ㅎㅎ 이 영역에서, 어떻게 기획을 했고, 사용자가 어떤 프롬프트로 기획을 진행했는지는 수집하고, 기획을 수정했던 데이터를 모아서 기획을 하는 스킬에 활용하고, 향 후 모든 데이터를 활용할 수 있는 다음 프로젝트에 적극 활용될 수 있도록 가공해두는 게 목표에요 ㅎ 답변이 되었으면 좋겠네용 ㅎㅎ! 웹 프로젝트는 아니고, 윈도우/맥에서 구동되는 앱을 제공해주는 게 목적이에요 ㅎㅎ
19:32우푸/클코
한 단계 한 단계, 여러 기술들이 들어가겠지만, 제가 이 회사에 없어도 문제없이 프로젝트를 계속 구성해 나아갈 수 있게 해주는게 최종 목표 입니다 ㅎ

Aside는 API 연결이 자유로운 AI 브라우저 후보로 언급됐지만 OS별 waitlist 차이가 확인 필요하다

한줄 결론브라우저 에이전트 후보는 추천 직후 접근 가능 OS와 waitlist 상태까지 확인해야 합니다.

왜 중요했나늦은 밤 짧은 도구 추천이 있었습니다.

무슨 일이 있었나

Aside 링크가 추천됐고, 곧 waitlist가 걸렸다는 정정이 붙었습니다.

다른 참여자는 Windows는 waitlist, Mac은 바로 사용 가능해 보인다는 추가 정보를 줬습니다.

추적 1차 출처 있음

지수님 포인트

브라우저 에이전트 후보는 추천 직후 접근 가능 OS와 waitlist 상태까지 확인해야 합니다.

왜 이 액션인가

브라우저 에이전트 후보는 추천 직후 접근 가능 OS와 waitlist 상태까지 확인해야 합니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Wikitools/browser_agent_candidates.md

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 4개 보기

22:16호떡/코덱스
https://aside.com 조심스럽게 추천해봅니다...ㅎ
22:18호떡/코덱스
아 언제 waitlist가 걸렸지요 죄송합니다. 조사가 부족했네요
22:18호떡/코덱스
AI 브라우저라고 합니다. 다른 api 연결이 자유롭다고 하는 것 같아 추천드렸습니다
22:32대학원생/클코
아마 윈도우 유저들에게는 waitlist 가 나오고, mac 유저는 바로 사용이 가능한 것 같아요

Codex 데스크톱과 CLI 사용 취향, 모바일 사용감 질문은 도구별 UX 선택 문제로 남았다

한줄 결론Codex는 작업 깊이와 환경에 따라 CLI/데스크톱/모바일을 나눠 보는 정도로 추적하면 충분합니다.

왜 중요했나마감 무렵에는 Codex 사용 형태에 대한 가벼운 Q&A가 이어졌습니다.

무슨 일이 있었나

한 사용자가 Codex 데스크톱과 CLI 중 무엇을 많이 쓰는지 물었고, 취향 차이라는 답변이 나왔습니다.

이어 Codex 모바일 사용감 질문과 “짤막하게 쓰기 좋다”는 반응이 붙어, 깊은 기술 이슈보다는 UX 선호 신호로 남았습니다.

읽기 방 발언 기준

지수님 포인트

Codex는 작업 깊이와 환경에 따라 CLI/데스크톱/모바일을 나눠 보는 정도로 추적하면 충분합니다.

왜 이 액션인가

Codex는 작업 깊이와 환경에 따라 CLI/데스크톱/모바일을 나눠 보는 정도로 추적하면 충분합니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 2개 보기

23:00하트쁌
코덱스 데스크톱을 많이 쓰시나영 코덱스 cli를 많이 쓰시나영?
23:06다시시작한 개발자
코덱스 모바일 괜찮나요?

Claude 리셋·한도 체감 이야기는 반복되지만 당일에는 운영 결론보다 사용자 체감 신호에 가까웠다

한줄 결론모델 플랜/한도 체감은 반복 신호가 쌓이면 비용 정책 페이지로 승격할 수 있습니다.

왜 중요했나여러 차례 한도와 리셋 이야기가 나왔습니다.

무슨 일이 있었나

Codex 초기화, Claude 5x/20x 체감, 리셋 기대가 반복됐습니다.

구체적 해결책보다는 플랜별 한도 체감과 불만 공유에 가까워 Watch로만 남겼습니다.

추적 방 발언 기준

지수님 포인트

모델 플랜/한도 체감은 반복 신호가 쌓이면 비용 정책 페이지로 승격할 수 있습니다.

왜 이 액션인가

모델 플랜/한도 체감은 반복 신호가 쌓이면 비용 정책 페이지로 승격할 수 있습니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 7개 보기

09:35백은/Codex
코덱스 초기화됐는데 이번엔 쿠폰이 아니네요
10:18춘/코덱 클코
오 아슬아슬했는데 나이스 리셋 ㅎ
10:26초보/클코,코텍스
이거 일주일 총량도 리셋인가요? 그대로여서..
10:34오크/클코
클로드나 코덱스 x5버전쓰면서 리셋즐기다가 진짜 부족할때만 ×20으로 바꾸는게 나을까요? 중간에 x5쓰다가 x20으로 바꿀때 추가청구되는 부분에대해서 불리한 점이 있을까요?
10:51고라니/클코덱스
클로드는 x20으로 쓰고 있고 코덱스는 x5 쓰면서 리셋을 즐기고 있습니다 ㅋㅋ
13:08최준바라기/클코
claude 5x 쓰고있는뎁 ㅋㅋ,,계속 오전내에 막히는데 ,, 이정도면,, x20쓰면 체감이크겠죠,,?
13:32멍한 프렌즈/클코
내내 막히는게 여유로워 질뿐 막 엄청 크진 않은것 같아요

글쓰기 페르소나와 AI 표시 프로젝트는 흥미롭지만 당일에는 짧은 사례 공유 수준이었다

한줄 결론글쓰기 페르소나는 추후 반복 사례가 나오면 별도 템플릿 연구 후보입니다.

왜 중요했나글쓰기/페르소나 관련 짧은 흐름이 있었습니다.

무슨 일이 있었나

I'm not AI 저장소가 공유되고, 글쓰기 페르소나를 만든다는 이야기가 이어졌습니다.

작가의 성격·경험까지 반영하는지 묻는 질문이 있었지만 깊은 방법론으로 확장되지는 않았습니다.

추적 1차 출처 있음

지수님 포인트

글쓰기 페르소나는 추후 반복 사례가 나오면 별도 템플릿 연구 후보입니다.

왜 이 액션인가

글쓰기 페르소나는 추후 반복 사례가 나오면 별도 템플릿 연구 후보입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 4개 보기

18:17킴블/클코
https://github.com/kimble125/im-not-ai
18:18마스트/클코
그래서 저 아예 글쓰기 페르소나 만들어뒀어요
18:18킴블/클코
오 글쓰기 페르소나라면 글 포맷 뿐 아니라 좀 더 딥하게 작가의 성격이나 경험까지 만든걸까요?
18:22킴블/클코
오 꾸준히 나를 LLM에 학습시키는 게 최선의 방법 같네요.. 아예 캐릭터처럼 페르소나를 만드는 것도 좋은 방법 같아요. 다양하게 시도해보겠습니다! ㅎㅎ

Remote-control 기능이 엔터프라이즈 전용으로 바뀌었다는 불만은 단일 신호라 Watch에만 보존했다

한줄 결론자주 쓰는 기능의 요금제 이동은 반복되면 도구 비용/대체재 추적 항목으로 올릴 수 있습니다.

왜 중요했나아침에 짧은 기능 정책 변화 언급이 있었습니다.

무슨 일이 있었나

Remote-control을 유용하게 쓰고 있었는데 엔터프라이즈에서만 사용 가능하게 바뀌었다는 메시지가 있었습니다.

후속 토론은 적어 Main/Mini로 승격하지 않고 정책 변화 Watch로 남깁니다.

추적 방 발언 기준

지수님 포인트

자주 쓰는 기능의 요금제 이동은 반복되면 도구 비용/대체재 추적 항목으로 올릴 수 있습니다.

왜 이 액션인가

자주 쓰는 기능의 요금제 이동은 반복되면 도구 비용/대체재 추적 항목으로 올릴 수 있습니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

카카오톡 방 원문과 공유 링크 기준입니다.

대화 원문 1개 보기

06:24토르/클코
Remote-control 꽤나 유용하게 쓰고 있었는데 엔터프라이즈에서만 사용가능하게 바뀌었네요 ㅠ

오늘의 흐름을 먼저 한 번에 보기

Microsoft MarkItDown

Facebook Research Nougat

공유 링크

공유 링크

OpenDataLoader PDF

Qwen3 VL Embedding

GSEEK 파이썬 강좌

GSEEK 파이썬 강좌

I'm not AI 저장소

공유 링크

browser-use

Aside AI browser

PDF 파싱 논의는 Docling 병목에서 MarkItDown·Nougat·멀티모달 Markdown 파이프라인 비교로 확장됐다

무슨 일이 있었나

AI 엔지니어 포트폴리오는 RAG 챗봇 하나보다 AgentOps·상태관리·평가·직무 리서치가 핵심이라는 조언으로 정리됐다

무슨 일이 있었나

로컬 AI 논의는 메모리 자랑보다 보안·성능·GB300급 투자 대비 성과를 따지는 온프레미스 의사결정으로 모였다

무슨 일이 있었나

oh-my-claude·슈퍼파워스 질문은 “도구 추천”보다 과제별 하네스와 Spec Driven Development 운영법으로 깊어졌다

무슨 일이 있었나

헤르메스 프로필 질문은 프로젝트별 기억을 나누되 개발자 피드백과 보완 루프까지 넣어야 한다는 운영 설계로 답이 났다

무슨 일이 있었나

라이브 후속 대화는 우푸의 Giver 역할과 “질문법/커뮤니티 안전”까지 포함한 지식공유 운영 이슈로 번졌다

무슨 일이 있었나

클로드 크롬 한도 질문은 browser-use·Playwright·Nanobrowser·BrowserOS까지 이어진 브라우저 에이전트 선택지 비교가 됐다

무슨 일이 있었나

토큰·새벽 작업 피로는 AI가 결함을 찾고 인간이 고치는 반복 속에서 “내 의지인가”라는 경계 문제로 번졌다

무슨 일이 있었나

Claude 저가 토큰 리셀은 비용 절감 팁이 아니라 결제사기·계정·데이터 유출 리스크로 받아들여졌다

무슨 일이 있었나

Qwen3 VL Embedding 공유는 로컬 메모리 논의와 문서/이미지 임베딩 후보 확인으로 이어졌다

무슨 일이 있었나

GSEEK 파이썬 강좌 링크는 입문자용 알고리즘·자동화 학습 자료로 분리 보관할 만하다

무슨 일이 있었나

비개발자용 하네스 구상은 자연어 상담 25~30회로 기획서를 만들고 조직에 남기는 구조를 목표로 했다

무슨 일이 있었나

Aside는 API 연결이 자유로운 AI 브라우저 후보로 언급됐지만 OS별 waitlist 차이가 확인 필요하다

무슨 일이 있었나

Codex 데스크톱과 CLI 사용 취향, 모바일 사용감 질문은 도구별 UX 선택 문제로 남았다

무슨 일이 있었나

Claude 리셋·한도 체감 이야기는 반복되지만 당일에는 운영 결론보다 사용자 체감 신호에 가까웠다

무슨 일이 있었나

글쓰기 페르소나와 AI 표시 프로젝트는 흥미롭지만 당일에는 짧은 사례 공유 수준이었다

무슨 일이 있었나

Remote-control 기능이 엔터프라이즈 전용으로 바뀌었다는 불만은 단일 신호라 Watch에만 보존했다

무슨 일이 있었나