"할 일 관리 앱 만들었는데, 카테고리 추가하려니까 완전 꼬여버렸어요. 처음엔 단순했는데, 기능 하나 추가하니까 전체를 다시 짜야 한대요. 데이터를 어떻게 정리해야 이런 일이 안 생기나요?"

맞아요. 기능은 만들었는데, 나중에 추가/수정하려니까 구조 자체를 뜯어고쳐야 하는 거예요.

왜 이런 일이 생길까요?

처음에 데이터를 어떻게 정리할지 생각 없이 시작해서 그래요. 단순할 땐 괜찮았는데, 복잡해지니까 한계가 드러나는 거죠.

이게 바로 자료구조(Data Structure) 문제예요. 데이터를 어떤 형태로 정리하느냐에 따라 나중에 확장이 쉬울 수도, 불가능할 수도 있어요.

자료구조를 알면 AI한테 **"이 구조로 관리해줘"**라고 정확히 말할 수 있어요. 그러면 AI가 확장 가능한 구조로 만들어줘요.

오늘부터 PART 4: 기술 개념 - 설계가 시작돼요.

알고 가기

🚫 이거 모르면: "구조 잡아줘" → 매번 다른 구조 → 나중에 기능 추가할 때 다 꼬임 ✅ 이거 알면: "레이어드로 통일해줘"라고 말하면 → 일관된 구조 → 고도화가 됨

이 글을 읽고 나면

  • 자료구조가 뭔지, 왜 필요한지 알 수 있어요
  • 자주 쓰는 자료구조 3가지를 구분할 수 있어요
  • 상황에 맞는 자료구조를 선택할 수 있어요
  • AI한테 "이 구조로 관리해줘"를 요청할 수 있어요

자료구조가 뭔가요?

자료구조는 데이터를 어떤 형태로 정리할지 정하는 거예요.

PART 3 복습: 데이터는 어디에 저장되나

12편에서 어디에 저장할지를 배웠죠?

오늘 배울 것은: 그 데이터를 어떤 형태로 정리할지

  • 12편: 어디에 저장? → 메모리 / localStorage / DB
  • 16편(오늘): 어떻게 정리? → 배열 / 객체 / 트리

자주 쓰는 자료구조

바이브 코더가 알아야 할 자료구조예요.

자료구조 3대장

1. 배열 (Array / List): 순서대로 나열

배열은 데이터를 순서대로 나열하는 거예요.

배열의 핵심: 순서가 있다

📦 실제 데이터 예시

// 할 일 목록 (배열)
[
  { "id": 1, "title": "밥 먹기", "completed": false },
  { "id": 2, "title": "코딩하기", "completed": true },
  { "id": 3, "title": "운동하기", "completed": false }
]

// 댓글 목록 (배열)
[
  { "id": 101, "author": "김철수", "content": "좋은 글이네요!" },
  { "id": 102, "author": "이영희", "content": "감사합니다~" }
]

// 주문 내역 (배열)
[
  { "orderId": "ORD001", "product": "무선 이어폰", "price": 50000 },
  { "orderId": "ORD002", "product": "키보드", "price": 80000 }
]

2. 객체 (Object / Dictionary): 이름표 붙인 서랍

객체는 데이터에 이름표를 붙여서 저장하는 거예요.

객체의 핵심: 이름표로 찾는다

📦 실제 데이터 예시

// 사용자 정보 (객체)
{
  "id": 1,
  "name": "김철수",
  "email": "kim@example.com",
  "age": 30,
  "job": "마케터"
}

// 앱 설정 (객체)
{
  "darkMode": true,
  "language": "ko",
  "notifications": {
    "email": true,
    "push": false
  }
}

// 게시글 하나 (객체)
{
  "id": 42,
  "title": "바이브 코딩 후기",
  "content": "AI랑 같이 코딩하니까 신세계...",
  "author": "김철수",
  "createdAt": "2026-01-12",
  "likes": 25
}

3. 트리 (Tree): 폴더 안에 폴더

트리는 데이터를 계층 구조로 정리하는 거예요.

트리의 핵심: 부모-자식 관계

카테고리 (트리 구조)
           [전체]
            /  \
        [업무] [개인]
         /  \    \
     [기획][개발][취미]

📦 실제 데이터 예시

// 카테고리 (트리를 배열+객체로 표현)
[
  { "id": 1, "name": "전체", "parentId": null },
  { "id": 2, "name": "업무", "parentId": 1 },
  { "id": 3, "name": "개인", "parentId": 1 },
  { "id": 4, "name": "기획", "parentId": 2 },
  { "id": 5, "name": "개발", "parentId": 2 },
  { "id": 6, "name": "취미", "parentId": 3 }
]
// → parentId로 누가 누구의 하위인지 알 수 있어요

// 댓글-대댓글 (트리 구조)
[
  { "id": 1, "content": "좋은 글이네요!", "parentId": null },
  { "id": 2, "content": "동감합니다", "parentId": 1 },
  { "id": 3, "content": "저도요!", "parentId": 1 },
  { "id": 4, "content": "완전 공감해요", "parentId": 2 }
]
// → 댓글 1번에 대댓글 2, 3이 달리고, 대댓글 2에 4가 달림

// 조직도 (트리 구조)
[
  { "id": 1, "name": "대표", "parentId": null },
  { "id": 2, "name": "개발팀장", "parentId": 1 },
  { "id": 3, "name": "마케팅팀장", "parentId": 1 },
  { "id": 4, "name": "프론트개발자", "parentId": 2 },
  { "id": 5, "name": "백엔드개발자", "parentId": 2 }
]

4. 큐 (Queue): 줄 서기

큐는 먼저 온 게 먼저 처리되는 구조예요. 은행 번호표처럼요.

📦 실제 사용 예시: 이메일 발송

5. 스택 (Stack): 접시 쌓기

스택은 나중에 온 게 먼저 처리되는 구조예요. 접시 쌓기처럼요.

📦 실제 사용 예시: 되돌리기(Undo)

큐 vs 스택: 헷갈릴 때

자동화와 웹훅: 큐가 필요한 이유

자동화를 만들다 보면 **웹훅(Webhook)**을 자주 만나요. 웹훅이랑 큐는 짝꿍이에요.

📦 실제 예시: 결제 완료 후 자동화

🔧 AI한테 이렇게 요청하세요:

나: "결제 완료되면 이메일 보내고 재고 차감하는 자동화 만들어줘.
    웹훅으로 결제 알림 받을 건데, 주문이 많을 때를 대비해서
    큐로 처리하게 해줘."

→ AI가 웹훅 수신 + 큐 + 순차 처리 구조로 만들어줌

상황별 자료구조 선택 가이드

실전 예시: 쇼핑몰 데이터 구조

쇼핑몰을 만든다면 어떻게 정리할까요?

핵심: 자료구조를 조합해서 쓴다

AI한테 이렇게 요청하세요

자료구조를 알면 AI한테 어떤 형태로 관리할지 정확히 말할 수 있어요.

상황 1: 할 일 관리 앱

❌ 나쁜 예 (구조 언급 없음)

나: "할 일 관리 앱 만들어줘"

→ AI가 알아서 구조를 정하는데, 나중에 카테고리 추가하려면 전부 다시 짜야 할 수도 있어요.

✅ 좋은 예 (자료구조 지정)

나: "할 일 관리 앱 만들 건데,
    할 일 목록은 배열로 관리해줘.
    각 할 일은 객체로 만들어서 제목, 완료여부, 마감일 필드 넣어줘.
    나중에 카테고리 기능 추가할 거니까 카테고리 ID 필드도 미리 넣어줘."

→ AI가 확장 가능한 구조로 만들어요.

상황 2: 댓글 시스템

❌ 나쁜 예

나: "댓글 기능 만들어줘"

✅ 좋은 예

나: "댓글 기능 만들 건데,
    댓글 목록은 배열로 관리해줘.
    대댓글도 있으니까 트리 구조로 부모 댓글 ID를 참조하게 해줘.
    각 댓글은 객체로 작성자, 내용, 작성일 필드 넣어줘."

상황 3: 쇼핑몰 카테고리

❌ 나쁜 예

나: "카테고리 만들어줘"

✅ 좋은 예

na: "상품 카테고리를 트리 구조로 만들어줘.
    대분류, 중분류, 소분류까지 3단계로 갈 수 있게.
    각 카테고리는 ID, 이름, 부모 카테고리 ID 필드로 관리해줘."

자료구조 선택의 실수 사례

실제로 자주 발생하는 실수예요.

사례 1: 할 일을 단순 문자열로 저장

사례 2: 카테고리를 배열로만 저장

실제 대화 예시

AI랑 자료구조 정하면서 대화할 때 이렇게 해요.

┌────────────────────────────────────────────────────────────────┐ │ 상황: 할 일 관리 앱 만들기 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 나: "할 일 관리 앱 만들 건데, Next.js + Supabase로 갈 거야." │ │ │ │ AI: "할 일 데이터 구조 어떻게 할까요? │ │ 1. 간단하게 제목만 저장? │ │ 2. 제목, 완료 여부, 마감일 포함? │ │ 3. 카테고리까지?" │ │ │ │ 나: "2번으로 가되, 나중에 카테고리 추가할 거니까 │ │ 카테고리 ID 필드도 미리 넣어줘. 기본값은 null로." │ │ │ │ AI: "알겠어요. 그럼 이렇게 구조 잡을게요: │ │ │ │ todos 테이블 (DB) │ │ - id: 고유 ID │ │ - title: 제목 │ │ - completed: 완료 여부 (true/false) │ │ - due_date: 마감일 │ │ - category_id: 카테고리 ID (null 허용) │ │ - created_at: 생성일 │ │ │ │ 프론트엔드에선 할 일 목록을 배열로 관리하고, │ │ 각 할 일은 이 객체 형태로 저장할게요." │ │ │ │ 나: "좋아. 그렇게 만들어줘." │ │ │ │ 💡 여기서 뭐가 중요했나요? │ │ - "배열로 관리", "객체 형태" 언급 │ │ - 나중 확장(카테고리) 미리 고려 │ │ - AI가 테이블 구조 제안하면 확인 후 진행 │ │ │ └────────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────────┐ │ 상황: 나중에 카테고리 기능 추가 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 나: "카테고리 기능 추가할 건데, │ │ 업무/개인 대분류 아래에 세부 카테고리 넣을 수 있게 해줘." │ │ │ │ AI: "트리 구조로 만들면 되겠네요. │ │ │ │ categories 테이블 │ │ - id: 카테고리 ID │ │ - name: 카테고리 이름 │ │ - parent_id: 부모 카테고리 ID (null이면 최상위) │ │ │ │ 예시: │ │ { id: 1, name: "업무", parent_id: null } │ │ { id: 2, name: "기획", parent_id: 1 } │ │ { id: 3, name: "개발", parent_id: 1 } │ │ │ │ 이렇게 하면 '업무' 아래 '기획', '개발'이 들어가요." │ │ │ │ 나: "그렇게 해줘. 그리고 할 일 목록에서 │ │ 카테고리별로 필터링할 수 있게 해줘." │ │ │ │ AI: "할 일 조회할 때 category_id로 필터링하는 │ │ API 만들게요." │ │ │ │ [기능 확인] │ │ - 카테고리 추가 → 트리 구조로 표시됨 ✅ │ │ - 할 일 작성 시 카테고리 선택 가능 ✅ │ │ - 카테고리별 할 일 필터링 ✅ │ │ │ │ 💡 처음에 category_id 필드를 미리 넣어뒀기 때문에 │ │ todos 테이블은 건드릴 필요 없이 categories 테이블만 │ │ 추가하면 됐어요. 이게 확장 가능한 구조예요. │ │ │ └────────────────────────────────────────────────────────────────┘

자료구조 선택 체크리스트

프로젝트 시작할 때 이렇게 생각하세요.

□ 1. 데이터가 순서대로 나열되어야 하나?
   YES → 배열 사용
   - 할 일 목록, 댓글, 주문 내역 등

□ 2. 항목마다 이름이 있고 의미가 다른가?
   YES → 객체 사용
   - 사용자 정보, 설정, 폼 데이터 등

□ 3. 데이터가 그룹 안에 그룹 형태인가?
   YES → 트리 사용
   - 카테고리, 댓글-대댓글, 조직도 등

□ 4. 나중에 기능이 추가될 가능성이 있나?
   YES → 필드를 미리 넣어두기
   - category_id 같은 예비 필드

□ 5. 데이터가 복잡하면 조합하기
   - 배열 안에 객체
   - 객체 안에 배열
   - 트리 구조 + 객체 정보

코드 문법 몰라도 돼요

💡 잠깐, 저는 코드를 못 짜는데요?

괜찮아요. 자료구조 개념만 알면 돼요.

여러분이 알아야 할 것:
✅ 배열 = 순서대로 나열
✅ 객체 = 이름표 붙인 데이터
✅ 트리 = 계층 구조

여러분이 몰라도 되는 것:
❌ 배열을 코드로 어떻게 만드는지
❌ 객체를 어떻게 선언하는지
❌ 트리를 어떻게 구현하는지

→ AI한테 "배열로 관리해줘"라고 말만 하면 돼요.
→ AI가 코드로 만들어줘요.

주의사항: 처음부터 완벽한 구조는 없어요

⚠️ 처음부터 모든 걸 완벽하게 설계할 수 없어요

근데 이것만은 지키세요:

  • 단순 문자열보다는 객체로
  • 확장될 것 같으면 예비 필드 미리
  • 계층 구조면 처음부터 트리로

다음 단계: 아키텍처

자료구조를 알았으면 이제 어디에 뭘 둘지 정하는 게 아키텍처예요.

오늘 배운 것: 데이터를 어떤 형태로 정리?
              → 배열 / 객체 / 트리

다음 편: 코드를 어떻게 구조화?
         → 프론트엔드 / 백엔드 / DB 각각 어떻게 나눌까
         → 레이어드 아키텍처, 클린 아키텍처 등

오늘의 핵심 정리

셀프체크

이 글을 이해했다면 아래 질문에 답할 수 있어요:

  • 게시글 목록은 어떤 자료구조로 관리하는 게 좋을까요?
  • 사용자 프로필 정보(이름, 나이, 이메일)는 어떤 자료구조가 적절한가요?
  • 쇼핑몰 카테고리(전자제품 > 컴퓨터 > 노트북)는 어떤 자료구조인가요?
  • 회원가입 이메일을 순서대로 발송하려면 어떤 자료구조가 적절한가요?
  • Ctrl+Z 되돌리기 기능은 어떤 자료구조를 쓰나요?
  • 배열 (순서대로 나열)
  • 객체 (항목마다 이름표 붙여서 관리)
  • 트리 (계층 구조)
  • 큐 (먼저 온 게 먼저 처리)
  • 스택 (나중에 온 게 먼저 처리)

다음 글 예고

오늘은 자료구조를 배웠어요. 데이터를 배열로 할지, 객체로 할지, 트리로 할지 선택하는 법이요.

근데 자료구조만 알면 부족해요. "이 코드를 어디에 둘까?"도 중요해요.

다음 글에서는 아키텍처 개념을 알아볼게요.

17편: 아키텍처 개념

  • "코드를 어떻게 구조화할까?"
  • 레이어드, 클린, MVC... AI한테 "이 아키텍처로 가자"라고 말하는 법
  • "프론트는 컴포넌트로 나누고, 백엔드는 서비스 레이어 분리해줘"

자료구조로 데이터를 정리했으면, 이제 코드를 정리하는 법을 배워요.

이 시리즈 로드맵

PART 3: 기술 개념 - 큰 그림
[ 10편 ] 프로그램의 종류 ✅
   ↓
[ 11편 ] 프론트엔드 vs 백엔드 ✅
   ↓
[ 12편 ] 데이터는 어디에 저장되나 ✅
   ↓
[ 13편 ] 서비스들이 대화하는 방법: API ✅
   ↓
[ 14편 ] 프로젝트 구조 ✅
   ↓
[ 15편 ] 데이터 흐름 ✅
   ↓
PART 4: 기술 개념 - 설계
[ 16편 ] 자료구조 개념 (지금 여기!)
   ↓
[ 17편 ] 아키텍처 개념
   ↓
[ 18편 ] 디자인 패턴 개념
   ↓
  ...

궁금한 점이나 다뤘으면 하는 주제가 있으면 댓글로 남겨주세요!