최근에 나는 AI에게 블로그 글을 다듬는 데 도움을 요청했다.
그것은 빠르게 썼다. 구조는 완성되어 있었고 아이디어는 명확했다. 더 전문적으로 들리게 하고 싶다고 말하자 기술적인 논의를 추가했다. 학술적 뒷받침을 요청하자 최근 논문들을 찾아냈다.
글은 점점 더 진지해졌지만, 나는 망설이기 시작했다: 정말 이렇게 쓰여야 하는 걸까?
내용에 딱히 잘못된 것은 없었다. 하지만 내가 쓰고 싶었던 것은 내 목소리가 담긴 글, 독자들이 내가 한 문제를 어떻게 고민했는지 볼 수 있게 하는 글이었다. 몇 차례 수정을 거치면서 그것은 점차 내 스스로도 소화하는 데 시간이 필요한 연구 리뷰가 되어가고 있었다.
나의 기대도 그 과정에서 변하고 있었다. 처음에는 이 특정 글에서 '전문적'이라거나 '심층적'이라는 것이 무엇을 의미해야 하는지 충분히 정리하지 못한 상태였다.
그 경험은 좋은 에이전트란 무엇인지 다시 생각하게 만들었다.
요구 사항을 하나하나 점검해 보면 우리의 협업은 꽤 많은 것을 해냈다: 글이 쓰였고, 조사가 이루어졌고, 참고 문헌이 갖춰졌다. 개별 요청 하나하나에는 대응하는 결과물이 있었다.
하지만 그것들을 종합해 보면, 나는 여전히 물어야 했다: 이것이 내가 발행하고 싶은 글인가?
에이전트가 무엇을 했는지 확인하는 것은 쉽다. 그 행동들이 사용자를 목표에 더 가깝게 옮겼는지 설명하는 데는 더 많은 작업이 필요하다.
이 경우 '학술적 뒷받침 추가'는 명시적인 요청이었다. 그 목적은 논거를 더 설득력 있게 만드는 것이었다. 연구를 추가함으로써 글이 본래의 목소리를 잃게 되었다면, 우리는 그 자료를 어떻게 활용할지 다시 고려해야 했다.
사용자의 새로운 요청이 항상 단순히 덧붙여야 할 것만은 아니다. 그것은 방향의 수정일 수도 있고, 이미 완료된 작업을 제거해야 할 이유일 수도 있다.
과제에 계속 관여하는 에이전트에게 이러한 변화를 이해하는 것은 전체 협업의 질에 영향을 미친다. 피드백이 들어올 때마다 결과물에 계속 무언가를 더하기보다는 과제에 대한 이해를 수정해 나가야 한다.
이는 '완료'를 더 복잡하게 만든다. 글에는 결말이 있고 과제는 완료로 표시될 수 있지만, 사용자는 여전히 쓸 수 있는 무언가를 갖지 못할 수 있다.
그래서 평가를 설계하기 전에, 나는 다른 것을 먼저 분명히 하고 싶다: 우리는 결과로부터 어떤 판단을 내리려 하는가?
사실 정확성을 점검한다는 것은 인용과 뒷받침 증거를 검증하는 것을 의미한다. 수정 능력을 평가한다는 것은 에이전트가 피드백을 이해하고 여전히 유효한 내용을 보존하는지 관찰하는 것을 의미한다. 과제를 처음부터 끝까지 수행할 수 있는지 판단한다는 것은 사용자에게 얼마나 많은 작업을 남기는지도 살펴보는 것을 의미한다.
이 질문들은 서로 관련되어 있지만, '전반적인 품질이 좋다'는 것으로는 이 모든 질문에 답하기 어렵다.
우리가 무엇을 평가하는지 분명해질 때에야 어떤 증거를 수집해야 하는지, 그리고 점수가 우리에게 얼마나 많은 것을 알려줄 수 있는지 알 수 있다.
평가는 당시의 상황에 대해서도 공정해야 한다.
이 글쓰기 과정에서 일부 목표는 논의를 통해서만 분명해졌다. 초기의 응답은 나중에 드러난 선호가 아니라 이미 표현되었던 요구에 비추어 판단되어야 한다.
요구 사항이 이미 명확했는데도 결과가 여전히 적합하지 않았다면, 우리는 문제를 더 정확히 파악해야 한다. 에이전트가 오해했는가? 이전의 제약을 잊었는가? 아니면 새로운 요청을 충족시키느라 이미 잘 작동하던 것을 무너뜨렸는가?
이 모든 것이 '글을 못 썼다'고 표현될 수 있지만, 그것들은 매우 다른 개선을 요구한다. 더 많은 과제 정보를 제공하는 것, 맥락을 조정하는 것, 또는 실행 방식을 바꾸는 것이 각각 도움이 될 수 있다. 그러나 먼저 우리는 어디서 잘못되었는지 알아야 한다.
다른 요구 사항들은 개인적 선호에 따라 변해서는 안 된다. 인용이 실제인지, 사실이 정확한지, 결론이 뒷받침되는지는 독립적으로 점검되어야 한다. 사용자가 결과를 좋아한다는 것만으로는 이러한 요구 사항이 충족되었다고 확립하기에 충분하지 않다.
나는 이 구분이 중요하다고 생각한다. 그것은 평가가 특정한 요구를 반영하면서도 필요한 판단 기준을 유지할 수 있게 해준다.
목표가 명확하고 에이전트가 이번에는 제대로 해냈더라도, 여전히 관찰할 것이 더 있다.
같은 과제를 두 번째에도 잘 해낼 수 있는가? 사용자가 요청을 다르게 표현하면 의도를 잘못 읽을 것인가? 정보가 없을 때 유창한 문장으로 빈틈을 메우는 대신 불확실성을 인정할 수 있는가?
에이전트 신뢰성에 관한 한 연구는 일관성, 견고성, 예측 가능성, 안전성을 각각 따로 살펴보았다. 그것이 테스트한 모델과 벤치마크 전반에서 능력의 향상은 신뢰성의 제한적인 개선만을 가져왔다. 이는 에이전트가 무엇을 성취할 수 있는지 배운 후에도, 우리가 어떤 조건에서 그것에 의존할 수 있는지 여전히 이해해야 한다는 것을 상기시켜 준다. 관련 연구
그렇다면 누가 좋은 에이전트를 정의하는가?
나는 사용자의 실제 목적이 출발점이 되어야 한다고 믿는다. 제품 팀은 어떤 요구를 해결하려는지, 그리고 얼마나 많은 책임을 질 것인지 분명히 해야 한다. 엔지니어링은 구현과 시스템 역량의 한계를 이해해야 한다. 평가는 그러한 기대를 구체적인 상황에 적용하고 결과가 그것을 입증하는지 시험한다.
누군가는 최종적인 절충에 대해 책임을 져야 하고, 그것을 논의할 근거가 있어야 한다.
무언가를 '더 전문적으로' 만들어 달라는 요청을 생각해 보자. 한 사람은 용어와 참고 문헌을 떠올린다. 또 다른 사람은 더 엄밀한 추론을 떠올린다. 또 다른 누군가는 저자가 문제의 핵심을 정확히 짚어내기를 기대한다. 우리가 그 요청을 실제 글에 적용해 보면, 우리 모두가 같은 것을 이야기하고 있지 않다는 점을 더 쉽게 알 수 있다.
나는 이런 사례들을 통해 합의를 만들어 가는 편이 낫다. 어떤 사실이 반드시 정확해야 하는가? 어떤 부분이 결과의 사용 가능 여부에 영향을 미치는가? 어디에 서로 다른 선택의 여지가 있는가? 이 모든 것은 논의될 수 있다. 우리의 기준이 더 구체적일수록, 나중에 의견 차이를 설명할 가능성이 더 높아진다.
그 기준은 수정에도 열려 있어야 한다. 새로운 상황은 우리가 고려하지 못한 문제를 드러낼 수 있고, 사용자들은 다른 것을 요구하기 시작할 수 있다. 중요한 것은 우리가 조정을 한 이유를 기록하여, 팀이 제품의 개선과 판단 방식의 변화를 구분할 수 있게 하는 것이다.
평가의 가치는 이후 우리가 내리는 선택에서도 드러나야 한다.
평가를 통해 무엇을 우선시해야 하는지 더 분명해지고, 어떤 개선에 투자할 가치가 있는지 설명할 수 있으며, 증거가 불충분할 때 어떤 추가 테스트가 필요한지 알게 된다면, 그 점수는 실질적인 가치를 지닌다.
돌이켜 보면, AI는 내가 글을 더 완성도 있게 만드는 데 도움을 주었다. 우리가 무엇을 남기고 무엇을 뺄 수 있을지 정리하는 데 도움을 준 것은 이후의 논의들이었다.
그것이 또한 내가 평가가 팀에 도움이 되기를 바라는 바이기도 하다: 결과가 이미 좋아 보일 때에도, 그것이 사용자의 손에 들어갈 준비가 되었는지, 그리고 우리가 그 판단에 왜 확신을 가질 수 있는지 판단할 방법을 여전히 갖는 것.