AI에게 '예약 앱을 만들어 달라'고 요청하면, 날짜와 시간을 고르는 화면이나 예약 버튼 등을 만들어 줍니다. 자신의 아이디어가 화면이 되고 실제로 조작할 수 있는 것은 즐거운 일입니다.
여기서 사용 가능한 앱으로 만들기 위해서는 화면의 뒷부분(백엔드)도 구축해야 합니다. 예약을 저장하고 다음에 열었을 때도 확인할 수 있게 하거나, 같은 시간에 신청이 겹쳤을 때의 처리 방식을 정하는 것이 필요하기 때문입니다. '예약 완료'라는 표시만으로는 데이터가 실제로 저장되었는지까지는 알 수 없습니다.
본 기사에서는 예약 앱을 예로 들어 프론트엔드(Front-end), 백엔드(Back-end), 데이터베이스(Database), 그리고 프레임워크(Framework)의 역할을 정리합니다.
여기서는 핫페ッパー와 인스타그램 DM으로 고객이 오는 가게를 가정해 보겠습니다. 이미 가게를 알게 되는 경로가 있으므로, 우선 그 경로에서 예약이 확정되기까지의 흐름을 확인합니다.
DM으로 날짜 시간을 상담한 후 핫페퍼로 안내할지, 아니면 DM 대화 과정에서 예약을 확정할지 등입니다. 직원은 어디서 빈 시간을 확인하고, 변경이나 취소를 어디에 기록하는 것일까요? 이 부분이 명확하지 않은 상태에서 새로운 예약 화면을 추가하면, 확인할 장소나 입력해야 하는 수고가 늘어나게 됩니다.
조사해 본 결과, 필요한 것은 고객용의 새로운 화면이라기보다 직원이 DM 대응 상황을 공유할 수 있는 시스템일지도 모릅니다. AI에게 요청할 때도 누가 어디서 왔는지, 지금 어떻게 대응하고 있는지까지 알려주면, 만들 기능을 생각하기가 쉬워집니다. 외부 서비스와 자동 연동이 가능한지는 사용 가능한 기능이나 계약 조건을 별도로 확인해야 합니다.
여기서는 웹의 구조를 배우기 위해, 자체적으로 예약 입력 및 저장 기능을 만드는 경우를 예로 들어 설명하겠습니다. 핫페퍼나 인스타그램과 자동으로 연동되는 구성은 아닙니다.
먼저 자동차 운전석을 상상해 보세요. 핸들과 페달로 조작하고, 계기판으로 속도를 확인합니다. 이처럼 사람이 조작하거나 상태를 보는 부분이 앱의 프론트엔드와 비슷한 역할을 합니다.
액셀러레이터 조작을 받아 차량 상태에 따라 동력을 조정하는 제어 메커니즘은 백엔드에 비유할 수 있습니다. 운전석에서는 보이지 않지만, 조작에 따라 실제 처리를 수행합니다.
데이터베이스는 내비게이션의 등록 지점이나 주행 기록을 저장하고 나중에 꺼내 볼 수 있는 시스템에 비유됩니다. 계기판에 지금 표시되는 것과 기록으로 남아있는 것은 별개입니다. 앱에서도 '화면에 나타난 것'과 '저장된 것'을 분리해서 생각합니다.
자동차와 웹 앱은 구조가 다르지만, 조작하는 부분, 처리하는 부분, 기록을 남기는 부분으로 나누면 각각의 역할을 파악하기 쉽습니다. 예약 앱에서는 다음과 같습니다.
프론트엔드는 이용자가 보는 화면이나 조작을 담당합니다. 예약 날짜를 고르는 캘린더, 입력 폼, 전송 중 표시 등이 해당됩니다. HTML은 페이지 구조, CSS는 시각적 디자인(외모), JavaScript는 조작에 따른 움직임 등을 다룹니다.
백엔드에서는 받아온 예약 날짜 시간에 빈 시간이 있는지, 조작하는 사람에게 권한이 있는지를 확인한 후에 저장 처리를 진행합니다.
데이터베이스는 예약이나 이용자 등의 정보를 저장하고 필요할 때 꺼내 쓰는 시스템입니다.
전형적인 구성에서는 화면에서 예약 요청을 보내면, 백엔드가 이를 확인하고 데이터베이스에 저장합니다. 그 결과가 화면으로 돌아와 사용자에게 완료를 알립니다. 이 통신에는 HTTP라는 메커니즘이 사용됩니다. 기본적인 흐름은 MDN의 서버 사이드 입문에서도 설명되어 있습니다.
이 모든 것을 하나의 프로젝트로 만들기도 합니다. 폴더나 파일을 보기만 해도 구별하기 어려울 때도 있으므로, 어떤 코드가 무엇을 담당하는지 확인해 나갑니다.
API라는 단어도 자주 등장합니다. 웹 개발에서는 다른 기능에 데이터를 전달하거나 처리를 요청할 때의 접점(interface)으로 나타납니다.
예를 들어 예약 기능에서는 희망 날짜 시간을 보내면, 예약 번호나 받아들여지지 않은 이유가 돌아옵니다. 이런 주고받음을 위해 전송지나 데이터 형식, 돌려줄 내용을 정해 놓습니다.
예약이 불가능할 때도 이 주고받음을 살펴보면 원인을 좁힐 수 있습니다. 화면에서 요청이 보내지지 않은 경우와, 요청은 도착했지만 저장에 실패한 경우는 고치는 곳이 다르기 때문입니다.
AI에게는 '고쳐줘'뿐만 아니라, '전송지, 보낸 내용, 돌아온 결과를 확인해서 실패한 부분을 설명해 줘'라고 요청할 수 있게 됩니다. 확인에 사용하는 기록에서는 개인 정보나 비밀 정보를 제거합니다.
앱에는 URL마다 처리를 전환하거나, 입력 내용을 확인하는 등 반복적으로 필요한 메커니즘이 있습니다. 이런 개발을 돕는 기능과 구성상의 규칙을 제공하는 것이 웹 프레임워크입니다. 갖춰진 기능은 제품마다 다릅니다. MDN의 프레임워크 해설에 그 역할이 정리되어 있습니다.
자동차 제작에서 공통의 차체나 부품 장착 규격을 사용하는 것처럼, 앱에서도 기존 시스템을 활용함으로써 개발 수고를 덜 수 있습니다. 프레임워크를 사용하더라도 예약 접수 조건 등, 자신의 앱에 필요한 규칙은 설계해야 합니다.
자주 언급되는 React와 Next.js도 역할에 차이가 있습니다. React는 화면을 부품으로 나누어 조립하기 위한 라이브러리입니다. Next.js는 React를 사용하는 프레임워크로, 서버에서 처리하는 작업과 브라우저에서 처리하는 작업을 하나의 프로젝트에서 다룰 수 있습니다. 공식 문서에서도 이 실행 위치의 차이가 설명되어 있습니다.
Next.js 프로젝트를 읽을 때는 브라우저에서 동작하는 코드와 서버에서 동작하는 코드를 구분해서 볼 필요가 있습니다.
AI가 프레임워크를 제안한다면, 이번 앱에서 무엇에 사용할 것인지 설명해 달라고 요청합시다. 공개할 곳에서 작동할 수 있는지, 필요한 기능이 갖춰져 있는지도 확인하면 선택 이유를 알게 됩니다.
예약 앱에서는 자신의 예약에만 취소 버튼을 표시하는 경우가 있습니다. 하지만 단순히 타인의 예약에서 버튼을 숨기는 것만으로는 취소 처리를 막을 수 없습니다. 이용자의 브라우저에서 전송되는 요청은 화면 조작 외의 방법으로도 만들어질 수 있습니다. 전달받은 예약 번호를 그대로 믿으면, 다른 사람의 예약을 취소할 가능성이 있습니다.
취소 처리를 하는 쪽에서도, 조작한 사람이 그 예약을 취소할 수 있는지 확인해야 합니다.
이 확인과 관련된 것이 '인증(Authentication)'과 '인가(Authorization)'입니다. 인증에서는 이용자가 누구인지 확인하고, 인가에서는 그 사람에게 허용하는 작업을 판단합니다. 로그인 기능만 있다고 해서 모든 권한 확인이 끝나는 것은 아닙니다. OWASP의 인가 가이드도 요청별 권한 확인과 클라이언트 측 판정에만 의존하지 않는 것을 권장합니다.
AI와 확인을 진행할 때는, 다른 이용자의 예약 번호를 지정했을 때 취소 처리가 거부되는지 등 조건을 구체적으로 전달합니다. 테스트용 계정과 예약을 준비하여, 예상대로 거부되는지 실제로 확인해 봅니다.
예약이 가능해졌다면, 새로고침이나 통신 실패 같은 경우도 시험해 봅니다. 예약 앱이라면 다음과 같은 항목을 확인할 것입니다.
- 새로고침해도 저장한 예약을 확인할 수 있다.
- 다른 이용자의 예약을 멋대로 변경할 수 없다.
- 같은 시간대에 동시에 신청해도, 정원을 초과하여 확정되지 않는다.
- 통신에 실패했을 때, 성공한 것처럼 표시되지 않는다.
버튼의 연타를 화면에서 막는 것은 유용하지만, 다른 단말기에서 동시에 신청될 가능성도 있습니다. 예약의 확정 조건은 저장하는 쪽을 포함해서 설계해야 합니다.
이러한 확인 항목들은 구현 전에 AI와 함께 정리해 두면 편리합니다. 수정할 때는 변경 전후의 차이점을 보고, 동작을 확인하면서 조금씩 진행합니다. 한 번에 많은 변경을 가하지 않는 편이, 결함의 원인을 추적하기 쉽습니다.
처음부터 전부를 외우려고 하면 힘들기 때문에, 만들고 싶은 기능에 맞춰서 조금씩 배우는 것이 추천됩니다.
예약 앱이라면, 우선 테스트용 예약을 하나 저장해 보고, 새로고침 후에도 확인할 수 있는 수준까지 만듭니다. 그 과정에서 화면에서 저장소까지의 처리를 추적하고, 다음으로 이용자별 권한이나 에러 대응을 조사하는 식으로 진행하면 배울 내용을 좁힐 수 있습니다.
DiluNova가 중요하게 생각하는 것은, 먼저 '언제까지, 어디까지 갈지'를 정하고, 그곳을 향해 나아갈 방법을 짜는 것입니다. AI를 사용하는 개발에서도, 완성이라 부를 조건을 미리 정해두는 것이 지시와 확인 양쪽 모두에 도움이 됩니다.
손에 앱이 있다면, 버튼 하나를 골라 처리를 추적해 보는 것이 좋은 연습이 됩니다. AI 관련 파일을 언급하게 하고, 전송지, 권한을 확인할 처리, 데이터의 저장소를 순서대로 살펴보면, 이번에 소개된 역할과 실제 코드를 연결 지어 볼 수 있습니다.
실제 프로젝트에서는, 시스템을 이해하는 것 외에도, 사용하는 사람의 어려움을 조사하여, 처음에 만들 범위와 완성 조건을 의뢰자와 맞춰두는 것이 필요합니다. 히어링부터 테스트/공개까지의 진행 과정은 AI를 사용한 웹 개발 실무 가이드에서 예약 접수 개선 예시와 함께 자세히 소개하고 있습니다.
끝까지 읽어주셔서 감사합니다.
DiluNova는 AI 도입·동반 지원, 소프트웨어·하드웨어 개발, 보안 진단에 임하는 회사입니다. 먼저 '언제까지, 어디까지 갈지'를 정하고, 사용하는 사람의 업무에 맞는 형태를 함께 고민합니다. DiluNova 홈페이지에서는 사업 내용과 개발·지원 실적도 소개하고 있습니다.
