Rapfi 를 엔진으로 오목·렌쥬 서비스를 만들 때 고려할 점을 정리합니다. 서버·브라우저(WASM)·앱 배치에 따라 달라지는 GPLv3 의무, 상태를 가진 Piskvork 프로토콜을 다루는 프로세스 모델과 Go 래퍼, 판 크기와 렌쥬 오프닝 규정의 공백, 초보자용 난이도 설계의 함정, 자원·버전 관리까지 실측과 소스 근거로 짚습니다.

«A Philosophy of Software Design» 19~21장으로 8부작을 맺습니다. struct embedding 으로 흉내 낸 구현 상속에서 ‘덮어쓴’ 메서드가 부모의 호출에는 적용되지 않는 함정을 재현하고 인터페이스 합성으로 바꾸며, 저자의 TDD 비판을 공정하게 옮기고 반론을 덧붙입니다. 20장의 RAMCloud Buffer 예제를 Go 로 옮겨 ‘측정 먼저’ 를 실제로 해 본 결과는 책의 2배가 아니라 10% 였고, 그 숫자를 그대로 싣습니다. 마지막으로 시리즈 전체를 위험 신호 표 하나로 정리합니다.

«A Philosophy of Software Design» 16~18장을 Go 코드로 읽습니다. 경로 탈출 버그를 Save 한 곳에만 땜질해서 Load 와 Delete 에 구멍을 남기는 수정과, ID 타입을 도입해 세 함수를 한 번에 막는 수정을 비교하고, ‘없음’ 을 네 가지 방식으로 표현하는 저장소를 한 가지로 통일하며, 제네릭 Pair 의 First·Second 를 이름 있는 struct 로 바꾸고, 이벤트 버스 뒤에 숨은 호출 흐름을 직선으로 펴는 과정을 Before → After 로 보여 줍니다. gofmt 가 이 책의 17장을 언어 차원에서 구현한 것이라는 이야기도 합니다.

«A Philosophy of Software Design» 12~15장을 Go 코드로 읽습니다. 이름을 그대로 풀어 쓴 주석을 단위와 경계 조건을 채운 주석으로 바꾸고, 저자가 6개월을 쏟은 Sprite 의 block 버그를 Go 의 named type 으로 컴파일 시점에 잡아내며, 14.5절에서 저자가 Go 스타일 가이드와 갈라서는 지점을 양쪽 논거 그대로 싣습니다. 여섯 줄짜리 주석 없이는 설명할 수 없던 Search 함수를 주석부터 다시 써서 설계를 고치는 과정도 보여 줍니다.

«A Philosophy of Software Design» 10장을 Go 코드로 읽습니다. 예외가 없는 Go 에서 이 장은 ‘if err != nil 을 어떻게 줄이는가’ 라는 질문이 됩니다. 없는 노트를 지우면 에러를 내던 Delete 를 ‘없는 상태로 만든다’ 로 재정의해 시그니처에서 error 를 지우고, 범위 밖이면 패닉하던 Snippet 을 항상 정의되는 함수로 바꾸고, 짧은 읽기를 io.ReadFull 로 감추고, 핸들러마다 반복되던 http.Error 를 한 곳으로 모으고, nil 검사를 부르던 ‘선택 없음’ 을 빈 선택으로 없앱니다. 저자가 Tcl 의 unset 을 설계 실수로 꼽는 이유와, 이 원칙을 지나치게 밀면 어떻게 되는지도 함께 봅니다.

«A Philosophy of Software Design» 9장과 11장을 Go 코드로 읽습니다. ‘20줄 넘으면 나눠라’ 를 따르느라 공유 상태 구조체를 주고받는 함수 다섯 개가 된 임포트 코드를 하나로 되돌리고, 텍스트 타입 안에 커서 undo 까지 끌어안은 설계를 범용 History 와 특수 목적 Action 으로 갈라내며, 줄 단위·범위 단위 두 인터페이스를 둘 다 Go 로 써 보고 상위 코드의 길이로 판정합니다. 책이 Clean Code 와 갈라서는 지점도 이 장에 있습니다.

«A Philosophy of Software Design» 6~8장을 Go 코드로 읽습니다. 백스페이스 키마다 메서드를 하나씩 둔 텍스트 타입을 Insert 와 Delete 두 개로 줄이면서 여러 줄 선택 삭제가 공짜로 생기는 과정, 다섯 메서드 중 넷이 저장소를 그대로 부르는 ‘서비스 계층’ 을 걷어내는 과정, 함수 네 단계를 관통하는 pass-through 인자를 App 구조체로 거두는 과정, 그리고 재시도 간격을 설정값으로 떠넘기는 대신 응답 시간을 재서 스스로 정하게 만드는 과정을 Before → After 로 보여 줍니다. Go 의 context.Context 가 책의 context 와 다른 이유도 짚습니다.

«A Philosophy of Software Design» 4~5장을 Go 코드로 읽습니다. 객체 세 개를 조립해야 노트 하나를 읽을 수 있는 얕은 모듈을 함수 하나짜리 깊은 모듈로 바꾸고, 내부 map 을 그대로 돌려주는 인터페이스가 어떻게 정보를 누출하는지, ‘읽고 나서 파싱한다’ 는 시간적 분해가 왜 같은 지식을 두 곳에 복사하게 만드는지를 실제로 컴파일되는 Before → After 로 보여 줍니다. go doc 출력 줄 수로 인터페이스 크기를 세는 방법도 소개합니다.

존 오스터하우트의 «A Philosophy of Software Design» 을 Go 코드로 다시 읽는 8부작의 첫 편입니다. 책이 말하는 복잡성의 세 가지 증상(변경 증폭·인지 부하·모름)과 두 가지 원인(의존성·모호성)을 각각 Before → After Go 코드로 보여 주고, 전술적 땜질이 어떻게 쌓이는지와 전략적 수정이 무엇을 다르게 하는지를 같은 버그 하나로 비교합니다. Go 가 이 책과 어디서 부딪히는지도 미리 밝혀 둡니다.

훌라 hard 봇의 값을 동결하고, 한 번도 쓰지 않은 딜 256개에서 최종 검증을 합니다. 실험이 고른 값을 일부러 쓰지 않은 자리와 그 이유, 시험 문제를 열기 전에 합격선을 못 박는 절차, 인원이 늘수록 두 배씩 벌어진 결과, 그리고 Part 4 의 여덟 자리 중 무엇이 메워졌고 무엇이 메운 줄 알았는데 아니었는지를 결산합니다.

훌라 hard 봇을 시뮬레이터로 잽니다. 같은 딜에서 hard 와 easy 를 바꿔 앉혀 딜 운을 지우는 방법, 도구가 만들어지자마자 잡은 “다른 봇을 재고 있었다” 는 버그, 8 seed 로는 아무 말도 못 하고 32 seed 에서야 방향이 보인 첫 성적, 그리고 손으로 정한 추 열한 개를 하나씩 빼 보니 넷은 5만 번의 결정에서 수를 하나도 바꾸지 않았다는 사실까지 다룹니다.

훌라 hard 봇의 땡큐와 스톱 판단을 다룹니다. 땡큐는 가져갔을 때와 안 가져갔을 때를 같은 자로 재야 한다는 것, 봇을 남의 차례에 깨우는 배선이 없으면 시뮬레이터에서 98% 를 가져가던 봇이 실제 서버에서는 한 번도 못 건다는 것, 일반 스톱은 기대값으로 판단하되 첫 구현에서 건 스톱의 36% 가 스톱박이 나 확률부터 고쳐야 했다는 이야기입니다.

훌라 hard 봇이 자기 차례에 무엇을 알고 어떻게 한 수를 고르는지 다룹니다. 지금까지 공개된 카드를 적어 두는 장부, 이번 턴에 할 수 있는 모든 행동 순서를 끝까지 그려 보는 계획, 남은 손패를 재는 추 일곱 개짜리 저울, 그리고 저울보다 위에 있는 규칙까지 카드 게임 용어로 설명합니다.

훌라 easy 봇의 한계를 여덟 자리로 정리합니다. 한 수 greedy 가 손패 전체를 깨뜨리는 실례, 7 을 전략적으로 쥘 줄 모르는 문제, 공개 카드를 기억하지 않는 문제까지 짚고, 이 여덟 개를 다 메우면 정말 강한 봇이 되는지를 앞선 두 시리즈의 실패 기록과 함께 따져 봅니다.

훌라 easy 봇을 규칙 다섯 줄로 구현합니다. 뽑고, 가장 많이 터는 조합을 등록하고, 가장 많이 붙이고, 가장 비싼 카드를 버립니다. 짧은 코드지만 결정론과 fallback 이라는 두 가지 운영 요건을 만족해야 하고, 이 봇이 우연히 잘하는 것과 원리적으로 못 하는 것이 무엇인지 정리합니다.

훌라 봇을 만들기 전에 경계를 긋습니다. 봇이 봐도 되는 정보는 어디까지인지, 봇이 규칙을 다시 판단하면 왜 안 되는지, 봇이 한 턴이 아니라 한 수만 돌려줘야 하는 이유가 무엇인지 정리하고, easy 와 hard 가 각각 무엇을 더 보고 무엇을 더 결정하는지 비교합니다.

시리즈 마지막입니다. 명시적 제어 평가기를 만들어 꼬리 재귀의 스택 깊이를 n 과 무관하게 10 으로 고정했고, 그 한 줄을 빠뜨렸다가 다시 찾은 과정을 실측과 함께 실었습니다. 컴파일러는 어휘 주소 지정으로 해석 대비 4.2배 빨라졌습니다. 마지막에 네 가지 실행 방식을 속도와 공간 두 축에 올리고, Go 로 SICP 를 읽은 것에 대한 최종 판정을 정리했습니다.

SICP 5장은 레지스터와 명령어만 있는 기계를 만들고 그 위에서 재귀를 구현합니다. 시리즈 내내 세 번 미룬 질문 — 꼬리 재귀는 왜 상수 공간인가 — 이 여기서 push 횟수 0 으로 자명해집니다. stop-and-copy 가비지 컬렉터도 만들었고, 만드는 도중 루트 집합을 빠뜨려 리스트가 깨진 사고를 그대로 실었습니다.

SICP 4.3 은 백트래킹을 언어 기능으로 만듭니다. amb 로 아무 값이나 고르고, 모순이 나오면 시간을 되감습니다. Part 1 에서 예고한 세 번째 마찰인 일급 연속의 부재는 실제로는 문제가 되지 않았고, 대신 다른 곳에서 값을 치렀습니다. 다세대 주택 퍼즐을 원서와 같은 답으로 풀었고 호스트 스택 132 MB 를 썼습니다.

SICP 4.1.7 은 구문 분석을 실행에서 분리해 평가기를 빠르게 만듭니다. 실제로 재 보니 1.74배 빨라지고 할당이 절반으로 줄었습니다. 그런데 같이 재 보니 꼬리 호출 최적화가 사라졌습니다. 스택이 0.62 MB 에서 512 MB 로 늘었습니다. 후반부는 게으른 평가기입니다. 세 군데만 고치면 스트림이 언어 기능으로 공짜로 딸려 옵니다.