Poooling Forest
터미널과 AI 에이전트, 회사의 표준 도구가 하나로 연결되는 에디토리얼 표지 이미지
Engineering & Tech

에이전트는 똑똑한데, 우리 회사를 모른다

같은 에이전트로 짠 코드가 사람마다 딴판이었다. 문제는 모델이 아니라 우리 기준이 에이전트에게 닿은 적이 없다는 것이었다. 회사의 표준과 실행 도구를 에이전트의 기본 환경에 심은 풀링포레스트 Agent Harness 이야기.

송찬영

CTO

요즘 우리 팀에 AI 에이전트를 안 쓰는 개발자가 없다. 어느 날 아침, 같은 기능을 두고 두 사람이 올린 코드를 나란히 열어 봤다. 둘 다 에이전트한테 시켜 받은 결과물이다. 그런데 두 회사에서 짠 코드처럼 달랐다.

한쪽은 인증을 제대로 걸고, 우리가 늘 쓰던 스택을 따라갔다. 다른 한쪽은 입력을 검증 없이 그대로 받고, 처음 보는 라이브러리를 끌어다 썼다. 속도는 둘 다 빨랐다. 빠른 게 더 문제였다. 어디서 어긋났는지 짚기도 전에 둘 다 다음 작업으로 넘어가 있었다.

같은 기능을 두고 서로 다른 방향으로 갈라진 두 개의 코드 화면

처음엔 모델 탓인 줄 알았다

흩어진 문서와 반복되는 온보딩 자료가 책상 위에 쌓인 장면

처음엔 이걸 에이전트 성능 문제로 봤다. 더 좋은 모델을 붙이면 정리될 줄 알았다. 아니었다. 더 똑똑한 모델을 붙여도 결과물은 여전히 제각각이었다.

모델은 똑똑한데, 우리 회사를 모른다. 우리가 어떤 순서로 일하는지, 무엇을 먼저 잠그는지, 어떤 스택을 표준으로 두는지 한 번도 들은 적이 없다. 똑똑함만으로는 우리 방식이 나오지 않는다.

문제는 모델이 아니라, 우리 기준이 에이전트에게 닿은 적이 없다는 것이었다.

신입이 출근한 첫날과 비슷하다. 아무리 똑똑해도 회사의 방식을 모르면 결과물은 제각각이다. 다른 점이 하나 있다. 신입은 옆자리에 물어보기라도 한다. 에이전트는 묻지 않고 그냥 짠다.

그래서 사람 교육을 그만뒀다

보통은 이 간극을 교육으로 메운다. 온보딩 문서를 쓰고, 컨벤션을 정리하고, 리뷰에서 계속 잡아준다. 우리도 그렇게 했다. 그런데 교육은 매번 처음으로 돌아간다. 사람이 들어오고 나갈 때마다, 프로젝트가 바뀔 때마다 같은 설명을 반복했다.

게다가 코드를 짜는 손은 점점 에이전트 쪽으로 넘어가고 있다. 사람을 교육해도, 정작 키보드를 두드리는 에이전트는 그 교육 자리에 없었다. 그래서 방향을 바꿨다. 기준을 사람 머릿속이 아니라, 에이전트가 일하는 실행 환경 안에 넣기로 했다.

풀링포레스트 Agent Harness

AI 에이전트와 회사 표준 도구가 하나의 실행 환경으로 연결된 구조 이미지

우리는 이 구조를 Agent Harness라고 부른다. 거창한 이름이 아니다. 에이전트가 프로젝트를 시작할 때, 회사의 표준 지식과 실행 도구를 함께 쥐고 출발하게 만드는 장치다.

에이전트가 프로젝트를 열면 우리가 만든 Skill이 함께 붙는다. Skill은 사용법 안내문이 아니라 작업 지침이다. 인프라를 어떻게 설계하는지, 보안에서 무엇을 먼저 잠그는지, 어떤 스택을 표준으로 쓰는지, 프로젝트를 어떤 순서로 진행하는지를 담는다.

이 Skill은 개발자가 처음 PC를 받을 때 같이 깔린다. 좋은 개발 문화를 잘하는 몇 사람의 습관이 아니라, 켜자마자 작동하는 기본값으로 만든 셈이다.

기준은 Skill이 아니라 DB에 둔다

중앙의 기준을 한 번 고치면 여러 프로젝트로 동시에 반영되는 구조 이미지

제일 오래 고민한 건 기준을 어디에 두느냐였다. 운영지침과 베스트 프랙티스는 계속 바뀐다. 어제의 표준이 다음 분기엔 낡는다. 그걸 Skill이나 문서에 박아두면, 고치는 순간 흩어져 있던 모든 사본이 옛날 버전이 된다.

그래서 기준 자체는 Skill에 담지 않았다. 회사 매뉴얼 DB에서 중앙으로 관리하고, Skill은 풀링포레스트 CLI로 그 DB를 호출해 그때그때 최신 기준을 불러온다. 누가 어떤 기준을 언제 가져갔는지, 권한과 로그는 API가 맡는다.

효과는 단순한 데서 온다. 기준을 한곳에서 한 번 고치면, 모든 프로젝트의 에이전트가 다음 작업부터 바뀐 기준으로 일한다. 다시 배포할 일도, 문서를 새로 돌릴 일도 없다.

평균 이상이 기본값이 되는 것

여러 프로젝트의 결과물이 하나의 기준 위에서 가지런히 정렬된 장면

이 구조에서 내가 원한 건 화려한 자동화가 아니다. 평균 이상의 결과물이 잘하는 몇 사람의 습관이 아니라, 그냥 우리 조직의 기본값이 되는 것이다.

그러면 신입도 첫 프로젝트부터 회사 기준 위에서 시작한다. 보안과 인프라 원칙은 사람의 기억이 아니라 실행 환경에서 먼저 적용된다. 리뷰는 사후에 사고를 잡아내는 일에서, 앞단에 적용된 기준을 확인하는 일로 옮겨간다.

개발 조직의 경쟁력은 이제 어떤 AI 도구를 쓰느냐에서 갈리지 않는다. 좋은 도구는 누구나 똑같이 산다. 차이는 그 도구에 무엇을 쥐여주느냐에서 난다. 에이전트에게 어떤 기준을 줄 것인가. 어떤 도구로 실행하게 할 것인가. 그걸 어떻게 조직 전체에 똑같이 적용할 것인가.

우리는 이 구조를 밖에서 사 오지 않았다. 내부에서 직접 만들고, 우리 프로젝트에 매일 쓰면서 다듬고 있다. 그래서 한 가지 질문이 남는다.

당신의 조직은 지금 에이전트에게 무엇을 기준으로 쥐여주고 있나.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.

기술 리더십조직 전략AI 시대 개발자Agent Harness엔지니어링 문화