만든 것

tate-align — 전각 대응·세로 정렬 포맷팅 도구

붙여넣은 텍스트의 열을, 전각=2·반각=1의 표시 너비를 올바르게 계산하여 세로로 맞추는 Web 도구입니다. 브라우저 내에서 완결되며, 입력값은 서버로 일절 전송하지 않습니다. 프레임워크도 외부 라이브러리도 사용하지 않는, 순수 HTML/CSS/JS로만 구성된 정적 1페이지입니다.

# 이것이
int a = 0; // 속도
int speed = 10; // 가속도 설정
...

주석 맞춤뿐만 아니라, /* */ 블록 주석의 닫는 기호까지 포함하여 전부 맞추는 「맞춤형」도 선택할 수 있습니다 (이는 후술할 v1.2에서 추가한 것입니다):

int a = 0; /* 속도 */
int speed = 10; /* 가속도 설정 */
long t = 3; /* 시간 */

리포지토리는 여기입니다: https://github.com/atoraku/tate-align

왜 만들었는가 — 「맞춰라」 문화와, SQL로 임계점을 넘긴 맞춤 작업

저는 원래 임베디드 계열 엔지니어로, 직장에는 예전부터 "주석의 세로를 맞춰라", "선언의 세로를 맞춰라"라는 문화가 있었습니다. 소스 코드의 주석란, 변수 선언, 구조체, 상수표, 배열 초기화, 사양서, 메일——어쨌든 맞춰져 있지 않으면 지적이 들어옵니다. 그래도 임베디드 시절에는 맞출 대상이 아직 인력으로 어떻게든 가능한 양이었습니다.

그 후, 고객 관리계 시스템 개발로 옮기면서 맞춤 작업이 임계점을 넘었습니다. SQL이나 헤더 정의가 들어오면, 맞춰야 할 행수가 차원이 달라집니다. 200행을 넘는 구조체나 SQL을 전부 세로로 맞춘다. 아니, 이걸 손으로 하는 건 이상하잖아, 라고 생각했습니다.

처음에는 Office 스크립트로 만들었다 (그리고 좌절했다)

사실 처음부터 Web 도구였던 것은 아니고, Office 스크립트(Excel)로 만들어서 실제로 사용하고 있었습니다. 그런데 직장 PC의 사양 부족인지 Excel의 버그인지, Office 스크립트가 실행되지 않거나 애초에 열리지 않는 사태가 빈번하게 발생했습니다. PC를 재부팅하면 고쳐지긴 하지만, 재부팅한다는 것은 열려 있는 사양서나 창들을 전부 닫는다는 뜻입니다. 맞추고 싶을 뿐인데 매번 그러면 본말전도입니다.

그럼 Excel 이외의 것으로 다시 만든다면 무엇이 가장 사용하기 편할까. 정적인 브라우저 페이지이면서, 서버에 아무것도 전송하지 않는다면, 입력 데이터가 외부로 나가지 않으므로 직장에서도 사용할 수 있습니다 (저희 회사는 파일 다운로드 자체가 허가제이므로, "브라우저에 붙여넣고, 맞춰진 결과를 복사하기만 하면" 끝나는 방식이 필수 요건이었습니다). 이것이다 싶어 다시 만든 것이 본 도구입니다.

그리고 전각 문제

또 다른 동기는 전각입니다. 세상의 포맷팅 도구나 에디터 플러그인은, 전각 문자가 섞이는 순간 파탄 나는 경우가 많습니다. 전각 문자는 등폭 폰트에서 반각 2글자만큼의 너비를 차지하는데, 단순히 "글자 수"로 계산하는 도구라면 일본어 주석 행만 어긋나게 됩니다.

• 「速度(속도)」 = 2글자지만 표시 너비는 4
• ①
• ※
• ±

와 같은 기호(Unicode의 East Asian Width에서 "Ambiguous"로 분류되는 문자)도 일본어 폰트에서는 너비가 2입니다.

이 너비 계산을 제대로 수행하는 것이 이 도구의 핵심입니다.

개발 진행 방식 — 사양서 주도 + AI 에이전트 3단 체제

이번에는 코드를 한 줄도 스스로 쓰지 않았습니다. 전부 AI 에이전트(Claude Code)입니다. 다만 "AI에게 통째로 맡기기"가 아니라, 다음과 같은 체제를 처음에 정했습니다.

• 설계: 상위 모델(Fable 5) — 사양이 모호한 부분을 없애고 구현 설계서를 작성함
• 구현: Opus의 서브 에이전트 — 설계서에 따라 코드와 테스트를 작성함
• 최종 확인: 다시 상위 모델(Fable 5) — 코드 리뷰 + 브라우저에서의 실기 확인

상위 모델로 품질을 담보하면서, 손이 많이 가는 구현은 서브 에이전트에게 위임하는 분담 방식입니다. 인간(나)의 업무는 사양서를 쓰는 것과 요점에서의 승인뿐입니다.

유일한 정답으로서의 SPEC.md

착수 전에 SPEC.md라는 사양서를 준비했습니다. 포인트는 사양서의 서두에 에이전트용 지시 사항을 적었다는 점입니다.

• 이 사양서가 유일한 정답(Single Source of Truth). 착수 전에 구현 계획을 제시하고, 승인을 얻은 뒤에 작성할 것
• 프레임워크, 빌드 도구, 외부 라이브러리 사용 금지 (순수 HTML/CSS/JS만 사용)
• 사양에서 벗어나고 싶다면, 구현하지 말고 이유를 덧붙여 제안할 것
• 테스트가 모두 초록색(Pass)이 될 때까지 완성된 것으로 간주하지 않음

그리고 사양서에는 입출력 예시를 7개(예: A~G), 기대 출력의 1글자 단위까지 작성했습니다. "코드 모드에서 주석을 맞추면 이렇게 된다", "탭 구분 표는 이렇게 된다", "= 맞춤은 이렇게 된다"…… 하는 식입니다. 이것이 나중에 큰 효과를 발휘합니다 (효과가 너무 커서, 사양서 자체의 버그까지 찾아내게 됩니다).

페이즈 1: 설계 — 사양의 모호함을 먼저 제거하기

いきなり 구현 에이전트에게 사양서를 넘기는 것이 아니라, 먼저 상위 모델에게 사양서를 읽히고, 모호한 부분을 설계 판단으로서 확정한 PLAN.md를 작성하게 했습니다. 예를 들어:

• 너비 2로 취급할 Unicode 범위의 구체적인 테이블 (CJK, 카나, 한글, 전각 문자에 더해 ①, ※, →, ■ 등 모호한(Ambiguous) 주요 범위)
• 인용부호의 '간이 스캔(Simple Scan)'에 대한 엄격한 정의 (', `

이 도구는 공개하고 끝내는 것이 아니라, 제가 매일 사용하는 도구로서, 사용하면서 계속해서 개선해 나갈 생각입니다. 실제로 공개 이후 지금까지의 흐름이 그대로 「사용한다 → 걸림돌이 생긴다 → 고친다」의 반복이었습니다 (v1.1과 v1.2도 그렇게 탄생했습니다). 현재 고려 중인 후보는 다음과 같습니다:

• 숫자 열의 우측 정렬
• Markdown 표(Table) 정렬
• 직장에서 전파하며 수집한 구분란·정렬형 프리셋(Preset) 요청

그리고, 이 글을 읽고 사용해 주신 분들께. 「이런 입력은 제대로 정렬되지 않는데」라는 부분이 있다면, 꼭 이 글의 댓글로 알려주세요. 붙여넣은 입력값과 「이렇게 되었으면 좋겠다」는 형태를 적어주시면, 재현하여 수정하겠습니다. 이 글에서 기술한 바와 같이, 보고 내용의 재현 → 원인 분류 → 테스트 추가 → 수정본 공개까지의 체제는 이미 갖춰져 있으므로, 수정은 매우 빠를 것입니다.

여기까지 읽어주셔서 감사합니다. 고정 폭 글꼴(Monospace font) 문화권에서 "정렬하라"는 요구를 받고 계신 여러분, 꼭 한번 사용해 보세요.

Discussion