AX, 제대로 하고 있는 게 맞나요 — 아티클 읽고 생각 정리
요즘 개발 업계에 있다 보면 AX니 바이브코딩이니 하는 단어가 하루에도 수십 번씩 눈에 들어온다.
슬랙에도, 뉴스레터에도, 유튜브 알고리즘에도. 그런데 이상하게 콘텐츠를 읽으면 읽을수록 뭔가 핀트가 어긋난 느낌이 계속 들었다. 오늘 읽은 아티클이 그 감각을 정확히 언어화해줬다.
감에 의존하지 않고 AX 하는 방법 — 바이브마피아클럽 뉴스레터에서 발행된 글이다. 분량은 짧지만 밀도가 높았다.
글이 짚는 세 가지 오해
첫 번째는 AX를 업무 자동화로 보는 시각이다. 자동화하기 쉬워 보이는 것부터 손대는 건데, 글쓴이는 그게 목표 설정부터 틀렸다고 말한다. 자동화 자체가 목표가 아니라 생산성 혁신이 목표여야 하고, 그러려면 실제 병목이 어딘지를 먼저 알아야 한다. 병목이 어딘지 모르겠으면 AI부터 들이미는 게 아니라 데이터 측정을 먼저 해야 한다고.
두 번째는 클로드코드 교육을 AX로 착각하는 경우다. Skill과 하네스를 사내에 뿌리면 뭔가 된 것 같은 기분이 드는데, 시스템은 만드는 게 끝이 아니라 전파하고 유지하는 게 훨씬 어렵다는 게 요지다. 직원 전체가 바이브코더가 되는 게 좋은 미래냐는 물음은 꽤 날카로웠다. 아무도 책임지지 않는 코드가 쌓이고 버려지는 그림이 눈에 그려졌다.
세 번째는 실무진 AI 역량 강화를 AX라고 보는 관점이다. 실무진이 각자 AI를 붙이면, 조직 전체로 봤을 때 각자 조각을 최적화하는 데 그친다. 진짜 병목은 전체 프로세스를 위에서 내려다볼 수 있어야 보이는데, 그건 리더십 레벨의 일이라는 거다.
올바른 순서는 이렇다. 데이터 수집 파이프라인을 먼저 만들고, 그 데이터로 병목을 찾고, 찾은 병목에만 AI를 붙인 뒤 모니터링하면서 개선한다.
가장 마음에 걸린 문장
"측정할 수 없다면 개선할 수 없다"
개발 바닥에서 워낙 자주 쓰이는 말이라 처음엔 스쳐 지나갔는데, AX 맥락에서 다시 읽으니 좀 달리 들렸다. 자동화를 열심히 했다는 것 자체가 뭔가 나아졌다는 근거가 되지 않는다. 측정하지 않으면 잘 된 건지 아닌지 그냥 모르는 거다.
개발 쪽에도 똑같은 패턴이 있다.
성능이 느리다고 할 때, 프로파일링 없이 느낌으로 리팩토링부터 들어가는 경우가 있다. 코드는 분명 깔끔해지는데, 실제로 빠르게 된 건지 아무도 모른다. 측정을 안 했으니까. 장애 대응도 비슷하다. 로그가 없으면 어디서 터진 건지 찍어서 고치게 되고, 같은 문제가 다시 나온다.
그래서 글쓴이가 "재밌는 클로드코드 교육 말고 지루한 데이터 수집에 집중하라"고 한 게 와닿았다. 화려하지 않지만, 그게 실제로 작동하는 방식이다.
관심 있으면 읽어볼 만한 글이다. 분량도 짧다.
