AI와 함께 배포부터 베타 테스트까지 — 윈도우 터미널 wTerm2 만들기 (2)

안녕하세요 가야태자 @talkit 입니다.

저는 기획 개발 배포까지 클로드와 함께 진행하고, 클로드와 함께 깃허브의 이슈로도 대화를 나누었습니다.

그리고, 어느정도 개발이 되었다는 전제 하에 베타 테스트를 하기에 이르렀습니다.

베타테스트 참여자가 개발 툴이라서 좀 적기는 합니다.

하지만, 주변의 지인분들과 지금 바쁜 일을 하고 베타 테스트 해보겠다는 분들이 있어서 베타테스트를 진행중이고, 이 베타테스트도 이슈가 올라오면 클로드가 이슈를 직접 읽고 답변 하도록 하고 있습니다.

지난 글에서 v0.6.1 배포를 준비한다고 했는데, 그 뒤로 사흘이 지났습니다. 그 사흘이 앞의 사흘보다 배운 게 많았습니다.

---

사흘 더 — 숫자

항목	1편 (8/6~8/8)	지금 (8/10)
커밋	81개	140개
소스 src/main.rs	8,874줄	11,621줄
문서	11,024줄	21,513줄
테스트	121개	146개
릴리스	v0.2.0 ~ v0.6.0	~ v0.6.4
연구노트	25건	38건
기술노트	—	7건
베타 테스터	—	2명
베타 이슈	—	7건 접수, 전부 닫음

문서가 두 배가 됐습니다. 소스도 늘었지만 문서가 더 빨리 늘었습니다. 왜 그렇게 됐는지가 이 글의 내용입니다.

---

1. 배포는 만드는 것과 다른 일이었습니다

같은 버전이 세 개 나란히 깔렸습니다

v0.6.1 을 올리고 제보가 왔습니다. "디자인이 옛날로 돌아갔다."

클로드가 처음에 "옛 창이 아직 떠 있는 것 같다" 고 진단했습니다. 저는 아니라고 했습니다.

아니야 내가 방금 사이트에서 내려 받아서 설치도 해봤어

떠 있는 것이 아니라 깔려 있던 것이었습니다. 설정 → 앱을 보니 wTerm2 0.6.1 이 세 개 있었습니다.

원인은 MSI 설정 한 줄이었습니다. WiX 의 MajorUpgrade 는 기본적으로 자기보다 낮은 버전만 지웁니다. 같은 버전을 다시 구워 설치하면 지우지 않고 나란히 하나 더 깔립니다.

<MajorUpgrade AllowSameVersionUpgrades='yes' ... />

베타 중에는 같은 버전을 하루에도 여러 번 다시 굽습니다. 그러니까 이게 기본 상황이었습니다. 시작 메뉴가 그 셋 중 어느 것을 여는지는 알 수 없고, 옛 것이 열리면 "고친 게 반영 안 됐다" 가 됩니다.

클로드가 그걸 확인하려고 MSI 를 손으로 뜯었습니다. OLE 복합 문서 → CAB → MSZIP 압축을 풀어서 안에 든 실행 파일이 정말 새 것인지 대조했습니다. 저는 그런 게 되는 줄도 몰랐습니다.

소스를 안 주고 바이너리만 주기

베타 테스터에게 줄 것과 제가 보는 것을 나눠야 했습니다. 개발 저장소에는 연구노트, 설계 문서, 제가 진단하는 과정이 다 남아 있어서 테스터가 보면 무엇이 문제인지 알 수 없습니다.

그래서 배포 저장소를 따로 만들었습니다.

	개발 저장소	배포 저장소
소스	있음	없음
연구노트·설계	있음	없음
사용 안내	있음	있음 (추려서)
라이선스 고지	있음	있어야 함
이슈	제 작업 기록	테스터 제보

여기서 클로드가 정한 방식이 좋았습니다. 뺄 것 목록이 아니라 넣을 것 목록입니다.

뺄 것 목록은 새 파일이 생길 때마다 손봐야 하고, 한 번 빠뜨리면 소스가 그대로 나갑니다. 넣을 것 목록은 빠뜨려도 "안 들어간다" 로 끝납니다.

그리고 복사한 뒤에 .rs·.toml·.wxs 가 섞였는지 확인하고, 있으면 멈춥니다.

깃허브가 자동으로 붙이는 zip

릴리스 페이지에는 Source code (zip) 이 자동으로 붙습니다. 끄는 설정도, API 옵션도 없습니다. MSI 옆에 나란히 보이니 소스를 같이 준 것처럼 보입니다.

클로드가 "그 zip 은 태그가 가리키는 커밋의 파일 전부이고, 배포 저장소에는 문서만 있으니 문서만 들어간다" 고 했는데, 저는 그래도 불안했습니다. 그래서 직접 받아서 열어봤습니다.

27개 파일, 러스트 소스 0개. 확인했습니다.

추측하지 말고 열어 보세요. 이게 이번 프로젝트에서 제일 많이 나온 문장인 것 같습니다.

---

2. 메뉴가 전부 한글이었습니다

제가 미디엄에 베타 테스트 하겠다고 글을 써놓고 나서 생각해보니, 메뉴와 도움말이 전부 한글이었습니다. 영어권 사람이 받으면 아무것도 못 읽습니다.

그래서 국제화를 했습니다. 클로드가 제안한 방식이 인상적이었습니다. 번역 파일을 따로 두는 게 아니라 구조체 리터럴로 두는 것입니다.

m("새 탭", "New tab")

이렇게 하면 한쪽을 빠뜨리면 컴파일이 안 됩니다. 번역 파일을 따로 두면 키가 빠져도 프로그램은 돌아가고, 빈 문자열이 화면에 나옵니다.

그런데 함정이 있었습니다. 급할 때 한글을 그대로 복사해 넣으면 통과합니다. 그래서 클로드가 소스를 직접 읽어서 "영어 자리에 한글이 남았거나 두 쪽이 똑같은 곳" 을 찾는 검사를 만들었습니다.

그 검사가 자기 자신을 세 번 잡았습니다 (연구노트 30). 검사 코드 안의 예시 문자열, 주석에 적어둔 설명, 테스트 자기 자신까지 걸렸습니다. 재미있었습니다.

문서도 두 벌이 됐습니다. README, 접속 설정 안내, 릴리스 노트 전부(v0.2.0부터), 라이선스 고지까지 한국어·영어 각각 있습니다. 지금 영문 문서가 14개입니다.

제가 요구한 방식은 이랬습니다.

모든 문서는 한글로 하고 한글 첫째 줄에 영어로 "영문버전은 여기 있습니다" 라고 한 다음에 모든 문서의 _en.md 를 만들어줘.

그대로 됐습니다. 그리고 제보 양식도 한국어/영어 두 개입니다. 깃허브는 양식이 둘 이상이면 "New issue" 에서 고르는 화면을 자동으로 띄워줍니다.

---

3. 테스터 모집

베타 테스터를 받으려니 문제가 하나 있었습니다. 비공개 저장소는 협업자로 초대해야 보입니다. 그러려면 깃허브 아이디를 받아야 합니다.

구글 폼으로 받기로 했습니다. 클로드가 폼에 넣을 글, 만드는 절차, 그리고 아이디 검증 정규식까지 만들어줬습니다.

여기서 하나 배웠습니다. 구글 폼의 정규식 엔진은 RE2 라서 전방탐색((?=...))이 안 됩니다. 클로드가 처음에 준 정규식이 거부당해서, 전방탐색 없이 다시 짜고 18가지 입력으로 검증했습니다.

그리고 초대할 때도 함정이 있었습니다. 없는 아이디로 초대하면 깃허브가 404 만 내고 왜 실패했는지 말해주지 않습니다. 실제로 제가 아이디 하나를 잘못 알아서 404 를 보고 "저장소 문제인가" 했는데, 그냥 없는 계정이었습니다. 그래서 초대 전에 계정이 있는지 먼저 확인하는 스크립트를 만들었습니다.

비공개 저장소라서 생기는 것이 하나 더 있습니다. 협업자는 서로의 이슈와 스크린샷을 전부 봅니다. 초기 이슈의 캡처에 제 접속 목록이 찍혀서 서버 이름과 IP 가 그대로 보이고 있었습니다. 그 이슈 둘은 내용을 개발 저장소로 옮기고 지웠습니다. 그리고 제보 양식에 이렇게 넣었습니다.

이 저장소는 비공개지만 다른 테스터에게도 보입니다. 서버 주소나 계정은 가려 주세요.

---

4. 베타 테스트 — 제보 7건

여기가 이 글의 본론입니다.

이슈가 올라오면 클로드가 직접 읽고 답변합니다. 제가 중간에서 옮기지 않습니다. 클로드가 이슈를 읽고, 원인을 찾고, 고치고, 그 이슈에 댓글로 설명하고, 제가 실기에서 확인하면 닫습니다.

제보 양식의 칸 하나가 셋을 잡았습니다

이게 이번에 제일 좋았던 발견입니다.

v0.6.3 에서 제보 양식에 칸을 하나 추가했습니다.

비슷한데 되는 것이 있나요?

설명은 이렇게 적었습니다.

안 되는 것만큼 도움이 됩니다. 두 방법이 갈리는 지점이 곧 원인인 경우가 많습니다.

다음 판에서 바로 값을 했습니다. 고친 것 넷 중 셋이 이 칸 하나로 갈렸습니다.

테스터가 쓴 한 줄	그것이 배제한 것	실제 원인
"SSH로 연결한 리눅스에서는 정상적으로 하나씩 지워집니다"	키 입력 경로 전체, 렌더링, IME	우리가 보내는 바이트가 관례와 어긋남
"파워쉘은 다 닫힘"	종료 감지, PTY, 읽기 스레드	ssh 가 원격의 종료 상태를 그대로 넘김
"드래그 복사는 안 되는데 Ctrl+Shift+C 는 된다"	클립보드, 권한, 선택 자체	클릭이 빈 선택을 만들고 있었음

셋 다 코드를 읽기 전에 후보가 하나로 줄었습니다. 안 되는 것만 알면 후보가 열 개인데, 되는 것과 나란히 놓으면 둘이 갈리는 지점이 곧 원인입니다.

백스페이스가 단어를 통째로 지웠습니다

powershell 환경에서 글자들을 입력하고 백스페이스로 지우면 여러 값이 한 번에 지워집니다.
ssh로 연결한 리눅스에서는 정상적으로 하나씩 지워집니다.

원인은 한 바이트였습니다. Backspace 키에 0x08(BS)을 보내고 있었는데, 터미널 관례는 0x7f(DEL) 입니다. 0x08 은 Ctrl+Backspace 자리입니다. xterm·iTerm2·윈도우 터미널 전부 그렇습니다.

왜 리눅스에서만 멀쩡했는지, 클로드가 맥에서 실제로 확인했습니다.

보낸 것	bash 응답
0x7f (DEL)	한 글자 지움
0x08 (BS)	한 글자 지움

리눅스의 readline 은 둘을 같은 동작으로 묶어둡니다. 그래서 어느 쪽을 보내도 정상으로 보입니다.

그런데 윈도우의 ConPTY 는 둘을 구분합니다. 0x08 을 Ctrl+Backspace 로 바꿔주고, PowerShell 에서 Ctrl+Backspace 는 앞 단어 전체 지우기입니다. 증상이 정확히 그것이었습니다.

한 플랫폼이 관대하면 다른 플랫폼의 버그가 숨습니다. 이게 이번에 배운 것입니다.

버그를 고치면 그 키는 아무 일도 안 하게 됐습니다

오른쪽에서 컨트롤 탭을 하면 왼쪽 터미널로 가지는데, 왼쪽 터미널에서 컨트롤 탭 하면 안 움직입니다.

버그는 있었습니다. Ctrl+Tab 은 탭 전환인데, 탭이 하나뿐이면 자기 자신을 다시 고르면서 포커스를 첫 창으로 되돌리고 있었습니다.

그런데 클로드가 고치면서 이렇게 말했습니다.

버그만 고치면 탭이 하나일 때 Ctrl+Tab 은 정확히 아무 일도 하지 않습니다. 그게 맞는 동작입니다. 그런데 제보자가 원한 것은 탭 전환이 아니라 나뉜 창 사이를 옮기는 것이었습니다.

확인해보니 마우스로 클릭하는 것 말고는 창을 옮길 방법이 없었습니다. 단축키 표에 새 탭, 분할, 탭 이동은 있는데 창 이동이 없었습니다. 그래서 테스터가 가장 그럴듯한 키를 눌러본 것이고, 그 키가 하필 버그를 밟은 것입니다.

버그만 고쳤으면, 테스터가 새 버전을 받아 그 키를 누르고 아무 반응이 없는 것을 보고 "아직 안 고쳐졌다" 고 다시 제보했을 겁니다.

Alt+Shift+←↑↓→ 를 넣었습니다. 그리고 화면에 보이는 대로 움직이게 했습니다 — 트리 구조가 아니라 좌표로 고릅니다. 대각선으로 건너뛰지 않고, 끝에서 반대편으로 돌지 않습니다. 돌면 지금 어디에 있는지 놓치니까요.

제보의 문장이 아니라 의도를 봐야 한다는 게 교훈이었습니다.

테스터가 원인까지 짚어준 건

이건 제보가 진단이었습니다.

탭2개 생성 후 탭2번에서 창 3개 띄우고 exit 입력 하면 기존 탭으로 포커스 이동 하는데, 입력이 되질않습니다
동일 입력에는 창의 개수가 3개인 것으로 보아, 기존 포커스가 남아있는 상태로 추정됨

정확했습니다.

여러 서버에 같은 명령을 보내는 동일 입력 전송이 켜져 있으면, 앱이 키보드를 붙잡고 입력을 대신 배달합니다. 그래야 여러 창에 한 번에 갑니다.

그런데 대상 목록은 켤 때 한 번 채우고 나면 스스로 낡습니다. exit 로 창이 사라지고, 탭을 옮기면 목록은 보이지 않는 탭을 가리킵니다.

키보드는 붙잡고 있는데 배달할 곳은 화면에 없는 상태가 된 것입니다.

그리고 화면에 보이던 "3개" 는 틀린 숫자였습니다. 다른 탭에 남은 창까지 세고 있었습니다. 틀린 숫자가 원인을 짚어준 건 운이 좋았던 거고, 원래는 실제로 가는 곳의 수여야 합니다.

사용자에게 보여주는 숫자는 실제로 일어나는 일이어야 합니다. 여러 서버에 명령이 나가는데 몇 곳인지 모르고 타이핑하게 두면 안 되니까요.

체크박스가 안 보였습니다

제가 올린 제보입니다.

동시 접속 UI는 체크 박스가 화면상에 잘 안보이네

기능은 처음부터 있었습니다. 만든 사람인 제가 못 찾았습니다.

클로드가 이걸 취향 문제로 다루지 않고 계산했습니다.

	대비비
체크박스 테두리 #2B2B2B vs 배경 #1F1F1F	1.16 : 1
비텍스트 요소(테두리·아이콘)의 최소 기준	3.0 : 1
고친 값	6.08 : 1

기준에 2.6배 모자랐습니다. "좀 흐리다" 가 아니라 기준 미달이었습니다.

그리고 대비를 숫자로 검사하는 테스트를 붙였습니다. 어두운 테마를 만드는 사람은 이미 어두운 화면에 눈이 맞춰져 있어서, 눈으로 고르면 또 흐린 값을 고릅니다.

있는 기능을 못 찾는 것은 없는 기능과 같습니다. 이 건에서 코드는 처음부터 옳게 동작하고 있었고, 고칠 것이 동작이 아니라 보이는 정도였습니다.

ssh 에서 exit 를 쳤는데 창이 안 닫혔습니다

음 ssh에 접속 후에 exit를 쳐서 logout 되어는데 창이 안닫히네
비슷한데 되는 것이 있나요: 파워쉘은 다 닫힘

원인은 ssh 가 원격 셸의 종료 상태를 그대로 넘긴다는 것이었습니다.

exit 는 마지막 명령의 상태를 돌려줍니다. 로그를 보다가 grep 이 아무것도 못 찾으면 1 이고, 그 상태로 exit 를 치면 ssh 도 1 로 끝납니다. 우리는 "0 이 아니면 실패" 로 보고 화면을 남겼습니다 — 접속 실패 메시지를 읽을 수 있게 하려던 것인데, 정상 로그아웃까지 실패로 본 것입니다.

제가 여러 서버로 시험해봤습니다.

네이버 클라우드 서버	안 닫힘
회사 서버 · 개인 MySQL · 오라클	닫힘

호스트마다 갈린다는 게 결정적인 단서였습니다. 매번 다른 게 아니라 그 서버에서는 항상 같은 코드가 나온다는 뜻이니까요. 원격의 로그아웃 스크립트에서 도는 명령이 0 이 아닌 코드를 내면 그렇게 됩니다.

여기서 클로드가 규칙을 어떻게 나눴는지가 좋았습니다.

fn propagates_remote_exit_status(&self) -> bool {
    matches!(self, Self::Ssh { .. })
}

처음에 is_remote() 로 지었다가 바꿨습니다. "원격이냐" 는 규칙이 갈리는 이유가 아니고, "종료 상태를 전달하느냐" 가 이유니까요. AWS SSM 은 원격이지만 세션 종료를 성공으로 보고하므로, 거기서 0 이 아닌 코드는 실제로 실패입니다. 같이 바꾸면 그 오류 메시지가 사라집니다.

이름이 이유를 담고 있으면 다음에 SSM 을 여기 넣고 싶어질 때 스스로 막힙니다.

진단이 막혔던 자리

이 건에서 제일 오래 걸린 것은 코드가 아니었습니다. 어느 경우인지 몰랐던 것입니다.

창이 남는 경우가 둘인데 화면에 나오는 문구가 이랬습니다.

• 프로세스가 코드 255 로 종료되었습니다
• 연결이 종료되었습니다

둘 다 "끝났다" 로만 읽힙니다. 그래서 제보를 받고도 저한테 되물어야 알 수 있었습니다.

클로드가 문구를 고쳐서 화면이 스스로 말하게 했습니다.

보이는 줄	뜻
접속에 실패했습니다 (ssh 255)	붙지 못했거나 인증이 막혔다
프로세스가 코드 N 로 종료되었습니다	로컬 셸이 0 아닌 코드로 끝났다
연결이 종료되었습니다 (종료 코드를 읽지 못해 창을 남겼습니다)	제보 대상

그리고 두 문구가 서로 달라야 한다는 것까지 테스트로 못박았습니다.

되물어야 하는 화면은 관측 도구로서 실패한 것입니다. 사용자에게 왕복을 시키는 만큼 진단이 늦어지고, 그 사이 사용자는 그 버그와 함께 삽니다.

---

5. 무너진 것은 프로그램이 아니라 배포 도구였습니다

이게 이번에 제일 뜻밖이었습니다. v0.6.3 을 배포하는 동안 문제가 셋 나왔는데 전부 앱 밖이었습니다. 앱은 그날 한 번도 잘못 동작하지 않았습니다.

값은 있었는데 자리가 없었습니다

릴리스 노트에 MSI 해시를 적어 두는데, 그게 이렇게 나갔습니다.

```nE37C2D26EF1A2B39...

PowerShell 의 큰따옴표 안에서 백틱은 이스케이프 문자입니다. 마크다운 울타리(백틱 3개)를 넣으려면 백틱을 여섯 개 써야 하고, 그 뒤에 줄바꿈까지 붙이면 일곱 개가 됩니다. 사람이 셀 수 있는 문법이 아닙니다.

그런데 더 중요한 건 검증이 있었는데도 통과했다는 것입니다.

Select-String -Path $note -Pattern $hash   # 들어갔는지 확인

이 검사는 통과했습니다. 해시는 분명히 파일 안에 있었으니까요. 깨진 것은 값이 놓인 자리였습니다.

"값이 들어갔는가" 와 "값이 제대로 놓였는가" 는 다른 질문입니다.

오류 메시지가 먼저 깨졌습니다

배포 스크립트를 돌리니 이렇게 나왔습니다.

..\wTerm2-beta ? git ??μ냼媛 ?꾨떃?덈떎. 癒쇱? 諛고룷 ??μ냼瑜??대줎?섏꽭??

원래 문장은 "배포 저장소가 아닙니다. 먼저 클론하세요" 였습니다.

윈도우 PowerShell 5.1 은 BOM 이 없는 .ps1 을 ANSI 코드페이지로 읽습니다. 한글 윈도우면 cp949 라, UTF-8 로 저장한 한글이 통째로 깨집니다. 맥에서는 멀쩡해 보이니 알 수가 없었습니다.

깨진 것이 하필 진단이었습니다. 스크립트는 제 할 일을 정확히 했습니다 — 클론이 없는 것을 잡고 멈췄습니다. 그런데 왜 멈췄는지를 읽을 수가 없었습니다.

오류 메시지는 무언가 잘못됐을 때만 나옵니다. 즉 이 결함은 정의상 가장 곤란한 순간에만 드러납니다.

확인하는 명령이 확인 대상을 바꿨습니다

설치본이 하나만 남았는지 보라고 이 명령을 받았습니다.

Get-CimInstance Win32_Product -Filter "Name='wTerm2'"

한참을 돌았습니다. 제가 물었습니다. "이게 원래 오래 걸리나?"

Win32_Product 는 조회할 때마다 설치된 모든 MSI 제품의 무결성 검사를 돌립니다. 그 과정에서 일부 제품을 자동으로 재구성합니다. 마이크로소프트 자신이 쓰지 말라고 안내하는 클래스입니다.

즉 확인하려던 명령이 시스템을 바꿔놓고 있었습니다. 거기다 그날 그 명령은 몇 분을 돌고 아무것도 못 뽑았습니다. 레지스트리로 보니 멀쩡히 하나 있었습니다. 느리고, 위험하고, 틀리기까지 했습니다.

더 나빴던 건 그 명령이 이미 나간 릴리스 노트에 들어 있었다는 것입니다. 테스터에게 "설치본이 하나만 남았는지 확인하세요" 라고 안내하면서 그런 명령을 준 거죠. 두 저장소의 릴리스 본문까지 다시 올려서 고쳤습니다.

셋의 공통점

클로드가 이 셋을 묶어서 정리한 게 이랬습니다.

첫째, 검증 코드에는 검증이 없습니다. 앱 코드는 테스트가 지키지만, 그 테스트를 돌리는 스크립트와 배포 절차는 아무도 안 지킵니다.

둘째, 전부 맥에서 실행되지 않는 코드입니다. 여기서 검증되지 않는 것이 결과의 정확성만이 아닙니다 — 비용과 부작용도 검증되지 않습니다. 그리고 이쪽이 더 조용합니다. 결과가 틀리면 알아채지만, 느린 것은 누가 물어봐야 드러납니다. 세 번째 건은 제가 "오래 걸리나?" 라고 물어서 발견됐습니다.

대응은 여기서 실행할 수 없어도 텍스트로는 검사할 수 있다는 것이었습니다. 검사 스크립트에 이런 게 들어갔습니다.

• .ps1 에 UTF-8 BOM 이 있는지
• 릴리스 노트의 해시 칸이 울타리째 온전한지
• 한국어판과 영어판의 해시가 같은지
• 문서에 손으로 적은 버전이 Cargo.toml 과 맞는지

마지막 것도 제가 데인 뒤에 생겼습니다. 릴리스마다 같은 숫자를 여러 문서에 적어야 하는데, 손으로 적는 건 반드시 빠집니다.

---

6. 연구노트가 38건이 됐습니다

1편에서 25건이었는데 13건이 늘었습니다. 이번에 늘어난 것들입니다.

#	제목
26	같은 버전을 단 다른 바이너리 세 개
27	테스트가 한 번도 해 보지 않은 동작
28	안내 문구가 저장된 값으로 읽혔다
30	검사기가 자기 자신을 읽었다
31	만든 사람도 못 찾은 기능
32	값은 있었다, 자리가 없었을 뿐
33	PowerShell 은 바이트를 텍스트로 본다
34	확인하는 명령이 대상을 바꿔 놓았다
35	관례에서 한 바이트 어긋나 있었다
36	버그를 고치면 그 키는 아무 일도 하지 않게 됐다
37	키보드는 붙잡고 배달은 하지 않았다
38	0 이 아닌 것은 실패가 아니다

그리고 기술노트라는 것도 생겼습니다. 연구노트가 "무엇이 잘못됐나" 라면 기술노트는 "어떻게 만들기로 했나" 입니다. 지금 7건인데, 이번에 둘이 늘었습니다.

• 여기서 저기 것을 쓴다 — 맥에서 만드는 윈도우 자동화
• 제보를 진단으로 바꾸기 — 재현할 수 없는 버그를 남의 화면에서 고치기

같은 실수를 세 번 했습니다

기록을 남기니까 이런 것도 보입니다. 테스트가 아무것도 지키지 않는 실수를 세 번 했습니다.

1편에 나온 22번(도움말 검사)이 첫 번째였고, 체크박스 대비 테스트가 두 번째, Ctrl+Tab 포커스 테스트가 세 번째였습니다.

세 번 다 같은 모양입니다. 테스트가 실제 코드 경로를 밟지 않고, 상수나 안쪽 함수만 검사했습니다. 되돌려보면 통과합니다.

세 번째에서는 대응이 달라졌습니다. 판단을 테스트가 부를 수 있는 자리로 옮겼습니다.

fn select_tab_in<P>(tree: &mut Tree<P>, index: usize, focus: &mut Option<TileId>)

메서드 안에 두면 테스트가 못 부르고, 그러면 안쪽 계산만 검사하게 됩니다. 이제는 "테스트가 부를 수 없는 자리에 판단이 있으면 뺀다" 를 규칙으로 봅니다.

그리고 하나 더 — 동일 입력 건에서는 테스트가 아니라 구조로 막았습니다. 키보드를 붙잡을지 정하는 값과 실제로 배달하는 목록이 같은 변수입니다. 두 곳에서 각각 계산하지 않으면 어긋날 수가 없습니다.

---

클로드와 이슈로 대화해보니

이슈를 직접 읽고 답하게 한 것

이게 이번 베타 테스트의 방식입니다. 제가 중간에서 요약해 전달하지 않습니다.

테스터: 이슈 등록 (스크린샷 + "비슷한데 되는 것")
클로드: 이슈 읽기 → 원인 분석 → 코드 수정 → 이슈에 댓글로 설명
    나: git pull → 빌드 → 실기 확인 → 닫기

좋았던 점은 테스터의 표현이 그대로 클로드에게 간다는 것입니다. 제가 요약하면 "백스페이스가 이상해요" 가 되는데, 원문에는 "ssh로 연결한 리눅스에서는 정상적으로 하나씩 지워집니다" 가 붙어 있었습니다. 그 한 줄이 원인이었습니다.

그리고 클로드가 댓글에 왜 그랬는지를 적습니다. 표와 숫자를 넣어서요. 테스터가 "아 그래서 그랬구나" 하고 다음 제보를 더 잘 써주게 됩니다.

모른다고 말하는 것

이번에 특히 그랬습니다. ssh 건에서 클로드가 이렇게 적었습니다.

가정이 하나 있습니다 — 그때 종료 코드가 0 이 아니었다는 것. 창이 남았을 때 아래쪽에 "프로세스가 코드 N 로" 가 보였다면 위 설명이 맞습니다. 대신 "연결이 종료되었습니다" 가 보였다면 원인이 다릅니다.

그리고 릴리스 노트의 "검증 범위" 에 이렇게 갈라 적었습니다.

백스페이스는 맥에서 실제 pty 를 띄워 확인했습니다. ConPTY 쪽은 여기서 돌려 볼 수 없어 실기 확인이 필요합니다.

전부 확인한 것처럼 쓰지 않는 게 좋았습니다. 제가 무엇을 믿어도 되는지 알 수 있으니까요.

요청 범위를 넘지 않는 것

Ctrl+Tab 건에서 클로드가 페인 이동 단축키를 새로 넣었는데, 그때 이렇게 말했습니다. "이걸 안 넣으면 버그만 고친 뒤에 그 키가 아무 반응도 안 하는 상태가 되어 다시 제보가 옵니다."

반대로 탭마다 마지막 창을 기억하는 기능은 넣지 않았습니다. 자기가 잘못 쓴 테스트로 그걸 발견하고는, 없는 기능을 단언한 테스트를 고치고 "알려진 제약" 에 적었습니다.

있으면 좋겠다고 생각한 것을 테스트에 적으면 그건 테스트가 아니라 희망입니다.

---

지금 상태와 다음

v0.6.4 까지 나왔고, 베타 이슈 7건이 전부 닫혔습니다.

이번 사흘에 들어간 것들입니다.

• 화면과 문서 전체가 영어로도 나옵니다 (F1 → 왼쪽 아래에서 전환)
• 나뉜 창 사이를 Alt+Shift+←↑↓→ 로 이동
• 백스페이스가 관례대로 (Ctrl+Backspace 로 단어 지우기)
• ssh 세션이 끝나면 창이 닫힘
• 동일 입력 전송이 낡지 않음
• 접속 목록 체크박스가 보임
• 창 제목에 버전 표시

남은 것은 1편과 같습니다. 화면 정리 — 상단 크롬이 아직 세 겹이라 터미널이 좁아 보입니다. 그리고 맥용 .app/.dmg 패키징이 남아 있습니다.

베타 테스터는 아직 두 분입니다. 개발 도구라서 그렇습니다. 그래도 두 분이 올려주신 제보로 나흘 만에 릴리스 넷이 나왔습니다. 사람 수보다 제보의 질이 중요하다는 걸 이번에 알았습니다.

혹시 윈도우에서 서버 여러 대를 다루시는 분이 계시면, 베타 테스트에 참여해주시면 감사하겠습니다. 깃허브 아이디만 알려주시면 됩니다.

베트 테스트 신청서.

https://forms.gle/fBsnUeJ8sxSFmcJ87

읽어주셔서 감사합니다.

---

이 글에 나온 숫자와 인용은 전부 실제 저장소의 커밋·이슈·연구노트에서 가져온 것입니다.
테스터 제보는 원문 그대로이고, 서버 주소와 계정은 가렸습니다.