AI로 앱 만들 때, '아키텍처 몰라도' 무너지지 않는 튼튼한 프로젝트 설계 비법

아마 이런 순간을 경험해본 적 있을 겁니다.

번뜩이는 앱 아이디어가 떠올랐죠. 하지만 그걸 어떻게 만들어야 할지는 막막했습니다. 그런데 AI 챗봇을 열고 원하는 것을 설명했더니, 놀랍게도 바로 작동하는 코드를 뱉어냈습니다. 코드를 실행해보니, 진짜로 돌아갔습니다. 한 달 전만 해도 꿈도 못 꿀 일이 내 눈앞에서 펼쳐지니, 그야말로 마법처럼 느껴졌을 겁니다.

그래서 기능을 하나 더 추가했습니다. 그리고 또 하나. 그러다 다섯 번째 기능쯤 추가했을까요? 어딘가에서부터 문제가 터지기 시작합니다. 하나를 고치면 두 개가 망가지고, AI에게 도움을 요청해도 뭘 잘못했는지조차 설명할 수 없습니다. 왜냐하면, 이제는 내 프로젝트인데도 내가 뭘 만들었는지조차 알 수 없게 되어버렸으니까요. 마치 불이 꺼진 방에서 시한폭탄을 해체하는 기분이 들었을 겁니다.

대부분의 사람이 막히는 지점이 바로 이 '벽'입니다. 코딩 자체가 아니라요. 여기서 아무도 말해주지 않는 핵심이 있습니다. AI는 코드를 작성하는 장벽을 없애줬지만, 코드를 구조화하는 장벽은 없애주지 않았다는 겁니다. 이 두 가지는 전혀 다른 기술이고, 이제 후자가 당신이 프로젝트를 계속 빌드할 수 있을지, 아니면 결국 무너지는 걸 지켜볼지 결정하는 중요한 척도가 되었습니다.

이 글은 바로 그 '벽' 앞에서 헤매는 이들을 위한 생존 가이드입니다. 컴퓨터 공학 학위는 필요 없습니다. 그저 AI로 만든 프로젝트가 스파게티처럼 엉키는 걸 막아주는 몇 가지 습관들을, 말 그대로 '맨땅에 헤딩하는' 초보자 눈높이에서 설명해 드릴 겁니다.

진짜 문제는: 이해하는 속도보다 코드를 더 빨리 생성한다는 것

본격적인 '어떻게 할 것인가'를 논하기 전에, 초보자들이 흔히 생각하는 것과 다른 진짜 문제점을 먼저 짚고 넘어갈 필요가 있습니다.

문제는 AI가 '나쁜 코드'를 작성해서 생기는 경우가 거의 없습니다. 진짜 문제는 AI가 당신이 앱이 어떻게 돌아가는지 이해하기도 전에 작동하는 앱을 만들어준다는 겁니다. 마치 조종간을 보지도 못한 채 비행기를 조종하는 것과 같습니다. 자동조종장치가 잘 작동하는 동안에는 문제없지만, 뭔가 조정해야 할 순간이 오면 어디를 손대야 할지 몰라 헤매게 되는 거죠. 왜냐하면, 애초에 아무것도 배우지 못했으니까요.

'아키텍처'라고 하면 왠지 무섭고, 고급스러우며, 컴퓨터 공학 전공자들만의 전유물처럼 들릴 겁니다. 하지만 전혀 그렇지 않습니다. 간단히 말해 아키텍처는 그저 **당신 프로젝트의 '모양'**입니다. 어떤 조각들이 있고, 각 조각이 무슨 역할을 하며, 어떻게 서로 연결되는지에 대한 그림이죠. 그리고 구조는 프로젝트를 이해 가능하게 만드는 핵심입니다. 이해할 수 있어야만 프로젝트가 커지더라도 계속해서 쌓아 올릴 수 있지, 매몰되지 않습니다.

그러니 이 가이드의 목표는 단 하나입니다. 프로젝트가 성장하더라도 당신 스스로 계속 이해할 수 있는 상태를 유지하는 것. 아래 모든 내용은 이 목표를 달성하기 위한 것입니다.

생존 기술 #1: 조각들을 분리하라

이것이 가장 중요한 습관이니, 가장 많은 주의를 기울여 주세요.

AI는 혼자 내버려 두면 모든 것을 하나의 거대한 파일에 쑤셔 넣으려는 경향이 있습니다. 화면을 그리는 부분, 실제 작업을 수행하는 부분, 데이터베이스와 통신하는 부분까지 모든 것이 한데 뒤섞여 있죠. 처음엔 잘 작동할 겁니다. 하지만 모든 것이 한곳에 모여 있으면, 무엇이든 바뀌면 모든 것이 망가질 위험이 있습니다. 왜냐하면, 어떤 것도 다른 것과 분리되어 있지 않기 때문이죠.

해결책은 세 가지 종류의 것을 분리하는 겁니다:

사용자가 보는 것 — 인터페이스, 버튼, 레이아웃 (흔히 "UI" 또는 "프론트엔드"라고 부릅니다).
앱이 하는 일 — 실제 로직, 규칙, 계산 (흔히 "비즈니스 로직"이라고 부릅니다).
데이터가 어디서 오는지 — 데이터베이스나 외부 서비스와 통신하는 부분 (흔히 "데이터 계층"이라고 부릅니다).

이렇게 분리해두면, 화면이 보이는 방식을 변경하더라도 앱이 하는 일에는 영향을 주지 않고, 앱이 하는 일을 변경하더라도 데이터와 통신하는 방식이 망가질 걱정을 덜 수 있습니다. 문제는 한곳에 머물러 퍼지지 않습니다. 제가 신입 시절, '빨리 돌아가기만 하면 돼!'라고 생각하며 UI, 로직, DB 접근 코드를 한 파일에 몰아넣었다가, 나중에 유지보수 지옥을 맛본 적이 많습니다. 이 경험을 통해 분리가 얼마나 중요한지 뼈저리게 느꼈죠.

AI에게 붙여넣을 지시어:

인터페이스, 비즈니스 로직, 데이터 접근 코드를 각각 별도의 파일로 분리해주세요. 서로 섞이지 않도록 해주세요.

이 한 문장을 꾸준히 사용하면, 이 가이드의 어떤 조언보다도 많은 프로젝트 붕괴를 막을 수 있습니다.

생존 기술 #2: 하나는 하나의 일만

머릿속에 담아두기 충분히 간단한 규칙이 있습니다. 파일이나 함수는 한 문장으로 설명할 수 있는 '하나의 일'만 해야 합니다.

어떤 파일이 무슨 일을 하는지 설명하려고 할 때, "이것도 하고 저것도 하고 심지어 그것도 해요"라고 말해야 한다면, 그 파일은 너무 많은 일을 하고 있는 것이고, 버그가 숨어들기 쉽고 변경이 잘못될 가능성이 높은 곳이 될 겁니다.

작고, 단일 목적의 조각들은 다루기 쉽습니다. 찾아내고, 이해하고, 두려움 없이 변경할 수 있죠. 거대한 '만물상' 파일은 마치 늪과 같습니다. 더 많은 것을 담을수록, 모든 편집은 도박이 됩니다. 이 원칙은 제가 몇 년 차 개발자가 되어서야 비로소 진가를 알게 된 부분인데요, 특히 레거시 프로젝트를 개선할 때, '왜 이 함수는 이렇게나 많은 일을 하고 있지?' 하는 순간마다 '단일 책임 원칙'이 얼마나 중요한지 다시금 깨닫습니다.

AI에게 붙여넣을 지시어:

각 파일과 함수는 단 하나의 명확한 책임을 가져야 합니다. 두 가지 이상의 일을 하는 부분은 분리해주세요.

생존 기술 #3: 각 데이터는 하나의 본거지

이것은 초보자 프로젝트가 무너지는 가장 흔한 방법 중 하나이므로, 주의 깊게 살펴보세요.

앱이 성장함에 따라, 로그인한 사용자 정보나 장바구니 품목과 같은 동일한 정보가 여러 다른 곳에 복사되어 관리될 수 있습니다. 그러면 이 복사본들이 서로 동기화되지 않고 어긋나게 됩니다. 앱의 어떤 부분은 장바구니에 세 개의 항목이 있다고 생각하고, 다른 부분은 하나만 있다고 생각하며, 결국 앱은 전혀 이치에 맞지 않고 디버깅하기 거의 불가능한 방식으로 작동하기 시작합니다.

생존 규칙은 이렇습니다: 모든 데이터 조각은 정확히 한 곳에 존재하며, 다른 모든 것은 그 한 곳에서 데이터를 읽어야 합니다. 즉, '진실의 원천(Single Source of Truth)'이 하나여야 합니다. AI가 프로젝트 곳곳에 당신의 상태(state)를 무심코 복사본으로 만들도록 내버려 두지 마세요. 프로젝트를 진행하다 보면, '분명 이 값은 여기서 업데이트했는데, 다른 화면에서는 왜 예전 값을 보여주지?' 하는 미스터리한 버그를 수도 없이 만납니다. 제가 여러 번의 삽질 끝에 깨달은 건, 데이터의 '진실의 원천'을 하나로 고정하는 것이 결국 디버깅 시간을 획기적으로 줄여준다는 사실입니다.

AI에게 붙여넣을 지시어:

이 데이터는 단 하나의 진실의 원천을 가져야 합니다. 컴포넌트 간에 중복시키지 말고, 모든 것이 한곳에서 데이터를 읽도록 해주세요.

이것은 '기술적으로는 아무것도 망가지지 않았지만, 모든 것이 일치하지 않는' 가장 골치 아픈 종류의 버그를 예방해 줍니다.

생존 기술 #4: 생성 전에 '모양'을 결정하라

대부분의 초보자는 이렇게 개발합니다: 기능을 떠올리고, AI에게 요청하고, 반복. AI는 매번 임시방편으로 구조를 만들고, 결국 각 조각들은 서로 제대로 들어맞지 않게 됩니다. 왜냐하면, 애초에 어떻게 맞춰야 할지 아무도 결정하지 않았으니까요.

모든 것을 바꾸는 변화는 바로 이것입니다: 구축하기 전에 앱의 각 부분에 이름을 붙여주세요.

코드를 생성하기 전에, 주요 구성 요소와 각 구성 요소의 역할을 적어보세요. 간단한 앱이라면 '로그인', '사용자 프로필', '메인 대시보드', '결제'가 될 수 있습니다. 네 개의 조각, 각각 명확한 역할을 가지고 있습니다. 이 목록—각 조각과 그 책임을 미리 아는 것—이 바로 평이한 언어로 설명하는 아키텍처입니다. 당신은 방금 해낸 겁니다. 전혀 무서울 게 없죠.

그리고 한 번에 한 조각씩 완벽하게 구축한 다음, 다음 조각으로 넘어가세요. AI에게 전체 앱을 한 번에 생성해달라고 요청하지 마세요. 당신이 이해할 수 없는 엉망진창을 얻게 될 겁니다. 로그인을 만들고, 작동시키고, 이해하세요. 그 다음에 다음 조각으로 넘어가는 겁니다. 예전에 AI에만 의존해서 전체 앱을 한 번에 생성해달라고 시도해봤는데, 결과물은 작동은 해도 마치 모래성 같더군요. 제가 실무에서 가장 효과를 본 방법은, 백지 위에 핵심 기능을 먼저 스케치하고 AI에게는 그 스케치에 따라 하나씩 채워나가도록 지시하는 것이었습니다. 이 과정이 프로젝트의 견고함을 좌우했죠.

AI에게 붙여넣을 지시어:

제 앱의 주요 컴포넌트와 각 역할은 다음과 같습니다: [당신의 목록]. [X]부터 시작하여 한 번에 하나씩 만들어봅시다.

생존 기술 #5: AI에게 설명하게 하라

이 습관은 개발을 학습으로 바꾸는 중요한 과정입니다. 그리고 초보자를 진정으로 구조를 이해하는 사람으로 변화시키는 핵심이죠.

AI가 준 코드를 그저 받아들이고 다음으로 넘어가지 마세요. 이렇게 질문해보세요:

"왜 이런 방식으로 구조를 만들었나요?"
"각 부분은 일반적인 용어로 무슨 일을 하나요?"
"이 부분을 변경하면 다른 어떤 부분에 영향을 미치나요?"

당신은 AI를 자판기가 아니라 튜터로 활용하는 겁니다. AI의 모든 답변은 프로젝트가 어떻게 조립되는지에 대한 지식을 조금씩 더 가르쳐줄 것입니다. 이는 당신이 시작할 때 부족했던 바로 그 지식이죠. 이 과정을 꾸준히 하면, 프로젝트를 거듭할수록 당신은 코드를 그저 생성하는 사람이 아니라 코드를 이해하는 사람으로 변모할 겁니다. 그 이해가 바로 이 게임의 전부입니다. 저는 AI를 단순한 코드 생성기가 아니라 최고의 튜터로 활용합니다. '왜 이렇게 짰어? 더 쉬운 방법은 없어?'라고 꾸준히 질문하며 코드를 해석하는 연습을 하다 보니, 어느새 저 스스로도 복잡한 아키텍처를 설계하고 개선할 수 있는 안목이 생기더군요. 이 습관이 제 성장의 가장 큰 동력이었습니다.

AI에게 붙여넣을 지시어:

이 코드를 사용하기 전에, 어떻게 구조화되어 있고 그 이유는 무엇인지 간단한 용어로 설명해주세요. 저는 그저 실행하는 것이 아니라 이해하고 싶습니다.

생존 기술 #6: 지루하고 일관되게 유지하라

두 가지 습관이 짝을 이루어 작동하기 때문에 함께 묶었습니다.

지루함이 영리함을 이깁니다. AI가 매끄럽고 복잡하며 인상적인 해결책을 제시할 때, 더 간단한 방법은 없는지 물어보세요. 비전문가인 당신에게 화려한 버전은 승리가 아니라 오히려 부담입니다. 왜냐하면, 이해할 수 없는 복잡성은 유지보수하거나 고칠 수 없는 복잡성이기 때문입니다. 단순하고 명확한 버전이야말로 다음 달에도 여전히 다룰 수 있는 버전입니다. 항상 단순한 것을 선호하세요.

일관성이 다양성을 이깁니다. 기능 A를 한 가지 방식으로 만들고 기능 B를 완전히 다른 방식으로 만든다면 (개별 AI 세션에서 쉽게 발생할 수 있습니다), 당신의 프로젝트는 어떤 규칙도 따르지 않고 모든 것이 혼란스러운 조각보가 될 겁니다. 새로운 기능은 기존 기능의 패턴과 일치시키세요. 가끔 AI가 꽤나 '스마트'해 보이는 최신 기술이나 복잡한 패턴을 제안할 때가 있습니다. 제가 실무에서 얻은 교훈은, 화려함보다는 '지금 당장 이해하고 유지보수할 수 있는' 단순함이 훨씬 가치 있다는 겁니다. 일관성은 또 다른 중요한 요소인데, 팀원들과 협업할 때 서로 다른 스타일의 코드가 뒤섞여 혼란이 가중되는 걸 여러 번 경험한 후로는 '뻔하고 일관된' 코드가 최고의 코드라는 생각을 굳히게 되었습니다.

AI에게 붙여넣을 지시어:

가장 똑똑한 버전이 아니라, 작동하는 가장 간단한 버전을 제공해주세요. 그리고 제 프로젝트에 이미 있는 구조와 패턴을 따라주세요.

너무 늦기 전에 경고 신호를 알아차려라

여기에 당신의 연기 감지기가 있습니다. 아래 증상 중 하나라도 느끼기 시작하면, 기능 추가를 멈추고 먼저 구조를 정리하세요:

무엇이 망가질지 몰라서 변경하는 것을 두려워합니다.
하나를 고치면 다른 것이 계속 망가집니다.
더 이상 아무것도 어디에 있는지 찾을 수 없습니다.
파일들이 계속해서 점점 커지고 더 많은 일을 합니다.
당신 스스로도 프로젝트를 들여다보면 이해가 안 됩니다.

이 중 어떤 것도 당신이 실패했다는 의미는 아닙니다. 그저 프로젝트가 구조보다 더 커졌다는 뜻입니다. 이는 전문가를 포함해 누구에게나 일어나는 일입니다. 차이점은 이제 당신이 그 느낌이 무엇을 의미하는지, 그리고 무엇을 해야 하는지 안다는 겁니다. 잠시 멈추고, 조각들을 분리하고, 더 쌓아 올리기 전에 이해도를 회복하세요.

핵심 정리

컴퓨터 공학 학위가 없어도 AI로 실제 소프트웨어를 만들 수 있습니다. 그 장벽은 진정으로 사라졌고, 다시 돌아오지 않을 겁니다.

하지만 "코드를 생성할 수 있다"와 "스스로 성장하더라도 살아남는 것을 만들 수 있다"는 서로 다른 이야기이며, 그 간극을 메우는 것이 바로 **'구조'**입니다. AI가 당신에게 제공할 수 없는 유일한 부분이죠. 왜냐하면, 그것은 당신의 프로젝트에 대한 '결정'에 달려 있고, 그 결정은 오직 당신만이 내릴 수 있기 때문입니다. AI는 코드를 제공합니다. 당신은 그 코드에 '모양'을 부여해야 합니다.

좋은 소식은 그 모양을 만드는 것이 어렵지 않다는 겁니다. 몇 가지 습관만 지키면 됩니다: 조각들을 분리하고, 각 조각에 하나의 일만 시키고, 각 데이터는 한곳에만 두며, 생성 전에 계획하고, AI에게 설명을 요청하며, 지루하고 일관되게 유지하는 것. 이 습관들을 지키고, 개발하면서 당신이 만들고 있는 것을 이해한다면, 생각보다 훨씬 많은 것을 만들 수 있을 겁니다. 그것도 무너지는 걸 지켜보지 않고요.

간단하게 시작하세요. 그리고 계속해서 이해할 수 있는 상태를 유지하세요. 그것이 바로 생존의 길입니다.

원문: https://dev.to/james_anderson_h/building-with-ai-when-you-dont-know-architecture-a-survival-guide-1ma3 수집일: 2026-09-02 01:39:14