[프로그래머스, Java] FrontEnd 개발자 찾기

💻 내가 작성한 코드

이번 문제에서 가장 중요했던 부분은 SKILL_CODE가 단순한 숫자가 아니라 각 스킬을 비트로 표현한 값이라는 점이었다.

SKILLCODES의 CODE는 2의 제곱수로 구성되어 있고, 개발자의 SKILL_CODE에는 해당 개발자가 가진 스킬의 비트가 켜져 있다.

그래서 특정 스킬을 가지고 있는지 확인하기 위해 MySQL의 비트 AND 연산자인 &를 사용했다.

SELECT DISTINCT
       D.ID,
       D.EMAIL,
       D.FIRST_NAME,
       D.LAST_NAME
FROM DEVELOPERS D
JOIN SKILLCODES S
  ON (D.SKILL_CODE & S.CODE) > 0
WHERE S.CATEGORY = 'Front End'
ORDER BY D.ID;

WHERE에서 Front End 스킬만 먼저 걸러내고, JOIN에서 개발자의 SKILL_CODE와 해당 스킬의 CODE를 & 연산했다.

& 연산은 어떻게 동작할까?

&는 두 숫자를 비트 단위로 비교하는 연산자다.

예를 들어 개발자의 SKILL_CODE가 400이라면:

400 = 110010000

문제에서 설명한 것처럼 256, 128, 16에 해당하는 비트가 켜져 있다.

따라서 JavaScript의 코드인 16과 비교하면:

400  = 110010000
16   = 000010000
----------------
400 & 16 = 000010000

결과가 16으로 0보다 크기 때문에 해당 개발자는 JavaScript 스킬을 가지고 있다고 판단할 수 있다.

반대로 가지고 있지 않은 스킬과 비교하면 결과가 0이 된다.

즉,

SKILL_CODE & CODE > 0

은 해당 개발자가 그 스킬을 가지고 있는지 확인하는 조건이라고 이해했다.

DISTINCT를 사용하는 이유

여기서 DISTINCT도 필요했다.

한 개발자가 JavaScript와 React처럼 여러 개의 Front End 스킬을 가지고 있다면 JOIN 결과가 개발자 한 명당 여러 행으로 만들어질 수 있기 때문이다.

예를 들어:

D161 + JavaScript
D161 + React

처럼 결과가 중복될 수 있다.

따라서

SELECT DISTINCT D.ID, D.EMAIL, D.FIRST_NAME, D.LAST_NAME

을 사용해 조회하는 전체 컬럼의 조합이 동일한 행을 하나로 합쳐줬다.

다시 말해 DISTINCT는 ID에만 적용되는 것이 아니라 SELECT에 작성한 모든 컬럼에 적용된다.

✨ 더 나은 방향

지금 작성한 코드는 정답이지만, JOIN 때문에 같은 개발자가 여러 번 조회될 수 있어서 DISTINCT가 필요하다.

이 문제는 "이 개발자가 Front End 스킬을 하나라도 가지고 있는가?"를 확인하는 문제이므로 EXISTS를 사용하는 방식도 깔끔하다.

SELECT
       D.ID,
       D.EMAIL,
       D.FIRST_NAME,
       D.LAST_NAME
FROM DEVELOPERS D
WHERE EXISTS (
    SELECT 1
    FROM SKILLCODES S
    WHERE S.CATEGORY = 'Front End'
      AND (D.SKILL_CODE & S.CODE) > 0
)
ORDER BY D.ID;

EXISTS는 조건을 만족하는 Front End 스킬이 하나라도 존재하면 해당 개발자를 조회한다.

따라서 JOIN처럼 개발자 한 명이 여러 행으로 만들어질 일이 없어 DISTINCT도 필요하지 않다.

개인적으로는 이 문제의 조건을 그대로 표현한다는 점에서 EXISTS 방식이 더 직관적인 것 같다.

📖 새로 배운 부분

1. & 연산자는 정수를 비트 단위로 비교하며, 두 값의 같은 위치에 1이 있는 경우 그 비트를 결과에 남긴다.
2. 이 문제에서는 SKILL_CODE & CODE > 0을 통해 개발자가 특정 스킬을 가지고 있는지 확인할 수 있었다.
3. DISTINCT는 특정 컬럼 하나가 아니라 SELECT에 지정한 전체 컬럼의 조합을 기준으로 중복을 제거한다.
4. JOIN으로 인해 같은 개발자가 여러 번 조회될 수 있는 상황에서는 DISTINCT를 사용할 수도 있지만, 존재 여부만 확인하면 되는 경우 EXISTS도 좋은 선택이 될 수 있다.

참고

프로그래머스