AI가 내 기술을 고르게 하려면, 무엇부터 보여 줘야 할까?

AI에게 앱을 만들라고 했는데 코드가 돌아간다. 그럼 내 기술을 잘 쓴 것일까? 이제 막 개발을 배우는 사람에게도 중요한 질문이다. 실행 결과만 보고 넘어가면 오래된 인증 방식이나 다른 제품을 택한 이유가 가려진다. AI가 무엇을 골랐는지 읽는 일이 작업의 일부가 됐다.

10월9일 Microsoft 개발자 블로그는 에이전트 경험, AX를 평가하는 플레이북을 소개했다. SDK와 API, 문서와 도구를 만드는 사람을 위한 방법이다. 모델의 일반 순위를 매기는 대신 자신이 제공한 기술을 에이전트가 실제로 발견하고 바르게 쓰는지 묻는다.

차이는 판단할 대상을 먼저 정하는 데 있다. 가령 특정 API를 이용하는 작은 서비스를 가정해 보자. 화면이 열리는 것, 원하는 API를 호출하는 것, 실패를 처리하는 것은 별개의 조건이다. 첫 조건만 통과한 작품을 나머지 조건까지 확인한 성공으로 기록할 수 없다.

작성자는 실행됐다는 증거와 내용의 적절성을 평가하는 조건을 나누도록 설명한다. 이 구분을 따르면 점수표가 그럴듯해도 실제 동작이 없었던 작업을 걸러 낼 수 있다. 다만 SOCRA가 이 방법의 효과나 모든 에이전트의 성능을 독립 실험으로 확인한 것은 아니다.

오류를 고치는 순서도 바뀐다. 확장이 아예 불러와지지 않은 경우, 불러왔지만 호출하지 않은 경우, 호출하고도 잘못 적용한 경우를 나눠 본다. 셋을 모두 모델이 멍청했다는 말로 묶으면 문서나 연결 설정처럼 내가 바꿀 수 있는 부분을 놓치기 쉽다.

여기서 문서는 참고용 설명을 넘어 작업의 입력이 된다. 예제의 버전과 인증 방식, 실패 처리의 안내가 실제 선택에 영향을 줄 수 있다는 이야기다. 문장을 많이 쓰는 능력보다 필요한 조건을 찾아 쓸 수 있게 정리하는 능력을 연습할 이유가 생긴다.

포트폴리오에서도 이 관점을 써 볼 수 있다. 가상의 결제 조회 과제를 정하고 정상 응답과 만료된 인증, 비어 있는 결과를 따로 확인한다. 어떤 조건에서 실패했고 무엇을 바꿨는지 남기면 완성 화면 한 장보다 의사결정을 설명할 재료가 많아진다.

수정 뒤 점수가 올랐다고 바로 인과를 단정할 필요는 없다. 같은 과제와 같은 조건으로 비교해야 변경의 역할을 읽을 수 있다. 요청을 새롭게 바꾸거나 평가 기준까지 함께 바꾸면 무엇이 개선을 만들었는지 구분하기 어려워진다는 것이 SOCRA의 해석이다.

이번 발표는 문서와 에이전트 도구를 다루는 업무의 질문을 보여 준다. 새로운 자격증이나 채용 증가를 확인해 주는 자료는 아니다. 어떤 회사에서 이 역량을 요구하는지, 내 분야의 제품에 적용할 수 있는지는 실제 공고와 프로젝트에서 더 확인해야 한다.

배울 대상을 모델 이름에서 한 걸음 옮겨 보자. 내 기술을 제대로 썼다는 말의 의미를 정하고, 실행 기록에서 그 조건을 찾는 연습이다. 에이전트가 일을 맡는 범위가 넓어져도 무엇을 성공으로 볼지 설명하는 능력은 사람이 다음 작업으로 가져갈 수 있다.