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

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

메타 시니어 엔지니어의 세미나는 코드 지도와 메모리로 구성한 세컨드 브레인, 스킬의 효과와 회귀를 검증하는 Eval을 함께 갖춰야 에이전트에 작업을 믿고 맡길 수 있다고 설명한다.

📌 핵심 요점

1. 코드 생성보다 검증이 병목이 된다. 발표에서 인용한 분석에서는 AI 사용이 많은 시기에 PR 크기가 51% 커지고 리뷰 시간이 약 다섯 배로 늘었다. 인과관계를 단정할 수는 없지만, 생산성은 생성량뿐 아니라 검토와 재작업까지 포함해 판단해야 한다.
2. 세컨드 브레인은 코드 그래프와 코드 메모리의 결합이다. 그래프는 호출·임포트 관계를 따라 변경 영향 범위를 찾고, 메모리는 설계 이유와 장애 이력을 보완한다. 반복 검색과 맥락 누락을 줄이는 구조이며, 오래된 정보가 쌓이지 않도록 갱신해야 한다.
3. 반복 지시는 하네스로 옮기고 호출 조건을 조정한다. 프로젝트 규칙과 맥락을 저장하고 테스트·훅·체크로 실행 과정에 적용한다. 다만 작은 작업에서는 브레인 호출이 오히려 느릴 수 있어, 필요한 상황에서만 사용하도록 라우팅해야 한다.
4. 스킬 Eval은 트리거·업리프트·회귀를 나눠 측정한다. 실제 호출 여부, 스킬 유무에 따른 품질·시간·토큰 차이, 버전 변경 후 성능 저하를 각각 확인한다. 저장소와 설정을 고정한 격리 환경에서 같은 문제를 반복 실행하고, 사실 검증을 통과한 답변을 루브릭으로 채점한다.
5. 평가는 운영에 연결하고 사람은 주도권을 유지한다. 스킬 변경 PR에서 Eval을 자동 실행하고 운영 실패를 새 평가 문제로 추가한다. 동시에 에이전트 관리 자체가 노동을 늘릴 수 있으므로, 운영 범위는 자신이 중요하게 여기는 삶의 가치에 맞춰 정해야 한다.

🧩 배경과 문제 정의

• 에이전트에 규칙·도구·설정을 제공해도 결과를 믿고 맡기기는 어렵다. 코드 생성량이 늘면서 사람이 결과를 검증하는 과정이 주요 병목으로 떠오른다.
• 에이전트는 이전 세션에서 파악한 프로젝트 맥락을 다음 세션에 그대로 기억하지 못한다. 큰 저장소를 반복 검색하는 비용과 정보 누락이 재작업과 검증 부담을 키운다.
• 세컨드 브레인은 코드의 연결 관계를 담은 지도와 설계 이유·장애 이력 등을 담은 메모리로 필요한 맥락을 제공한다. Eval은 스킬 변경이 실제 성능과 품질에 미치는 영향을 검증하는 수단이다.

🕒 시간순 섹션별 상세정리

1. 에이전트를 신뢰하려면 환경과 검증 체계가 필요하다

• 발표자의 회사 대시보드에는 최근 한 달 에이전트 사용 비용이 3만 달러로 표시됐다. 다만 해당 수치의 정확성은 확신하지 못한다고 덧붙였다. [02:37]
• 규칙·도구·설정으로 구성한 하네스를 잘 갖춰도 업무를 믿고 맡기기는 쉽지 않다. 핵심 과제는 신뢰할 수 있는 위임 방식, 하네스 설정, 에이전트가 일할 환경을 함께 설계하는 것이다. [02:58]

2. 코드 자동완성에서 작업 위임과 다중 에이전트 운영으로 확장된다

• 초기에는 AI가 코드 한두 줄에서 많아야 열 줄 정도를 자동완성하고 사람이 대부분을 작성했다. 이후에는 버그 수정이나 기능 개발 같은 작업 전체를 맡기고 결과를 확인하는 방식으로 활용 범위가 넓어졌다. [07:53]
• 여러 에이전트에 프로젝트 조사, 버그 수정, 서비스 배포 모니터링을 각각 맡겨 동시에 진행할 수 있다. 업무 운영의 단위가 개별 코드 제안에서 여러 작업의 병렬 수행으로 바뀐다. [08:21]

3. 사람의 역할은 계획과 결과 검증에 집중된다

• 에이전트는 사람처럼 지치지 않고 계속 실행되므로 짧은 시간에 많은 코드를 생성할 수 있다. 발표자는 자신의 경우 에이전트가 자신보다 코드를 더 잘 작성한다고 평가한다. [09:23]
• 사람은 작업 전에 범위와 계획을 정하고, 작업 후에는 결과물을 검증하는 데 더 많은 시간을 쓰게 된다. 위임하더라도 업무 범위와 성공 여부를 판단하는 주도권은 사람이 유지해야 한다. [09:55]

4. 코드 생산량 증가가 PR 검토의 병목으로 계속된다

• 파로스 AI의 분석은 개발자 22,000명과 4,000개가 넘는 팀의 2년치 작업 기록을 대상으로, 같은 회사에서 AI를 적게 쓰던 시기와 많이 쓰던 시기를 비교했다. [10:48]
• AI 사용이 많은 시기에는 PR 하나의 크기가 51% 커졌고 리뷰에 걸리는 시간은 약 다섯 배가 됐다. 생성 속도가 빨라져도 검토할 코드와 검토 부담이 함께 증가할 수 있다. [11:11]

5. 반복하는 지시는 대화에서 하네스로 옮긴다

• 에이전트에 같은 말을 두 번 이상 반복한다면 프롬프트를 계속 보충하기보다 설정과 환경으로 해결해야 한다. 반복 지시는 하네스가 맡아야 할 일을 사람이 매번 대신하고 있다는 신호다. [12:36]
• 프로젝트 맥락과 규칙은 CLAUDE.md나 세컨드 브레인에 저장해 에이전트가 직접 찾아 읽게 한다. 결과 확인 기준도 테스트 케이스와 게이팅으로 미리 정해 스스로 평가할 수 있게 한다. [13:25]

6. 세컨드 브레인은 코드 지도와 코드 메모리로 구성된다

• 새로운 개발자에게 프로젝트 맥락을 온보딩하고 PR과 테스트로 작업을 검증하듯, 에이전트에도 맥락 제공과 결과 검증이 필요하다. [14:10]
• 코드 지도는 큰 코드베이스에서 필요한 정보를 효율적으로 찾는 기반이다. 코드 전체를 컨텍스트 윈도우에 담기 어려울수록 검색 구조가 작업 품질에 영향을 준다. [15:15]

7. 스킬 Eval은 변경에 따른 품질 저하를 검증한다

• 체감 속도와 실제 결과는 다를 수 있으므로 성과를 수치로 평가해야 한다. 이 세미나에서 다루는 Eval의 대상은 에이전트가 사용하는 스킬이다. [16:00]
• 스킬도 코드처럼 유지보수가 필요하다. 한 줄의 수정으로 기존 프롬프트나 스킬 동작이 깨지면 에이전트의 작업·검증 품질이 떨어지고 서비스 장애로 이어질 수 있다. [16:31]

8. 반복 검색 실험은 정답률과 탐색 재사용의 차이를 보여 준다

• 에이전트는 어제 조사한 내용을 오늘 기억하지 못해 같은 저장소를 처음부터 다시 검색할 수 있다. 저장소가 클수록 이 반복 탐색의 비용도 커진다. [17:59]
• 특정 파일을 바꾸면 영향을 받을 파일을 찾는 실험에서 정답은 394개였다. 같은 프롬프트를 세 번 실행했을 때 스킬이 없는 쪽은 두 번만 전부 찾았고, 스킬을 넣은 쪽은 세 번 모두 찾았다. [19:21]

9. 불완전한 컨텍스트는 재작업과 사람의 병목을 키운다

• 필요한 정보를 검색에서 누락하거나 검색 결과가 컨텍스트 윈도우를 넘으면 분석의 출발점부터 불완전해진다. 예시로 필요한 항목 1,000개 중 800개만 찾는 상황을 제시한다. [20:13]
• 불완전한 분석은 누락된 작업과 잘못된 결과를 만들고, 사람이 수정 방향을 다시 주게 한다. 이 과정에서 프롬프트·규칙·체크리스트가 계속 늘어나 하네스도 복잡해진다. [20:44]

10. 전문 도구와 진단 절차를 제공하면 작업 시간을 줄일 수 있다

• 메타 엔지니어링 블로그의 성능 진단 사례에서는 엔지니어가 프로파일링 자료를 추적하고 문서를 읽으며 분석하는 데 처음에는 10시간이 걸렸다. [21:57]
• 표준 프로파일링 도구를 MCP로 제공하고 전문가의 진단 순서를 스킬로 만든 뒤에는 에이전트가 작업을 30분 만에 마쳤다고 한다. 필요한 도구와 맥락, 진단 절차를 함께 제공한 사례다. [22:36]

11. 에이전트용 세컨드 브레인은 코드 중심으로 구성하고 최신성을 유지한다

• 기존의 세컨드 브레인이 사람을 위한 개인 지식 관리 시스템이었다면, 에이전트용 세컨드 브레인은 에이전트가 활용할 수 있도록 코드베이스를 중심에 둔다. [23:23]
• 파일·함수의 호출과 임포트 관계에 설계 문서, ADR, 머지한 PR, 서비스 장애 회고 자료 등을 결합한다. 코드 구조와 개발 과정에서 축적된 지식을 함께 다루는 방식이다. [23:55]

12. 코드 그래프는 역방향 의존성을 따라 영향 범위를 찾는다

• 변경할 파일을 노드로 두고, 해당 파일을 임포트하는 파일들을 역방향으로 따라간다. 연결을 단계적으로 확장하는 너비 우선 탐색인 BFS로 간접 영향까지 찾는다. [25:20]
• 시연에서는 가장 먼 파일까지 아홉 단계의 연결을 거쳐 도달했다. 결과는 전체 394개 파일이며, 그중 테스트 파일은 144개로 나타났다. [25:53]

13. 코드 그래프의 구축과 갱신은 LLM의 추론에 의존하지 않는다

• 코드 그래프는 LLM이 코드를 해석해 임의로 그리는 구조가 아니라 실제 소스 코드를 근거로 만든다. [26:46]
• 컴파일러와 인덱싱 등의 메커니즘으로 그래프를 갱신하므로, LLM의 성능이 낮아져도 그래프 자체의 성능은 달라지지 않는다는 설명이다. [27:01]

14. 코드 메모리는 그래프에 없는 설계 이유와 장애 맥락을 보완한다

• 코드 그래프는 연결 관계를 보여 주지만 왜 그렇게 설계했는지, 이전 버그와 근본 원인이 무엇이었는지는 담지 못한다. [27:23]
• 설계 문서, 서비스 장애 자료, 런북, 위키, 채팅 스레드에 있는 맥락과 암묵지를 조사해야 이러한 질문에 답할 수 있다. 코드 메모리는 이 정보를 찾는 역할을 맡는다. [27:54]

15. 코드 메모리는 검색 후보를 걸러 설계 이유의 근거를 찾는다

• 특정 파일이 왜 필요한지 찾는 예시에서 BM25 검색을 사용한다. 흔한 단어보다 드문 단어가 겹치는 자료에 높은 순위를 주는 방식이다. [28:18]
• 검색 결과에서 커밋, 변경 로그, 변경 노트, 파일명과 연결된 문서를 살펴보고 해당 파일과 무관한 후보는 제외한다. [28:51]

16. BFS로 영향 범위를 찾고 검색 점수로 코드 메모리를 정렬한다

• 코드 관계 탐색에는 BFS를 사용한다. 임포트 관계를 따라 홉을 확장하며 관련 파일을 경로에 추가한다 [30:34]
• 예시 출력에서는 한 번의 홉으로 60개를 찾았고, 최대 아홉 번의 홉을 거쳐 전체 394개를 찾았다고 표시된다 [30:45]

17. 저장소와 외부 맥락을 언어별 어댑터로 인덱싱한다

• 브레인의 입력에는 코드 저장소 전체와 함께 커밋, 문서, 디자인 문서처럼 코드 바깥의 정보도 포함된다. 저장소에서는 코드 그래프를 만들고 외부 정보는 코드의 배경을 보완한다 [32:42]
• brain build는 언어별 어댑터를 통해 코드를 그래프로 변환한다. 어댑터는 컴파일러와 인덱서 역할을 하며, 다른 언어를 지원하려면 해당 언어의 어댑터를 추가하는 구조다 [33:05]

18. 고유 심볼 ID로 그래프와 메모리를 연결한다

• 함수와 클래스에는 파일 경로와 이름을 조합한 심볼 ID를 붙인다. 같은 이름의 심볼도 경로로 구분해 검색 대상이 섞이지 않도록 한다 [34:23]
• TypeScript 컴파일러로 실제 참조 대상을 확인해 연결하고 외부 패키지는 제외한다. 해석하지 못한 관계는 누락하지 않고 기록해, 에이전트가 관계의 부재와 탐색 실패를 구분하고 추가로 조사할 수 있게 한다 [35:00]

19. 작은 작업에서는 브레인을 호출하지 않도록 라우팅한다

• 파일 한두 개처럼 범위가 작은 작업에서는 세컨드 브레인을 사용했을 때 오히려 느려지는 결과가 측정됐다. 이런 작업에는 코드 그래프를 사용하지 않는 편이 낫다는 판단이다 [36:54]
• SKILL.md에는 작은 작업에서 브레인을 호출하지 말라는 조건을 둔다. 필요한 작업에서도 호출되지 않을 수 있으므로 호출 조건을 설명하는 문구는 추가 튜닝이 필요하다 [37:24]

20. 실제 서비스에서 인덱싱 속도와 영향 범위를 확인한다

• 오토클릭 서비스 데모에서는 6,230개 파일을 읽고 임포트와 심볼 ID를 구성해 약 12초 만에 brain.db 구축을 완료했다 [38:16]
• brain impact에서 탐색 범위를 세 홉으로 제한하자, 지정한 파일의 영향을 받을 수 있는 파일 23개가 검색됐다 [38:44]

21. 스킬 변경도 검증 없이 병합하면 성능을 떨어뜨릴 수 있다

• 코드 지도는 어디로 탐색해야 하는지를, 코드 메모리는 왜 그런 코드가 생겼는지를 제공한다. 다만 이 정보가 실제로 도움이 되는지는 조건과 환경을 정해 Eval로 평가해야 한다 [40:45]
• 스킬 수정 PR은 일반 코드와 달리 리뷰 기준과 습관이 부족해 대략 읽고 승인하기 쉽다. 스킬 Eval이 없으면 변경의 영향을 판단하기가 더 어렵다 [42:03]

22. 짧은 프롬프트 변경도 넓은 평가에서는 회귀가 드러날 수 있다

• 인용된 클로드 코드 사례에서는 4월 16일 시스템 프롬프트에 도구 호출 사이의 글을 25단어 이하로 제한하는 지시가 추가됐다 [43:47]
• 수 주간의 내부 테스트와 Eval에서는 회귀가 없다고 판단했지만, 출시 후 코딩 품질 저하 보고가 들어왔다. 더 넓은 평가에서는 Opus 4.6과 4.7의 점수가 3% 떨어졌다고 하며, 변경을 롤백하고 프롬프트 수정 시 평가 범위를 넓히기로 했다 [44:11]

23. 호출률과 품질을 함께 봐야 스킬의 실제 효과를 알 수 있다

• 첫 번째 사례에서는 필요한 스킬이 56%의 케이스에서 호출되지 않아 스킬 유무에 따른 점수가 같았다. 수정 후 점수는 53에서 79로, 추가 수정 뒤에는 100%로 올랐다고 한다 [46:10]
• 앤트로픽의 스킬 크리에이터 사례에서는 Eval로 트리거 문제를 확인하고 튜닝한 뒤, 여섯 개 중 다섯 개의 트리거가 개선됐다고 한다 [47:08]

24. Eval은 매번 달라지는 행동을 반복해서 측정한다

• Eval은 같은 요청에도 결과가 달라지는 에이전트의 행동을 위한 반복 가능한 테스트다. 결정적인 출력을 가정하는 유닛 테스트와 달리, 같은 프롬프트를 여러 번 실행해야 한다 [48:28]
• 반복 횟수를 K라고 부르며 데모에서는 K를 3으로 설정했다. 반복을 늘리면 평가가 더 정확해지는 대신 비용이 증가하고, 줄이면 비용은 낮아지지만 평가의 정확성이 떨어질 수 있다 [49:00]

25. 사실 검증과 답변 품질 평가를 분리한다

• 인용한 파일과 줄이 실제로 존재하는지처럼 코드로 확인할 수 있는 사실은 스크립트로 검증한다. 이러한 하드 체크를 먼저 수행하고 통과 여부를 판정한다 [49:34]
• 답변의 품질은 다른 모델이 정답과 채점 기준인 루브릭을 참고해 평가한다. 이 방식이 LLM-as-a-Judge다 [50:17]

26. 스킬 평가는 트리거·업리프트·회귀를 구분한다

• 트리거 평가는 에이전트가 필요한 상황에서 실제로 스킬을 로드했는지 확인한다. 스킬을 만들어도 호출되지 않으면 의도한 효과를 낼 수 없다 [51:28]
• 업리프트는 같은 프롬프트를 스킬 없이 실행한 결과와 스킬을 사용한 결과의 차이다. 품질 점수가 같아도 더 빠르게, 더 적은 토큰으로 같은 답을 내면 이득이 있다 [51:55]

27. 평가 환경은 저장소를 고정하고 정답 유출을 차단한다

• 예시 평가 문제는 배치 두 개가 동시에 시작될 때 발생했던 문제와 현재의 방지 방법을 근거와 함께 설명하는 것이다 [53:29]
• Eval에서는 실제 저장소를 직접 작업 대상으로 삼지 않고, 저장소를 복사해 특정 커밋에 고정한 샌드박스를 사용한다 [53:58]

28. 필수 사실 검증에 실패한 답변은 0점 처리한다

• 에이전트가 근거로 제시한 파일과 커밋이 실제로 존재하는지 먼저 확인한다. 답변에 지어낸 근거가 있는지를 하드 체크로 검증한다 [55:25]
• 필수 하드 체크 중 하나라도 실패하면 해당 답변은 0점이다. 이 평가에서는 근거의 실재성 같은 필수 조건을 충족하지 못한 답변을 사용할 수 없는 답변으로 취급한다 [56:05]

29. 루브릭 항목을 여러 판정자의 다수결로 채점한다

• 하드 체크를 통과한 답변은 다른 모델이 정답과 대조해 품질을 평가한다. 루브릭에는 항목별로 통과·실패를 판단할 조건을 미리 적어 둔다 [56:25]
• 판정은 세 번 수행하며, 세 판정자의 항목별 결과를 다수결로 취합한다. 판정이 서로 다르더라도 다수가 통과로 판단한 항목은 통과로 계산한다 [57:06]

30. 실패 원인을 구분하고 같은 문제를 반복 실행한다

• 0점도 원인에 따라 나눠 기록한다. 안전 게이트에 걸린 경우와 답이 틀리거나 대상을 덜 찾은 경우를 구분하고, 덜 찾은 경우에는 찾은 비율을 별도로 남긴다 [58:33]
• 스킬이 아예 호출되지 않은 경우는 답변의 0점과 구분해 라우팅 실패로 분류한다. 호출 실패와 실행 후의 품질 실패는 다른 평가 대상이다 [59:04]

31. 스킬 비교군과 고정 커밋으로 평가 조건을 맞춘다

• 비교군은 스킬 없음, 첫 번째 버전 V1, 두 번째 버전, V1과 동일한 V1B의 네 가지로 구성한다. 동일한 스킬을 별도 비교군으로 반복해 실행 결과의 점수 차이도 확인한다. [1:00:00]
• 평가 대상 코드베이스는 특정 커밋으로 고정한다. 스킬을 수정하거나 새로 만들었다면 해당 변경이 반영된 커밋을 기준으로 Eval을 실행한다. [1:00:49]

32. 코드 검색은 찾은 비율과 맞은 비율을 함께 평가한다

• 조건에 맞는 파일을 모두 찾는 과제에서는 정답 집합을 기준으로 검색 결과를 평가한다. 예시의 정답은 394개이며, 이 중 몇 개를 찾았는지가 재현율인 리콜이다. [1:02:06]
• 정밀도인 프리시전은 에이전트가 제시한 결과 중 실제 정답의 비율이다. 결과 100개가 모두 맞으면 100%, 그중 50개만 맞으면 50%이므로, 누락을 측정하는 리콜과 함께 봐야 한다. [1:02:35]

33. 격리 환경으로 다른 스킬과 정답지의 개입을 차단한다

• 새 작업 폴더에 고정 커밋의 코드베이스 복사본을 만들고 그 안에서 평가한다. 실행마다 기준이 되는 코드 상태를 동일하게 유지하는 방식이다. [1:03:29]
• 각 비교군에서는 평가 대상 스킬만 활성화한다. 스킬 A를 시험하는 환경에서 B·C·D·E까지 에이전트에 로드되면 평가 환경이 제대로 분리되지 않은 것이다. [1:03:46]

34. 실제 팀 요청을 모아 코드 판정과 모델 채점으로 확장한다

• 체감에 의존하는 단계에서는 사람마다 평가가 다르고 스킬이 나빠져도 알아차리기 어렵다. 팀이 자주 시키는 요청 패턴을 파일로 모으는 것이 출발점이며, 약 20개의 질문으로도 시작할 수 있다. [1:05:05]
• 모은 질문에 기대 답변을 붙이면 평가 케이스가 된다. 근거·파일·PR의 실제 존재 여부처럼 정답이 명확한 항목은 하드 체크로 구현해 코드가 자동 판정하도록 한다. [1:06:01]

35. CI와 운영 실패의 피드백으로 Eval을 지속한다

• 스킬을 수정하는 PR마다 CI가 자동으로 Eval을 실행해야 한다. 사람이 매번 기억해 실행하는 방식에는 한계가 있으므로, 점수가 떨어지면 병합을 막는 절차로 연결한다. [1:07:29]
• 충분히 테스트해도 운영에서는 스킬 때문에 장애가 생길 수 있다. 장애를 일으킨 요청과 기대 답변을 새 평가 케이스로 추가해 같은 실패를 다시 검출하는 피드백 루프를 만든다. [1:08:05]

36. 트리거 여부부터 확인하고 불필요한 스킬도 가려낸다

• 중요하다고 생각하는 스킬도 실제로는 사용되지 않을 수 있다. 설명이 좋지 않아 트리거되지 않는 경우가 있으므로, 성능 개선에 앞서 스킬이 호출되는지부터 확인해야 한다. [1:09:35]
• 스킬을 수정한 뒤에는 Eval 점수로 변경 효과를 확인하며 작게 시작할 수 있다. 세미나에서 다룬 구현은 기본적인 프로토타입이고, 회사에서는 더 고도화된 세컨드 브레인과 Eval을 사용한다. [1:10:00]

37. 강의 혜택과 세컨드 브레인·Eval 심화 범위

• 강의 구매 혜택의 조건은 세미나 당일까지 25% 할인과 13만 원 상당의 ChatGPT 프로 1개월 구독권 제공이다. 구독권은 선착순이어서 조기에 마감될 수 있다. [1:11:45]
• 개편 강의의 범위에는 코드 그래프와 코드베이스 메모리를 활용한 세컨드 브레인, AI DB 설계·구축·자동화, Eval 파이프라인의 평가 기준과 사례 설계, CI 자동화가 포함된다. [1:12:40]

38. 사람의 역할 변화와 에이전트 관리가 늘리는 노동

• AI가 더 많은 일을 대체할수록 사람의 역할은 계획·설계·전략과 검증으로 옮겨갈 수 있다. 다만 에이전트가 전략과 검증까지 잘할 가능성이 있어, 이러한 역할 구분이 언제까지 지속될지는 불확실하다. [1:14:01]
• 에이전트를 많이 쓰면서 오히려 일이 늘었다는 경험이 있다. 에이전트를 계속 실행하고 관리해야 하며, 노트북을 덮은 뒤에도 진행 상태나 다음에 시킬 일을 생각하게 된다. [1:14:53]

39. 자신의 가치를 기준으로 에이전트의 주도권을 지킨다

• 에이전트에 끌려다니지 않으려면 자신이 중요하게 여기는 가치를 먼저 생각해야 한다. 에이전트를 운영하느라 허둥대는 상태에서는 오히려 에이전트가 사람에게 일을 시키는 듯한 느낌을 받을 수 있다. [1:16:15]
• 개인적으로 가장 중요한 가치는 가족과 좋은 시간을 보내고 좋은 삶을 사는 것이다. 에이전트를 많이 돌려 돈을 버는 것이 우선인 사람은 다른 선택을 할 수 있으므로, 각자 자신의 가치를 돌아볼 시간이 필요하다. [1:16:56]

🧾 결론

• 세컨드 브레인은 필요한 맥락을 제공하고, Eval은 그 맥락과 스킬이 실제로 도움이 되는지 확인한다. 두 체계를 함께 운영해야 한다.
• 스킬은 코드처럼 유지보수해야 한다. 짧은 문구 변경도 호출률과 답변의 완전성을 바꿀 수 있으므로 변경 전후를 비교해야 한다.
• 목표는 에이전트를 많이 실행하는 데 있지 않다. 검증 가능한 위임을 통해 원하는 결과를 얻고, 사람이 업무와 삶의 판단권을 유지하는 데 있다.

📈 투자·시사 포인트

• AI 도입 성과: 생성 코드량이나 사용량과 함께 리뷰 시간, 재작업, 정확도, 비용을 봐야 실제 생산성 개선을 판단할 수 있다.
• 도구 도입 판단: 큰 코드베이스의 관계 탐색과 맥락 재사용에는 효용이 있을 수 있지만, 작은 작업에서는 추가 비용이 생길 수 있다. 저장소 규모와 작업 유형별 비교가 필요하다.
• 조직의 운영 역량: 평가 문제, 자동 검증, CI 게이트, 실패 사례의 축적이 스킬 개선을 지속하는 기반이다. 도구 설치 이후의 유지보수 부담도 도입 판단에 포함해야 한다.
• 비용 절감의 해석: 소개된 사례처럼 비용이 줄어도 정확도가 악화될 수 있다. 비용 지표만으로 개선을 판정하면 품질 저하를 놓칠 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• PR 크기·리뷰 시간 변화는 세미나에서 인용한 분석이다. 회사와 프로젝트별 차이가 있으며, 제시된 비교만으로 AI 사용이 변화의 원인이라고 단정할 수 없다.
• 394개 파일 탐색의 세 차례 실행, 6,230개 파일의 약 12초 인덱싱 등은 특정 실험과 데모의 결과다. 다른 언어·저장소·환경에서도 같은 성능이 나오는지는 별도 검증이 필요하다.
• 외부 기업의 성능 개선·프롬프트 회귀·배포 직전 사고 사례는 발표에서 소개한 내용이다. 제공된 자료만으로 원문과 세부 조건을 독립적으로 확인할 수는 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 팀이 자주 맡기는 요청 약 20개를 모으고, 기대 답변과 필수 근거를 붙여 초기 평가 세트를 만든다.
• 반복해서 전달하는 규칙과 맥락을 설정·메모리로 옮기고, 준수 여부를 테스트·훅·체크로 확인한다.
• 작은 작업과 넓은 영향 분석 작업을 구분해 브레인 호출 조건을 정하고, 필요한 경우의 호출률과 불필요한 호출 여부를 측정한다.
• 고정 커밋의 격리 환경에서 스킬 없음·기존 버전·새 버전을 반복 비교하고, 정답지와 다른 스킬의 개입을 차단한다.

❓ 열린 질문

• 우리 저장소에서는 어느 규모와 작업 유형부터 코드 그래프·메모리의 이익이 구축·갱신·호출 비용을 넘어서는가?
• 스킬의 필수 호출 조건과 회귀 허용 기준을 어떻게 정하고, 평가 문제를 실제 팀 업무에 맞게 유지할 것인가?
• 설계 문서와 장애 이력의 최신성을 누가 어떤 절차로 관리하며, 확인되지 않은 관계를 에이전트에 어떻게 전달할 것인가?