김솔비 블로그
기술 블로그

[Part 4] 회고편: '안 된다'고 했다가 두 번 틀렸다

5분 읽기시리즈 5/5

결론부터

  • 대부분의 결정은 "쉬운 길이 있는데 안 간" 결정이었다. 그 쉬운 길은 대체로 만들기는 쉽고 쓰기는 나쁜 쪽이었다.
  • 통과만 하는 검사는 고장을 못 잡아도 통과한다. 그래서 검사를 쓰면 일부러 고장을 넣어 본다.
  • 가장 크게 틀린 건 기능 단위로 확인하고 제품 단위로 보지 않은 것이다.

고른 것과 버린 것

고른 것버린 것이유
양식을 제품으로편집기를 제품으로노션, 구글 독스와 경쟁하면 진다
HWPX 직접 조립DOCX만 지원한국에서 결재는 한글로 올라간다. 라이브러리가 없다는 건 이유가 안 된다
PDF를 글자(벡터)로 조립지면을 사진으로 찍어 넣기사진은 만들기 쉽고 미리보기와 똑같지만, 복사와 검색이 안 되면 문서가 아니다
지면 값 단일 출처형식마다 따로 최적화미리보기가 거짓말하면 없느니만 못하다. 형식별 미세 조정은 그 대가로 포기했다
문서를 jsonb 한 칸에 통째로표로 정규화양식이 자주 바뀐다. 쪼개면 양식을 고칠 때마다 DB를 고쳐야 한다
휴지통 표시를 JSON 안에컬럼 추가와 마이그레이션두 저장소가 규칙 하나를 따른다. 서버 표를 고칠 필요가 없었다
비회원이 먼저 쓸 수 있게로그인 강제처음 온 사람이 가입부터 해야 하면 문서 하나 안 만들어 보고 나간다
가입을 닫고 초대제로공개 가입품질과 비용을 통제하려고. 화면에서 숨기는 걸로는 부족해서 서버에서도 막았다
비공개 저장소오픈소스서비스는 열되 코드는 열지 않는다. 양식 문안이 이 제품의 자산이다
구매한 템플릿 문안 제외그대로 싣기개인 활용 범위를 넘는다. 항목 구성만 참고하고 문안은 새로 썼다

일하는 방식

검사에 일부러 고장을 넣는다

검사를 쓰면 반드시 코드에 고장을 넣어 보고, 그 검사가 고장을 잡는지 확인한다. 통과만 하는 검사는 고장을 못 잡아도 통과한다.

이 습관으로 검사 자체의 허점을 여럿 찾았다.

  • HWPX 글자 모양 검사가 기대값을 검사 대상 함수로 만들고 있었다. 그 함수가 망가지면 기대값과 결과가 같이 틀려서 검사가 통과한다. 선언된 XML을 직접 펴서 보도록 고쳤다.
  • "자(ruler)를 지면에 달았는지" 검사는 개수만 셌다. 값이 {에서 끊겨도 개수는 맞으니 통과했다. 값을 읽어서 파싱하도록 고쳤다.
  • "두 번 지워도 지운 시각은 그대로" 검사는 가끔만 실패를 잡았다. 두 번의 호출이 같은 밀리초 안에 들어오면 코드가 틀려도 시각이 같아 보였다. 검사에서 시계를 앞으로 넘기도록 고쳤다.
  • 절을 지우면 값도 "비워짐"으로 뜰 거라고 단정하고 검사를 썼다. 실제 코드는 값을 지우지 않았다. 이건 내 단정이 틀렸고 코드가 맞았다.

브라우저에서 직접 눌러 본다

Node에서 도는 검사를 통과하고도 브라우저에서 죽은 것들이 있었다.

  • Packer.toBuffer: Node의 Buffer에 의존해서 브라우저에서만 멈췄다.
  • pdfmake: 조판하면서 넘겨준 객체를 고쳐서, 여러 곳에서 공유한 값이 첫 자리에만 남았다.
  • 포인터 캡처: 서식 단추가 눌리지 않았다.

특히 세 번째는 타입 검사도 단위 검사도 원리상 잡을 수 없는 종류다.

그 뒤로 검사 방식을 바꿨다. 정의만 검사하지 않고, 실제로 그려진 결과에서 글자를 뽑아 센다. PDF 검사는 실제로 만든 파일에서 텍스트를 추출해서 확인한다.

커밋 메시지에 '왜'를 적는다

무엇을 바꿨는지는 diff가 말해 준다. 커밋 메시지에는 왜 그렇게 했는지를 한국어로 적는다. 실제로 남긴 커밋 하나를 옮긴다.

문서 하나는 파일 하나 — 이어 붙이지 않는다

여러 건을 PDF로 내보낼 때 한 파일로 이어 붙이고 있었다. 인쇄 창을 한 번만 띄우려고 그렇게 했는데, 그러면 문서가 문서로 남지 않는다. 받는 쪽은 문서 세 건이 아니라 한 덩어리를 받는다.

여섯 달 뒤 이 코드를 열 사람은 나다. 그때 필요한 건 무엇을 바꿨는지가 아니라 왜 이렇게 돼 있는지다.

틀렸던 것

"안 됩니다"라고 답했다가 두 번 틀렸다

  • "PDF는 zip으로 못 묶습니다." 브라우저가 PDF 파일을 코드에 넘겨주지 않는 건 맞다. 하지만 PDF를 우리가 직접 만들면 된다. Word와 한글은 이미 그렇게 하고 있었다.
  • "목차 점선은 못 넣습니다." 쪽 번호를 포기해야 한다고 봤다. 한 번 조판해서 쪽을 재고 다시 그리면 둘 다 된다.

두 번 모두 "도구가 안 해 준다"를 "할 수 없다"로 바꿔 읽었다. 도구가 안 해 주는 것과 불가능한 것은 다르다.

기능 단위로 확인하고, 제품 단위로 보지 않았다

본문 서식 기능을 만들고, 네 가지 형식에 모두 실리는 것까지 확인했다. 검사도 통과했다. 그런데 이런 피드백이 왔다.

글씨 사이즈 변경 색상 변경 기타 등등 이런거 뭐 하나도 안되는데?

세어 보니 양식 전체 287칸 중 서식이 되는 칸은 28칸이었다. 나머지는 표가 152칸, 한 줄 칸이 82칸이었다. 실제 기획 문서는 대부분 표다.

나는 서식 본문(rich) 28칸에서 굵게가 먹는 걸 확인하고 다 됐다고 생각했다. 쓰는 사람은 표에 커서를 놓고 굵게를 눌러 보고 안 된다고 했다. 둘 다 맞다. "기능이 동작한다"와 "제품이 동작한다"는 다르다.

고친 방향은 단순하다. 글자가 들어가는 자리라면 본문이든 표 칸이든 목록 항목이든 전부 같은 편집기를 쓴다. 쓰는 사람이 서식이 되는 칸을 외워야 할 이유가 없다.

목록 화면을 네 번 바꾸고 되돌렸다

문서 목록 화면을 하루 동안 이렇게 바꿨다.

유형별 묶음 → 아코디언 → 표 하나 안에서 펼치기 → 카드 목록 → 최신순 단일 목록 → 다시 표 하나 안에서 펼치기

커밋 로그에 그대로 남아 있다. 네 번을 만들어 보고서야 두 번째 안이 맞았다는 걸 알았다. 다만 이건 종이에 그려 보고 고를 수 있었던 일이기도 하다.

README가 계속 낡았다

계정 저장과 공유가 들어왔는데도 README에는 "문서는 브라우저에 저장된다, 팀 공유 서버가 붙으면…"이라고 적혀 있었다. 양식 수(28종), 분류 수(7개), 견본 수(23종), 글꼴 이름까지 전부 옛 값이었다.

한 번에 몰아서 고치면서 수치를 코드에서 직접 세어 맞췄다. 문서에 숫자를 적을 거라면, 그 숫자를 어디서 세는지도 같이 적어 둬야 한다.

마치며

만든 것보다 안 만든 것과 되돌린 것에서 더 많이 배웠다.

  • 분류는 내 폴더가 아니라 남이 찾는 길이다.
  • 미리보기는 거짓말하면 안 된다.
  • 도구가 안 해 주는 것과 불가능한 것은 다르다.
  • 기능이 동작하는 것과 제품이 동작하는 것은 다르다.

문서고는 munseogo.solfany.com에서 쓸 수 있다.