현재 작업하던 프로젝트들을 뒤져봤는데, lessons가 16개가 최대이더라구요.
그리고 영향 파트 및 Severity를 같이 라벨링하기 때문에 어느정도 누적은 버텨줄 것으로 보이는데,
그 이상 쌓였을 경우에 대한 플랜은 생각해둬야 할 것 같네요.
저의 경우 시드에 대한 테스트를 따로 돌려보는 편이 아니고,
데모 수준의 프로젝트에 이용해 보는 경우가 아닌 실제 본격 작업중인 프로젝트에 적용하고 쓰면서 다듬는 상황이라 측정 자료는 따로 존재하지 않습니다.
RAG 인덱스 최적화 부분은 현재로서는 마크다운 위주의 개발문서 repo 타겟이라 현재 수준으로 적용되어 있습니다.
(* Claude Project의 개발 문서 repo 연동시의 최적화를 목적으로 적용된 부분입니다.)
두 번째 사항에 대해서는, 실질적으로 실시간 동시 운용을 권장 드리는 편은 아닙니다.
목적에 따라 효과적인 모델을 이용하려 할 때가 기본 가정이고,
그 외에는 명백히 서로 다른 파트를 작업할 때는 동시에 이용할 수 있습니다.
예를 들어 Claude로 PM 파트 담당으로 해서 작업 분배 플래닝을 먼저 진행한 뒤,
Antigravity와 Codex에서 FE/BE를 각각 동시에 돌린 후,
PM이 결과 취합하고 다시 다음 플래닝을 하는 식입니다.
그리고 현재로써는 제가 토큰을 아끼는 상황이 아니어서 마스터 시드에 모두 상위 모델로 돌리고 있는 관계로,
토큰 분산은 각 에이전트 플랫폼 별 가성비가 높은 플랜을 선택하고 추가 타 플랫폼도 마찬가지로 가성비 플랜을 구독하여 수평 확장하는 차원에서 접근되어 있습니다.
토큰을 절대적으로 아끼는게 목적이라면 현 시점에서는 본 시드 사용을 권장 드리는 편은 아닙니다.
우선 좋은 프로젝트 소개 감사합니다. 저도 관심있는 분야입니다.
패턴을 잘 정리하셨네요. 본글 보면서 두 가지 자리가 궁금해서 댓글 답니다.
첫 번째 - _lessons/ 누적 비용. lessons 가 100개 >500개 정도로 쌓이면 grep 후 파일 통독 비용이 비례해서 증가할 텐데, AI Native 프로젝트에서 어느 임계점부터 매 태스크 시작 비용이 부담스러워지셨는지 혹시 측정 자료 있으시면 궁금합니다.
v1.3 RAG 인덱스 최적화 섹션이 결국 마크다운 메타데이터라 본질적 해결이 아닌 것 같아서요.
두 번째 - 멀티 에이전트 동시 운용 시 같은 파일이 에이전트 수만큼 중복 로딩되는 자리. 3 에이전트 디자인 베이스인데 각자 세션에서 AGENTS.md + rules.md + architecture.md + STATE.md + lessons 를 다 읽으면, 토큰 분산 목적이 오히려 곱해지는 자리 아닌가요. 이 부분은 혹시 어떻게 풀이하셨는지 아니면 어떻게 푸실건지 궁금합니다.
METR이 발표한 숙련 오픈소스 개발자 대상 RCT에서 AI 사용 조건이 작업 시간을 오히려 19% 증가시켰다는 결과가 있었는데, 이 보고서의 J-Curve 프레임으로 보면 해석이 달라짐
METR 연구 표본은 수년간 대형 오픈소스 저장소에 기여한 숙련 개발자들로, 암묵적 스타일 규칙·리뷰 관행·아키텍처 기준이 강하게 작동하는 환경 — DORA가 ROI 전제 조건으로 꼽는 AI-accessible internal data, IDP, 자동화된 가드레일이 갖춰지지 않은 상태에서의 AI 사용은 Verification Tax가 생산성 이득을 초과하는 J-Curve 초입 구간으로 해석 가능함
METR도 2026년 2월 업데이트에서 후속 실험이 "unreliable signal"을 준다고 인정 — AI 없이는 일하기 싫다는 개발자가 늘면서 AI 효과가 클 작업이 표본에서 빠지는 선택 편향이 원인. 같은 RCT 설계로는 현재의 AI 개발 생산성을 더 이상 잘 포착하지 못함
"AI가 개발자를 느리게 한다"는 해석보다 "조직 기반 없이 AI를 쓰면 J-Curve가 깊어진다" 는 DORA의 주장을 실증한 데이터로 읽는 것이 더 적합해 보임
맥에서는 https://github.com/maxgoedjen/secretive 를 사용하면 편리하게 키를 관리할 수 있습니다.
secure enclave 가 없는 윈도우 환경에서는 yubikey 에 ssh key 를 보관하고 사용하는 것이 편했습니다. 다만 원 글 내용에도 언급했듯 커밋 서명 기능이 활성화된 경우 git rebase 를 여러 커밋에 진행할 때 매 커밋마다 하드웨어 키를 터치해야 하는데 그 딜레이가 생각보다 길어서 오래 걸리고 매우 불편해서 다른 분들께 쓰라고 추천하기는 어려웠습니다.
현재 작업하던 프로젝트들을 뒤져봤는데, lessons가 16개가 최대이더라구요.
그리고 영향 파트 및 Severity를 같이 라벨링하기 때문에 어느정도 누적은 버텨줄 것으로 보이는데,
그 이상 쌓였을 경우에 대한 플랜은 생각해둬야 할 것 같네요.
저의 경우 시드에 대한 테스트를 따로 돌려보는 편이 아니고,
데모 수준의 프로젝트에 이용해 보는 경우가 아닌 실제 본격 작업중인 프로젝트에 적용하고 쓰면서 다듬는 상황이라 측정 자료는 따로 존재하지 않습니다.
RAG 인덱스 최적화 부분은 현재로서는 마크다운 위주의 개발문서 repo 타겟이라 현재 수준으로 적용되어 있습니다.
(* Claude Project의 개발 문서 repo 연동시의 최적화를 목적으로 적용된 부분입니다.)
두 번째 사항에 대해서는, 실질적으로 실시간 동시 운용을 권장 드리는 편은 아닙니다.
목적에 따라 효과적인 모델을 이용하려 할 때가 기본 가정이고,
그 외에는 명백히 서로 다른 파트를 작업할 때는 동시에 이용할 수 있습니다.
예를 들어 Claude로 PM 파트 담당으로 해서 작업 분배 플래닝을 먼저 진행한 뒤,
Antigravity와 Codex에서 FE/BE를 각각 동시에 돌린 후,
PM이 결과 취합하고 다시 다음 플래닝을 하는 식입니다.
그리고 현재로써는 제가 토큰을 아끼는 상황이 아니어서 마스터 시드에 모두 상위 모델로 돌리고 있는 관계로,
토큰 분산은 각 에이전트 플랫폼 별 가성비가 높은 플랜을 선택하고 추가 타 플랫폼도 마찬가지로 가성비 플랜을 구독하여 수평 확장하는 차원에서 접근되어 있습니다.
토큰을 절대적으로 아끼는게 목적이라면 현 시점에서는 본 시드 사용을 권장 드리는 편은 아닙니다.
재밌는 프로젝트네요. 9router 가 잠시 생각났지만 좀 더 free models 에 특화된 것 같아 흥미롭습니다. 좋은 제품 고맙습니다.
https://9router.com
우선 좋은 프로젝트 소개 감사합니다. 저도 관심있는 분야입니다.
패턴을 잘 정리하셨네요. 본글 보면서 두 가지 자리가 궁금해서 댓글 답니다.
첫 번째 - _lessons/ 누적 비용. lessons 가 100개 >500개 정도로 쌓이면 grep 후 파일 통독 비용이 비례해서 증가할 텐데, AI Native 프로젝트에서 어느 임계점부터 매 태스크 시작 비용이 부담스러워지셨는지 혹시 측정 자료 있으시면 궁금합니다.
v1.3 RAG 인덱스 최적화 섹션이 결국 마크다운 메타데이터라 본질적 해결이 아닌 것 같아서요.
두 번째 - 멀티 에이전트 동시 운용 시 같은 파일이 에이전트 수만큼 중복 로딩되는 자리. 3 에이전트 디자인 베이스인데 각자 세션에서 AGENTS.md + rules.md + architecture.md + STATE.md + lessons 를 다 읽으면, 토큰 분산 목적이 오히려 곱해지는 자리 아닌가요. 이 부분은 혹시 어떻게 풀이하셨는지 아니면 어떻게 푸실건지 궁금합니다.
html이 한눈에보기는 너무 예쁘지만 예쁜만큼 수정도 어려운거같습니다.
html 슬라이드도 간단한 슬라이드 빠르게 만들기는 좋은거같은데, 스크린샷에 특정 부분 표시한다든지 하는데에서는 ppt처럼 GUI 형태로 고칠 수 있는게 훨씬 편하고
굳이 머메이드 같은걸로 돌아갈 필요가 없었네요..
저희 부처에서 rag개발하고 있는 거 있는데 클론해서 저희쪽 관련 법령 등만 추출해서 쓰고 싶은데,
그렇게 가능할까요?
최근에 26년 된 26평 구축 아파트 올리모델링을
했습니다. 직접 겪어보니 인테리어 견적 비교 서비스가
얼마나 절실한지 새삼 느껴져서 응원차 댓글 남깁니다.
실제 진행해 보니 공실 확보부터 업체 선정까지
최소 두 달은 발품을 팔아야 하더라고요.
특히 예산은 한정되어 있는데, 업체별로 공정 기간이나
자재비, 인건비가 천차만별이라 소비자로서는 평판 리스크를
안고 최저가를 택해야 하는 게 가장 큰 고민이었습니다.
저는 오늘의 집, 한샘, 부동산 추천 등 7군데 정도
비교해 봤는데요. 가견적은 오늘의 집이 합리적이었지만,
실측을 하면 결국 비용이 다 올라가더군요.
특히 철거, 화장실, 주방 쪽은 자재, 인건비 등으로 복잡한 구조이다
보니 문외한인 소비자가 적정 가격을 산정하고 계산하는 것이
어려웠습니다.
결국 예산 문제로 고민하다 저희 아파트 시공 경험이
많은 업체를 선택해 기간을 단축하며 가성비 있게
마무리하긴 했지만,
그 과정에서 쏟은 에너지가 어마어마했습니다.
작성자님께서 만드신 견적 비교 앱이 이런 정보
비대칭을 해결해 주는 좋은 도구가 되었으면 합니다.
‘오늘의 집’ 같은 곳의 스탠다드 견적을 참고해 현재
시세를 정교하게 녹여내신다면,
저처럼 예산과 평판 사이에서 갈등하는 사용자들에게
정말 큰 도움이 될 것 같습니다.
멋진 도전 응원하겠습니다!
2024년 3월에, 이와 같은 접근을 취하다 깃허브로부터 제지받은 케이스가 있습니다. 각 이용자는 유의하시는 편이 좋겠습니다.
https://velog.io/@bang9dev/14줄의-코드로-로또-자동구매-설정하기
에이전트에 의해 늘어난 거래량으로 결국은 전문적인 개인이나 기업들이 이익을 얻게 된다는 말씀이 맞을까요?
사실 최근에 투자에 AI를 활용하려는 사람들이 많아졌는데, 정말 유효한 전략이 될 수 있을지 궁금했습니다.
zzz
보편적 오해: 좋은 설계란 가변적인 상황을 "모두 대응" 가능하게 만들어야한다
Qwen-TTS 한국어 품질도 상당히 좋은 거 같더군요.
돈 없다는 프롬프트를 항상 AGENTS.md에 남겨놔야겠네요
펀드매니저이자 개발자로써. 소프트웨어 업계와는 다릅니다. 은행 보험을 제외한 금융 즉 증권사 자산운용사는 기본적으로 거래를 일으켜서 수익을 얻는 구조예요. 이러한 금융 플러그인은 거래숫자를 극대화 할 것입니다.
참고로 Claude Project의 파일(프로젝트 지식) 용량 제한은 10MB 가량이므로 repo가 반드시 텍스트 위주여야 합니다.
물론 일부 파일 제외는 Claude Project쪽 UI로 가능하니 폴더로 구분되어있거나 갯수가 적은 정도까지는 괜찮을 수 있습니다.
구글이 너무 좋아서 다섯개쯤 있었으면 좋겠어요🥰
맥에서는 https://github.com/maxgoedjen/secretive 를 사용하면 편리하게 키를 관리할 수 있습니다.
secure enclave 가 없는 윈도우 환경에서는 yubikey 에 ssh key 를 보관하고 사용하는 것이 편했습니다. 다만 원 글 내용에도 언급했듯 커밋 서명 기능이 활성화된 경우 git rebase 를 여러 커밋에 진행할 때 매 커밋마다 하드웨어 키를 터치해야 하는데 그 딜레이가 생각보다 길어서 오래 걸리고 매우 불편해서 다른 분들께 쓰라고 추천하기는 어려웠습니다.
오..! 연금복권720+도 지원되면 좋겠네요
이 의견에 동의합니다.
잘못 사용된 폰트로 인해서 정보의 접근이 차단, 방해 받는다면 공공성이 위협됩니다.
국민청원 가야합니다.