상세화면설계에 필요한 DB 또는 SQL 지식

여러분, 오늘은 상세화면설계를 할 때 꼭 알아두면 좋을 데이터베이스와 SQL 지식에 대해 이야기해보려 합니다. 처음 기획자로 일하기 시작했을 때, 개발자가 "이건 DB 구조상 어렵습니다"라는 말을 들으면 반박할 논리가 없었던 기억이 생생합니다.

기획자로서 DB나 SQL을 깊이 알 필요는 없지만, 기본적인 개념과 원리를 이해한다면 개발자와의 소통이 훨씬 수월해지고 현실적인 기획을 할 수 있습니다.

---

데이터베이스 이해는 왜 중요한가?

화면을 설계한다는 것은 단순히 보이는 UI만 그리는 것이 아닙니다. 그 화면에서 어떤 데이터가 보여지고, 어떻게 저장되며, 어떻게 연결되는지 이해해야 합니다.

예를 들어, 회원관리 페이지를 기획할 때 "회원목록에 결제내역도 함께 보여주세요"라고 요청했다고 가정해봅시다. 개발자 입장에서는 이 요청이 DB 구조에 따라 간단할 수도, 매우 복잡할 수도 있습니다.

한 프로젝트에서 제가 비슷한 요청을 했을 때, 개발자는 "회원 테이블과 결제 테이블이 완전히 별도로 설계되어 있어서 한 화면에 표시하려면 성능이 크게 저하됩니다"라고 답했습니다. 당시 DB 구조를 이해했다면 더 현실적인 대안을 제시할 수 있었을 것입니다.

---

기획자가 알아야 할 데이터베이스 기초 개념

1. 테이블과 필드

데이터베이스는 엑셀 시트처럼 생각하면 이해하기 쉽습니다. 각 시트가 하나의 '테이블'이고, 열(컬럼)이 '필드'입니다.

예를 들어 '회원' 테이블이 있다면:

• 회원ID (고유식별자)
• 이름
• 이메일
• 가입일
• 상태 등의 필드로 구성됩니다.

실제 프로젝트에서 회원가입 화면을 설계할 때, 어떤 정보를 수집할지 고민한다면 이 정보들이 DB의 어떤 테이블, 어떤 필드에 저장될지 생각해보는 습관이 중요합니다.

2. 관계(Relationship)

데이터베이스의 핵심은 테이블 간의 '관계'입니다. 주요 관계 유형으로는:

일대일(1:1): 한 회원이 하나의 프로필을 가지는 경우

일대다(1

): 한 회원이 여러 개의 주문을 할 수 있는 경우

다대다(N

): 한 상품이 여러 카테고리에 속할 수 있고, 한 카테고리에 여러 상품이 있는 경우

쇼핑몰 상품 상세페이지를 기획한다고 상상해보세요. 상품과 리뷰는 1

관계입니다. 이 관계를 이해한다면 "리뷰가 많은 상품의 경우 리뷰를 어떻게 보여줄 것인가?"와 같은 현실적인 고민을 기획에 반영할 수 있습니다.

3. 주요키(Primary Key)와 외래키(Foreign Key)

주요키(PK): 테이블에서 레코드를 고유하게 식별하는 필드 (예: 회원ID)

외래키(FK): 다른 테이블의 주요키를 참조하는 필드 (예: 주문 테이블의 회원ID)

마이페이지에서 "내 주문 내역"을 보여주는 화면을 기획한다면, 이 두 개념의 이해가 필수적입니다. 시스템이 어떻게 특정 회원의 주문들을 연결해서 보여주는지 알 수 있기 때문입니다.

---

SQL의 기본 이해

SQL(Structured Query Language)은 데이터베이스와 대화하는 언어입니다. 기획자가 모든 SQL 문법을 알 필요는 없지만, 기본적인 개념을 이해하면 도움이 됩니다.

1. SELECT 문의 이해

 

sql

SELECT 이름, 이메일 FROM 회원 WHERE 상태 = '활성' ORDER BY 가입일 DESC LIMIT 10;

이 쿼리는 '활성' 상태인 회원들의 이름과 이메일을 가입일 최신순으로 10명만 조회합니다.

회원 목록 화면을 기획할 때, 위와 같은 쿼리가 실행된다는 것을 알면 "정렬 기준을 사용자가 선택할 수 있게 해보면 어떨까?" 같은 아이디어를 낼 수 있습니다.

2. JOIN의 개념

데이터베이스에서 가장 중요한 개념 중 하나인 JOIN은 여러 테이블을 연결하는 방법입니다.

 

sql

SELECT 회원.이름, 주문.주문번호 
FROM 회원 
JOIN 주문 ON 회원.회원ID = 주문.회원ID;

이 쿼리는 회원과 그들의 주문 정보를 함께 가져옵니다.

한 번은 제가 통합검색 결과 화면을 기획하면서, 한 페이지에 회원, 상품, 게시글 등 모든 검색결과를 보여주려 했습니다. 개발자가 "이건 여러 테이블을 JOIN해야 해서 성능 이슈가 있습니다"라고 했을 때, 그 의미를 바로 이해하고 탭으로 분리하는 대안을 제시할 수 있었습니다.

---

실무 기획에 바로 적용할 수 있는 DB 지식

1. 데이터 조회 성능 고려하기

복잡한 화면일수록 여러 테이블의 데이터를 조회해야 하고, 이는 성능 저하로 이어질 수 있습니다.

예를 들어 쇼핑몰 관리자 페이지에서 "한 화면에서 회원정보, 주문내역, 리뷰, 문의내역을 모두 보여주세요"라는 요구사항이 있다면, 이것은 많은 테이블 JOIN이 필요하다는 것을 이해해야 합니다.

제가 경험한 프로젝트에서는 이런 요구에 "데이터를 탭으로 분리하거나, 주요 정보만 표시하고 상세는 별도 모달로 보여주는 방식"으로 대안을 제시했습니다.

2. 필터링과 페이지네이션 설계

목록 화면을 설계할 때 DB 관점에서 생각해보면:

필터링: WHERE 절에 조건을 추가하는 것 정렬: ORDER BY 절로 구현 페이지네이션: LIMIT과 OFFSET 사용

이런 이해를 바탕으로 "어떤 필터가 DB에 부담을 줄까?"를 고려하며 화면을 설계할 수 있습니다.

한 프로젝트에서 자유롭게 모든 필드를 검색할 수 있는 고급검색 기능을 요청받았을 때, DB 인덱스 개념을 알고 있었기에 "자주 검색하는 필드 위주로 검색 옵션을 제한하는 것이 성능에 유리합니다"라고 제안할 수 있었습니다.

3. 폼 설계와 유효성 검사

입력 폼을 설계할 때 DB 필드 타입과 제약사항을 고려해야 합니다:

• 텍스트 필드의 최대 길이 (VARCHAR 길이 제한)
• 날짜 형식 (DATE, DATETIME 타입)
• 필수 입력 값 (NOT NULL 제약)

이런 정보를 알면 사용자에게 적절한 안내와 유효성 검사를 기획에 포함시킬 수 있습니다.

회원가입 화면을 설계하면서 이메일 필드가 DB에서 UNIQUE 제약조건이 있다는 것을 알고 있었기에, 중복 이메일 체크 기능을 추가로 기획했던 경험이 있습니다.

---

DB 모델링의 기본 이해하기

완벽한 DB 모델링을 할 필요는 없지만, 기본적인 ERD(Entity-Relationship Diagram)를 읽을 수 있다면 큰 도움이 됩니다.

예를 들어 아래와 같은 간단한 ERD가 있다고 가정해봅시다:

회원(1) ──── 주문(N) │ └── 배송지(N)

이 다이어그램은 "한 회원이 여러 주문을 할 수 있고, 여러 배송지를 가질 수 있다"는 관계를 보여줍니다.

이런 구조를 이해하면 "배송지 관리" 화면을 설계할 때, 회원별로 여러 배송지를 저장하고 관리할 수 있는 UI를 자연스럽게 기획할 수 있습니다.

한 프로젝트에서 개발팀이 공유한 ERD를 보고 "상품과 카테고리가 다대다 관계네요. 그럼 한 상품이 여러 카테고리에 동시에 표시될 수 있도록 기획해야겠군요."라고 바로 이해하고 대응할 수 있었습니다.

---

실무에서 개발자와 소통하기

1. 적절한 질문하기

개발자와 대화할 때 DB/SQL 기초 지식이 있다면 더 효과적인 질문을 할 수 있습니다:

❌ "이 기능 가능한가요?" ✅ "회원 테이블과 포인트 이력 테이블을 연결해서 조회하는 것이 성능상 문제가 없을까요?"

이런 질문은 개발자에게 당신이 기술적 고민을 함께하고 있다는 인상을 줍니다.

2. 개발 난이도 이해하기

어떤 기능이 DB 구조상 간단한지, 복잡한지 판단할 수 있다면 우선순위를 정하는 데 도움이 됩니다.

예를 들어, "특정 기간의 주문 데이터만 보여주기"는 단순한 WHERE 조건이지만, "각 고객별로 가장 많이 구매한 카테고리 분석하기"는 복잡한 JOIN과 GROUP BY가 필요하다는 것을 이해할 수 있습니다.

이런 지식이 있었기에 제가 참여했던 프로젝트에서 "대시보드에 어떤 통계를 먼저 구현할지" 우선순위를 정할 때 큰 도움이 되었습니다.

---

실전 예시: 회원관리 화면 설계

회원관리 페이지를 설계한다고 가정해보겠습니다. DB 지식이 없다면 단순히 필요한 필드를 나열할 것입니다.

그러나 DB를 이해하고 있다면:

1. 회원 기본정보는 '회원' 테이블에서 가져온다는 것을 인지
2. 회원의 주문내역은 '주문' 테이블과 JOIN 필요 → 성능 고려해 "최근 5건만 표시하고 더보기 버튼 제공"
3. 회원의 등급은 '등급' 테이블과 연결 → 등급 변경 시 드롭다운으로 선택할 수 있게 설계
4. 회원 포인트는 '포인트 이력' 테이블에서 합산 → 누적 포인트와 상세내역 분리

이런 식으로 DB 구조를 고려한 현실적인 화면을 설계할 수 있습니다.

실제로 제가 참여했던 프로젝트에서는 처음에 회원 상세 페이지에 모든 정보를 한꺼번에 보여주려 했습니다. 그러나 DB 구조를 이해한 후, 관련 데이터를 탭으로 분리하고 주요 정보만 요약해 보여주는 방식으로 변경했더니 개발팀의 호응이 매우 좋았습니다.

---

기획자에게 유용한 DB 관련 도구

1. Excel이나 Google Sheets: 간단한 데이터 모델을 시각화하는 용도로 활용
2. Draw.io: 무료로 간단한 ERD를 그릴 수 있는 도구
3. Airtable: DB 구조를 쉽게 이해할 수 있게 도와주는 도구
4. DB Designer 사이트: 온라인에서 DB 모델을 간단히 설계할 수 있는 도구

이런 도구들을 활용하면 개발자와 더 효과적으로 소통할 수 있습니다.

프로젝트 초기에 개발팀이 ERD를 공유했을 때, 저는 Draw.io로 이를 단순화해서 기획팀 내부에 공유한 적이 있습니다. 이것이 전체 기획팀이 DB 구조를 이해하는 데 큰 도움이 되었고, 결과적으로 더 현실적인 기획이 가능했습니다.

기획자가 DB와 SQL을 깊이 알 필요는 없지만, 기본 개념을 이해한다면 개발자와의 소통이 원활해지고 더 실현 가능한 화면을 설계할 수 있습니다. 무엇보다 기획자로서의 자신감과 전문성이 한층 높아질 것입니다.

Jay Kim
웹/앱 서비스기획 26년차
현대경제연구원 IT분야 전문 컨설턴트
프로필 http://bit.ly/3E1OGQB
프로젝트 문의: mailside@gmail.com (카카오톡, 지메일)