어제 일본 회사에 다니는 지인에게 연락을 받았습니다. 회사 사장의 요청으로 빠르게 결과물을 만들어야 했고, 개발자가 아닌 지인이 AI를 활용해 개발을 진행했다고 합니다. 화면과 기능은 대부분 만들어졌습니다. 체감상 90% 정도는 완성된 상태였다고 해요.
문제는 남은 10%였습니다. 특정 버그를 고치면 다른 기능에서 오류가 발생하고, 새로 나타난 오류 메시지를 AI에 전달하면 코드가 또 크게 바뀌는 식이었습니다. 그러다 보니 원래 해결하려던 문제와 점점 멀어지는 상황이 됐습니다. 흔히 말하는 ‘거의 다 됐는데 끝나지 않는’ 개발 지옥에 들어간 것이죠.
지인에게는 오류 메시지만 AI에 반복해서 전달하지 말라고 이야기했습니다. 에러 문구는 결과일 뿐, 원인이 아닐 수 있기 때문입니다. 실제 코드를 확인해 수정했고, 이번 일을 계기로 AI로 개발하더라도 왜 개발자가 필요한지 이야기해볼 필요가 있겠다고 생각했습니다.
90%까지는 빠른데, 마지막 10%가 어려운 이유
AI를 이용하면 홈페이지 화면, 간단한 관리자 기능, 데이터 입력 화면처럼 형태가 비교적 분명한 작업은 매우 빠르게 만들 수 있습니다. 원하는 기능을 말로 설명하고, 생성된 코드를 붙여 넣고, 눈에 보이는 결과를 확인하는 과정도 생각보다 수월합니다.
그래서 초기에는 “개발자를 거치지 않아도 되겠는데?”라는 생각이 들기 쉽습니다. 실제로 아이디어를 시제품으로 확인하는 단계라면 AI만으로도 충분히 의미 있는 결과가 나옵니다. 내부에서 써볼 간단한 도구나, 사업 가능성을 검토하기 위한 화면이라면 더욱 그렇습니다.
하지만 서비스가 실제 업무 흐름을 처리하기 시작하면 이야기가 달라집니다. 회원 정보가 저장되고, 권한에 따라 화면이 달라지고, 결제나 예약, 재고, 외부 서비스 연동이 붙는 순간부터는 기능들이 서로 영향을 줍니다.
예를 들어 로그인 오류가 보인다고 해서 로그인 부분만 고치면 되는 것이 아닐 수 있습니다. 회원 정보 저장 방식, 세션 유지 방식, 권한 확인 로직, 데이터베이스 연결 문제 중 하나가 원인일 수 있습니다. 화면에 나타난 오류 한 줄만 보고 코드를 바꾸면, 당장은 메시지가 사라져도 다른 기능이 망가질 가능성이 있습니다.
오류 메시지를 계속 넣으면 왜 문제가 커질까
AI에게 오류 메시지를 주고 “고쳐줘”라고 요청하는 방식 자체가 잘못된 것은 아닙니다. 작은 문법 오류나 누락된 설정처럼 원인이 명확한 문제라면 상당히 빠르게 해결됩니다. 문제는 AI가 제시한 수정안을 충분히 검토하지 않은 채 계속 적용하는 경우입니다.
AI는 대화에서 받은 정보와 현재 보이는 코드 기준으로 그럴듯한 해결책을 만듭니다. 그런데 프로젝트 전체 구조, 이전에 왜 그렇게 만들었는지, 실제 사용 환경에서 어떤 조건이 있는지까지 자동으로 정확히 이해하는 것은 아닙니다. 특히 여러 번 수정된 코드에서는 이미 들어간 임시 처리나 충돌하는 설정을 놓치기 쉽습니다.
이 상태에서 오류가 날 때마다 AI가 제안한 코드를 통째로 바꾸면, 하나의 문제를 고치기 위해 다른 부분의 약속을 깨게 됩니다. 함수 이름은 바뀌었는데 호출하는 곳은 그대로 남거나, 데이터 형식은 바뀌었는데 기존 화면은 예전 형식을 기대하는 식입니다. 수정 횟수가 늘어날수록 코드의 일관성은 떨어집니다.
지인이 겪은 상황도 비슷했습니다. AI가 일을 못 해서라기보다, 문제를 진단하는 과정 없이 처방만 반복한 것이 더 큰 원인이었습니다. 열이 난다고 해열제만 계속 바꾸는 것과 비슷합니다. 열이 왜 나는지 확인하지 않으면 잠시 괜찮아 보여도 문제가 끝나지 않습니다.
개발자는 코드를 치는 사람만은 아닙니다
기업에서 개발자를 찾을 때 흔히 “기능을 만들어줄 사람”을 떠올립니다. 물론 구현도 중요한 일입니다. 다만 AI 개발 환경에서는 개발자의 역할이 오히려 조금 달라집니다. AI가 빠르게 만든 결과물을 검토하고, 문제가 생겼을 때 원인을 좁히고, 앞으로 고쳐도 무너지지 않는 구조인지 판단하는 사람이 필요합니다.
개발자는 오류가 난 위치와 실제 원인을 구분합니다. 어떤 변경이 다른 기능에 영향을 주는지 살피고, 지금 급하게 막을 문제인지 구조를 다시 잡아야 할 문제인지 결정합니다. 기능 요청이 들어왔을 때도 무조건 코드부터 추가하지 않습니다. 기존 데이터와 충돌하지 않는지, 운영자가 관리할 수 있는 방식인지부터 보는 편이 낫습니다.
무엇보다 운영되는 시스템에는 책임질 주체가 있어야 합니다. AI는 코드를 생성하고 수정안을 제시할 수 있지만, 장애가 났을 때 고객 정보가 안전한지, 결제 데이터가 꼬이지 않는지, 수정 후 서비스가 정상인지 판단하고 책임지지는 않습니다. 그 판단은 결국 사람의 몫입니다.
AI 개발에서 현실적으로 나누면 좋은 역할
AI를 쓰지 말자는 이야기는 아닙니다. 저는 AI를 마법의 지팡이보다는 굉장한 속도를 가진 도구라고 봅니다. 반복적인 화면 구성, 기본 코드 작성, 문서 정리, 아이디어를 빠르게 구현하는 일에서는 개발 시간을 크게 줄여줍니다. 개발자 역시 이런 작업에 AI를 쓰면 훨씬 빠르게 움직일 수 있습니다.
다만 AI에게 맡길 일과 사람이 확인할 일을 나누는 편이 좋습니다. 초기 화면이나 기능 시안은 AI를 적극 활용해도 됩니다. 반면 회원 정보, 권한, 결제, 개인정보, 외부 시스템 연동처럼 한번 잘못되면 운영 문제가 생기는 영역은 개발자가 구조를 확인해야 합니다.
버그가 반복되기 시작했다면 새 오류 메시지를 계속 입력하기 전에 잠시 멈추는 편이 낫습니다. 직전에 무엇을 바꿨는지, 오류가 처음 발생한 시점이 언제인지, 어떤 조건에서만 재현되는지부터 확인해야 합니다. 수정 전 코드를 남겨두는 것도 중요합니다. 그래야 AI의 제안이 문제를 해결했는지, 단지 다른 문제를 가렸는지 비교할 수 있습니다.
개발자를 언제 투입해야 할까
모든 작업에 처음부터 개발자가 상주해야 하는 것은 아닙니다. 사내에서 잠깐 사용할 계산기나 단순한 소개 페이지라면 AI로 직접 만들어보는 선택도 괜찮습니다. 요구사항을 정리하는 데도 도움이 됩니다.
다만 기능 하나를 고칠 때마다 다른 곳이 깨지고, 같은 오류가 다른 형태로 반복되며, 코드가 왜 그렇게 바뀌었는지 아무도 설명할 수 없는 상태라면 개발자 검토가 필요한 시점입니다. 이때는 기능을 하나 더 만드는 것보다 현재 구조를 정리하는 일이 우선일 수 있습니다.
AI로 만든 결과물을 개발자에게 보여주는 일도 전혀 헛된 과정이 아닙니다. 오히려 막연하게 “이런 시스템이 필요하다”고 말하는 것보다 원하는 화면과 흐름이 보이기 때문에, 필요한 개발 범위와 비용을 더 현실적으로 논의할 수 있습니다.
AI가 많은 일을 대신해주는 것은 맞습니다. 하지만 빠르게 만든 코드가 실제 업무에서 계속 돌아가게 하려면, 원인을 판단하고 수정의 책임을 질 사람이 필요합니다. AI 개발이 막히는 지점은 대개 프롬프트를 한 번 더 잘 쓰는 문제가 아니라, 이제 누가 구조를 보고 결정할 것인가의 문제입니다.
