AI 시대에도 엔지니어가 필요한 이유
누구나 AI로 소프트웨어를 만드는 시대에 엔지니어의 자리는 어디인가. 코드를 더 쓰는 사람이 아니라, AI가 헤매지 않도록 문제 공간을 좁히고 시행착오와 위험을 함께 줄이는 사람에 대한 생각.
이제 누구나 Claude Code나 Codex 같은 도구로 자신에게 필요한 소프트웨어를 직접 만든다. 특히 큰 날개를 단 쪽은 기획자다. 아이디어가 가득한 노트를 몇 권씩 쌓아 두고도 디자이너와 개발자를 거쳐 결과를 기다리던 사람이, 이제는 AI에게 설명하면 몇 분 만에 작동하는 프로토타입을 손에 쥔다. 그것도 프로토타입에 그치지 않는다. 로그인과 권한, 데이터베이스와 결제, 배포와 관리자 기능까지 갖춘 제품을 혼자 만든다. 그래서 회사는 SaaS를 도입하기 전에 먼저 묻기 시작했다. “이 정도라면 우리가 직접 만들 수 있지 않을까?”
그렇다면 구현이 이렇게 흔해진 시대에 엔지니어는 무엇을 하는 사람인가. 앞서 AI는 인프라 위에서 자란다에서, 같은 모델을 써도 결과를 가르는 건 데이터와 피드백 루프와 평가 — 모델 밖의 일이라고 적었다. 그렇다면 남는 질문은 자연스럽게 이어진다. 그 차이를 실제로 만드는 사람은 누구인가.
만드는 것과 이해하는 것은 다르다
기획자가 AI로 만든 제품이 부족하다는 뜻이 아니다. 사용자의 문제와 업무 흐름을 잘 아는 기획자는 오히려 더 쓸모 있는 제품을 만들기도 한다. 갈리는 지점은 완성도가 아니라, 그 제품이 왜 작동하는지 내부 구조를 아는가에 있다.
AI가 만들어 준 시스템은 잘 도는 동안에는 문제가 없어 보인다. 오류가 나도 로그와 코드를 넘기면 대개 해결된다. 문제는 시스템이 커질 때다. 기능이 늘고 데이터가 쌓이고 외부 서비스가 얽히면, 하나의 장애가 수많은 원인과 뒤섞인다. 원인이 코드인지 데이터인지 캐시인지 네트워크인지 인프라인지, 판단 자체가 어려워진다. 구조를 이해하지 못하는 사람은 이때도 AI에 의존하는데, 넘겨야 할 맥락이 오류 메시지 한 줄에서 수천 줄의 로그와 배포 이력과 호출 관계로 불어난다. 맥락이 부족하면 답이 어긋나고, 모든 맥락을 밀어 넣으면 비용과 시간이 치솟는다. 이해 없이 운영하는 조직이 위험에 놓이는 건 그 지점이다.
엔지니어는 탐색 범위를 좁힌다
경험 많은 엔지니어도 모든 로그와 코드를 처음부터 끝까지 읽지는 않는다. 오히려 보지 않아도 되는 것을 빠르게 걷어낸다. 특정 사용자에게만 문제가 생겼다면 전체 배포보다 그 사용자의 데이터 상태를 먼저 의심한다. 요청은 성공했는데 화면 반영이 늦다면 저장 실패보다 캐시나 비동기 처리를 살핀다. 트래픽이 늘어난 뒤 장애가 났다면 단순 코드 오류보다 병목과 자원 고갈을 먼저 검토한다.
이건 답을 많이 안다는 뜻이 아니다. 어떤 가능성을 먼저 버려도 되는지 안다는 뜻이다. AI에게 모든 경우를 탐색시키면 막대한 맥락과 시간이 들지만, 엔지니어는 문제의 구조를 보고 유력한 가설 몇 개만 남긴 뒤 좁혀진 영역에 AI를 투입한다. AI 시대에 엔지니어의 지식이 중요한 이유는 AI보다 코드를 더 많이 써서가 아니다. AI가 헤매지 않도록 문제 공간을 줄일 수 있어서다.
같은 이유로 전문가는 평균에서 벗어나야 할 순간을 알아본다. AI는 자주 등장하고 대체로 안전한, 평균적인 해법을 먼저 내놓는 경향이 있다. 대부분의 상황에서는 그게 장점이다. 하지만 우리가 풀려는 문제가 AI가 충분히 학습하지 못한 사례이거나, 특정 산업·조직에서만 생기는 문제이거나, 기존 기술을 원래와 전혀 다른 방식으로 써야 풀리는 문제일 때는 이야기가 달라진다. 무엇이 중요한 맥락인지 알아보고 그것을 AI에게 건네는 일은 여전히 사람의 몫이다.
그 판단은 도메인마다 다르게 생겼다. 회계 전문가는 회계 업무 안에서 자동화할 지점을 찾고, 물류 담당자는 창고의 흐름에서 병목을 알아보고, 디자이너는 남이 지나치는 사용성 문제를 포착한다. 개발자도 마찬가지로, 기술의 성질과 결합 조건을 알기에 다른 사람에게는 보이지 않는 해법을 떠올린다. 검색 기술을 추천에 응용하거나, Git의 버전 관리 방식을 의사결정 이력에 적용하는 발상은 기술의 이름만 알아서는 나오기 어렵다. 도메인 지식이 풀어야 할 문제를 발견하게 한다면, 기술 지식은 이전에는 보이지 않던 해법을 발견하게 한다.
전문성은 토큰만 아끼는 게 아니다
AI 시대에 개발자의 지식은 API 사용량을 줄이는 지식만이 아니다. 잘못된 질문을 줄이고, 불필요한 탐색을 줄이고, 잘못된 설계와 반복되는 재구현을 줄인다. 장애가 나면 원인의 범위를 빠르게 좁히고, 터지기 전에 위험을 알아본다. 그러니 이 지식이 아끼는 건 토큰만이 아니다. 시간과 비용, 시행착오와 위험, 그리고 조직이 소비하는 인지 자원을 함께 아낀다.
이 절약은 대개 눈에 잘 띄지 않는 자리에서 일어난다. “좋아진 것 같다”는 AI 품질에서 가장 미끄러운 문장인데, 그 감각을 측정으로 바꾸는 장치가 없으면 개선은 어느새 기분의 영역으로 흘러간다. 유창한 답이 곧 맞는 답도 아니어서, 판단을 검증 가능한 사실에 묶는 규율이 없으면 그럴듯한 허구를 운에 맡기게 된다. 우리가 자체 제품을 매일 운영하며 되풀이해 확인한 것도, 이런 장치들이 화려하지 않아도 없으면 나머지가 모래 위에 선다는 사실이었다.
구현이 자동화된 다음
AI는 직군 사이의 장벽을 낮추고 있다. 기획자는 직접 소프트웨어를 만들고, 디자이너는 직접 인터랙션을 구현하고, 개발자는 기획과 디자인을 넘나든다. 하지만 경계가 흐려진다고 각 분야의 전문지식까지 옅어지는 건 아니다. 오히려 구현 비용이 낮아질수록, 무엇을 만들고 무엇을 만들지 말아야 하는지, 어떤 해법이 위험한지, 언제 기존의 방법에서 벗어나야 하는지를 판단하는 능력이 더 무거워진다.
누구나 AI로 소프트웨어를 만들 수 있다. 그러나 자신이 만든 것을 끝까지 이해하는 일은 여전히 누구에게나 주어지지 않는다. 구현이 자동화된 다음, 엔지니어의 자리는 코드를 대신 쓰는 데 있지 않다. 시스템이 왜 작동하는지 이해하고, 문제가 생기기 전에 위험을 알아보고, AI가 탐색할 범위를 좁히는 데 있다. 구현이 흔해질수록 그 자리는 사라지기는커녕 오히려 더 또렷해지는 듯하다.