메타 시니어 엔지니어, 세컨드 브레인 + Eval 무료 세미나 풀버전

한 줄 핵심

에이전트에게 일을 맡기려면 코드베이스 맥락을 구조화해 제공하는 세컨드 브레인과, 그 결과를 반복적으로 채점하는 Eval을 함께 설계해야 실제 생산성과 신뢰성을 얻을 수 있다.

시간별 요약

1. 0:00
   이 세미나를 올리는 이유 에이전트에 일을 맡기려면 컨텍스트를 주고 결과를 검증할 수 있어야 하며, 이 세미나는 그 방법을 다룬 무료 강의의 핵심 내용을 담고 있다. 기존 강의에 세컨드 브레인, Eval, 사이드 브라우저 내용이 추가된 리뉴얼 소식도 함께 전한다.
2. 0:59
   AI 에이전트에 돈 너무 많이 쓰고 계신가요? AI 에이전트를 많이 쓸수록 비용이 빠르게 늘고, 회사에서는 그 비용을 더 과감하게 써보며 학습하는 상황이 벌어진다. 핵심 질문은 에이전트에게 일을 얼마나 믿고 맡길 수 있는지, 그리고 그를 위해 어떤 하네스를 만들어야 하는지다.
3. 3:33
   오늘 준비한 스킬 2개: 세컨드 브레인, Skill Eval 메타에서의 실무 경험과 사이드 프로젝트 경험을 바탕으로 세컨드 브레인 스킬과 Skill Eval 스킬 두 가지를 준비했다. 실제 프로덕션 서비스에 적용해보며 효과를 검증한 데모까지 보여줄 예정이다.
4. 7:23
   실리콘밸리 개발자는 AI를 어떻게 쓰나 초기에는 코드 자동완성 수준이었지만, 이제는 버그 수정과 기능 구현 같은 작업 단위 전체를 에이전트에 맡긴다. 사람의 역할은 코드를 직접 쓰는 것보다 플래닝과 검증으로 이동했고, 여러 에이전트를 병렬로 운영하는 방식이 일반화되고 있다.
5. 10:41
   어디가 막히는가: PR은 1.5배, 리뷰 시간은 5배 AI를 많이 사용할수록 PR 크기는 커지고 리뷰 시간은 크게 늘어나며, 리뷰 없이 머지되는 비율도 증가한다. 코드를 쓰는 비용은 낮아졌지만 코드를 검수하는 비용과 병목은 오히려 더 커졌다.
6. 12:20
   같은 말을 두 번 하면 harness의 영역 에이전트에게 같은 설명을 반복하고 있다면 그 문제는 프롬프트가 아니라 하네스 설계의 문제다. 프로젝트 맥락은 문서화해두고, 결과 검증은 테스트와 게이팅으로 자동화하며, 규칙은 훅으로 강제해야 한다.
7. 14:10
   온보딩은 세컨드 브레인, 검증은 Eval 새 개발자에게 일을 맡길 때와 마찬가지로, 에이전트도 온보딩용 컨텍스트와 결과 검증이 모두 필요하다. 세컨드 브레인은 코드베이스 지도와 코드 메모리로 구성되고, Eval은 스킬이 실제로 도움이 되는지 숫자로 판단하는 장치다.
8. 17:42
   개발자를 위한 세컨드 브레인 에이전트는 어제 찾은 내용을 오늘 기억하지 못하므로, 코드베이스를 매번 다시 검색하는 낭비를 줄이기 위한 세컨드 브레인이 필요하다. 지도와 메모리를 주면 반복 검색 비용이 줄고, 사람이 병목이 되는 상황도 크게 완화된다.
9. 21:51
   Meta 사례: 10시간이 30분으로 프로파일링 도구와 진단 순서를 스킬로 제공하자, 사람이 10시간 걸리던 작업이 30분으로 줄었다. 세컨드 브레인은 파일 연결 관계뿐 아니라 설계 문서, ADR, 장애 리포트 같은 왜(why)의 맥락까지 포함해야 효과가 크다.
10. 24:53
    코드 그래프: hopping과 BFS 코드 그래프는 파일 간 참조를 역방향으로 따라가는 hopping과 BFS로 탐색된다. 컴파일러와 인덱서 기반으로 갱신되기 때문에 모델 성능과 무관하게 일관된 검색 품질을 유지할 수 있다.
11. 27:24
    코드 메모리: 그래프에 없는 why 코드 그래프가 알려주지 못하는 것은 왜 그렇게 만들었는지, 어떤 버그가 있었는지, 어떤 루트 원인이 있었는지다. 이런 정보는 BM25 검색과 문서·커밋 순위를 활용해 코드 메모리로 구축해야 한다.
12. 30:04
    코드 살펴보기: query.mjs와 why.mjs query.mjs는 BFS로 임포트 관계를 따라가며 코드 그래프를 찾는 역할을 한다. why.mjs는 메모리 데이터베이스에서 BM25 기반으로 관련 커밋과 설명을 순위화해 코드의 배경을 돌려준다.
13. 32:21
    코드베이스 브레인 설계: brain build, adapter, symbol ID brain build는 저장소 전체와 외부 문서를 입력으로 받아 코드 그래프와 메모리 DB를 만든다. 언어별 adapter가 필요하고, 함수·클래스에는 symbol ID를 붙여 그래프와 메모리를 안정적으로 연결한다.
14. 36:54
    한계: 작은 작업엔 오히려 느려진다 세컨드 브레인은 큰 코드베이스에는 유용하지만, 파일 1~2개 수준의 작은 작업에서는 오히려 느려질 수 있다. 그래서 작은 작업은 브레인을 부르지 않도록 라우팅 규칙을 따로 둬야 한다.
15. 38:03
    AutoKliq에 brain build 실제 서비스에 brain build를 돌려 6,230개 파일의 심볼과 링크를 만들어내고, 파일이 미칠 영향을 빠르게 찾는 데모를 보여준다. 큰 프로젝트일수록 정확도, 토큰 사용량, 응답 속도에서 세컨드 브레인의 이점이 커진다.
16. 41:12
    이 스킬이 정말 도움이 될까? 스킬의 가치는 느낌이 아니라 숫자로 판단해야 하며, 그 역할을 하는 것이 Eval이다. 스킬을 바꾸는 PR은 리뷰가 쉽지 않기 때문에, 스킬이 실제로 트리거되고 성능을 올리는지 검증할 장치가 필요하다.
17. 43:43
    실제 사고: Claude Code postmortem, Amazon 시스템 프롬프트를 조금 바꾼 뒤 내부 테스트에서는 문제가 없었지만, 더 넓은 Eval에서는 성능 저하가 드러나 롤백한 사례가 있었다. Amazon 사례처럼 배포 직전까지 위험한 변경이 들어가는 일도 있어, Eval의 중요성이 분명하다.
18. 45:58
    Eval을 붙이면: Vercel, Skill Creator, Arize Eval을 붙이면 스킬이 실제로 호출되지 않는 문제, 트리거 품질이 낮은 문제, 비용은 줄었지만 정확도가 떨어지는 문제를 드러낼 수 있다. Vercel, Skill Creator, Arize 사례는 Eval이 없으면 좋은 스킬처럼 보여도 사실은 죽은 코드가 될 수 있음을 보여준다.
19. 48:19
    Eval이란: K번 실행, hard check, LLM as a judge Eval은 같은 프롬프트를 K번 반복 실행해 변동성을 흡수하고, 사실 여부는 hard check로, 품질은 LLM as a judge로 채점하는 반복 가능한 테스트다. 스킬의 트리거 여부, 성능 향상, 리그레션 여부를 각각 분리해서 봐야 한다.
20. 53:14
    채점 설계: sandbox와 다수결 judge Eval은 반드시 가짜 세계인 sandbox에서 돌려야 하며, 원본 저장소·정답·네트워크를 차단해야 한다. 하드 체크를 통과한 뒤에는 여러 judge의 다수결로 품질을 점수화하고, 실패 유형도 별도로 분류해야 한다.
21. 59:46
    Eval suite 파일: 비교군, recall/precision, isolation Eval suite에는 스킬 없음, 구버전, 신버전 등 비교군이 필요하고, 정답을 얼마나 찾았는지와 얼마나 정확했는지를 recall/precision으로 봐야 한다. 격리 환경에서는 다른 스킬이 로드되지 않게 막고, 테스트 대상 스킬만 활성화해야 한다.
22. 1:04:52
    팀에서 쓰는 법: Golden Prompt, CI, 운영 루프 팀에서는 자주 쓰는 요청을 Golden Prompt로 모으고, 하드 체크와 judge를 붙여 CI에서 자동으로 Eval이 돌게 해야 한다. 운영에서 발견된 실패 사례를 다시 테스트 케이스로 편입하는 피드백 루프가 중요하다.
23. 1:08:59
    Eval 대시보드와 정리 대시보드를 통해 비교군별 통과율을 추적하면 스킬 버전이 실제로 개선되는지 확인할 수 있다. 작은 작업에는 세컨드 브레인이 불필요할 수 있고, 스킬도 유지보수되는 코드처럼 계속 다듬어야 한다.
24. 1:11:41
    강의 리뉴얼 소식 리뉴얼된 강의에는 코드 그래프와 코드 메모리로 세컨드 브레인을 구축하는 방법, Eval 파이프라인 설계, 사이드 브라우저 활용법이 포함된다. 오늘 소개한 내용보다 더 고도화된 실전 스킬들을 강의에서 다룬다.
25. 1:13:41
    마지막 메시지: 주도권을 뺏기지 말자 AI 시대의 핵심은 에이전트에게 일을 맡기되 주도권을 잃지 않는 것이다. 사람은 자신의 가치와 방향을 정하고, 에이전트는 그 가치를 실현하는 도구로 써야 한다.

실무 인사이트

• 세컨드 브레인은 단순 검색 도구가 아니라, 코드베이스의 구조와 왜(why)를 함께 복원해 에이전트의 반복 작업과 사람의 검증 부담을 동시에 줄이는 장치로 설계해야 한다.
• Eval은 모델 평가가 아니라 스킬 운영의 안전장치이므로, 하드 체크·judge·샌드박스·CI 자동화를 한 세트로 묶어야 실제 리그레션을 잡아낼 수 있다.
• 작은 작업에서는 브레인과 스킬이 오히려 느려질 수 있으므로, 작업 크기와 위험도에 따라 라우팅하고 필요할 때만 세컨드 브레인과 Eval을 호출하는 정책이 중요하다.