[5월 TIL #17] 폰으로만 코딩③: 느슨해진 업무에도 긴장감이 필요하다

1. 발단: 짧은 시간과 적은 리소스가 만든 제약

폰으로만 코딩 시리즈를 올리고 있다. 첫 번째와 두 번째 글은 작업 내용 자체에 대한 것이었다. 이번 세 번째 글은 작업 자체보다 그 과정에서 얻은 깨달음을 실제 업무에 적용해본 이야기가 중심이다.
 
폰으로만 코딩이라는 제약은 처음에는 불편함에 가까웠다. 화면이 작고, 한 번에 여러 창을 열어두기 어렵고, 위로 스크롤해서 이전 대화를 다시 찾기도 번거롭다. 퇴근 후 짧은 시간 안에 적은 리소스로 결과를 만들어야 했다. 그런데 이 제약이 “문서화”를 통해 작업 효율을 높이는 방향으로 자연스럽게 이끌었다.
 
그리고 그 과정을 돌아보다 보니 한 가지 질문이 생겼다.

업무에서는 왜 이렇게 안 했지?

 
업무는 시간이 더 길고, 환경이 익숙하다. 그래서 작업 방식 자체를 충분히 고찰하지 않은 채 익숙한 흐름으로 진행하는 경우가 많다. 폰으로만 코딩의 제약이 강제로 만들어낸 그 방식을, 제약이 없는 업무에도 가져갈 수 있을 것 같았다. 지금 진행 중인 복잡하고 규모 있는 업무에도 이 방식의 회고를 적용해보려 한다. 이번 글은 그 적용기에 가깝다.
 

2. 전개: 제약이 효율성을 높이다

이번 폰 코딩에서는 단백질 정보를 시각화해주는 작은 도구를 만들었다. 작업을 시작하기 전에 GitHub Issue에 셋업 가이드부터 만들었다.

셋업 가이드를 만들고 작업 효율성이 매우 높아짐을 체감했다.

• 필요한 외부 서비스 목록 (Gemini, Neon)
• 각 서비스의 무료 여부, 카드 등록 필요 여부, 모바일 가입 가능 여부를 표로
• 가입 순서와 환경 변수 입력 위치
• "안 되면" 항목 — 막혔을 때 어디를 보고 무엇을 시도할지

폰이라는 작은 화면에서 빠르게 작업을 끝내겠다는 제약 덕분에 더 효율적인 방법을 찾게 됐고, 그 방법이었던 가이드 문서 하나가 큰 변화를 만들었다. 가이드 덕분에 "이 키는 어디서 만들지?", "이 서비스가 무료가 맞나?", "DB를 직접 만들어야 하나?" 같은 질문으로 작업 맥락이 끊기지 않을 수 있었다. 작은 화면에서는 컨텍스트를 잃는 비용이 큰데, 가이드 한 장이 그 비용을 줄여준 것이었다. 보통 문서화는 끝나고 정리하는 일에 가깝게 느껴지는데 이번에는 그게 작업을 빠르게 하기 위해 먼저 해두는 일에 가까웠다. 
 

3. 위기: 반면, 업무에서는 효율성에 대한 고민이 느슨했다

이렇게 가이드를 만들어 효율성을 높이는 경험을 하고 내가 업무에서는 왜 이런 효율을 높이기 위한 방식을 고민하지 않고 있는가에 대해 되돌아보게 되었다. 폰으로만 코딩에서는 '폰으로만', '짧은 시간' 등의 제약을 걸어두면서, 되려 업무에서 더 제약이 없어 느슨하게 작업을 했다는 반성을 하게 되었다.

제약이 없으니 느슨해졌고, 때문에 괴로운 건 나였다.

 
최근 업무에서 꽤나 규모 있는 작업을 하고 있는데, 작업의 중반으로 갈 수록 화면에서 바로 보이는 문제를 하나씩 고치는 방식이 되었다. 그런데 규모가 크다보니 UX에서 복잡도가 커지고 의사결정을 해야할 부분들과, 동시에 내가 직접 테스트를 해보며 발견되는 문제도 많아졌다. 이 수동적인 방식에 한계가 있다는 것을 느끼는 지점이 온 것이다.
 

4. 절정: '폰으로만 코딩'에서 배운 방식을 가져왔다

늦었지만 이걸 느낀 시점에 '폰으로만 코딩'에서 느꼈던 교훈을 떠올리고 문서 하나를 만들었다. docs/right-sidebar-custom-mode.md에 제품 의도, 용어, 핵심 원칙, 패널 추가 규칙, 이동과 위계, 데이터 추적, 미결정 사항을 한 문서에 정리했다. 특히 다음 기준이 이후 판단을 덜 흔들리게 만들었다.

• 기본 모드는 훼손하지 않는다
• 커스텀 모드는 표시 방식만 다르고 로직은 동기화된다
• 드롭 피드백은 실제 결과와 1:1로 대응해야 한다
• 추적은 마지막 모드와 조합을 보는 데 집중한다

이 문서화 덕분에 기준이 생겼다. 예를 들어 이벤트 추적도 같은 경우에도 처음에는 모드 변경, 패널 추가, 기능 선택, 추천 조합, 이동, 닫기까지 이벤트가 늘어날 뻔했는데, 모드 전환 경험·모드 선호·커스텀 모드의 마지막 조합을 보는 단일 스냅샷 이벤트 중심으로 정리했다. 이후 작업 흐름이 달라졌다. PR을 만들고 CodeRabbit 리뷰를 반영할 때도, 번역 키와 용어 일관성, 타입 안정성, 누락 방어를 정리할 때도 문서가 기준점이 됐다.
 

5. 결말: 그러나, 업무에서는 한 층이 더 필요했다

문서를 만든 이후 의사결정은 빨라졌다. 다만 문서가 모든 부분의 리소스를 덜어주진 못했다. 이번 작업의 상당 부분이 정책보다 감각의 문제였기 때문이다. 카드 너비, 중앙 정렬, 여백, 아이콘 제거, 제목 중복 제거 같은 것은 문서에 원칙이 있어도 화면을 보면서 조정해야 하는 영역이 많았기 때문이다. 폰 코딩에서는 한 층의 가이드로 충분했다. 작업 규모가 작고 외부 서비스 셋업이 거의 전부였기 때문이다. 업무처럼 시각적 디테일이 많고 사용자 인터랙션이 복잡한 작업에서는 한 층이 더 필요했다. 그래서 다음 번에는 어떻게하면 이 '계약'의 측면이 아닌 '감각'의 측면까지 문서화를 통해 내 리소스를 아낄 수 있을지 고민이 필요하고 시도해 볼 것이다.
 
1) 제품 계약서: 이 기능이 무엇이고 무엇을 절대 깨면 안 되는지를 고정하는 문서. 이번에 만든 right-sidebar-custom-mode.md가 여기에 해당한다.
 
2) UX/UI 기준선: 이쪽이 더 어렵다. 제품 계약서는 "무엇을 깨면 안 되는가" 라서 명확히 적을 수 있지만, UX/UI는 "어떻게 동작하고 어떻게 보여야 하는가" 에 가까워서 결정의 폭이 넓다. 드롭 피드백·빈 상태 같은 인터랙션을 체크리스트로 잘게 쪼개는 게 맞는지, 여백·정렬 같은 시각 디테일까지 묶을 큰 원칙을 세우는 게 맞는지, 둘을 함께 두고 균형을 잡는 게 맞는지 — 이 자체를 시행착오로 알아내야 할 것 같다.

문서화 해야할 하나의 Layer를 더 깨닫게 되었다.

 
폰으로만 코딩이 알려준 건 "작업 전에 기본을 문서화한다" 였다. 업무에 옮겨보니 그 원칙은 그대로 통했지만, 업무의 복잡도가 큰 만큼 문서 자체도 두 층으로 나뉘어야 했다. 폰 코딩에서 배운 한 줄을 그대로 가져온 게 아니라, 업무 맥락에 맞게 한 번 더 확장한 셈이다. 다음 작업에서는 시작할 때부터 두 층을 같이 만들어보려 한다. 그리고 폰 코딩 시리즈를 계속하면서, 제약이 만들어준 다른 깨달음들도 같은 방식으로 업무에 옮겨볼 생각이다.