MCP 도구를 붙여도 링크드인 코딩 에이전트가 길을 잃은 이유

링크드인이 만들려는 온콜 동료

회사 검색, 문서, 티켓에 Claude Code를 이미 연결해 본 사람이 마주치는 질문은, 그런데도 사내 워크플로에서는 왜 멈추느냐입니다. AJ로 통하는 링크드인 소프트웨어 엔지니어 Ajay Prakash는 그 막힘의 안에서 답을 냅니다. MCP 도구로 링크드인 쪽 자료는 가져올 수 있었지만, 에이전트는 절차에서 여전히 길을 잃었습니다. AI Engineer 채널에 올라온 그의 강연은 그 간극을 실패로 짚은 뒤, 링크드인이 그 도구들 위에 만든 내부 시스템을 따라갑니다.

그는 이 작업을 컨텍스트 엔지니어링으로 봅니다. 코딩 에이전트가 무엇을 보고 무엇을 호출할 수 있는지를 다듬어, 범용 자동완성이 아니라 링크드인 안에서 일하게 만드는 일입니다. 도입부는 온콜 상황을 따라가는 이야기이고, 그는 이를 팀들이 이미 돌리고 있는 실제 운영 사례로 제시합니다.

중요 서비스를 맡은 팀의 엔지니어가 인시던트를 아직 파악하는 중에 오류 급증 알림을 받습니다. 엔지니어는 알림 링크를 Claude Code나 GitHub Copilot 같은 코딩 에이전트에 붙여 넣습니다. 사람이 아직 상황을 잡는 동안, 에이전트는 회사의 디버그 지침을 가져오고, 영향받은 서비스를 짚고, 그 서비스에 해당하는 맥락을 불러온 뒤 로그와 메트릭을 당깁니다. 거기에서 원인과 완화 단계를 제안하고 확인을 기다립니다. 엔지니어가 확인한 뒤의 단계는 Prakash가 이렇게 설명합니다. 에이전트가 완화 조치를 하고, 세부 내용과 오류 메트릭, 대시보드로 인시던트 관리 시스템을 갱신하고, 코드를 체크아웃한 뒤 원인을 겨냥한 풀 리퀘스트를 엽니다.

그는 이 순환이 손으로 하면 몇 시간 걸릴 일을 몇 분의 작업으로 처리한다고 말하고, 이 사례에 “허구가 아니다”라는 딱지를 붙이며, 링크드인 팀들은 이미 코딩 에이전트를 내부 시스템과 코드를 깊이 아는 동료처럼 이렇게 쓴다고 말합니다. 이를 가능하게 하는 시스템을 그의 말로 하면 contextual agent playbooks and tools입니다. 강연의 나머지는 왜 만들었는지, 어떻게 만들었는지, 무엇을 배웠는지입니다.

• Ajay Prakash, 링크드인 — AI Engineer 강연 (YouTube)

엔지니어에게 범용 코딩 에이전트를 쥐여 준 것만으로는 부족했던 이유

링크드인은 많은 회사가 하듯 엔지니어에게 코딩 에이전트를 배포했고, Prakash는 대규모 기업에서는 잘 작동하지 않았다고 말합니다. 그가 보는 원인은 학습 데이터의 빈칸입니다. 모델은 오픈소스 저장소로 학습되었고, 링크드인의 성숙한 내부 코드베이스와 프레임워크, 시스템은 갖고 있지 않았습니다.

그 맥락이 없으면, 그의 말에 따르면 에이전트는 환각을 일으키거나, 작업 중간에 멈추거나, 틀린 세부 내용을 지어냈습니다. 엔지니어는 올바른 일을 시키려고 손으로 프롬프트를 넣었고, 그 시간이 코드를 직접 쓰는 것보다 길어지는 경우가 많았습니다. 많은 엔지니어가 다시 손으로 코딩했습니다.

그가 스케치한, 에이전트가 익혀야 할 스택은 크고 대부분 비공개입니다. 그는 링크드인에 새로 온 엔지니어가 그 시스템에 익숙해지는 데만 일주일짜리 부트캠프를 듣는다고 말합니다. 그 온보딩을, 에이전트에도 같은 조직 맥락이 필요한 이유의 비유로 씁니다.

• 수천 개의 마이크로서비스와 앱을 떠받치는 1,000개가 넘는 저장소
• 그 서비스 아래의 내부 프레임워크와 라이브러리
• 사내 데이터베이스, 실험·추적 플랫폼, 내부 구성 관리 시스템 같은 자체 인프라

기준: 어떤 에이전트든, 신뢰할 수 있는 내부 코드

그들이 세운 설계 질문은, Cursor든 Claude Code든 GitHub Copilot이든, 어떤 코딩 에이전트라도 링크드인 내부를 충분히 이해해서 엔지니어가 믿을 코드를 내놓을 수 있는가였습니다. Prakash는 그 신뢰를 두 가지로 정의합니다. 코드가 맞아야 하고, 품질은 실제 엔지니어가 쓴 코드에 맞아야 합니다.

그것이 팀이 세웠다고 그가 말하는 기준입니다.

첫 돌파구는 내부 MCP 도구였습니다

Prakash는 첫 돌파구를 2025년 초로 잡습니다. 그는 Anthropic이 에이전트를 외부 도구에 잇는 Model Context Protocol, 즉 MCP를 내놓았고, 그것이 에이전트 도구를 만드는 업계 표준으로 빠르게 자리 잡았으며, 링크드인은 첫 도구가 전사 코드 검색인 내부 MCP 서버를 만들었다고 말합니다. 자동 자막은 “MCB”와 “Cloud Code”로 흘립니다. 강연에서 가리키는 것은 Anthropic의 MCP 프로토콜과 Claude Code입니다.

링크드인에는 이미 키워드와 맞춤 필터로 수천 개 저장소를 질의하는 정교한 코드 검색이 있었습니다. 그 시스템을 MCP로 열자 에이전트는 특정 구성을 링크드인이 어떻게 하는지 사내 예시를 찾고, 그 결과로 구현할 수 있었습니다. Prakash는 이것을 큰 돌파구라고 부릅니다. 엔지니어가 설정 방법을 물으면, 에이전트는 추측하는 대신 링크드인 코드를 검색할 수 있었습니다.

이어서 문서, Jira, 슬랙, 데이터 플랫폼, 피처 플래그를 MCP로 더 붙였습니다. 그는 엔지니어가 제품 요구사항 문서(PRD), 설계 문서, Jira 티켓을 코딩 에이전트에 넣으면서 가치가 겹쳐 쌓였다고 설명합니다.

도구만으로는 일을 끝내지 못한 세 가지 이유

그 도구들을 연결해도 조금 복잡한 워크플로에서는 여전히 실패했습니다. Prakash는 도구가 있으면 에이전트가 기본 질문에 답하고 코드 예시를 찾을 수 있었다고 말합니다. 일을 처음부터 끝까지 안정적으로 마치는 것은 다른 기준이었습니다.

첫 번째 실패는 흩어진 현장 지식이었습니다. 특정 일을 끝내려면 주어진 오류를 어떻게 고치고, 시스템을 어떻게 설정하고, 특정 로그를 어떻게 디버그하는지를 알아야 했습니다. 그 지식은 문서, 위키, 슬랙 대화에 나뉘어 있었고, 오래되었거나 중복된 경우가 많았습니다. 도구는 그 자료가 있는 곳을 가져옵니다. 거기에서 절차를 짜는 일은 별개의 단계입니다. 접근이 되는 에이전트도 여전히 “길을 잃었습니다.”

두 번째 실패는 컨텍스트 과부하입니다. 도구 결과가 돌아올 때마다 에이전트의 컨텍스트 창, 즉 그 세션의 작업 기억을 차지했습니다. 결국 세션은 앞선 내용을 요약하거나 버리며 압축해야 했고, 정보가 빠져 에이전트는 일을 다시 해야 했습니다.

세 번째 실패는 세션을 넘는 기억이 없다는 점이었습니다. 에이전트가 작업을 파악해도, 다음 엔지니어가 같은 일을 요청하면 처음부터 다시 시작했습니다. 플레이북은 나중에 이를 저장소 안의 지침 파일로 다룹니다.

• 특정 오류, 설정, 로그에 대한 현장 지식은 문서, 위키, 슬랙에 흩어져 있었습니다
• 도구 결과가 컨텍스트 창을 채워, 압축 과정에서 정보가 빠졌습니다
• 풀어 낸 작업에도 이어지는 기억이 없어, 다음 세션은 처음부터 다시 시작했습니다

플레이북: 도구와 같은 방식으로 넘어오는 지침

Prakash는 2025년 초에, MCP가 도구와 함께 그 도구를 쓰는 지침이나 프롬프트도 넘기도록 플레이북을 만들었다고 말합니다. 각 플레이북은 에이전트가 호출할 수 있는, 이름과 설명이 있는 도구로 나타납니다. 호출하면 지침과 맥락이 도구 출력으로 돌아오므로, 에이전트는 같은 채널로 기능과 안내를 받습니다.

그가 드는 사용 예는, 엔지니어가 링크드인에서 Apache Airflow DAG, 즉 작업의 방향 비순환 그래프를 어떻게 세우는지 묻는 장면입니다. 에이전트는 그 작업의 플레이북을 고르고, 돌아온 지침을 읽은 뒤, 관련 도구를 호출해 일을 끝냅니다.

링크드인 누구나 플레이북을 작성하고, 저장소에 넣고, 다른 사람에게 열어 줄 수 있습니다.

작성 원칙 두 가지, 그리고 스킬과의 비교

플레이북이 늘어나자, Prakash는 모두에게 두 가지 기본 원칙을 따르라고 했다고 말합니다. 첫째, 플레이북은 하나의 구체적인 작업만으로 완결되어야 에이전트가 올바른 것을 고를 수 있습니다. Airflow DAG 플레이북은 그 DAG 이야기에 머뭅니다.

둘째, 큰 플레이북은 상위 플레이북이 참조할 수 있는 더 작은 플레이북으로 나눕니다. 나누면, 그의 말에 따르면 두 가지를 얻습니다. 작은 플레이북을 여러 상위에서 참조할 수 있어 다시 쓸 수 있고, 에이전트는 그 맥락 조각이 필요할 때만 더 작은 플레이북을 불러 점진적으로 발견합니다.

그는 플레이북을 스킬과도 비교합니다. 스킬은 에이전트가 필요할 때 불러 오도록 지침을 묶는 업계의 패턴입니다. Prakash는 플레이북이 같은 아이디어이고, 링크드인은 스킬이 생기기 전에 플레이북 시스템을 만들었으며, 플레이북은 조직 맥락을 담아 준비를 거의 들이지 않고 MCP로 제공하는 쪽에 더 맞춰져 있다고 말합니다.

플레이북이 낡지 않게 하려는, 권장된 순환

그가 짚는 지식 베이스의 문제는 낡음입니다. 지침이 오래됩니다. 권장되는 에이전트 흐름은 플레이북을 쓴 뒤, 세션이 끝날 때 배운 점, 즉 오래되었거나 어긋나거나 빠진 정보를 찾고, 저장소의 플레이북 파일을 고친 다음 풀 리퀘스트를 여는 것입니다.

그는 풀 리퀘스트 뒤에 플레이북이 갱신된다고 말합니다. 그는 이것을 플라이휠이라고 부릅니다. 에이전트가 회사 지침을 가져다 쓰는 동시에 고친다는 뜻입니다.

노트북 MCP 하나, 중앙 플레이북, 로컬 플레이북

그가 설명하는 배포는 링크드인 노트북에 미리 깔린 로컬 MCP 서버입니다. 입사해 노트북을 받으면 서버는 이미 있습니다. Prakash는 서버, 플레이북, 도구의 업데이트가 한 시간마다 도착한다고 말합니다.

플레이북은 두 종류로 나뉩니다. 중앙 플레이북은 여러 저장소에 걸쳐 적용되는 공통 작업을 다룹니다. 로컬 플레이북은 특정 저장소에 있고, 코딩 에이전트가 거기서 일할 때만 집어 옵니다. 그래서 중앙 카탈로그를 바꾸지 않고도 저장소별 지식이 늘어날 수 있습니다.

MCP 서버 하나가 모든 플레이북과 도구의 앞단이 되어, 인증과 텔레메트리, 학습을 중앙에서 처리할 수 있습니다.

모든 도구를 나열하지 않게 된 이유

MCP 표면에 플레이북과 도구를 전부 올리는 방식은, 그가 MCP에서 흔히 보는 문제로 두는 규모 한계에 부딪혔습니다. 도구가 대략 30개나 40개를 넘으면 컨텍스트와 시스템 성능이 나빠졌습니다.

그들이 쓴 우회는 카탈로그 앞에 메타 도구 세 개를 두는 방식입니다. 에이전트는 키워드와 태그로 검색하고, 고른 도구나 플레이북의 스키마를 가져온 뒤, 그 항목을 실행합니다. 링크드인은 각 코딩 에이전트에 검색과 나머지 메타 도구를 효율적으로 쓰는 시스템 지침을 미리 넣습니다. Prakash는 이 설계로 도구와 플레이북을 수천 개까지 늘릴 수 있었다고 말합니다.

누가 쓰나, 그리고 기업을 위한 결론 두 가지

무대에서 보여 준 성장 차트에서 Prakash는 도구와 플레이북의 하루 사용자가 8,000명을 넘고 플레이북은 600개를 넘는다고 인용합니다. 그는 프로덕트 매니저, 디자이너, 테크니컬 프로그램 매니저(TPM)도 엔지니어와 함께, 직무를 가로질러 도구를 쓰고 플레이북을 가져온다고 말합니다. 올라온 영상 제목은 이 강연을 “500 Skills, Zero Fine-Tuning”으로 포장합니다. 말로 한 강연에는 스킬 500개라는 수치도, 파인튜닝을 하지 않는다는 방침도 없습니다.

그의 첫 번째 결론은, MCP 서버를 만들기 전부터 포함해 품질과 신뢰성을 첫날의 제약으로 두었기 때문에 시스템이 작동했다는 것입니다. 그는 이 원칙을, 빨리 움직이는 동안에도 떨어지지 않도록 생산성과 함께 시스템의 품질과 신뢰성을 보장하는 일로 설명합니다.

그의 두 번째 결론은, MCP 검색과 티켓을 이미 연결한 실무 개발자를 향한 주장입니다. 대규모 기업에서는, 그의 말에 따르면, 회사가 에이전트가 그 안에서 일할 인프라도 만들지 않으면 최신 에이전트와 모델은 효과를 내지 못한 채로 남습니다. 그 인프라는 플레이북, 노트북 MCP, 그리고 카탈로그가 세션을 가득 채우지 않게 하는 메타 도구입니다.

• 유튜브에서 강연 보기