AX = AI eXperience

“AI”와 “경험”이라는 두 단어지만 이걸 받아들이는 사람들의 정의는 각각인 것 같다. 정의 차이는 A와 X 가운데 어느 곳에 힘을 주느냐에서 나온다. A를 강조하는 쪽은 AI를 쓰는 것에 우선하는 반면에 X는 일상의 경험이 바뀌는 것을 우선한다.

AI를 쓰면 일상이 바뀔거라는 생각은 지나친 낙관주의다. 세상의 모든 시선이 AI에 집중되다보니 쓰면 바뀌고 가치가 올라간다는 착시 현상이다. 정작 무엇이 바뀌었는지 냉정히 따져보면 바뀐 건 AI를 쓴다는 것 밖에는 없는 것 같다.

개발 세상에서 AI가 바꾼 걸 가혹하게 말하면 IDE와 단축키를 대체했다는 것 아닐까? 이제는 Claude Code나 Codex가 없으면 개발을 못하는 지경이 됐으니 말이다. 그렇다고 개발 속도가 급속도로 빨라지지도 않았다. 물론 코드가 작성되는 속도는 비약적으로 빨라졌지만 정작 사용자를 위해 제대로, 장애없이 실행되는 지점에 도착하는데 걸리는 시간은 이전 IDE로 코드를 짜던 때와 대비해 극적 향상을 만들지는 못했다.

AI 무용론을 이야기하는 것이 아니다. AI는 분명 혁신적인 물건이다. 다만 혁신은 단순히 쓴다고 해서 만들어지는 것이 아니다. 우리 일상에서 혁신을 어떻게 대입할지를 고민해야 AI가 기여한 일상의 찐 혁신을 이룰 수 있다. 인터넷과 스마트폰이 불러온 혁신을 혁신이라 부르는 이유는 이것들이 없는  일상을 생각할 수 없기 때문이다. 세상을 바꿀 것 같았이 등장했던 세그웨이가 한때의 유명세가 되버린 것과 대비된다. AI를 통해 일상의 변화를 만들기 위해서는 먼저 우리는 어떤 일을 어떻게 하고 있는지를 스스로 관찰해야 한다. 관찰을 통해 AI로 변화할 수 있는 지점, 구간이 어딘지 찾아야 한다. 물론 이걸 위해서는 AI를 경험하고 이해해야 한다. AI Literacy가 필요한 이유다. 기본인  Literacy 이외에 실제 변화를 위해서는 당연히 토큰비를 포함한 투자가 필요하다. 변화의 정당성은 효과가 투자 비용을 상쇄할 때 입증된다.

다시 개발 세상으로 돌아가보자. SDLC(Software Development Life Cycle) 관점을 간단히 요약하면 “요구사항(Requirement) – 개발(Coding) – 검증(Functional Test)- 배포(Deploy) – 운영(Operation)” 이라는 흐름으로 동작한다. 그리고 흐름을 구성하는 개별 요소는 전단계 요소의 결과에 따라 필연적으로 “대기 시간”이 발생한다. 명확하지 않은 요구 사항으로 아키텍처가 뒤바뀐 경험을 한 아키텍트는 온전한 요구 사항이 수립될 때가지 기다린다. 한 줄 요구 사항에 혼쭐난 개발자는 완벽한 명세가 기입된 Jira Ticket이 오기 전까지는 Business Logic을 구현하고 싶지 않다. 결국 이런 대기 시간이 합쳐서 비효율을 만들고, 앞단의 대기 시간은 뒤쪽으로 흐를수록 스노볼 효과를 만들게 마련이다. 개발에 Claude나 Codex를 쓴다고 해서 전체 개발 시간이나 Performance 개선이 이뤄지지 않는 이유가 여기에 있다.

결국에는 흐름(flow)를 혁신해야 찐 AI 효과를 볼 수 있다. 기존 흐름이 만드는 가치를 AI를 이용한 흐름으로 재설계해야 혁신의 결과를 기대할 수 있다. 그리고 재설계의 핵심은 흐름에 필연적으로 존재하는 대기 시간에 있다. 사람 중심 흐름에 존재하는 대기시간을 AI 중심에서 없애거나 최소화되야 한다. 사람이 아닌 기계의 속도는 실행 시간을 극단으로 줄일 수 있다는 것이 오히려 대기 시간으로 역효과를 만들 수 있다. 단순히 사람 중심의 기존 흐름에 AI를 끼워넣으면 대기 시간이 만드는 병목 현상이 흐르는 관을 부풀려 터트릴 수도 있다. 쓸 수 있다고 해서 썼다가는 거덜날 수 있다.