비개발자의 AI 개발 도전기 3: 처음 보는 사람도 쓰기 쉬운 화면 만들기

AI로 첫 앱 만들기 · 3화

할 일 추가도 되고, 완료 표시도 되고, 새로고침 후 목록도 남습니다. 그런데 처음 보는 사람에게 보여 주면 이런 질문이 나올 수 있습니다. “어디에 입력해요?”, “체크한 건 끝났다는 뜻인가요?”, “목록이 없는데 오류인가요?”

이번 도전은 설명하지 않아도 다음 행동을 알 수 있는 화면을 만드는 것입니다. 개발자가 쓰는 디자인 도구를 새로 배울 필요는 없습니다. 불편한 장면을 찾고, 원하는 변화를 구체적인 문장으로 AI에게 요청한 뒤, 기존 기능까지 다시 확인하겠습니다.

오늘의 목표
읽기 쉬운 글자와 버튼 → 처음 상태 안내 → 좁은 화면 확인 → 기존 기능 재확인
준비물: 2편의 저장 기능을 추가한 index.html과 AI 대화
완료 기준: 처음 보는 사람이 입력·완료·삭제를 찾을 수 있고, 저장 동작도 그대로 유지되는 화면

2편에서 브라우저 저장 제한을 만났다면 1편의 앱으로 화면 개선만 연습해도 됩니다. 이 경우 저장이 된다고 안내 문구를 바꾸면 안 됩니다. 현재 실제로 되는 기능을 기준으로 설명과 확인표를 맞추세요.

1. ‘예쁘게’ 대신 불편한 순간을 적습니다

“세련되고 예쁘게 만들어 줘”라고 요청하면 AI는 색상, 그림자, 배경부터 바꿀 수 있습니다. 내가 원한 것이 작은 버튼을 누르기 쉽게 만드는 일이었다면 결과가 빗나갑니다. 먼저 내 화면을 보며 세 가지를 적어 보세요.

• 읽기: 글자가 작거나 옅어서 할 일 내용을 읽기 어려운가?
• 행동: 어느 버튼이 추가이고 어느 버튼이 삭제인지 한눈에 구별되는가?
• 상태: 항목이 없을 때, 완료했을 때, 저장에 실패했을 때 상황을 알 수 있는가?

막연한 요청	확인할 수 있는 요청
버튼을 예쁘게 해 줘	추가·완료·삭제를 글자로 표시하고, 버튼을 충분히 크게 띄워 배치해 줘
깔끔하게 해 줘	제목, 입력 영역, 목록 순서로 정리하고 각 영역 사이에 간격을 줘
모바일처럼 해 줘	좁은 창에서 입력칸과 버튼이 겹치지 않고 긴 문장이 줄바꿈되게 해 줘

한 번에 바꿀 항목은 세 묶음으로 제한하겠습니다. 글자와 버튼, 상태 안내, 좁은 화면 대응입니다. 달력이나 알림 같은 새 기능은 이번 요청에 섞지 않습니다.

2. 화면의 순서를 먼저 정합니다

화면을 위에서 아래로 읽을 때 다음 순서가 보이면 좋겠습니다. 아래는 실제 앱 화면을 촬영한 것이 아니라, AI에게 전달할 배치 예시입니다.

오늘의 할 일
작은 일 하나부터 적어 보세요.

할 일 입력
[예: 책 5쪽 읽기                 ] [추가]

전체 2개 · 완료 1개 · 남은 일 1개

[완료됨 / 완료 취소] 물 한 잔 마시기   [삭제]
[미완료 / 완료하기] 책 5쪽 읽기        [삭제]

저장 상태: 이 브라우저에 저장됨

입력칸 위의 ‘할 일 입력’은 항목의 이름입니다. 입력칸 안의 예시 문장은 글을 쓰면 사라지므로, 그것만으로 입력칸을 설명하지 않도록 요청합니다. 화면에 보이는 이름을 입력칸과 연결하는 방법은 W3C의 입력 요소 레이블 안내를 참고했습니다.

‘완료’는 색깔 하나로만 구별하지 않고 완료됨이라는 글자나 취소선을 함께 사용합니다. 삭제는 의미를 모를 수 있는 작은 아이콘만 두기보다 ‘삭제’라는 글자를 보여 줍니다. 내가 익숙한 아이콘을 다른 사람도 똑같이 이해한다고 가정하지 않는 것입니다.

3. AI에게 보낼 화면 개선 요청문

기존 대화를 이어서 아래 내용을 보냅니다. 새 대화를 열었다면 현재 index.html 전체 코드를 함께 전달하세요. 2편에서 저장 기능이 정상 작동했다면 그 사실도 적어 두면 좋습니다.

현재 할 일 앱을 비개발자가 처음 봐도 쓰기 쉽게 다듬어 줘.
새 기능을 크게 늘리지 말고 아래 세 묶음만 개선해 줘.

1. 읽기와 조작
- 제목 → 입력 영역 → 항목 수 → 목록 → 저장 상태 순서로 배치한다.
- 본문과 입력 글자는 기본 16px 이상으로, 배경과 구별되는 진한 색을 쓴다.
- 입력칸 위에 항상 보이는 '할 일 입력' 레이블을 두고 입력칸과 연결한다.
- 추가·완료하기·완료 취소·삭제 버튼은 의미를 글자로 표시한다.
- 주요 버튼의 누르는 영역은 가로와 세로 최소 44px을 목표로 하고 서로 간격을 둔다.
- 키보드 Tab으로 이동할 때 현재 선택된 입력칸과 버튼의 테두리가 보이게 한다.

2. 상태 안내
- 목록이 비었을 때 '아직 할 일이 없습니다. 첫 할 일을 적어 보세요.'를 표시한다.
- 전체·완료·남은 항목 수를 실제 목록에서 계산해 표시한다.
- 완료 상태를 색만으로 구별하지 않고 글자나 취소선도 함께 쓴다.
- 저장 성공·실패 문구는 실제 결과와 일치해야 한다.

3. 좁은 화면
- 화면 폭 360px에서도 입력칸·버튼이 겹치거나 가로로 잘리지 않게 한다.
- 긴 문장과 공백 없는 긴 문자열도 목록 안에서 줄바꿈한다.
- 필요하면 버튼을 다음 줄로 배치한다. 과한 애니메이션은 넣지 않는다.

유지할 것:
추가·Enter 입력·빈 입력 거부·완료 전환·개별 삭제·저장과 복원.
현재 localStorage 키와 항목 데이터 구조를 바꾸지 않는다.
기존 데이터를 초기화하거나 예시 항목으로 덮어쓰지 않는다.
외부 라이브러리·서버·로그인 없이 index.html 파일 하나를 유지한다.
입력 내용은 글자 그대로 표시하고 기존 오류 처리를 유지한다.

변경 내용을 쉬운 말로 설명하고 생략 없는 전체 코드를 줘.

여기서 16px과 44px은 이 실습에서 선택한 설계 목표입니다. 숫자만 맞췄다고 접근성이 모두 검증되는 것은 아닙니다. W3C의 터치·클릭 대상 크기 설명도 버튼 크기와 주변 간격을 함께 다룹니다. 우리는 작은 화면에서도 버튼을 구별하고 누를 수 있는지 직접 확인하겠습니다.

4. 적용 전후를 같은 조건으로 비교합니다

1. 기존 코드 파일을 index-before-layout.html로 한 부 복사합니다. 파일 복사는 저장된 할 일 데이터까지 백업하는 것은 아닙니다.
2. 앱에는 ‘물 한 잔 마시기’와 ‘책 5쪽 읽기’ 같은 연습 항목만 남기고, 첫 번째 항목을 완료로 표시합니다.
3. 전체·완료·남은 항목 수와 현재 상태를 적어 둡니다. 이 예시는 전체 2개, 완료 1개, 남은 일 1개입니다.
4. 원래 위치의 index.html을 새 코드로 바꾸고 저장합니다.
5. 같은 브라우저·프로필·파일 경로에서 새로고침합니다.

색상이나 간격이 달라졌더라도 기존 두 항목과 완료 상태는 유지돼야 합니다. 목록이 사라졌다면 새 예시를 입력해서 덮기 전에, AI가 저장 키나 데이터 형식을 바꿨는지 먼저 확인하세요. 로컬 파일의 저장 환경에 관한 제약은 2편에서 설명한 것과 같습니다.

5. 보기 좋은 화면인지 다섯 장면으로 확인합니다

장면 A · 처음 열었을 때

연습 항목을 모두 지워 빈 목록 상태를 만듭니다. 오류처럼 텅 비어 보이지 않고 첫 할 일을 입력하라는 안내가 나타나야 합니다. 항목을 하나 추가하면 빈 상태 안내는 사라지고 개수가 1로 바뀌어야 합니다.

장면 B · 문장이 길어졌을 때

‘퇴근 후 책상 위에 쌓인 종이를 정리하고 내일 읽을 자료만 따로 모아 두기’를 넣어 보세요. 문장이 길어져도 삭제 버튼을 화면 밖으로 밀어내지 않아야 합니다. 공백 없는 ‘가나다라마바사아자차카타파하가나다라마바사아자차카타파하’도 추가해 줄바꿈을 확인합니다.

장면 C · 창을 좁혔을 때

브라우저 창의 가로 폭을 줄입니다. 입력칸과 추가 버튼이 겹치거나, 버튼 일부가 잘리거나, 페이지를 좌우로 움직여야 하는지 확인하세요. 창을 줄이는 것은 좁은 화면의 1차 확인입니다. 이것만으로 실제 휴대전화에서의 동작까지 검증됐다고 할 수는 없습니다.

장면 D · 마우스 없이 이동할 때

입력칸을 한 번 누른 뒤 Tab을 눌러 다음 버튼으로 이동해 보세요. 현재 위치를 나타내는 테두리가 보여야 합니다. Shift+Tab으로 이전 위치로 돌아갈 수 있는지, 버튼에 초점이 있을 때 Enter 또는 Space로 동작하는지도 확인합니다. 브라우저·운영체제의 키보드 탐색 설정에 따라 이동 방식은 달라질 수 있습니다.

장면 E · 글자를 크게 봤을 때

브라우저 메뉴의 확대 기능으로 200%까지 키워 봅니다. 글자와 버튼이 겹치지 않고, 중요한 동작을 계속 찾을 수 있는지 확인합니다. 끝나면 원래 배율로 되돌립니다. 확대했을 때 보기 좋다는 이유만으로 평소 글자가 너무 작은 문제를 덮지는 마세요.

6. 화면을 바꾼 뒤에는 기능도 다시 확인합니다

AI가 화면을 고치며 버튼과 연결된 코드를 바꿀 수도 있습니다. 이전에 잘되던 기능이 여전히 되는지 확인하는 일을 개발에서는 ‘회귀 확인’이라고 부릅니다. 이름은 어려워 보여도 확인할 항목은 익숙합니다.

• 추가 버튼과 Enter로 항목이 한 번씩만 추가되는가?
• 공백만 입력하면 빈 항목이 생기지 않는가?
• 완료·완료 취소를 누르면 해당 항목과 개수가 함께 바뀌는가?
• 같은 문장의 항목이 두 개여도 누른 항목만 삭제되는가?
• 새로고침 후 내용·완료 상태·개수가 다시 맞게 표시되는가?
• 저장 실패 안내가 기존처럼 남아 있고, 실패를 성공으로 표시하지 않는가?

‘전체 3개, 완료 1개’라면 남은 일은 2개여야 합니다. 항목 수가 틀렸다면 색상보다 계산과 갱신 순서를 먼저 고쳐야 합니다. 화면의 숫자는 장식이 아니라 현재 상태를 알려 주는 정보이기 때문입니다.

7. 수정 요청은 한 가지 문제씩 보냅니다

현재 문제: 창을 좁히면 긴 할 일 문장이 삭제 버튼을 화면 밖으로 밀어내.
재현 순서: 긴 문장 추가 → 브라우저 창 폭 줄이기.
원하는 결과: 문장은 줄바꿈되고, 삭제 버튼은 화면 안에서 누를 수 있어야 해.

기존 저장 키와 데이터 구조, 추가·완료·삭제 동작을 유지해 줘.
이번에는 이 배치 문제만 수정해 줘.
바꾼 부분을 설명하고 전체 index.html 코드를 다시 줘.

수정할 때마다 기능 전체를 새로 만들라고 요청하면 잘되던 부분까지 달라질 수 있습니다. ‘어떤 조건에서 무엇이 불편했는지’와 ‘유지할 것은 무엇인지’를 함께 전달하는 습관을 들여 보세요.

오늘의 도전 기록

• 처음 화면에서 불편했던 장면: ______
• AI에게 전달한 구체적인 수정 조건: ______
• 수정 후 다시 확인한 기존 기능: ______
• 아직 확인하지 못한 환경이나 동작: ______

오늘은 작은 앱을 ‘동작하는 화면’에서 ‘다른 사람도 이해할 수 있는 화면’으로 다듬었습니다. 직접 코드를 모두 작성하지 않았더라도, 기능을 정하고 결과를 살펴보고 수정 이유를 설명하는 과정은 내 몫입니다. 다음 단계에서는 이 앱을 다른 사람에게 보여 주기 전에 무엇을 확인해야 하는지 이어서 다루겠습니다.

이전 글: 2편 · 새로고침해도 남는 할 일 앱
처음부터: 1편 · 첫 할 일 앱 만들기
연재 모아보기: AI로 첫 앱 만들기