데이터베이스 (Database)

화면에 보이는 데이터와 저장된 데이터

문의 관리 앱에서 항목을 추가했는데 새로고침 뒤 사라졌다면, 화면 상태만 바꿨을 가능성이 있습니다. 사용자가 보는 목록과 지속적으로 저장되는 기록은 같은 것이 아닙니다.

BOAZ의 AX 리더 실습은 가상 데이터로 기능을 만든 뒤 직접 입력과 데이터 저장으로 이어집니다. 이때부터 ‘화면이 그럴듯하다’에 더해 저장 위치, 조회 조건, 접근 권한을 확인해야 합니다.

관계형 데이터베이스는 업무 대상을 나눠 담는다

다음은 가상 교육 문의 앱의 예시입니다.

이름만으로 연결하면 동명이인이나 이름 변경을 다루기 어렵습니다. 식별자를 두고 관계를 연결하면 같은 대상을 일관되게 참조할 수 있습니다. 값의 중복이나 빠지면 안 되는 항목은 제약으로 관리할 수 있습니다.

PostgreSQL의 관계형 개념 안내는 표·행·열을 설명합니다. 이는 관계형 모델의 설명이며 문서형이나 그래프형을 포함한 모든 데이터베이스의 저장 형태가 같다는 뜻은 아닙니다.

화면·API·데이터베이스를 연결한다

화면은 입력을 받고 결과를 보여줍니다. API는 요청을 받아 권한과 입력을 확인하고 저장·조회 기능에 연결할 수 있습니다. 데이터베이스는 구조에 맞춰 기록을 관리합니다. 제품에 따라 일부 층을 관리형 서비스가 제공하기도 합니다.

바이브 코딩으로 이 연결을 만들 때는 저장 성공 메시지뿐 아니라 실제 기록을 확인합니다. 오류가 났는데 화면만 성공으로 바뀌거나, 이전 사용자의 데이터를 그대로 표시하면 업무 상태를 잘못 전달하게 됩니다.

로그인과 접근 권한을 따로 검증한다

로그인은 ‘누구인가’를 확인하고, 접근 권한은 ‘이 기록으로 무엇을 할 수 있는가’를 정합니다. 담당자에게 배정된 문의만 보여야 한다면 조회와 수정 경로 모두에서 그 조건을 검사해야 합니다.

버튼을 숨겼어도 요청을 직접 보내 수정할 수 있다면 제한이 충분하지 않습니다. 가드레일을 설계할 때 화면의 안내와 서버의 실행 제한을 구분하는 이유입니다.

동시 변경과 중복 저장도 업무 문제다

두 사람이 같은 문의를 수정할 때 어느 변경을 보존할지 정해야 합니다. 여러 기록을 함께 바꿔야 하는 작업은 일부만 반영되는 상황도 다룹니다. 이를 위해 트랜잭션과 충돌 처리 등 데이터베이스가 제공하는 기능을 업무 조건에 맞게 사용합니다.

통신이 끊겨 같은 저장 요청을 다시 보냈을 때 중복 생성되지 않도록 설계할 수도 있습니다. 이런 조건을 AI가 자동으로 알아서 정했다고 가정하지 말고 PRD에 필요한 동작을 적습니다.

저장 기능의 완료 기준

최소한 저장 후 재조회, 새로고침, 허용된 다른 기기에서의 접근, 권한이 다른 사용자, 잘못된 입력을 확인합니다. 필요한 기록을 삭제하거나 덮어썼을 때 복구할 방법도 정합니다. 백업 파일의 존재와 실제 복구 가능 여부는 별도로 확인해야 합니다.

지식 그래프처럼 관계 중심으로 데이터를 활용하는 경우에도 식별자와 출처, 변경 기록을 관리하는 기반은 필요합니다. 먼저 어떤 질문에 답하고 어떤 변경을 보존할지 정한 뒤 저장 구조를 선택합니다.