데이터 타입이란? 바이브코딩에서 타입이 중요한 이유

AI에게 예약 앱의 데이터베이스를 만들어달라고 했더니 이런 표를 보여줍니다.

어떤 값을 저장할지는 알겠는데, 옆에 붙은 타입 이름까지 알아야 할까요? 화면에서는 모두 입력칸에 들어가는 값처럼 보이니 전부 문자열로 저장해도 될 것 같습니다.

하지만 데이터 타입은 개발 도구가 임의로 붙이는 이름표가 아니에요. 데이터베이스가 어떤 값을 허용하고, 그 값으로 어떤 작업을 할지 정하는 규칙입니다. 타입을 어떻게 정하느냐에 따라 계산과 정렬 결과, 잘못 입력한 값을 막는 방법, 앱과 데이터베이스가 값을 주고받는 과정까지 달라집니다.

데이터 타입은 값의 사용 설명서예요

데이터베이스는 이름, 금액, 날짜, 완료 여부처럼 성격이 다른 값을 함께 다룹니다. 각 컬럼에 어떤 종류의 값을 담을지 정하면 데이터베이스가 그 값을 어떻게 처리할지 알 수 있어요.

• 숫자는 더하고 빼거나 크기를 비교합니다.
• 날짜는 시간순으로 정렬하고 기간을 계산합니다.
• 불리언은 참과 거짓 중 하나인지 확인합니다.
• UUID는 고유 ID 형식에 맞는지 확인합니다.
• 문자열은 입력한 글자와 기호를 그대로 보존합니다.

스키마가 데이터베이스의 전체 설계도라면, 데이터 타입은 설계도 안에서 각 칸에 무엇을 담고 어떻게 사용할지 적은 규칙이라고 볼 수 있어요.

타입은 값을 저장하는 순간에만 필요하지 않습니다. 앱이 데이터를 다시 읽고, 검색하고, 정렬하고, 통계를 만들 때도 계속 영향을 줍니다.

자주 만나는 데이터 타입부터 볼게요

데이터베이스마다 정확한 이름은 조금씩 다르지만 일반적인 웹앱에서 자주 만나는 종류는 비슷합니다.

문자열

이름, 이메일, 전화번호, 주소, 설명처럼 글자로 다룰 값을 저장합니다. text, varchar, string 같은 이름으로 볼 수 있어요.

숫자

금액, 수량, 점수처럼 계산하거나 크기를 비교할 값을 저장합니다. 정수에는 integer, 소수점이 필요한 정확한 값에는 numeric이나 decimal을 사용할 수 있어요.

금액에 float 같은 부동소수점 타입을 무심코 선택하지 않는 편이 좋습니다. 일부 소수는 컴퓨터에서 정확히 표현하기 어려워 계산 결과에 작은 오차가 생길 수 있어요. 원 단위만 사용한다면 정수로 저장하고, 소수 단위가 필요하다면 정확한 소수 계산을 지원하는 타입을 검토할 수 있습니다.

불리언

참과 거짓, 켜짐과 꺼짐처럼 두 가지 상태를 저장합니다. boolean이나 bool이라는 이름으로 나타나요.

is_paid: true
is_canceled: false

날짜와 시간

생년월일이나 예약일처럼 날짜만 필요한 값과 게시글 작성 시각처럼 시간까지 필요한 값을 구분합니다.

예약일:   date
작성 시각: timestamp

UUID

사용자, 예약, 주문처럼 각각의 데이터를 구분하는 고유 ID에 자주 사용합니다. 긴 문자열처럼 보이지만 UUID 타입을 사용하면 데이터베이스가 형식을 확인할 수 있어요.

JSON

항목의 모양이 유연한 부가 정보를 객체 형태로 저장합니다. 다만 구조를 정하기 귀찮다는 이유로 모든 데이터를 JSON 하나에 넣으면 검색, 관계 설정, 값 검증이 어려워질 수 있어요. 자주 조회하고 규칙이 분명한 정보는 일반 컬럼으로 두는 편이 자연스럽습니다.

타입에 따라 할 수 있는 작업이 달라요

예약 앱의 기능을 떠올리면 타입마다 맡는 역할이 더 선명해집니다.

예약 인원을 숫자로 저장하면 전체 방문 인원을 더하고 5명 이상인 예약을 찾을 수 있어요. 예약일을 날짜 타입으로 저장하면 이번 주 예약이나 특정 날짜 사이의 예약을 찾을 수 있습니다.

결제 완료 여부에는 불리언 타입이 잘 맞아요. true와 false만 사용한다는 규칙이 생기므로 "완료", "결제함", "yes"처럼 같은 뜻을 여러 표현으로 저장하는 문제를 줄일 수 있습니다. UUID 타입을 사용한 예약 ID는 다른 값과 헷갈리지 않는 고유 식별자 역할을 합니다.

타입은 저장한 값의 모양뿐 아니라 앱이 그 값에 던질 수 있는 질문의 종류를 결정합니다.

타입은 잘못 입력한 값을 막아줘요

데이터 타입이 없다면 예약 인원 컬럼에 다음 값이 함께 들어갈 수 있습니다.

2
"두 명"
"미정"
-10

숫자 타입을 사용하면 "두 명"과 "미정"처럼 숫자가 아닌 값을 거부할 수 있어요. UUID 타입은 ID 형식에 맞지 않는 값을 막고, 날짜 타입은 해석할 수 없는 날짜를 걸러냅니다.

오류가 발생하면 불편하게 느껴질 수 있지만, 잘못 입력한 값이 조용히 쌓인 뒤 통계와 검색을 망가뜨리는 것보다 일찍 발견하는 편이 낫습니다. 데이터 타입은 저장한 데이터를 믿고 사용할 수 있게 돕는 첫 번째 안전장치예요.

물론 타입만으로 모든 문제를 막을 수는 없습니다. 숫자 타입도 예약 인원 -10을 허용할 수 있어요. “예약 인원은 1명 이상이어야 한다”처럼 서비스에 필요한 세부 규칙은 별도의 입력 검증이나 데이터베이스 제약 조건으로 추가해야 합니다.

값의 생김새보다 의미와 용도를 보세요

전화번호 01012345678에는 숫자만 들어 있지만 숫자 타입으로 저장할 이유는 없습니다.

• 전화번호끼리 더하거나 평균을 계산하지 않습니다.
• 맨 앞의 0을 그대로 보존해야 합니다.
• 국가번호를 붙이면 +82 같은 기호가 들어갈 수 있습니다.
• 화면에서는 010-1234-5678처럼 하이픈을 넣을 수 있습니다.

우편번호, 주문번호, 사번도 마찬가지예요. 숫자로만 이루어져 있어도 계산할 값이 아니라 대상을 구분하거나 원래 모양을 보존할 값이라면 문자열이 더 자연스럽습니다.

반대로 가격, 수량, 점수, 거리처럼 더하거나 크기를 비교할 값은 숫자 타입이 잘 맞아요. 타입을 고를 때 “어떤 글자가 들어 있는가?”보다 “이 값으로 무엇을 할 것인가?”를 먼저 물어보세요.

화면, 코드, API, 데이터베이스가 타입을 약속해야 해요

데이터베이스 컬럼의 타입을 잘 정해도 앱이 다른 타입의 값을 보내면 오류가 납니다.

화면이 받은 값과 데이터베이스가 기대하는 타입은 서로 다를 수 있어요.

앱은 각 값을 검증하고 필요한 타입으로 바꾼 뒤 데이터베이스에 보내야 합니다. 변환하거나 해석할 수 없는 값은 저장하기 전에 사용자에게 알려줘야 해요.

모든 단계가 완전히 같은 표현을 사용할 필요는 없지만 어디에서 어떤 타입으로 변환하는지는 분명해야 합니다. 화면, 앱 코드, API, 데이터베이스 중 한 곳이 서로 다른 타입을 기대하면 다음과 비슷한 오류를 볼 수 있어요.

invalid input syntax for type integer
invalid input syntax for type uuid

이런 오류가 나오면 세 가지를 확인해보세요.

1. 데이터베이스 컬럼은 어떤 타입인가요?
2. 앱은 실제로 어떤 타입의 값을 보내고 있나요?
3. 값을 올바른 타입으로 바꾸는 과정이 있나요?

값을 저장한 뒤에는 타입을 더 조심해서 바꿔야 해요

처음에는 예약 인원을 문자열로 저장했다고 해볼게요. 나중에 전체 인원을 계산하려고 숫자 타입으로 바꾸려 합니다.

"4"    → 4     변환 가능
"미정" → 숫자  변환 불가능

기존 값이 모두 숫자로 바뀔 수 있다면 비교적 단순하지만 "미정"이나 "두 명"이 섞여 있으면 타입 변경 마이그레이션이 실패할 수 있어요. 기존 값을 삭제할지, 숫자로 바꿀 규칙을 만들지, 다른 컬럼으로 옮길지 먼저 정해야 합니다.

그래서 타입을 정할 때는 지금 입력할 값뿐 아니라 앞으로 필요한 검색, 정렬, 계산도 함께 생각하는 것이 좋아요. 미래의 모든 기능을 맞힐 필요는 없지만 이미 분명한 용도는 타입에 반영할 수 있습니다.

바이브코딩에서는 값의 예시와 용도를 함께 알려주세요

AI에게 “예약 테이블을 만들어줘”라고만 요청하면 AI가 일반적인 타입을 추측합니다. 저장할 값의 예시와 사용 방법을 알려주면 더 적절한 스키마를 제안받을 수 있어요.

예약자 이름, 전화번호, 예약 인원, 예약 날짜, 결제 완료 여부를 저장할 거야. 전화번호는 앞자리 0을 유지해야 하고, 예약 인원은 전체 합계를 계산할 거야. 날짜순 정렬과 기간 검색도 필요해. 각 컬럼에 알맞은 데이터 타입을 정하고 선택한 이유를 설명해줘.

AI가 제안한 타입을 볼 때는 다음 질문으로 검토할 수 있습니다.

1. 이 값으로 계산하거나 크기를 비교할까요?
2. 날짜순 정렬이나 기간 계산이 필요할까요?
3. 원래 입력한 모양과 기호를 보존해야 할까요?
4. 값의 범위가 명확한가요?
5. 사용자가 잘못 입력한 값을 데이터베이스가 막아야 할까요?
6. 앱 코드와 데이터베이스가 같은 타입을 기대하나요?

정리

• 데이터 타입은 어떤 값을 허용하고 그 값으로 어떤 작업을 할지 정하는 규칙입니다.
• 숫자, 날짜, 불리언처럼 타입에 따라 계산, 정렬, 검색 방법이 달라집니다.
• 타입은 형식에 맞지 않는 값이 데이터베이스에 쌓이지 않도록 막아줍니다.
• 값의 생김새보다 의미와 용도를 보고 타입을 골라야 합니다.
• 화면, 앱 코드, API, 데이터베이스 사이에서 타입을 언제 바꿀지 분명해야 합니다.
• 기존 데이터가 새 타입으로 바뀔 수 있는지 확인한 뒤 타입 변경 마이그레이션을 실행해야 합니다.

데이터 타입의 이름을 모두 외우지 않아도 괜찮습니다. 이 값으로 무엇을 하고, 어떤 값을 허용하며, 어디에서 타입을 바꿀 것인지 설명할 수 있다면 더 안전한 데이터베이스를 설계할 수 있어요.