LinkedIn의 코딩 에이전트, 500개 스킬로 다시 태어나다

AJ는 LinkedIn에서 소프트웨어 엔지니어로 일하며, 이날 발표에서 사내 코딩 에이전트의 성능을 끌어올리기 위한 컨텍스트 엔지니어링 작업을 다룬다고 예고했다.

AJ가 제시한 목표는 LinkedIn 내부에서 코딩 에이전트의 성능을 컨텍스트 엔지니어링으로 개선하는 것이다. 데모가 아니라 실제 운용이라는 점을 그는 먼저 못 박았다.

사내 팀들은 LinkedIn의 내부 시스템과 코드를 깊이 이해한 코딩 에이전트를 동료처럼 활용해 생산성을 올리고 있다고 AJ는 말했다. 이를 가능케 한 것은 LinkedIn이 자체적으로 만든 컨텍스트 기반 에이전트 플레이북과 도구들이었다. 발표는 왜 만들었는지, 어떻게 만들었는지, 무엇을 배웠는지 세 가지 질문 순서로 진행됐다.

LinkedIn은 코딩 에이전트를 전 엔지니어에게 지급했지만, 대다수는 결국 손으로 코드를 쓰는 쪽으로 돌아섰다. 근본 원인으로 AJ가 든 것은 LLM의 학습 데이터 편향이다. 오픈소스 저장소로 학습된 모델은 LinkedIn의 성숙한 코드베이스와 내부 프레임워크, 내부 시스템에 대한 맥락을 갖지 못한다.

실패 양상은 환각, 작업 도중 멈춤, 그리고 잘못된 내용을 지어내는 것이었다. 그중 마지막을 AJ는 가장 위험한 것으로 꼽았다. 엔지니어들은 에이전트가 올바르게 움직이도록 매번 손으로 프롬프트를 넣어야 했고, 그 시간은 직접 코딩하는 것보다 오래 걸렸다. 결과적으로 많은 엔지니어가 수동 코딩으로 회귀했다.

대부분은 사내 프레임워크와 라이브러리 위에 세워져 있다.

내부 전용 인프라의 예로 자체 데이터베이스, 자체 실험·추적 플랫폼, 자체 구성 관리 시스템이 나왔다. 코딩 에이전트는 이 중 어느 것도 알지 못한다. 신입 엔지니어조차 이런 시스템에 익숙해지려면 일주일짜리 부트캠프를 거쳐야 한다고 AJ는 덧붙였다.

AJ가 던진 문제 설정은 이랬다. Cursor, Claude Code, GitHub Copilot 같은 어떤 코딩 에이전트든 LinkedIn 내부 시스템을 충분히 이해해, 엔지니어가 신뢰할 수 있는 코드를 내놓게 만들 수 있느냐는 것이다.

그가 정의한 신뢰의 기준은 두 갈래다. 코드가 정확해야 하고, 품질이 현직 엔지니어가 쓴 코드만큼 좋아야 한다.

이 신뢰 기준선을 세운 시점은 2025년 초였다. LinkedIn이 그해 초 플레이북 체계를 만들기 시작한 것과 같은 출발점이다.

도구를 다 연결해도 충분하지 않았다고 AJ는 정리했다. 조금만 복잡한 워크플로가 걸리면 에이전트는 제대로 해내지 못했다. 기본 질문에 답하고 코드 예시를 찾는 데까지는 됐지만, 작업을 처음부터 끝까지 안정적으로 완수하지는 못했다.

원인으로 지목된 것은 암묵지다. 특정 에러를 어떻게 고치는지, 어떻게 설정하는지, 특정 에러 로그를 어떻게 디버깅하는지 같은 지식이 문서와 위키, 슬랙 대화에 흩어져 있었다. 문서와 위키는 오래됐거나 중복된 상태일 수 있었다. 도구 접근권이 있어도 에이전트는 길을 잃곤 했다.

두 번째 문제는 컨텍스트 과부하였다. 에이전트가 도구를 점점 더 많이 쓰면 컨텍스트가 넘치기 시작한다. 도구 출력 하나하나가 컨텍스트 공간을 차지하기 때문이다.

결국 에이전트는 작업 도중 자기 컨텍스트를 압축하게 되고, 그 과정에서 정보 일부를 잃는다. 그러면 같은 일을 처음부터 다시 해야 한다.

세 번째 문제는 기억의 부재였다. 에이전트가 세부 사항을 알아내더라도 그 정보를 보유할 방법이 없었다. 지속적인 메모리가 없었기 때문이다.

그래서 엔지니어가 특정 작업을 요청할 때마다 에이전트는 매번 처음부터 시작해야 했다.

2025년 초 LinkedIn이 만든 체계의 이름은 플레이북이다. 도구를 MCP로 제공하는 데 그치지 않고, 지시와 프롬프트도 MCP를 통해 에이전트가 접근하게 했다.

플레이북은 이름과 설명을 갖춘 평범한 도구처럼 보인다. 에이전트는 일반 도구를 부르듯 플레이북을 호출한다. 호출되면 플레이북 안의 지시와 컨텍스트가 도구 출력으로 코딩 에이전트에 반환된다.

이 구조 덕분에 에이전트는 도구와 함께 그 도구를 쓰는 방법까지 받는다. 도구만 주고 사용법은 모델이 알아서 익히길 기대하던 이전 방식과 갈라지는 지점이다.

엔지니어가 LinkedIn에서 Airflow DAG을 어떻게 세팅하느냐고 물으면, 에이전트는 우선 해당 작업을 위한 플레이북이 있다고 판단한다. 그 플레이북을 가져와 정보를 얻고, 그 안의 지시를 따라 관련 도구를 호출해 작업을 끝낸다.

플레이북을 만드는 권한은 열려 있다. LinkedIn의 누구든 플레이북을 만들어 저장소에 체크인하고, 다른 사람 모두가 쓸 수 있게 공개할 수 있다.

LinkedIn의 누구든 플레이북을 만들고 저장소에 체크인해 사내 전체에 공개할 수 있다고 AJ는 밝혔다. 체크인된 플레이북은 다른 사람들이 바로 쓸 수 있는 형태로 저장소에 남는다.

AJ가 꼽은 두 번째로 중요한 원칙은 큰 플레이북을 여러 개의 작은 플레이북으로 나누고, 그 작은 것들을 큰 플레이북에서 참조하게 하는 것이다. 그가 특히 강조한 원칙이었다.

첫 번째 이점으로 제시된 것은 재사용성이다. 작고 자기완결적인 플레이북이면 여러 곳에서 가져다 쓸 수 있다.

영상은 두 번째 이점을 소개하는 도중에 잘린다. 그가 말하려던 나머지 이점은 이 대목의 자막에 남아 있지 않다.

지식베이스라면 어디든 겪는 문제는 낡는다는 점이다. AJ는 컨텍스트를 어떻게 신선하게 유지하느냐가 가장 큰 문제라고 짚었다.

엔지니어가 플레이북을 써서 저장소에 체크인하는 구조 위에서, LinkedIn은 에이전트가 특정 플레이북을 쓴 세션 끝에 학습 내용을 정리하도록 권한다. 오래된 정보, 불일치, 빠진 정보를 식별하는 것이 그 내용이다.

에이전트는 나아가 플레이북 개선안을 마련해 저장소를 갱신하고 PR을 만든다. PR이 올라가면 플레이북이 갱신되는데, AJ는 이를 스스로 배우는 매끄러운 플라이휠이라고 표현했다. 에이전트가 즉석에서 응용할 수 있다는 점이 그 근거로 제시됐다.

LinkedIn에 입사해 노트북을 받으면 이미 설치돼 있는 상태다.

MCP 서버나 플레이북, 도구에 변경이 생기면 모든 노트북에서 1시간마다 자동으로 갱신된다.

하나의 코드 저장소만을 위한 것이 아니라는 뜻이다.

로컬 플레이북은 특정 코드 저장소에만 해당하며, 그 저장소에 함께 체크인된다. 코딩 에이전트가 그 저장소에서 작업할 때만 자동으로 인식된다. 이 구조 덕분에 LinkedIn은 중앙 저장소를 건드리지 않고도 저장소별 플레이북을 늘려갈 수 있다.

하나의 MCP 서버가 모든 플레이북과 도구를 담당한다. 이 단일 서버를 통한 중앙화로 매끄러운 인증과 텔레메트리, 학습 데이터를 확보해 생태계 전체를 개선할 수 있다는 것이 AJ의 설명이다.

MCP에는 공통된 한계가 있다. 도구가 30~40개를 넘어서면 컨텍스트나 시스템 성능이 저하된다는 점을 AJ는 인정했다.

그래서 LinkedIn은 모든 플레이북과 도구를 MCP에 그대로 노출하는 대신 세 개의 메타 도구로 대체했다. 첫 번째는 검색으로, 에이전트가 키워드와 태그로 관련 도구와 플레이북을 찾는다. 두 번째는 스키마 조회로 선택한 도구의 세부 정보를 가져오고, 세 번째는 도구나 플레이북을 실행하는 것이다.

시스템 지시도 LinkedIn이 통제한다. 모든 코딩 에이전트는 도구 사용법과 효율적 검색 방법에 대한 지시를 미리 설정받는다. 이 구조 덕분에 도구와 플레이북을 수천 개 규모로 확장할 수 있었다는 것이 AJ의 주장이다.

성장 추이를 보여주는 차트와 함께 제시된 수치다.

사용자는 엔지니어에 그치지 않는다. 프로덕트 매니저, 디자이너, TPM 등 여러 직군이 도구를 쓰고 있으며, 각자 자기 워크플로를 자동화하려고 플레이북을 직접 가져오고 있다.