[기타] 스마트 데이터의 이해 및 활용 추가 + 면접/자기소개서 관련 메모

1. CTE(공통 테이블 표현식) vs VIEW

CTE(Common Table Expression)는 WITH로 정의하며 하나의 SQL 문을 실행하는 동안만 이름을 갖는 결과 집합이다. 복잡한 쿼리를 단계로 나누거나 재귀 처리가 필요할 때 사용한다.

VIEW는 CREATE VIEW로 DB에 저장하는 이름 있는 쿼리 정의다. 일반 VIEW는 결과 데이터를 별도로 저장하지 않고, VIEW를 참조할 때 정의된 쿼리를 실행한다. 반복해서 쓰는 조회 로직을 일관된 인터페이스로 제공하고, 복잡한 테이블 구조를 숨길 때 유용하다.

구분	CTE	VIEW
범위	현재 SQL 문 안	DB 스키마에 지속
정의 방식	WITH 이름 AS (...)	CREATE VIEW 이름 AS ...
대표 목적	쿼리 내부 단계 분리·재귀	반복 조회 로직 재사용·추상화
결과 저장	일반적으로 저장하지 않음	일반 VIEW는 저장하지 않음; 필요하면 Materialized View를 별도 검토

-- CTE: 현재 쿼리 안에서만 사용
WITH customer_sales AS (
    SELECT customer_id, SUM(amount) AS total_amount
    FROM orders
    GROUP BY customer_id
)
SELECT * FROM customer_sales WHERE total_amount >= 100000;

-- VIEW: 반복해서 사용할 조회 정의를 DB에 저장
CREATE VIEW customer_sales_view AS
SELECT customer_id, SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id;

 

성능은 CTE·VIEW라는 형식만으로 판단하지 않는다. 실제 데이터와 EXPLAIN (ANALYZE)로 확인한다. PostgreSQL 일반 VIEW는 참조할 때 쿼리를 실행한다는 점을 기억한다.

2. 인덱스 원리

• B-Tree: 대부분의 경우 쓰는 기본 인덱스. 동등 비교·범위 비교·정렬에 폭넓게 대응한다.
• Hash 인덱스: 동등 비교(=)에 사용한다.
• Composite 인덱스: 다중 컬럼 인덱스이며, 컬럼 순서가 중요하다. 어떤 조건으로 먼저 행을 줄이는지를 기준으로 순서를 정한다.
• 집계 성능 처리: COUNT·SUM·AVG보다 집계 전에 얼마나 행을 줄였는지, 통계와 실행 계획이 적절한지가 중요하다.

인덱스는 조회를 빠르게 하지만 데이터 변경 때 갱신 비용이 든다. 따라서 컬럼마다 만들기보다 실제 WHERE·JOIN·ORDER BY·GROUP BY 패턴을 보고 설계한다.

3. WHERE vs HAVING

SELECT 시 둘 다 조건을 처리하지만 대상과 시점이 다르다.

FROM / JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

• WHERE: 그룹화 전의 개별 행을 먼저 줄인다.
• HAVING: 그룹화 뒤의 그룹·집계 결과를 거른다.

SELECT customer_id, COUNT(*) AS order_count
FROM orders
WHERE status = 'PAID'
GROUP BY customer_id
HAVING COUNT(*) >= 3;

가능한 조건은 WHERE에서 먼저 처리해 집계 대상 행을 줄이고, 집계값 조건은 HAVING에서 처리한다.

→ 실무에서는 SELECT *는 절대 사용을 안함

필요한 컬럼을 명시하면 읽는 데이터 양과 네트워크 전송량을 줄일 수 있고, 같은 이름의 컬럼 충돌도 피할 수 있다. 또한 테이블에 컬럼이 추가돼도 API·리포트 결과가 의도치 않게 바뀌지 않아 조회 계약이 더 명확해진다.

-- 지양: 필요한 범위가 드러나지 않음
SELECT * FROM orders;

-- 권장: 사용하는 컬럼과 의미를 명시
SELECT order_id, customer_id, status, created_at
FROM orders;

4. 쿼리 호환 매핑

PostgreSQL / SQL Server / Oracle / MySQL은 같은 업무 의미의 SQL을 작성하더라도 문법·함수·자료형이 달라질 수 있다. 쿼리 호환 매핑은 DBMS를 옮기거나 함께 사용할 때 이 차이를 대응시키는 작업이다.

기능	PostgreSQL·MySQL 계열 예	SQL Server 예	Oracle 예
행 제한	LIMIT 10	TOP (10) 또는 OFFSET … FETCH	FETCH FIRST 10 ROWS ONLY
문자열 연결	CONCAT() 또는 `		`
자동 증가	GENERATED ... AS IDENTITY	IDENTITY	IDENTITY 또는 Sequence
UPSERT	INSERT ... ON CONFLICT	MERGE 등	MERGE

 

문법 치환 뒤에는 NULL 처리, 날짜·시간대, 문자열 정렬, 함수 반환값까지 테스트한다. 아래의 실행 계획·성능 관점은 호환성 확인과 별도로 각 DBMS에서 검증한다.

얼마나 많은 행을 읽는가?
→ 어떤 접근 경로를 선택했는가?
→ Join·Sort·Aggregate 중 어디가 비싼가?
→ 추정 행 수와 실제 행 수가 왜 다른가?
→ 쿼리·통계·인덱스 중 무엇을 조정할 것인가?

 

DBMS	대표 확인 도구
PostgreSQL	EXPLAIN, EXPLAIN ANALYZE
SQL Server	Actual Execution Plan
Oracle	EXPLAIN PLAN, DBMS_XPLAN
MySQL	EXPLAIN, EXPLAIN ANALYZE

5. 실행 계획(EXPLAIN)

EXPLAIN은 DBMS가 SQL을 실행하기 위해 선택한 물리적 실행 계획을 보여 준다.

EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM orders
WHERE tenant_id = 10
  AND created_at >= DATE '2026-07-01';

 

읽을 때는 Scan 방식, Join·Sort·Aggregate, 추정 행 수와 실제 행 수의 차이, 인덱스 추가 전후 변화를 확인한다. Seq Scan은 테이블이 작거나 대부분의 행을 읽어야 할 때 합리적일 수 있으므로, 무조건 나쁜 결과로 판단하지 않는다.

→ 실행 계획대로 테스트 후에는 무조건 ROLLBACK을 진행

 

EXPLAIN만 사용하면 계획만 보여 주지만, EXPLAIN ANALYZE는 쿼리를 실제로 실행한다. 따라서 INSERT·UPDATE·DELETE를 EXPLAIN ANALYZE로 확인할 때는 트랜잭션 안에서 실행한 뒤 ROLLBACK으로 되돌린다.

BEGIN;

EXPLAIN (ANALYZE, BUFFERS)
UPDATE orders
SET status = 'PROCESSED'
WHERE order_id = 123;

ROLLBACK; -- 실행 계획·실제 시간은 확인하되 데이터 변경은 남기지 않음

6. 제안 요청서(RFP)

제안 요청서(RFP)는 해결할 문제, 범위, 요구사항, 제약, 평가 기준, 제출물을 정리한 문서다.

문제 배경 → 목표와 성공 기준 → 요구사항·범위 → 제약 조건 → 제안·PoC → 평가·검증

기술을 먼저 고르기보다, 요구사항을 사용자·업무 흐름·데이터·성공 기준으로 나눠 읽는다. 그래야 제안한 기능과 평가 기준이 연결된다.

→ 보통 기술평가점수(80%) + 가격평가(20%)로 사용

 

기술 평가와 가격 평가의 비중은 제안 요청서·입찰 방식마다 달라질 수 있으므로, 실제 지원·제안에서는 해당 공고의 평가표와 배점 기준을 최우선으로 확인한다. 기술 평가에서는 문제 이해, 수행 전략, 유사 경험, 인력·일정·보안·운영 계획, PoC의 실현 가능성 등이 평가 대상이 될 수 있다. 가격 평가는 비용 자체만이 아니라 요구 범위를 충족하는 비용 구조인지 함께 본다.

인덱스 최적화

인덱스 최적화는 인덱스를 많이 만드는 작업이 아니라, 서비스가 자주 실행하는 쿼리를 적은 비용으로 처리하게 하는 일이다.

실제 느린 쿼리 확인
→ 조건·정렬·조인·집계 패턴 확인
→ 필요한 인덱스 후보 설계
→ EXPLAIN으로 실제 선택 확인
→ 읽기 성능 이득과 쓰기·저장 비용 비교

논리 아키텍처

논리 아키텍처는 특정 DB나 도구 이름보다, 데이터가 어디서 생기고 어떤 역할을 거쳐 누가 어떤 판단에 쓰는지를 정리하는 큰 틀이다. 물리 아키텍처가 PostgreSQL·Kafka·Airflow 같은 구현 기술을 정한다면, 논리 아키텍처는 각 계층의 책임과 데이터 흐름을 정한다.

1. Table Source / Source System

업무 사실이 최초로 기록되는 원천 시스템이다. 회원, 주문, 결제, 재고, 상담, 앱 로그처럼 서비스가 실제로 동작하며 생긴 데이터가 여기에 있다.

핵심은 “분석용으로 무엇을 볼까?”보다 먼저 어떤 업무 사건을 원천에서 정확히 남길 것인가다. 원천 데이터가 누락되거나 의미가 모호하면 이후 Pipeline·DW·대시보드도 신뢰할 수 없다.

2. Data Pipeline → DW Area → 대시보드, 보고서, 분석 영역

Data Pipeline
  → 여러 원천 데이터를 수집·검증·정제·변환·적재

DW Area
  → 여러 시스템·기간의 데이터를 공통 기준으로 통합

대시보드·보고서·분석 영역
  → 현재 상태·추세·이상 징후를 역할별로 확인하고, 조회·보고·분석에 활용

의사결정
  → 담당자가 우선순위·운영 조치·실험·개선 행동을 선택

이 흐름의 목적은 데이터를 옮기는 데 있지 않다. 원천의 업무 사실을 신뢰 가능한 판단 근거로 바꾸고, 실제 행동으로 연결하는 것이 목적이다.

• Pipeline에서는 중복·누락·지연·형식 문제를 관리한다.
  → Source System로 수집된 데이터를 전처리 및 가공함
• DW Area에서는 고객·상품·날짜·상태 같은 공통 기준과 이력을 통합한다.
  → 전처리 및 가공된 데이터를 비슷한 공통 기준으로 통합
• 대시보드에서는 역할별로 필요한 지표를 이해 가능한 형태로 제공한다.
  → 공통 기준으로 통합된 것을 보고 분석 및 보고서를 작성
• 의사결정에서는 지표를 보고 실제 조치가 일어나야 한다.
  → 위의 자료로 의사결정

3. 데이터 활용 → 통합 포털 시스템

통합 포털 시스템은 DW의 정제 데이터를 업무 담당자가 한 곳에서 활용하도록 연결하는 계층이다.

DW Area(데이터 활용)
→ 통합 포털 시스템
  → 역할별 대시보드·검색·알림·리포트
    → 담당자 확인
      → 실제 업무 처리와 의사결정

통합 포털은 단순히 차트를 모아 두는 화면이 아니다. 누가, 어느 시점에, 어떤 정보를 보고, 다음으로 어떤 행동을 해야 하는지를 연결해야 한다. 의사결정 결과는 다시 Source System에 기록되어 다음 데이터와 판단을 개선한다.

---

ETC (면접)

자기소개서 1

• 자기소개서에 의사결정 기법 관련 내용을 적으면, 면접에서 상세하게 어떤 기업과 트레이드오프등을 고민해서 했는지 등을 물어볼 수 있음
• 자기소개서에 적은 항목들에 대해서 고민을 해보는 것이 좋다.

상황 → 비교한 대안 → 선택 기준·근거 → 결정 → 실행·검증 → 회고

제한된 시간·정보·자원 안에서 무엇을 우선순위로 두었는지, 그 결정이 효과가 있었는지 어떻게 검증했는지를 말할 수 있어야 한다.

자기소개서 2

• 특정 기술을 사용해 보았다면, 기술에 대해서 어떻게든 써봤다라는 티를 자기소개소에 넣는것이 좋다.
• 면접관들이 “경험해봤네?”라고 생각을 한후, 그에 대한 면접 질문을 함

비전공자들에게 조언

• 면접에서 전공이 다른데 왜 AX를 지원했는지에 대한 생각을 물어볼 수 있음
• 자신의 전공에 대한 확장으로 ~~~ 처럼 풀어서 생각해보자

AX 엔지니어의 시작?

• 각 도메인별로 어떻게 AX를 적용할지 고민
• AI 기능을 먼저 붙이기보다, 업무에서 반복·지연·오류가 생기는 장면과 그때 필요한 데이터·문서·규칙을 먼저 찾는다.

도메인 업무 이해
→ 병목·반복·오류 장면 찾기
→ 데이터·문서·규칙 확인
→ 필요한 AI 활용 방식 선택
→ 사람 검토·권한·예외 처리 설계
→ 처리 시간·오류율·사용률·결과 품질로 검증

Career Path : 좁고 깊게 vs 넓고 얇게

• 전체적인 흐름 구조를 알아야, 그 중에서 어떤 것이 관심이 있는지, 더 흥미가 가는지를 발견하게됨
• 특정 분야에 대해 깊게 학습하고, 나아가기 위해서는 전체적인 논리 아키텍처에 전반에 대한 어느정도의 지식이 필요하다
• 즉, 현재에는 넓은 범위를 먼저 학습하는 것을 목표로 하자