한 줄 요약
Everything Claude Code는 코딩 에이전트에 스킬과 개발 규칙, 실행 시점별 훅, 기억과 학습 절차를 더해 팀의 작업 방식을 구성하는 오픈소스 도구 모음이며, 현재 ECC라는 이름으로 제공됩니다.
저장소: affaan-m/ECC
에이전트에게 새 기능을 맡길 때마다 “기존 구현부터 찾고, 테스트를 돌리고, 바꾼 이유를 남겨 주세요”를 다시 설명하고 계신가요? Everything Claude Code는 이런 반복 설명을 개발 환경에 담아 두고 싶은 빌더가 살펴볼 만합니다. 필요한 절차를 스킬로 부르고, 공통 규칙을 정하고, 작업 중 정해진 시점에 검사를 연결하는 구성이 들어 있습니다.
앞서 소개한 Superpowers가 요구 정리부터 구현과 리뷰까지 이어지는 개발 순서에 집중한다면, ECC에서는 그 흐름에 어떤 규칙과 도구를 붙일지 살펴보세요. mattpocock/skills처럼 필요한 절차 하나를 고르는 데서 시작해, 팀이 반복하는 조사·검증·기억까지 넓혀 볼 수 있습니다. 두 도구를 함께 검토한다면 같은 단계의 지침이 겹치는지도 먼저 비교하면 좋겠습니다.
저희가 권하는 출발점은 자주 고치는 작은 기능 하나입니다. 파일 업로드의 입력 검증처럼 기존 코드와 라이브러리를 살펴볼 이유가 있고, 성공과 실패를 구분할 수 있는 작업을 골라 보세요. 규칙을 많이 설치하는 것보다 조사 결과가 계획에 반영되는지, 검증 결과가 완료 보고에 남는지를 따라가면 ECC가 팀에 맞는지 판단하기 쉽습니다.
무엇을 할 수 있나
ECC는 새로운 코딩 모델을 제공하기보다 이미 사용하는 코딩 도구의 작업 방식을 구성합니다. README에는 계획, 테스트, 구현, 리뷰, 검증, 기억, 개선으로 이어지는 흐름이 소개돼 있습니다. 실제로 사용할 기능은 설치 방식과 코딩 도구의 지원 범위에 따라 달라집니다. 첫 도입에서는 Claude Code 경로를 중심으로 살펴보면 각 구성 요소의 역할을 이해하기 좋습니다.
skills/에는 조사, 테스트 주도 개발, 프런트엔드 패턴, 데이터베이스 변경, 검증 같은 작업 지침이 있습니다. 특정 일을 할 때 필요한 절차를 불러오는 용도입니다. agents/에는 계획이나 코드 리뷰처럼 역할을 나눈 정의가 있고, commands/에는 작업으로 들어가는 슬래시 명령이 있습니다. README는 스킬 중심으로 옮겨 가면서 기존 명령 진입점도 유지한다고 안내합니다.
rules/는 공통 개발 기준과 언어별 기준을 선택하는 영역입니다. 예를 들어 TypeScript 프로젝트라면 공통 규칙과 TypeScript 규칙부터 검토할 수 있습니다. 스킬이 어떤 일을 수행할 때 읽는 절차라면, 규칙은 해당 환경에서 계속 참고할 기준에 가깝습니다. 기존 프로젝트의 기여 규칙과 충돌하는 내용은 설치 전에 비교할 대상입니다.
훅은 세션 시작이나 도구 사용 전후 같은 시점에 연결하는 실행 동작입니다. 필요한 정보를 준비하거나 작업 중 검사를 붙이는 데 쓰입니다. 따라서 지침 문서를 추가하는 것과 실행 코드를 환경에 연결하는 것을 구분해서 읽어야 합니다. 어떤 훅이 켜지는지, 어떤 런타임이 필요한지, 실패하면 작업을 멈추는지 알면 설치 뒤 달라진 동작도 설명하기 쉽습니다.
기억과 학습 기능은 작업을 마칠 때 남길 정보를 다룹니다. 세션 요약과 재사용 절차, 관찰을 바탕으로 만든 작은 행동 지침이 각각 있습니다. 학습 기능의 instinct는 조건과 행동, 근거와 신뢰도를 가진 작은 규칙입니다. 이를 관련 항목끼리 묶어 스킬 같은 형태로 발전시키는 흐름도 제공합니다. 팀에서는 처음부터 모두 켜기보다 어느 정보가 다음 작업에 필요한지 먼저 정해 보세요.
README의 구성 목록을 읽을 때는 항목 수보다 지금 막히는 단계를 중심으로 고르면 좋습니다. 계획을 매번 다시 설명하는지, 완료 보고에 검증이 빠지는지, 같은 오류 해결법을 반복해서 찾는지에 따라 첫 기능이 달라집니다. 선택한 구성 요소가 실제로 읽히고 실행되는지 확인한 뒤 다음 기능을 더하는 편이 운영하기 쉽습니다.
설치와 첫 실행
Everything Claude Code라는 이름으로 찾던 저장소의 현재 주소는 affaan-m/ECC입니다. Claude Code 플러그인 식별자는 ecc@ecc, npm 패키지는 ecc-universal입니다. 이름이 서로 다르므로 예전 안내의 긴 플러그인 이름과 섞지 말고 현재 README의 설치 절에서 시작해 보세요.
공식 안내의 통합 패키지는 Node.js 18 이상을 요구합니다. Claude Code 플러그인 설정에는 Git과 Claude Code 2.1 이상이 PATH에 있어야 합니다. README의 안내형 설치는 다음 명령입니다. 이 명령은 설치할 범위와 훅 구성을 선택하는 흐름이므로, 실행 전에 기존 설치 방식도 정리해 두면 좋습니다.
npx ecc-universal@2.2.3 setup
Claude Code 안에서 기본 플러그인 명령을 사용하는 경로도 있습니다. 다음 두 줄은 터미널 셸이 아니라 Claude Code 대화창에서 실행합니다. 안내형 설치와 기본 플러그인 설치는 같은 플러그인을 설정하는 대안이므로 한 도구에서는 하나의 설치 경로를 선택합니다.
/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc
설치 뒤 새 Claude Code 세션에서 다음 명령으로 ecc@ecc가 활성화돼 있는지 살펴봅니다. 기존 설치가 있거나 적용 범위가 충돌한다면 오류에 나온 범위를 먼저 정리합니다. 수동 파일 복사로 같은 구성 요소를 한 번 더 넣으면 해결 경로가 오히려 복잡해질 수 있습니다.
/plugin list
플러그인 설치와 규칙 설치는 구분합니다. README는 Claude Code 플러그인이 규칙을 배포할 수 없다고 설명하며, 필요한 규칙만 별도로 더하도록 안내합니다. 다음은 공통 규칙과 TypeScript 규칙을 추가하는 공식 예입니다. 복사하기 전에 파일 내용을 읽고 현재 저장소의 규칙과 맞는지 살펴보세요.
git clone https://github.com/affaan-m/ECC.git
cd ECC
mkdir -p ~/.claude/rules/ecc
cp -R rules/common ~/.claude/rules/ecc/
cp -R rules/typescript ~/.claude/rules/ecc/
이 경로는 사용자 디렉터리에 규칙을 놓습니다. 다른 프로젝트에도 영향을 줄 수 있으므로 여러 언어의 규칙을 한꺼번에 넣기보다 실제 사용하는 묶음부터 고릅니다. 플러그인 설치 뒤 전체 수동 설치까지 겹치는 방식은 README에서도 피하도록 안내합니다. 설치 방식, 적용 범위, 선택한 규칙을 팀 메모에 남겨 두면 환경 차이를 비교하기 좋습니다.
첫 대화는 코드 수정 전에 환경과 작업 범위를 파악하는 요청으로 시작해 보세요. 아래 요청은 설치 명령이 아니라, 프로젝트에서 어떤 근거를 읽어야 할지 좁히는 대화 예시입니다. 결과를 받으면 파일 경로와 실제 테스트 명령이 일치하는지 직접 읽어 봅니다.
이 프로젝트에서 파일 업로드 기능을 맡기려 합니다.
기존 입력 검증, 오류 처리, 테스트가 있는 위치를 먼저 찾아 주세요.
사용할 수 있는 ECC 기능 중 이번 작업에 필요한 절차만 제안하고,
코드는 바꾸지 말고 읽은 파일과 아직 결정할 조건을 정리해 주세요.
활용 시나리오 1: 새 유틸리티를 만들기 전에 조사와 계획 연결하기
파일 업로드의 확장자와 크기를 검사하는 기능을 추가한다고 해 보겠습니다. 짧은 요청이지만 브라우저에서만 검사할지, 서버 검증은 어디에 둘지, 이미 사용하는 라이브러리가 있는지부터 정해야 합니다. ECC의 search-first 스킬은 이런 상황에서 기존 구현과 도구를 조사한 뒤 채택, 확장, 직접 구현을 비교하도록 안내합니다.
먼저 저장소 안의 비슷한 기능을 찾고, 그다음 필요한 공식 문서와 패키지로 범위를 넓혀 보세요. 검색할 채널을 사용할 수 있는지도 확인하는 절차가 있습니다. 패키지 검색이 안 되는 환경에서 저장소 파일만 살펴봤다면 그 범위를 결과에 남기는 식입니다. 검색 결과가 없는 것과 검색하지 못한 것은 이후 선택에서 다르게 읽어야 합니다.
파일 업로드에 확장자와 크기 검증을 추가하려 합니다.
먼저 기존 저장소에서 재사용할 검증과 오류 응답을 찾아 주세요.
추가 도구가 필요하면 공식 문서와 라이선스를 근거로 후보를 비교하고,
기존 코드 재사용·작은 확장·직접 구현 중 선택 이유를 설명해 주세요.
조사 범위와 접근하지 못한 자료도 결과에 구분해 주세요.
이 시나리오에서 받을 산출물은 후보 이름 목록보다 선택 근거입니다. 현재 의존성에 필요한 기능이 있다면 새 패키지가 왜 필요한지 물어볼 수 있습니다. 외부 도구가 잘 맞더라도 아주 작은 검사에 큰 의존성을 추가한다면 설치 크기와 유지보수 부담을 함께 읽어야 합니다. 스킬도 필요한 기능보다 큰 의존성을 들이는 문제를 다룹니다.
조사를 마치면 계획으로 이어갑니다. ECC의 plan 명령은 요구를 다시 정리하고, 기존 패턴과 관련 파일을 찾고, 단계와 위험을 제시한 뒤 확인을 기다리는 흐름입니다. 코드를 고치기 전에 입력 조건과 실패 응답을 합의할 수 있습니다. 여러 파일에 영향을 주는 변경에서 먼저 읽어 볼 만한 절차입니다.
조사 결과를 바탕으로 구현 계획을 세워 주세요.
지원할 파일 형식과 크기 제한은 기존 제품 규칙을 따릅니다.
서버의 검증 실패가 화면 오류 안내로 이어지는 경로와,
정상 업로드가 유지되는지 검증할 방법을 파일별로 연결해 주세요.
결정이 필요한 조건은 계획 앞에 모으고 승인 전에는 수정하지 마세요.
계획을 검토할 때는 저장소의 실제 이름을 사용하는지부터 봅니다. 없는 서비스 계층을 새로 가정하거나 사용하지 않는 테스트 프레임워크를 넣었다면 바로잡을 지점입니다. 공식 명령은 이름, 오류 처리, 로그, 데이터 접근, 테스트의 기존 패턴을 파일 근거로 남기도록 안내합니다. 이 근거가 있으면 팀원이 제안의 적합성을 판단하기 좋습니다.
다음으로 성공 경로와 실패 경로를 같은 계획에서 따라가 봅니다. 서버가 요청을 거절할 때 화면은 무엇을 보여 주는지, 같은 파일을 다시 선택하면 어떻게 되는지처럼 실제 제품 조건을 연결합니다. 이 질문들은 업로드 작업에 적용해 볼 검토 항목입니다. 도구가 제안한 모든 조건을 새 요구로 받아들이기보다 제품에서 필요한 동작만 범위에 남깁니다.
이 방식의 장점은 구현을 시작하기 전에 선택 이유를 검토할 수 있다는 점입니다. 조사와 계획이 분리돼 있으면 조사에서는 재사용을 권하고 계획에서는 새 코드를 만드는 일이 생길 수 있습니다. 선택한 후보, 바꿀 파일, 검증 방법이 서로 이어지는지 읽으면 그런 어긋남을 이른 단계에서 찾을 수 있습니다.
활용 시나리오 2: 완료 보고를 빌드·테스트·변경 근거로 받기
업로드 기능을 구현한 뒤 “작업 완료”라는 답을 받았다고 해 보겠습니다. 무엇을 실행했는지 없으면 화면만 고쳤는지, 서버에서 잘못된 입력도 처리하는지 판단하기 어렵습니다. ECC의 verification-loop는 빌드, 타입 검사, 린트, 테스트, 보안 점검, diff 검토를 나누고 결과를 보고하는 절차입니다.
이 목록을 프로젝트의 기존 명령과 연결해 보세요. 공식 스킬에는 여러 도구의 예시가 있지만 저장소마다 실행 방법은 다릅니다. 테스트 스크립트가 없는 프로젝트에서 예시 명령을 그대로 실행한 뒤 기능이 검증됐다고 받아들이면 곤란합니다. 실행 가능한 검사는 실행 결과로, 추가로 준비해야 하는 검사는 남은 일로 보여야 합니다.
구현 결과를 verification-loop의 검토 항목에 맞춰 정리해 주세요.
명령은 이 저장소에 실제로 정의된 것을 사용하고 종료 결과를 읽어 주세요.
빌드·타입·린트 결과와 업로드 성공·실패 동작의 검증을 구분합니다.
변경한 파일, 실패한 검사, 수행하지 못한 항목을 함께 남기고,
로그에는 실제 고객 파일이나 인증 정보가 나오지 않게 해 주세요.
보고서를 읽을 때는 각 근거가 어떤 주장을 뒷받침하는지 따라가 봅니다. 빌드는 배포할 코드가 만들어지는지를, 타입 검사는 선언한 타입 관계를, 테스트는 작성된 조건에서 동작을 살펴봅니다. 서로 다른 검사이므로 한 가지 성공으로 모든 요구를 대신할 수는 없습니다. 업로드 실패 안내는 해당 동작을 다룬 테스트나 재현 결과와 연결해서 읽습니다.
검사가 실패하면 실패한 단계의 원인부터 좁혀 보세요. 이번 변경이 만든 오류인지, 시작 전부터 있던 오류인지, 필요한 실행 환경이 없는지에 따라 다음 행동이 달라집니다. 원래 오류를 해결하는 작업이 범위를 크게 넓힌다면 별도로 판단할 수 있게 보고받습니다. 실패 결과가 긴 로그 사이에 묻히지 않고 최종 보고에도 남는지가 중요합니다.
변경 검토에서는 계획 밖 파일도 봅니다. 업로드 제한을 추가했는데 인증이나 결제 설정까지 바뀌었다면 이유를 확인해야 합니다. 공식 스킬은 의도하지 않은 변경, 오류 처리 누락, 경계 조건을 diff에서 살펴보도록 안내합니다. 작은 리팩터링이 함께 들어갔다면 기능 수정과 어떻게 연결되는지 읽고, 독립적인 정리가 필요하면 작업을 나눌 수 있습니다.
훅과 최종 검증의 관계도 살펴보세요. 작업 중 훅이 알려 주는 문제와 전체 변경을 대상으로 돌리는 검증은 시점과 범위가 다릅니다. 에디터에서 경고가 없었다는 이유로 최종 빌드 결과를 생략하지 않고, 반대로 같은 검사를 불필요하게 반복하는지도 관찰합니다. 팀의 기존 CI와 겹치는 항목은 누가 언제 실행하고 결과를 남길지 정해 두면 좋습니다.
보안 점검은 실제 환경에 맞게 범위를 정합니다. 예시 검색을 돌릴 때 발견한 비밀값을 출력 전체에 남기는 방식은 피하고, 필요한 파일 경로와 마스킹한 정보만 보고받으세요. 검사 도구가 경고하지 않았다는 사실과 데이터 전송 범위를 승인했다는 판단은 별개입니다. 모델로 보내는 코드와 연결 서비스는 사용하는 코딩 도구에서 함께 관리합니다.
검증 결과가 잘 남으면 다음 리뷰도 구체적이 됩니다. 리뷰어는 “잘 동작하나요” 대신 크기 초과 입력의 응답, 정상 요청의 회귀, 계획 밖 변경을 하나씩 대조할 수 있습니다. 저희는 첫 파일럿에서 보고서 길이보다 요구 하나가 구현과 검증에 끝까지 이어지는지 살펴보시길 권합니다.
활용 시나리오 3: 반복해서 설명한 관례를 재사용 절차로 다듬기
업로드 기능을 고치는 동안 “오류 문구는 공통 모듈을 사용하고, 사용자 메시지와 내부 진단을 나눠 주세요”를 여러 번 설명했다면 다음 작업에도 남기고 싶을 수 있습니다. ECC의 continuous-learning-v2는 세션의 관찰을 작은 행동 지침으로 만들고 관련 지침을 재사용 형태로 묶는 흐름을 소개합니다.
여기서 instinct는 특정 조건에서 취할 행동을 작은 단위로 기록한 것입니다. 어떤 관찰에서 나왔는지, 어느 영역에 속하는지, 얼마나 신뢰하는지 같은 정보가 붙습니다. 한 프로젝트의 React 관례가 다른 Python 프로젝트에 그대로 섞이지 않도록 프로젝트 범위와 전역 범위를 나누는 설계도 들어 있습니다.
처음에는 학습 결과를 많이 쌓는 것보다 읽고 고칠 수 있는지 살펴보세요. 잠깐 우회한 해결책이 상시 규칙이 되면 다음 작업에서 문제가 반복될 수 있습니다. 실제로 팀이 승인한 관례인지, 이번 오류에만 해당하는지, 더 이상 맞지 않는 조건은 무엇인지 검토하는 과정이 필요합니다. 신뢰도 값도 팀의 승인 여부를 대신하지 않습니다.
이번 작업에서 반복해서 적용한 오류 처리 관례를 정리해 주세요.
공통으로 재사용할 행동과 업로드 기능에만 맞는 조건을 나눕니다.
각 제안에 근거 파일과 적용 조건을 붙이고,
임시 우회나 고객 데이터는 재사용 지침에 넣지 마세요.
팀 규칙으로 옮기기 전에 검토할 초안으로 보여 주세요.
이 요청은 재사용할 내용을 검토하기 위한 대화 예시입니다. 관찰 훅과 학습 기능이 실제로 활성화돼 있는지는 선택한 설치와 훅 설정에서 따로 살펴봅니다. 기능 이름이 있다는 이유로 모든 세션에서 모든 학습이 수행된다고 가정하지 않는 편이 좋습니다. 관찰 자료가 어디에 남고 누가 읽는지까지 알면 팀 도입 범위를 정하기 쉽습니다.
공식 스킬에는 관찰에 프롬프트와 도구 사용, 결과가 포함되는 흐름이 나옵니다. 따라서 민감한 자료를 다루는 팀은 저장 위치와 보관 범위부터 검토하세요. 반복 절차의 입력으로 고객 데이터 전체가 필요한지, 익명화한 예와 규칙만으로 충분한지 판단합니다. 개인 환경에서 만든 학습 결과를 그대로 공용 저장소에 옮기기보다 내용을 읽고 공유할 부분을 고릅니다.
프로젝트별 분리는 관리에 도움이 되지만 그 자체가 운영체제 격리는 아닙니다. 같은 컴퓨터에서 어떤 프로세스가 자료에 접근할 수 있는지, 다른 코딩 도구와 저장 경로가 겹치는지는 별도로 정해야 합니다. README도 여러 코딩 환경에서 기억 파일을 사용할 때 데이터 경로를 구분하는 방법을 다룹니다. 공유할 관례와 분리할 대화 기록을 먼저 나눠 보세요.
충분히 반복해서 유효했던 절차라면 팀 문서나 스킬로 정리할 수 있습니다. 입력, 실행 순서, 성공 조건, 멈출 조건이 있어야 다른 담당자가 같은 맥락에서 사용할 수 있습니다. 예를 들어 “업로드 수정 시 공통 오류 모듈과 성공·실패 테스트를 함께 읽는다”는 지침은 근거 파일이 바뀌면 함께 갱신해야 합니다. 한 번 만들어 둔 절차에도 유지보수할 담당자가 필요합니다.
이 기능은 Hermes Agent의 기억과 스킬과 함께 비교해 보면 좋습니다. Hermes에서 여러 대화 사이의 기억과 반복 업무를 살펴봤다면, ECC에서는 코딩 환경의 관찰과 개발 지침을 어떻게 묶을지에 주목할 수 있습니다. 지금 필요한 것이 대화의 연속성인지, 저장소 개발 절차의 재사용인지 정하면 첫 도구를 고르기 쉽습니다.
첫 파일럿에서 살펴볼 것
같은 규모의 작은 변경을 하나 골라 조사, 계획, 구현, 검증에서 남은 결과를 모아 보세요. 조사에 쓴 후보가 계획에 반영됐는지, 계획의 실패 조건이 테스트에 들어갔는지, 완료 보고에서 그 근거를 찾을 수 있는지 읽습니다. 속도 수치를 약속하기보다 팀원이 다음 행동을 판단하는 데 필요한 정보가 남는지를 먼저 보는 편이 좋겠습니다.
설치 구성도 결과 옆에 남깁니다. 같은 요청이라도 규칙 묶음과 훅 설정이 다르면 에이전트가 받는 맥락과 실행 동작이 달라집니다. 한 사람은 플러그인만, 다른 사람은 전체 수동 설치까지 사용하고 있다면 응답 차이를 비교하기 어렵습니다. 파일럿 동안에는 선택한 설치 경로와 필요한 구성 요소를 좁혀 두세요.
기존 지침과 겹치는 부분은 실제 작업에서 찾아봅니다. 두 스킬이 모두 구현 전에 다른 형식의 계획을 요구하거나, 리뷰 단계에서 같은 검사를 반복할 수 있습니다. 이때 지침을 계속 덧붙이기보다 팀에서 어떤 결과물을 기준으로 검토할지 정합니다. 필요한 절차를 골라 쓰는 판단이 ECC 도입에서도 중요한 작업입니다.
첫 파일럿의 결과로 남길 것은 거대한 설정 목록보다 다음 작업에서 유지할 선택입니다. 유용했던 조사 절차, 검증에 필요한 명령, 제거할 중복 규칙, 아직 켜지 않을 학습 기능을 정리해 보세요. 작은 범위에서 동작을 이해하면 이후 다른 프로젝트나 코딩 도구로 확장할 때도 어떤 차이를 확인해야 할지 분명해집니다.
어떤 팀에 맞나
장점: 코딩 에이전트에게 같은 개발 관례를 반복해서 설명하거나 조사·계획·검증의 연결을 다듬고 싶은 개인 빌더와 팀이 살펴볼 만합니다. 필요한 스킬과 언어 규칙을 고를 수 있고, 반복 작업의 결과를 다음 절차로 발전시키는 경로가 있습니다. 구성 요소의 역할을 구분하면 현재 병목부터 작게 도입하기 좋습니다.
운영 부담: 규칙과 스킬을 읽고 충돌을 정리하며 업데이트를 검토할 담당자가 필요합니다. 훅의 실행 시간과 추가 모델 호출, 불러오는 지침의 양도 비용과 작업 흐름에 영향을 줍니다. 기억과 학습을 켜면 보관할 자료와 갱신할 관례도 늘어납니다. 첫 도입에서는 설치한 항목 수보다 실제 사용한 기능과 검토할 결과를 좁혀 보세요.
도구별 지원: README는 Claude Code를 주된 안정 경로로 소개하고 다른 코딩 도구의 지원 상태와 제한을 따로 제공합니다. 같은 스킬 목록이 있더라도 훅, 역할 호출, 규칙 적용이 동일하다고 볼 수는 없습니다. 지원 표에서 팀이 사용하는 도구의 설치 경로와 빠지는 기능을 함께 읽어 보세요.
라이선스와 비용: ECC 저장소는 MIT입니다. 수정·재배포할 때 LICENSE 조건을 유지하고, 추가하는 외부 도구와 자료의 라이선스도 각각 살펴봅니다. 코딩 도구와 모델 서비스, 선택적인 외부 연결 비용은 별도로 준비해야 합니다. 오픈소스 지침을 설치했다는 사실만으로 실행 서비스까지 제공되는 것은 아니므로 팀 예산에서는 이 항목들을 함께 계산합니다.
원문과 함께 읽기
- ECC 저장소와 현재 설치 안내
- README · v2.2.3 릴리스
- 조사 우선 절차 · 계획 명령과 예시 대화
- 검증 절차 · 학습 흐름과 예시
- LICENSE
- 함께 읽기: Superpowers의 개발 흐름, agency-agents의 역할별 작업
마치며
하이프마크 빌더 커뮤니티는 앞으로도 이렇게 직접 살펴본 AI 도구와 오픈소스를 꾸준히 공유하려고 합니다. 빌더 여러분께 도움이 될 좋은 자료들을 계속 모아 나누겠습니다.