오웬의 개발 이야기

Binary Search Tree를 구현해보기 (TypeScript)

DevOwen — Fri, 10 Jul 2026 20:11:02 +0900

최근에 Typescript로 BST를 직접 구현해 보라는 질문을 받았는데 제대로 구현하지 못했다. 그래서 중요한 개념을 복습할 겸 하나씩 정리해 보고자 한다. with Codex

이 글은 정수 값만 저장하는 Binary Search Tree(BST) 를 TreeNode, BinarySearchTree 두 클래스로 직접 구현하는 흐름을 정리한 노트입니다. 먼저 의사코드로 생각을 고정하고, 그 다음 그림으로 포인터 이동을 확인한 뒤, 마지막에 TypeScript 코드로 옮깁니다.

이 구현의 규칙은 네 가지입니다.

value는 정수만 허용합니다.
한 노드의 왼쪽 서브트리에는 더 작은 값만 둡니다.
한 노드의 오른쪽 서브트리에는 더 큰 값만 둡니다.
중복 값은 삽입하지 않고 false를 반환합니다.

1. BST 규칙부터 잡기

BST는 이름 그대로 “검색을 빠르게 하기 위한 이진 트리”입니다. 핵심은 노드 하나를 기준으로 작은 값은 왼쪽, 큰 값은 오른쪽에 둔다는 점입니다.

의사코드로 쓰면 이렇게 시작할 수 있습니다.

BST 규칙

어떤 node가 있을 때
  node.left에 있는 모든 값은 node.value보다 작다
  node.right에 있는 모든 값은 node.value보다 크다

값을 찾거나 넣을 때
  비교 대상 value가 node.value보다 작으면 왼쪽으로 간다
  비교 대상 value가 node.value보다 크면 오른쪽으로 간다
  같으면 찾은 것이다

이 규칙 덕분에 모든 노드를 무조건 훑지 않고, 비교할 때마다 탐색 범위를 왼쪽 또는 오른쪽으로 줄일 수 있습니다.

2. 클래스 책임 나누기

TreeNode는 값 하나와 왼쪽/오른쪽 포인터를 책임지고, BinarySearchTree는 루트 노드와 삽입, 검색, 삭제, 순회 같은 동작을 책임집니다.

먼저 TreeNode 의사코드는 단순합니다.

CLASS TreeNode
  value
  left
  right

  CONSTRUCTOR(value)
    if value is not integer
      throw error

    this.value = value
    this.left = null
    this.right = null

TypeScript에서는 number 타입만으로 정수를 보장할 수 없습니다. 1.5도 number이기 때문입니다. 그래서 런타임에서 Number.isInteger(value)로 한 번 더 검사합니다.

function assertInteger(value: number): void {
  if (!Number.isInteger(value)) {
    throw new TypeError("value must be an integer");
  }
}

class TreeNode {
  value: number;
  left: TreeNode | null;
  right: TreeNode | null;

  constructor(value: number) {
    assertInteger(value);
    this.value = value;
    this.left = null;
    this.right = null;
  }
}

3. insert(value) 의사코드

삽입은 루트부터 시작해서 비교하며 내려갑니다. 값이 현재 노드보다 작으면 왼쪽, 크면 오른쪽입니다. 내려가다가 null 포인터를 만나면 그 자리가 새 노드의 위치입니다.

METHOD insert(value)
  if value is not integer
    throw error

  if root is null
    root = new TreeNode(value)
    return true

  current = root

  LOOP
    if value == current.value
      return false

    if value < current.value
      if current.left is null
        current.left = new TreeNode(value)
        return true

      current = current.left
    else
      if current.right is null
        current.right = new TreeNode(value)
        return true

      current = current.right

이 의사코드를 그대로 TypeScript로 바꾸면 다음과 같습니다.

insert(value: number): boolean {
  assertInteger(value);

  if (this.root === null) {
    this.root = new TreeNode(value);
    return true;
  }

  let current: TreeNode = this.root;

  while (true) {
    if (value === current.value) {
      return false;
    }

    if (value < current.value) {
      if (current.left === null) {
        current.left = new TreeNode(value);
        return true;
      }

      current = current.left;
    } else {
      if (current.right === null) {
        current.right = new TreeNode(value);
        return true;
      }

      current = current.right;
    }
  }
}

while (true)를 써도 괜찮은 이유는 내부에서 반드시 return하는 조건이 있기 때문입니다. 빈 자리를 찾으면 true, 중복 값을 만나면 false로 끝납니다.

4. contains(value) 의사코드

검색은 삽입보다 더 단순합니다. 새 노드를 만들지 않고, 같은 비교 규칙으로 내려가면서 값이 있는지만 확인합니다.

METHOD contains(value)
  if value is not integer
    throw error

  current = root

  while current is not null
    if value == current.value
      return true

    if value < current.value
      current = current.left
    else
      current = current.right

  return false

TypeScript 코드입니다.

contains(value: number): boolean {
  assertInteger(value);

  let current = this.root;

  while (current !== null) {
    if (value === current.value) {
      return true;
    }

    current = value < current.value ? current.left : current.right;
  }

  return false;
}

current가 null이 되었다는 것은 더 내려갈 자식이 없다는 뜻입니다. 즉, 그 값은 트리에 없습니다.

5. remove(value) 의사코드

삭제는 삽입/검색보다 한 단계 어렵습니다. 삭제할 노드의 자식 개수에 따라 처리가 달라지기 때문입니다.

세 경우만 기억하면 됩니다.

자식이 없으면 부모가 그 자리를 null로 바꿉니다.
자식이 하나면 삭제할 노드 대신 그 자식을 부모에게 연결합니다.
자식이 둘이면 오른쪽 서브트리에서 가장 작은 값, 즉 successor를 찾아 현재 노드의 값으로 복사한 뒤 successor 원본 노드를 삭제합니다.

METHOD remove(value)
  root, removed = removeNode(root, value)
  return removed

METHOD removeNode(node, value)
  if node is null
    return null, false

  if value < node.value
    node.left, removed = removeNode(node.left, value)
    return node, removed

  if value > node.value
    node.right, removed = removeNode(node.right, value)
    return node, removed

  // 여기까지 왔다면 node.value == value

  if node has no child
    return null, true

  if node has only right child
    return node.right, true

  if node has only left child
    return node.left, true

  successor = find minimum node in node.right
  node.value = successor.value
  node.right, _ = removeNode(node.right, successor.value)
  return node, true

삭제는 부모 포인터를 직접 들고 다니는 방식으로도 구현할 수 있습니다. 여기서는 재귀 함수가 “삭제 후 이 자리에 다시 연결할 노드”를 반환하게 만들었습니다. 그래서 루트를 삭제하는 경우도 같은 코드로 처리됩니다.

6. traversal 의사코드

순회는 트리의 모든 값을 어떤 순서로 방문할지 정하는 규칙입니다. BST에서 가장 자주 쓰는 것은 inOrder입니다. 왼쪽 → 현재 노드 → 오른쪽 순서로 방문하면 값이 오름차순으로 나옵니다.

METHOD inOrder()
  result = []

  FUNCTION walk(node)
    if node is null
      return

    walk(node.left)
    result.push(node.value)
    walk(node.right)

  walk(root)
  return result

preOrder와 postOrder는 방문 위치만 바뀝니다.

preOrder:  node → left → right
inOrder:   left → node → right
postOrder: left → right → node

7. 최종 TypeScript 구현

아래 코드는 위 의사코드를 하나로 합친 완성본입니다.

function assertInteger(value: number): void {
  if (!Number.isInteger(value)) {
    throw new TypeError("value must be an integer");
  }
}

class TreeNode {
  value: number;
  left: TreeNode | null;
  right: TreeNode | null;

  constructor(value: number) {
    assertInteger(value);
    this.value = value;
    this.left = null;
    this.right = null;
  }
}

class BinarySearchTree {
  root: TreeNode | null;

  constructor() {
    this.root = null;
  }

  insert(value: number): boolean {
    assertInteger(value);

    if (this.root === null) {
      this.root = new TreeNode(value);
      return true;
    }

    let current: TreeNode = this.root;

    while (true) {
      if (value === current.value) {
        return false;
      }

      if (value < current.value) {
        if (current.left === null) {
          current.left = new TreeNode(value);
          return true;
        }

        current = current.left;
      } else {
        if (current.right === null) {
          current.right = new TreeNode(value);
          return true;
        }

        current = current.right;
      }
    }
  }

  contains(value: number): boolean {
    assertInteger(value);

    let current = this.root;

    while (current !== null) {
      if (value === current.value) {
        return true;
      }

      current = value < current.value ? current.left : current.right;
    }

    return false;
  }

  remove(value: number): boolean {
    assertInteger(value);

    const [nextRoot, removed] = this.removeNode(this.root, value);
    this.root = nextRoot;
    return removed;
  }

  inOrder(): number[] {
    const result: number[] = [];

    const walk = (node: TreeNode | null): void => {
      if (node === null) {
        return;
      }

      walk(node.left);
      result.push(node.value);
      walk(node.right);
    };

    walk(this.root);
    return result;
  }

  preOrder(): number[] {
    const result: number[] = [];

    const walk = (node: TreeNode | null): void => {
      if (node === null) {
        return;
      }

      result.push(node.value);
      walk(node.left);
      walk(node.right);
    };

    walk(this.root);
    return result;
  }

  postOrder(): number[] {
    const result: number[] = [];

    const walk = (node: TreeNode | null): void => {
      if (node === null) {
        return;
      }

      walk(node.left);
      walk(node.right);
      result.push(node.value);
    };

    walk(this.root);
    return result;
  }

  private removeNode(node: TreeNode | null, value: number): [TreeNode | null, boolean] {
    if (node === null) {
      return [null, false];
    }

    if (value < node.value) {
      const [nextLeft, removed] = this.removeNode(node.left, value);
      node.left = nextLeft;
      return [node, removed];
    }

    if (value > node.value) {
      const [nextRight, removed] = this.removeNode(node.right, value);
      node.right = nextRight;
      return [node, removed];
    }

    if (node.left === null && node.right === null) {
      return [null, true];
    }

    if (node.left === null) {
      return [node.right, true];
    }

    if (node.right === null) {
      return [node.left, true];
    }

    const successor = this.findMinNode(node.right);
    node.value = successor.value;

    const [nextRight] = this.removeNode(node.right, successor.value);
    node.right = nextRight;

    return [node, true];
  }

  private findMinNode(node: TreeNode): TreeNode {
    let current = node;

    while (current.left !== null) {
      current = current.left;
    }

    return current;
  }
}

8. 사용 예시

const bst = new BinarySearchTree();

for (const value of [8, 3, 10, 1, 6, 14, 4, 7, 13]) {
  bst.insert(value);
}

console.log(bst.inOrder());
// [1, 3, 4, 6, 7, 8, 10, 13, 14]

console.log(bst.contains(6));
// true

console.log(bst.contains(5));
// false

console.log(bst.insert(6));
// false: 중복 값은 삽입하지 않음

console.log(bst.remove(3));
// true

console.log(bst.inOrder());
// [1, 4, 6, 7, 8, 10, 13, 14]

9. 스스로 점검할 부분

insert에서 root === null인 첫 삽입을 따로 처리했는가?
작으면 왼쪽, 크면 오른쪽이라는 규칙이 insert와 contains에 똑같이 적용되는가?
중복 값을 어떻게 처리할지 정했는가? 이 글에서는 false를 반환합니다.
remove에서 리프, 자식 1개, 자식 2개 케이스를 모두 처리했는가?
inOrder() 결과가 항상 정렬된 배열인지 확인했는가?
Number.isInteger(value)로 정수 검사를 하고 있는가?

10. 시간 복잡도

트리의 높이를 h라고 하면 insert, contains, remove는 평균적으로 O(h)입니다. 트리가 균형에 가까우면 h = log n이므로 O(log n)에 가깝고, 한쪽으로 치우치면 h = n이 되어 O(n)까지 나빠질 수 있습니다.

이 과제의 핵심은 “클래스를 만드는 법”보다 “비교 결과에 따라 포인터를 왼쪽 또는 오른쪽으로 이동시키는 감각”입니다. 그 감각만 잡히면 삽입과 검색은 거의 같은 코드로 보이고, 삭제도 세 가지 케이스로 나누어 차분히 처리할 수 있습니다.

위클리 인사이트 By 오웬 (Y26W28)

DevOwen — Fri, 10 Jul 2026 18:00:50 +0900

26.07.06 ~ 26.07.10

나의 필요에 의한 스킬을 처음 만들어 보았다

나는 지금까지 누군가가 만든 스킬을 사용하는 것에 익숙했는데, 최근에 처음으로 내가 필요에 의해서 반복되는 작업을 스킬로 만든 사례가 있었다.

나는 뱅크샐러드에서 가계부 관리를 한다. 뱅크샐러드와 내 모든 은행과, 카드를 연동하면 실시간으로 나의 자산 내역과 지출, 수입 내역을 관리할 수 있어서 편리하게 잘 쓰고 있다. 뱅크샐러드에서 이 모든 자산 관련 내용을 엑셀 파일로 추출할 수 있는데, 한 달에 한 번씩 내가 수동으로 하고 있던 재무관리를 AI 스킬을 만들어서 하게 해 보았다.

뱅크 샐러드 앱에서 파일 추출 후 Codex에 파일 업로드까지만 내가 하고 내가 만든 재무분석 스킬을 돌리면 AI가 알아서,

나의 현재 자산 현황 (현금, 주식, 연금 등 비율 포함)
나의 최근 한 달 수입과 지출 카테고리 분석
나의 주식 포트폴리오 분석 및 리밸런싱 가이드

등의 리포트를 만들어서 구글 스프레드시트에 업로드해 준다. 상당히 편하다. 나는 그냥 커피 한 잔 마시면서 기다리면 몇 분 만에 AI가 알아서 내 자산을 분석해 주는 것이다.

앞으로 이와 같이 AI를 내 삶에서 반복되던 작업에 사용할 수 있는 창구를 찾아보아야겠다.

집을 마련하는 것에 대한 고민

요즘 나는 앞으로 사랑하는 사람과 함께 살 집을 마련하는 데 관심이 많다.

<나의 첫 번째 부동산 교과서>라는 송희구 작가님의 책도 사서 읽어 보고 있다. 요즘에는 데이트를 할 때 네이버 부동산에서 관심 있는 지역들의 매물들을 보는 것이 소소한 취미가 되었다.

마음 같아서는 신축, 상급지, 아파트, 매매, 역세권 등등 다 챙기고 싶지만 예산이 현실적으로 제한이 있다 보니, 무엇이 더 우리에게 중요한 조건인지를 살펴보게 된다. 예를 들면 나는 구축 아파트에 살 수는 있지만, 역에서 멀거나 회사에서 먼 집은 싫다.

그리고 집을 사는 건 마음대로 할 수 있더라도, 파는 건 우리 마음대로 되는 것이 아니기 때문에 처음에는 전세로 시작해야겠다는 마음이 들었다. 그런데 여기서 또 고민은 전세에 많은 돈이 묶여 있는 것이 아깝다는 점과 그 시간 동안 다른 집들은 가격이 오를 텐데 이에 대한 상대적 박탈감 등이 걱정 요인으로 떠올랐다.

앞으로 데이트를 하면서 우리가 매물을 눈여겨본 여러 지역들을 돌아다녀 볼 생각이다. 이렇게 열 군데 정도 돌아다녀 보면 또 생각이 바뀌게 되지 않을까 하는 생각이 든다.

[LeetCode] 698. Partition to K Equal Sum Subsets (Medium)

DevOwen — Thu, 9 Jul 2026 00:09:47 +0900

이 문제를 풀기 위해서는 비트마스크 DP에 대해서 알아야 한다.

배열의 길이가 최대 16이기 때문에, 각 원소를 썼는지 안 썼는지를 하나의 비트마스크로 표현할 수 있다. 그리고 어떤 원소들을 이미 사용했는지 알 수 있으면, 지금 만들고 있는 부분집합의 합이 목표값에서 어디까지 차 있는지도 계산할 수 있다.

0. 필요한 개념 먼저 정리하기

먼저 이 문제의 목표는 k개의 부분집합을 만드는 것이다. 모든 부분집합의 합이 같아야 하므로, 전체 합을 k로 나눈 값이 각 부분집합의 목표 합이 된다.

예를 들어 nums = [4,3,2,3,5,2,1], k = 4라면 전체 합은 20이고 각 부분집합의 목표 합은 5다. 따라서 (5), (4,1), (3,2), (3,2)처럼 모든 그룹이 합 5로 끝나야 한다.

여기서 중요한 전제는 두 가지다.

전체 합이 k로 나누어떨어지지 않으면 답은 바로 false다.
어떤 숫자가 목표 합보다 크면 그 숫자는 어떤 부분집합에도 들어갈 수 없으므로 답은 false다.

그다음 필요한 개념이 비트마스크다. 배열의 원소가 최대 16개이므로, 2^16개의 사용 상태를 충분히 탐색할 수 있다. 예를 들어 정렬된 배열이 [5, 4, 3, 3, 2, 2, 1]일 때, 마스크 0000011은 앞의 두 원소 5, 4를 이미 사용했다는 뜻으로 볼 수 있다.

DP 상태는 다음처럼 정의한다.

dp[mask] = mask에 포함된 원소들을 사용했을 때,
           현재 채우는 중인 부분집합의 합

다만 현재 부분집합의 합은 항상 target보다 작게 유지하면 된다. 부분집합 하나가 정확히 target이 되는 순간에는 다음 부분집합을 새로 채우기 시작하므로, 값을 target으로 나눈 나머지로 저장한다.

즉 dp[mask] = usedSum % target이라고 생각할 수 있다. 도달할 수 없는 상태는 -1로 둔다.

1. 접근 : 문제를 단순화 하기

문제는 정수 배열 nums를 k개의 비어 있지 않은 부분집합으로 나누되, 모든 부분집합의 합이 같게 만들 수 있는지 묻는다. k는 nums.length 이하이고, nums.length는 최대 16이다.

모든 부분집합을 직접 만들어보면 경우의 수가 매우 커진다. 하지만 원소 수가 16개로 작다는 점을 이용하면, "어떤 원소를 이미 골랐는가"를 상태로 삼는 DP가 가능하다.

먼저 전체 합을 sum이라고 하자.

const total = nums.reduce((acc, cur) => acc + cur, 0);

if (total % k !== 0) {
  return false;
}

const target = total / k;

이제 문제는 nums의 모든 원소를 사용하면서, 매번 target을 넘지 않게 숫자를 추가할 수 있는지 확인하는 문제로 바뀐다.

2. 핵심 아이디어

dp[mask]가 -1이 아니라면, 그 상태는 실제로 만들 수 있는 상태다. 이 상태에서 아직 사용하지 않은 원소 nums[i]를 하나 더 넣어본다.

현재 부분집합의 합이 dp[mask]이고, 다음 숫자가 nums[i]라면 다음 합은 다음과 같다.

next = dp[mask] + nums[i]

이때 next > target이면 현재 부분집합이 목표 합을 초과하므로 그 선택은 버린다. 반대로 next <= target이면 다음 마스크로 이동할 수 있다.

다음 상태의 값은 next % target으로 저장한다.

next < target이면 아직 같은 부분집합을 채우는 중이다.
next === target이면 부분집합 하나가 완성되었으므로 나머지가 0이 되고, 다음 부분집합을 새로 시작한다.

결국 모든 원소를 사용한 마스크 fullMask에 도달할 수 있고, 그때 나머지가 0이면 모든 부분집합이 정확히 target으로 끝난 것이다.

3. 단계별로 구현하기

3-1. 목표 합 계산과 빠른 예외 처리

전체 합이 k로 나누어떨어지지 않으면 같은 합의 부분집합을 만들 수 없다. 또한 가장 큰 숫자가 target보다 크면 그 숫자를 담을 수 있는 부분집합이 없다.

const total = nums.reduce((acc, cur) => acc + cur, 0);

if (total % k !== 0) {
  return false;
}

const target = total / k;

nums.sort((a, b) => b - a);

if (nums[0] > target) {
  return false;
}

내림차순 정렬은 필수는 아니지만, 큰 수부터 확인하면 불가능한 선택을 더 빨리 걸러낼 수 있다.

3-2. 비트마스크 DP 배열 준비하기

원소가 n개라면 가능한 사용 상태는 2^n개다. 아무 원소도 사용하지 않은 상태 0은 만들 수 있으므로 dp[0] = 0으로 시작한다.

const n = nums.length;
const size = 1 << n;
const dp = new Array(size).fill(-1);

dp[0] = 0;

dp[mask] === -1이면 아직 도달할 수 없는 상태이므로 전이를 시도하지 않는다.

3-3. 아직 쓰지 않은 숫자를 하나씩 추가하기

각 마스크에서 아직 사용하지 않은 원소를 골라본다. 목표 합을 넘지 않는 경우에만 다음 마스크를 reachable 상태로 만든다.

for (let mask = 0; mask < size; mask++) {
  if (dp[mask] === -1) {
    continue;
  }

  for (let i = 0; i < n; i++) {
    if ((mask & (1 << i)) !== 0) {
      continue;
    }

    const next = dp[mask] + nums[i];

    if (next > target) {
      continue;
    }

    const nextMask = mask | (1 << i);
    dp[nextMask] = next % target;
  }
}

다만 같은 nextMask가 이미 도달 가능한 상태라면 다시 계산할 필요가 없다. 그래서 최종 구현에서는 dp[nextMask] !== -1인 경우를 건너뛴다.

4. 최종 구현

/**
 * @param {number[]} nums
 * @param {number} k
 * @return {boolean}
 */
var canPartitionKSubsets = function(nums, k) {
  const total = nums.reduce((acc, cur) => acc + cur, 0);

  if (total % k !== 0) {
    return false;
  }

  const target = total / k;

  nums.sort((a, b) => b - a);

  if (nums[0] > target) {
    return false;
  }

  const n = nums.length;
  const size = 1 << n;
  const dp = new Array(size).fill(-1);

  dp[0] = 0;

  for (let mask = 0; mask < size; mask++) {
    if (dp[mask] === -1) {
      continue;
    }

    for (let i = 0; i < n; i++) {
      if ((mask & (1 << i)) !== 0) {
        continue;
      }

      const next = dp[mask] + nums[i];

      if (next > target) {
        continue;
      }

      const nextMask = mask | (1 << i);

      if (dp[nextMask] !== -1) {
        continue;
      }

      dp[nextMask] = next % target;
    }
  }

  return dp[size - 1] === 0;
};

5. 시간복잡도

n을 nums.length라고 하자.

시간복잡도: O(n * 2^n)
공간복잡도: O(2^n)

가능한 마스크가 2^n개이고, 각 마스크마다 최대 n개의 원소를 추가해보기 때문이다. 이 문제에서는 n <= 16이므로 이 방식이 충분히 가능하다.

참고자료

LeetCode: https://leetcode.com/problems/partition-to-k-equal-sum-subsets/

[LeetCode] 1125. Smallest Sufficient Team (Hard)

DevOwen — Wed, 8 Jul 2026 02:29:03 +0900

이 문제를 풀기 위해서는 비트마스크 DP에 대해서 알아야 한다.

비트마스크는 여러 개의 참/거짓 상태를 하나의 정수로 압축하는 방법이다. 이 문제에서는 필요한 스킬의 개수가 최대 16개이므로, 각 스킬을 비트 하나에 대응시키면 어떤 팀이 가진 스킬 조합을 숫자 하나로 표현할 수 있다. 그리고 그 숫자를 DP의 상태로 쓰면, "이 스킬 조합을 만들 수 있는 가장 작은 팀"을 차근차근 갱신할 수 있다.

0. 필요한 개념 먼저 정리하기

먼저 비트마스크부터 보자. 예를 들어 필요한 스킬이 ["java", "nodejs", "reactjs"]라면 다음처럼 위치를 정할 수 있다.

java -> 0번 비트
nodejs -> 1번 비트
reactjs -> 2번 비트

그러면 ["nodejs", "reactjs"]를 가진 사람은 110이라는 마스크로 표현된다. 팀에 사람을 추가할 때는 기존 팀의 마스크와 새 사람의 마스크를 OR 연산하면 된다.

const nextMask = mask | personMask;

이제 DP 상태를 정의할 수 있다.

dp[mask] = mask에 해당하는 스킬 조합을 만들 수 있는 가장 작은 팀

예를 들어 dp[0101] = [0, 3]이라면, 사람 0번과 3번을 고르면 0101에 해당하는 스킬들을 커버할 수 있고, 지금까지 발견한 방법 중 팀 크기가 가장 작다는 뜻이다.

1. 접근 : 문제를 단순화 하기

문제는 필요한 스킬 목록 req_skills와 각 사람이 가진 스킬 목록 people이 주어졌을 때, 모든 필요 스킬을 커버하는 가장 작은 사람 인덱스 집합을 찾는 것이다. 정답은 여러 개일 수 있고, 그중 아무 하나를 반환하면 된다.

사람 수는 최대 60명이다. 사람의 모든 부분집합을 검사하면 2^60이 되므로 불가능하다. 하지만 필요한 스킬 수는 최대 16개다. 따라서 사람 조합을 직접 상태로 두지 말고, 스킬 조합을 상태로 두면 가능한 상태 수는 최대 2^16 = 65536개로 줄어든다.

여기서 중요한 포인트는 다음과 같다.

사람은 최대 60명이지만, 스킬 조합은 최대 65536개뿐이다.
각 사람을 하나씩 보면서, 그 사람을 추가했을 때 더 작은 팀이 만들어지는지만 확인하면 된다.
최종 목표 상태는 모든 비트가 켜진 fullMask다.

2. 핵심 아이디어

각 사람을 순서대로 보면서 DP를 갱신한다.

현재 어떤 스킬 조합 mask를 만들 수 있다고 하자. 여기에 사람 i를 추가하면 새 조합은 mask | personMask가 된다. 만약 이 새 조합을 만들 팀이 아직 없거나, 기존 팀보다 dp[mask] + i가 더 작다면 갱신한다.

주의할 점은 한 사람을 처리하는 동안 그 사람을 같은 팀에 여러 번 넣지 않도록, 갱신 전의 DP 배열을 복사해서 기준으로 삼는 것이다.

const before = dp.slice();

이렇게 하면 현재 사람 i를 추가하는 전이는 항상 "사람 i를 보기 전까지 만들어진 팀"에서만 출발한다.

3. 단계별로 구현하기

3-1. 스킬을 비트 위치로 바꾸기

먼저 필요한 스킬마다 비트 위치를 부여한다.

const skillToBit = new Map();
for (let i = 0; i < req_skills.length; i++) {
  skillToBit.set(req_skills[i], i);
}

그리고 각 사람의 스킬 목록도 하나의 마스크로 바꾼다.

let personMask = 0;
for (const skill of people[i]) {
  personMask |= 1 << skillToBit.get(skill);
}

3-2. DP 배열 초기화하기

dp[mask]에는 해당 스킬 조합을 만드는 사람 인덱스 배열을 저장한다. 아직 만들 수 없는 조합은 null로 둔다.

const fullMask = (1 << req_skills.length) - 1;
const dp = Array(1 << req_skills.length).fill(null);
dp[0] = [];

아무 스킬도 필요하지 않은 상태 0은 빈 팀으로 만들 수 있으므로 dp[0] = []가 된다.

3-3. 사람을 하나씩 추가해보기

각 사람에 대해 기존의 모든 스킬 조합을 확인한다. 새 조합이 더 작은 팀으로 만들어진다면 갱신한다.

const before = dp.slice();
for (let mask = 0; mask <= fullMask; mask++) {
  if (before[mask] === null) continue;

  const nextMask = mask | personMask;
  if (dp[nextMask] === null || dp[nextMask].length > before[mask].length + 1) {
    dp[nextMask] = [...before[mask], i];
  }
}

이때 스킬을 하나도 새로 추가하지 못하는 사람이어도 로직은 안전하다. nextMask가 기존 mask와 같아지고, 팀 크기는 오히려 늘어나므로 갱신되지 않는다.

4. 최종 구현

/**
 * @param {string[]} req_skills
 * @param {string[][]} people
 * @return {number[]}
 */
var smallestSufficientTeam = function(req_skills, people) {
  const skillToBit = new Map();
  for (let i = 0; i < req_skills.length; i++) {
    skillToBit.set(req_skills[i], i);
  }

  const fullMask = (1 << req_skills.length) - 1;
  const dp = Array(1 << req_skills.length).fill(null);
  dp[0] = [];

  for (let i = 0; i < people.length; i++) {
    let personMask = 0;
    for (const skill of people[i]) {
      personMask |= 1 << skillToBit.get(skill);
    }

    const before = dp.slice();
    for (let mask = 0; mask <= fullMask; mask++) {
      if (before[mask] === null) continue;

      const nextMask = mask | personMask;
      if (dp[nextMask] === null || dp[nextMask].length > before[mask].length + 1) {
        dp[nextMask] = [...before[mask], i];
      }
    }
  }

  return dp[fullMask];
};

5. 시간복잡도

m을 필요한 스킬 개수, n을 사람 수라고 하자.

시간복잡도: O(n * 2^m * m)
공간복잡도: O(2^m * m)

각 사람마다 가능한 모든 스킬 조합을 순회한다. 또한 팀 배열을 복사할 때 최대 m명 정도의 인덱스를 담을 수 있으므로 위와 같이 볼 수 있다. m <= 16이기 때문에 이 방식은 충분히 통과 가능하다.

참고자료

LeetCode: https://leetcode.com/problems/smallest-sufficient-team/

[LeetCode] 1820. Maximum Number of Accepted Invitations (Medium)

DevOwen — Wed, 8 Jul 2026 02:02:04 +0900

이 문제를 풀기 위해서는 이분 그래프 최대 매칭(Bipartite Matching), 그중에서도 Kuhn Algorithm에 대해서 알아야 한다.

Kuhn Algorithm은 이분 그래프에서 매칭의 수를 하나씩 늘려 가는 알고리즘이다. 핵심은 단순히 "빈 자리를 찾는다"가 아니라, 이미 누군가 차지한 자리라도 기존 매칭을 다른 곳으로 옮길 수 있다면 전체 매칭 수를 늘릴 수 있다는 점이다.

이 문제에서 남학생과 여학생은 자연스럽게 두 그룹으로 나뉜다.

왼쪽 그룹: 남학생
오른쪽 그룹: 여학생
grid[i][j] === 1: i번 남학생이 j번 여학생을 초대할 수 있음

따라서 문제는 "가능한 초대 관계들 중 서로 겹치지 않게 최대 몇 쌍을 만들 수 있는가?"로 바뀐다.

1. 접근 : 문제를 단순화 하기

문제에서는 m x n 크기의 grid가 주어진다.

grid[i][j]가 1이면 i번 boy가 j번 girl을 초대할 수 있고, 0이면 초대할 수 없다.

여기서 제한 조건이 하나씩 붙는다.

한 boy는 최대 한 명의 girl만 초대할 수 있다.
한 girl은 최대 한 명의 boy의 초대만 받을 수 있다.
최대로 성사될 수 있는 초대 수를 구해야 한다.

즉, 어떤 boy가 어떤 girl을 선택하면 그 boy와 girl은 더 이상 다른 매칭에 사용할 수 없다. 이것은 그래프 관점에서 보면 정확히 matching이다.

처음에는 단순하게 greedy로 풀 수 있을 것처럼 보인다. 예를 들어 각 boy마다 가능한 첫 girl을 바로 선택하면 될 것 같다.

하지만 greedy는 쉽게 깨진다.

grid = [
  [1, 1],
  [1, 0]
]

만약 0번 boy가 0번 girl을 먼저 선택하면 1번 boy는 더 이상 선택할 girl이 없다. 결과는 1개다.

하지만 0번 boy가 1번 girl을 선택하고, 1번 boy가 0번 girl을 선택하면 결과는 2개가 된다.

여기서 중요한 포인트는 "이미 매칭된 girl을 포기해야 하나?"가 아니라, "그 girl과 매칭되어 있던 boy를 다른 곳으로 옮길 수 있나?"를 봐야 한다는 점이다.

이 과정을 DFS로 수행하는 방식이 Kuhn Algorithm이다.

2. Kuhn Algorithm이란?

Kuhn Algorithm은 이분 그래프의 maximum matching을 구하는 대표적인 augmenting path 기반 알고리즘이다.

여기서 matching은 서로 겹치지 않는 간선들의 집합이다. 이 문제에서는 "성사된 초대 쌍"이라고 보면 된다.

augmenting path는 현재 매칭 상태에서 매칭 수를 1개 늘릴 수 있는 경로를 의미한다.

조금 더 쉽게 말하면 다음과 같다.

아직 매칭을 시도하지 않은 boy에서 시작한다.
이 boy가 초대할 수 있는 girl을 하나씩 본다.
girl이 비어 있으면 바로 매칭한다.
girl이 이미 다른 boy와 매칭되어 있다면, 그 기존 boy가 다른 girl로 이동할 수 있는지 DFS로 확인한다.
이동할 수 있다면 기존 boy를 옮기고, 현재 boy를 이 girl과 매칭한다.

이렇게 하면 단순히 빈 자리만 찾는 것이 아니라, 기존 배치를 재조정하면서 전체 매칭 수를 늘릴 수 있다.

Kuhn Algorithm은 종종 Hungarian Algorithm이라는 이름으로도 설명된다. 다만 알고리즘 문맥에 따라 "Hungarian Algorithm"은 비용이 있는 assignment problem을 푸는 알고리즘을 가리키기도 한다. 이 문제에서 쓰는 방식은 DFS로 augmenting path를 찾는 Kuhn Algorithm이라고 부르는 편이 더 정확하다.

3. 핵심 아이디어

우리는 girl 기준으로 현재 매칭 상태를 관리한다.

const matchGirl = Array(n).fill(-1);

matchGirl[j]는 j번 girl이 현재 어떤 boy와 매칭되어 있는지를 의미한다.

matchGirl[j] === -1: 아직 아무 boy와도 매칭되지 않음
matchGirl[j] === i: j번 girl은 현재 i번 boy와 매칭됨

이제 각 boy에 대해 DFS를 한 번씩 시도한다.

for (let boy = 0; boy < m; boy++) {
  const seen = Array(n).fill(false);
  if (canInvite(boy, seen)) answer++;
}

여기서 seen은 DFS 한 번 동안 이미 확인한 girl을 표시한다.

왜 매번 새로 만들까?

각 boy가 매칭을 시도할 때는 새로운 augmenting path를 찾는 것이다. 이전 boy의 DFS에서 어떤 girl을 봤는지는 현재 boy의 탐색과 직접적인 관련이 없다. 그래서 outer loop에서 boy가 바뀔 때마다 seen도 새로 만든다.

반면 matchGirl은 전체 매칭 상태이므로 끝까지 유지한다.

4. 단계별로 구현하기

4-1. 현재 매칭 상태 만들기

먼저 boy 수와 girl 수를 구하고, girl 기준 매칭 배열을 만든다.

const m = grid.length;
const n = grid[0].length;
const matchGirl = Array(n).fill(-1);

이 문제의 제약은 m, n < 200이기 때문에 DFS 기반 Kuhn Algorithm으로 충분하다.

4-2. canInvite 함수 정의하기

canInvite(boy, seen)은 현재 boy가 새로운 매칭을 만들 수 있는지 확인한다.

const canInvite = (boy, seen) => {
  for (let girl = 0; girl < n; girl++) {
    if (grid[boy][girl] === 0 || seen[girl]) continue;

    seen[girl] = true;

    if (matchGirl[girl] === -1 || canInvite(matchGirl[girl], seen)) {
      matchGirl[girl] = boy;
      return true;
    }
  }

  return false;
};

여기서 가장 중요한 부분은 이 조건이다.

if (matchGirl[girl] === -1 || canInvite(matchGirl[girl], seen)) {
  matchGirl[girl] = boy;
  return true;
}

두 가지 경우에 현재 boy를 이 girl과 매칭할 수 있다.

matchGirl[girl] === -1
- girl이 비어 있으므로 바로 매칭할 수 있다.
canInvite(matchGirl[girl], seen)이 true
- 이 girl과 이미 매칭된 기존 boy가 다른 girl로 이동할 수 있다.
- 그러면 이 girl을 현재 boy에게 넘겨도 전체 매칭이 유지된다.

이 두 번째 경우가 Kuhn Algorithm의 핵심이다.

4-3. 모든 boy에 대해 매칭 시도하기

이제 모든 boy를 시작점으로 삼아 DFS를 실행한다.

let answer = 0;

for (let boy = 0; boy < m; boy++) {
  const seen = Array(n).fill(false);
  if (canInvite(boy, seen)) {
    answer++;
  }
}

canInvite가 true를 반환했다는 것은 현재 boy를 포함해서 매칭 수를 1개 늘릴 수 있었다는 뜻이다.

따라서 answer를 1 증가시킨다.

5. 예제로 따라가기

예를 들어 다음과 같은 입력이 있다고 하자.

grid = [
  [1, 1, 1],
  [1, 0, 1],
  [0, 0, 1]
]

가능한 한 가지 최적 매칭은 다음과 같다.

Boy 0 -> Girl 1
Boy 1 -> Girl 0
Boy 2 -> Girl 2

총 3개의 초대가 성사된다.

여기서 Boy 2는 Girl 2만 가능하다. 만약 앞에서 Girl 2를 다른 boy가 가져갔다면, DFS는 그 boy를 다른 girl로 옮길 수 있는지 확인한다. 옮길 수 있다면 Girl 2를 Boy 2에게 주고, 기존 boy는 다른 girl과 매칭한다.

이렇게 매칭을 "다시 배치"할 수 있기 때문에 greedy보다 강하다.

6. 엣지 케이스

다음 케이스들을 생각해볼 수 있다.

grid = [[0, 0, 0]]

초대할 수 있는 관계가 하나도 없으므로 답은 0이다.

grid = [[1], [1], [1]]

모든 boy가 같은 girl만 초대할 수 있다. girl은 한 명의 초대만 받을 수 있으므로 답은 1이다.

grid = [
  [1, 0],
  [1, 1]
]

처음에는 둘 다 Girl 0을 바라볼 수 있지만, Boy 1은 Girl 1로도 갈 수 있다. 따라서 최종적으로 2개 매칭이 가능하다.

이런 케이스에서 Kuhn Algorithm의 재배치 로직이 제대로 동작하는지 확인할 수 있다.

7. 최종 구현

결과적으로 최종 구현은 다음과 같다.

/**
 * @param {number[][]} grid
 * @return {number}
 */
var maximumInvitations = function(grid) {
  const m = grid.length;
  const n = grid[0].length;
  const matchGirl = Array(n).fill(-1);

  const canInvite = (boy, seen) => {
    for (let girl = 0; girl < n; girl++) {
      if (grid[boy][girl] === 0 || seen[girl]) continue;

      seen[girl] = true;

      if (matchGirl[girl] === -1 || canInvite(matchGirl[girl], seen)) {
        matchGirl[girl] = boy;
        return true;
      }
    }

    return false;
  };

  let answer = 0;

  for (let boy = 0; boy < m; boy++) {
    const seen = Array(n).fill(false);
    if (canInvite(boy, seen)) {
      answer++;
    }
  }

  return answer;
};

8. 시간복잡도

boy의 수를 B, girl의 수를 G, 가능한 초대 관계의 수를 E라고 하자.

Kuhn Algorithm은 각 boy에서 augmenting path를 찾기 위해 DFS를 수행한다.

시간복잡도: O(B * E)
이 문제의 matrix 기준 최악의 경우: E = B * G이므로 O(B^2 * G)
공간복잡도: O(G + B)

matchGirl과 seen은 girl 수만큼 필요하고, 재귀 DFS 깊이는 최대 boy 수 정도로 보면 된다.

이 문제는 B, G < 200이기 때문에 이 방식으로 충분히 통과 가능하다.

참고자료

LeetCode: https://leetcode.com/problems/maximum-number-of-accepted-invitations/
doocs/leetcode 1820 README: https://github.com/doocs/leetcode/tree/main/solution/1800-1899/1820.Maximum%20Number%20of%20Accepted%20Invitations
Kuhn Algorithm: https://cp-algorithms.com/graph/kuhn_maximum_bipartite_matching.html

Step by step goes a long way.

위클리 인사이트 By 오웬 (Y26W27)

DevOwen — Fri, 3 Jul 2026 18:00:43 +0900

26.06.29 ~ 26.07.03

너무 열심히 살게 만드는 나라

이번 한 주 몸이 안 좋다 보니 부정적인 생각들이 많이 생겼다. 열심히 사는 삶이 가지는 부작용에 대해 한 주간 생각해 보게 되었다.

어렸을 때부터 나는 뭐든지 열심히 하라는 말을 참 많이 들으며 자라 왔다. 그러다 보니 그게 맞다고 믿었고, 실제로 그런 나를 좋게 인정해 주는 사람도 주변에 많았던 것 같다. 하지만 요즘 나는 내가 열심히 살아온 삶이 너무 후회스럽다. 특히 나는 무언가에 몰두하면 시야가 좁아지기 쉬운 사람인데, 열심으로 인해 주변의 상황을 보지 못한 경우가 너무나도 많았기 때문이다. 가족이 무슨 생각을 하는지, 친구가 뭐에 관심이 있는지, 연인이 어떤 힘듦이 있는지 이러한 것들을 그동안 너무 보지 못하고 살아왔던 것 같다. 그리고 내가 항상 무언가에 분주한 모습이다 보니 주변 사람들도 눈치를 보게 만들고 마음이 어렵게 만들었던 건 아닐까 하는 생각도 든다.

열심히 살지 않으면 무가치하거나 게으르다고 생각하는 사회적인 시선도 이러한 삶을 자의적, 타의적으로 살게 만드는 원인 중 하나가 아닐까 하는 생각이 든다. 누군가는 열심히 살고 싶다면 그렇게 살고, 그렇지 않게 살고 싶다면 그렇게 살 수 있는 사회가 되면 좋을 것 같다. 사회가 빠르게 발전하다 보니 조금만 멈추고 쉬어도 주변에서 그 사람을 낙오자로 만드는 시선이 사라졌으면 좋겠다. 요즘은 쉬는 청년들을 "쉬었음 청년"이라고 용어를 붙여서 표현하기도 하는데 그것 자체만으로도 나는 구분 짓고 평가하는 기준이 들어간다고 생각한다. 일을 하는 청년들은 옳고, 쉬는 청년들은 틀렸다는 기성 세대들의 인식이 반영된 단어라고 나는 생각한다. 그들이 왜 쉬고 있고, 왜 쉬어야 할 수밖에 없는지를 유심히 관찰하면 좋겠다.

부상투혼이라는 말도 참 폭력적이라고 느껴진다. 아프면 멈추고 쉬는 게 정상이고 당연한 건데, 아픈 걸 참고 열심히 하는 사람들을 우리는 대단하다고 치켜세운다. 나는 이러한 말들을 보면서 우리가 아픈 걸 참고 일하는 걸 당연하게 여기고 푸시하는 문화를 만드는 건 아닌가 하는 생각도 든다. 이러한 문화 속에서 살다 보면 아픈 게 마치 죄처럼 여겨지고, 본인의 책임을 다하지 않는 사람으로 비춰지기도 하는 것 같다. 그 아픈 사람이 아프고 싶어서 아픈 것도 아닌데, 안그래도 힘든 상황 속에서 사회적인 시선마저 그 사람을 비난한다면 그러한 사람들은 2배 3배 더 큰 고통을 받게 될 것이라는 생각도 든다.

나의 모습을 세상의 기준이 아닌 나의 존재 그 자체로 사랑할 수 있는 사람이 되고 싶다. 내가 무엇을 잘 해서 인정받고, 성취해야 내가 잘 살고 있고 좋은 사람인 것이 아니라 그냥 나라는 사람 자체로서도 충분히 잘 하고 있고, 충분히 소중하며, 가치 있는 사람이라는 것을 이 사회가 계속해서 점점 더 알려주었으면 좋겠다. 그러한 개인의 개성과 색깔이 더 많이 드러나는 사회가 되었으면 좋겠다. 타인을 비난하고, 평가하고, 욕하는 그러한 모습들이 너무나도 팽배해 있는 시대가 안타까울 뿐이다.

위클리 인사이트 By 오웬 (Y26W26)

DevOwen — Fri, 26 Jun 2026 18:00:47 +0900

26.06.22 ~ 26.06.26

대한민국 월드컵 경기를 보며

이번 주 목요일에는 남아공과의 대한민국 월드컵 축구 경기가 있었다. 회사에서 업무 시간이어서 다 챙겨 보지는 못했지만, 중간중간 소식을 들을 때마다 아쉬움이 많이 느껴졌다. 가장 아쉬웠던 부분은, 0대 1로 지고 있는데 최소 비기기는 해야 하는 경기에서 우리나라 선수들이 적극적으로 공을 앞으로 가져가지 못하는 상황을 보았을 때였다. 아마 해설을 하던 위원들도 답답해하는 것 같았다. 결과는 이미 나왔고 사람들은 32강에 가기 위한 경우의 수를 계산하고 있는데, 나는 개인적으로 32강에 가지 않고 귀국해서 다시 팀을 꾸리는 게 어떨까 하는 생각이 든다.

여러 문제점들이 많이 나왔지만, 선수들의 역량 부족과 자신감 부족이라는 측면이 가장 아쉬웠다. 공격을 전개해 나가는 흐름을 계속 만들어야 하는데 지는 상황에서도 백패스를 하고 안전한 공간으로만 패스를 하는 모습이 이기기 위한 축구를 하는 것이 아니라, 실수하지 않는 축구를 하는 모습을 봤던 것 같다. 혹시나 돌파를 하다가 공을 빼앗기면, 역습을 허용하고 그러한 두려움이 선수들을 앞으로 나가게 하지 못하는 것은 아니었을까 하는 생각이 든다. 그런데 비단 이 모습이 과연 축구장에서만 일어나는 것일까?

실수를 하는 건 누구나 두려워하고, 실패를 좋아하는 사람은 아무도 없다. 하지만 우리의 삶에서 100% 안전하기만 한 선택이 과연 있는가 생각해 보면 그렇지는 않다. 내가 진학할 학교를 결정하고, 내가 앞으로 해야 할 일을 결정하는 큰 문제부터 오늘 저녁에 이 모임을 갈 것인지 말 것인지 하는 사소한 선택까지 하루에도 여러 가지의 선택을 하면서 우리는 무엇이 옳은 선택인지 자연스럽게 훈련을 하게 된다. 때로는 그 과정에서 선택이 잘못되는 경우도 발생한다. 그리고 우리는 그 잘못된 선택에 대한 책임을 스스로 진다.

어린 선수들이 이번 경험을 통해 부정적이고 안 좋은 기억들만 가져가기보다는 본인들이 한 선택에 대한 책임을 지는 시간으로 잘 사용하면서 성장했으면 좋겠다. 찾아보면 남탓을 할 부분들이 참 많이 보이겠지만, 그런 상황 가운데에서도 본인이 했던 선택들을 돌아보고 앞으로 어떻게 하면 더 좋은 결과를 얻을 수 있을지 생각해 보는 시간을 가지길 소망한다. 이 세상에 좋은 점만 있는 선택은 없다.

다른 사람들의 눈치를 보면서 이 일을 내가 해도 되는지, 할 수 있는지를 스스로 의심하는 방어기제가 유독 한국 사람들 사이에서는 많은 것 같아서 그 점은 너무 안타깝다. 누군가의 지시를 받아 일을 하고, 누군가가 칭찬해 주는 상황에서 열심히 하는 건 한국 사람들이 유독 잘하는 것 같다. 하지만, 남들이 다 안 하려고 하는 길을 걸어가거나 그러한 선택을 하는 부분에 대해서는 눈치도 많이 보고 필요 이상으로 다들 생각이 많은 듯하다. 다들 안전하고 검증된 길을 걸어 가려고 하는데, 과연 그러한 문화는 어떻게 하면 바뀔 수가 있을까?

바쁘다는 말을 하는 것에 대하여

나는 개인적으로 바쁘다는 말을 하는 것을 좋아하지 않는다. 그 이유는 바쁘다고 말하는 대상에게 내가 그 상대방을, 혹은 어떤 일의 우선순위를 낮게 생각한다는 인식을 줄 수 있다고 생각하기 때문이다. 나도 누군가에게 내가 소중한 대상이라는 인식을 받지 못하고 나의 일이 우선순위에서 밀린다는 것을 알게 되면 서운하고 부정적인 감정이 올라오기 때문에 이러한 말을 최대한 안 하려고 한다.

그래서 일을 최대한 똑똑하게, 그리고 빠르게 하려고 노력한다. 이런저런 소통을 많이 해야 할 때가 있는데, 그럴 때 일찍 줄 수 있는 문서는 최대한 일찍 주려고 하고, 답변도 빨리 하려고 한다. 이러한 방식이 나는 지금까지 옳다고 생각하면서 살아왔다. 그런데 요즘 드는 생각은, 내가 이렇게 살아가는 것에 익숙해질 수록, 남들이 이렇게 하기를 바라는 마음이 들면서 동시에 남들이 이러지 않으면 그들을 정죄하는 마음을 가지게 된다는 사실을 알게 되었다.

"왜 저 사람은 답변을 빠르게 안 주지? 나를 우습게 여기나?"
"왜 저 사람은 내 카톡을 안 보지? 나도 지금 바쁜데도 이렇게 빨리 하고 있는데"

이와 같은 내 안에서 부정적인 감정들이 생겨날 때가 많다. 내가 여유가 있고, 마음이 평온하면 그냥 아무렇지도 않게 여길 일들인데, 내가 예민하고 조급하니까 사람이 감정적으로 변하기가 쉽다.

나를 지키기 위해서, 나와 가까운 사람들을 지키기 위해서라도 내가 바쁜 상황에 놓여 있다면 그것들을 조금씩 벗어나는 것이 중요함을 느낀다. 성격상 답답하면 그냥 내가 다 해버리고 끝내는 편인데, 그러한 성격이 도움이 될 때도 있지만 요즈음에는 오히려 나를, 그리고 나의 가까운 사람들을 지키지 못한다는 생각에 단점이 더 크게 보이는 생각도 든다.

AI 시대의 전문성 - 하용호

이전부터 발표 자료를 잘 만드신다고 생각했던 하용호님의 <AI 시대의 전문성> 이라는 슬라이드를 보게 되었다.

https://drive.google.com/file/d/19rY4idXdBoFyqqzu0ImZe45C31ETb7rC/view

20260611_하용호_AI시대의전문성_인프런.pdf

drive.google.com

여기서 말하는 회사가 AX를 적용하는 과정이 우리 회사와도 너무 비슷해서 약간 소름이 돋았다. 결국 많이는 만드는데 쓰는 사람이 없는 그러한 대혼돈의 상태가 지금 우리 회사를 포함한 여러 많은 회사에서 나타나는 현상인 것으로 보인다.

결국 발표 자료 마지막에서 말하긴 하지만, 나도 AI 시대에는 검증과 취향 두 가지 영역을 잘하는 사람이 실력을 인정받을 수 있다고 생각한다. 둘 다 AI가 완벽하게는 하지 못하는 분야이다. 결국 어려운 선택과 결정을 잘하는 쪽으로 나도 앞으로 나아가야겠다는 생각이 든다.

위클리 인사이트 By 오웬 (Y26W25)

DevOwen — Fri, 19 Jun 2026 18:00:44 +0900

26.06.15 ~ 26.06.19

허리 통증과 근육 뭉침, 꾸준한 스트레칭의 중요성

나는 개발자로 일을 시작한 뒤로 꾸준하게 허리 통증과 근육 뭉침 증상으로 힘들었다. 내가 찾아보니 지금 내 증상이 퇴행성 디스크의 증상과 유사한 점이 많다는 것을 알게 되었다. 그래서 21년부터 거의 매년 빠지지 않고 도수 치료를 받았었다. 회당 10만 원~20만 원 정도 수십 회를 받으면 비용이 상당히 많이 든다. 하지만 그때뿐, 치료가 끝나면 다시 통증이 찾아왔다. 그리고 작년에는 트래일러닝을 하면서 허벅지에 쥐도 몇 번 나고, 근육이 뭉쳐 있는 증상이 운동을 하고 나서 풀어주지 않으면 위험해질 수 있다는 것도 알게 되었다.

그래서 나는 폼롤러를 구입해서 폼롤러 스트레칭과 허리, 어깨, 목 부분을 중심으로 스트레칭을 시작했다. 처음에 하루 이틀 사흘… 매일 10분씩 하는 것조차 나에게는 너무 귀찮은 일이었다. 그리고 그렇게 하더라도 증상이 크게 나아지지 않았던 것 같다. 하지만 일주일, 이주일 꾸준하게 하다 보니 그 뒤로는 허리, 어깨 등에 통증이 사라지고 근육도 뭉침이 덜하게 되었다. 너무 신기하고 감사했다. 몸이 안 아파지니까 스트레스도 줄어들고 하루하루가 기분 좋은 날이 많아진 것이 참 다행이었다.

그러다가 또 귀찮음이 많은 성격 탓에 안 아파서 스트레칭과 마사지를 안 해 주었더니, 다시 또 통증이 올라온다. 참 신기하다. 내 몸은 절대 거짓말을 하지 않는다는 걸 알게 된다. 누군가의 본 모습을 보고 싶을 때, 그 사람의 몸을 보는 것이 어느 정도 도움이 될 수 있겠다는 생각이 든다. 꾸준한 습관을 통해 나의 몸을 더 사랑하고 관리하는 것이 중요함을 몸으로 알게 된다. 이러한 행동 하나하나를 통해 들어가지 않아도 되는 시간과 돈을 벌 수 있다면, 이는 나에게 있어서 중요한 재테크라는 생각도 하게 된다.

원칙과 포용 사이

이번 주는 교회에서 국내선교팀 사역을 하느라 한 주 동안 참 분주했다. 우리 교회의 여러 선교팀이 이번 여름 선교를 가는데, 이에 대한 팀을 배정하고 가이드를 정하는 일을 했다.

이에 대한 일을 하면서 원칙을 어기는 케이스들이 계속해서 나옴을 알 수 있었다. 예를 들면 첫날 같이 출발하는게 원칙인데 부득이한 사정으로 늦게 출발한다고 하는 사람이 있는가 하면, 처음에 희망하는 선교지에서 나중에 다른 선교지로 바꾸고 싶다는 사람들도 있었다. 이와 같은 문의들이 개인적으로도 오고 팀으로도 와서 좀 피곤했는데, 원칙에 따라 결정하면 단순하지만 원칙대로 할 수 없는 케이스들이 존재했기 때문이다. 편의를 봐 준다면 어디까지 봐 주어야 하는 건지… 이에 대해서도 팀 안에서도 구성원들마다 의견이 다르기도 해서 스트레스를 많이 받았다.

명확한 정답이 있는 문제는 아니다. 어떤 한 사람의 특정 사유 편의를 봐주면, 나중에 비슷한 사유의 또 다른 문의가 올 수도 있지만, 이로 인해 한 사람이 선교를 못 갈 뻔했는데 갈 수 있게 된다. 무엇이 더 옳고, 무엇이 더 그른지는 우리 팀이 가지고 있는 방향과 지향점에 따라 다른 것 같다. 앞으로도 이러한 원칙과 포용 사이에서 고민할 일들이 많이 생기겠지만, 나름대로 그 과정을 세우는 순간순간이 팀이 더 방향을 정교하게 다듬는다는 측면에서 의미가 있다고 생각하고 즐겁게 해보려고 한다.

위클리 인사이트 By 오웬 (Y26W24)

DevOwen — Fri, 12 Jun 2026 18:00:04 +0900

26.06.08 ~ 26.06.12

AI 에이전트를 어떻게 평가할 수 있을까

요즘 개인적으로도, 팀에서도 AI 에이전트를 만들면서 하는 가장 큰 고민 중 하나는 "어떻게 평가할 수 있을지?"이다. 이와 관련해서 이번 주에 엔트로픽의 블로그 글을 하나 읽게 되었다. 제목은 <Demystifying evals for AI agents>

Demystifying evals for AI agents

www.anthropic.com

이 글에서 말하는 핵심은 AI 에이전트 평가는 단순히 정답 채점이 아니라, 에이전트가 실제 환경에서 여러 턴 동안 도구를 쓰고 상태를 바꾸며 목표를 달성하는지를 측정하는 체계 라는 점이다. 일반적인 LLM 평가와 다르게, 에이전트 평가는 여러 턴 동안 도구를 호출하고, 환경을 바꾸고, 중간 결과에 따라 행동을 바꾼다. 그렇기 때문에 마지막 답변만 보는 것은 부족하고 전체 실행 과정과 최종 환경 상태를 같이 보아야 한다.

에이전트는 비결정적인 특성을 가지고 있기 때문에 통과하는 지표 측정도 pass@k, pass^k 나누어서 하는 점이 인상적이었다.

pass@k : k번 시도 중 한 번이라도 성공할 확률. 여러 시도 중 하나만 성공하면 되는 코딩 문제나 탐색형 문제에 유용.
pass^k : k번 모두 성공할 확률. 고객을 마주하는 에이전트처럼 매번 안정적으로 성공해야 하는 제품에서 중요.

그리고 Capacity eval과 Regression eval을 목적에 맞게 사용해야 한다는 점도 기억에 남는다.

Capacity eval : "이 에이전트가 무엇을 할 수 있는가?"를 보는 평가. 처음에는 pass rate가 낮아야 좋다.
Regression eval : "예전에 잘하던 걸 여전히 잘하는가?"를 보는 평가. 거의 100%에 가까운 pass rate를 기대한다.

단순히 프롬프트를 잘 작성하는 관점에서만 나는 고민을 했는데, 평가도 하나의 시스템 요소로 넣고 고민을 해야겠다는 생각이 든다.

[번역] 컴포넌트가 WCAG를 준수할 수 있을까요?

DevOwen — Fri, 5 Jun 2026 18:15:28 +0900

원문: https://hidde.blog/component-conformance/

접근성을 고려해 UI 컴포넌트를 만들 수 있습니다. 개발하면서 컴포넌트와 함께 접근성 관련 사항을 문서화하거나, 명백한 장애물이 없는지 검토해도 됩니다. 모두 도움이 되고 권장할 만한 일입니다. 그렇다면 적합성을 주장하는 건 어떨까요? 이 글에서는 WCAG가 기술적으로 그것을 허용하지 않는 이유와, 그 판단이 옳다고 보는 이유를 이야기합니다.

이 글의 일부는 제가 진행해 온 "내장 접근성: 축복인가 저주인가?"라는 발표 시리즈에서 비롯되었습니다. 이 발표에서는 "접근 가능한 웹 플랫폼 기능"과 저작 도구도 다룹니다. JS Heroes 2025 유튜브 영상을 확인하실 수 있습니다.

평소와 같이, 이 글의 의견은 제 개인적인 견해이며 고용주나 제가 속한 워킹 그룹의 입장을 대표하지 않습니다.

컴포넌트가 준수할 수 없는 이유

WCAG 2에서 컴포넌트(디자인 시스템의 리액트/앵귤러/바닐라/HTML 컴포넌트 등)는 공식적으로 WCAG를 준수할 수 없습니다. WCAG의 적합성 요건 중 하나가 이렇게 명시하고 있기 때문입니다.

적합성은 완전한 웹 페이지에만 적용되며, 웹 페이지의 일부가 제외된 경우에는 달성할 수 없습니다.

격리된 컴포넌트를 HTML 페이지에 올려두거나 Codepen이나 스토리북(Storybook) 환경에 두는 방식도 있지만, 그렇다고 달라진다고 보지 않습니다(기술적으로 '완전한 웹 페이지'를 만들었다 해도 마찬가지입니다). 우리가 알고 싶은 건 사용자가 무언가에 접근할 수 있는지 여부이고, 사용자(최종 사용자)는 최종 제품, 즉 완전한 페이지와 프로세스에 접근합니다(예를 들어 물건을 구매하거나 리뷰를 제출하고 싶어 합니다).

이 요건은 WCAG 2.0이 발행된 2008년 이전에 작성되었습니다. 당시에는 프런트엔드 컴포넌트가 설치 가능한 패키지로도, 복사해서 붙여넣을 수 있는 코드 조각으로도 존재하지 않았습니다(나탈리 다우니(Natalie Downe)가 2009년 Clearleft에서 이 관행을 선구적으로 도입한 것으로 보입니다).

요건을 재검토할 여지가 있습니다. 지난 10년간 디자인 시스템은 많이 성숙했습니다. 멀티 브랜드, 멀티 프레임워크, 자동화 테스트 컴포넌트가 이제 표준이 되었습니다. 접근성 전문가로서 편향될 수 있지만, 저는 많은 팀이 접근성을 디자인 시스템 개발의 주요 동기 중 하나 혹은 핵심 동기로 꼽는 모습을 봐왔습니다. 수많은 팀이 더 접근 가능한 최종 제품을 만드는 데 대단히 효과적인 것도 목격했습니다. 모범 사례를 많은 사람에게 전달하고, 유용한 문서를 한 곳에 모아두는 역할을 하기 때문입니다.

컴포넌트가 얼마나 접근 가능한지 테스트하고, 웹사이트의 접근성에 무엇을 기여할 수 있고 없는지 문서화하는 일은 반드시 해야 합니다. WCAG 요건도 이 작업에 도움이 됩니다. 그러나 오늘날 우리가 하는 것처럼 페이지 또는 페이지 집합에 대한 WCAG 적합성을 주장하는 방식이 올바른 접근이라고 봅니다. 컴포넌트 자체의 적합성을 주장하려 해서는 안 됩니다(컴포넌트를 검토하고, 최적화하고, 문서화하고, 접근성 전문가가 평가하는 일은 얼마든지 해도 됩니다). 적합성을 주장해서는 안 되는 이유는 두 가지 위험 때문입니다. 과잉 약속과 실제 접근성을 제대로 포착하지 못하는 문제입니다.

과잉 약속의 위험

컴포넌트에 대한 적합성 주장을 허용하면 "컴포넌트 세일즈맨"이 지킬 수 없는 약속을 너무 쉽게 하게 됩니다.

"컴포넌트 세일즈맨"이라는 표현을 비하적으로 쓴 건 아닙니다. 저도 한때 그런 사람이었으니까요. 이 표현으로 제가 가리키는 건 구체적으로 다음과 같은 역할을 맡은 사람들입니다.

자신의 제품에 컴포넌트를 쓸 수 있는 사람들(또는 상업적으로 구매할 수 있는 사람들)에게 디자인 시스템을 홍보하는 역할
의사 결정권자와 예산 담당자에게 디자인 시스템과 그 장점을 홍보하는 역할

WCAG를 준수하는 컴포넌트라는 개념은 정말 매력적으로 들립니다. 개발자라면 당장 npm install 하고 싶을 것이고, 예산 담당자라면 막대한 자금을 쏟아붓고 싶을 겁니다. 접근성 담당자로서도 그런 것이 존재하기를 바라겠지만, 저는 꽤 확신합니다… "그것"은 없습니다. 그것은 실제로 실현 가능하거나 의미 있는 무언가가 아닙니다(아래 내용 참조).

컴포넌트가 접근 가능하다거나 어떤 접근성 표준을 준수한다고 말할 때 그 가치를 과도하게 약속할 실질적인 위험이 있습니다. 사람들이 해당 컴포넌트를 쓰거나 구매하면 더 이상 접근성에 대해 걱정할 필요가 없다고 믿게 만들 수 있습니다. 잘못된 기대를 심어주는 거죠. 접근성은 지속적인 프로세스입니다. 사용자 경험을 항상 개선하고 싶듯이, 접근성도 항상 개선해야 합니다.

실제 접근성을 포착하지 못하는 위험

컴포넌트가 적합하다고 주장하는 것은 보이는 것만큼 의미 있지 않습니다. 여러 이유로 사용자의 실제 접근성을 제대로 포착하지 못할 가능성이 높습니다. 아래에서 세 가지를 살펴보겠습니다. 맞춤화 가능성, 조합 가능성, 그리고 맥락입니다.

맞춤화 가능성

대부분의 현대 컴포넌트에는 옵션이 있습니다. 스토리북 같은 도구를 쓰면 웹 개발자가 컴포넌트 옵션을 나열하고, 데모하고, 테스트할 수 있습니다.

이러한 옵션 중 많은 것이 사용 시점에서 WCAG 적합성에 쉽게 영향을 미칩니다. 사용이 WCAG를 충족하는지는 최종 제품에서만 확인할 수 있다는 뜻이고, 적합성은 "데모" 컴포넌트 단계에서 결정할 수 없습니다.

예를 들어:

컴포넌트에서 색상을 바꿀 수 있다면, 최종 제품이 WCAG를 충족하는지 판단하려면 어떤 색상인지 알아야 합니다(1.4.3, 1.4.11)
컴포넌트에서 버튼 텍스트를 바꿀 수 있다면, 최종 제품이 접근 가능한지(예: "여기를 클릭하세요"는 안 되고 설명적인 텍스트여야 함) 또는 WCAG를 충족하는지 판단하려면 최종 제품의 텍스트가 무엇인지 알아야 합니다(예: 2.5.3)
이미지 컴포넌트에 대체 텍스트를 전달할 수 있다면, 전달된 텍스트가 이미지를 제대로 설명하는지 알아야 합니다… 최종 제품이 WCAG를 충족하는지 판단하려면 이미지와 텍스트 모두 확인해야 합니다(1.1.1)
간격을 맞춤화할 수 있다면, 최종 제품이 WCAG를 충족하는지 판단하려면 최종 제품의 수치가 무엇인지 알아야 합니다(2.5.8)

조합 가능성

접근 가능하거나 WCAG를 충족하는 무언가를 만들려고 컴포넌트를 올바른 방식으로 조합해야 할 때가 있습니다.

예를 들어, 많은 디자인 시스템에는 별도의 레이블 컴포넌트와 입력 컴포넌트가 있습니다. WCAG를 충족하는 입력 상황을 만들려면(1.3.1, 4.1.2), 최종 제품을 만드는 사람이 두 컴포넌트를 조합해야 할 수 있습니다. 그 시점에서 "적합성"은 컴포넌트 하나에 있는 것이 아니라, 여러 컴포넌트의 효과적인 조합에 있게 됩니다(많은 시스템이 이를 쉽게 해주는 헬퍼나 단일 컴포넌트를 제공하지만, 그건 제 핵심 주장이 아닙니다).

맥락

마지막으로, 맥락도 중요합니다. 테스트 스위트의 고립된 환경에서는 볼 수 있는 것이 제한적입니다. 실험실 조건에서 접근성을 살펴보는 것은 분명히 유용하지만, 실제 접근성에는 맥락이 필요합니다. 사람들이 실제로 쓸 환경 말이죠.

건너뛰도록 설정된 ID를 포함하지 않는 페이지에서 제 스킵 링크 컴포넌트를 쓰면, 의미 있는 접근성을 제공할 수 없습니다. 반복되는 콘텐츠 블록이 없는 경우도 마찬가지입니다. 2.4.1 반복 블록 건너뛰기 충족에 기여할 수는 있지만, 사용자가 실제 블록을 실제로 건너뛸 수 있게 해주는 페이지의 맥락 안에서만 그렇습니다.

날짜 선택기(date picker)가 중간을 잘라버리는 요소 안에 있다면, 제 캘린더 컴포넌트의 포커스 표시기는 의미 있는 접근성을 제공할 수 없습니다. 2.4.7 포커스 표시 충족에 기여할 수는 있지만, 그것을 깨뜨리지 않는 페이지의 맥락 안에서만 그렇습니다.

내장할 수 있는 접근성

접근성의 일부 측면은 맞춤화 가능성, 조합 가능성, 맥락에서 대체로 "살아남는" 것들이 있습니다.

가능하다면 다음 항목들은 컴포넌트에 반드시 내장하려고 노력해야 합니다.

키보드 접근성. 예를 들어 날짜 선택기에서 날짜 간 이동 방법, 목록에서 옵션 선택 방법, 요소 순서 등입니다.
참고: 페이지 수준의 키보드 개입으로 여전히 깨질 수 있습니다(양수 tabindex 사용이나 스크립트를 통한 개입 등).
의존하지 않는 시맨틱(특히 역할(role)). 예를 들어 button 요소를 쓰는 버튼 컴포넌트입니다.
참고: 많은 시맨틱이 실제로 의존합니다. 예를 들어 팝오버(popover)에는 적합한 역할이 여러 가지입니다.
상태와 관계. 예를 들어 확장 가능한 요소의 aria-expanded 상태입니다.
합리적인 읽기 순서.
줌 및 리플로우(reflow) 지원.
참고: 콘텐츠와 맥락에 따라 여전히 깨질 수 있습니다.
사용자 선호 지원. 예를 들어 다크 모드/강제 색상 모드, 텍스트 간격 등입니다.
접근성 기능 지원. 예를 들어 비디오 플레이어 컴포넌트의 자막 및 화면 해설 지원입니다.

컴포넌트를 견고하게 만드는 방법은 이 외에도 많습니다. 그렇게 하는 데서 큰 가치를 느낍니다. 지난 몇 년간 디자인 시스템 수준에서 접근성에 진지하게 투자해 최종 제품의 문제가 더 적고 덜 심각해지는 사례를 많이 봤습니다.

디자인 시스템에서 컴포넌트를 다루는 또 다른 큰 이점은 방향을 제시할 기회가 많다는 점입니다. 컴포넌트를 잘 쓰는 방법, 테스트한 내용, 최종 제품에서 테스트해야 할 내용 등을 문서화하세요. 선의를 가진 개발자들이 올바르게 쓸 수 있도록 도와주세요(악의적인 개발자를 어떻게 할지는 다른 글에서 다룰 수 있습니다).

컴포넌트가 충족할 수 있는 스펙

Peter의 사려 깊은 댓글을 바탕으로 8월 13일에 추가되었습니다

컴포넌트가 WCAG 스펙을 충족할 수 없다고 말하지만, 다른 스펙은 충분히 충족할 수 있습니다. 버튼이 WCAG를 충족한다고 주장하는 것은 의미 없지만, 버튼이 버튼 전용 스펙을 충족한다고 말하는 것은 의미 있습니다.

어떤 컴포넌트에 대해서도 그 컴포넌트를 접근 가능하게(또는 훌륭하게) 만들기 위한 요구사항 목록을 작성할 수 있습니다. 컴포넌트는 그 요구사항 전체를 충족할 수 있습니다. 공상이 아닙니다.

NL 디자인 시스템 프로젝트(면책 사항: 저는 그곳에서 일한 적이 있습니다)는 정부 디자인 시스템 제작자 커뮤니티의 컴포넌트를 인큐베이팅합니다. 인큐베이션 과정에서 각 컴포넌트의 요구사항 목록을 작성합니다. 예를 들어 스킵 링크에 대한 요구사항 목록을 확인해보세요(네덜란드어이지만, 번역 서비스를 쓰면 됩니다).

US 웹 디자인 시스템에도 체크리스트가 있습니다. 버튼 체크리스트가 그 예입니다. 컴포넌트를 만들 때 테스트한 내용과 구현 시 각 컴포넌트에 대해 테스트해야 할 내용을 설명합니다.

마무리

공식적으로, 컴포넌트에 대한 접근성 적합성을 주장할 수 없습니다. 그러나 과잉 약속의 위험이 있기 때문에 그런 주장을 하고 싶지도 않습니다. 그럼에도 컴포넌트를 최적화하는 데는 큰 가치가 있습니다. 합리적으로 내장할 수 있는 것을 내장하려는 시도에도 큰 가치가 있습니다. 어떻게 만들고 테스트했는지 설명하는 문서를 제공하는 일도 마찬가지입니다. 누가 무엇과, 그리고 어떻게 상호작용하는지 절대 잊지 않는 한에서 말이죠. 목표는 사람들이 최종 제품을 쓸 수 있어야 한다는 것입니다.

업데이트 목록

2025년 8월 15일: 피드백을 반영해 여러 곳에 명확한 설명을 추가했습니다. 이 글은 컴포넌트를 만들고, 테스트하고, 평가하고, 최적화하는 것을 만류하려는 게 아닙니다. WCAG가 적합성 주장을 공식적으로 전체 페이지에 한정하는 이유, 그리고 그 범위가 왜 타당한지(사용자는 컴포넌트가 아닌 최종 제품을 경험하기 때문)를 설명하기 위한 글입니다.
2025년 8월 13일: 컴포넌트가 충족할 수 있는 다른 스펙 섹션 추가.