'좋아요' 두 번 누르기 원천 차단법

앱 코드를 믿으면 안 되는 이유 (동시성 문제)

바이브코딩 AI에게 "한 사람이 같은 글에 좋아요를 한 번만 누를 수 있게 해줘"라고 하면 보통 이런 흐름의 로직(코드)을 짜줍니다.

1. 프론트엔드: 버튼을 누르면 서버로 '좋아요' 요청을 보냅니다.
2. 백엔드 서버: 데이터베이스에 가서 "이 사람이 이 글에 이미 좋아요를 누른 적이 있나?" 물어봅니다. (`SELECT`)
3. 백엔드 서버: "아직 없네!"라는 대답을 들으면, 그제야 데이터베이스에 '좋아요' 기록을 새롭게 하나 추가합니다. (`INSERT`)
4. 프론트엔드: '좋아요' 버튼을 회색으로 비활성화하여 더 이상 못 누르게 막습니다.

겉보기에는 아주 논리적이고 완벽해 보입니다. 그런데 만약 악의적인 유저가 해킹 프로그램을 써서 0.001초 간격으로 '좋아요' 요청을 10번 연속으로 우다다닥 보냈다면 어떻게 될까요? (또는 스마트폰이 느려져서 유저가 답답한 마음에 버튼을 마구 연타했을 수도 있습니다.)

앱 코드는 여러 요청이 동시에 들어왔을 때 이렇게 속수무책으로 뚫려버립니다. 이를 전문 용어로 동시성 경쟁 상태(Race Condition)라고 부릅니다.

최후의 철벽 수비: `UNIQUE` 제약조건

이런 구멍을 완벽하게 틀어막으려면, 검사 로직을 백엔드 앱이 아니라 데이터베이스의 깊은 곳(DB 스키마 자체)에 박아두어야 합니다. "어떤 일이 있어도 이 칸에는 똑같은 값이 두 번 들어올 수 없다!"라고 데이터베이스 문지기에게 못을 박는 것이 바로 `UNIQUE` 제약조건입니다.

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(100) UNIQUE, -- 똑같은 이메일은 절대 두 번 들어갈 수 없습니다.
  name VARCHAR(50)
);

궁극의 콤보: 복합 UNIQUE (Composite Unique)

그렇다면 서두에서 말한 '좋아요' 문제는 어떻게 해결할까요? '좋아요' 테이블 구조를 상상해 봅시다. 어떤 유저(`user_id`)가 어떤 글(`post_id`)에 좋아요를 눌렀는지 기록합니다. 여기에 `user_id` 컬럼에 혼자 `UNIQUE`를 걸면, 그 유저는 일평생 단 하나의 글에만 좋아요를 누를 수 있게 됩니다. `post_id`에 걸면 그 글에는 세상에서 딱 한 명만 좋아요를 누를 수 있습니다.

우리가 원하는 조건은 "유저 혼자서는 여러 글을 누를 수 있고, 글 하나도 여러 유저에게 받을 수 있지만, [어떤 유저 + 어떤 글] 의 짝꿍 조합은 오직 세상에 하나만 존재해야 한다"는 것입니다. 이때 사용하는 것이 두 개 이상의 컬럼을 묶어서 중복을 검사하는 복합 UNIQUE입니다.

CREATE TABLE likes (
  id SERIAL PRIMARY KEY,
  user_id INT NOT NULL,
  post_id INT NOT NULL,
  -- 이 두 개의 조합이 겹치는 데이터는 절대 삽입 불가!
  UNIQUE (user_id, post_id) 
);

이 제약조건 한 줄만 테이블에 걸어두면, 프론트엔드가 버그를 내든 백엔드 코드가 부실하든 아무 상관이 없습니다. 누가 버튼을 1초에 100번 연타하더라도, 데이터베이스는 첫 번째 요청만 1개의 좋아요로 기록하고 나머지 99개는 데이터베이스 엔진 차원에서 강력하게 튕겨내 버립니다. 이것이 데이터 무결성(Data Integrity)을 완벽하게 지켜내는 진정한 방어 기술입니다.