2026년 10월 6일, OpenAI와 Atlassian이 파트너십 확대를 발표했다. 두 회사는 Jira 업무를 사람에게 하듯 AI 에이전트에게 배정하고, 진행과 결과를 추적하는 연동을 검토 중이라고 밝혔다. 아직 출시된 기능이 아니다.
그래도 이 방향이 현실이 되면 먼저 떠오르는 질문이 있다. 담당자 칸에 에이전트가 들어오면, 그 결과물은 누가 어떤 속도로 읽는가.
이 글은 그 질문을 이미 겪고 있는 작은 규모의 이야기다. 결론부터 적으면 승인 버튼이 있다는 사실과 승인이 일어난다는 사실은 다르다. 그리고 그 차이는 AI가 빨라질수록 벌어진다.
1. 요구사항 1건이 산출물 N개가 된다
BATON을 만들면서 반복해서 겪는 장면이 있다.
요구사항 하나를 고쳐 달라고 요청한다. 변경 의도는 한 줄이다. 그런데 AI는 이 요구사항과 영향 관계에 있는 산출물을 전부 수정해서 돌려준다.
- 유스케이스
- 기능
- 데이터
- 시퀀스
AI의 판단은 대체로 합리적이다. 요구사항이 바뀌면 그에 딸린 문서도 바뀌어야 한다. 사람이 했다면 며칠 걸렸을 일을 AI는 한 번에 끝낸다.
문제는 그다음이다. 적용 버튼 앞에 서면 읽어야 할 것이 한 줄이 아니라 수십 군데다. 하나씩 읽어 보려 하지만 다 읽기 전에 지친다. 결국 제대로 읽지 않고 적용을 누르게 된다.
아직 이것 때문에 사고가 난 적은 없다. 다만 읽지 않았다는 사실이 불안하다. 지금까지 괜찮았던 이유가 AI가 정확해서인지, 내가 놓친 것이 아직 드러나지 않아서인지 구분할 수 없기 때문이다.
2. 비용이 비례하는 대상이 틀어져 있다
사람이 직접 고칠 때는 수정 범위가 곧 노력이었다. 많이 고치려면 그만큼 오래 걸렸고, 고치는 과정에서 읽게 됐다. 쓰는 일이 읽는 일을 겸했다.
AI는 이 둘을 분리한다.
| 항목 | 사람이 직접 | AI에게 맡길 때 |
|---|---|---|
| 변경 의도 | 한 줄 | 한 줄 |
| 변경 범위 | 손이 닿은 만큼 | 영향 있는 곳 전부 |
| 만드는 비용 | 범위에 비례 | 거의 일정 |
| 읽는 비용 | 만드는 과정에 포함 | 범위에 비례, 전부 별도 |
만드는 비용은 사실상 사라졌는데 읽는 비용은 그대로다. 게다가 읽는 비용은 의도의 크기가 아니라 영향 범위의 크기를 따라간다. 요구사항 한 줄이 작아도 연결된 곳이 많으면 검토 비용은 커진다.
그래서 이 문제는 내 성실성이나 AI의 정확도 문제가 아니다. 구조가 그렇다. 만드는 쪽의 속도가 올라갈수록 읽는 쪽은 상대적으로 더 느려진다.
생성 속도가 올라가면 승인은 판단이 아니라 통과 의례가 된다.
3. 기준은 이미 있었다
이 지점에서 이렇게 반문할 수 있다. 이슈 작성, 리뷰, 배포 기준을 정해 두면 되지 않느냐고.
기준은 이미 정해 두었다. 이슈를 어떻게 쓰고, 무엇을 리뷰하고, 어떤 상태가 되어야 배포하는지 표준화했다. 어려운 것은 기준을 만드는 일이 아니라 지키는 일이다. 생성 속도가 너무 빠르다 보니 지킬 틈이 없다.
앞선 글에서 게이트가 있고, 자리가 맞고, 실제로 작동하는지 확인하라고 적었다. 그리고 승인 요청이 많아지면 사람은 내용을 보지 않고 승인을 누르니 게이트는 되돌릴 수 없는 지점에만 두라고 적었다.
이번에 겪은 것은 그 문장의 반대편이다. 게이트를 한 곳에만 두어도, 그 한 곳에 도착한 변경의 양이 너무 크면 같은 일이 벌어진다. 앞선 글이 통제 지점이 있는가를 물었다면, 이 글이 묻는 것은 그 지점이 작동 가능한가다.
앞선 글의 네 번째 질문은 “판단의 근거가 그 시점에 실제로 존재하는가”였다. 여기에 하나가 더 붙어야 한다.
그 근거를, 그 시간 안에, 사람이 읽을 수 있는가.
4. 에이전트가 담당자가 되면
Jira 담당자 칸에 에이전트가 들어오는 장면으로 돌아가 보자.
지금 BATON에서는 내가 요구하고 AI가 수정하며 한 번에 하나를 본다. 이슈 트래커에 에이전트가 담당자로 들어오면 이 구조는 이슈 단위로 복제된다. 여러 이슈가 동시에 진행되고, 각각 영향 범위가 따로 있다. 사람이 읽어야 할 양은 이슈 수와 이슈당 영향 범위의 곱으로 커진다.
사람에게 맡긴 일의 결과는 대개 사람의 속도에 맞춰 도착한다. 속도가 같으니 검토도 같은 속도로 따라간다. 에이전트의 결과는 그 속도에 맞춰 오지 않는다.
이슈를 모호하게 쓰면 엉뚱한 결과가 나온다는 이야기는 이미 많이 한다. 맞는 말이지만, 이슈를 완벽하게 써도 남는 문제가 있다. 결과가 맞더라도 맞는지 확인할 사람이 따라가지 못한다.
5. 아직 해 보지 않은 것들
여기서부터는 해법이 아니라 방향이다. 어느 것도 아직 시도하지 않았고, 효과가 있는지 모른다.
읽는 단위를 바꾼다
지금은 변경된 산출물을 문서별로 나열한다. 읽는 사람은 어디서부터 읽어야 하는지, 이 변경이 처음 요청과 어떻게 이어지는지 스스로 추적해야 한다.
대신 요청한 변경 의도 한 줄을 맨 위에 두고, 거기서 파생된 변경을 그 아래로 묶어 보여 주면 어떨까 생각하고 있다. 전부 읽게 하지 않고, 의도와 어긋난 곳을 찾기 쉽게 만드는 것이다. 시각화를 통해 사람의 인지 부담을 줄이는 쪽이다.
읽어야 할 지점에서만 멈춘다
모든 변경에 같은 강도의 승인을 요구하면 승인 피로로 다시 같은 문제가 된다. 그래서 일부 단계에서만 사람의 승인을 강제하고 나머지는 흐르게 두는 쪽을 생각하고 있다.
다만 어떤 변경이 읽어야 할 변경인지 누가 어떻게 구분하는가는 아직 답이 없다. 이 분류가 틀리면 멈춰야 할 곳을 지나치고, 너무 넓으면 지금과 같아진다.
두 방향 모두 위험이 있다
시각화는 잘 만들수록 사람이 화면만 보고 안심하게 만들 수 있다. 승인 강제는 늘릴수록 형식이 된다. 어느 쪽도 읽는 비용 자체를 없애지는 못한다. 줄이거나 옮길 뿐이다.
6. 정리
- 요구사항 1건의 변경 의도는 한 줄인데 AI는 영향 있는 산출물을 전부 수정해 돌려준다.
- 만드는 비용은 거의 사라졌지만 읽는 비용은 영향 범위에 비례해 남는다. 승인은 이 간격에서 의미를 잃는다.
- 기준을 만드는 것은 이미 했다. 어려운 것은 기준을 지킬 시간을 사람이 가질 수 있느냐다.
- 에이전트가 이슈 담당자가 되면 이 구조가 이슈 수만큼 복제된다.
- 시각화와 단계별 승인 강제를 생각하고 있지만 아직 시도 전이다.
솔직히 아직 답은 없다. 다만 에이전트에게 일을 맡기기 전에 하나는 묻고 싶다.
이 결과를 내가 읽을 수 있는 속도로, 읽을 수 있는 양만큼만 받고 있는가.