데이터베이스 스키마 개념을 설명하게 함으로써 전산 직무에 필요한 DB 기초 지식 수준과 전공 이해도를 평가한다.
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
스키마는 데이터베이스의 구조를 정의하는 것입니다. 어떤 테이블이 있고, 각 테이블에 어떤 컬럼이 있으며, 컬럼의 타입과 제약 조건이 무엇인지를 명세하는 것입니다. 스키마가 잘 설계되어 있으면 데이터 무결성을 유지하고 쿼리 효율을 높일 수 있습니다. 저는 수업 프로젝트에서 PostgreSQL로 ERD를 먼저 그린 뒤 스키마를 정의하는 순서로 작업하였습니다.
처음에 스키마를 대충 잡으면 나중에 테이블 수정 비용이 크다는 것을 직접 경험하였습니다. 그 경험 이후로 스키마 설계를 가장 먼저 꼼꼼하게 하는 습관이 생겼습니다. 구조가 탄탄하면 개발이 편해집니다. 설계가 먼저라는 감각이 그때 생겼습니다.
스키마는 데이터의 구조와 규칙을 정의한 설계도라고 생각합니다. 데이터베이스에서 어떤 데이터를 어떤 형식으로, 어떤 관계로 저장할지를 사전에 명세하는 것이에요. 논리 스키마는 데이터 관계를 정의하고, 물리 스키마는 실제 저장 방식까지 포함합니다. 인턴 때 기존 DB 스키마를 분석하면서 설계 의도를 파악하는 것이 코드보다 먼저라는 것을 배웠어요. 스키마를 이해하면 어디에 어떤 데이터가 들어오는지 전체 그림이 보입니다.
스키마를 읽는 능력이 협업에서도 중요하다는 걸 그때 알았어요. 구조를 먼저 이해하는 사람이 시스템을 더 빠르게 파악합니다. 스키마 없이 코드만 보면 맥락이 빠집니다.
스키마라는 개념은 데이터베이스뿐 아니라 `API` 설계에서도 쓰입니다. JSON Schema나 OpenAPI 스펙도 결국 입출력 데이터의 구조를 정의하는 것이에요. 어떤 필드가 있고, 어떤 타입이어야 하며, 어떤 값이 들어올 수 있는가를 사전에 정의하면 협업에서 오해가 줄어요. 팀 프로젝트에서 API 스펙을 먼저 정의했을 때, 프론트와 백엔드가 독립적으로 작업할 수 있어서 개발 속도가 빨라졌습니다. 스키마는 단순히 구조를 정의하는 것이 아니라 팀이 공통으로 이해하는 약속이라고 생각해요. 그 약속이 잘 정의될수록 협업이 매끄러워집니다. 스키마가 있는 팀과 없는 팀의 속도 차이는 명확합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 한전KDN 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.