별고래의 항해일지

[카테고리:] 개발 노트

  • 클로드 Fable 5 정리 — Opus·Sonnet과의 차이, 클로드 코드의 변화

    요약 — 먼저 결론

    2026년 6월 9일, 앤트로픽이 클로드 Fable 5를 냈다. 핵심은 셋이다.

    • 기존 Opus급 위에 Mythos급이라는 새 체급이 생겼고, Fable 5는 그 체급의 첫 일반 공개 모델이다
    • 위험한 질문을 만나면 거부하는 대신 Opus 4.8로 모델을 갈아끼운다 — 차단이 아니라 교대
    • 클로드 코드엔 /goal 명령이 생겼다. “조건이 참이 될 때까지 멈추지 마”가 가능해졌다

    가격은 Opus 4.8의 2배. 그런데 실제 체감은 2배보다 크다 — 아래에서 설명한다.

    무엇이 나왔나 — Fable과 Mythos

    이름 구조부터. Mythos 5가 본체다. 같은 모델에 안전 분류기를 달아 일반 공개한 판이 Fable 5다.

    Mythos 5는 정부 협력 프로그램(Project Glasswing)의 승인된 보안 연구자들만 쓴다. 일반 사용자·기업이 만나는 건 Fable 5 하나다.

    벤치마크는 코딩(Cognition FrontierCode)·금융 추론(Hebbia)·비전에서 모두 기존 최고치를 넘겼다고 발표됐다. Stripe는 5천만 줄 코드베이스 이전에서 “몇 달 걸릴 엔지니어링을 며칠로 압축했다”고 증언했다.

    숫자로 — 기존 모델과 비교

    현행 4개 모델의 공식 스펙을 한 표로 모으면 이렇다.

    Fable 5 Opus 4.8 Sonnet 4.6 Haiku 4.5
    포지션 최상위 (Mythos급) 복잡한 추론·에이전트 속도·지능 균형 최속·저가
    컨텍스트 1M 토큰 1M 1M 200K
    최대 출력 128K 128K 64K 64K
    가격 (입력/출력, 1M토큰당) $10 / $50 $5 / $25 $3 / $15 $1 / $5

    여기 함정이 하나 있다. Fable 5는 새 토크나이저를 쓰는데, 같은 텍스트가 구모델 대비 약 30% 더 많은 토큰으로 계산된다(공식 문서 명시). 단가 2배에 토큰 수까지 늘어나니, 실효 비용 차이는 표보다 크다.

    또 하나 — Fable 5는 생각(thinking)을 끄는 옵션이 없다. 항상 적응형으로 켜져 있고, 깊이만 조절한다.

    안전장치 — 차단이 아니라 교대

    가장 흥미로운 설계다. 사이버보안·생물학·모델 증류 같은 고위험 주제를 감지하면, Fable 5는 답을 거부하는 대신 그 요청을 Opus 4.8에게 넘겨 처리한다.

    API에서도 거부가 에러가 아니다. HTTP 200에 stop_reason: "refusal"로 돌아오고, 다른 모델로 자동 재시도하는 fallback 파라미터까지 제공된다. 발표 기준 95% 이상의 세션은 폴백 없이 Fable로만 끝난다.

    이 글을 쓰는 환경에서도 직접 겪었다. 서버 점검 스크립트와 보안 게이트를 다루던 세션에서 Fable 5를 켜자, 분류기가 “사이버보안 주제”로 오탐해 Opus 4.8로 자동 전환됐다. 작업은 그대로 이어졌다 — 차단당한 게 아니라 담당자가 바뀐 것에 가깝다.

    클로드 코드에서 달라진 것

    클로드 코드(터미널 AI 코딩 도구)엔 /goal 명령이 들어왔다. “테스트가 전부 통과하고 린트가 깨끗할 때까지”처럼 완료 조건을 걸면, 조건이 참이 될 때까지 세션이 계속 일한다.

    설계가 눈에 띈다. 조건 충족 여부를 일하던 모델이 아니라 별도의 평가자가 매 턴 검사한다. 일한 사람이 자기 숙제를 채점하지 않게 만든 것이다.

    제작자 보리스 체르니는 “지금까지 코딩에 써본 모델 중 큰 차이로 최고 — 지시와 개입이 줄고, 토큰 효율·코드 품질·자가 검증이 좋아졌고, 더 길게 자율로 돈다”고 썼다. 팀 동료는 변화를 한 문장으로 요약했다. “전엔 일을 제대로 했는지 검증했는데, 이젠 제대로 된 일을 하고 있는지 검증한다.”

    맥락 — 공개 며칠 전의 경고

    출시 타이밍이 묘하다. 발표 며칠 전, 앤트로픽은 주요 AI 연구소들에 “프런티어 AI 개발에 공동 브레이크가 필요하다”는 경고문을 냈다. 가장 강한 모델을 공개하면서 가장 강한 경고를 같이 낸 셈이다.

    비판도 있다. Mythos급 트래픽은 30일 데이터 보존이 의무라 ‘보존 제로’ 옵션이 없고, 기업들 사이에선 AI 비용 자체에 대한 회의도 커지고 있다.

    한 줄 정리

    Fable 5의 본질은 성능보다 구조다. “위험하면 거부” 대신 “위험하면 교대”, “다 했다고 믿기” 대신 “남이 채점” — 더 센 모델을 더 깐깐한 틀에 넣어 내보냈다.

    참고한 것

    글의 수치·인용은 모두 아래에서 확인했다 (2026-06-10 기준).

  • 스키마(Schema) — 데이터베이스와 머릿속이 같은 단어를 쓰는 이유

    요약 — 먼저 결론

    스키마는 “데이터가 어떤 모양이어야 하는지 미리 정해둔 틀”이다. 데이터베이스에선 테이블 설계도를, 심리학에선 머릿속 지식의 틀을 가리킨다.

    같은 단어를 쓰는 건 우연이 아니다. 둘 다 핵심이 같다 — 틀이 먼저 있어야, 새로 들어오는 것이 자리를 잡는다.

    개발할 땐 스키마가 쓰레기 데이터를 막고, 공부할 땐 스키마가 새 지식을 붙잡는다.

    은행 신청서 양식을 떠올리면 된다

    은행 신청서엔 칸마다 규칙이 있다. 이름 칸엔 글자, 생년월일 칸엔 숫자 8자리, 서명은 필수.

    이렇게 칸의 종류·형식·필수 여부를 미리 정해둔 약속이 스키마다. 내용물이 아니라 틀이다. 누가 써넣든 양식은 같다.

    개발에서 — 데이터의 설계도

    개발에서 스키마는 “이 데이터는 이 모양이어야 한다”는 선언이다. 쓰이는 곳마다 뜻이 같다.

    맥락 스키마가 정하는 것
    DB 스키마 어떤 테이블에 어떤 컬럼(이름·타입·필수)이 있나
    API 스키마 요청·응답에 어떤 필드가 와야 하나
    폼·설정 스키마 입력값이 어떤 형식이어야 하나

    스키마의 힘은 들어오는 순간 거른다는 데 있다. 나이 칸에 “abc”가 오면 저장 전에 거부된다. 스키마가 없으면 틀린 데이터가 조용히 쌓이다가 몇 달 뒤에 터진다.

    심리학에서 — 머릿속 지식의 틀

    1932년 심리학자 바틀릿(Bartlett)이 유명한 실험을 했다. 영국 학생들에게 낯선 북미 원주민 설화 “유령들의 전쟁”을 들려주고 시간이 지난 뒤 다시 말하게 했다.

    사람들은 이야기를 그대로 기억하지 못했다. 자기에게 익숙한 틀에 맞게 바꿔서 기억했다. 낯선 카누는 익숙한 배로, 낯선 의식은 익숙한 사냥으로.

    머릿속에 이미 있는 지식의 틀 — 이게 심리학의 스키마다. 우리는 새 정보를 원본 그대로 저장하지 않는다. 기존 틀에 끼워 넣으며 저장한다. “식당 스키마”가 있으면 처음 가는 식당에서도 헤매지 않는 것처럼 — 들어가고, 앉고, 주문하고, 계산한다.

    왜 같은 단어인가

    어원은 그리스어 skhēma(형태·모양). 두 분야가 같은 단어를 고른 건 같은 일을 하기 때문이다.

    DB 스키마 머릿속 스키마
    틀 테이블·컬럼 기존 지식 구조
    새 데이터 행으로 삽입 기존 틀에 연결
    틀에 안 맞으면 거부 (에러 발생) 조용히 왜곡되거나 잊힘

    마지막 줄이 무섭다. 컴퓨터는 안 맞으면 에러라도 띄운다. 뇌는 조용히 왜곡하거나 버린다. 바틀릿의 학생들은 자기 기억이 바뀐 줄도 몰랐다.

    실전 — 공부와 개발에 그대로 쓴다

    이 개념은 책상 양쪽에서 다 쓰인다.

    공부: 새 지식이 안 외워지는 건 머리가 나빠서가 아니라 걸어둘 틀이 없어서일 때가 많다. 새 개념을 만나면 “내가 아는 것 중 무엇과 닮았나”부터 찾아라. 비유 하나가 반복 열 번보다 오래간다.

    개발: 데이터를 받기 전에 스키마부터 정하라. “일단 저장하고 나중에 정리”는 거의 항상 쓰레기 산으로 끝난다. 그리고 스키마 변경은 그 위의 데이터 전부에 영향을 주는 수술이다 — 바꾸기 전에 백업.

    한 줄 정리

    스키마 = 틀. 틀이 먼저 있어야 새것이 자리를 잡는다 — 데이터베이스에서도, 머릿속에서도.

    참고한 것

    글에 쓴 실험·용어의 출처다.

    • Frederic Bartlett, Remembering (1932) — “유령들의 전쟁” 실험, 스키마 이론의 출발
    • Jean Piaget — 아이는 동화(assimilation)·조절(accommodation)로 스키마를 키운다
    • JSON Schema — 개발 쪽 스키마 표준의 예

  • 깃허브 오픈소스 도구 고르는 기준 — 별점 8만짜리도 안 골랐다

    요약 — 먼저 결론

    깃허브에서 비슷한 도구 4개를 두고 고민했다. 결국 하나만 골랐다.

    재밌는 건 안 고른 이유다. 별점 8만짜리도 뺐고, 라이선스 배지를 믿었다가 틀리기도 했다.

    결론부터. 별점은 인기지 내 상황에 맞는다는 뜻이 아니다. 그리고 배지 하나도 곧이곧대로 믿으면 안 된다 — 내가 그렇게 틀렸으니까.

    별점은 인기지 ‘fit’이 아니다

    가장 별이 많은 걸 골랐을까? 아니다. 별점 8만이 넘는 도구를 안 골랐다.

    그건 멀티에이전트 트레이딩 프레임워크였다(TradingAgents, 별 8만4천). 강력하다. 그런데 실거래는 진짜 돈이 걸리고, 지금 내게 필요한 게 아니었다.

    별점은 마치 식당 리뷰 수와 같다. 리뷰가 5만 개라고 내 입맛에 맞는 건 아니다. 별점은 ‘남들이 많이 본다’는 신호지, ‘나한테 맞다’는 보장이 아니다.

    배지를 믿었다가 틀렸다 — 라이선스 이야기

    여기서 내가 한 번 틀렸다. 정직하게 적는다.

    나는 한 금융 터미널(FinceptTerminal)을 “라이선스 함정(AGPL)”이라고 메모해 뒀다. 그런데 직접 확인해 보니 AGPL이 아니었다. 깃허브가 표준 라이선스로 인식 못 하는 NOASSERTION 상태였다.

    NOASSERTION은 “나쁘다”가 아니다. “성분표가 표준이 아니니 직접 까보라”는 뜻이다. 실제로 앤트로픽이 낸 보안 도구(defending-harness)도 똑같이 NOASSERTION이었다.

    라이선스 배지 하나로 판단하면 틀린다. 포장지만 보고 멀쩡한 걸 함정이라 부를 뻔했다. 배지는 직접 읽기 전까지 가설일 뿐이다.

    그래서 기준은 “좋냐”가 아니라 “맞냐”

    좋은 도구를 찾는 게 아니다. 내 스택·필요·리스크에 맞는 도구를 찾는 거다.

    도구 별점 라이선스 고른/안 고른 이유
    HyperFrames 2만6천 Apache-2.0 ✅ 골랐다 — 블로그를 영상으로, 바로 씀
    TradingAgents 8만4천 Apache-2.0 실거래 리스크 + 지금 필요 아님 → 보류
    FinceptTerminal 2만6천 NOASSERTION 라이선스 직접 읽어야 + C++(내 스택 아님) + 통째 앱인데 조각만 필요
    defending-harness 5천 NOASSERTION 좋지만 ‘직접 커스텀하는 참고용’이라 즉시 적용 아님

    전부 좋은 도구다. 다만 나한테 지금 맞는 건 하나였다.

    “다 좋다”고 하면 의심하라

    이 평가를 처음엔 AI 조수에게 맡겼다. 그랬더니 네 개를 다 좋게 말했다.

    내가 물었다. “전부 적용할 점이 있다는 거야?” 그제야 솔직한 순위가 나왔다.

    누구든 — AI든 리뷰어든 — 평가를 맡기면 띄우는 쪽으로 기운다. 그래서 물음을 바꿔야 한다. “뭐가 좋아?”가 아니라 “뭘 버려야 해?”

    한 줄 정리

    별점도, 배지도, ‘AI의 첫 대답’도 신호일 뿐이다. 직접 확인하고, “좋냐”가 아니라 “맞냐”로 골라라.

    확인한 것

    글에 적은 숫자는 추측이 아니라 직접 확인한 값이다.

    • 네 repo의 별점·라이선스·언어는 깃허브 API로 직접 확인(2026-06)
    • NOASSERTION = 깃허브가 표준 SPDX 라이선스로 식별 못 한 상태(비표준/커스텀) → 직접 LICENSE 파일 확인 필요

  • 블로그 자동발행 스킬을 만들었다 — 그리고 이 글이 그 첫 결과물이다

    요약 — 먼저 결론

    블로그에 글 하나 올리는 데 손이 너무 많이 갔다. 제목, 요약, 카테고리, 번역, 캐시 비우기까지 11단계.

    그래서 이 과정을 한 번에 처리하는 도구를 만들었다. 핵심은 “자동화”가 아니라 글이 읽히게 만드는 것이었다.

    그리고 만들면서 깨달았다. 만드는 건 쉽고, 내놓는 게 어렵다. 지금 읽는 이 글이 그 ‘내놓기’의 첫 결과물이다.

    왜 만들었나 — 같은 잔손질 11번

    글 하나 올릴 때마다 똑같은 일을 손으로 반복했다. 세어 보니 11개였다.

    1. 제목 짓기
    2. 요약 쓰기
    3. 카테고리 붙이기
    4. 태그 달기
    5. 한글판 올리기
    6. 영어판으로 번역
    7. 두 판을 번역쌍으로 연결
    8. 글을 웹용으로 변환
    9. 발행
    10. 캐시 비우기
    11. 주소가 살아있는지 확인

    한 번은 재밌다. 열 번째부턴 일이다. 빠뜨리는 것도 생긴다. 영어판 연결을 깜빡하거나, 캐시를 안 비워서 옛날 글이 보이거나.

    매번 같은 재료를 같은 순서로 써는 일이다. 레시피를 외울 게 아니라 밀키트를 만들어야 한다.

    진짜 문제는 자동화가 아니었다 — “읽히는가”

    자동화는 절반이었다. 더 중요한 건 올린 글이 실제로 읽히느냐였다.

    사람은 글을 안 읽는다. 훑는다. 닐슨 노먼 그룹(NN/g) 연구에서 사람은 웹페이지 글자의 20~28%만 읽는다.

    《스틱(Made to Stick)》엔 더 무서운 실험이 있다. 머릿속 노래의 박자를 두드리는 사람은, 듣는 사람이 곡을 맞힐 확률을 50%로 봤다. 실제론 40곡 중 1곡이었다.

    쓰는 사람 머릿속엔 멜로디가 흐르지만, 읽는 사람에겐 ‘똑똑’ 소리만 들린다. 이걸 “지식의 저주”라 부른다. 내가 아는 걸 남도 알 거라는 착각.

    그래서: 이해도를 ‘보안 게이트’처럼 만들었다

    읽히는 글을 강제하기로 했다. 통과 못 하면 발행이 안 되는 검사기를 짰다.

    비밀번호 검사를 떠올리면 된다. 너무 짧으면 가입이 안 되듯, 글도 기준을 못 넘으면 못 올라간다.

    검사 항목은 연구에서 그대로 뽑았다.

    • 결론이 맨 위에 있는가 — 각 단락 첫 문장이 곧 답
    • 한 단락이 너무 길지 않은가 — 길면 건너뛴다
    • 소제목이 충분한가 — 훑는 사람의 이정표
    • 한 문장이 너무 길지 않은가 — 숨이 차면 못 읽는다
    • 비유와 예가 있는가 — 추상적이면 안 박힌다

    이 글도 그 검사기에 걸렸다. 초안 끝에 멋 부린 마무리 한 문장을 넣었는데, 나는 겸손한 매듭이라 여겼다. 검사기는 “흔한 상투구”라며 막았다. 빼버렸다.

    쓰는 나에겐 멋이고, 읽는 쪽엔 군더더기. 이게 지식의 저주의 작은 실례다. 검사기가 그 간극을 대신 잡아줬다.

    뜻밖의 발견 — 한 번 잘 쓰면 세 곳에서 이득

    읽기 좋게 다듬었더니 효과가 한 군데가 아니었다. 세 군데였다.

    사람이 훑기 좋은 글은 검색·요약하는 AI도 뽑아 쓰기 좋다. 요즘 검색은 AI가 결과를 정리해 보여주는데, 결론이 위에 있고 단락이 짧은 글을 먼저 인용한다.

    그렇게 정리된 글은 공유하기도 좋다. 핵심 세 줄을 그대로 가져다 쓸 수 있으니까.

    레버 하나를 당겼는데 문이 셋 열렸다. 사람·AI·공유가 같은 방향을 본다.

    삽질 기록 — 날것 그대로

    깔끔하게 된 건 하나도 없었다. 막힌 것들을 그대로 적는다.

    도구가 글자를 거부했다. 글을 옮기는 한 방식이 보안 필터에 걸려 멈췄다. 다른 방식으로 우회했다.

    메뉴에 안 떴다. 스킬을 만들었는데 목록에 안 보였다. 파일 맨 위 설정 한 줄이 빠져 있었다. 잘 되는 도구와 비교해서야 찾았다.

    영어판 주소가 충돌했다. 한글판과 같은 주소를 쓰니 시스템이 뒤에 숫자를 붙였다. 영어판엔 고유 주소를 따로 줬다.

    매끈한 결과물 뒤엔 늘 이런 잔고장이 있다.

    도구 스택 — 인프라까지 공개

    뭘로 굴리는지도 숨기지 않는다.

    블로그는 집에 둔 작은 PC 한 대에서 돈다. 그 위에 도커로 워드프레스를 띄우고, 다국어 플러그인으로 한글·영어를 짝짓는다.

    밖에서 접속되게 하는 건 클라우드플레어 터널이다. 글 초안은 무료 gpt-4o에게 맡기고, 읽기 검사기는 파이썬으로 직접 짰다.

    진짜 배운 것 — 만드는 건 쉽고, 내놓는 게 어렵다

    이번에 가장 크게 남은 한 가지다. 도구를 만드는 일은 편하고, 내놓는 일은 불편하다.

    도구 만들기 내놓기
    통제 내 손안 남의 반응
    실수하면 고치면 끝 남이 본다
    기분 편함 불편함
    성장 적음 큼

    그래서 자꾸 도구만 더 만들고 싶어진다. 그게 편하니까. 하지만 성장은 불편한 쪽에 있다.

    그래서 이 글을 쓴다. 만든 이야기를 만든 채로 두지 않고 밖에 내놓는 것. 이 글 자체가 그 연습이다.

    한 줄 정리

    도구는 읽히는 글을 강제하려고 만들었지만, 진짜로 배운 건 따로 있다. 만드는 건 쉽고 내놓는 게 어렵다 — 그러니 내놓아라.

    참고한 것

    • 닐슨 노먼 그룹(NN/g), “How Users Read on the Web” — 글자의 20~28%만 읽음
    • 칩 히스·댄 히스, 《스틱(Made to Stick)》 — 지식의 저주, 두드리는 사람 실험
    • Diátaxis — 문서 유형 4분류(튜토리얼·how-to·참고·설명)

  • 야크 셰이빙, 멱등성, 도그푸딩, 데드맨 스위치 — 코드 밖에서도 통하는 개발 용어 4개

    개발자들이 쓰는 말 중엔 코드보다 일하는 방식을 가리키는 게 많다. 오늘 넷이 그렇다 — 곁가지에 홀리는 함정, 몇 번을 해도 안전한 반복, 내놓기 전에 내가 먼저 써보기, 내가 멈췄을 때 안전하게 멈추는 장치. 알아두면 협업할 때도 혼자 일할 때도 쓰인다.

    요약

    • 야크 셰이빙: 진짜 할 일을 하려다 곁가지가 꼬리를 물어 엉뚱한 데서 시간을 다 쓰는 것
    • 멱등성: 몇 번을 실행해도 결과가 한 번 한 것과 같은 성질 (재시도해도 안전)
    • 도그푸딩: 남에게 내놓기 전에 내가 먼저 사용자로 써보는 것
    • 데드맨 스위치: 내가 “살아있다”는 신호를 멈추면 시스템이 자동으로 안전하게 정지하는 장치
    • 넷의 공통점: 코드 용어 같지만 실은 집중·안전·정직·대비라는 일의 태도
    용어 한 줄 뜻 일에서는
    야크 셰이빙 곁가지가 꼬리를 물어 본질을 잃음 집중
    멱등성 여러 번 해도 결과가 한 번과 같음 안전한 반복
    도그푸딩 내놓기 전 내가 먼저 써봄 정직한 검증
    데드맨 스위치 내가 멈추면 시스템이 안전하게 정지 실패 대비

    1. 야크 셰이빙 (Yak Shaving)

    차를 닦으려는데 호스가 없다. 호스를 사려니 마트 회원카드가 만료됐고, 갱신하려니 옆집이 빌려간 책을 돌려줘야 하고… 정신을 차려보니 동물원에서 야크 털을 깎고 있다. 정작 차는 그대로다.

    이렇게 진짜 목표를 위해 시작한 곁가지 작업이 꼬리에 꼬리를 물어, 원래 일과 상관없어 보이는 데서 시간을 다 쓰는 것이 야크 셰이빙이다. MIT에서 나온 표현이라고 알려져 있다.

    개발에서 흔하다. “버그 하나 고치자” → “그러려면 라이브러리 업데이트” → “그러려면 빌드 도구 교체” → 반나절째 환경 설정 중. 일상도 똑같다 — 글 하나 쓰려다 블로그 테마부터 손보고 있는 것.

    빠져나오는 법: “지금 이게 원래 하려던 일에 정말 필요한가?”를 한 번 묻는다. 아니면 곁가지는 메모만 남기고 본 작업으로 돌아온다.

    2. 멱등성 (Idempotency)

    엘리베이터 버튼을 열 번 눌러도 한 번 누른 것과 똑같이 온다. 이게 멱등성이다 — 같은 동작을 여러 번 해도 결과가 한 번 한 것과 같은 성질.

    원래 수학 용어(f(f(x)) = f(x))인데, 개발에선 특히 재시도 안전에서 중요하다. 결제 요청을 보냈는데 응답이 안 와 다시 보냈다고 하자. 멱등하지 않으면 두 번 결제된다. 멱등하면 같은 요청은 한 번만 처리된다 — 요청마다 붙이는 “멱등 키”로 구분한다.

    구분도 쉽다. “삭제”는 멱등이다(이미 지운 걸 또 눌러도 여전히 지워진 상태). “1개 추가”는 멱등이 아니다(누를 때마다 늘어남).

    왜 알면 좋나: 자동화·재시도가 들어가는 모든 곳(결제·알림·동기화)에서 “이게 두 번 실행되면 사고가 나나?”를 판단하는 기준이 된다.

    3. 도그푸딩 (Dogfooding)

    “자기 개밥 자기가 먹기(eat your own dog food).” 개사료 회사가 자기 개에게 그 사료를 먹이며 품질을 증명했다는 데서 나왔고, 1988년 마이크로소프트가 “우리 소프트웨어를 우리가 먼저 쓰자”는 뜻으로 퍼뜨렸다고 알려져 있다.

    뜻은 단순하다 — 남에게 팔거나 내놓기 전에, 내가 먼저 사용자로 써보는 것. 직접 써봐야 버그도 잡고, 사용자가 어디서 불편한지 몸으로 안다.

    핵심은 정직이다. 내가 안 쓰는 도구를 남에게 권하긴 어렵다. 반대로 내가 매일 쓰는 도구는 빠르게 좋아진다 — 불편하면 내가 제일 먼저 아프니까.

    한 칸 더 — 도그푸딩은 “내가 써보기”까지다. 그다음 칸은 모르는 남이 써보는 것이고, 진짜 시험은 거기서 시작된다.

    4. 데드맨 스위치 (Dead Man’s Switch)

    기차 기관사가 운전 중 쓰러지면 어떻게 될까. 옛 기차엔 페달이 있었다. 기관사가 페달을 계속 밟고 있어야 기차가 달리고, 발을 떼면(쓰러지면) 기차가 자동으로 멈춘다. 이 장치가 데드맨 스위치다.

    이름은 섬뜩하지만 발상은 단순하다 — 내가 멈췄을 때, 시스템이 알아서 안전하게 멈추는 것. 평소엔 “나 살아있다”는 신호를 계속 보내야 하고, 그 신호가 끊기면 최악을 가정하고 안전 쪽으로 작동한다.

    개발·자동화에서 그대로 쓴다. 자동매매 봇이 응답을 멈추면 포지션을 자동으로 정리한다(안 그러면 시장이 급변해도 무방비). 서버가 주기적 “심장박동(heartbeat)”을 못 보내면 다른 서버가 대신 깬다.

    왜 알면 좋나: 무인으로 도는 모든 것(봇·크론·자동화)에 “이게 죽으면 어떻게 안전하게 멈추지?”를 미리 심는 발상이다. 켜는 것보다 죽을 때를 설계하는 것이 진짜 안전이다.

    한 줄 정리

    세 용어는 코드가 아니라 태도를 가리킨다.

    • 야크 셰이빙 → 곁가지에 홀리지 말고 본질에 집중하라
    • 멱등성 → 반복·재시도해도 안전하게 설계하라
    • 도그푸딩 → 내놓기 전에 내가 먼저 써봐라
    • 데드맨 스위치 → 잘 돌 때가 아니라 죽을 때를 설계하라

    이름을 알면 일이 어디서 새는지 가리킬 수 있다. 개발자와 대화할 때도, 혼자 일할 때도.