AI로 백엔드 개발해도 바퀴를 다시 만드는 이유
AI가 CRUD와 SQL을 대신 작성해도 권한·워크플로·감사 로그 등 기업 백엔드의 반복 작업이 여전히 큰 비중을 차지한다는 지적이다.
중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.
많은 사람이 이미 AI에게 코드를 작성하게 하는 데 익숙해졌다. CRUD 인터페이스 하나를 생성하고, SQL 한 조각을 보완하고, 유틸리티 클래스 하나를 작성하는 일은 확실히 직접 타이핑하는 것보다 효율이 높다.
하지만 실제 기업 백오피스 프로젝트에 적용해 보면, 속도가 그렇게 빨라지지 않았다는 것을 알게 된다. AI가 인터페이스 작성을 끝내도, 이어서 여전히 권한, 메뉴, 워크플로, 리포트, 감사 로그, 데이터 딕셔너리를 처리해야 한다. 이 코드들은 복잡하지 않지만 프로젝트 시간의 절반 이상을 차지하며, 게다가 매 프로젝트마다 처음부터 다시 해야 한다.
문제는 모델에 있는 것이 아니라 출발점에 있다.
1. 익숙한 장면
"고객 관리" 모듈을 만든다고 가정해 보자. 요구사항은 명확하다. 목록, 상세, 추가, 편집, 가져오기, 내보내기, 그리고 역할에 따라 서로 다른 데이터를 보는 것이다.
처음부터 시작한다면, AI는 테이블 하나와 인터페이스 하나를 금방 만들어 준다. 하지만 이어서 이런 문제들을 연달아 마주하게 된다.
권한을 메뉴와 버튼에 어떻게 연결할 것인가?
데이터 범위를 부서별로 어떻게 격리할 것인가?
작업 로그는 누가 기록하는가?
가져오기 실패는 어떻게 프런트엔드에 피드백하는가?
리포트는 어떻게 기존 시스템과 데이터 소스를 공유하는가?
각 문제는 어렵지 않지만, 각각을 다 작성해야 한다. 더 번거로운 점은 이들이 서로 연관되어 있다는 것이다. 권한을 한 군데 바꾸면 메뉴, 인터페이스, 프런트엔드를 동시에 바꿔야 할 수도 있다. AI는 매번 네가 준 그 한 부분의 컨텍스트만 볼 수 있어서, 이런 가로 관계들을 스스로 채우기가 어렵다.
그래서 흔히 나타나는 결과는 이렇다. AI가 생성한 코드는 "돌아가지만", 기존 시스템에 연결할 수 없다.
2. "제로에서 생성"의 세 가지 숨은 비용
1. 기반 시설의 반복 구축
권한, 조직, 사용자, 역할, 딕셔너리, 로그는 백오피스 시스템의 공통 부분이다. 이들은 구체적인 업무와 무관하지만, 모든 프로젝트에 반드시 존재해야 한다.
제로에서 생성한다는 것은 매번 테이블 구조를 다시 설계하고, 인터셉트 로직을 다시 작성하고, 프런트엔드를 다시 조정해야 한다는 뜻이다. AI는 개별 파일을 가속할 수 있지만, 이런 모듈을 넘나드는 일관성 작업은 가속하지 못한다.
2. 불완전한 컨텍스트
AI는 국부적 생성에 능하지만, 일련의 암묵적 제약 전체를 유지하는 데는 능하지 않다. 예를 들어 "편집 권한이 있는 사람만 내보내기 버튼을 볼 수 있다"는 규칙은 백엔드 인터페이스, 프런트엔드 라우팅, 메뉴 설정에 동시에 존재할 수 있다.
너가 그중 파일 하나만 AI에게 보내면, AI는 가장 직접적인 방식으로 구현하고, 나머지 두 곳은 네가 직접 발견해서 채워 넣어야 한다.
3. 통제 불가능한 산출물
제로에서 생성한 프로젝트는 품질이 프롬프트와 모델 상태에 크게 의존한다. 같은 요구사항이라도 오늘 생성된 구조와 다음 주에 생성된 구조가 다를 수 있다. 팀이 이를 유지하려면, 먼저 역사도 없고 약속도 없는 코드 한 세트를 읽고 이해해야 한다.
3. 출발점을 바꾸자: AI가 성숙한 백엔드 위에 서게 하기
기반 시설을 매번 다시 작성해야 한다면, 다시 작성하지 않을 수는 없을까?
GewuMind Boot의 사고방식은 이렇다. 먼저 기업 백오피스에 필요한 기반을 잘 만들어 두고, 그다음 AI가 이 기반 위에서 업무를 작성하게 한다.
이것은 45개의 시스템 테이블을 내장하고 있으며, 사용자, 조직, 역할, 권한, 메뉴, 딕셔너리, 로그, 워크플로, 리포트 등 흔한 기능을 포괄한다. AI가 요구사항을 받으면 테이블 생성부터 시작할 필요 없이, 이런 기능들을 그대로 재사용하고 정력을 업무 필드와 업무 규칙에 쏟는다.
두 방식의 차이는 "AI가 얼마나 빨리 작성하는가"가 아니라 "AI가 어디서부터 작성을 시작하는가"이다.
제로에서 생성: 요구사항 -> 테이블 설계 -> 권한 작성 -> 인터페이스 작성 -> 프런트엔드 작성 -> 통합 테스트.
기반 기반: 요구사항 -> 업무 테이블 -> 업무 인터페이스 -> 권한과 메뉴 재사용 -> 통합 테스트.
중간의 가장 오류가 나기 쉽고 가장 반복적인 작업들이 기반에 흡수된다.
4. 30분 만에 모듈 하나 전달하기, 구체적으로 어떤 모습인가
권한이 딸린 관리 모듈을 예로 들면, 흐름은 대략 이렇다.
1. 업무 요구사항 설명, 필드와 역할 명확화
2. 업무 테이블 DDL 생성
3. 백엔드 인터페이스 스크립트 생성
4. 페이지 컴포넌트 생성
5. 메뉴 연결, 권한 설정
6. 발행 및 검증
하위 계층 기능이 이미 존재하기 때문에, 3단계부터 5단계는 다시 발명할 필요가 없다. AI가 출력하는 것은 "기반에 접속하는" 코드이지, "별도의 세트를 새로 만드는" 코드가 아니다.
이것이 또한 Cursor, Claude Code 같은 도구와 가장 본질적인 차이다. 그 도구들은 너가 코드를 더 빨리 작성하도록 돕고, GewuMind Boot는 너가 코드 한 세트 전체를 덜 작성하도록 돕는다.
5. 어떤 팀이 이런 방식에 적합한가
팀 규모가 크지 않아 백오피스 기반 시설 한 세트를 유지할 정력이 없는 경우
프로젝트가 프라이빗 배포를 필요로 하고, 데이터를 제3자에게 맡길 수 없는 경우
요구사항 변화가 빨라 매번 반복할 때마다 빠르게 전달하고 싶은 경우
이미 AI 코딩 도구가 있지만 생성 결과를 기존 시스템에 연결하지 못해 고민인 경우
프로젝트에 간단한 인터페이스 하나만 있다면, 제로에서 생성하는 것으로 충분하다. 하지만 백오피스, 권한, 다중 역할 협업이 관련된다면, 출발점이 효율의 상한을 결정한다.
6. 마지막으로
AI는 "바퀴를 다시 발명하는" 일을 사라지게 하지 않는다. 단지 바퀴를 다시 발명하는 일을 더 빠르게 만들 뿐이다. 방향이 틀렸다면, 더 빠르게 바퀴를 다시 발명하는 것은 더 빠르게 반복하는 것일 뿐이다.
진정으로 투자할 가치가 있는 것은, AI가 성숙하고 유지보수 가능한 백엔드 기반 위에 서게 하여, 시간을 업무 그 자체에 쓰는 것이다.