Building With AI When You Don't Know Architecture: A Survival Guide
Let me describe a moment you might recognize. You had an idea for an app. You didn't know how to...
개요 #
만들고 싶은 앱이 있었다. 제대로 만들 줄은 몰랐지만 AI 챗에 원하는 걸 설명했더니 돌아가는 코드가 나왔다. 실행해보니 진짜로 동작했다. 그래서 기능을 하나 더 붙였고, 또 하나 붙였다. 다섯 번째쯤 되자 여기저기서 깨지기 시작했다. 하나를 고치면 둘이 망가졌다. AI에게 도와달라고 했지만 뭐가 잘못됐는지 설명할 수조차 없었다. 자기 프로젝트인데 자기가 이해하지 못하게 된 것이다.
Dev.to에 올라온 James Anderson의 글은 바로 이 지점을 다룬다. 대부분의 사람이 막히는 곳은 코딩이 아니라 그 벽이라는 것. 그리고 아무도 말해주지 않는 사실 하나를 짚는다. AI는 코드를 쓰는 장벽을 없앴지, 코드를 구조화하는 장벽까지 없앤 게 아니다. 이 둘은 다른 기술이고, 지금 프로젝트의 생사를 가르는 건 두 번째 쪽이다.
전공 학위는 필요 없다. AI가 만든 프로젝트가 스파게티로 변하지 않게 막아주는 습관 몇 가지면 된다.
진짜 문제는 이해 속도가 생성 속도를 못 따라간다는 것 #
해법을 꺼내기 전에 뭐가 잘못되고 있는지부터 짚어야 한다. 초보자들이 짐작하는 것과는 좀 다르다.
문제는 AI가 나쁜 코드를 썼다는 게 아니다. 거의 항상 아니다. 진짜 문제는 앱이 어떻게 지탱되고 있는지 이해하기도 전에 동작하는 앱을 손에 쥐게 된다는 것이다. 조종석이 안 보이는 비행기를 모는 셈이다. 오토파일럿이 버텨주는 동안은 괜찮다. 뭔가 조정이 필요한 순간 길을 잃는다. 애초에 뭐가 어디 있는지 배운 적이 없으니까.
'아키텍처'라는 단어가 겁나게 들릴 수 있지만 실체는 단순하다. 프로젝트의 생김새다. 조각이 뭐뭐 있고, 각각 무슨 일을 하고, 서로 어떻게 연결되는가. 구조가 있어야 프로젝트를 이해할 수 있고, 이해해야 계속 만들어나갈 수 있다.
그래서 이 글의 목표는 하나다. 프로젝트가 커져도 계속 이해할 수 있는 상태를 유지하라. 아래 여섯 가지 습관은 전부 이걸 위한 것이다.
Photo by 생존 기술 1 — 조각을 나눠라 #
여섯 가지 중 가장 중요한 습관이다.
그냥 두면 AI는 전부를 한 파일에 우겨넣는 경향이 있다. 화면을 그리는 부분, 실제 일을 하는 부분, 데이터베이스와 대화하는 부분이 전부 뒤엉킨다. 처음엔 잘 돌아간다. 하지만 모든 게 한자리에 있으면 어떤 변경이든 전부를 깨뜨릴 위험을 안는다. 아무것도 서로 분리돼 있지 않으니까.
해법은 세 종류를 떼어놓는 것이다.
- 사용자가 보는 것 — 인터페이스, 버튼, 레이아웃. 흔히 UI 또는 프론트엔드라고 부른다.
- 앱이 하는 일 — 실제 로직, 규칙, 계산. 비즈니스 로직이다.
- 데이터가 오는 곳 — 데이터베이스나 외부 서비스와의 통신. 데이터 레이어다.
이렇게 분리하면 하는 일을 건드리지 않고 보이는 방식만 바꿀 수 있고, 데이터 통신을 깨뜨리지 않고 하는 일만 바꿀 수 있다. 문제가 번지지 않고 한곳에 머문다.
AI에게 붙여넣을 지시문: "인터페이스, 비즈니스 로직, 데이터 접근을 별도 파일로 분리해줘. 섞지 마."
이 한 문장을 꾸준히 쓰는 것만으로 이 글의 나머지 전부를 합친 것보다 많은 붕괴를 막을 수 있다고 원문은 말한다.
생존 기술 2 — 하나당 한 가지 일 #
머릿속에 담아둘 만큼 단순한 규칙이다. 파일이든 함수든, 한 문장으로 이름 붙일 수 있는 일 하나만 해야 한다.
어떤 파일이 무슨 일을 하는지 설명하려는데 "이것도 하고 저것도 하고 그리고 또 저것도 한다"고 말해야 한다면, 그 파일은 너무 많은 걸 하고 있다. 버그가 숨고 변경이 어긋나는 자리가 된다.
작고 목적이 하나인 조각은 살아남는다. 찾을 수 있고, 이해할 수 있고, 두려움 없이 하나만 고칠 수 있다. 뭐든 다 하는 거대 파일은 늪이다. 담긴 게 많을수록 편집 한 번이 도박이 된다.
AI에게 붙여넣을 지시문: "파일과 함수는 책임이 하나여야 해. 두 가지 이상 하는 건 나눠줘."
생존 기술 3 — 데이터마다 집은 하나 #
초보 프로젝트가 깨지는 1위 원인이라 특히 조심해야 한다.
앱이 커지면 같은 정보가 — 로그인한 사용자든, 장바구니에 담긴 항목이든 — 여러 곳에 복사돼서 각각 추적되는 상황이 생긴다. 그리고 그 사본들이 서로 어긋난다. 앱의 한쪽은 장바구니에 세 개가 있다고 믿고 다른 쪽은 하나라고 믿는다. 앱이 말도 안 되는 방식으로 동작하기 시작하고 디버깅은 거의 불가능해진다.
생존 규칙은 이렇다. 모든 데이터는 정확히 한 곳에만 살고, 나머지는 전부 그 한 곳에서 읽어간다. 단일 진실 공급원(single source of truth)이다. AI가 상태 사본을 프로젝트 여기저기 아무렇지 않게 흩뿌리게 두지 마라.
AI에게 붙여넣을 지시문: "이 데이터는 단일 진실 공급원을 가져야 해. 컴포넌트마다 복제하지 말고 한 곳에서 읽어가게 해줘."
세상에서 가장 사람 미치게 하는 종류의 버그를 막아준다. 기술적으로는 아무것도 안 망가졌는데 아무것도 서로 일치하지 않는 그런 버그다.
생존 기술 4 — 생성하기 전에 형태를 정하라 #
대부분의 초보자는 이렇게 만든다. 기능이 하나 떠오르면 AI에게 요청하고, 반복한다. AI는 매번 구조를 즉흥적으로 만들어내고, 조각들은 끝내 맞물리지 않는다. 어떻게 맞물려야 하는지 아무도 정하지 않았기 때문이다.
판을 바꾸는 전환은 이것이다. 만들기 전에 앱의 조각들에 이름을 붙여라.
코드를 생성하기 전에 주요 조각과 각각의 책임을 적어라. 간단한 앱이라면 로그인, 사용자 프로필, 메인 대시보드, 결제 정도가 될 수 있다. 네 조각, 각자 명확한 역할. 미리 조각과 책임을 파악한 그 목록이 바로 쉬운 말로 옮긴 아키텍처다. 방금 한 게 그거다. 무서울 게 없다.
그다음엔 한 번에 한 조각씩 완성하고 다음으로 넘어간다. 앱 전체를 한 방에 만들어달라고 하지 마라. 이해할 수 없는 덩어리가 나온다. 로그인을 만들고, 동작시키고, 이해한 다음, 그다음 조각으로 간다.
AI에게 붙여넣을 지시문: "내 앱의 주요 컴포넌트와 각각의 역할은 이렇다: [목록]. [X]부터 시작해서 하나씩 만들자."
생존 기술 5 — AI에게 설명을 시켜라 #
만들기를 배우기로 바꾸는 습관이다. 초보자를 구조 아는 사람으로 서서히 바꿔놓는 것도 여기서 시작한다.
AI가 준 코드를 그냥 받아들이고 넘어가지 마라. 이렇게 물어라.
- "왜 이런 구조로 짰어?"
- "각 부분이 무슨 일을 하는지 쉬운 말로 설명해줘."
- "이걸 바꾸면 뭐가 같이 영향받아?"
AI를 자판기가 아니라 개인 교사로 쓰는 것이다. 답변 하나하나가 프로젝트가 어떻게 맞물리는지 조금씩 가르쳐준다. 처음에 없었던 바로 그 지식이다. 이걸 꾸준히 하면 프로젝트를 거듭할수록 코드를 생성하는 사람에서 코드를 이해하는 사람으로 옮겨간다.
AI에게 붙여넣을 지시문: "쓰기 전에 이게 어떻게 구조화됐고 왜 그런지 쉬운 말로 설명해줘. 실행만 하려는 게 아니라 이해하고 싶어."
생존 기술 6 — 지루하고 일관되게 #
짝으로 움직이는 두 습관을 묶었다.
멋진 것보다 지루한 것이 낫다. AI가 매끄럽고 복잡하고 그럴싸해 보이는 해법을 내밀면 더 단순한 방법은 없는지 물어라. 아키텍트가 아닌 사람에게 화려한 버전은 이득이 아니라 부채다. 이해하지 못하는 복잡성은 유지할 수도 고칠 수도 없는 복잡성이다. 다음 달에도 다룰 수 있는 건 단순하고 뻔한 쪽이다.
다양함보다 일관성이 낫다. 기능 A를 한 방식으로 만들고 기능 B를 전혀 다른 방식으로 만들면 — AI 세션이 나뉘면 쉽게 벌어지는 일이다 — 프로젝트는 아무 규칙도 공유하지 않는 누더기가 된다. 새 기능은 기존 기능의 패턴에 맞춰라.
AI에게 붙여넣을 지시문: "제일 영리한 버전 말고 제일 단순하게 돌아가는 버전으로 줘. 그리고 내 프로젝트에 이미 있는 구조와 패턴에 맞춰줘."
늦기 전에 알아채야 할 경고 신호 #
화재경보기라고 생각하면 된다. 아래 중 하나라도 느껴지기 시작하면 기능 추가를 멈추고 구조부터 정리해야 한다.
- 뭐가 깨질지 몰라서 바꾸기가 두렵다.
- 하나 고치면 다른 게 깨지는 일이 반복된다.
- 뭐가 어디 있는지 더 이상 못 찾겠다.
- 파일이 계속 커지고 하는 일도 계속 늘어난다.
- 열어봐도 내 프로젝트가 이해가 안 된다.
이 중 어느 것도 실패를 뜻하지 않는다. 프로젝트가 자기 구조를 넘어서 자랐다는 신호일 뿐이고, 전문가에게도 일어나는 일이다. 차이는 이제 그 느낌이 무슨 뜻인지 알고 무엇을 해야 할지 안다는 것이다. 멈추고, 조각을 나누고, 그 위에 더 쌓기 전에 이해를 되찾는 것.
정리 #
AI로 진짜 소프트웨어를 만드는 데 전공 학위는 필요 없다. 그 장벽은 정말로 사라졌고 돌아오지 않는다.
하지만 "코드를 생성할 수 있다"와 "성장을 견디는 무언가를 만들 수 있다"는 다른 이야기다. 그 사이의 간격이 구조다. AI가 대신 채워줄 수 없는 유일한 부분이기도 하다. 내 프로젝트에 대한 결정, 나만 내릴 수 있는 결정에 달려 있기 때문이다. AI는 코드를 준다. 형태는 사람이 줘야 한다.
다행히 그 형태를 잡는 일은 어렵지 않다. 조각을 나누고, 하나당 한 가지 일을 시키고, 데이터마다 집을 하나만 두고, 생성 전에 계획하고, AI에게 가르치게 하고, 지루하게 유지하는 것. 습관 몇 가지다. 이걸 지키면서 만드는 것을 이해해나가면 생각보다 훨씬 많은 걸 만들 수 있다. 무너지는 걸 지켜보지 않아도 된다.
단순하게 시작하고, 이해할 수 있는 상태를 유지할 것. 그게 생존이다.
원문 말미에는 이 글이 AI의 도움을 받아 작성됐고 게시 전 저자가 검토·편집했다는 고지가 붙어 있다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.