https://school.programmers.co.kr/learn/courses/30/lessons/276034

1. 문제 설명

SKILLCODES 테이블은 개발자들이 사용하는 프로그래밍 언어에 대한 정보를 담은 테이블입니다. SKILLCODES 테이블의 구조는 다음과 같으며, NAME, CATEGORY, CODE는 각각 스킬의 이름, 스킬의 범주, 스킬의 코드를 의미합니다. 스킬의 코드는 2진수로 표현했을 때 각 bit로 구분될 수 있도록 2의 제곱수로 구성되어 있습니다.

NAME	TYPE	UNIQUE	NULLABLE
NAME	VARCHAR(N)	Y	N
CATEGORY	VARCHAR(N)	N	N
CODE	INTEGER	Y	N

DEVELOPERS 테이블은 개발자들의 프로그래밍 스킬 정보를 담은 테이블입니다. DEVELOPERS 테이블의 구조는 다음과 같으며, ID, FIRST_NAME, LAST_NAME, EMAIL, SKILL_CODE는 각각 개발자의 ID, 이름, 성, 이메일, 스킬 코드를 의미합니다. SKILL_CODE 컬럼은 INTEGER 타입이고, 2진수로 표현했을 때 각 bit는 SKILLCODES 테이블의 코드를 의미합니다.

NAME	TYPE	UNIQUE	NULLABLE
ID	VARCHAR(N)	Y	N
FIRST_NAME	VARCHAR(N)	N	Y
LAST_NAME	VARCHAR(N)	N	Y
EMAIL	VARCHAR(N)	Y	N
SKILL_CODE	INTEGER	N	N

예를 들어 어떤 개발자의 SKILL_CODE가 400 (=b'110010000')이라면, 이는 SKILLCODES 테이블에서 CODE가 256 (=b'100000000'), 128 (=b'10000000'), 16 (=b'10000') 에 해당하는 스킬을 가졌다는 것을 의미합니다.

1.1 문제

DEVELOPERS 테이블에서 Python이나 C# 스킬을 가진 개발자의 정보를 조회하려 합니다. 조건에 맞는 개발자의 ID, 이메일, 이름, 성을 조회하는 SQL 문을 작성해 주세요.

결과는 ID를 기준으로 오름차순 정렬해 주세요.

예시
예를 들어 SKILLCODES 테이블이 다음과 같고,

NAME	CATEGORY	CODE
C++	Back End	4
JavaScript	Front End	16
Java	Back End	128
Python	Back End	256
C#	Back End	1024
React	Front End	2048
Vue	Front End	8192
Node.js	Back End	16384

DEVELOPERS 테이블이 다음과 같다면

ID	FIRST_NAME	LAST_NAME	EMAIL	SKILL_CODE
D165	Jerami	Edwards	jerami_edwards@grepp.co	400
D161	Carsen	Garza	carsen_garza@grepp.co	2048
D164	Kelly	Grant	kelly_grant@grepp.co	1024
D163	Luka	Cory	luka_cory@grepp.co	16384
D162	Cade	Cunningham	cade_cunningham@grepp.co	8452

다음과 같이 DEVELOPERS 테이블에 포함된 개발자 중 Python 스킬이나 C# 스킬을 가진 개발자의 정보가 결과에 나와야 합니다.

ID	EMAIL	FIRST_NAME	LAST_NAME
D162	cade_cunningham@grepp.co	Cade	Cunningham
D164	kelly_grant@grepp.co	Kelly	Grant
D165	jerami_edwards@grepp.co	Jerami	Edwards

D162번 개발자의 경우 SKILL_CODE가 8452 = 8192 + 256 +4 로 Vue, Python, Cpp 스킬을 보유하고 있습니다.
D164번 개발자의 경우 SKILL_CODE가 1024 로 C# 스킬을 보유하고 있습니다.
D165번 개발자의 경우 SKILL_CODE가 400 = 256 + 128 + 16 으로 Python, Java, JavaScript 스킬을 보유하고 있습니다.

2. 풀이

내 풀이1

set @python_code = (select CODE from SKILLCODES where NAME='Python');
set @c_sharp_code = (select CODE from SKILLCODES where NAME='C#');
select *	
from DEVELOPERS
where (SKILL_CODE & @python_code) <> 0
or (SKILL_CODE & @c_sharp_code) <> 0

프로그래머스 환경에서 실행이 되지 않았다.
온라인 테스트나 환경에서 SET을 사용해서 그런 것 같은데
논리적으로는 맞는 것 같지만 실행이 되지 않아서 확인이 필요하다.

내 풀이2

with codes as (
    select CODE
    from SKILLCODES
    where NAME = "Python" or NAME = "C#"
)
select distinct id,EMAIL, FIRST_NAME, LAST_NAME
from codes c
JOIN DEVELOPERS d
on c.CODE & d.SKILL_CODE
order by 1

GROUPBY 를 활용해 풀었는데, DINSTINCT 를 빼고 실행했을 때, 틀렸다고 나왔었다.

예를 들어, 만약 개발자가 Python + C# 둘 다 가지고 있었다면

• 예: SKILL_CODE = 1280 (Python 256 + C# 1024)

codes.CODE	DEVELOPERS.ID	SKILL_CODE	매칭 여부
256 (Python)	D162	1280	TRUE
1024 (C#)	D162	1280	TRUE

• JOIN 결과 → 2행
• 따라서 DISTINCT 없으면 중복 출력 → 정답과 다르게 됨

다른 사람 쿼리

SELECT ID, EMAIL, FIRST_NAME, LAST_NAME
FROM DEVELOPERS
WHERE (SKILL_CODE & (SELECT CODE FROM SKILLCODES WHERE NAME = 'Python')) <> 0
   OR (SKILL_CODE & (SELECT CODE FROM SKILLCODES WHERE NAME = 'C#')) <> 0
ORDER BY ID;

• 이건 distinct없어도 잘 돌아 간다.

3. 성능 비교

접근 방식	Full Table Scan 가능성	비트 연산 포함 여부	JOIN/CTE 오버헤드	인덱스 활용 가능 여부	종합 평가
풀이1 (SET 변수 + 비트 연산)	높음	있음	없음	없음	비트 연산 때문에 대규모 테이블에서는 느림
풀이2 (CTE + JOIN)	높음	있음	있음 (JOIN + CTE)	없음	JOIN과 CTE로 오버헤드 추가, 대규모에서 느림
서브쿼리 직접 사용	높음	있음	없음	없음	비트 연산 때문에 인덱스 활용 불가, 단순 구조로 약간 빠름

3.1 성능 개선 방안

1) 전제: 테이블 정규화

현재 구조:

• DEVELOPERS : ID, EMAIL, FIRST_NAME, LAST_NAME, SKILL_CODE(비트 마스크)
• SKILLCODES : NAME, CODE

→ 비트 연산은 인덱스 활용 불가
→ 따라서 개발자-스킬 관계를 별도 테이블로 분리

|DEVELOPER_SKILLS|
|----------------|
|DEV_ID          | -- 개발자 ID (FK)
|SKILL_CODE      | -- SKILL_CODE (FK)

• 각 개발자 스킬별로 한 줄씩 저장
• DEV_ID + SKILL_CODE에 복합 인덱스 생성 가능

2) 최적화 쿼리 (인덱스 활용 가능)

SELECT d.ID, d.EMAIL, d.FIRST_NAME, d.LAST_NAME
FROM DEVELOPERS d
JOIN DEVELOPER_SKILLS s 
  ON d.ID = s.DEV_ID
JOIN SKILLCODES c 
  ON s.SKILL_CODE = c.CODE
WHERE c.NAME IN ('Python', 'C#')
ORDER BY d.ID;

• DEVELOPER_SKILLS.SKILL_CODE와 SKILLCODES.CODE에 인덱스 활용 가능
• JOIN 조건과 IN 조건은 MySQL에서 인덱스를 잘 사용
• 비트 연산 없이 단순 비교로 Python/C# 포함 여부 체크 가능

3) 성능 비교 (인덱스 고려)

접근 방식	Full Table Scan 가능성	인덱스 활용	JOIN/CTE 오버헤드	대규모 데이터 성능
기존 비트 연산 (SET 변수/서브쿼리)	높음	없음	없음	느림, 수십만~수백만 건에서 Full Scan 발생
CTE + JOIN + 비트 연산	높음	없음	있음	느림, JOIN + CTE 오버헤드 추가
정규화 + SKILL 테이블 + 인덱스	낮음	있음 (DEV_ID + SKILL_CODE)	있음 (JOIN)	매우 빠름, 인덱스 활용으로 대규모에서도 안정적