요즘 기술 업계의 대화는 마치 '생성형 AI가 코드를 얼마나 잘 짜느냐'라는 단일 축을 중심으로 돌아가는 것 같다.
마치 개발자의 가치가 코드를 얼마나 많이, 얼마나 빠르게 뱉어내느냐에 비례하는 것처럼 말이다.
하지만 이번에 전개된 흐름을 자세히 들여다보면, 이 논의의 초점이 근본적으로 잘못 설정되어 있다는 느낌을 지울 수 없다.
모두가 AI의 '코드 생성' 능력에 열광하지만, 실제 이 기술이 겨냥하는 지점은 훨씬 더 지저분하고, 복잡하며, 인간의 개입이 필수적이었던 '개발 수명 주기(SDLC) 전체의 마찰 지점'이다.
Harness가 자신들의 AI 어시스턴트 AIDA를 내세우며 강조하는 지점은 바로 이 지점이다.
그들은 마치 "우리가 코딩 자체를 대체하려는 게 아니다"라고 방어하는 것처럼 들리지만, 실질적으로는 코딩이라는 가장 눈에 띄는 부분에서 시선을 돌려, 빌드 실패의 원인 추적, 보안 취약점의 자동 패치, 심지어 클라우드 비용 최적화 같은, 그동안 '숙련된 엔지니어의 경험과 시간이 필요한 영역'들을 AI의 영역으로 끌어들이고 있다.
이 접근 방식은 흥미롭지만, 동시에 우리가 놓치고 있는 근본적인 질문을 던진다.
과연 이 모든 '프로세스 최적화'가 정말로 개발자 생산성 향상이라는 거대한 명분 아래, 결국은 플랫폼 종속성이라는 새로운 형태의 족쇄를 채우려는 시도는 아닌가?
모두가 '효율성'이라는 단어에 현혹되어, 이 복잡한 과정의 주도권을 플랫폼 공급자에게 넘겨주는 건 아닌지, 비판적인 시각으로 바라볼 필요가 있다.
특히 주목해야 할 부분은 AI가 해결책을 제시하는 방식이다.
단순히 "여기가 문제야"라고 지적하는 수준을 넘어, "이런 원인으로 인해 A 시스템과 B 시스템 간의 연쇄적인 실패가 발생했고, 이 해결책 C를 적용하면 돼"라고 구체적인 해결책과 함께 제시한다는 점이다.
이는 개발자가 마주하는 가장 고통스러운 순간, 즉 수많은 상호작용(AWS, Kubernetes, Secrets Manager 등) 중 어디서부터 문제가 터져 나왔는지 추적해야 하는 '디버깅의 지옥'을 직접적으로 겨냥한다.
이 과정에서 AI가 제시하는 해결책을 개발자가 최종적으로 '판단'하고 '적용'해야 한다는 인간의 통제권 유지는, 이 기술이 '대체'가 아닌 '지원'임을 강조하는 가장 강력한 방패막이다.
하지만 이 '인간의 통제'라는 문구 자체가 또 하나의 논쟁거리가 된다.
AI가 제시하는 수많은 옵션과 해결책들 앞에서, 개발자는 오히려 '어떤 해결책이 가장 근본적인 해결책인지'를 판단하는 데 더 많은 인지 부하를 겪을 수 있다.
게다가 보안 취약점 자동 수정이나 비용 절감 기회 포착 같은 기능들은, 결국 기업이 가진 인프라의 구조적 결함이나 운영상의 비효율성을 AI가 '발견'해준다는 의미다.
이는 개발자 개인의 역량 문제라기보다, 조직 전체의 거버넌스나 아키텍처 설계 단계에서부터 해결되어야 할 구조적 문제들을, 마치 'AI 툴을 잘 쓰지 못해서' 발생한 것처럼 보이게 만들 위험을 내포하고 있다.
이 기술의 진정한 가치는 코드를 짜는 속도 향상이 아니라, 복잡하게 얽힌 운영 과정의 '불확실성'과 '추적의 어려움'을 플랫폼 레벨에서 구조적으로 관리하려는 시도에 있다.