해시 충돌을 가르치는 그림이라면, 먼저 모양이 아니라 상태 변화의 규칙을 정해야 합니다. Anatomy는 기술 개념을 조작 가능한 SVG 설명으로 만드는 데 쓸 수 있는 에이전트용 키트입니다. 작은 팀이 온보딩 자료나 개발 문서를 만들 때 검토할 만하지만, 연결선과 부품 배치가 자연스럽다는 이유만으로 알고리즘까지 맞다고 판단하면 안 됩니다. 이 글은 네 개의 버킷을 가진 교육용 모델을 기준으로, 어떤 결과를 받아들일지 정하는 방법을 설명합니다.
확인: 2026년 10월 20일 · 대상: Anatomy v1.1.0 · 검증 범위: 공식 문서·릴리스 검토와 AI를 활용한 집필·편집. 프로젝트 설치, 그림 생성 결과의 실행, 성능 측정은 하지 않았습니다. 아래 모델과 확인 항목은 이 글에서 설계한 제안이며 실제 테스트 결과가 아닙니다.
정적 관계도 대신 조작 가능한 설명이 필요한 때
서버와 데이터베이스의 연결 관계만 보여주려면 Mermaid 같은 정적 다이어그램이 더 단순한 선택입니다. 반면 서로 다른 두 키가 같은 위치에 도착한 뒤에도 각각의 값을 찾는 과정을 설명하려면, 입력을 바꾸고 저장 상태를 따라가는 화면이 도움이 될 수 있습니다. Anatomy를 검토할 이유는 이 차이에 있습니다. 도구 이름보다 독자가 직접 바꿔 볼 입력이 있는지 먼저 판단하세요.
공식 릴리스 기록상 첫 버전은 2026년 10월 10일, v1.1.0은 10월 12일에 공개됐습니다. 공개 이력이 짧은 프로젝트인 만큼, 이 릴리스 기록만으로 안정성이 입증됐다고 볼 수는 없습니다. 별 수나 관심도보다 아래처럼 좁은 설명 과제에 맞는지 살펴보는 편이 유용합니다.
관심의 단서도 있습니다. GeekNews의 Anatomy 소개 글은 2026년 10월 20일 21:36 KST 확인 당시 19점·댓글 1개였습니다. 다만 최근 GitHub 별 증가량은 확인하지 못했습니다. 이 반응은 도구를 살펴볼 계기일 뿐, 정확성이나 안정성을 입증하는 자료는 아닙니다.
관련 글인 아키텍처 다이어그램의 표현과 정확성이 정적 구조를 어떻게 표현할지 다뤘다면, 여기서는 입력 뒤 저장 상태와 조회 결과가 어떻게 바뀌어야 하는지에 초점을 맞춥니다.
먼저 고정할 것: 네 버킷짜리 교육용 모델
실제 Python의 hash()나 dict 구현을 재현하려는 것이 아닙니다. 정수 키에 대해 버킷 번호를 k % 4로 계산하고, 충돌하면 같은 버킷의 목록에 항목을 이어 붙이는 별도 교육용 모델입니다. 이런 충돌 처리 방식을 분리 연결법(separate chaining)이라고 합니다. 키가 이미 있으면 값을 바꾸고, 없으면 새 항목을 추가한다고 정합니다. 삭제·리사이징·동시 접근·실제 성능은 범위에서 제외합니다.
- 초기화: 버킷 0~3은 비어 있고 저장 항목 수는 0입니다.
- 첫 삽입: 키 1, 값 A를 넣으면 1 % 4 = 1이므로 버킷 1에 (1, A)가 생깁니다. 항목 수는 1입니다.
- 충돌 삽입: 키 5, 값 B도 버킷 1로 갑니다. 이때 (1, A)를 지우거나 덮어쓰지 않고 (5, B)를 추가합니다. 항목 수는 2입니다.
- 조회: get(1)은 A, get(5)는 B를 보여줘야 합니다. 같은 버킷이라는 이유만으로 같은 키로 취급하지 않고, 목록 안에서 키를 비교합니다.
- 기존 키 갱신: 키 1의 값을 C로 바꾸면 get(1)은 C, get(5)는 여전히 B입니다. 항목 수는 2로 유지됩니다.
- 없는 키 조회: 키 9도 버킷 1에 해당하지만 저장한 적은 없습니다. get(9)는 A·B·C 중 하나가 아니라 ‘찾을 수 없음’을 표시해야 합니다. 항목 수와 저장 내용은 바뀌지 않습니다.
이 순서를 화면에 붙일 설명이 아니라 결과물의 수용 조건으로 사용하세요. 화살표가 버킷 1로 이동하는 장면만으로는 부족합니다. 저장된 항목, 조회 결과, 항목 수 표시가 같은 상태를 반영해야 합니다. 화면 구석의 숫자를 애니메이션과 별도로 바꾸면 그럴듯하게 움직이면서도 잘못된 설명이 될 수 있습니다.
기하 검사와 알고리즘 확인은 다른 작업입니다
v1.1.0의 작업 지침을 검토할 때는 시각적 검사와 모델 검증을 구분해야 합니다. 부품의 연결·겹침·깊이 순서 같은 기하 문제가 해결돼도, 앞서 정한 삽입과 조회 규칙이 맞는지는 별도로 확인해야 한다는 것이 이 글의 판단입니다. 눈에 보이는 배치 오류를 찾는 검사를 해시 테이블의 정확성 증명으로 확대할 수는 없습니다.
검토 순서는 ‘초기화 → 1 삽입 → 5 삽입 → 두 키 조회 → 1 갱신 → 두 키 재조회 → 없는 키 9 조회’로 고정하면 됩니다. 각 단계에서 버킷 내용과 반환값, 항목 수를 함께 확인합니다. 재생·초기화 버튼을 넣었다면 반복 조작 뒤 상태가 의도대로 돌아오는지도 확인 대상입니다. 여기까지는 독자가 결과물을 받아 본 뒤 수행할 점검 계획이며, 이 글에서 실행해 통과한 항목이 아닙니다.
시작할 때는 버전과 범위를 함께 넘기세요
처음에는 v1.1.0 릴리스의 소스와 해당 버전에 고정된 README를 확인하는 방법이 좋습니다. wheresryan22/anatomy 저장소의 MIT 라이선스 프로젝트이며, v1.1.0 문서는 Claude Code·OpenCode·Codex 사용을 안내합니다. 설치·실행 전에 파일 구성과 필요한 도구, 외부 전송 범위를 검토하고, 위 교육용 모델과 제외 범위를 작업 요청에 함께 적습니다. 저장소의 최신 문서가 나중에 바뀌더라도 같은 기준을 다시 확인할 수 있습니다.
필요한 Node 버전도 구분해야 합니다. 문서의 키트 최소 조건은 Node 20.10 이상이지만, 문서에서 언급하는 skills CLI 1.7.1은 Node 22.20 이상을 요구합니다. 키트 조건만 보고 설치 도구까지 같은 환경에서 동작한다고 가정하지 마세요. 이 글은 설치 명령을 실행해 호환성을 검증하지 않았습니다.
에이전트가 만든 결과물을 수정할 사람과 검증 기준이 없다면 도입을 미루는 편이 낫습니다. 계산 규칙과 접근성 요구를 엄격히 통제해야 하고 팀에 구현 여력이 있다면, 작은 HTML·JavaScript 예제를 직접 작성하는 선택도 있습니다. 이 역시 자동으로 정확해지는 방법은 아니지만, 모델과 표시의 연결을 직접 검토하기는 수월합니다. 모델 제공자의 이용료는 별도 확인이 필요하며 여기서는 비용을 검증하지 않았습니다.
공유는 생성과 분리해서 결정합니다
설명 페이지를 만드는 것과 공개 갤러리에 제출하는 것은 별개의 결정입니다. 공개 제출을 원하지 않는 작업에서는 갤러리 공유를 요청할 필요가 없습니다. 제출하려면 소스뿐 아니라 프롬프트와 제작 정보 등 공개될 내용도 먼저 살펴보고, 비공개 코드·내부 명칭·민감한 입력이 없는지 확인해야 합니다. 제작 과정의 정보를 붙이는 기능이 있다고 해서 업무 자료를 그대로 공개해도 된다는 뜻은 아닙니다.
채택 기준은 간단합니다. 독자가 입력을 바꾸며 상태 변화를 이해해야 하고, 팀이 그 상태 규칙을 검토할 수 있다면 Anatomy를 제한된 설명 과제에 검토할 수 있습니다. 관계만 보여주면 되는 문서라면 정적 그림으로 충분합니다. 어떤 방식을 택하든 ‘보기 좋은 그림’과 ‘맞는 설명’은 따로 확인해야 합니다.
댓글
댓글 쓰기