함께 일하는 상대가 사람이 아니면 무엇이 달라질까

앞선 병목은 매번 나였다에서는 내가 직접 하던 전달과 검증을 여러 에이전트에게 나눠 맡긴 과정을 썼다.

여러 AI 에이전트를 각각 별도의 대화에서 일하게 하고 있다. 이 대화 단위를 세션이라고 부른다. 처음에는 각 에이전트가 알아낸 내용을 조율을 맡은 리드 세션에 전달하게 했다. 리드는 그 내용을 받아 다른 에이전트에게 다시 전했다. 직접 물어보면 끝날 일까지 리드를 거치는 모습을 보고, 실무자 세션끼리 이야기하도록 방식을 바꿨다.

리드 세션을 보니 작은 개발팀을 이끌던 시절의 내가 떠올랐다. 나를 거치지 않아도 되는 일에 관여하고, 설명해서 맡기기 어렵다는 이유로 직접 처리하다가 바빠지던 때가 있었다. 지금은 에이전트에게 일을 맡기면서 그때와 비슷한 고민을 한다. 일을 맡기고 보고받는 모습은 닮았지만, 함께 일하는 상대가 바뀌면 무엇이 달라질까.

일을 맡기는 어려움은 닮았다

사람에게든 에이전트에게든 내가 원하는 일을 맡기려면 목적과 제약을 설명해야 한다. 나는 내가 이미 아는 내용은 빼고 모르는 부분을 듣고 싶지만, 상대는 내가 어디까지 아는지 처음부터 알 수 없다. 서로 이해가 어긋났다면 진행 중에 확인하고 바로잡아야 한다. 뒤늦게 결과를 보고 나서야 다르게 이해했다는 사실을 알면 다시 해야 할 일이 많아진다.

팀원에게 내가 생각한 방향을 제대로 전하지 못해 원하지 않는 결과를 받은 적이 있었다. 위임하기 어려운 일은 직접 처리했고, 그러는 동안 내 업무는 늘고 팀원들은 다음 일을 기다렸다. 바빠진 만큼 내 결과물의 품질도 떨어졌다. 에이전트에게 맡긴 일이 기대와 다르게 진행될 때도, 처음에 무엇을 어떻게 설명했는지 돌아보게 됐다.

보고받는 방식도 비슷하다. 동료가 조사한 자료를 처음부터 모두 읽지는 않는다. 정리된 설명을 듣고 이해되지 않는 부분을 묻는다. 에이전트에게도 내가 이미 아는 설명은 빼고, 지금 내 판단이 필요한 내용과 일을 막고 있는 것만 짧게 알려 달라고 한다. 보고가 짧아도 왜 그런 판단을 했는지 이해할 수 없다면 다시 물어야 한다.

한때는 에이전트에게 할 일을 하나하나 적어 주고, 에이전트가 만든 긴 계획서도 처음부터 끝까지 읽었다. 지금은 일을 작게 나누고 자주 묻는다. 어디까지 진행했는지, 내 결정이 필요한지, 일을 계속하려면 어떤 정보가 필요한지를 확인한다. 결과를 볼 때도 코드의 모든 줄을 같은 비중으로 읽기보다, 맡긴 목적을 해결했는지와 기존 동작이나 보안에 문제가 없는지를 살핀다.

피드백을 받을 상대는 다르다

팀원에게 실수를 지적하거나 업무 방식을 개선해 달라고 요청하는 일도 어려웠다. 사람은 한 번의 요청으로 습관을 바꾸기 어렵다. 내가 바꿔 달라고 했다고 따를 의무도 없고, 내 피드백이 잘못됐을 수도 있다. 당시에는 상대의 생각을 듣고 조율하는 데 익숙하지 않아 필요한 말을 충분히 하지 못할 때가 있었다. 무엇을 바꿔야 하는지 알려주지 않은 채 상대가 개선하기를 기대했던 것은 아닌지 돌아보게 된다.

에이전트에게는 개선할 점을 더 직접적으로 말할 수 있었다. 같은 요구가 반복되면 다음 작업에서도 참고할 지침에 적거나 작업 도구를 바꾼다. 에이전트가 실제로 달라졌는지는 확인해야 하지만, 피드백을 반영할 방법을 내가 직접 수정할 수 있다.

그런데 하나의 지침을 여러 세션에 적용하면 내가 잘못 정한 기준도 여러 작업에서 반복될 수 있다. 내 의견이 틀렸는데 에이전트가 그대로 따르면 작업도 잘못된 방향으로 진행된다. 그래서 다른 의견이 있다면 말하고 판단의 근거를 확인하도록 지침을 조정했다. 에이전트가 내 말에 수긍했다는 사실만으로 내 판단이 맞았다고 볼 수는 없다.

규칙으로 맡길 범위를 정한다

행동을 바꾸도록 요청하는 것에 더해, 어떤 행동은 내 확인 없이는 실행되지 않도록 조건을 정했다. 사람 조직에서도 맡긴 일의 범위를 합의하고, 검토 절차나 시스템 권한으로 실행을 제한한다. 에이전트와 일하면서는 내가 사용하는 도구에도 이런 제한을 직접 반영해 맡길 범위를 구체적으로 정했다.

Git으로 관리하는 코드 변경은 잘못되면 되돌려 다시 작업할 수 있으므로 비교적 쉽게 맡긴다. 공개 저장소에 작업 환경이나 개인정보가 올라가는 일은 그렇게 되돌리기 어렵다. 그래서 공개 저장소에 코드 변경 요청을 올리는 명령은 내 허락을 먼저 받도록 해 두었다. 데이터베이스도 조회는 맡기되, 내가 만든 조회용 도구에서 변경 명령을 제한한다. 결과를 보고 고칠 수 있는 일과 실행 전에 확인해야 하는 일을 작업 환경에서도 구분한 것이다.

이 장치들이 모든 실수를 막아 준다고 생각하지는 않는다. 다만 어디까지는 결과를 검토하고, 어디부터는 실행 전에 확인해야 하는지를 요청과 도구에 함께 반영할 수 있었다.

지금 내린 결론

리드 세션을 거치던 대화를 실무자끼리 하도록 바꾼 일은, 예전에 팀을 이끌며 고민했던 위임과 닮았다. 하지만 이번에는 대화 방식을 정하는 지침과 도구까지 내가 직접 바꿀 수 있었다. 그렇게 만든 규칙이 일을 돕는지, 오히려 잘못된 판단을 반복하게 만드는지도 내가 확인해야 했다.

내가 느낀 가장 큰 차이는 상대의 행동을 바꿀 수 있는 범위와 그에 따른 책임이다. 사람 동료와는 서로의 판단을 존중하며 일하는 방식을 만들어 간다. 에이전트 조직에서는 내가 만든 작업 환경이 여러 세션의 행동에 직접 영향을 준다. 일을 맡기는 모습이 닮았다고 해서 같은 방식으로 조율할 수 있는 것은 아니다. 에이전트에게 더 많은 일을 맡길수록, 내가 정한 기준을 스스로 의심하고 검토하는 일도 중요해진다.

아직 맡기지 못한 일이 있다면 무엇이 망설여지는가.