9. AI 개발과 제품 개선

한 고객을 위해 만든 기능이 다른 고객에게도 필요해지는 순간이 있다. 첫 프로젝트에서는 특수한 문서 권한 때문에 만든 처리였는데, 다음 고객도 비슷한 문제를 겪는다. 엔지니어는 코드를 복사해 빨리 해결할 수도 있고, 공통 기능으로 만들자고 제안할 수도 있다. 어느 쪽을 선택하느냐에 따라 이후의 개발 비용과 제품 구조가 달라진다.

FDE가 고객의 문제를 제품팀에 전달한다는 말은 이 과정 전체를 가리킬 수 있다. 문제를 보고하는 것에서 끝날 수도 있고, 공통 설계와 구현에 직접 참여할 수도 있다. 중요한 것은 현장에서 얻은 경험이 다른 개발자가 판단할 수 있는 형태로 남는가 하는 점이다.

실패 원인 분석

AI 기능이 기대대로 작동하지 않으면 고객은 흔히 “답변이 틀린다”고 말한다. 그러나 같은 표현 안에 서로 다른 원인이 있다. 필요한 문서가 검색되지 않았을 수 있고, 오래된 문서를 참고했을 수 있으며, 모델이 근거를 잘못 해석했을 수도 있다. 답변은 맞지만 사용자가 볼 수 없는 자료를 사용한 경우도 있다.

이 차이를 구분하지 않은 채 모델 성능 문제로 보고하면 해결 방향을 정하기 어렵다. FDE는 실제 입력, 사용자의 권한, 참고한 자료, 나온 결과와 기대한 행동을 함께 정리할 수 있다. 고객의 업무를 알고 구현에도 접근할 수 있다는 점이 이 조사에 도움이 된다.

고객의 기대 자체를 다시 확인해야 할 때도 있다. 자료가 부족한 상황에서 답변을 보류하는 것이 올바른 동작인데 사용자는 항상 답을 원할 수 있다. 어떤 실패를 피해야 하는지에 대한 합의가 없다면 같은 출력을 보고 엔지니어와 고객이 다른 평가를 내리게 된다.

업무 평가

앞 장의 가상 문서 검토 시스템에서 정확한 조항을 찾는 것만으로 충분하지 않았던 이유는 사용자가 근거를 확인해야 했기 때문이다. 시스템은 문서 이름뿐 아니라 해당 위치와 적용 시점을 보여줄 필요가 있다. 이 요구는 모델의 정답률만 측정해서는 잘 드러나지 않는다.

평가 사례에는 정상적인 질문 외에 문서가 없는 질문, 개정 전후 규정이 함께 있는 질문, 권한이 다른 사용자의 질문도 포함될 수 있다. 이런 사례를 통해 어떤 부분이 모델의 행동이고 어떤 부분이 애플리케이션의 책임인지 드러난다. 실제 업무의 실패를 설명하는 평가가 제품 개발의 자료가 되는 것이다.

Anthropic의 FDE 공고도 운영 환경에서 쓸 기술 산출물과 LLM 평가 경험을 함께 언급한다. 특정 기술의 사용 여부보다 구현과 평가를 이어서 수행한다는 점이 이 역할을 이해하는 데 중요하다. 공식 공고

공통 기능 설계

첫 고객의 권한 구조에 맞춘 코드는 그 고객의 부서 체계와 예외 규칙을 포함할 수 있다. 다른 고객이 비슷한 요청을 했다고 같은 코드를 바로 적용할 수 있는 것은 아니다. 공통으로 처리할 부분과 고객마다 달라질 부분을 분리해야 한다.

예를 들어 문서에 접근할 수 있는지 확인하는 절차는 공통으로 만들 수 있지만, 접근 허용 여부를 판단하는 규칙은 고객의 시스템에 남겨야 할 수 있다. 이 경우 공통 제품은 권한 확인을 요청할 인터페이스를 제공하고, 고객별 구현은 기존 권한 시스템과 연결한다. 고객마다 다른 규칙을 제품 본체에 계속 추가하는 부담을 줄일 수 있다.

이런 설계는 초기 납품보다 시간이 더 걸린다. 인터페이스를 정의하고, 다른 조건에서도 동작하는지 시험하고, 오류와 변경의 책임을 정해야 한다. 따라서 공통화는 남는 시간에 할 정리 작업이 아니라 별도의 개발 결정이다.

개선 제안

“고객이 원한다”는 요청에는 우선순위를 정하기 위한 정보가 부족하다. 어떤 사용자가 어떤 업무에서 막히는지, 현재의 우회 방법은 무엇인지, 구현으로 얼마나 해결했는지 알아야 한다. 같은 원인이 다른 고객에게도 나타나는지까지 알면 공통 기능으로 다룰 이유가 더 분명해진다.

FDE의 역할은 현장의 모든 요구를 제품 로드맵으로 밀어 넣는 데 있지 않다. 공통 기능으로 만들 가치가 있는 문제와 고객별로 남겨야 할 요구를 함께 드러내는 데 있다. 제품팀이 요청을 수용하지 않더라도 그 판단의 이유가 기록되면 다음 프로젝트에서 같은 논의를 처음부터 반복할 필요가 줄어든다.

코드와 도구 관리

어디에 남기든 유지할 사람이 필요하다. 복사해 사용할 수 있는 코드가 생겼다는 사실과 조직이 그 코드를 지원할 수 있다는 사실은 다르다. 고객 자료와 계약상 제한이 있는 코드는 재사용 가능한 설계 경험과도 구분해야 한다.

핵심 요약

현장 경험이 제품 개선으로 이어지려면 실패 원인과 업무 맥락이 함께 전달되어야 한다. 그 경험을 고객별 구현, 공통 도구, 제품 기능 중 어디에 반영할지는 반복되는 요구와 유지 비용을 보고 판단한다. 공통화 이후의 책임까지 정해졌을 때 한 프로젝트의 개발이 다음 프로젝트의 기반이 된다.