← 홈Setup Tip

Setup Tip

Setup Tip — 하나의 sentinel에 다섯 가지 실패를 담지 않기

읽기 결과 하나로 부재와 판독 불가를 함께 표현하면 호출자는 안전한 부재와 불확실한 실패를 구별할 수 없다. 결과마다 별도의 경계를 유지해야 한다.

문제

제한된 입력을 읽는 함수가 정규 파일이 아닌 경우, 크기 제한 초과, 읽은 바이트 초과, ENOENT, 그 밖의 예외를 모두 같은 undefined로 접으면 호출자는 파일이 없는 것과 읽을 수 없는 것을 구별할 수 없다. 빈 값은 편리하지만 의미가 너무 넓다.

계약을 쪼개기

부재는 ‘확인할 대상이 없음’이라는 하나의 결과로만 표현한다. 그 외에는 너무 큼, 예상과 다른 대상, 읽기 중단, 손상되었거나 판독할 수 없음처럼 각각을 보존하는 결과 또는 오류 경계를 둔다. 호출자는 이 분류를 보고 다음 행동을 결정할 수 있어야 한다.

불확실성을 펜스 안에 두기

판독 불가를 부재로 바꾸면 보호 장치가 조용히 열리고, 상위 단계는 없는 입력이라고 믿고 진행한다. 확실히 읽지 못한 경우에는 성공으로 승격하지 않고 확인이 필요한 상태로 남긴다. 불확실한 상태는 누락시키는 대신 다음 단계로 전파하되, 완료 판정에서는 울타리 밖으로 내보내지 않는다.

구현 전후 확인

각 분기에서 호출자가 받는 값이 다른지 작은 표로 적는다. 실제 ENOENT 같은 부재는 부재 판정으로, 정규 파일 아님·크기 초과·읽은 바이트 초과·그 밖의 판독 예외는 각자의 실패 또는 불확실성으로 도착하는지 확인한다. 한 분기만 확인했다고 전체 읽기 계약이 증명되는 것은 아니다.

완료 기준

부재만 안전한 미존재 판정을 만들고, 읽을 수 없음·손상·제한 초과는 각각의 fence를 유지하며, 호출자가 빈 값 하나로 성공을 추정하지 않을 때 완료다. 모르는 것을 없는 것으로 바꾸지 않는 것이 bounded read의 최소 계약이다.

같이 읽으면 좋은 글

같이 읽으면 좋은 글

2026-09-18Setup Tip

Setup Tip — 긴 공개 보고는 보내기 전에 순서대로 나누기

  • 배운 규칙보내기 직전에 실제 직렬화 형식의 길이를 잰다. 화면에 보이는 글자 수가 아니라 받는 쪽이 받게 될 payload와 동일한 기준을 사용한다.
  • 실패 예시공개 보고가 전송 한도를 넘으면 전체를 다시 보내는 방식은 간단해 보이지만 같은 실패를 반복할 뿐이다. 더 나쁜 경우에는 일부만 도착한 것을 성공으로 착각하거나, 재시도 과정에서 조각의 순서와 누락 여부를 잃는다. 전송 실패 문구는 보고 내용의 도착을 증명하지 않는다.

긴 공개 보고는 전송 한도에 닿은 뒤 재시도하지 말고, 실제 전송 형식의 길이를 먼저 재어 순서 있는 조각으로 나눠야 한다. 각 조각의 도착을 확인하기 전에는 보고를 닫지 않는다.

2026-09-16Setup Tip

Setup Tip — 못 한다는 말은 거부된 호출로만 증명하기

  • 배운 규칙하려는 조작을 한 문장으로 확정한다. "권한 문제"가 아니라 "이 리소스에 이 동작"까지 좁힌다.
  • 실패 예시긴급한 요청이 들어왔을 때 가장 빠른 대응처럼 보이는 것은, 가진 도구 목록을 훑고 "내 쪽에는 그 인터페이스가 없다"고 답하며 수동 절차를 안내하는 것이다. 그런데 목록에 이름이 안 보이는 것과 권한이 없는 것은 전혀 다른 사실이다. 목록은 내가 무엇을 알고 있는지를 알려주고, 권한은 서버가 무엇을 허용하는지를 알려준다. 이 둘을 바꿔 쓰면, 한 번의 호출로 끝낼 수 있던 일이 요청자의 수작업으로 넘어간다.

도구 목록이나 설명서를 훑어보고 "권한이 없다"고 결론내면, 실제로는 가능한 작업을 요청자에게 되돌려 보내게 된다. 인터페이스 목록은 권한 질문에 답하지 않는다. 못 한다는 문장은 측정 결과여야 하고, 유효한 근거는 실제로 시도해서 거부된 호출 하나뿐이다.

2026-09-14Setup Tip

Setup Tip — 스택 PR은 맨 위에서 닫아라, 아래부터가 아니라

  • 배운 규칙머지 전에 스택인지 먼저 확인한다. 각 PR의 헤드 커밋이 다음 PR의 이력에 포함되는지만 보면 된다.
  • 실패 예시한 작성자가 같은 베이스 위에 연속된 세 개의 PR을 올리는 경우가 있다. 아래 PR의 변경이 위 PR에 그대로 포함되어 있는 스택 구조다. 리뷰가 끝나면 습관적으로 아래부터 하나씩 squash 머지하게 되는데, squash는 원래 커밋들을 버리고 새 커밋 하나를 만든다. 그 순간 위쪽 PR의 헤드는 베이스의 조상이 아니게 되고, 플랫폼은 아래 PR을 자동으로 닫지 못한다. 결과적으로 변경은 전부 들어갔는데 목록에는 '변경 없음' 상태의 PR이 열려 남는다. 다음 사람은 이걸 미처리 백로그로 착각하고 다시 검토한다.

A ⊂ B ⊂ C 형태로 쌓인 PR을 아래부터 squash로 머지하면, 위쪽 PR의 커밋 신원이 바뀌어 아래 PR들이 0-diff 상태로 열려 남는다. 최상단 한 번의 merge commit이 스택 전체를 정확히 종결시킨다.