1. REST API 및 HTTP 통신 기본 개념 (실전 예시 포함)
| 핵심 키워드 | 정석적인 개념 정의 | 핵심 정보 및 작동 원리 |
|---|---|---|
| REST (Representational State Transfer) |
웹의 기존 HTTP 프로토콜을 그대로 활용하여, URL 경로로 자원(Resource)을 명시하고 HTTP 메서드로 제어하는 웹 아키텍처 스타일입니다. | • 특징: 서버와 클라이언트가 독립적으로 분리되어 통신할 수 있게 합니다. • 구성 요소: 자원(URI), 행위(HTTP 메서드), 표현(JSON 등 데이터 형태)의 3가지 요소가 명확하게 결합됩니다. |
| URI 설계 (Uniform Resource Identifier) |
인터넷상에 존재하는 특정 자원의 고유한 위치와 식별자를 체계적이고 직관적으로 설계하는 규칙입니다. | • 작동 규칙: 자원은 동사가 아닌 '복수형 명사'로 표현하고, 알파벳은 소문자만 사용하며 단어 사이는 하이픈(-)을 씁니다. • 구조적 명시: 계층 관계는 슬래시(/)로 표현하며, /api/v1/과 같은 버전 접두사를 붙여 시스템 업데이트에 대응합니다. |
| HTTP 메서드 (HTTP Methods) |
클라이언트가 서버에게 특정 자원에 대해 어떤 행위(조회, 생성, 수정, 삭제)를 요청하는지 명시하는 통신 규약입니다. | • GET: 자원을 안전하게 조회할 때 사용합니다. • POST: 새로운 자원을 생성하여 등록할 때 사용합니다. • PUT: 기존 자원의 전체 내용을 새 데이터로 교체할 때 사용합니다. • PATCH: 자원의 일부분만 수정할 때 사용합니다. • DELETE: 특정 자원을 삭제할 때 사용합니다. |
| CRUD | 데이터베이스가 가지는 가장 기본적인 4가지 처리 기능(생성, 조회, 수정, 삭제)을 묶어 부르는 소프트웨어 개발 핵심 용어입니다. | • Create (생성) → HTTP POST 메서드와 매칭 • Read (조회) → HTTP GET 메서드와 매칭 • Update (수정) → HTTP PUT / PATCH 메서드와 매칭 • Delete (삭제) → HTTP DELETE 메서드와 매칭 |
| 멱등성 (Idempotence) |
동일한 요청을 수차례 연속해서 보내도 서버의 최종 결과나 데이터 상태가 항상 똑같이 유지되는 성질입니다. | • 멱등성 있음 (GET, PUT, DELETE): 특정 데이터를 1번 지우든 100번 지우든 최종 결과는 '삭제된 상태'로 동일합니다. • 비멱등 (POST): 게시글 등록 요청을 5번 보내면 게시글이 5개 생기므로 최종 상태가 매번 달라져 비멱등합니다. |
POST /api/v1/books → 새로운 책 등록 (Create) — 성공 시 201 Created 응답 및 Location 헤더 반환 GET /api/v1/books → 등록된 전체 책 목록 조회 (Read) — 페이지네이션 쿼리 스트링 결합 가능 GET /api/v1/books/97889 → 특정 ISBN 번호를 가진 책의 상세 정보 조회 (Read) PUT /api/v1/books/97889 → 해당 책의 전체 정보를 새 데이터로 통째로 교체 수정 (Update) PATCH /api/v1/books/97889 → 해당 책의 가격 등 특정 일부분만 부분 수정 (Update) DELETE /api/v1/books/97889 → 해당 책을 시스템에서 영구 삭제 (Delete) — 성공 시 본문 없이 204 No Content 반환2. API 응답 프로토콜 및 데이터 포맷
| 핵심 키워드 | 정석적인 개념 정의 | 핵심 정보 및 작동 원리 |
|---|---|---|
| 상태 코드 (HTTP Status Code) |
클라이언트가 보낸 HTTP 요청에 대해 서버가 처리 결과를 3자리 숫자로 응답하는 시스템 통신 규약 코드입니다. | • 2xx (성공): 요청이 정상적으로 처리됨 (예: 200 OK) • 4xx (클라이언트 에러): 요청 주소가 잘못되었거나 접근 권한이 없음 (예: 404 Not Found) • 5xx (서버 에러): 서버 내부 프로그램 오류 (예: 500 Internal Server Error) |
| 201 Created | POST 요청이 성공하여 서버에 새로운 자원이 성공적으로 생성되었음을 명시하는 HTTP 상태 코드입니다. | • 동작 결과: 생성 완료 신호뿐만 아니라, 방금 생성된 새 자원이 위치한 실제 인터넷 주소(Location 헤더 값)를 함께 반환하는 것이 표준 아키텍처 규칙입니다. |
| 204 No Content | 요청(주로 DELETE)이 완벽히 성공했으나 클라이언트에게 돌려줄 데이터 본문(Body)이 없을 때 반환하는 HTTP 상태 코드입니다. | • 동작 결과: 데이터는 완전하게 삭제/변경되었지만, 화면 갱신이 불필요하거나 네트워크 전송량을 최소화하고자 할 때 유용하게 쓰입니다. |
| JSON (JavaScript Object Notation) |
데이터를 구조화하여 저장하거나 시스템 간 주고받을 때 사용하는, 인간과 컴퓨터 모두 읽고 파싱하기 쉬운 텍스트 기반의 글로벌 표준 데이터 포맷입니다. | • 구조: '키-값(Key-Value)'의 쌍 혹은 정렬된 리스트 형태를 가집니다. 특정 프로그래밍 언어에 종속되지 않고 전 세계 모든 플랫폼 간 통신 데이터 포맷으로 사용됩니다. |
| 응답 포맷 (Envelope Pattern) |
서버가 응답 데이터를 반환할 때 성공 여부, 실제 데이터, 에러 메시지 등을 하나의 일정한 봉투(Envelope) 객체로 감싸서 전달하는 표준 설계 방식입니다. | • 규격화: 항상 일정한 데이터 양식으로 응답하기 때문에, 클라이언트 앱이나 웹 프론트엔드가 에러를 사전 판별하고 핵심 데이터를 가공하여 화면에 뿌려주기 매우 편리해집니다. |
| Content-Type | HTTP 요청과 응답 메시지의 헤더 영역에 포함되어, 본문(Body)에 담겨 송수신되는 데이터가 어떤 형식인지 명시하는 메타 데이터입니다. | • 응용 방식: REST API의 경우 대다수 application/json으로 지정하여 양 시스템 간 JSON 형식임을 명시적으로 상호 식별시킵니다. |
| 페이지네이션 (Pagination) |
한 번에 대량 데이터를 서버에서 통째로 불러오지 않고, 일정 수량 단위로 쪼개어 부분적으로 가져오는 데이터 조회 최적화 기술입니다. | • Offset/Limit 방식: '몇 번째 데이터부터 몇 개를 가져올지'를 지정합니다. 전통적인 관리자 페이지나 게시판 웹 시스템에 유용합니다. • Cursor 방식: '특정 데이터 ID 기준값 다음부터 몇 개를 가져올지' 지정합니다. 데이터의 실시간 변동이 극심한 대용량 모바일 SNS 피드 조회에 활용됩니다. |
3. API 게이트웨이 및 인프라 연동
| 핵심 키워드 | 정석적인 개념 정의 | 핵심 정보 및 작동 원리 |
|---|---|---|
| API 게이트웨이 (API Gateway) |
클라이언트의 모든 API 요청을 단일 창구에서 전면 접수하여 배정하고 관리하는 네트워크 허브 인프라 장치입니다. | • 통합 관리 기능: 인증/인가(보안), 트래픽 라우팅, 요청 횟수를 제한하는 스로틀링(Throttling), 실시간 모니터링을 개별 백엔드 서버가 아닌 이 통문 한 곳에서 전담 처리합니다. |
| 프록시 통합 (Proxy Integration) |
API 게이트웨이가 클라이언트로부터 받은 HTTP 요청 메시지(헤더, 바디 등) 전체를 뒤에 있는 서버(예: AWS Lambda)에 아무런 가공 없이 그대로 전달하는 연동 방식입니다. | • 특징: 백엔드 서버나 Lambda 함수가 클라이언트의 원본 데이터 전체를 직접 유연하게 해석할 수 있어, AWS 서버리스 인프라 구축 시 표준 연동 옵션으로 적극 권장됩니다. |
4. 12가지 데이터베이스 유형 핵심 해설
| 핵심 키워드 | 정석적인 개념 정의 | 핵심 정보 및 작동 원리 |
|---|---|---|
| RDS (관계형) (Relational DB) |
데이터를 행(Row)과 열(Column) 형태의 표(Table) 구조로 관리하며, 테이블 간의 명확한 연관 관계를 바탕으로 관리하는 정통 데이터베이스입니다. | • 핵심 특징: 데이터 무결성을 지켜내는 'ACID' 트랜잭션, 다수의 표를 결합해 복합 조회하는 'JOIN' 기능, 데이터 중복을 제거하는 '정규화'가 핵심 축입니다. AWS에서는 관리형 MySQL, PostgreSQL, Oracle 등으로 제공됩니다. |
| Aurora (AWS 네이티브) |
AWS 클라우드에 최적화하여, 기존 오픈소스 관계형 DB의 스토리지 레이어 구조를 전면 재설계한 고성능 클라우드 전용 DB입니다. | • 성능: 표준 MySQL 대비 최대 5배, PostgreSQL 대비 최대 3배 뛰어난 연산 처리 성능을 보장합니다. 가용영역 3곳에 6개의 데이터 복사본을 실시간 자동 분산 복제하므로 고가용성이 탁월합니다. |
| DynamoDB (NoSQL Key-Value) |
서버리스(Serverless) 형태의 초고속 키-값(Key-Value) 및 문서형 NoSQL 데이터베이스 서비스입니다. | • 성능: 저장된 데이터 규모나 동시 접속자 수가 폭증하더라도, 밀리초(ms) 단위의 일정한 초고속 응답 성능을 보장합니다. 용량이 모자라면 시스템이 가상 스케일 아웃을 알아서 수행합니다. |
| Redis / ElastiCache (인메모리 캐싱) |
물리 디스크가 아닌, 서버 컴퓨터의 초고속 RAM 메모리 위에 데이터를 직접 적재하여 실시간 처리하는 인메모리 데이터베이스입니다. | • 속도: 디스크를 읽는 지연 시간이 없어 초당 10만 건 이상의 압도적인 읽기/쓰기 성능을 뿜어냅니다. 주로 사용자 세션 데이터, 실시간 게임 리더보드, 자주 반복 조회되는 데이터의 임시 캐시 저장소로 활약합니다. |
| MongoDB (문서형 NoSQL) |
엄격하게 고정된 표 형태가 아니라, 유연하게 확장 가능한 JSON 형태의 문서(Document) 구조 그대로 데이터를 관리하는 대표 NoSQL 데이터베이스입니다. | • 확장성: 서비스 개발 도중 데이터 요구 규격이 수시 변경되어도 스키마 변경 부담이 없습니다. 데이터를 여러 노드로 쪼개어 수평 확장하는 '샤딩(Sharding)' 아키텍처가 매우 강력합니다. |
| Cassandra (컬럼 패밀리 NoSQL) |
대규모 분산 환경 아키텍처 하에서, 초대용량 빅데이터의 실시간 쓰기 작업을 지연 없이 처리하는 데 특화된 NoSQL 데이터베이스입니다. | • 구조: 대장 서버가 없는 '마스터리스(Masterless)' 구조로 설계되어 일부 장비가 고장 나도 전체 서비스에 중단이 없습니다. 대형 플랫폼의 대규모 로그 수집이나 글로벌 쓰기 분산 처리에 주로 투입됩니다. |
| Neo4j / Neptune (그래프형 DB) |
데이터 개체들 사이의 연결 고리와 관계 속성 자체를 '점(Node)'과 '선(Edge)'의 그래프 네트워크로 구조화하여 저장하는 특수 DB입니다. | • 용도: 친구 추천 엔진, 소셜 네트워크 인맥 관계망 분석, 금융권의 이상 거래 및 사기 추적 시스템에 전담 활용됩니다. LLM과 지식 맵을 결합하는 'GraphRAG' 인프라 기술의 중추로도 각광받고 있습니다. |
| InfluxDB / Timestream (시계열 DB) |
시간의 흐름(Time-Stamp)에 따라 일정한 규칙으로 쏟아지는 연속형 데이터를 대량 누적 저장하는 데 최적화된 DB입니다. | • 용도: 사물인터넷(IoT) 장비들의 실시간 모니터링, 클라우드 인프라 서버 로그 분석 등 시간 범위 조건의 복합 데이터 조회를 극도로 최적화하여 딜레이 없이 도출합니다. |
| 벡터 DB (Vector DB) |
AI 신경망 모델이 텍스트나 이미지의 특징을 고차원 숫자의 나열로 변환해 만든 '벡터 임베딩 데이터'를 영구 저장하고 수학적 유사도 검색을 하는 AI 전용 DB입니다. | • 용도: 거대언어모델(LLM)에 내부 기밀 문서를 직접 학습시키지 않고도, 외부 벡터 저장소 데이터를 연동하여 답변 신뢰도를 높여주는 RAG(검색 증강 생성) 아키텍처 구축의 핵심 저장소입니다. (예: Pinecone, pgvector 등) |
| Redshift / BigQuery (데이터 웨어하우스) |
열(Column) 단위로 대량의 데이터를 압축 저장하여, 수십억 건에 달하는 빅데이터의 통계 분석 값을 단 몇 초 만에 뽑아내는 OLAP 전용 거대 분석 시스템입니다. | • 특징: 일상적인 단건 CRUD 처리를 위한 저장소가 아닙니다. 기업 내부의 수년간 누적된 데이터를 적재하여, 비즈니스 전략 대시보드를 생성하거나 전사적 통계 인사이트를 추출하는 데이터 마이닝용 거대한 창고 시스템입니다. |
| OpenSearch (검색 엔진) |
텍스트 문서 내부의 핵심 어휘 형태소를 미리 분해하여 역인덱싱 표를 구축해 두고, 원하는 키워드를 실시간 검색해 내는 전문 검색 가속 인프라 엔진입니다. | • 성능: 단순 글자 매칭을 초월하여 문맥의 의미와 자연어 형태소를 정밀 분석하는 '풀텍스트(Full-Text) 검색 기능'과 AI 기반의 '벡터 하이브리드 검색'을 완벽하게 동시 지원합니다. |
| CockroachDB / Spanner (NewSQL) |
전통 관계형 DB의 ACID 무결성 보장과 NoSQL의 글로벌 무한 수평 확장을 현대 기술로 결합해 낸 최첨단 NewSQL 시스템입니다. | • 글로벌 인프라: 전 세계 각 대륙의 클라우드 데이터 센터에 걸쳐 데이터를 실시간 분산 배치하면서도, 글로벌 은행권 수준의 ACID 무결성을 한 치의 오차도 없이 일치시키는 글로벌 스케일 인프라를 실현합니다. |
5. 현대 데이터베이스 12종 실전 선택 가이드 (의사결정 트리)
비즈니스 요구사항 및 시스템 요건에 맞춰 최적의 DB를 도출하는 가이드라인입니다.
Q1. 결제, 금융, 핵심 회원 정보 등 데이터 무결성이 최우선인가?
➔ 기본적으로 관리형 RDS (MySQL, PostgreSQL)를 채택합니다. 엔터프라이즈급 성능 및 가용성이 요구된다면 Aurora를 선택하며, 글로벌 멀티 리전 단위의 초분산 환경에서 은행 수준의 완벽한 ACID 무결성이 필요하다면 CockroachDB 또는 Google Spanner (NewSQL)를 우선 검토합니다.
Q2. 서비스 스키마가 수시로 변경되고 빠른 프로토타이핑이 필요한가?
➔ JSON 문서 형식으로 스키마 없이 유연하게 적재할 수 있는 MongoDB (문서형 NoSQL)를 선택합니다. 대규모 수평 확장(샤딩)이 내장되어 유연한 확장에 매우 유리합니다.
Q3. 데이터 규모나 트래픽 폭증과 무관하게 10ms 이하의 초고속 단건 조회가 필수인가?
➔ 완전관리형 서버리스 Key-Value 저장소인 DynamoDB를 선택합니다. 데이터 규모가 기하급수적으로 커져도 일정한 한 자릿수 밀리초 속도를 완벽히 보장합니다.
Q4. 로그인 세션, 실시간 리더보드, 혹은 빈번히 조회되는 데이터의 캐싱이 목적인가?
➔ 고속 RAM 영역을 활용하는 인메모리 데이터베이스 Redis / ElastiCache를 선택하여 디스크 I/O 병목을 제거합니다.
Q5. 특정 비즈니스 기능(검색, 분석, 관계망, 시계열, AI)에 특화된 요건인가?
• 형태소 분석 및 전문 검색 기능 필요 ➔ OpenSearch
• 소셜 인맥, 친구 추천 엔진, GraphRAG AI 지식 맵 구축 ➔ Neo4j / Neptune (그래프 DB)
• IoT 센서 데이터, 주식 차트 등 시간 흐름에 따른 연속 대량 적재 ➔ InfluxDB / Timestream
• LLM 기반 유사도 검색 및 AI 임베딩 데이터 영구 보존 ➔ 벡터 DB (Pinecone, pgvector)
• 전사 대용량 빅데이터 통계 분석 및 BI 대시보드 구축 ➔ Redshift / BigQuery (데이터 웨어하우스)
각 DB를 외울 때 '이 DB는 어떤 상황에서 선택하나?'를 기준으로 기억하면 효과적입니다.
• '실시간 랭킹이 필요해' → Redis
• '유저의 친구 관계를 분석해야 해' → Neo4j / Neptune
• 'AI 문서 검색 시스템을 만들어야 해' → 벡터 DB + OpenSearch
• '데이터 구조가 계속 바뀌는 스타트업 프로젝트야' → MongoDB
'KT 에이블스쿨 9기 DX컨설턴트' 카테고리의 다른 글
| [Kt 에이블스쿨 9기 기자단] DX컨설턴트 10주차 후기 (0) | 2026.06.30 |
|---|---|
| [Kt 에이블스쿨 9기 기자단] DX컨설턴트 9주차 후기 (0) | 2026.06.30 |
| [Kt 에이블스쿨 9기 기자단] AWS 클라우드 인프라 용어 정리 (0) | 2026.06.30 |
| [Kt 에이블스쿨 9기 기자단] DX컨설턴트 8주차 후기 (0) | 2026.05.23 |
| [KT 에이블스쿨 9기 기자단] DX컨설턴트 7주차 후기 (0) | 2026.05.20 |