문제설명

• 문제 링크: LeetCode 1527
• 요구사항: 질병 코드가 DIAB1으로 시작하는(접두사) 제1형 당뇨병 환자 찾기

📝 나의 풀이 및 고민했던 점

초기에는 단순히 특정 문자열 포함 여부만 확인하면 된다고 생각해 정규표현식(REGEXP 'DIAB1')을 사용했다. 하지만 문제의 조건은 명확히 '접두사(prefix)'였다. 정규식을 단순하게 작성하니 DIAB1이 단어 중간에 포함된 예외 케이스(예: SADIAB100)까지 잡아내는 논리적 오류가 발생한다는 것을 깨달았다.

💡 다른 접근법 및 배운 점

1. LIKE 연산자 사용 (실무 표준 ⭐️) 굳이 복잡한 정규표현식을 쓸 필요 없이, 실무에서 가장 권장하는 LIKE 연산자를 활용하는 것이 정석이었다. % 와일드카드를 사용한 검색은 데이터베이스의 인덱스를 탈 수 있어 성능(검색 속도) 면에서도 훨씬 유리하다.

# Write your MySQL query statement below

SELECT 
    patient_id,
    patient_name,
    conditions
FROM Patients

-- LIKE 연산자를 활용
WHERE conditions LIKE 'DIAB1%' 
   OR conditions LIKE '% DIAB1%';
-- REGEXP 연산자를 활용
-- WHERE conditions REGEXP '^(DIAB1| DIAB1)'

2. 정규표현식(REGEXP) 보완

만약 정규표현식을 끝까지 활용한다면, 문자열의 시작을 알리는 기호(^)와 파이프(|)를 사용하여 WHERE conditions REGEXP '^DIAB1| DIAB1' 형태로 고도화할 수 있다는 것도 새롭게 알게 되었다.

1581. Customer Who Visited but Did Not Make Any Transactions

문제설명

• 문제 링크: LeetCode 1581
• 요구사항: 쇼핑몰에 방문은 했지만, 결제는 한 번도 하지 않은 고객의 ID와 그 횟수 구하기

📝 나의 풀이 및 고민했던 점

데이터의 차집합(Anti-Join)을 구하는 문제라 판단해, LEFT JOIN을 걸고 오른쪽 테이블의 결제 내역이 없는 값을 WHERE t.visit_id IS NULL로 찾아내도록 쿼리를 짰다. 결과는 정확했지만, 쿼리 작성 중 습관적으로 SELECT DISTINCT를 사용한 것이 아쉬웠다. GROUP BY를 쓰면 이미 고유하게 그룹화가 이루어지며 중복이 제거되는데, 여기에 DISTINCT까지 추가하면 데이터베이스가 불필요한 중복 제거 연산을 한 번 더 수행하게 되어 성능이 저하된다.

💡 다른 접근법 및 배운 점

NOT EXISTS 활용 (대용량 데이터 최적화 ⭐️) 내가 작성한 LEFT JOIN + IS NULL 방식도 훌륭한 기법이지만, 실무나 대용량 데이터 환경에서는 NOT EXISTS를 활용하는 것이 성능 면에서 가장 우수하다고 한다. 서브쿼리를 사용하는 NOT IN 방식은 서브쿼리 내에 NULL이 포함되거나 데이터가 많아질 경우 연산 속도가 크게 떨어질 위험이 있어 지양해야겠다.

SELECT
    DISTINCT v.customer_id,
    COUNT(v.customer_id) as count_no_trans

FROM Visits v
LEFT JOIN Transactions t
ON t.visit_id = v.visit_id

-- v.visit_id가 T.visit_id에 포함되지 않는 조건
WHERE t.visit_id IS NULL
-- WHERE v.visit_id NOT IN (
--     SELECT visit_id
--     FROM Transactions
-- )

GROUP BY v.customer_id

NOT EXIST를 활용한 방법

SELECT 
    v.customer_id, 
    COUNT(v.customer_id) AS count_no_trans
FROM Visits v
WHERE NOT EXISTS (
    SELECT 1 
    FROM Transactions t 
    WHERE t.visit_id = v.visit_id
)
GROUP BY v.customer_id;

1587. Bank Account Summary II

문제설명

• 문제 링크: LeetCode 1587
• 요구사항: 모든 거래를 합산한 잔액이 10,000을 초과하는 유저의 이름과 잔액 출력

📝 나의 풀이 및 고민했던 점

JOIN으로 두 테이블을 결합하고, SUM 함수로 잔액을 계산한 뒤 GROUP BY로 계좌를 묶었다. 그리고 마지막에 HAVING 절로 10000 초과 조건을 걸어 문제를 통과했다. 이 문제를 풀며 WHERE와 HAVING의 차이를 머릿속으로 확실하게 정리할 수 있었다. WHERE는 데이터 그룹화 이전 개별 행에 대한 필터링이고, HAVING은 그룹화 및 계산이 끝난 요약 결과값에 대한 필터링이다.

💡 다른 접근법 및 배운 점

내가 작성한 방식이 이 문제의 가장 깔끔한 정답이었다. 특히 MySQL 환경에서는 표준 SQL과 다르게 편의상 HAVING 절에 SELECT에서 선언한 별칭(Alias, balance)을 바로 가져다 쓸 수 있어 쿼리의 가독성을 크게 높일 수 있었다.

SELECT 
    u.name,
    SUM(t.amount) as balance

FROM Users u
JOIN Transactions t
ON u.account = t.account

GROUP BY t.account
HAVING balance > 10000

1633. Percentage of Users Attended a Contest

문제설명

• 문제 링크: LeetCode 1633
• 요구사항: 각 대회별 유저 등록 비율을 소수점 둘째 자리까지 구하기

📝 나의 풀이 및 고민했던 점

초기에는 두 테이블을 단순히 JOIN한 뒤, COUNT(r.user_id) / COUNT(u.user_id)를 하면 분자와 분모가 알맞게 계산될 것이라 생각했다. 하지만 큰 착각이었다. 두 테이블을 INNER JOIN하게 되면, 이미 '해당 대회에 등록한 유저'들만의 교집합이 만들어진다. 결국 분자와 분모의 숫자가 동일해져 모든 대회의 등록 비율이 100%가 나오는 논리 오류를 범했다. 게다가 기준을 묶어주는 GROUP BY 구문마저 누락했었다.

💡 다른 접근법 및 배운 점

스칼라 서브쿼리 (Scalar Subquery) 활용 ⭐️ 애초에 무거운 JOIN 연산을 사용할 필요가 없는 문제였다. SELECT 절 내부에 (SELECT COUNT(*) FROM Users)와 같이 스칼라 서브쿼리를 작성하면, 데이터베이스가 전체 유저 수를 고정된 상수 값으로 뱉어준다. 분모를 정확하게 고정하는 매우 유용한 테크닉을 배웠다.

SELECT 
    contest_id,
    ROUND(COUNT(user_id) / (SELECT COUNT(*) FROM Users) * 100, 2) AS percentage

FROM Register

GROUP BY contest_id

ORDER BY 
    percentage DESC, 
    contest_id ASC;

1661. Average Time of Process per Machine

문제설명

• 문제 링크: LeetCode 1661
• 요구사항: 각 기계별 프로세스의 평균 처리 시간(end - start) 구하기

📝 나의 풀이 및 고민했던 점

activity_type이 start인 경우와 end인 경우를 WITH 구문(CTE)을 사용해 각각 별개의 가상 테이블로 분리하려는 논리로 접근했다. 하지만 이렇게 쪼갠 두 테이블을 다시 어떤 조건으로 JOIN 해야 동일한 프로세스로 정확하게 묶이는지, 연결고리를 설정하는 구문 작성이 헷갈렸다.

# Write your MySQL query statement below
-- activity type이 start인 table
WITH start_activity AS (
    SELECT machine_id, process_id, timestamp AS start_time
    FROM Activity
    WHERE activity_type = 'start'
),

-- activity type이 end인 table
end_activity AS (
    SELECT machine_id, process_id, timestamp AS end_time
    FROM Activity
    WHERE activity_type = 'end'
)

SELECT 
    s.machine_id,
    ROUND(AVG(e.end_time - s.start_time), 3) AS processing_time
FROM start_activity s
JOIN end_activity e 
  ON s.machine_id = e.machine_id 
  AND s.process_id = e.process_id
GROUP BY s.machine_id;

💡 다른 접근법 및 배운 점

Self JOIN 활용 (코드 단축 ⭐️) 굳이 WITH 구문으로 테이블을 명시적으로 분리할 필요 없이, 원본 테이블을 두 번 불러와(a1, a2) 조인 조건에서 바로 start와 end의 역할을 부여하는 Self JOIN 방식이 훨씬 간결하고 직관적이었다. 동일한 기계(machine_id)와 프로세스(process_id)를 기준으로 묶어주니 직관적으로 평균을 계산할 수 있었다.

SELECT 
    a1.machine_id,
    ROUND(AVG(a2.timestamp - a1.timestamp), 3) AS processing_time
FROM Activity a1
JOIN Activity a2 
  ON a1.machine_id = a2.machine_id 
  AND a1.process_id = a2.process_id
  AND a1.activity_type = 'start' 
  AND a2.activity_type = 'end'
GROUP BY a1.machine_id;

추가로, JOIN 없이 수학적인 원리를 이용해 CASE WHEN 절로 end 시간은 더하고 start 시간은 빼서 테이블을 단 한 번만 스캔하는 최적화 기법도 존재한다는 것을 알게 되었다. 추후 대용량 데이터를 처리할 때 꼭 적용해 봐야겠다.

문제설명

Write a solution to show the unique ID of each user, If a user does not have a 
unique ID replace just show null. Return the result table in any order.

두 테이블을 LEFT JOIN을 진행하면 되는 간단한 문제였다.

SELECT 
    uni.unique_id, 
    e.name
FROM Employees e
LEFT JOIN EmployeeUNI uni
ON e.id = uni.id

1407. Top Travellers

문제설명

Write a solution to report the distance traveled by each user.
Return the result table ordered by travelled_distance in descending order, 
if two or more users traveled the same distance, order them by their name in 
ascending order.

각 유저(Users)별로 차량 탑승 기록(Rides)의 총 이동 거리를 구하는 문제이다.

SELECT 
    u.name,
    IFNULL(SUM(r.distance), 0) AS travelled_distance
FROM 
    Users u
LEFT JOIN 
    Rides r ON u.id = r.user_id
GROUP BY 
    u.id
ORDER BY 
    travelled_distance DESC, 
    u.name ASC;

오늘의 핵심 개념: IFNULL vs COALESCE

위 1407번 문제에서 탑승 기록이 없어 distance 합계가 null이 되는 경우를 0으로 바꿔주기 위해 IFNULL을 사용했다. 다른 분들의 풀이를 보니 COALESCE를 많이 사용하길래, 두 함수의 차이점을 정리했다.

요약 및 적용

• 단순 대체 (IFNULL): 지금처럼 단순히 값이 NULL일 때 0으로 바꾸는 등의 1차원적인 작업에서는 코드가 직관적인 IFNULL을 써도 무방하다.
• 다중 조건 & 호환성 (COALESCE) 만약 여러 컬럼을 순차적으로 확인해야 하거나(ex: 사내번호 -> 휴대폰번호 -> '없음' 순으로 데이터 추출), 향후 다양한 DB 환경을 고려한다면 표준 문법인 COALESCE를 사용하는 것이 더 좋은 습관이다.

SQL-- COALESCE 활용 예시 SELECT COALESCE(NULL, NULL, 10, 20); -- 결과: 10

1484. Group Sold Products By The Date

문제설명

Write a solution to find for each date the number of different products sold and 
their names. The sold products names for each date should be sorted lexicographically.
Return the result table ordered by sell_date.

날짜별로 판매된 상품들을 그룹화하고, 하나의 문자열로 묶어서 출력하는 문제이다.

트러블 슈팅: 기존 쿼리의 문제점 분석

제가 처음에 작성했던 오답 쿼리와 발생한 문제점은 다음과 같다.

[초기 쿼리]

SELECT 
    sell_date,
    COUNT(product) as num_sold,
    GROUP_CONCAT(product) as products
FROM Activities 
GROUP BY sell_date
ORDER BY 
    sell_date ASC,
    products ASC;

[문제점]

• 중복 값이 그대로 출력됨: 동일한 날짜에 'Mask'가 두 번 팔렸다면, num_sold도 1개가 더 카운트되고 products 문자열에도 'Mask'가 두 번 들어가게 된다.

• 문자열 내부 정렬 안 됨: 쿼리 맨 마지막에 있는 ORDER BY products ASC는 결과로 나온 행(Row) 전체의 순서를 정렬할 뿐, GROUP_CONCAT으로 묶인 단어들 내부의 순서(사전순)를 정렬해 주지 못한다.

해결 방법 및 정답 쿼리

이 문제를 해결하려면 COUNT()와 GROUP_CONCAT() 함수 내부에서 직접 DISTINCT와 ORDER BY를 사용해야 한다.

num_sold: COUNT(DISTINCT product)를 사용하여 중복을 제거한 고유 상품 개수만 센다.

products: GROUP_CONCAT(DISTINCT product ORDER BY product ASC)를 사용하여 결합하기 전에 미리 중복을 제거하고 사전순으로 정렬되도록 처리한다.

SELECT 
    sell_date,
    COUNT(DISTINCT product) AS num_sold,
    GROUP_CONCAT(DISTINCT product ORDER BY product ASC SEPARATOR ',') AS products
FROM 
    Activities
GROUP BY 
    sell_date
ORDER BY 
    sell_date ASC;

핵심 개념: GROUP_CONCAT 함수 파헤치기

MySQL에서 여러 행의 데이터를 하나의 문자열로 결합할 때 사용하는 굉장히 유용한 함수이다. 데이터를 요약해서 보여주어야 할 때 자주 활용된다.

1. 기본 문법

GROUP_CONCAT(
    [DISTINCT] 컬럼명
    [ORDER BY 정렬할_컬럼명 ASC/DESC]
    [SEPARATOR '구분자']
)

2. 주요 옵션 설명

• DISTINCT: 결합할 데이터 중 중복되는 값을 하나로 합쳐준다.

• ORDER BY: 문자열로 결합되기 전에 괄호 안에서 데이터들의 순서를 먼저 정렬한다. (전체 쿼리 끝에 쓰는 ORDER BY와는 적용 시점과 대상이 다르다!)

• SEPARATOR: 단어와 단어 사이를 이어줄 구분자를 지정한다.

• 기본값은 쉼표(,)*이다. 만약 띄어쓰기나 슬래시 등으로 연결하고 싶다면 SEPARATOR ' / ' 와 같이 지정할 수 있다.

3. 활용 예시 비교

만약 묶어줄 데이터가 [A, B, A, C] 순서로 존재한다고 가정.

• 기본 결합: GROUP_CONCAT(col) $\rightarrow$ "A,B,A,C"
• 중복 제거: GROUP_CONCAT(DISTINCT col) $\rightarrow$ "A,B,C"
• 중복 제거 & 역순 정렬: GROUP_CONCAT(DISTINCT col ORDER BY col DESC) $\rightarrow$ "C,B,A"
• 구분자 변경: GROUP_CONCAT(col SEPARATOR ' | ') $\rightarrow$ "A | B | A | C"

1517. Find Users With Valid E-Mails

문제설명

Write a solution to find the users who have valid emails.
A valid e-mail has a prefix name and a domain where:
The prefix name is a string that may contain letters (upper or lower case), digits, 
underscore '_', period '.', and/or dash '-'. The prefix name must start with a letter.
The domain is '@leetcode.com'. Return the result table in any order.

정규표현식(Regular Expression)을 활용하여 복잡한 문자열 조건을 필터링하는 문제이다. 정규식 문법뿐만 아니라, MySQL의 대소문자 구분(Case Sensitivity) 처리와 버전별 호환성 에러까지 해결해야 하는 꽤 까다롭고 배울 점이 많은 문제였다.

📌 문제 이해 및 정규표현식 설계

유효한 이메일인지 판별하기 위해 문제에서 제시한 규칙을 정규표현식 기호로 하나씩 치환했다

1. 무조건 문자로 시작 (대문자 or 소문자)
   • ^[a-zA-Z] : ^는 문자열의 시작을 의미한다.
2. @ 앞에는 문자, 숫자, 특수문자(_, ., -)만 허용
   • [a-zA-Z0-9_.-]* : 괄호 안의 문자들이 0개 이상(*) 올 수 있음을 의미한다.
3. 도메인은 무조건 @leetcode.com으로 끝날 것
   • @leetcode\\.com$ : 마침표(.)는 정규식에서 '아무 문자 1개'를 의미하므로, 진짜 마침표를 표현하기 위해 이스케이프(\\) 처리한다. $는 문자열의 끝을 의미한.

[완성된 기본 정규표현식] '^[a-zA-Z][a-zA-Z0-9_.-]*@leetcode\\.com$'

트러블 슈팅 1: 대소문자 구분의 함정

위에서 만든 정규표현식을 WHERE mail REGEXP 구문에 넣고 돌렸더니, winston@leetcode.COM 이라는 오답 데이터가 검색 결과에 포함되었다.

• 원인: MySQL의 REGEXP 연산자는 기본적으로 대소문자를 구분하지 않는다(Case-insensitive). 따라서 소문자로 @leetcode.com이라 적었어도 대문자인 COM까지 모두 유효하다고 판단한 것이다.
• 1차 해결 시도: 정규식에서 대소문자를 엄격하게 구분하도록 REGEXP 뒤에 BINARY 키워드를 추가하였다. (WHERE mail REGEXP BINARY '정규식')

트러블 슈팅 2: 문자열 셋(Character set) 충돌 에러

BINARY 키워드를 넣었더니 이번에는 아래와 같은 끔찍한 에러가 발생했습니다.

Character set 'utf8mb3_general_ci' cannot be used in conjunction with 'binary' in call to regexp_like.

• 원인: LeetCode의 테이블 컬럼은 대소문자를 무시하는 문자열 셋(utf8mb3_general_ci)을 사용 중인데, 쿼리에서는 바이트 단위로 비교하는 BINARY를 강제로 적용하려고 하니 MySQL 내부에서 충돌이 일어난 것이다.

최종 해결: REGEXP_LIKE 함수와 매칭 옵션

최신 MySQL 8.0 이상 환경에서는 이 문제를 아주 깔끔하게 해결할 수 있는 REGEXP_LIKE 전용 함수와 매칭 옵션을 제공한다.

• 문법: REGEXP_LIKE(컬럼명, '정규식', '매칭옵션')
• 매칭 옵션에 'c' (Case-sensitive)를 주면, 대소문자를 아주 엄격하게 구분하여 매칭해주고, 반대로 대소문자를 무시하고 싶다면 'i'를 사용한다.

💻 최종 정답 쿼리

```sql SELECT user_id, name, mail FROM Users WHERE REGEXP_LIKE(mail, '^[a-zA-Z][a-zA-Z0-9_.-]*@leetcode\.com$', 'c');

문제설명

Write a solution to find all the authors that viewed at least one of their own 
articles. Return the result table sorted by id in ascending order.

최소 1번 이상 author_id와 viewer_id가 같은 author_id 출력하는 문제이다.

SELECT DISTINCT author_id as id

FROM Views

WHERE author_id = viewer_id

ORDER BY 1 ASC;

1179. Reformat Department Table

문제 설명

Reformat the table such that there is a department id column and a revenue column 
for each month.    Return the result table in any order.

다음과 같은 Department table에서 id와 month 컬럼을 분리하여 테이블을 Reformat 하는 문제이다.

Input: Department table

Reformat 해야 하는 결과 형태는 다음과 같다.

Output:

(Month의 Value들은 다음과 같다. "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec")

첫 접근과 깨달음: "이런 노가다 문제였다니.. ^^"

처음 문제를 접했을 때는 세로로 긴 데이터를 가로로 펼쳐야 하길래, 당연히 복잡한 윈도우 함수나 내가 모르는 특별한 내장 함수가 있을 줄 알았다. 하지만 막상 파고들어 보니 생각보다 정직한(?) 노가다를 요구하는 문제였다.

이러한 작업을 데이터베이스 용어로 '피벗(Pivot)' 또는 '행-열 변환'이라고 부른다. 기계가 저장하기 좋은 형태(세로)를 사람이 보기 좋은 형태(가로)로 바꾸는 작업이다. Oracle이나 MS SQL 같은 곳에서는 PIVOT이라는 전용 함수를 지원하지만, 아쉽게도 MySQL에서는 이를 직접 구현해야 한다.

이를 위해 사용하는 핵심 기술이 바로 조건부 집계(Conditional Aggregation)다.

조건부 집계의 3요소

1. GROUP BY: 결과 테이블은 id별로 한 줄씩 나와야 하므로 id를 기준으로 묶어준다.
2. CASE WHEN (또는 IF): 각 월(Month)에 해당하는 컬럼(기둥)을 세우고, 해당 월일 때만 revenue를 가져오고 아니면 NULL을 주도록 조건을 건다.
3. SUM (또는 MAX): 그룹화된 여러 행 중에서 우리가 조건문으로 골라낸 특정 값을 단일 값으로 추출하기 위해 집계 함수로 감싸준다.

여기서 생기는 궁금증: "데이터가 아예 없는 월(Month)은 어떻게 될까?"

문제를 풀다 보면 한 가지 의문이 생긴다. *"예를 들어, 원본 데이터에 month가 'Dec'인 데이터가 아예 없더라도 12월 컬럼은 존재해야 하는데, 이건 어떻게 처리되는 거지?"*

결론부터 말하자면, 데이터가 없더라도 컬럼은 정상적으로 만들어지며 값은 NULL로 채워진다. 그 이유는 SQL의 실행 흐름에 있다.

1. 설계도는 SELECT 절이 결정한다: SQL은 원본 데이터 유무와 상관없이 SELECT 절에 작성한 컬럼 13개(id 1개 + 월 12개)를 무조건 결과 테이블의 기둥으로 세운다.
2. 모든 데이터가 ELSE null 처리됨: 12월 데이터가 원본에 단 한 줄도 없다면, CASE WHEN month = 'Dec' 조건을 만족하는 데이터가 없으므로 모든 행이 ELSE null에 걸려 null을 반환한다.
3. 집계 함수의 결과: GROUP BY로 묶인 상태에서 null들만 모아서 SUM()을 하게 되므로, 최종 결과도 자연스럽게 null이 된다.

코드 다이어트: CASE WHEN 대신 IF() 사용하기

처음에 작성했던 정석적인 CASE WHEN 쿼리는 다음과 같다.

# 정석적인 CASE WHEN 구문
SELECT 
    id,
    SUM(CASE WHEN month = 'Jan' THEN revenue ELSE NULL END) AS Jan_Revenue,
    SUM(CASE WHEN month = 'Feb' THEN revenue ELSE NULL END) AS Feb_Revenue,
    -- ... (12월까지 반복) ...
    SUM(CASE WHEN month = 'Dec' THEN revenue ELSE NULL END) AS Dec_Revenue
FROM 
    Department
GROUP BY 
    id;

틀린 코드는 아니지만 12달을 다 적으려니 코드가 너무 길어지고 가독성이 떨어진다. 어떻게 하면 더 줄일 수 있을까 찾아보니, MySQL 환경에서는 IF() 함수를 활용해 훨씬 간결하게 작성할 수 있었다.

IF(조건, 참일 때 값, 거짓일 때 값) 이 구조를 적용하여 코드를 리팩토링한 최종 정답은 다음과 같다.

최종 코드

SELECT 
    id,
    SUM(IF(month = 'Jan', revenue, null)) AS Jan_Revenue,
    SUM(IF(month = 'Feb', revenue, null)) AS Feb_Revenue,
    SUM(IF(month = 'Mar', revenue, null)) AS Mar_Revenue,
    SUM(IF(month = 'Apr', revenue, null)) AS Apr_Revenue,
    SUM(IF(month = 'May', revenue, null)) AS May_Revenue,
    SUM(IF(month = 'Jun', revenue, null)) AS Jun_Revenue,
    SUM(IF(month = 'Jul', revenue, null)) AS Jul_Revenue,
    SUM(IF(month = 'Aug', revenue, null)) AS Aug_Revenue,
    SUM(IF(month = 'Sep', revenue, null)) AS Sep_Revenue,
    SUM(IF(month = 'Oct', revenue, null)) AS Oct_Revenue,
    SUM(IF(month = 'Nov', revenue, null)) AS Nov_Revenue,
    SUM(IF(month = 'Dec', revenue, null)) AS Dec_Revenue
FROM 
    Department
GROUP BY 
    id;

처음엔 반복 작업이 귀찮게 느껴졌지만, 조건부 집계를 통해 데이터베이스가 어떤 원리로 피벗 테이블을 생성하는지 정확하게 이해할 수 있는 좋은 문제였다!

1211. Queries Quality and Percentage

문제설명

We define query quality as:
The average of the ratio between query rating and its position.
We also define poor query percentage as:
The percentage of all queries with rating less than 3.
Write a solution to find each query_name, the quality and poor_query_percentage.
Both quality and poor_query_percentage should be rounded to 2 decimal places.
Return the result table in any order.

데이터베이스 쿼리 실행 결과가 담긴 Queries 테이블이 주어지고, 이 데이터를 바탕으로 각 쿼리 이름(query_name)별로 다음 두 가지 지표를 구해야 한다.

1. Quality (품질): 쿼리 평점(rating)을 위치(position)로 나눈 값들의 평균
2. Poor Query Percentage (낮은 품질 비율): 평점이 3 미만인 쿼리의 백분율 (%)

두 값 모두 소수점 둘째 자리까지 반올림해야 하며, 순서 상관없이 출력합니다.

Input: Queries table

Output:

나의 첫 접근과 고민

처음 문제를 보고 핵심 로직은 바로 파악했다.

1. rating / position을 계산해야 한다.
2. query_name으로 GROUP BY를 묶어야 한다.

그래서 다음과 같이 쿼리를 짰는데, 집계 함수를 겹쳐 쓴 부분과 낮은 평점의 비율을 구하는 서브쿼리 부분에서 코드가 꼬이기 시작했다.

# ❌ 수정 전 초기 접근
SELECT 
    query_name,
    AVG(SUM(rating/position)) as quality
    -- (SELECT 
    --     quality/COUNT(rating)
    --     FROM q
    --     WHERE rating < quality)
    -- as poor_percentage
FROM Queries q
GROUP BY query_name;

핵심 요구사항은 잘 파악했지만, 문법적으로 아쉬운 부분들이 있었다. 이를 어떻게 개선할 수 있을까?

코드 리팩토링 & 핵심 포인트

1. quality 계산: AVG()와 SUM()은 겹쳐 쓸 필요가 없다!

AVG() 함수는 이미 내부에 '합계를 구한 뒤 개수로 나누는' 기능이 포함되어 있다. 따라서 각 행의 rating / position 값을 구한 뒤 바로 AVG()로 감싸주기만 하면 된다.

수정 전: AVG(SUM(rating / position))

수정 후: AVG(rating / position)

2. poor_query_percentage 계산: 서브쿼리 대신 IF() 활용하기 조건부 집계를 사용하면 서브쿼리 없이 한 줄로 끝낼 수 있다. 평점이 3 미만이면 1을, 아니면 0을 주도록 한 뒤 전체 개수로 나누면 된다.

수정: SUM(IF(rating < 3, 1, 0)) / COUNT(*) * 100

3. 소수점 둘째 자리 반올림: ROUND() 문제 조건에 맞게 계산된 값들을 ROUND(값, 2)로 감싸준다.

실무자들의 숏코딩 팁 (초강력 추천!)

위에서 SUM과 COUNT를 조합해서 퍼센트를 구했지만, MySQL에서는 이를 AVG()와 IF()를 결합하여 엄청나게 짧게 줄일 수 있는 마법 같은 팁이 있다.

ROUND(AVG(IF(rating < 3, 100, 0)), 2) AS poor_query_percentage

🤔 어떻게 이게 가능할까? IF(rating < 3, 100, 0) 로직을 통해 3점 미만이면 100, 아니면 0이라는 값을 준다. 예를 들어 위 문제의 'Dog'의 경우 점수가 5, 5, 1이므로 IF문을 거치면 0, 0, 100이 된다. 이 세 숫자의 평균(AVG)을 구하면 (0 + 0 + 100) / 3 = 33.33이 되어 자연스럽게 백분율(Percentage)이 계산된다!

실무에서도 비율이나 퍼센트를 구할 때 정말 자주 쓰이는 세련된 패턴이니 꼭 기억해두자.

최종 코드

SELECT 
    query_name,
    ROUND(AVG(rating / position), 2) AS quality,
    ROUND(AVG(IF(rating < 3, 100, 0)), 2) AS poor_query_percentage
FROM 
    Queries
WHERE 
    query_name IS NOT NULL
GROUP BY 
    query_name;

배운 점

집계 함수(AVG)의 특성을 정확히 이해하고 중복 사용을 피하자.

서브쿼리가 생각날 때, 조건부 집계(IF 또는 CASE WHEN)로 더 간단하게 해결할 수 있는지 먼저 고민해 보자.

AVG(IF(조건, 100, 0)) 패턴은 백분율을 구하는 치트키다!

1251. Average Selling Price (MySQL)

문제 설명

Write a solution to find the average selling price for each product. 
average_price should be rounded to 2 decimal places. 
If a product does not have any sold units, 
its average selling price is assumed to be 0.
Return the result table in any order.

제품의 가격 변동 이력이 담긴 Prices 테이블과, 제품 판매 기록이 담긴 UnitsSold 테이블이 주어지고, 이 두 테이블을 활용하여 각 제품별 평균 판매 가격(Average Selling Price)을 구해야 한다.

• 평균 판매 가격은 (해당 제품의 총 매출액) / (해당 제품의 총 판매 개수)로 계산합니다.
• 소수점 둘째 자리까지 반올림해야 합니다.
• 판매 기록이 없는 제품의 평균 가격은 0으로 처리해야 합니다.

Input: Prices table

Input: UnitsSold table

Output:

나의 첫 접근: "이게 왜 안 될까?"

가장 먼저 떠오른 생각은 product_id로 두 테이블을 조인하고, 총액을 구한 뒤 개수로 나누어 평균(AVG)을 내는 것이었다. 그래서 아래와 같이 쿼리를 작성했다.

# ❌ 초기 접근 쿼리
SELECT 
    p.product_id,
    ROUND(AVG(p.price * us.units / us.units), 2) as average_price
FROM Prices p 
JOIN UnitsSold us 
  ON p.product_id = us.product_id
GROUP BY p.product_id;

논리적으로 그럴싸해 보였지만, 결과는 오답이었다. 이 쿼리에는 데이터베이스의 작동 방식을 오해한 3가지 결정적인 함정이 숨어있었다.

코드 피드백 & 3가지 함정 탈출하기

함정 1. 평균 계산의 오류: (price * units) / units 가장 흔히 하는 수학적 실수다. p.price * us.units / us.units를 수식으로 보면, 곱한 units를 다시 units로 나누었기 때문에 결국 units는 약분되어 사라진다. 즉, 데이터베이스는 AVG(p.price)를 계산한 것과 완전히 똑같이 행동하게 되어 판매량(가중치)을 전혀 반영하지 못하는 단순 가격 평균을 내버린다.

해결책: '가중 평균'의 정확한 공식인 (총 매출액) / (총 판매 개수)를 SUM 함수를 이용해 명시적으로 적어주어야 한다.

수정: SUM(p.price * us.units) / SUM(us.units)

함정 2. 기간(Date) 조건 누락: 가격은 시간에 따라 변한다! 단순히 ON p.product_id = us.product_id만 조건으로 주면 대참사가 일어난다. 1번 상품의 경우 2월 가격(5달러)과 3월 가격(20달러)이라는 두 개의 데이터가 존재한다. 단순히 id만으로 조인하면, 2월 25일에 팔린 물건이 3월 가격표와도 억지로 짝지어지는 크로스 조인(Cross Join) 현상이 발생한다.

해결책: 물건이 판매된 날짜(purchase_date)가 가격표에 명시된 기간(start_date ~ end_date) 안에 있을 때만 조인해야 한다.

수정: ON p.product_id = us.product_id AND us.purchase_date BETWEEN p.start_date AND p.end_date

함정 3. 팔리지 않은 상품의 처리: INNER JOIN의 한계 문제 조건 중 "판매 기록이 없는 상품의 평균 가격은 0으로 간주한다." 라는 문장이 있다. 기본 JOIN (INNER JOIN)을 사용하면 한 번도 안 팔린 상품은 조인 과정에서 매칭되지 않아 결과 테이블에서 아예 증발해 버린다.

해결책: 가격표(Prices)를 기준으로 모두 살려두고 판매 기록을 갖다 붙이는 LEFT JOIN을 사용해야 한다. 그리고 판매 기록이 없어 평균값이 NULL로 나올 경우, IFNULL() 함수를 이용해 0으로 바꿔주어야 한다.

✨ 최종 정답 코드 위의 3가지 문제를 모두 수정한 깔끔한 정답 코드는 다음과 같다.

SELECT 
    p.product_id,
    IFNULL(ROUND(SUM(p.price * us.units) / SUM(us.units), 2), 0) AS average_price
FROM 
    Prices p
LEFT JOIN 
    UnitsSold us 
    ON p.product_id = us.product_id 
    AND us.purchase_date BETWEEN p.start_date AND p.end_date
GROUP BY 
    p.product_id;

배운 점 (Takeaways)

날짜 이력 데이터 조인 패턴: 가격이나 상태가 시간에 따라 변하는 이력(History) 테이블을 조인할 때는 ON A.id = B.id AND date BETWEEN start AND end 조건을 반드시 기억하자. 실무에서도 숨 쉬듯 사용하는 필수 패턴이다.

가중 평균의 정석: 수학적인 비례/가중 평균을 구할 때는 AVG() 함수에 의존하기보다, 분자와 분모를 각각 SUM()으로 구해서 직접 나누는 것이 데이터 오염을 막는 가장 확실하고 정확한 방법이다.

엣지 케이스 고려: 조인하기 전에 '데이터가 없는 경우(팔리지 않은 경우)'를 어떻게 처리할지 항상 고민하고 LEFT JOIN과 IFNULL을 적절히 활용하자.

문제 설명

Write a solution to swap all 'f' and 'm' values (i.e., change all 'f' values to 'm' and vice versa) with a single update statement and no intermediate temporary tables.

Note that you must write a single update statement, do not write any select statement for this problem.

sex가 'f'인 값을 'm'으로 변경하고, 'm'인 값은 'f'로 변경하는 문제입니다. SELECT가 아닌 UPDATE를 사용해야합니다.

UPDATE Salary
SET sex = CASE 
    WHEN sex = 'm' THEN 'f'
    ELSE 'm'
    END;

UPDATE는 처음 사용해봤기 때문에 내용을 좀 찾아 정리했습니다.

기본문법구조

UPDATE 테이블명
SET 컬럼명1 = 변경할값1, 컬럼명2 = 변경할값2
WHERE 조건;

UPDATE를 활용할 때에는 WHERE구문을 잘 활용하는 것이 중요합니다. 실행 전, 먼저 SELECT * FROM 테이블명 WHERE 조건;을 실행 후 내가 수정하려는 대상이 정확히 의도한 데이터인지 확인하는 습관이 필요할 것 같습니다.

1050. Actors and Directors Who Cooperated At Least Three Times

문제설명

Write a solution to find all the pairs (actor_id, director_id) where the actor has cooperated with the director at least three times.

Return the result table in any order.

(actor_id, director_id) 쌍의 같이 작업한 횟수가 최소 3개 이상인 조합을 찾아내면 되는 문제입니다.

SELECT actor_id, director_id

FROM ActorDirector

GROUP BY actor_id, director_id

HAVING COUNT(*) >= 3

easy하게 풀 수 있는 문제였다.

1068. Product Sales Analysis I

문제설명

Write a solution to report the product_name, year, and price for each sale_id in the Sales table.

Return the resulting table in any order.

두 테이블을 JOIN해서 해당하는 컬럼들을 추출하는 문제입니다.

SELECT 
    p.product_name,
    s.year,
    s.price
FROM Sales s
JOIN Product p
ON s.product_id = p.product_id

이정도는 너무 easy합니다

1075. Project Employees I

문제설명

Write an SQL query that reports the average experience years of all the employees for each project, rounded to 2 digits.

Return the result table in any order.

프로젝트 별로 참여한 employee들의 experience years의 평균을 소수점 둘째자리까지 나타내는 문제입니다.

-- 프로젝트 별 참여한 근로자들의 평균 경험 연도 추출
SELECT 
    p.project_id,
    ROUND(AVG(experience_years), 2) as average_years
FROM Project p 
LEFT JOIN Employee e
ON p.employee_id = e.employee_id

GROUP BY p.project_id

일단 문제에서 ~별로 이런게 나오면 GROUPBY를 활용한다. 처음에는 SUM(e.experience_years)/COUNT(e.experience_years)를 사용했지만 AVG 함수가 있었지.. 아직도 효율적으로, 빠르게 생각이 안나는걸 보니 SQL 연습 아직 멀었다!!!! 아직은 Easy 난이도의 문제만 풀고 있지만 Median, Hard까지 열심히 가보자. 🔥🔥

1084. Sales Analysis III

문제설명

Write a solution to report the products that were only sold in the first quarter of 2019. That is, between 2019-01-01 and 2019-03-31 inclusive.

Return the result table in any order.

1분기에만 팔린 product_id와 product_name을 추출하는 문제입니다. 처음에 작성한 쿼리는 다음과 같습니다.

SELECT 
    p.product_id,
    p.product_name
FROM Sales s
JOIN Product p
ON s.product_id = p.product_id

WHERE DATE(s.sale_date) BETWEEN DATE('2019-01-01') AND DATE('2019-03-31')+1
GROUP BY s.product_id
HAVING COUNT(s.product_id) = 1

[내가 겪은 문제점]

처음에는 WHERE 절을 사용해 2019년 1분기(1월~3월) 데이터만 필터링한 뒤, COUNT()를 이용해 판별하려고 했습니다. 하지만 이 방식은 치명적인 논리적 오류를 가지고 있었습니다.

[원인 분석: SQL 실행 순서] SQL은 FROM → WHERE → GROUP BY → HAVING 순서로 실행됩니다. 만약 어떤 상품(product_id = 2)이 2월(1분기)과 6월(2분기)에 모두 팔렸다면, WHERE 절에서 6월 판매 기록이 먼저 삭제(필터링)되어 버립니다. 그 결과, GROUP BY 단계로 넘어갈 때는 2월 판매 기록만 남게 되고, HAVING COUNT() = 1이라는 조건마저 통과해버려서 1분기에만 팔린 상품으로 잘못 분류되는 문제가 발생한 것입니다.

해결 방법: HAVING 절과 MIN/MAX의 활용 (정답 접근법)

WHERE 절에서 미리 데이터를 잘라내면 안 됩니다. 상품의 전체 판매 이력을 온전히 유지한 채로 그룹화(GROUP BY)를 진행해야 해당 상품이 언제 팔렸는지 정확히 검증할 수 있습니다.

[MIN과 MAX를 이용한 논리]

그룹화된 전체 데이터에서 조건 검사를 하기 위해 HAVING 절을 사용했습니다. 어떤 상품이 '오직 1분기에만' 팔렸다는 것을 증명하려면 다음 두 가지 조건이 모두 만족해야 합니다.

MIN(sale_date) >= '2019-01-01': 해당 상품의 가장 첫 판매일이 1월 1일 이후여야 한다. (이전 년도 판매 방지)

MAX(sale_date) <= '2019-03-31': 해당 상품의 가장 마지막 판매일이 3월 31일 이전이어야 한다. (2분기 이후 판매 방지)

문제설명

Write a solution to report the name and bonus amount of each employee who satisfies either of the following:

• The employee has a bonus less than 1000.
• The employee did not get any bonus.

Return the result table in any order.

두가지 조건을 만족하는 employee를 추출하는 문제이다.

1. 보너스가 1000보다 이하인 employee
2. 보너스를 받지 않은 employee 

LEFT JOIN을 활용하면 쉽게 풀 수 있는 문제였다!

 # Write your MySQL query statement below
SELECT e.name, b.bonus
FROM Employee e
LEFT JOIN Bonus b 
ON e.empId = b.empId
WHERE b.bonus < 1000 
OR b.bonus IS NULL;

595. Big Countries

문제설명

A country is big if:

it has an area of at least three million (i.e., 3000000 km2), or it has a population of at least twenty-five million (i.e., 25000000). Write a solution to find the name, population, and area of the big countries.

Return the result table in any order.

해당 조건을 만족하는 나라를 출력하는 되는 문제이다.

SELECT name, population, area

FROM World

WHERE area >= 3000000
    OR population >= 25000000

WHERE절에 해당 조건을 넣어주기만 하면 되기 때문에 쉽게 풀 수 있었다.

607. Sales Person

문제 설명

Write a solution to find the names of all the salespersons who did not have any orders related to the company with the name "RED".

Return the result table in any order.

The result format is in the following example.

SalesPerson Company Orders 3개의 테이블이 주어져서 어떻게 해결해야할까 고민을 많이 했다. 처음에는 SalesPerson Orders 두개의 테이블을 이용해서 WHERE o.com_id != 1 조건을 사용했지만 이건 "RED 회사와 거래한 적이 있는 사람 전체를 제외해야 하는데, RED 회사와 거래한 '개별 주문 건'만 제외하기 때문"에 원하는 방식이다.

RED 회사와 거래한 sales_id 목록"을 먼저 구한 뒤, 그 목록에 포함되지 않은 사람만 뽑는 방식을 사용했다.

# Write your MySQL query statement below
# "RED 회사와 거래한 sales_id 목록"을 먼저 구한 뒤, 그 목록에 포함되지 않은 사람만 뽑는 방식

SELECT name

FROM SalesPerson

WHERE sales_id NOT IN (
    SELECT o.sales_id
    FROM Company c
    JOIN Orders o
    ON c.com_id = o.com_id
    WHERE c.name = 'RED'
)

610. Triangle Judgement

문제설명

Report for every three line segments whether they can form a triangle.

Return the result table in any order.

삼각형을 만들기 위한 조건이 제일 어려웠던 문제였다.. 생각 안나.. 🤦🏻‍♂️

삼각형 결정 조건(Triangle Inequality Theorem) 이 정리에 따르면, 세 변 중 어떤 두 변의 길이를 더해도 나머지 한 변의 길이보다 항상 커야 한다. 즉, $x, y, z$가 삼각형을 이루려면 다음 세 가지 조건을 모두 만족

• $x + y > z$
• $x + z > y$
• $y + z > x$

SELECT x, y, z,
    CASE 
        WHEN (x+y > z) AND (x+z > y) AND (y+z > x) THEN 'Yes'
        ELSE 'No'    
        END AS triangle

FROM Triangle

619. Biggest Single Number

문제설명

A single number is a number that appeared only once in the MyNumbers table.

Find the largest single number. If there is no single number, report null.

SELECT MAX(num) AS num
FROM (
    SELECT num
    FROM MyNumbers
    GROUP BY num
    HAVING COUNT(num) = 1
) AS single_nums;

집계함수는 NULL을 자동으로 반환한다!!

집계 함수의 결과값 동작

NULL이 나오는 것이 싫고, 데이터가 없으면 0이나 다른 기본값을 보여주고 싶다면 COALESCE(값, 대체값)을 활용한다. COALESCE(값, 대체값)은 첫 번째 값이 NULL이면 두 번째 값을 반환한다.

SELECT COALESCE(MAX(num), 0) AS num
FROM (
    SELECT num
    FROM MyNumbers
    GROUP BY num
    HAVING COUNT(num) = 1
) AS single_numbers;

문제설명

주어진 Person 테이블은 id와 email 두개의 컬럼을 갖고 있다. 중복으로 갖고 있는 email을 DISTINCT하도록 추출하는 것이다.

SELECT DISTINCT email

FROM Person

GROUP BY email

HAVING COUNT(1) >= 2

따라서 email을 GROUPBY를 진행하여 COUNT가 2개 이상인 것을 추출하였다. Runtime이 549ms로 어떻게 하면 더 줄일 수 있을까?

SELECT DISTINCT email

FROM Person

GROUP BY 1

HAVING COUNT(1) >= 2

다음과 같은 방법으로 Runtime을 줄일 수 있었다. 해당 방법은 정리 후 게시할 예정이다.

183. Customers Who Never Order

문제설명

Write a solution to find all customers who never order anything.

Return the result table in any order.

Customers와 Orders 두개의 테이블이 존재하고, Orders에 존재하는 customerId를 보유하지 않은 Customers테이블의 컬럼을 출력하는 것이다.

생각한 방법은 두가지이다.

첫번째 방법은 NOT IN을 활용하여, 주문 테이블에 있는 모든 고객 ID를 제외한 나머지 고객"을 찾는 방식이다!

SELECT name AS Customers
FROM Customers
WHERE id NOT IN (
    SELECT customerId 
    FROM Orders);

두번째 방법은 NOT EXISTS를 활용한 방법이다.

SELECT c.name AS Customers
FROM Customers c
WHERE NOT EXISTS (
    SELECT 1 
    FROM Orders o 
    WHERE o.customerId = c.id
);

근데 생각해보니 제일 쉽고 간단한 방법이 있었다..

SELECT c.name AS Customers
FROM Customers c
LEFT JOIN Orders o ON c.id = o.customerId
WHERE o.id IS NULL;

LEFT JOIN을 진행하면 대응되는 데이터가 없다면 Orders의 컬럼들은 NULL값을 갖게 된다. 이 때 WHERE절에 NULL인 것을 추출하는 조건을 넣어주면 끝.

196. Delete Duplicate Emails

문제 설명

Write a solution to delete all duplicate emails, keeping only one unique email with the smallest id.

For SQL users, please note that you are supposed to write a DELETE statement and not a SELECT one.

For Pandas users, please note that you are supposed to modify Person in place.

After running your script, the answer shown is the Person table. The driver will first compile and run your piece of code and then show the Person table. The final order of the Person table does not matter.

중복된 email을 삭제하고, 작은 id값을 가진 데이터만 남기는 문제. 처음에 SELECT 문을 하는데 왜 안되지 ..? 했는데 역시 문제를 꼼꼼히 읽지 않는 버릇은 중학생 때부터 고쳐지지 않는다.. 문제에 보면 SQL의 경우 SELECT 문이 아닌 DELETE 문을 사용하라고 적혀있다.

DELETE p1
FROM Person p1
JOIN Person p2
ON p1.email = p2.email
WHERE p1.id > p2.id -- -- 더 큰 ID 삭제

197. Rising Temperature

문제설명

Write a solution to find all dates' id with higher temperatures compared to its previous dates (yesterday).

Return the result table in any order.

잘못된 쿼리

SELECT w2.id as Id

FROM Weather w1
JOIN Weather w2
ON w1.id = w2.id

WHERE w2.id > w1.id 
    AND DATEDIFF(w2.recordDate, w1.recordDate) = 1 
    AND w2.temperature - w1.temperature > 0 

작성한 쿼리에서 문제점

1. 조인 조건(ON)의 문제: ON w1.id = w2.id라고 작성하면, w1과 w2가 같은 행(Row)을 가리키게 된다.

2. WHERE 절의 모순: w2.id > w1.id 조건이 붙어있는데, 위에서 이미 id가 같다고 설정했기 때문에 이 조건은 수학적으로 절대 만족할 수 없는 조건(x > x)이 된다. 그래서 결과가 나오지 않았던 것이다..

수정된 쿼리

SELECT w2.id
FROM Weather w1
JOIN Weather w2 
  ON DATEDIFF(w2.recordDate, w1.recordDate) = 1
WHERE w2.temperature > w1.temperature;

511. Game Play Analysis I

문제설명

Write a solution to find the first login date for each player.

Return the result table in any order.

SELECT player_id, MIN(event_date) AS first_login
FROM Activity
GROUP BY player_id;

위의 문제를 풀기 위해서는 단순히 첫 로그인 날짜만을 필요로 하기 때문에 MIN()을 사용하는 것이 효율적인 쿼리이다. 하지만 다른 세부적인 정보가 필요할 때에는 ROW_NUMBER()를 활용하는 것이 더욱 효율적이다.

** GROUP BY + MIN(): "요약"이 필요할 때 ** 이 방식은 ** "데이터를 압축" ** 하는 방식이다. 여러 개의 행을 하나의 행으로 뭉쳐서 통계 값을 뽑아낼 때 주로 사용합니다.

장점: 코드가 매우 짧고 직관적이다. 한계: '첫 로그인 날짜'는 알 수 있지만, 그날 어떤 기기(device_id)로 로그인했는지는 바로 알 수 없습니다. 만약 첫 로그인 날짜와 함께 그날의 기기 정보까지 가져오려면 다시 JOIN을 해야 하는 번거로움이 생긴다.

** ROW_NUMBER(): "상세 내역"이 필요할 때 ** 이 방식은 "전체 행을 유지하면서 순번만 매기는" 방식입니다. 데이터의 원형을 보존하고 싶을 때 사용합니다.

용도: 첫 로그인 날짜뿐만 아니라, "첫 로그인을 했을 때의 device_id나 games_played 정보도 함께 보고 싶을 때" 사용합니다.

장점: 첫 번째 행을 고른 뒤, 그 행의 나머지 데이터(기기 정보 등)를 그대로 가져올 수 있다.

"상위 3명", "날짜별 순위" 등 복잡한 조건(Top-N 문제)을 처리할 때 매우 강력!!

한계: GROUP BY보다는 문법이 조금 더 길고 복잡하다.

ROW_NUMBER() 를 활용한 쿼리

```sql SELECT player_id, event_date AS first_login FROM ( SELECT player_id, event_date, ROW_NUMBER() OVER(PARTITION BY player_id ORDER BY event_date ASC) as rn FROM Activity ) t WHERE rn = 1;

이전 글에서 ETL/ELT 기본 개념을 정리했다면, 이번엔 실무에서 반드시 마주치는 핵심 개념들을 다룹니다.

⚡ 1. Batch vs Streaming 파이프라인

Batch Processing

데이터를 일정 시간 동안 모아서 한꺼번에 처리하는 방식입니다. 스케줄에 따라 주기적으로 실행됩니다.

Source → [데이터 쌓임] → Batch Job 실행 (1시간/1일마다) → Target DW 적재

Stream Processing

데이터가 발생하는 즉시 연속적으로 처리하는 방식입니다.

Source → 이벤트 발생 → Stream Processor → 실시간 적재/알림

비교

🏗️ 2. Lambda / Kappa 아키텍처

Lambda 아키텍처

Batch와 Streaming을 병렬로 운영해 정확성과 실시간성을 동시에 확보하는 아키텍처입니다.

Data Source
    ├── Batch Layer    → Batch View   ─┐
    │   (Hadoop/Spark, 높은 정확도)    ├→ Serving Layer → 쿼리 응답
    └── Speed Layer   → Real-time View┘
        (Kafka/Flink, 낮은 지연)

• Batch Layer: 전체 데이터를 주기적으로 재처리. 정확하지만 느림.
• Speed Layer: 최근 데이터만 실시간 처리. 빠르지만 완전하지 않음.
• Serving Layer: 두 결과를 병합해 쿼리 응답.

⚠️ 단점: 두 레이어를 모두 유지해야 해서 복잡도가 높고, 같은 처리 로직을 두 번 작성해야 합니다.

Kappa 아키텍처

Lambda의 복잡성을 제거하고 스트리밍 단일 경로만 사용하는 아키텍처입니다.

Data Source
    → Append-only Event Log (Kafka)
    → Stream Processor (Flink / Spark Streaming)
    → Serving Layer

모든 데이터를 이벤트 로그로 영구 보관하고, 재처리가 필요할 때는 처음부터 다시 읽습니다.

✅ 장점: 아키텍처가 단순하고 운영이 쉬움. 단, 스트리밍 처리 기술에 대한 높은 역량이 필요합니다.

🔁 3. 멱등성 (Idempotency)과 재실행 가능한 파이프라인

멱등성이란 동일한 작업을 여러 번 실행해도 결과가 항상 동일한 성질입니다.

파이프라인 장애 후 재실행 시, 데이터 중복이나 오염 없이 안전하게 복구할 수 있어야 합니다.

멱등성이 없는 경우 vs 있는 경우

❌ 멱등성 없음:
  1회 실행 → 100행
  2회 실행 → 200행 (중복 누적!)
  3회 실행 → 300행 (집계 오류 발생)

✅ 멱등성 있음:
  1회 실행 → 100행
  2회 실행 → 100행 (동일)
  3회 실행 → 100행 (동일)

멱등성 구현 핵심 패턴

📥 4. Incremental Load vs Full Refresh vs Backfill

Incremental Load (증분 적재)

마지막 실행 시점 이후 변경된 데이터만 추출해 적재합니다.

[1월 ✓] [2월 ✓] [3월 ✓] [4월 ✓] [5월 NEW →처리]

• ✅ 빠른 처리 속도, 리소스 효율적
• ⚠️ 소스에서 변경 감지 필요, 삭제된 레코드 처리 어려움

Full Refresh (전체 갱신)

매번 전체 데이터를 삭제하고 소스에서 전부 다시 적재합니다.

실행 1회차 → 전체 삭제 후 100% 재적재
실행 2회차 → 전체 삭제 후 100% 재적재
실행 3회차 → 전체 삭제 후 100% 재적재

• ✅ 구현이 단순, 데이터 일관성 보장
• ⚠️ 처리 시간·비용 증가, 대용량 테이블에 부적합

Backfill (소급 처리)

파이프라인 신규 도입 또는 로직 변경 후, 과거 특정 기간의 데이터를 재처리합니다.

새 로직 적용 → [2024-01 🔄] [2024-02 🔄] [2024-03 🔄] [2024-04 🔄] [2024-05 현재]

• ✅ 로직 변경 시 과거 데이터 정합성 유지, 신규 컬럼 과거분 채우기
• ⚠️ 대규모 처리 비용 발생, 멱등성 설계가 필수

✅ 5. 데이터 품질 (Data Quality) 6대 원칙

데이터 품질은 파이프라인 신뢰성의 핵심입니다. 6가지 차원으로 측정하고 관리합니다.

파이프라인에서 품질 체크 적용 위치

Source → [수집 시 검증] → Staging → [변환 전 검증] → Transform → [변환 후 검증] → Target

🛠️ 대표 도구: Great Expectations, dbt tests, Soda
파이프라인 각 단계에서 자동 품질 체크를 실행하고, 실패 시 알림을 보냅니다.

📝 정리

• Batch: 주기적 대량 처리 / Streaming: 실시간 이벤트 처리
• Lambda: Batch + Stream 병렬 운영 (복잡) / Kappa: Stream 단일 경로 (단순)
• 멱등성: 몇 번을 실행해도 같은 결과 → 안전한 재실행의 핵심
• Incremental: 변경분만 / Full Refresh: 전체 재적재 / Backfill: 과거 소급 처리
• Data Quality: 완전성·정확성·일관성·적시성·유일성·유효성 6가지로 측정

이전 글: 데이터 파이프라인 완전 정복: ETL vs ELT, 뭐가 다를까?

데이터 엔지니어링을 처음 공부하다 보면 ETL, ELT라는 단어를 자주 마주치게 됩니다.
이 글에서는 데이터 파이프라인의 기본 구조부터 ETL/ELT의 차이와 선택 기준까지 정리해봤습니다.

📦 데이터 파이프라인이란?

데이터 파이프라인은 데이터가 흘러가는 경로입니다. 크게 세 단계로 이루어집니다.

Source → Staging → Target

🔄 ETL이란?

ETL(Extract, Transform, Load) 은 다양한 소스의 데이터를 추출(Extract) 하고, 변환(Transform) 한 뒤, 데이터 웨어하우스에 적재(Load) 하는 프로세스입니다.

단순한 데이터 이동이 아니라, 비즈니스 규칙을 적용해 데이터를 정리·구조화함으로써 분석, BI, ML에 바로 활용 가능한 상태로 만드는 것이 핵심입니다.

ETL이 필요한 이유

기업 데이터는 수많은 소스에 정형·비정형으로 분산되어 있습니다.

• 온라인 결제 및 CRM 시스템의 고객 데이터
• 공급업체 시스템의 재고 및 운영 데이터
• IoT 디바이스의 센서 데이터
• 소셜 미디어의 마케팅 데이터
• 내부 HR 시스템의 직원 데이터

ETL은 이 데이터들을 하나의 통합된 뷰로 만들어 의미 있는 인사이트를 뽑아낼 수 있게 해줍니다.

⚙️ ETL은 어떻게 작동하나요?

1단계 — 추출 (Extract)

소스에서 원시 데이터를 복사해 스테이징 영역(랜딩 존) 에 임시 저장합니다.

추출 방식은 세 가지입니다.

2단계 — 변환 (Transform)

추출된 데이터를 분석에 적합한 형태로 가공합니다.

기본 변환

• 오류 제거 및 데이터 정리
• 중복 레코드 제거
• 날짜·단위·문자셋 형식 통일

고급 변환 (비즈니스 규칙 적용)

3단계 — 적재 (Load)

변환된 데이터를 대상 데이터 웨어하우스에 올립니다.

☁️ ELT란? 그리고 왜 대세가 됐나?

ELT(Extract, Load, Transform) 는 변환을 적재 이후에 수행하는 방식입니다.

ETL:  Source → Extract → Staging → Transform → Load → Target
ELT:  Source → Extract → Staging → Load → Target → Transform

데이터를 일단 클라우드 데이터 웨어하우스(BigQuery, Snowflake 등)에 원시 상태로 올려두고, 필요할 때 쿼리로 변환합니다.

ELT가 주류가 된 이유

클라우드 DW의 발전 덕분입니다.

• 스토리지 비용 이 크게 낮아졌고
• 스케일아웃 쿼리 엔진 이 대용량 변환을 빠르게 처리할 수 있게 됨
• 굳이 적재 전에 무거운 변환 작업을 할 필요가 없어졌습니다

🤔 ETL vs ELT, 언제 뭘 쓸까?

📝 정리

• ETL: 변환 먼저, 적재 나중. 정제된 데이터만 웨어하우스에 들어갑니다.
• ELT: 적재 먼저, 변환 나중. 클라우드의 강력한 컴퓨팅 파워를 활용합니다.
• 현재 대부분의 현대적인 데이터 스택은 ELT 방식을 채택하고 있으며, dbt 같은 도구가 Target 내부의 Transform을 담당합니다.

참고: AWS - ETL이란 무엇인가요?

🟢 1280. Students and Examinations

문제 요약

모든 학생이 모든 과목 시험에 몇 번 참석했는지 반환한다. 한 번도 안 본 조합도 0으로 출력해야 한다.

💡 핵심 개념 - CROSS JOIN

두 테이블의 모든 조합을 생성하는 JOIN. 조건(ON) 없이 사용한다.

-- Students 2명 × Subjects 3개 = 6가지 조합 생성
SELECT s.student_id, s.student_name, sub.subject_name
FROM Students s
CROSS JOIN Subjects sub

시험을 안 본 조합도 0으로 출력해야 하므로:

• CROSS JOIN → 모든 학생-과목 조합 생성
• LEFT JOIN → Examinations와 연결, 없으면 NULL
• COUNT(e.student_id) → NULL은 카운트 안 함 → 자동으로 0 반환

COUNT(e.student_id)  -- ✅ NULL 제외 → 0 반환
COUNT(*)             -- ❌ NULL도 카운트 → 1 반환

✅ 최종 풀이

SELECT
    s.student_id,
    s.student_name,
    sub.subject_name,
    COUNT(e.student_id) AS attended_exams
FROM Students s
CROSS JOIN Subjects sub
LEFT JOIN Examinations e
    ON s.student_id = e.student_id
    AND sub.subject_name = e.subject_name
GROUP BY s.student_id, s.student_name, sub.subject_name
ORDER BY s.student_id, sub.subject_name

📝 배운 점

• CROSS JOIN : 모든 조합 생성, 0을 포함한 집계 문제에서 활용
• LEFT JOIN 후 COUNT 할 때 COUNT(*) 대신 COUNT(특정 컬럼) 사용해야 NULL 제외됨
• "모든 조합을 보여줘야 할 때" → CROSS JOIN + LEFT JOIN 패턴 기억하기

🟡 1045. Customers Who Bought All Products

문제 요약

Product 테이블의 모든 제품을 구매한 customer_id를 반환한다.

💡 핵심 개념 - HAVING COUNT(DISTINCT) = 전체 COUNT

특정 고객이 구매한 distinct 제품 수가 전체 제품 수와 같으면 모든 제품을 산 것.

HAVING COUNT(DISTINCT p.product_key) = (SELECT COUNT(*) FROM Product)

처음 접근 (오답)

-- ❌ EXISTS 방식 - 하나라도 일치하면 통과 → "모든 제품" 조건 충족 불가
SELECT DISTINCT c.customer_id
FROM Customer c
WHERE EXISTS (
    SELECT 1 FROM Product p
    WHERE c.product_key = p.product_key
);

EXISTS는 조건을 하나라도 만족하면 TRUE를 반환하므로 "모든 제품"을 검증할 수 없다.

✅ 최종 풀이

SELECT c.customer_id
FROM Customer c
JOIN Product p
ON c.product_key = p.product_key
GROUP BY c.customer_id
HAVING COUNT(DISTINCT p.product_key) = (SELECT COUNT(*) FROM Product)

📝 배운 점

• "모든 ~를 포함하는" 조건 → HAVING COUNT(DISTINCT) = (SELECT COUNT(*) FROM 전체테이블) 패턴
• EXISTS는 "하나라도 존재하면" 조건, 전체 포함 여부 검증에는 부적합
• 중복 구매 가능성이 있으므로 COUNT(DISTINCT)로 중복 제거 필수

🟡 608. Tree Node

문제 요약

Tree 테이블에서 각 노드의 타입을 반환한다.

• Root : p_id가 NULL (부모 없음)
• Inner : 자식이 있는 노드 (다른 노드의 p_id로 등장)
• Leaf : 자식이 없는 노드 (나머지)

💡 핵심 개념 - CASE WHEN + IN 서브쿼리

조건 분기 로직을 CASE WHEN으로, 자식 존재 여부를 IN 서브쿼리로 확인한다.

-- 자식이 있는 노드 = 다른 노드의 p_id 목록에 내 id가 있는 경우
WHEN id IN (SELECT p_id FROM Tree WHERE p_id IS NOT NULL) THEN 'Inner'

주의: WHERE p_id IS NOT NULL을 빠뜨리면 서브쿼리 결과에 NULL이 포함되어 NOT IN 사용 시 전체 결과가 빈값이 될 수 있음.

✅ 최종 풀이

SELECT id,
    CASE
        WHEN p_id IS NULL
            THEN 'Root'
        WHEN id IN (SELECT p_id FROM Tree WHERE p_id IS NOT NULL)
            THEN 'Inner'
        ELSE 'Leaf'
    END AS type
FROM Tree

📝 배운 점

• CASE WHEN은 위에서 아래로 순서대로 평가 → Root 먼저 걸러야 Inner/Leaf 구분 가능
• IN 서브쿼리에 NULL이 포함되면 NOT IN이 항상 false → WHERE p_id IS NOT NULL 필수
• 트리 구조 문제는 "부모 여부(p_id IS NULL)", "자식 여부(id IN p_id 목록)" 두 가지로 분류

🟡 1341. Movie Ratings

문제 요약

두 가지를 반환한다.

1. 가장 많은 영화를 평가한 유저 이름 (동점이면 사전순 앞)
2. 2020년 2월 평균 평점이 가장 높은 영화 제목 (동점이면 사전순 앞)

💡 핵심 개념 - UNION ALL + 다중 정렬

성격이 다른 두 결과를 하나로 합칠 때 UNION ALL을 사용한다.

-- UNION    : 중복 제거 (느림)
-- UNION ALL : 중복 유지 (빠름) ← 두 결과가 애초에 다른 종류이므로 UNION ALL이 적합

동점 처리 → ORDER BY 기준1 DESC, 기준2 ASC로 우선순위 지정

ORDER BY COUNT(mr.movie_id) DESC, u.name ASC
-- 평가 수 많은 순 → 같으면 이름 사전순

✅ 최종 풀이

-- 가장 많은 영화를 평가한 유저
(
    SELECT u.name AS results
    FROM Users u
    JOIN MovieRating mr ON u.user_id = mr.user_id
    GROUP BY mr.user_id
    ORDER BY COUNT(mr.movie_id) DESC, u.name ASC
    LIMIT 1
)
UNION ALL
-- 2020년 2월 평균 평점이 가장 높은 영화
(
    SELECT m.title AS results
    FROM MovieRating mr
    JOIN Movies m ON mr.movie_id = m.movie_id
    WHERE YEAR(mr.created_at) = 2020
      AND MONTH(mr.created_at) = 02
    GROUP BY mr.movie_id
    ORDER BY AVG(mr.rating) DESC, m.title ASC
    LIMIT 1
)

📝 배운 점

• UNION ALL : 성격이 다른 두 결과를 합칠 때, 중복 제거 불필요하면 UNION보다 빠름
• 동점 처리는 ORDER BY 주기준 DESC, 보조기준 ASC 패턴
• 각 서브쿼리를 괄호로 감싸야 ORDER BY + LIMIT이 각각 적용됨

🔑 오늘의 핵심 정리

🟡 586. Customer Placing the Largest Number of Orders

문제 요약

Orders 테이블에서 주문을 가장 많이 한 customer_number를 반환한다.

💡 핵심 개념 - ORDER BY + LIMIT vs 서브쿼리

직관과 반대로 ORDER BY + LIMIT이 더 빠르다. 이유는:

• 정렬 대상이 전체 row가 아닌 그룹화된 결과(k개)
• 옵티마이저가 LIMIT 1을 만나면 전체 정렬 없이 최솟값/최댓값 탐색으로 최적화함

💡 EXPLAIN으로 실행 계획 확인

EXPLAIN SELECT ...

type 성능 순서: const > ref > range > index > ALL(최악)

✅ 최종 풀이

SELECT customer_number
FROM (
    SELECT customer_number, COUNT(order_number) AS order_count
    FROM Orders
    GROUP BY customer_number
) AS cnt
ORDER BY order_count DESC
LIMIT 1

📝 배운 점

• 쿼리 효율성을 고민할 때 "테이블을 몇 번 읽는가" 를 먼저 따질 것
• ORDER BY + LIMIT 1 패턴은 옵티마이저가 최솟값/최댓값 탐색으로 최적화함
• EXPLAIN / EXPLAIN ANALYZE로 실제 실행 계획을 확인하는 습관 들이기

🟢 596. Classes More Than 5 Students

문제 요약

Courses 테이블에서 수강생이 5명 이상인 수업명을 반환한다.

💡 핵심 개념 - WHERE vs HAVING

두 가지 풀이 비교

-- 서브쿼리 방식 ✅
SELECT class
FROM (
    SELECT class, COUNT(*) AS student_cnt
    FROM Courses
    GROUP BY class
) AS cnt
WHERE student_cnt >= 5

-- HAVING 방식 ✅ (더 간결)
SELECT class
FROM Courses
GROUP BY class
HAVING COUNT(*) >= 5

서브쿼리가 유리한 경우 → 집계 결과를 여러 조건에서 재사용할 때

✅ 최종 풀이

SELECT class
FROM Courses
GROUP BY class
HAVING COUNT(*) >= 5

📝 배운 점

• 간단한 집계 조건은 HAVING이 더 깔끔하고 성능도 좋음 (임시 테이블 생성 없음)
• 집계 결과에 이름을 붙여 재사용해야 할 때는 서브쿼리가 유리

🔴 1193. Monthly Transactions I

문제 요약

월별/국가별로 전체 거래 수/금액, 승인된 거래 수/금액을 반환한다.

💡 핵심 개념 - 조건부 집계 (Conditional Aggregation)

같은 행을 조건에 따라 다르게 집계하는 기법. JOIN 없이 한 번에 해결 가능.

-- 기본 패턴
SUM(CASE WHEN state = 'approved' THEN 1 ELSE 0 END)      -- 승인 건수
SUM(CASE WHEN state = 'approved' THEN amount ELSE 0 END)  -- 승인 금액

-- MySQL 최적화 버전
SUM(state = 'approved')                     -- Boolean 평가 (0/1)
SUM(IF(state = 'approved', amount, 0))       -- IF 함수

쿼리 성능 최적화

실제 결과: 3818ms (하위 5%) → 565ms (상위 40%) 개선

실무 주의: SUM(state = 'approved')는 MySQL 전용 문법. 타 DB 호환이 필요하면 CASE WHEN 사용.

❌ 처음 접근의 실수

• CTE + JOIN 방식으로 approved 데이터를 분리 시도 → JOIN 후 approved 건만 남아 trans_count 오류
• 조건부 집계로 한 테이블에서 한 번에 해결 가능

✅ 최종 풀이

SELECT
    LEFT(trans_date, 7) AS month,
    country,
    COUNT(*) AS trans_count,
    SUM(amount) AS trans_total_amount,
    SUM(state = 'approved') AS approved_count,
    SUM(IF(state = 'approved', amount, 0)) AS approved_total_amount
FROM Transactions
GROUP BY month, country

📝 배운 점

• 조건부 집계는 JOIN 없이 한 테이블에서 다양한 조건의 집계를 동시에 처리
• LEFT(date, 7)가 DATE_FORMAT보다 빠름 (단순 문자열 연산)
• 실무에서는 DB 호환성을 고려해 CASE WHEN을 선호하는 팀도 많음

🟡 1141. User Activity for the Past 30 Days I

문제 요약

2019-07-27 기준 30일간(포함) 일별 활성 유저 수를 반환한다.

💡 핵심 개념 - COUNT(DISTINCT)

테이블에 중복 행이 있을 수 있으므로 같은 날 여러 활동을 한 유저는 1명으로 세야 한다.

COUNT(user_id)          -- ❌ 활동 수를 셈 (중복 포함)
COUNT(DISTINCT user_id) -- ✅ 유저 수를 셈 (중복 제거)

30일 날짜 범위 정확히 계산하기

2019-07-27 기준 30일 → 2019-06-28 ~ 2019-07-27 (양 끝 포함)
= INTERVAL 29 DAY (30일이 아님!)

-- ❌ INTERVAL 1 MONTH = 2019-06-27~ → 31일
WHERE activity_date >= DATE_SUB('2019-07-27', INTERVAL 1 MONTH)

-- ✅ 정확히 30일
WHERE activity_date >= DATE_SUB('2019-07-27', INTERVAL 29 DAY)
  AND activity_date <= '2019-07-27'

❌ 처음 접근의 실수

1. GROUP BY user_id → GROUP BY activity_date 로 수정 (날짜별 집계 필요)
2. INTERVAL 1 MONTH → INTERVAL 29 DAY (30일 포함 범위)
3. 상한 조건 AND activity_date <= '2019-07-27' 누락

✅ 최종 풀이

SELECT activity_date AS day,
    COUNT(DISTINCT user_id) AS active_users
FROM Activity
WHERE activity_date >= DATE_SUB('2019-07-27', INTERVAL 29 DAY)
  AND activity_date <= '2019-07-27'
GROUP BY activity_date

📝 배운 점

• 중복 데이터가 있는 테이블에서 유일한 값을 세려면 COUNT(DISTINCT) 사용
• "N일간" 날짜 범위는 INTERVAL N-1 DAY (양 끝 포함 시)
• GROUP BY 대상은 항상 "무엇을 기준으로 집계하는가"를 먼저 생각하기

🟡 1327. List the Products Ordered in a Period

문제 요약

2020년 2월에 100개 이상 주문된 제품의 이름과 수량을 반환한다.

💡 핵심 개념 - SQL 절 실행 순서

FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY

이 순서는 반드시 지켜야 한다. WHERE가 GROUP BY 뒤에 오면 문법 오류.

WHERE vs HAVING 최종 정리

WHERE  → GROUP BY 이전, 개별 행 필터링, 집계 함수 ❌
HAVING → GROUP BY 이후, 그룹 필터링,   집계 함수 ✅

이 문제에서:

• LEFT(order_date, 7) = '2020-02' → 개별 행 조건 → WHERE
• SUM(unit) >= 100 → 집계 후 조건 → HAVING

❌ 처음 접근의 실수

-- ❌ 오류 쿼리
GROUP BY product_name
WHERE LEFT(o.order_date, 7) = '2020-02'   -- WHERE가 GROUP BY 뒤에 위치
  AND SUM(unit) >= 100                     -- 집계 함수를 WHERE에 사용

✅ 최종 풀이

SELECT p.product_name, SUM(o.unit) AS unit
FROM Products p
JOIN Orders o ON p.product_id = o.product_id
WHERE LEFT(o.order_date, 7) = '2020-02'
GROUP BY p.product_name
HAVING SUM(o.unit) >= 100

📝 배운 점

• SQL 절 순서 FROM → WHERE → GROUP BY → HAVING → SELECT 는 반드시 암기
• 날짜 필터는 WHERE, 집계 조건은 HAVING으로 명확히 구분
• 두 테이블 모두 매칭되는 데이터만 필요할 때는 INNER JOIN이 의도를 명확하게 표현

🔑 오늘의 핵심 정리

🟢 175. Combine Two Tables

문제 요약

Person 테이블의 모든 사람에 대해 이름과 주소를 반환한다. Address 테이블에 주소가 없으면 NULL을 반환한다.

💡 핵심 개념 - JOIN의 종류

❌ 틀렸던 이유

• INNER JOIN을 쓰면 주소가 없는 사람이 결과에서 탈락해버림
• 항상 "어느 테이블의 모든 행을 보존해야 하는가"를 먼저 생각할 것

✅ 최종 풀이

SELECT p.firstName, p.lastName, a.city, a.state
FROM Person p
LEFT JOIN Address a ON p.personId = a.personId

🟡 176. Second Highest Salary

문제 요약

Employee 테이블에서 두 번째로 높은 distinct salary를 반환한다. 없으면 NULL 반환.

💡 핵심 개념 - RANK() vs DENSE_RANK()

• RANK() → 동점 시 다음 순위를 건너뜀 (1,1,3...)
• DENSE_RANK() → 동점 시 순위를 연속으로 매김 (1,1,2...)

❌ 틀렸던 이유

1. Window 함수를 같은 SELECT 절에서 바로 사용 → 서브쿼리 분리 필요
2. RANK() 사용 → DENSE_RANK()로 변경
3. NULL 반환 처리 누락 → MAX()로 감싸기

✅ 최종 풀이

SELECT MAX(salary) AS SecondHighestSalary
FROM (
    SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
    FROM Employee
) ranked
WHERE rnk = 2

🟡 181. Employees Earning More Than Their Managers

문제 요약

자신의 매니저보다 급여가 높은 직원의 이름을 반환한다.

💡 핵심 개념 - Self Join

같은 테이블을 두 개인 것처럼 alias를 다르게 줘서 JOIN하는 기법.

• ON → 두 테이블을 어떻게 연결할 것인가 (관계 정의)
• WHERE → 연결된 결과에서 어떤 행을 필터링할 것인가 (조건 적용)

✅ 최종 풀이

SELECT e.name AS Employee
FROM Employee e
JOIN Employee m ON e.managerId = m.id
WHERE e.salary > m.salary

🟢 584. Find Customer Referee

문제 요약

referee_id가 2가 아니거나, 추천인이 없는(NULL) 고객의 이름을 반환한다.

💡 핵심 개념 - NULL과의 비교 연산

NULL과의 모든 비교 연산은 TRUE/FALSE가 아닌 NULL(unknown)을 반환한다.

• referee_id != 2 에서 NULL인 행 → 결과가 NULL → WHERE 조건 탈락!
• 반드시 IS NULL로 명시적으로 체크해야 한다.

❌ 틀렸던 이유

1. 불필요한 Self Join 시도
2. NULL 처리 누락
3. IS NOT IN → 없는 문법, NOT IN이 올바름

✅ 최종 풀이

SELECT name
FROM Customer
WHERE referee_id != 2 OR referee_id IS NULL

🟡 1978. Employees Whose Manager Left the Company

문제 요약

급여가 $30,000 미만이면서 매니저가 회사를 떠난 직원의 ID를 반환한다.

💡 핵심 개념 - NOT IN + 서브쿼리

❌ 틀렸던 이유

1. IS NOT IN 문법 오류 → NOT IN으로 수정
2. <= 30000 → strictly less than이므로 < 30000
3. manager_id IS NOT NULL 누락

✅ 최종 풀이

SELECT employee_id
FROM Employees
WHERE salary < 30000
  AND manager_id IS NOT NULL
  AND manager_id NOT IN (SELECT employee_id FROM Employees)
ORDER BY employee_id

🔑 오늘의 핵심 정리

데이터를 집계하거나 순위를 매길 때 GROUP BY를 사용하지 않고 개별 행의 속성을 유지하면서 계산할 수 있게 해주는 기능

일반적인 집계 함수(SUM, AVG 등)는 GROUP BY 절과 함께 쓰여 여러 행을 하나의 행으로 압축(Collapse)한다.

하지만 윈도우 함수는 행을 압축하지 않는다. 대신, 쿼리 결과의 각 행에 대해 윈도우라고 불리는 특정 행 집합을 기준으로 계산한 값을 추가 열로 보여준다.

비유: 반 학생들의 '반 평균' 점수를 알고 싶을 때,

• GROUP BY: 'A반'의 평균 점수 70점'이라는 한 줄의 결과만 보여준다.
• 윈도우 함수: '철수 (A반)'의 점수 80점, 'A반 평균' 70점 / '영희 (A반)'의 점수 60점, 'A반 평균' 70점... 처럼 모든 학생 목록을 보여주면서 각 학생 옆에 반 평균을 같이 보여준다.

2. 기본 문법

SELECT 
    함수명(인자) OVER (
        [PARTITION BY 컬럼1, 컬럼2 ...]
        [ORDER BY 컬럼3, 컬럼4 ...] 
    ) AS 별칭
FROM 테이블명;

• FUNCTION() :사용할 윈도우 함수 (예: RANK(), SUM())
• OVER(): 윈도우 함수임을 명시.
• PARTITION BY (선택): 윈도우를 나눌 기준.(예: PARTITION BY department -> 부서별로 윈도우를 나눔)
• ORDER BY (선택): 윈도우 내에서 어떤 순서로 계산할지 정한다. (예: 급여 순, 입사일 순)

3. 예시 데이터

4. 주요 윈도우 함수

4-1. 순위 함수 (Ranking Functions)

PARTITION BY로 그룹을 나누고, 그 안에서 ORDER BY로 순위를 매긴다.

1. ROW_NUMBER()
   • 의미: 윈도우 내에서 순서를 1부터 차례대로 계산한다. (중복 값도 다른 순위 부여)
   • 사용법: ROW_NUMBER() OVER (ORDER BY salary DESC)
   • 예시: 전체 직원 급여 순위 (동점자도 다른 순위)

```sql
SELECT
    name, department, salary,
    ROW_NUMBER() OVER (ORDER BY salary DESC) AS row_num
FROM employees;
```

• 결과:

  | **name** | **department** | **salary** | **row_num** |
  | --- | --- | --- | --- |
  | Eve | Engineering | 8000 | 1 |
  | David | Engineering | 7000 | 2 |
  | Bob | Sales | 6000 | 3 |
  | Frank | Marketing | 5500 | 4 |
  | Alice | Sales | 5000 | 5 |
  | Charlie | Sales | 5000 | 6 |

2. RANK()

   • 의미: 순위를 매기되, 동점자에게는 같은 순위를 부여. 단, 다음 순위는 동점자 수를 건너뛰고 계산한다.

   • 사용법: RANK() OVER (PARTITION BY department ORDER BY salary DESC)

   • 예시: 부서별 급여 순위 (동점자 같은 순위, 중간 순위 비움)

     SELECT
        name, department, salary,
        RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS rnk
     FROM employees;

   • 결과:

  | **name** | **department** | **salary** | **rnk** |
  | --- | --- | --- | --- |
  | Eve | Engineering | 8000 | 1 |
  | David | Engineering | 7000 | 2 |
  | Frank | Marketing | 5500 | 1 |
  | Bob | Sales | 6000 | 1 |
  | Alice | Sales | 5000 | 2 |
  | Charlie | Sales | 5000 | 2 |



  **[참고]** Sales 부서에서 1위(Bob) 다음 2위가 2명(Alice, Charlie)이므로 다음 순위인 3위는 없고 1, 2, 2가 된다. 
  만약 4위가 있었다면 4위가 된다.

3. DENSE_RANK()

   • 의미: RANK()와 같지만, 다음 순위를 건너뛰지 않는다. (예: 1, 2, 2, 3)

   • 사용법: DENSE_RANK() OVER (ORDER BY salary DESC)

   • 예시: 전체 직원 급여 순위 (동점자 같은 순위, 중간 순위 비우지 않음)

     SELECT
        name, department, salary,
        DENSE_RANK() OVER (ORDER BY salary DESC) AS dense_rnk
     FROM employees;

   • 결과:

  | **name** | **department** | **salary** | **dense_rnk** |
  | --- | --- | --- | --- |
  | Eve | Engineering | 8000 | 1 |
  | David | Engineering | 7000 | 2 |
  | Bob | Sales | 6000 | 3 |
  | Frank | Marketing | 5500 | 4 |
  | Alice | Sales | 5000 | 5 |
  | Charlie | Sales | 5000 | 5 |

4-2. 집계함수 (Aggregate Functions)

SUM, AVG, COUNT, MAX, MIN 등 기존 집계 함수를 OVER()와 함께 사용.

1. SUM() OVER ()

   • 의미: 윈도우 내의 합계를 구한다.

   • 사용법 1 (누적 합계): SUM(salary) OVER (PARTITION BY department ORDER BY id)

   • 사용법 2 (그룹 전체 합계): SUM(salary) OVER (PARTITION BY department)

   • 예시: 부서별 급여 합계 및 누적 급여

     SELECT
        name, department, salary,
        -- 부서별(PARTITION BY)로 총 급여 합계 (ORDER BY 없음)
        SUM(salary) OVER (PARTITION BY department) AS dept_total_salary,
        -- 부서별(PARTITION BY)로 id 순서 (ORDER BY)대로 누적 급여
        SUM(salary) OVER (PARTITION BY department ORDER BY id) AS running_total
        FROM employees;

• 결과:

  | **name** | **department** | **salary** | **dept_total_salary** | **running_total** |
  | --- | --- | --- | --- | --- |
  | David | Engineering | 7000 | 15000 | 7000 |
  | Eve | Engineering | 8000 | 15000 | 15000 |
  | Frank | Marketing | 5500 | 5500 | 5500 |
  | Alice | Sales | 5000 | 16000 | 5000 |
  | Bob | Sales | 6000 | 16000 | 11000 |
  | Charlie | Sales | 5000 | 16000 | 16000 |

2. AVG() OVER ()

   • 의미: 윈도우 내의 평균을 구합니다.

   • 사용법: AVG(salary) OVER (PARTITION BY department)

   • 예시: 각 직원의 급여와 해당 직원이 속한 부서의 평균 급여를 함께 보기

     SELECT
        name, department, salary,
        AVG(salary) OVER (PARTITION BY department) AS dept_avg_salary
     FROM emplyees;

   • 결과: (모든 Sales 부서 직원은 동일한 dept_avg_salary 5333.33을 가짐

     name	department	salary	dept_avg_salary
     David	Engineering	7000	7500.00
     Eve	Engineering	8000	7500.00
     Frank	Marketing	5500	5500.00
     Alice	Sales	5000	5333.33
     Bob	Sales	6000	5333.33
     Charlie	Sales	5000	5333.33

4-3. 값 함수 (Value Functions)

윈도우 내에서 특정 위치의 값(예: 이전 행, 다음 행)을 가져온다. ORDER BY가 필수.

1.RAG()

• 의미: 윈도우 내에서 이전(Previous) 행의 값을 가져옵니다.

• 사용법: LAG(가져올 컬럼, [몇 칸 앞인지, 기본값 1], [이전 행이 없을 때 기본값]) OVER (ORDER BY ...)

• 예시: 부서별로 정렬했을 때, 바로 이전 직원의 급여 가져오기

  SELECT
      name, department, salary,
      LAG(salary, 1, 0) OVER (PARTITION BY department ORDER BY salary)     AS prev_salary
  FROM employees;

• 결과: (Engineering의 David, Marketing의 Frank, Sales의 Alice/Charlie는 부서 내 첫 번째 순서이므로 prev_salary가 0)

  | **name** | **department** | **salary** | **prev_salary** |
  | --- | --- | --- | --- |
  | David | Engineering | 7000 | 0 |
  | Eve | Engineering | 8000 | 7000 |
  | Frank | Marketing | 5500 | 0 |
  | Alice | Sales | 5000 | 0 |
  | Charlie | Sales | 5000 | 5000 |
  | Bob | Sales | 6000 | 5000 |

2.LEAD()

• 의미: 윈도우 내에서 다음(Next) 행의 값을 가져온다.

• 사용법: LEAD(가져올 컬럼, [몇 칸 뒤인지, 기본값 1], [다음 행이 없을 때 기본값]) OVER (ORDER BY ...)

• 예시: 부서별로 정렬했을 때, 바로 다음 직원의 급여 가져오기

  SELECT
      name, department, salary,
      LEAD(salary, 1, 0) OVER (PARTITION BY department ORDER BY salary) AS next_salary
  FROM employees;

• 결과: (Engineering의 Eve, Marketing의 Frank, Sales의 Bob은 부서 내 마지막 순서이므로 next_salary가 0)

  | **name** | **department** | **salary** | **next_salary** |
  | --- | --- | --- | --- |
  | David | Engineering | 7000 | 8000 |
  | Eve | Engineering | 8000 | 0 |
  | Frank | Marketing | 5500 | 0 |
  | Alice | Sales | 5000 | 5000 |
  | Charlie | Sales | 5000 | 6000 |
  | Bob | Sales | 6000 | 0 |

🎬 이번 주 활동 요약

• 제출 기한: 10월 25일(토) 24:00
• 프로젝트명: Promptory
• 주제: 생성형 AI 대화 자동 수집·요약·분류 서비스
• 개발 목표:
  • 대시보드 기능 고도화 및 시각화 완성
  • 태그 추출 알고리즘 구현 (KoNLPy, nltk)
  • UI/UX 개선 및 안정화
• GitHub: early-developer-club/promptory

💡 프로젝트 개요

Promptory는 Gemini와 ChatGPT 등 생성형 AI와의 대화를 자동으로 수집·요약·분류하는
AI 대화 아카이빙 서비스다.
6주차에는 단순한 기록을 넘어, 대화 데이터의 의미를 분석하고 시각화하는 기능을 중심으로 개발이 진행되었다.

“AI와의 대화가 단순 로그를 넘어,
내가 쌓아온 학습 패턴과 인사이트로 구조화되는 순간이었다.”

⚙️ 6주차 주요 개발 내용

🧠 지능형 태그 추출 방식

이번 주의 핵심은 “대화를 분석해 의미 있는 태그를 자동 생성하는 기능”이었다.
Promptory는 다음과 같은 과정을 통해 태그를 생성한다.

1. 형태소 분석:
   KoNLPy의 Okt 분석기를 이용해 대화(질문+응답)를 단어 단위로 분리
2. 핵심 품사 추출:
   명사(Noun) 및 알파벳(Alpha) 품사만 선택
3. 질문 가중치 부여:
   Prompt(질문)에 포함된 키워드에 5배 가중치를 적용
4. 불용어 및 필터링:
   불필요한 단어, 한 글자 단어, stopwords 목록을 제거
5. 상위 5개 태그 선정:
   가중치 + 빈도수 기반으로 최종 태그 추출

[대화 발생] → [형태소 분석] → [명사/알파벳 추출] → [질문(×5) 가중치 부여] → [불용어 필터링] → [상위 5개 태그 선정]

단순한 문자열 분석을 넘어,
“AI가 생성한 대화를 또 다른 AI로 분석한다”는 점에서
Promptory의 진정한 지능형 구조가 완성되었다.

📊 주요 결과 화면

1️⃣ 대시보드 기능 고도화 – 태그 통계 시각화

• 백엔드 /api/v1/statistics/tags API 추가
• recharts를 활용한 상위 10개 태그 빈도 분석 차트 구현
• 차트 클릭 시 해당 태그가 포함된 대화 목록으로 이동

2️⃣ DatePicker 개선 및 반응형 UI

• 실제 대화가 있는 날짜만 활성화되도록 API 연동
• 캘린더 및 레이아웃 여백(padding) 조정으로 사용자 경험 개선

3️⃣ Chrome Extension 안정화

• ChatGPT: 기존 대화 제외, 신규 대화만 저장
• Gemini: CSP 정책을 우회하기 위해 background.js에서 백엔드 통신 처리

🧩 인상 깊었던 포인트

“태그가 단순 문자열이 아니라,
내가 어떤 질문을 반복하고 어떤 주제에 집중하는지를 보여주는 거울 같았다.”

대시보드의 태그 분석 그래프를 통해
AI와의 대화 패턴이 시각적으로 드러나는 경험은 매우 흥미로웠다.
‘대화를 통한 자기 분석’이라는 Promptory의 방향성이 구체화된 순간이었다.

⚠️ 어려웠던 점

• 형태소 분석 라이브러리 이슈: KoNLPy 설치 시 JPype1 버전 충돌 발생 → 버전 고정으로 해결
• 태그 중복 처리: 영어·한글 혼용 시 중복되는 키워드가 발생 → 소문자 변환 및 중복 필터링 추가
• 대시보드 렌더링 속도: 태그 데이터 fetch 시 지연 발생 → API 응답 캐싱 적용

💬 이번 주 회고

6주차는 Promptory의 “지능화”와 “완성도 개선”이 동시에 이뤄진 주차였다.
AI 대화를 단순히 저장하는 것을 넘어,
그 대화를 분석하고 나의 AI 사용 습관을 시각화하는 단계로 진화했다.

이제 Promptory는 단순한 AI 로거를 넘어,
“AI와 함께 성장하는 학습 파트너”로 발전할 준비를 마쳤다.

🎬 5주차 활동 요약

• 제출 기한: 10월 18일(토) 24:00
• 프로젝트명: Promptory
• 주제: 생성형 AI 대화 자동 수집·요약·분류 서비스
• 개발 목표:
  • 백엔드(FastAPI)와 프론트엔드(Next.js) 연동
  • 실시간 대화 데이터 시각화 구현
  • Chrome Extension → 백엔드 → DB → Dashboard 전 흐름 완성
• GitHub: early-developer-club/promptory

💡 프로젝트 개요

Promptory는 ChatGPT, Gemini 등과의 대화를 자동으로 수집·요약·분류·시각화하는 서비스다.
이번 주에는 백엔드로 수집된 대화 데이터가 실제로 화면에 렌더링되는 전체 흐름을 구현했다.

“AI 대화가 단순 텍스트 로그가 아니라, 지식 자산으로 시각화되는 순간을 보고 싶었다.”

⚙️ 5주차 주요 개발 내용

🧩 결과 화면

1️⃣ 프로젝트 개발 계획 정리 (README 일부)

2️⃣ Promptory Dashboard 화면

3️⃣ Conversation Details 페이지

실제로 ChatGPT와 Gemini를 통해 수집된 대화가
FastAPI → DB → Next.js를 거쳐 프론트엔드 대시보드에 시각화되었다.

⚠️ 개발 중 이슈: “Docker 빌드 중 코드 롤백 사고”

“빌드 테스트 중 gemini가 git 옵션으로 파일을 돌려버렸다…”

이번 주 가장 큰 사건이었다.
FastAPI와 Next.js를 각각 로컬 서버로 띄워 테스트하다가
Docker 이미지 빌드 과정을 자동화하려고 했는데,
Gemini가 git 명령어로 “이전 커밋 시점”을 복원해버려
작성해둔 코드가 통째로 롤백되는 사고가 발생했다.

결과적으로 Promptory 프로젝트를 두 번 개발하게 되었고,
그 과정에서 아래 두 가지 차이가 생겼다.

정상 버전(초기 개발 버전)

이 경험 덕분에 “Git 커밋은 보험이다”라는 말을 몸으로 배웠다.
자동화된 AI 환경에서도 결국 버전 관리의 주도권은 사람에게 있다.

💬 인상 깊었던 포인트

“AI와의 협업은 효율적이지만, 모든 책임은 개발자에게 있다. 개발자가 최종 책임을 갖지 않으면 프로젝트는 언제든 무너질 수 있다.”

Gemini가 빌드를 돕는 과정에서 예기치 못한 명령을 실행했지만,
그 상황을 되돌리고 복구해가는 과정 자체가 큰 배움이었다.
덕분에 Git 관리의 중요성, Docker 워크플로우의 리스크,
AI 협업 시 명령어 검증의 필요성을 절실히 깨달았다.

🧠 이번 주 회고

이번 주는 기능 완성과 사고 대응이 동시에 있었던 주차였다.
결과적으로 Promptory는 시각화 구조를 완성했고,
대화 데이터가 실제 서비스 형태로 보여지는 첫 버전을 완성했다.

다음 주에는 UI를 복구하고 요약(summary) 및 태그 자동화 로직을 추가하여
대화 데이터의 “가공 → 분석 → 가치화” 단계로 발전시킬 예정이다.

🎬 이번 주 활동 요약

• 제출 기한: 10월 11일(토) 24:00
• 프로젝트명: Promptory
• 주제: 생성형 AI 대화 자동 수집·요약·분류 서비스
• 개발 목표: FastAPI 기반 백엔드 초기 구축 및 Chrome Extension 연동
• 작업 기간: 2025년 10월 8일 기준
• Promptory Repository 바로가기

💡 프로젝트 개요

Promptory는 ChatGPT, Gemini 등과의 대화를 자동으로 백업·요약·태깅하여
프롬프트 재사용과 학습 자산화를 돕는 개발자용 서비스다.

“매일 쏟아지는 대화 속에서 내가 어떤 질문을 했는지조차 헷갈린다.”

이 문제를 해결하기 위해, Promptory는 생성형 AI와의 모든 대화를
하나의 데이터 자산으로 시각화하는 것을 목표로 한다.

⚙️ 4주차 주요 개발 내용

✅ 결과: Week 1 목표(백엔드 기본 구조 + 인증 시스템 구축) 달성!

💬 인상 깊었던 포인트

“AI가 문제를 해결해주는 게 아니라, 함께 디버깅하며 설계 방향을 잡는 경험이었다.”

이번 주는 로그인 인증 관련된 오류와의 싸움이 많았지만, Gemini가 실제 코드 수정·가이드·경로 교정까지 수행하며 비교적 수월하게 진행할 수 있었다.

특히 Python 버전 이슈나 OAuth 환경 변수 설정 같은 세부적인 문제들을 AI가 단계적으로 해결해준 점이 인상 깊었다.

🧩 이번 주 소감

4주차는 Promptory 서비스의 기반을 다진 주차였다.
AI와 협업하며 PRD → 기능 명세 → 개발 → 디버깅의 전체 사이클을 경험했고,
이 과정이 바로 “바이브코딩의 본질”임을 실감했다.

다음 주에는 프론트엔드(Next.js) 연동과 AI 대화 요약/태깅 로직 개발에 도전할 예정이다.

바이브 코딩 로그 보러가기

🎬 3주차 활동 요약

• 제출 기한: 10월 4일(토) 24:00
• 과제: 절대색감 게임 바이브 코딩하기
• GitHub: early-developer-club/color-game-jinyoung
• 배포 주소: https://color-game-jinyoung.netlify.app/

🎮 프로젝트 개요

절대 색감 게임(Absolute Color Game) 은 제한 시간 내에 n×n 색상 그리드에서
‘하나만 다른 색상’을 찾아 점수를 얻는 간단한 웹 게임이다.
게임이 끝나면 점수가 Firebase DB에 저장되어, 이름과 함께 랭킹보드에 표시된다.

• 소요 시간: Gemini와 함께한 단일 페어 프로그래밍 세션
• 기술 스택:
  • Frontend: HTML, CSS, JavaScript
  • Backend / DB: Firebase Realtime Database
  • Deploy: Netlify

🧠 개발 과정 (프롬프트 & 처리 내역)

Gemini CLI와의 대화 기반으로 게임이 점점 발전해갔다.
아래는 주요 프롬프트 흐름과 AI가 처리한 작업 요약이다.

1️⃣ 초기 설계

절대 색감 게임을 만들려고 해. Netlify를 통해 간단한 배포를 진행해볼 예정이야.
게임 정보를 저장해서 게임이 끝난 후 진행해 본 사용자들의 데이터를 바탕으로 랭킹을 보여주는 기능도 있으면 좋을 것 같아.

• Gemini가 HTML/CSS/JS + Firebase + Netlify 스택을 제안하고 전체 개발 계획을 설계.

2️⃣ 기본 구조 생성

응 동의해.

• 프로젝트 폴더 구조 및 기본 파일(index.html, style.css, script.js) 생성.
• 초기 버전의 색상 찾기 로직 구현.

3️⃣ 데이터베이스 연동

(Firebase 설정 객체 제공)

• Firebase SDK 추가 및 saveScore, fetchRanking 함수 구현.

4️⃣ README 및 보안 강화

(DB 정보 마스킹 요청)

• README.md 생성 및 Firebase 설정 정보 마스킹 처리.

5️⃣ 게임 규칙 개선

... n×n 형태로 시작한 뒤 1개의 다른 색상을 찾는 방식으로 진행해도 좋을 것 같아.
30초 안에 가장 많은 점수를 획득하는 것으로 하자.

• 타이머 기능, 난이도 증가 로직, 보너스/패널티 설계 추가.

6️⃣ UI/UX 수정

웅 동의해 수정해줘.

• index.html / style.css / script.js 전면 수정.
• 동적 그리드 구성 및 타이머 시각화 추가.

7️⃣ 음악 및 몰입감 추가

시간 차감이 좋을 것 같아. 긴장감을 높이기 위해 배경음악도 추가할 수 있을까?

• 오답 시 2초 차감 로직 추가.
• 배경음악 기능 구현 (background_music.mp3, loop 재생).

8️⃣ 최종 문서화

README.md 파일에 모든 프롬프트와 처리 내용을 업데이트해줘.

• 전체 개발 이력 및 규칙을 정리한 README 완성.

💡 인상 깊었던 포인트

“AI가 만든 코드를 그대로 사용하는 것이 아니라,
내가 원하는 방향으로 ‘조율하고 발전시키는 과정’이 바이브코딩의 진짜 핵심이다.”

Gemini CLI는 단순한 코드 생성의 역할이 아니라 개발의 전 과정을 함께 설계·수정·기록할 수 있는 협업 파트너로 느껴졌다. 다른 팀원들이 진행한 프로젝트를 봤을 때, Claude.md를 통해

⚙️ 어려웠던 점

• 배포까지의 과정은 혼자서 해본 적이 처음이었다. 관련된 지식이 없기 때문에 시간이 조금 소요되었지만, 핵심 개념을 갖고 있는 사람이 바이브 코딩을 사용한다면 엄청난 무기가 될 수 있을 것 같다.

🧩 이번 주 소감

이번 주는 단순한 실습이 아니라 AI와 함께 하나의 웹서비스를 완성한 경험이었다.
코드를 자동으로 생성하는 데서 그치지 않고,
요구사항 설계 → 구현 → 테스트 → 배포 → 문서화의 전 단계를
AI와 대화로 완성했다는 점이 인상 깊었다.

AI와 함께한 이 과정은 “바이브코딩(Vibe Coding)”이라는 개념을
가장 실감 나게 보여준 시간이었다.
다음 주에는 배포된 게임의 개선 아이디어나 기능 확장을 시도해볼 예정이다.

🎬 2주차 활동 요약

• 과제 마감: 27일(토) 24:00

• Basic 미션 1) 이후 스터디에 사용할 AI 툴 선택·설치(필요시 구독)
  2) AI에게 다음을 지시하고 결과 캡처

  "Hello, Early Developer Club!"이라고 출력하는 프로그램을 작성해줘.

• 나의 선택: Gemini CLI

🧠 세션 내용 정리

1️⃣ 툴 선택 & 세팅

• 바이브 코딩 환경으로 Gemini CLI를 선택하여 설치·인증을 진행했다.
• 로컬 환경에서 프롬프트 → 코드 생성 → 실행까지의 짧은 피드백 루프를 만드는 데 초점을 맞춤.
• Gemini CLI는 터미널에서 바로 AI에게 명령을 내릴 수 있어 개발 워크플로우에 자연스럽게 녹아드는 장점이 있었다.
• 또한 대학생 프로모션으로 pro 모델을 사용할 수 있는 것도 장점이 있었다.

2️⃣ 첫 지시와 결과

“Hello, Early Developer Club!”이라고 출력하는 프로그램을 작성해줘.

출력 화면은 다음과 같다.

세션 종료 후 Gemini CLI가 자동으로 모델 사용량과 성능 리포트를 보여주는 점이 인상적이었다.

⚙️ Gemini CLI 세션 종료 리포트 분석

Gemini CLI에서 /quit 명령어를 입력하면, 세션 요약(Interaction Summary)이 자동으로 출력된다.
이번 실습을 마친 뒤 CLI가 보여준 결과를 살펴보며 구조를 간단히 정리해봤다.

🧾 Interaction Summary

세션의 기본 정보와 수행 통계를 보여주는 구간이다.

👉 즉, 이번 세션은 2개의 명령을 모두 성공적으로 실행했음을 의미한다.

⚙️ Performance

AI가 응답하는 과정에서의 시간 비율을 보여준다.

💡 대부분의 시간은 AI 응답 생성(약 69%) 에 사용되었으며, 나머지는 로컬 툴 실행이었다.

🤖 Model Usage

💰 Savings Highlight

11,356 (61.3%) of input tokens were served from the cache, reducing costs.

Gemini CLI는 캐시 기능을 통해 이전 세션의 일부 입력을 재사용했다.
즉, 61.3%의 입력 데이터를 새로 계산하지 않아 비용 절감 및 속도 향상 효과가 있었다.

💡 Tip

CLI에서는 /stats model 명령어를 사용해 토큰 사용량을 더 자세히 분석할 수 있다.
덕분에 모델 호출 효율성과 비용 최적화를 직접 확인할 수 있었다.

🧩 이번 주 소감

처음 Gemini CLI를 설정할 때 인증 관련 에러가 반복되어 가장 어려웠다. Loaded cached credentials 같은 메시지가 출력되었지만, 실제로는 API Key가 올바르게 연결되지 않아 여러 번 재설정을 시도했다. 결국 환경 변수 설정과 캐시 파일 삭제를 통해 문제를 해결했지만, CLI 기반 툴의 인증 과정이 생각보다 까다롭다는 점을 체감했다.

하지만 문제를 해결하고 난 후, 터미널에서 곧바로 “프롬프트 → 코드 → 실행”이 이어지는 경험이 새로웠다. 명령 한 줄로 AI와 대화하며 코드를 생성하는 과정이 진짜 바이브 코딩의 시작처럼 느껴졌다.

세션을 종료하면서 자동으로 이런 성능 리포트와 토큰 사용량이 출력되는 점이 인상적이었다.
AI와의 대화가 단순 텍스트 수준을 넘어, 실제 리소스 단위로 추적 가능한 개발 활동이라는 걸 체감할 수 있었다.
앞으로는 이런 로그를 기반으로 프롬프트 효율성이나 캐시 전략을 비교해보는 것도 흥미로울 것 같다.

다음 주에는 이 환경을 기반으로 좀 더 구체적인 기능을 가진 코드를 작성해보고 싶다. 단순 출력에서 벗어나, 프롬프트 설계와 실행 결과를 반복적으로 다듬는 과정을 연습할 예정이다.

🎬 온보딩 & 첫 만남

처음 스터디를 참여하게 된 계기는 지인이 SNS를 통해 같이 스터디 참여할 인원을 모집하여 참여하게 되었다.

Early Developer Club으로 새로운 기술을 즐겁게 경험하고 삶에 적용하고 싶은 모임이며, 개발자가 아니더라도 참여할 수 있는 것이 큰 특징이었다.

EDC의 첫 스터디로 VDD(Vibe Driven Development)가 열렸다.

스터디 목표는 바이브 코딩을 경험하는 것이며 바이브 코딩은 다음과 같다.

바이브 코딩(Vibe Coding)

• 개발자가 코드를 직접 설계하고 작성하는 기존 코딩 방식과 달리, AI를 파트너 삼아 자연어(사람의 언어)로 지시를 내리고 AI가 생성한 코드를 검토, 수정, 활용하는 방식입니다.

VDD 첫 주는 자기소개와 앞으로의 활동 방향을 공유하는 온보딩 세션으로 시작되었다.

다양한 직군의 스터디원들이 모여 다양한 방법으로 활용될 것을 생각하며 오히려 좋았다.

🧠 특강: AI 트렌드의 변화와 바이브코딩 툴 소개

이도하님의 세션에서는 최근 AI 트렌드의 흐름과 개발자가 알아두면 좋은 툴 중심으로 이야기가 진행되었다.

1️⃣ LLM의 이해
2️⃣ RAG (Retrieval Augmented Generation)
3️⃣ MCP (Model Context Protocol)

다음과 같은 순서로 특강이 진행되었으며, 자세한 내용은 비밀 .. 인상깊었던 점은 “귀멸의 칼날: 무한성편 = 거대한 맞춤형 AI 세계”라는 비유이다😄

🧩 이번 주 소감

첫 주차부터 AI 트렌드 전반과 Vibe Coding에 대해 폭넓게 배울 수 있었다.
LLM, RAG, MCP 같은 키워드를 중심으로 “AI를 어떻게 내 개발에 녹일 수 있을까?”에 대한 방향성이 잡힌 시간이었다.

GROUP BY

problem

FISH_NAME_INFO에서 물고기의 종류 별 물고기의 이름과 잡은 수를 출력하는 SQL문을 작성해주세요. 물고기의 이름 컬럼명은 FISH_NAME, 잡은 수 컬럼명은 FISH_COUNT로 해주세요. 결과는 잡은 수 기준으로 내림차순 정렬해주세요.

code

SELECT COUNT(*) AS FISH_COUNT,
       B.FISH_NAME AS FISH_NAME

FROM FISH_INFO A

JOIN FISH_NAME_INFO B

ON A.FISH_TYPE = B.FISH_TYPE

GROUP BY B.FISH_TYPE, B.FISH_NAME

ORDER BY FISH_COUNT DESC; 

note

처음에 작성한 쿼리는 다음과 같다.

SELECT COUNT(A.FISH_TYPE) AS FISH_COUNT, 
       B.FISH_NAME AS FISH_NAME

FROM FISH_INFO AS A

JOIN FISH_NAME_INFO AS B

ON A.FISH_TYPE = B.FISH_TYPE

GROUP BY A.FISH_TYPE

ORDER BY FISH_COUNT;

안됬던 이유는 뭘까...

실패 (1055, "Expression #3 of SELECT list is not in GROUP BY clause and contains 
nonaggregated column 'programmers.B.FISH_NAME' which is not functionally dependent on
columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by")

에러를 해석하면 GROUP BY A.FISH_TYPE만 있어서 B.FISH_NAME이 비집계 컬럼이 된다. 따라서 B.FISH_NAME을 가져올 수 없는 것이다. 이 문제를 GROUP BY B.FISH_TPYE, B.FISH_NAME으로 바꿔주며 해결하였다. 요즘 문제를 풀면서 느끼는 생각인데, 과연 실무에 들어갔을 때 내가 원하는 결과 값을 한번에 쿼리를 작성해서 도출할 수 있을까?? 라는 생각이 든다. 공부를 하면 할수록 부족함을 느끼고 그에 따라 불안감도 커져만 간다. 나를 믿고 하루하루 후회없이 살아보자 🔥

GROUP BY

problem

HR_DEPARTMENT, HR_EMPLOYEES, HR_GRADE 테이블에서 2022년도 한해 평가 점수가 가장 높은 사원 정보를 조회하려 합니다. 2022년도 평가 점수가 가장 높은 사원들의 점수, 사번, 성명, 직책, 이메일을 조회하는 SQL문을 작성해주세요. 2022년도의 평가 점수는 상,하반기 점수의 합을 의미하고, 평가 점수를 나타내는 컬럼의 이름은 SCORE로 해주세요.

code

-- 코드를 작성해주세요
SELECT G.SCORE, E.EMP_NO, E.EMP_NAME, E.POSITION, E.EMAIL

FROM HR_EMPLOYEES AS E

JOIN (SELECT EMP_NO, SUM(SCORE) AS SCORE

      FROM HR_GRADE

      GROUP BY EMP_NO) AS G

ON E.EMP_NO = G.EMP_NO

ORDER BY SCORE DESC

LIMIT 1;        

note

테이블이 3개가 나와서 당황했지만 쉽게 풀 수 있는 문제였다. 어떻게 하면 더욱 효율적이고, 문제에서 요구한 바를 정확하게 표현할 수 있을까? 고민했다. 총 3가지를 보완할 수 있었다.

2022년 필터 빠짐 → WHERE YEAR = 2022

동점 처리 → LIMIT 1은 동점을 잘라버림. “가장 높은 사원들”이면 동점 모두 반환

불필요한 작업 최소화 → 집계 끝난 뒤에만 사원 테이블과 조인

WITH yearly AS (
  SELECT
    EMP_NO,
    SUM(SCORE) AS SCORE
  FROM HR_GRADE
  WHERE `YEAR` = 2022
  GROUP BY EMP_NO
)

SELECT
  y.SCORE,
  e.EMP_NO,
  e.EMP_NAME,
  e.`POSITION`,
  e.EMAIL

FROM (
  SELECT
    EMP_NO,
    SCORE,
    DENSE_RANK() OVER (ORDER BY SCORE DESC) AS rnk
  FROM yearly
) y

JOIN HR_EMPLOYEES e ON e.EMP_NO = y.EMP_NO

WHERE y.rnk = 1;

추가로 조만간 WINDOW FUNCTION (윈도우 함수)에 대해 정리하는 시간을 가져야겠다!