글자 크기와 색상 기능이 생각보다 어려웠던 이유
코딩은 AI에게 맡겼습니다 · 시즌 1 / 10
리치 텍스트 편집기 도입 일주일 뒤에는 글자 크기와 색상 조절 기능을 추가했습니다. 네 개 파일에서 254줄을 추가하고 67줄을 삭제했습니다. 버튼 두 개가 늘어난 것처럼 보이지만 편집 상태와 화면 상태를 함께 다뤄야 했습니다.
먼저 보는 핵심
편집 기능은 버튼을 화면에 놓는 것으로 끝나지 않습니다. 선택 영역과 현재 서식이 저장된 HTML에 반영되고, 테마를 바꾸거나 키보드로 조작해도 사용 흐름이 이어져야 합니다. UI를 만들기 전에 사용자 행동에 따라 편집기와 화면이 어떻게 바뀌는지 정리하는 것이 도움이 됩니다.
사용자가 보는 버튼과 내부 상태
사용자는 글자를 선택하고 크기나 색상을 누릅니다. 내부에서는 다음과 같은 경우를 구분해야 합니다.
- 선택 영역이 있는가, 커서만 있는가
- 선택한 여러 글자에 서로 다른 서식이 있는가
- 새로 입력할 글자에만 서식을 적용할 것인가
- 편집기를 다시 열었을 때 툴바가 현재 위치의 서식을 표시하는가
- 다크 테마에서 선택한 색상이 읽히는가
AI는 편집기 API를 호출하는 코드를 빠르게 만들었습니다. 선택한 글자의 서식을 툴바에 어떻게 표시하고, 새로 입력할 글자에는 어떤 서식을 적용할지는 따로 정해야 했습니다.
색상 선택이 만드는 접근성 문제
색상 팔레트를 많이 제공하면 자유도가 높아 보입니다. 그러나 밝은 배경과 어두운 배경에서 모두 읽히는 색은 제한적입니다. 사용자가 직접 지정한 색이 테마 전환 뒤 보이지 않을 수도 있습니다.
확인 항목은 다음과 같습니다.
| 항목 | 질문 |
|---|---|
| 대비 | 밝은·어두운 테마에서 읽을 수 있는가 |
| 표시 | 선택한 색상을 색상 이름이나 코드로도 확인할 수 있는가 |
| 키보드 | 마우스 없이 팔레트를 열고 선택할 수 있는가 |
| 초기화 | 기본 색상으로 쉽게 돌아갈 수 있는가 |
| 내보내기 | 지정 색상이 HTML 파일에 보존되는가 |
기능을 추가할 때마다 테스트 조합이 늘어납니다. 테마 3개와 글자색 8개만 있어도 24가지 조합이 됩니다.
AI에게 상태표를 먼저 요청했다
UI 코드를 바로 만들기 전에 다음 형태의 표를 작성하게 하면 누락을 줄일 수 있습니다.
사용자 행동 / 편집기 상태 / 저장 데이터 변화 / 화면 피드백 / 실패 시 동작
예를 들어 글자를 선택하지 않고 크기를 바꿨을 때, 이후 입력할 글자에 적용할지 아니면 선택을 먼저 안내할지 정해야 합니다. 이런 사용 흐름은 API 사용법만으로 결정되지 않습니다.
작은 기능을 작게 유지하는 방법
첫 버전에서는 모든 워드프로세서 기능을 따라 하지 않았습니다. 자주 쓰는 크기와 색상만 제한해 제공하고, 복잡한 글꼴 관리와 문단 스타일은 제외했습니다.
AI로 기능을 추가하기 쉬워질수록 이번 버전에 넣을 범위를 정하는 기준이 필요합니다. 버튼을 하나 추가하면 저장·복원·테마·내보내기 과정에서도 그 기능을 처리하고 계속 테스트해야 합니다.
다음 편
텍스트 서식을 지원하자 이미지도 붙여넣고 싶어졌습니다. 다음 편에서는 이미지 하나 때문에 내보내기 형식을 텍스트에서 HTML로 바꾼 과정을 이야기합니다.
댓글
댓글 쓰기