요즘은 개발이 정말 빨라졌습니다. 바이브코딩으로 하루 만에 프로토타입을 뽑아내는 사람도 있고, 커서나 클로드 코드 같은 AI 도구를 쓰면 비개발자도 화면을 직접 만들어볼 수 있는 시대가 됐거든요.
그러다 보니 자연스럽게 드는 생각이 있습니다. "이렇게 빨리 만들 수 있는데, 화면 설계까지 해야 하나?" 기획서도 쓰고, 요구사항도 정리했는데, 거기에 설계 단계까지 거치라고 하면 답답한 마음이 들 수 있어요. 그냥 바로 만들어보고, 안 되면 고치면 되는 거 아닌가 싶거든요.
그런데 설계를 건너뛴 프로젝트에서 실제로 벌어지는 일을 보면, 이야기가 달라집니다.
화면 설계 없이 가면 어떤 일이 벌어지나요
가장 흔한 상황부터 말씀드리겠습니다.
앱 개발이 어느 정도 진행된 뒤에 결과물을 처음 확인하는 순간이 옵니다. 그때 높은 확률로 이런 말이 나와요.
"이건 제가 생각한 거랑 다른데요."
화면은 만들어져 있는데 흐름이 다르거나, 기능은 있는데 사용자가 쓰는 순서가 의도와 달라요.
이게 왜 생기느냐면, 기획서에는 "뭘 만들 건지"가 담겨 있지만 "어떻게 보여주고 어떤 순서로 작동하는지"까지는 안 담겨 있기 때문입니다. 그 빈 곳을 개발자가 스스로 판단해서 채운 거예요. 그 판단이 의뢰인의 머릿속 그림과 다르면, 결과물이 달라질 수밖에 없습니다.
여기서 문제가 커지는 이유가 있어요. 개발이 끝난 뒤에 "이 화면을 이렇게 바꿔주세요"라고 하면, 화면 하나만 바꾸는 게 아닙니다. 화면이 바뀌면 데이터 흐름이 바뀌고, 데이터 흐름이 바뀌면 뒷단 로직도 바뀌어야 해요. 화면 설계서에서 잡았으면 30분이면 끝날 수정이, 개발 이후에는 며칠이 걸리기도 합니다. 수정비로 치면 3배에서 5배까지 차이가 나거든요.
바이브코딩으로 직접 만드는 경우에도 마찬가지입니다. 오히려 더 빨리 이 상황을 만납니다. AI가 코드를 빠르게 만들어주니까, 설계 없이 바로 "이거 만들어줘"를 반복하게 되거든요. 기능이 하나둘 쌓이다 보면 어느 순간 서로 충돌하기 시작해요. 로그인 화면과 결제 화면이 따로 놀고, 데이터가 엉뚱한 곳에 저장되고, 한 곳을 고치면 다른 곳이 깨지는 상황이 반복됩니다. 바이브코딩 경험담에서 가장 많이 나오는 말이 "PRD를 먼저 안 쓰면 망한다"인 이유가 이겁니다.
AI 시대에 앱 설계는 오히려 더 중요해졌습니다
여기서 한 가지 오해를 짚어야 합니다. AI가 코딩을 대신해주니까 설계가 필요 없어진 게 아니라, 설계의 무게가 더 커진 겁니다.
예전에는 개발자가 기획서를 받아서, 빠진 부분을 경험으로 채우고, "이건 이렇게 하는 게 맞겠다"고 판단하면서 설계를 겸했어요. 그런데 AI한테 코딩을 시키는 상황에서는, AI가 그 판단을 대신 해주지 않습니다. AI는 시킨 대로 만들 뿐이에요. "이 화면 다음에 뭘 보여줘야 하는지", "사용자가 뒤로 갔을 때 데이터는 어떻게 되는지" 같은 걸 정해주지 않으면, AI도 엉뚱한 걸 만들어요.
그래서 바이브코딩을 제대로 하는 사람들은 코딩 전에 PRD를 먼저 씁니다. PRD는 제품 요구사항 문서라는 뜻인데, 쉽게 말하면 "이 서비스가 어떻게 작동해야 하는지를 미리 정리해놓은 설계서"예요. 화면 흐름, 기능 간의 연결, 데이터가 어디서 어디로 가는지를 명확하게 쓴 다음에 AI한테 넘기는 거죠.
앱 외주 개발도 같은 원리입니다. 개발사에 기획서만 넘기면, 기획서에 안 담긴 부분은 개발사가 알아서 판단합니다. 그 판단이 내 의도와 다르면 결과물이 달라지고, 나중에 수정비가 생기거든요. 화면 설계서를 통해 화면 흐름과 기능 구조를 미리 합의해두면, 그 빈 곳이 사라집니다.
결국 앱 설계란, 만들기 전에 "어떻게 작동해야 하는지"를 정리하는 과정입니다. AI 시대에 코드를 쓰는 건 빨라졌지만, 뭘 만들어야 하는지를 정하는 건 여전히 사람의 영역이에요.
비개발자가 앱 설계 단계에서 확인해야 할 것
설계라고 하면 개발자의 영역 같지만, 비개발자도 반드시 관여해야 하는 부분이 있습니다. 핵심은 두 가지예요.
첫째, 화면 흐름을 확인해야 합니다
앱 설계 단계에서 나오는 결과물 중 하나가 화면 설계서입니다. 사용자가 첫 화면에서 시작해서 최종 목적을 달성할 때까지, 어떤 화면을 어떤 순서로 거치는지를 그린 것이에요. 이걸 확인할 때 중요한 건 "이 화면이 예쁜가"가 아닙니다. "이 버튼을 누르면 어디로 가는지", "이 단계에서 사용자가 뭘 보는지", "뒤로 갔을 때 어떻게 되는지"를 체크하는 거예요.
이 확인을 꼼꼼히 하지 않으면, 개발 끝난 뒤에 "여기서 뒤로 가면 원래 화면으로 돌아가야 하는 거 아니에요?"라는 상황이 생깁니다. 화면 설계서에서 이걸 잡으면 선 하나만 바꾸면 돼요. 개발 이후에 잡으면 코드를 뜯어야 합니다.
둘째, "이건 나중에 해도 된다"를 정해야 합니다
설계를 하다 보면 기능이 자꾸 늘어나는 유혹이 생깁니다. 화면 흐름을 그리면서 "여기에 이것도 있으면 좋겠다"가 계속 떠오르거든요. 그런데 다 넣으면 개발 범위가 커지고, 일정이 밀리고, 비용이 올라갑니다.
그래서 설계 단계에서 가장 중요한 판단이 "이건 1차에 넣고, 이건 2차로 미룬다"를 정하는 겁니다. 이 판단은 개발사가 대신 해줄 수 없어요. 서비스의 핵심 가치가 뭔지를 가장 잘 아는 건 만드는 사람이니까요. 10번 글에서 다뤘던 전략 수립 단계에서 "이 서비스가 왜 필요한지"를 정리해뒀다면, 여기서 그 기준이 그대로 쓰입니다.
설계 유무에 따른 개발 흐름 비교
설계 단계 수정비 vs 개발 후 수정비: 3~5배 차이
AI로 빠르게 만들 수 있는 시대일수록
바이브코딩이든 AI 에이전트든, 코드를 만드는 속도는 계속 빨라지고 있습니다. 그런데 속도가 빨라질수록 방향이 잘못됐을 때의 낭비도 커지거든요. 빠르게 만들었는데 엉뚱한 걸 만들었으면, 빠르게 버린 셈이니까요.
화면 설계는 그 방향을 잡아주는 과정입니다. 어떤 도구를 쓰든, 누가 만들든, "이 서비스가 어떻게 작동해야 하는지"가 정리되어 있으면 헛걸음이 줄어듭니다.
다만 이 과정을 혼자 하기는 쉽지 않아요. 화면 흐름을 그리는 건 해볼 수 있는데, 그 흐름에서 기술적으로 빠진 부분이 없는지, 데이터 구조는 이대로 괜찮은지를 판단하려면 개발 경험이 필요하거든요. 설계서를 완벽하게 혼자 만들어 오는 게 아니라, 경험 있는 파트너와 함께 만들어가는 게 현실적인 방법입니다.
흐름소프트에서 프로젝트를 진행할 때, 설계 단계에서 의뢰인과 가장 많은 대화를 나누는 이유가 이겁니다. 화면 설계서를 그리면서 "이 화면 다음에 사용자가 어디로 가야 하죠?", "이 기능은 1차에 꼭 들어가야 하나요?"를 함께 정리합니다. 이 과정을 거친 프로젝트는 개발 도중에 방향이 흔들리는 일이 확실히 줄어들거든요.
정리하면 이렇습니다
화면 설계를 건너뛰고 싶은 마음은 자연스럽습니다. AI로 바로 만들 수 있는 시대에, 한 단계를 더 거치는 게 비효율적으로 느껴질 수 있어요. 그런데 설계 없이 간 프로젝트에서는 "생각한 거랑 다른" 결과물이 나오고, 수정비가 3배에서 5배까지 올라가는 상황이 반복됩니다.
AI 시대에 코드를 쓰는 건 빨라졌지만, 뭘 만들어야 하는지를 정하는 건 여전히 사람의 일입니다. 앱 설계란 결국, 만들기 전에 "이건 이렇게 작동해야 한다"를 정리하는 과정이에요. 이 과정을 거치면 AI든 개발사든, 의도대로 만들어줄 가능성이 훨씬 높아집니다.
