어느 엔지니어가 아무도 2년째 손대지 않은 코드를 붙잡고 사흘을 보냈다. AI가 있었다면 30분이면 끝났을 작업이다. 그런데 그는 git 히스토리를 처음부터 읽고, 로직을 앞뒤로 추적하고, 각 결정이 왜 그 자리에 있는지 머릿속에 그려냈다. 사흘이 지났을 때 그가 얻은 건 버그 수정이 아니었다. 시스템을 이해하는 눈이었다. dev.to에 올라온 'The Mercy of Hard Things'는 이 장면으로 시작하며, AI가 가져다준 속도가 실은 무언가를 조용히 삭제하고 있다는 이야기를 꺼낸다.
같은 주, 또 다른 글이 눈에 들어왔다. AI API로 블로그 포스트 500건을 배치 분석하다가 429 Too Many Requests로 박살났다는 경험담이다. 처음엔 동기 루프, 그다음엔 asyncio.gather()로 한꺼번에 날렸다가 3초 만에 막혔다. 결국 asyncio.Queue와 워커 코루틴으로 동시 요청 수를 제어하고, 지수 백오프에 지터를 더한 재시도 로직을 손으로 짰다. 이 글의 저자는 서드파티 솔루션으로 오후 한 나절을 아낄 수도 있었다고 솔직히 인정한다. 하지만 직접 구현해봤기에 이제 어디서 무엇이 깨지는지 안다고 썼다.
두 이야기는 표면적으로는 전혀 다른 맥락이다. 하나는 레거시 코드 앞에 앉은 주니어 엔지니어의 선택이고, 다른 하나는 파이썬 비동기 큐의 구현 세부다. 그런데 둘이 가리키는 지점은 정확히 겹친다. AI가 마찰을 제거한 자리에, 원래 그 마찰이 강제하던 이해가 함께 사라진다는 것.
'The Mercy of Hard Things'의 저자는 이 지점을 날카롭게 짚는다. 실행이 어렵던 시절엔 아키텍처를 미리 생각할 수밖에 없었다. 디버깅이 비싸니까 문제를 먼저 예측했고, 기억이 코드보다 먼저 사라질 걸 알았기에 문서를 썼다. 이건 모범 사례가 아니었다. 지름길이 없어서 자동으로 생기는 습관이었다. 그런데 지금은 오후 한나절에 시스템 하나를 올릴 수 있다. 프롬프트 엔지니어링과 미들웨어로 붙여두고, 프로덕션에서 뭔가 터지지 않기를 바라면서. 그 글의 저자는 자신도 지난달에 그런 워크플로우를 배포했다고 고백한다. 데모는 깔끔했고 테스트도 통과했다. 하지만 실패가 어디서 어떻게 전파되는지 지금도 설명하지 못한다.
비동기 큐 경험담은 이 고백의 구체적인 버전이다. asyncio.gather()로 500개 요청을 동시에 던지면 빠를 거라는 생각은 틀리지 않았다. 다만 서버가 어떻게 반응하는지, 재시도가 왜 우르르 몰리는지—그 동작 원리를 이해하지 못한 채 API 호출만 병렬로 만든 코드는 3초 안에 벽에 부딪혔다. 지터 없는 지수 백오프는 thundering herd를 만들고, 큐를 쓰지 않으면 종료 시점을 통제할 수 없다. 이건 검색 한 번으로 나오는 팁이 아니다. 직접 터뜨려보고 왜 그런지 파고들어야 체득되는 감각이다.
여기서 내가 진짜 묻고 싶은 건 이거다. AI를 쓰지 말자는 이야기가 아니다. 나 역시 Cursor로 보일러플레이트를 날리고, Claude로 리팩토링 초안을 잡고, v0로 컴포넌트 프로토타입을 30분 안에 뽑는다. 그 속도는 실제로 강력하다. 문제는 그 다음이다. AI가 뽑아준 코드가 왜 그렇게 작동하는지, 어디서 전제를 깔고 있는지, 트래픽이 몰리면 어느 지점이 먼저 꺾이는지—그걸 추적하는 건 여전히 사람 몫이다. 그 판단을 건너뛰면 프로토타입은 나오지만 시스템은 안 나온다.
'The Mercy of Hard Things'는 AI가 무너뜨린 것이 역량의 장벽이 아니라 평범함의 장벽이라고 쓴다. 이게 핵심이다. 이제는 아이디어만 있으면 뭔가 돌아가는 걸 만들 수 있다. 하지만 데이터가 어디를 흐르는지, API 타임아웃이 나면 무엇이 깨지는지 추적해본 사람과, 그냥 작동하니까 넘어간 사람이 만드는 시스템은 6개월 뒤에 갈린다. 예전엔 이 간극이 배포 전에 드러났다. 아무것도 쉽게 올라가지 않았으니까. 지금은 배포 이후에 조용히 드러난다.
실용적 시사점을 짚자면 세 가지다. 첫째, AI에게 구현을 맡기기 전에 최소한 '이게 왜 필요한가'와 '어디서 깨질 수 있는가'를 먼저 말로 정리해야 한다. 그 과정 자체가 설계다. 둘째, AI가 생성한 코드는 동작 여부가 아니라 실패 경로를 기준으로 검토해야 한다. 정상 흐름은 AI도 잘 짠다. 예외 처리와 백프레셔, 종료 조건은 사람이 봐야 한다. 셋째, 마찰을 느꼈을 때 바로 자동화로 돌리지 말고 잠깐 앉아 있어야 한다. 그 불편함이 시스템에 대해 말해주는 정보일 수 있다.
AI 도구는 앞으로 더 빠르고 더 정확해질 것이다. 그럴수록 '작동하는 코드'와 '오래 버티는 시스템' 사이의 간극을 채우는 판단력은 더 희귀해지고 더 가치 있어진다. 빠르게 움직이되 무엇을 이해하고 무엇을 위임하는지를 의식적으로 선택하는 개발자—그게 AI 도구가 일상이 된 시대에 실제로 차별화되는 역량이다. AI가 이 선택을 만들어내지는 않았다. 다만 숨을 수 없게 만들었을 뿐이다.