씨앗과 발아: 현장에서 진화하는 소프트웨어

이 글은 연재 4편 가운데 3편입니다. 1편에서는 범용 작업자가 된 에이전트와 전문 도구의 분리를 이야기했습니다. 이 연재에서 '작업자'는 사람이 아니라 범용 에이전트를 가리킵니다. 2편에서는 분리망을 가진 조직에도 그 작업자가 일할 실행환경이 필요하다고 주장했습니다. 3편에서는 이 환경을 전제로 소프트웨어를 만들고 고객 현장에 적용하는 일을 생각해보려 합니다.

제품을 개발하는 곳과 사용하는 곳의 조건은 다릅니다. 개발 환경에서 보지 못했던 데이터가 들어오고, 같은 이름의 시스템도 버전과 설정이 다르며, 문서에 적힌 업무와 실제로 수행하는 업무 사이에는 차이가 있습니다. 공급자는 공통 기능을 만들지만, 그 기능이 현장에서 제 역할을 하게 만드는 데에는 또 다른 작업이 필요합니다.

에이전트는 이 현장 적용 과정에 참여할 수 있습니다. 사람이 현장을 이해하고 판단하는 동안 에이전트가 데이터를 살펴보고, 연결 코드를 작성하고, 변경을 시험할 수 있습니다. 한편 제품 내부에도 환경의 차이를 감지하고 대응하는 기능을 넣을 수 있습니다. 둘 다 ‘현장에 적응한다’고 표현할 수 있지만, 구분해서 보아야 할 두 가지 일입니다.

첫 번째는 사람과 에이전트가 제품을 만들고 현장에 적용하는 방식입니다. 누가 어떤 도구를 사용해 무엇을 바꿀 것인가의 문제입니다. 두 번째는 제품이 실행 중에 환경과 데이터의 차이에 대응하는 구조입니다. 어떤 차이를 제품 내부에서 처리하고, 무엇을 다음 실행을 위해 남길 것인가의 문제입니다.

사람과 에이전트의 현장 협업은 자기적응 기능이 없는 일반 소프트웨어에도 적용할 수 있습니다. 제품 내부의 적응 기능은 규칙과 통계 처리, 필요한 지점의 모델 호출로 구현할 수도 있습니다. 두 방식은 서로 다른 설계 문제를 다루며, 현장에서 얻은 경험을 다음 제품에 반영하는 과정에서 만납니다.

외부의 씨앗과 현장의 발아

내부망에 코딩 에이전트가 도입되면 SI의 수행 방식도 달라질 수 있습니다. 외부에서는 Claude Code나 Codex를 사용하고, 내부망에서는 별도로 구축한 에이전트를 운용하는 상황을 생각해볼 수 있습니다.

이때 두 환경의 모델과 연산 자원, 연결할 수 있는 도구는 서로 다를 수 있습니다. 내부에서 사용할 수 있는 자원이 제한되어 있다면 외부와 같은 수준의 역량을 확보하기 어려울 수도 있습니다. 각각의 환경에서 맡길 수 있는 일을 나누고, 그 사이를 어떻게 연결할지 정해야 합니다.

외부의 에이전트는 제품의 구조를 설계하고, 공통 기능을 구현하고, 다양한 조건을 가정해 시험하는 데 활용할 수 있습니다. 현장 내부의 에이전트는 실제 데이터와 시스템, 조직의 업무 맥락에 접근할 수 있습니다. 추론 능력과 접근 가능한 정보가 서로 다른 두 환경에 나뉘어 있는 셈입니다. 사업 수행 방식은 이 차이를 전제로 설계해야 합니다.

이러한 분업을 ‘씨앗과 발아’에 비유할 수 있습니다. 외부에서는 씨앗을 만들고, 현장에서는 그 씨앗을 발아시킵니다.

여기서 씨앗은 특정 현장에 가져갈 초기 소프트웨어와, 그 소프트웨어가 현장에 맞게 달라질 수 있는 구조를 함께 뜻합니다. 기본 기능은 이미 동작해야 하고, 입력과 출력이 무엇인지, 어느 부분을 조정할 수 있는지, 조정한 결과를 어떻게 확인하는지까지 정해져 있어야 합니다. 발아는 실제 환경을 관찰하면서 그 가능성을 구체적인 연결과 동작으로 만드는 과정입니다.

예를 들어 운영 데이터를 분석하는 제품을 공급한다고 해봅시다. 외부에서는 분석 엔진과 공통 데이터 구조, 결과를 확인할 예제와 시험 방법을 준비할 수 있습니다. 현장에서는 어떤 수집기를 쓰는지, 데이터가 어디에 쌓이는지, 서비스 이름이 어떻게 표현되는지, 누구에게 어떤 결과를 전달해야 하는지를 확인합니다. 공통 제품을 실제 업무에 연결하는 데 필요한 차이가 이때 드러납니다.

현장에서는 실제 환경에 맞춰 스크립트와 설정 파일, 메모리 파일을 작성합니다. 스크립트는 현장의 시스템을 연결하고, 설정 파일은 환경의 차이를 표현하며, 메모리 파일에는 이미 확인한 사실과 작업상의 주의점을 남깁니다.

이렇게 남긴 정보는 같은 현장에서 다음 작업을 수행할 사람이나 에이전트가 매번 처음부터 조사하는 부담을 줄여줍니다. 다만 확인된 사실과 잠정적인 추정은 구분해야 하고, 언제 어떤 조건에서 얻은 정보인지도 함께 알 수 있어야 합니다.

공급자가 미리 잘 준비할수록 현장의 에이전트가 감당해야 하는 불확실성은 줄어듭니다. 사용할 수 있는 연결 지점, 예제, 오류 설명, 검증 명령이 명확하면 조율해야 할 작업을 작게 나눌 수 있습니다. 여기에 현장 모델의 역량을 고려해 맡길 범위를 정하고, 어려운 판단과 수정은 사람이 맡거나 추가 지원으로 이어가도록 구성해야 합니다.

씨앗의 씨앗과 FDE의 역할

현장의 차이를 처리하는 일은 지금도 SI에서 중요합니다. 고객의 시스템을 연결하고 업무에 맞는 소프트웨어를 만드는 경험은 에이전트가 등장했다고 사라지지 않습니다. 오히려 사람이 그 경험을 에이전트가 수행할 수 있는 작업과 검증 기준으로 풀어주는 일이 더 중요해집니다.

여기에 공통 제품을 현장에 적용하고 발전시키는 FDE, 즉 Forward Deployed Engineer의 역할을 연결해볼 수 있습니다. Palantir의 공식 설명은 현장에 가까이 있는 엔지니어와 핵심 제품 개발팀이 함께 피드백을 종합해 새 기능을 만드는 과정을 강조합니다. 제가 주목하는 것은 현장 문제 해결과 제품 개선이 이어진다는 점입니다.

이 관계를 씨앗의 비유로 이어가면, FDE는 ‘씨앗의 씨앗’에 해당하는 공통 구상을 바탕으로 현장에 가져갈 씨앗을 만들고, 현장의 AI 에이전트와 함께 발아를 돕는 사람입니다.

‘씨앗의 씨앗’은 여러 현장에 반복해서 적용할 수 있는 설계 원칙과 공통 기반을 뜻합니다. 무엇을 같은 구조로 유지하고 어떤 차이를 현장에 맡길지, 어떤 결과를 올바른 동작으로 인정할지에 관한 지식도 포함합니다. FDE는 이 기반을 이해하면서 현장의 조건에 맞는 구현을 만들어갑니다.

FDE는 고객이 해결하려는 문제를 구체화하고, 제품의 어느 부분에서 해결할지 판단하며, 변경 결과가 실제 업무에 맞는지 확인합니다. 고객의 요청을 개발 작업으로 풀어내는 과정에서 현장별 설정으로 충분한 요구와 공통 제품의 결함을 구분하는 일도 맡습니다.

에이전트는 그 판단을 실행으로 옮기는 데 참여합니다. 데이터 구조를 조사하고, 어댑터의 초안을 만들고, 변경 전후의 결과를 비교하고, 확인한 내용을 문서로 남길 수 있습니다. 사람이 모든 파일을 직접 작성해야 한다는 제약은 줄어들지만, 무엇을 바꾸어야 하고 언제 충분히 해결되었다고 볼 것인지의 판단은 여전히 필요합니다.

FDE는 변경 내용을 어디에 남길지도 정해야 합니다. 고객마다 다른 값은 설정과 매핑으로, 여러 시스템을 연결하는 코드는 어댑터로, 반복해서 쓸 조사 순서는 Skill과 업무 절차로 남길 수 있습니다. 올바른 결과를 구분하게 해준 사례는 평가와 인수 기준으로 정리합니다. 현장 요구를 이런 형태로 풀어놓으면 고객의 에이전트가 달라져도 같은 기능과 지식을 다시 활용할 수 있습니다.

SI에서 쌓아온 시스템 연결과 현장 조율 경험은 이런 FDE의 수행 방식으로 이어질 수 있습니다. 재사용 가능한 기반을 제품으로 유지하면서 사람과 에이전트가 함께 현장 적합성을 만들고, 그 결과를 공통 제품에 되돌리는 역할입니다. 저는 앞으로 이런 역할이 개발 사업에서 차지하는 비중이 커질 것이라고 생각합니다.

이 방향을 실제 사업 방식으로 만들려면 현장 작업을 제품에 되돌리는 시간이 확보되어야 합니다. 현장에서 급히 고친 코드가 고객별 분기로만 남고, 공통 제품팀은 그 이유를 알지 못한다면 다음 현장에서도 같은 일을 반복하게 됩니다. 현장 해결과 공통 제품 개선을 함께 책임지는 구조가 씨앗의 품질을 높입니다.

제품의 변화와 축적을 위한 구조

현장마다 반복되는 조정은 제품 자체의 구조를 바꾸는 단서가 됩니다. 어떤 차이는 사람이 설정하도록 열어두고, 어떤 차이는 제품이 데이터를 관찰해 직접 처리하도록 만들 수 있습니다. 후자의 범위를 넓히려면 제품이 무엇을 바꾸고 어떤 경험을 남길지 설계해야 합니다.

씨앗을 설계할 때 모든 현장 조건을 미리 구현하기는 어렵습니다. 대신 견고하게 유지할 뼈대와 변경을 허용할 부분, 변경을 축적하는 부분을 나누어 현장의 다양한 상황에 적응할 수 있도록 설계해야 합니다.

이 구상에서는 세 부분의 책임을 나누는 것이 중요합니다. ‘견고한 뼈대’는 제품의 기본 동작과 약속을 유지합니다. ‘변경을 허용하는 부분’은 현장마다 다른 조건을 수용합니다. ‘변경을 축적하는 부분’은 확인한 경험을 다음 실행과 다음 작업에 전달합니다.

견고한 부분도 제품 개발 과정에서는 바뀔 수 있습니다. 다만 현장 작업이 임의로 흔들어도 되는 부분과 공통 제품의 검토를 거쳐 바꿀 부분을 나누어야 합니다. 예를 들어 데이터 필드의 이름을 조정하는 일과, 분석 결과를 성공으로 판정하는 기준을 바꾸는 일은 같은 권한으로 처리할 일이 아닙니다.

변경을 허용하는 방법에 소스코드 수정만 있는 것은 아닙니다. 현장별 차이를 설정으로 충분히 표현할 수 있다면 그 방법을 쓰면 됩니다. 정해진 변환으로 해결할 수 있는 차이는 어댑터로 구현하고, 의미 판단이 필요한 부분에는 모델을 사용할 수 있습니다. 무엇이 달라지는지에 따라 가장 단순하고 확인하기 쉬운 방법을 선택할 수 있어야 합니다.

확장 가능한 구조는 사람이나 외부 작업자가 설정과 처리 방법을 바꿀 수 있도록 접점을 제공합니다. 자동 적응은 제품이 실제 데이터를 관찰해 그 설정이나 처리 방법을 선택하는 기능입니다. 선택한 결과를 저장해 다음 실행에도 활용하면 적응의 효과가 지속됩니다. 변경할 자리를 만드는 것과 변경을 자동으로 선택하고 축적하는 것은 각각 설계해야 합니다.

‘현장에서 진화하는 도구’라는 구상은 바로 이 경계에서 시작합니다. 어디까지를 제품이 스스로 처리하고, 어느 지점에서 사람이나 외부 작업자에게 넘길 것인지 정해야 합니다. 범용 에이전트가 제품을 고칠 수 있다는 사실만으로 제품 내부의 자동 적응이 완성되는 것은 아닙니다.

운영 데이터 분석 제품의 적응형 분석 계층

이 문제를 구체적으로 다뤘던 작업이 그 제품의 적응형 분석 계층입니다. 운영 데이터 분석에서는 현장마다 수집기와 데이터 형식이 다릅니다. 같은 CPU 사용량도 어떤 곳에서는 현재 사용률로 들어오고, 다른 곳에서는 누적 사용 시간으로 들어옵니다. 메모리 사용량을 비율로 계산하려면 어떤 값이 사용량이고 어떤 값이 상한인지도 알아야 합니다.

분석기가 기대하는 형식으로 데이터가 들어온다는 가정이 깨지면, 뒤의 추론이 좋아도 필요한 정보를 보지 못할 수 있습니다. 그 제품에서는 이 입력의 차이를 다루는 적응 계층을 구현했습니다. 먼저 데이터 구조를 탐색하고 분석 결과를 종합하는 파이프라인을 실험했고, 이후에는 기존 분석기가 사용할 수 있도록 입력을 변환하는 자동매핑 어댑터를 만들었습니다.

먼저 실험용 합성 파이프라인은 입력에서 필드와 수치 데이터를 찾아 공통 형태로 펼치고, 값의 변화 특성을 살펴 누적값과 시점별 값을 구분했습니다. 누적값은 변화량으로 바꾸어 비교하고, 여러 지표가 함께 움직이거나 시간차를 두고 움직이는 관계를 계산했습니다. 로그에서는 특정 오류 단어만 찾는 대신 발생량의 급증이나 희소성과 같은 특징을 이용해 살펴볼 대상을 추렸습니다.

실험용 파이프라인에서는 데이터 처리와 통계 계산을 코드가 수행하고, 마지막 해석 단계에서 모델을 한 번 직접 호출했습니다. 계산으로 얻은 관찰 결과를 모델에 전달해 의미를 해석하도록 한 구조입니다.

이처럼 제품 내부에서 반복하는 분석 기능은 필요한 코드와 모델 호출로 구현할 수 있습니다. 여러 도구를 조합하는 범용 작업자와, 특정 입력의 차이를 처리하는 적응 계층은 각자의 역할에 맞는 실행 구조를 갖습니다.

이후에는 엔진이 예상하지 못한 지표 형식을 기존 분석기가 읽는 공통 구조로 변환하는 자동매핑 어댑터를 구현했습니다. 이 어댑터는 필드 이름의 규칙, 값의 범위, 누적값 여부 등을 조합합니다. 매핑 자체에는 모델 호출을 사용하지 않았습니다. 원본 데이터를 덮어쓰지 않고 읽는 시점에 변환된 보기를 제공하기 때문에, 매핑을 끄면 원래 경로를 사용할 수 있습니다.

예를 들어 누적 CPU 사용 시간을 사용률로 바꾸거나, 메모리 사용량을 메모리 한도로 나누어 비율로 만드는 것입니다. 개발자가 특정 데이터에 맞춰 수동으로 만들었던 매핑을 자동으로 재현할 수 있는지 확인했고, 확인한 실제 데이터 사례에서는 기준 결과와의 일치를 검증했습니다. 이전의 실험용 합성 경로는 이후 엔진의 실행 모드에서 제외되었습니다. 자동매핑 어댑터는 입력의 차이를 처리하는 데 초점을 맞춘 별도의 구현입니다.

이 구현에서 검증한 범위는 일부 실제 데이터의 입력 차이를 발견하고 공통 분석 구조로 연결하는 것이었습니다. 전체 진단 품질을 비교하는 평가는 당시 완료되지 않았습니다. 매핑의 정합성과 최종 진단의 유용성을 각각 확인해야 적용 범위를 넓힐 수 있습니다.

오히려 이 작업에서 인상적이었던 것은 실제 데이터가 드러낸 조용한 실패였습니다. 초기 구현은 메모리 사용량에 해당할 법한 필드들 가운데 하나를 골랐는데, 실제 사용량 대신 값이 계속 0인 다른 필드를 선택했습니다. 매핑 과정은 성공했고 결과 행도 생겼지만, 계산된 메모리 사용률은 계속 0이었습니다.

개발 과정에서 원본 필드와 변환된 값을 기준 결과와 비교하면서 이 오류를 발견했습니다. 그 뒤 값에 유효한 변화가 있는지 살피고, 실제 사용량에 해당하는 후보를 우선하도록 선택 규칙을 고쳤습니다. 사람이 실행 결과와 근거를 확인해 교정한 경험이 다음 구현에 반영된 것입니다.

이 사례는 적응 기능 자체도 검증의 대상임을 보여줍니다. 정해진 형식만 받던 제품이 더 다양한 입력을 받아들이게 되면, 잘못된 입력 해석이 그럴듯한 출력으로 이어질 가능성도 생깁니다. 따라서 무엇에 적응했는지, 무엇을 근거로 선택했는지, 처리하지 못한 데이터는 무엇인지를 함께 남겨야 합니다. 이 기록이 다음 교정의 출발점이 됩니다.

자기치유와 자기진화의 범위

이런 적응을 더 확장하면 자기진화 에이전트(self-evolving agents)와 자기치유 계층(self-healing layer)의 문제로 이어집니다. 실패를 어떻게 발견하고, 허용된 범위에서 무엇을 바꾸며, 효과가 있었던 변화를 어떻게 다음 실행에 남길지가 핵심입니다.

이를 구체적인 제품으로 구현하려면 변화하는 대상부터 정해야 합니다. 한 번의 실행에서 다른 처리 방법을 고르는 것인지, 설정을 바꾸는 것인지, 메모리를 갱신하는 것인지, 코드와 테스트를 수정하는 것인지에 따라 필요한 구조가 달라집니다. 변화의 대상과 범위가 분명해야 구현 방법도 정할 수 있습니다.

이 층위들은 함께 개선될 수도 있지만, 하나의 변화가 다른 변화까지 뜻하지는 않습니다. 그 제품에서 입력을 맞추는 규칙을 고친 일, 현장의 에이전트에게 더 나은 조사 절차를 제공하는 일, 모델을 다시 학습하는 일은 바꾸는 대상과 확인할 결과가 다릅니다. ‘학습’이나 ‘진화’라는 말만으로 묶기보다 무엇이 어디에 남아 다음 실행을 바꾸는지 설명해야 합니다.

이 글에서 자기치유는 실패하거나 어긋난 동작을 발견했을 때, 허용된 범위의 변경을 통해 기대한 동작을 회복하는 것으로 보겠습니다. 예를 들어 입력 필드의 이름이 달라져 기존 매핑이 실패했을 때 새로운 매핑 후보를 찾고, 기존의 분석 의미가 보존되는지 확인한 뒤 적용하는 흐름을 설계할 수 있습니다. 이는 앞서 설명한 그 제품의 구현에서 더 나아갈 수 있는 방향입니다.

자기진화는 그 변화 중 유효한 것을 남겨 다음 작업에도 활용하고, 새로운 조건을 처리할 수 있는 범위를 넓히는 과정으로 보겠습니다. 여기에 모델의 가중치를 다시 학습하는 과정이 반드시 필요한 것은 아닙니다. 검증된 매핑, 새 어댑터, 더 나은 작업 절차, 재현 가능한 실패 사례가 남는 것만으로도 소프트웨어가 다음 환경에 대응하는 방식은 달라질 수 있습니다.

한 실행 안에서 임시로 다른 방법을 시도해 성공했다면 그 실행의 적응입니다. 다음 실행에서도 같은 조건을 알아보고 검증된 방법을 재사용한다면 경험이 축적된 것입니다. 그 방법을 다른 현장에서도 쓸 수 있도록 정리해 배포하면 제품의 개선으로 이어집니다. 변화가 어디에 남는지에 따라 이 세 단계를 구분할 수 있습니다.

변경 후보를 만드는 주체도 하나일 필요는 없습니다. 제품 내부의 작은 모델이 새 매핑을 제안할 수 있고, 현장의 범용 에이전트가 스크립트를 작성할 수 있으며, 사람이 공통 코드를 수정할 수도 있습니다. 후보를 생성하는 방법과 그 후보를 제품의 유효한 변경으로 채택하는 절차는 각각 설계해야 합니다.

경험을 남기는 메모리에도 같은 문제가 있습니다. 예를 들어 ‘이 서비스는 평소 이 정도의 메모리를 사용한다’는 정보는 다음 분석의 출발점이 될 수 있습니다. 하지만 그 기억 때문에 현재의 다른 증거를 보지 않게 되면 새로운 장애를 놓칠 수 있습니다. 과거의 기준은 현재 관찰로 수정할 수 있는 가정이어야 합니다.

그 제품의 후속 설계에서는 과거의 기준과 알려진 사례를 참고하는 경로, 현재 데이터를 새롭게 관찰하는 경로를 구분하는 방안을 검토했습니다. 보고서와 관찰 기록은 누적하되, 그 기록에서 계산한 정상 범위나 판단 기준은 주기적으로 다시 계산하고 오래된 정보의 영향은 줄이는 방식입니다. 이 구상은 아직 설계 단계이며, 경험의 축적이 실제로 진단 품질을 높이는지는 추가로 확인해야 합니다.

기억을 많이 남기는 것과 유용한 경험을 축적하는 것은 다릅니다. 어떤 환경에서 성립했던 사실인지, 그 환경이 지금도 유지되는지, 어떤 반례가 발견되었는지까지 다룰 수 있어야 합니다. 새 경험을 채택하는 능력과 함께 잘못되거나 낡은 경험을 수정하고 버리는 능력도 필요합니다.

교정의 근거가 되는 원장과 트레이스

저는 현장의 변화를 다루는 제품이라면 모든 실행을 원장과 트레이스에 기록하고, 그 기록을 바탕으로 감사와 교정을 수행할 수 있어야 한다고 생각합니다. 문제가 발생했을 때 결과뿐 아니라 그 결과가 만들어진 과정까지 살펴볼 수 있어야 하기 때문입니다.

실행 원장은 어떤 작업과 변경이 있었는지 남기는 기록이고, 트레이스는 그 결과에 도달하기까지의 호출과 판단 근거, 중간 산출물을 따라갈 수 있게 하는 기록입니다. 이러한 기록 체계는 앞서 소개한 적응 기능을 더 확장할 때 적용하려는 설계 원칙입니다.

자동매핑의 예라면 어떤 원본 필드를 골랐는지, 어떤 변환을 적용했는지, 어떤 데이터는 처리하지 못했는지가 남아야 합니다. 변경이 있었다면 바꾸기 전후의 결과와 검증에 사용한 조건을 확인할 수 있어야 합니다. ‘분석 성공’이라는 상태와 최종 보고서만 저장해서는 메모리 사용률이 왜 0으로 계산되었는지 추적하기 어렵습니다.

변경이 다음 실행에 영향을 준다면 버전과 적용 범위도 필요합니다. 특정 서버에서 확인한 매핑을 모든 서버에 적용할지, 특정 고객에서만 유지할지 판단할 수 있어야 하고, 문제가 생기면 앞선 상태로 되돌릴 수 있어야 합니다. 검증 기준을 변경 후보에 맞춰 느슨하게 바꾸는 것으로 성공을 만들지 않도록, 기능을 고치는 과정과 올바름을 판정하는 과정도 구분해야 합니다.

이 기록은 외부와 내부의 역량 차이를 연결하는 데에도 쓰입니다. 내부에서 해결하기 어려운 문제가 생기면, 현장에서 반출이 허용되는 자료를 정리해 필요한 승인 절차를 거쳐 외부의 지원을 받을 수 있습니다. 외부에 전달할 수 있는 재현 예제와 오류 설명을 만들고, 외부의 에이전트와 개발자가 수정 후보를 만드는 것입니다.

외부에서 만든 수정은 다시 내부의 실제 조건에서 확인해야 합니다. 외부가 접근할 수 없는 데이터나 시스템 상태 때문에 재현 예제와 현장의 차이가 남을 수 있기 때문입니다. 외부에서는 후보를 만들고, 현장에서는 적용 가능성과 결과를 확인하는 책임이 이어집니다. 이 과정에서도 반출이 허용되지 않는 원본 자료와 외부에 제공할 수 있는 재현 자료의 범위는 현장의 조건에 따라 정해집니다.

기록을 교정으로 연결하려면 변경을 제안하고, 확인하고, 반영하고, 필요하면 되돌릴 수 있는 절차가 함께 있어야 합니다. 원장과 트레이스는 각 판단에 필요한 근거를 제공합니다. 현장이 달라질 수 있도록 열어둔 만큼, 그 변화의 이유와 결과를 설명할 수 있어야 합니다.

현장 경험의 제품 환류

현장에서 발아한 소프트웨어의 경험이 다시 공통 제품으로 돌아오는 흐름은 진화의 과정과 닮아 있습니다. 현장의 차이로 생겨난 변화 가운데 다음 제품에 남길 것을 선택하기 때문입니다.

현장에서 이루어진 모든 변경이 공통 제품에 들어갈 필요는 없습니다. 특정 고객의 서비스 이름과 경로, 해당 환경에서만 유효한 필드 매핑은 그 현장의 설정으로 남길 수 있습니다. 같은 수집기를 쓰는 여러 고객에게 필요한 변환은 재사용 가능한 어댑터로 만들 수 있습니다. 여러 현장에서 반복된 실패가 공통 구조의 한계를 드러낸다면 제품의 뼈대와 설계 원칙을 수정해야 합니다.

조사 과정에서 효과가 있었던 도구의 사용 순서와 판단 기준은 Skill이나 업무 절차로 남길 수 있습니다. 어떤 결과를 올바르다고 인정했는지, 어떤 실패를 다시 만들어 확인할 수 있는지는 평가 사례와 인수 기준이 됩니다. 이런 자산은 제품 코드의 일부가 되지 않더라도 다음 현장의 작업 품질을 바꿉니다. 설정, 어댑터, 업무 지식, 검증 사례와 공통 제품 개선을 각각 어디에서 관리할지 정해야 환류가 실제로 이루어집니다.

이 선별 과정이 앞서 이야기한 두 종류의 적응을 연결합니다. 제품 내부에서 발견한 새로운 입력이나 실패를 사람과 에이전트가 조사해 개선할 수 있습니다. 반대로 사람이 현장에서 반복해 수행하던 조정 중 규칙이 분명해진 부분을 제품 내부의 적응 기능으로 옮길 수도 있습니다. 현장 작업에서 배우고, 그중 반복 가능한 부분을 제품이 담당하게 만드는 흐름입니다.

환류되는 것은 완성된 수정 코드만이 아닙니다. 어떤 조건에서 문제가 발생했는지 보여주는 재현 예제, 잘못된 후보를 배제한 이유, 다음 변경에서도 지켜야 할 시험이 함께 돌아와야 합니다. 그래야 다음 현장에 가져가는 씨앗이 이전의 경험을 품을 수 있습니다.

Anthropic의 코드 현대화 수행 지침도 완성된 코드와 함께 작업 흐름, 완료 기준과 검증 근거를 재사용할 자산으로 남기도록 권합니다. 다음 씨앗에 담아야 할 것은 수정된 기능과, 그 기능을 만들고 확인한 방법입니다.

씨앗의 씨앗 역시 이 과정에서 달라집니다. 처음에는 현장별 설정으로 충분하다고 생각했던 부분에 공통 인터페이스가 필요하다는 사실을 알게 될 수 있습니다. 모든 고객에게 유용할 것이라 생각한 기능이 실제로는 특정 환경에서만 의미가 있다는 사실도 알게 됩니다. 현장의 경험은 구현뿐 아니라 제품이 책임질 범위를 다시 정하는 근거가 됩니다.

관찰한 차이에 맞춰 변경을 시도하고, 그 결과를 검증해 유효한 것을 선별하고 축적하는 과정이 이 글에서 말하는 진화입니다. 어떤 변화가 효과가 있었는지 확인하고 다음 실행과 배포에 남길 수 있을 때, 현장의 경험이 제품의 능력이 됩니다.

이 변화는 제품의 포지셔닝과 개발 사업의 수행 방식을 함께 바꿉니다. 공급자는 견고한 공통 기능과 현장에서 조정할 수 있는 구조를 함께 제품으로 제시합니다.

FDE와 현장의 에이전트는 그 제품을 실제 업무에 맞게 적용하고, 제품 내부의 적응 기능은 정해진 범위의 차이를 처리합니다. 검증된 현장 경험은 다시 공통 기반으로 돌아와 다음 고객에게 가져갈 씨앗을 바꿉니다.

다음 글에서는 이 관점을 전문 모니터링 제품의 사업 전략에 적용하겠습니다. 범용 에이전트가 사용할 수 있는 제품 접점을 만드는 선택이 고객의 업무에 어떤 가치를 주고, 실행환경의 구축과 현장 경험의 축적이 공급자에게 어떤 사업 기회를 만드는지 살펴보겠습니다.