에이전트에 맥락이 부족한 이유: "맞습니다!" 해결 방법 — 브랜든 와셀누크, Unblocked

AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00안녕하세요. AIE에서 모두 멋진 하루를 보내고 계시기를 바랍니다. 날씨도 아주 좋네요.
00:00:17자외선 지수가 거의 9까지 올라갔으니 자외선 차단제를 잘 바르시고
00:00:20성숙한 어른답게 행동하고 계시길 바랍니다. 저는 오늘 컨텍스트
00:00:24엔지니어링에 대해 말씀드리러 나왔습니다. 링크드인의 AJ에 이어
00:00:27발표하게 되어 다행입니다. 그는 저희가 실제로 설계하여 다른
00:00:29솔루션에 판매하는 시스템에 대해 많은 이야기를 나누었죠. 저는 다양한 오픈소스 도구를
00:00:33소개해 드릴 예정입니다. 직전 발표를 들으셨다면 직접 가져다
00:00:36사용해 볼 수 있는 다양한 툴체인과 여러 가지 기법들을 오늘 배워가실 수 있을 겁니다. 목표는
00:00:39물론 “말씀이 맞습니다”라는 응답을 고치는 것입니다. 제 생각에 프롬프트에서
00:00:44그 내용은 이제 빠지고 그냥 맞다고 하거나 다른 말이 나오는 것 같지만, 여러분도 다들 겪어보셨을 겁니다.
00:00:47저는 언블록(Unblocked)에서 일하는 브랜던입니다. 네, 코코넛을 가지고 있죠. 신선한 컨텍스트와
00:00:53신선한 코코넛을 나눠드리고 있었거든요. 제가 여러분께 말씀드리고 싶은 것은 이러한 모델들, 특히 최신 모델들과 관련해서
00:00:57오늘 클로드 5(Claude 5)가 다시 나온다고 하니 제 미팅 녹화본을 보면서
00:01:01예약을 시도해 보라고 하네요. 이건 무시하셔도 됩니다. 하지만 제가 말씀드리고 싶은 점은
00:01:05이러한 도구들을 사용할 때, AI가 생성한 코드는 마치
00:01:11팀에서 수년 동안 일해 온 사람이 작성한 것처럼 느껴져야 한다는 사실입니다. 따라서 오랜 기간 동안
00:01:15손발을 맞춘 듯한 마인드셋을 갖추려면, 여러분 자신이 바로 컨텍스트 엔진이었다는 점을 고려해야 합니다. 어떻게 그렇게 하셨나요?
00:01:23회사에 출근해 질문하고, PR을 올리고 거절당하고,
00:01:27회의에 참석하는 등 이 모든 과정을 거치며 오랜 시간 동안 서서히
00:01:34여러분의 뇌라는 엔진을 구축해 온 것입니다. 여러분은 이곳의 작동 방식을 이해하고 있고, 코드가 어떻게
00:01:39배포되는지 알며, 프로덕션 서버가 다운되었던 그날 밤 왜 그런 일이 일어났는지 온콜로 대응하며 겪었습니다.
00:01:42문제는 이러한 에이전트들도 이와 정확히 똑같은 문제를 겪는다는 점입니다. 에이전트와 함께 새로운 터미널 세션을
00:01:48생성할 때마다, 에이전트는 매우 영리하지만 우리 회사가 어떻게 운영되는지에 대한 컨텍스트가 전혀 없습니다.
00:01:53따라서 어떻게든 그 정보를 얻어야만 합니다. 문제는
00:01:57이러한 에이전트들의 규모를 키워나갈수록 시작 단계에서부터 잘못 단추를 꿰면 그 비용이 눈덩이처럼 불어난다는 것입니다.
00:02:02컨텍스트와 콘텐츠가 주는 레버리지 말입니다. (잠시 이 문제를 바로잡겠습니다,
00:02:07다들 사진을 좀 찍고 싶어 하시는 것 같아서요. 완벽합니다.) 그 컨텍스트 문제는 계속
00:02:13누적될 것입니다. 자, 맨 왼쪽을 보면 우리 모두 기억하는 2년 전의
00:02:20옛날 옛적 시절이 떠오를 겁니다. 당시에는 꽤 멋진 탭 자동 완성 모델들이 있었죠.
00:02:25어떤 일이 일어났냐면, 팝업이 뜨며 “이 코드를 탭으로 완성할까요?”라고 물어보고, 여러분은 머릿속으로 가진
00:02:29컨텍스트를 활용해 빠르게 “아니, 이건 별로야”라고 판단했습니다.
00:02:32혹은 “오 좋네” 하며 탭을 누르곤 했죠. 좋습니다. 에이전트 중심의
00:02:37채택 곡선을 따라 이동함에 따라, 어떤 일이 벌어지냐면 인간이 루프에 개입하지 않거나
00:02:41적어도 개입하고 싶지 않은 상황에서 실행되는 에이전트들을 마주하는 경우가 점점 더 많아집니다.
00:02:46그들에게 필요한 것은 코드를 작성하거나 문제를 해결하고,
00:02:50본질적으로 이슈를 해결하기 위해 벽에 부딪혔을 때 필요한 질문을 던질 수 있는 방법이며,
00:02:54궁극적으로는 여러분의 코드베이스에 병합 가능한 코드를 출력하는 것입니다. 특히 여기 계신 많은 분들이 오랜 기간 운영되어 온
00:02:58브라운필드 코드베이스, 즉 단순한 신규 개발 프로젝트가 아니라 실제로 매출을 창출하고 있는
00:03:02시스템을 다루고 있다는 점을 생각하면 더욱 그렇습니다.
00:03:06따라서 시작 단계에서 잘못된 컨텍스트로 인해 비용이 누적되는 문제는 결함이나 버그를 발견하는 '시프트 레프트' 관점과 비슷하게,
00:03:12가능한 한 가장 일찍 찾아내고 싶어 하는 것과 같습니다. 컨텍스트도 마찬가지입니다. 앞으로 나아갈수록
00:03:17무한 루프에 빠지게 되니까요. 대개 에이전트에게 무언가를 하라고 시키면 “다 했어요”라고 하고,
00:03:22여러분은 “아니, 그게 아니야”라며 계속해서 수정하고 또 수정하게 됩니다.
00:03:26이것은 검색 토큰의 낭비일 뿐만 아니라 재작업 시간의 낭비이기도 하며,
00:03:29앞으로 다가올 토큰 경제학 관점에서 볼 때 결코 용납될 수 없는 일입니다.
00:03:34그리고 병렬 에이전트 등의 단계로 넘어가면 리뷰 비용(review tax)을 치르기 시작합니다.
00:03:39우리가 사용하려고 시도 중인 AI 코드 리뷰어들도 마찬가지입니다. 여기서도 핵심 컨텍스트가 중요해서,
00:03:43코드 리뷰가 비즈니스의 운영 방식을 제대로 이해하고 비즈니스 로직 등을 파악할 수 있어야 합니다.
00:03:48마지막으로, 완전히 루프에서 벗어나 백그라운드 에이전트가 실수 없이
00:03:52일을 처리해 주기를 바란다면, 에이전트들이 쿼리를 날려 필요한 모든 답변을 얻고
00:03:57효과적인 방식으로 계속 작동할 수 있도록 해주는 컨텍스트 엔진을 반드시 확보해야 합니다.
00:04:02효과가 없는 몇 가지 일반적인 접근 방식이 있습니다. 기본적으로 지역 최댓값(local maxima)에
00:04:05갇히는 식인데, 수백 개의 엔터프라이즈 및 중견기업 고객사에서
00:04:08가장 흔히 목격하는 두 가지 중 하나는 바로 '큐레이션된 컨텍스트의 함정'입니다. 가상 파일 시스템이나
00:04:16로컬 파일 시스템을 열고 그 안에 마크다운 파일 몇 개를 넣은 뒤, “이 프로젝트의 모든 컨텍스트와 작동 방식은 이거야”라고
00:04:21생각해 본 적이 다들 한 번쯤은 있으실 겁니다.
00:04:26그런 다음 에이전트가 그 파일들을 그렙(grep)하도록 허용하면 꽤 좋은 데이터를 얻고 성능도 향상되죠.
00:04:30문제는 첫째, 이제 그 파일을 배포해야 한다는 점입니다. 깃허브에 올려서 팀원들이 받아가게 할 수도 있겠지만,
00:04:35그 다음 문제는 여러분이 작성했던 다른 모든 문서들처럼 그 저장소 역시 낡아 썩어 문드러질 것이라는 점입니다. 게다가 조직 내에서 도대체 누가 조직의 말 그대로 모든 사람을 위해 이 파일이나 저장소를 큐레이션할 안목을 가진 전지전능한 존재란 말입니까?
00:04:52이런 문제들에 부딪히기 시작합니다. 다음은 MCP 플래토(plateau)입니다. 이건 꽤 명확합니다. 우리에게는 훌륭한 MCP들이 있고, 이를 에이전트에게 제공하면 다른 소스 시스템에서 정보를 가져올 수 있게 됩니다. 물론 문제는 서버 설명과 도구 설명을 어떻게 작성하느냐에 따라 에이전트가 반드시 호출해야 함에도 불구하고 영원히 호출하지 않을 수 있다는 점입니다. 혹은 호출하더라도 '검색 만족 편향(satisfaction of search bias)'이라고 알려진 잘 알려진 편향이 존재합니다. 그게 무슨 뜻이냐 하면, 에이전트는 자신이
00:05:22올바르다고 생각하는 첫 번째 정보를 찾으면 “아, 필요한 걸 찾았어”라고 하며 그대로 진행해 버린다는 겁니다. 대부분의 조직에는 “B 대신 A를 해야 한다”고 말하는 어젯밤의 슬랙 대화 기록이 존재하는데, 에이전트가 아키텍처 기록을 먼저 찾아버리면 그 대화를 결코 찾지 못하므로 모든 컨텍스트를 실제로 고려하지 못하게 됩니다.
00:05:40여기서의 문제는 정보에 대한 접근성이 곧 이해를 의미하지는 않는다는 점입니다. 따라서 모델에 이해력을 전달하려면 다른 기법들을 사용해야 합니다. 제가 기본적으로 하려는 말은, 에이전트가 볼 수 없는 것은 수면 아래에 있는 모든 것이라는 겁니다. 에이전트는 컴파일되는 코드를 100퍼센트 만들어낼 수 있지만, 그 컴파일되는 코드가 프로덕션을 다운시키고, 특정 롤아웃 절차를 놓쳤거나 기능 플래그(feature flag)를 꺼야 한다는 사실을 놓치는 바람에 새벽 1시에 P0 장애를 맞닥뜨리게 될 수 있습니다.
00:06:10따라서 팀에는 컨텍스트 엔진이 필요합니다. 컨텍스트 엔진이 해야 할 일은 여러분이 누구이고 조직 내 어디에서 일하는지 이해하는 것이기 때문입니다. 그래서 제가 “인증(auth) 기능을 구축하고 싶어”라고 말하면, 엔진은 제가 어디에서 일하고, 제 깃 커밋이 어디에 있으며, 누가 그 커밋을 리뷰하는지 알고 있으므로 제 컨텍스트를 파악해 저에게 집중하고, 이를 트리거 포인트로 삼아 나머지 정보를 찾아낼 수 있습니다.
00:06:33앞서 언급했듯이 오래된 아키텍처 다이어그램과 어젯밤 CTO와의 슬랙 대화 사이에 충돌이 발생했을 때 어느 쪽이 맞는지를 판단하기 위해 여러 가지 기법을 활용하여 이를 해결합니다.
00:06:44물론 권한과 거버넌스도 존중합니다. MCP를 사용하면 OAuth나 기타 스코프, SSO를 활용할 수 있지만, '비밀 프로젝트 A'에 대해 알 자격이 없는 누군가가 이쪽에서 질문을 던졌을 때 그 내용이 응답으로 유출되지 않도록 확실히 차단해야 합니다.
00:06:58그리고 마지막으로, 토큰에 최적화된 방식으로 적절한 시점에 올바른 컨텍스트를 모델에 전달해야 합니다.
00:07:03인간 엔지니어들은 여전히 슬랙이나 기타 채널을 통해 필요한 정보를 얻기 위해 항상 언블록과 소통하므로, 우리에게는 다양한 인터페이스가 존재합니다.
00:07:09하지만 토큰 비용에 대한 부담을 줄이기 위해 머신 대 머신으로 소통할 때는 토큰이 최적화된 응답을 원하게 됩니다.
00:07:17이것이 엔진이 작동하는 방식입니다. 간략하게 설명하자면, 기본적으로 왼쪽에서 들어오는 모든 데이터 소스를 볼 수 있습니다.
00:07:26우리 서비스의 경우 엔지니어링 팀에 집중하고 있으며, 지원(support)이나 영업(sales) 같은 주변의 기술적 성향이 덜한 팀들도 우리를 사용합니다.
00:07:34모든 데이터를 수집하고, 인시던트 관리 툴체인 같은 도구로부터 실시간 데이터를 가져옵니다.
00:07:39데이터가 엔진으로 들어오면, 엔진은 내부적으로 처리를 거치는데 이에 대해서는 잠시 후 슬라이드를 통해 자세히 설명하겠습니다.
00:07:45기본적으로 이 여섯 가지 핵심 특성을 활용한 뒤, 오른쪽에 있는 정확한 워크플로우와 필요한 방식으로 컨텍스트를 출력합니다.
00:07:53앞서 언급한 여섯 가지 핵심 포인트 중 첫째는 통합된 시스템 컨텍스트로, 전체 영역을 아울러야 한다는 점입니다.
00:08:01링크드인 규모, 워크데이, 제너럴 모터스 같은 대규모 조직과 기업들에게는 이러한 유형의 데이터가 필요합니다.
00:08:08그들은 벌어지고 있는 모든 일을 이해해야 합니다.
00:08:10오늘 아침 타릭(Tharik)도 어쩌면 오늘 늦게 나올 수도 있는 Fable에 대해 이야기하면서
00:08:15실제로 지도를 제공한 다음 Fable이 영토를 탐색하도록 해야 한다고 언급했습니다.
00:08:21그 범위를 좁히는 방법은 이러한 모델들이 모든 컨텍스트에 접근할 수 있도록 보장하는 것입니다. 모델들이 여러분의 '알지 못했던 미지의 영역(unknown unknowns)'을 찾아내 줄 것이기 때문입니다.
00:08:29여러분은 잘 모르고 있었지만 하려는 작업에 정말 큰 도움이 될 일들이 회사 내에서 분명히 벌어지고 있습니다.
00:08:35그렇게 하면 훨씬 더 빠르게 진행될 수 있습니다.
00:08:37하지만 타겟팅된 검색의 경우, 링크를 제공했을 때 빠르게 언퓨얼(unfurl)하여 해당 문서를 가져와 작업을 이어갈 수 있어야 합니다.
00:08:43따라서 심층 연구 같은 두 가지 작업은 시간을 오래 들여 수행해도 괜찮습니다.
00:08:46하지만 속도가 필요할 때는 속도 역시 확보해야 합니다.
00:08:49충돌 해결에 대해서는 이미 이야기했습니다.
00:08:51어떤 것은 A를 하라 하고 다른 것은 B를 하라 할 때, 과연 누가 옳은가 하는 문제입니다.
00:08:55개인화된 관련성, 즉 나는 누구고, 어디서 일하며, 무엇을 작업하고 있는가 하는 점입니다.
00:08:59그리고 토큰 최적화를 통해 응답이 유용하고 효과적이도록 만들며 컨텍스트 창이 비대해지지 않도록 방지하는 것입니다.
00:09:04마지막으로 권한 집행, 즉 OAuth를 통해 “너는 이걸 볼 수 없어야 해”라는 규칙을 적용하는 것입니다.
00:09:10우리가 진행한 일부 테스트에서는 동일한 모델에게 정확히 똑같은 프롬프트를 넣되, 한쪽에는 컨텍스트를 제공하고 다른 한쪽에는 제공하지 않고 실행해 보았습니다.
00:09:17이 결과가 바로 벽시계 기준의 소요 시간 절감 효과이며, 2시간이나 단축되어 아주 훌륭합니다.
00:09:21그리고 토큰 절감 효과도 있었습니다.
00:09:23꽤 규모가 큰 작업이었습니다.
00:09:25컨텍스트가 없을 때는 약 2,100만 개의 토큰이 소모되었지만, 있을 때는 1,800만, 아니 1,080만 개의 토큰이 소모되었습니다.
00:09:31이것이 바로 컨텍스트 엔진을 사용할 때 전형적으로 볼 수 있는 경험입니다. 매 세션 시작마다 이해하고 발견하기 위해 에이전트가 억지로 그렙을 수행해야 했던 대다수의 낭비되는 검색 토큰들이, 컨텍스트가 채워짐으로써(hydrated) 더 이상 발생하지 않기 때문입니다.
00:09:45채워진 상태 말이죠.
00:09:47그리고 앞으로 나아갈수록 이러한 유형의 결과물을 얻게 됩니다.
00:09:50토큰 50퍼센트 감소, 더 빠른 트리아지, 그리고 비즈니스 내부에서 무슨 일이 일어나고 있는지 파악하고 있었기 때문에 답변 품질도 실제로 더 좋아집니다.
00:09:57자, 다음 부분부터는 아마 사진을 찍고 싶으실 겁니다.
00:10:01혹시 모르실 수도 있지만, QR 코드 사진을 찍어둔 다음 나중에 사진 앱에서 탭하여 링크를 열 수 있습니다. 여기서 발을 동동 구를 필요가 없죠. 제가 QR 코드 세 개를 보여드릴 테니까요.
00:10:09첫 번째 것은 소셜 커멘트 네트워크를 위한 것입니다.
00:10:12사진을 찍으실 수 있도록 띄워두겠습니다.
00:10:14하지만 이건 저희가 만든 오픈소스 도구로, 순수 결정적 프로그래밍을 활용해 여러분의 깃허브를 훑어보고 팀에서 누가 일하는지 파악해 줍니다.
00:10:22이건 제 실제 팀입니다.
00:10:23우리는 라신(Rasheen)이 미친 듯이 코드를 배포하기 때문에 그를 '머신'이라고 불렀습니다.
00:10:26하지만 오른쪽에서 그가 어디에 커밋하고, 어디에 기여하며, 누가 그의 작업을 리뷰하는지 볼 수 있습니다.
00:10:30그리고 해당 탭들에서 요약된 전문가 그래프를 찾을 수 있죠.
00:10:33비즈니스에서 진행되는 상황을 완벽하게 파악할 수 있습니다.
00:10:35그리고 OpenAI나 앤트로픽의 API 키 중 하나를 선택적으로 추가하면, 여러분을 위해 라벨링을 수행하여 팀이 무엇을 하는지 파악해 줍니다.
00:10:44직접 이런 도구들을 구축하려는 경우, 팀이 어디에서 일하는지 이해하고 컨텍스트 엔진에 집중하기 위해 소셜 네트워크를 활용할 수 있는 정말 멋진 도구입니다.
00:10:52다음은 레포 규칙 에이전트(repo rules agent)라고 불리는 것입니다.
00:10:55이것은 저희의 실제 코드베이스에서 가져온 샘플입니다.
00:10:57어쨌든 화면에 띄워드릴 테니 직접 보실 필요는 없습니다.
00:11:00간단히 말해, 팀이 규칙 파일을 작성한 모든 장소를 찾아내어 전부 확인한 다음, 부여한 심각도나 기타 설정들을 알려줍니다.
00:11:11그냥 이걸로 전환할까요?
00:11:13알려줍니다 -- 아, 저기요.
00:11:15여러분 모두 만나서 반갑습니다.
00:11:17기본적으로 저장소 내부에 있는 모든 규칙을 찾아내어 중복된 이슈나 기타 문제가 있는지 알려줍니다.
00:11:24그리고 인덱스로서 그 위에서 grep을 수행할 수 있습니다.
00:11:26따라서 해당 인덱스를 호출하여 중복을 제거할 수 있으며, 컨텍스트 검색 능력을 향상시키는 데 도움이 됩니다.
00:11:32마지막으로, 월요일에 저희는 RAG를 뛰어넘는 내용의 워크숍을 진행했고, 관계형 컨텍스트 엔진을 처음부터 구축하는 법을 가르쳐 드렸습니다.
00:11:40그러니 저 QR 코드를 스캔하시면 전체 워크북을 받으실 수 있습니다.
00:11:43이를 구현하는 방법을 단계별로 알려주는 6개의 PR이 쌓여 있습니다.
00:11:46요약하자면, RAG는 놀라운 기술이며 여러분께 꼭 필요한 기술입니다.
00:11:49하지만 문제의 나머지 절반은 사람들이 실제로 다음과 같이 묻는다는 점입니다.
00:11:53“지난주에 인증과 관련해서 내가 작업한 열린 PR들은 무엇이지?”
00:11:57RAG만으로는 그 질문에 답할 수 없습니다.
00:12:00쿼리가 필요합니다.
00:12:01따라서 이 세션에서는 에이전트가 스키마를 발견할 수 있게 해주는 기본적으로 스키마리스한 조회 방법을 보여줍니다.
00:12:08그런 다음 그러한 관계형 데이터를 얻기 위해 결정론적으로 그에 대한 쿼리를 작성합니다.
00:12:13매우 유용한 기술입니다.
00:12:15컨텍스트 엔진의 사용 사례는 물론 코드 생성을 넘어섭니다.
00:12:21이것이 바로 우리가 주로 머무는 곳입니다.
00:12:22많은 고객들이 시간을 보내는 곳이기도 하죠.
00:12:24하지만 비즈니스 전반의 다른 많은 사람들이 이러한 도구를 채택하기 시작할 때 어떤 일이 벌어지는지 보는 것은 놀랍습니다.
00:12:30고객 성공(CS) 담당자들이 고객으로부터 문의가 들어오는 바로 그 순간에 티켓을 해결합니다.
00:12:35영업 사원들은 현장에 있는 동안 즉석에서 언블록드 컨텍스트 엔진에 쿼리하여 분기 초에 거래를 성사시키고 있습니다.
00:12:44그 외에도 훨씬 더 많습니다.
00:12:45앞서 제가 단계들에 대해 이야기했던 곡선 차트를 보셨다면, 다음과 같은 작업도 하실 수 있습니다.
00:12:51LLM이 여러분에게 퀴즈를 내고 현재 상황에 대해 물어보는 재미있는 작은 도구를 만들었습니다.
00:12:55그러면 현재 위치를 정확히 매핑해 주고, 해당 단계를 거쳐 성장하는 방법에 대한 몇 가지 기법을 알려줍니다.
00:13:01역량을 키우고 대규모로 AI 도구와 함께 제품을 출시하고자 한다면 말이죠.
00:13:07바로 readiness.getunblocked.com입니다.
00:13:11이제 격차는 지능에 있지 않습니다.
00:13:13바로 컨텍스트입니다.
00:13:14앤트로픽이 발전시켜 온 미토스(Mythos)처럼 놀라운 모델들은 앞으로도 계속 등장할 것입니다.
00:13:19그리고 솔(Sol) 역시 제가 볼 수 있게 허락되는 대로 사용해 보게 되겠죠.
00:13:22참고로 캐나다 데이(Canada Day)를 축하합니다.
00:13:24하지만 중요한 것은, 이러한 모델들이 조직 내부에서 효과적이고 토큰 효율적으로 작동하도록 만들기 위해
00:13:30그 모델들을 둘러싸는 컨텍스트가 무엇이냐 하는 점입니다.
00:13:35그래서 질문 슬라이드가 있긴 한데, 제가 해도 되는지 잘 모르겠네요.
00:13:40아니요.
00:13:41그러니 부스 P16으로 저를 찾아오시면 됩니다.
00:13:44코코넛을 찾으시면 됩니다.
00:13:46여러분 모두와 함께 어울리며 필요하다면 자세한 이야기를 나눌 수 있으면 좋겠습니다.
00:13:49시간 내주셔서 감사합니다.
00:14:00감사합니다.

핵심 요약

에이전트의 지능 수준이 아닌 조직의 운영 방식과 깃허브 커밋 기록을 반영한 컨텍스트 엔진의 유무가 토큰 비용과 작업 완성도를 결정합니다.

하이라이트

  • 에이전트에게 컨텍스트를 제공했을 때 작업 소요 시간이 2시간 단축되고 토큰 소모량이 1,080만 개로 감소했습니다.

  • 큐레이션된 컨텍스트 파일은 쉽게 낡아 썩어 문드러지며 전체 조직을 위한 안목을 가진 전지전능한 존재가 부재하다는 한계가 있습니다.

  • MCP 플래토 현상으로 인해 에이전트는 자신이 올바르다고 생각하는 첫 번째 정보를 찾으면 그대로 진행해 버리는 검색 만족 편향에 빠집니다.

  • 소셜 커멘트 네트워크는 순수 결정적 프로그래밍을 활용해 깃허브를 훑어보고 팀의 실제 기여와 전문가 그래프를 파악합니다.

  • 관계형 컨텍스트 엔진은 RAG만으로는 답할 수 없는 사용자의 열린 PR과 같은 구체적인 질의에 대응할 수 있습니다.

타임라인

에이전트 도입에 따른 컨텍스트 부재 문제

  • 에이전트와 함께 새로운 터미널 세션을 생성할 때마다 회사의 운영 방식을 이해하는 컨텍스트가 전혀 없습니다.
  • 시작 단계에서 잘못된 컨텍스트로 인해 비용이 눈덩이처럼 불어나며 무한 루프와 재작업 시간을 유발합니다.
  • 백그라운드 에이전트가 실수 없이 작동하려면 필요한 답변을 얻을 수 있는 컨텍스트 엔진이 필수적입니다.

인간은 출근과 회의 참석, 온콜 대응을 거치며 뇌라는 엔진을 구축해 왔지만 에이전트는 매번 컨텍스트 없이 시작합니다. 에이전트 규모가 커질수록 시작 단계의 오류로 인한 비용이 누적되며, 반복적인 수정은 검색 토큰과 재작업 시간을 낭비하게 만듭니다.

실패하는 일반적인 접근 방식과 컨텍스트 엔진의 역할

  • 로컬 파일 시스템에 마크다운 파일을 넣는 큐레이션된 컨텍스트는 쉽게 낡고 관리 주체가 부재하다는 문제가 있습니다.
  • 에이전트는 첫 번째로 찾은 정보로 만족하는 검색 만족 편향 때문에 최신의 슬랙 대화 기록을 놓치게 됩니다.
  • 컨텍스트 엔진은 커밋 위치와 리뷰어 정보를 활용해 집중할 정보를 찾고 권한과 거버넌스를 존중합니다.

가상 파일 시스템에 문서를 넣는 방식은 문서가 쉽게 낡고 관리하기 어렵습니다. MCP를 사용할 때도 에이전트는 아키텍처 기록만 먼저 찾고 어젯밤의 슬랙 대화를 놓치는 검색 만족 편향을 보입니다. 따라서 조직 내 위치와 커밋 이력을 바탕으로 올바른 정보를 토큰 최적화 방식으로 전달하는 엔진이 필요합니다.

컨텍스트 엔진의 실제 효과와 도구 활용법

  • 컨텍스트를 제공했을 때 벽시계 기준 소요 시간이 2시간 단축되고 토큰 소모량이 1,080만 개로 줄어듭니다.
  • 소셜 커멘트 네트워크는 결정적 프로그래밍으로 깃허브를 분석해 팀의 실제 기여와 전문가 그래프를 파악합니다.
  • 관계형 컨텍스트 엔진은 RAG의 한계를 넘어 사용자의 PR 내역과 같은 관계형 데이터 쿼리를 가능하게 합니다.

동일한 모델에 컨텍스트를 제공한 경우와 그렇지 않은 경우를 비교하면 소요 시간과 토큰 소모량이 대폭 감소합니다. 깃허브를 활용해 팀원의 기여도를 파악하는 오픈소스 도구와 스키마리스 조회 방법을 담은 워크북을 통해 컨텍스트 엔진을 직접 구축할 수 있습니다.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기