화면 하나를 만들 때 상태를 일곱 개로 나눠 함께 설계합니다.
AI에게 화면을 만들어 달라고 하면 대개 잘 되는 상태 한 장이 나옵니다. 목록에 항목이 열 개 있고, 값이 다 채워져 있고, 버튼이 눌리는 화면입니다. 그런데 실제로 쓰다 보면 목록이 비어 있고, 아직 불러오는 중이고, 요청이 실패하고, 권한이 없어 아예 못 여는 순간이 옵니다. 그때 화면은 대개 아무것도 없는 흰 판이 됩니다. 사용자는 고장인지 기다리는 중인지 구분할 수 없습니다. 그래서 제가 쓰는 개발 운영 규칙에는 화면을 만들 때 정상, 비어 있음, 로딩, 오류, 성공, 비활성, 권한 거절 일곱 가지를 함께 설계한다는 항목이 있습니다. 나중에 붙이는 것이 아니라 처음에 같이 그립니다.
정상 화면만 만들면 무엇이 문제인가요?
화면을 한 장으로 생각하면 나머지 상태는 만들지 않은 것이 아니라 정해지지 않은 것이 됩니다. 정해지지 않은 자리는 결국 비어 있는 화면으로 나타납니다.
비어 있는 화면이 위험한 이유는 정보가 없어서가 아니라, 서로 다른 원인이 똑같이 보이기 때문입니다. 데이터가 없는 것과 못 불러온 것과 볼 권한이 없는 것이 화면에서는 구분되지 않습니다.
만드는 쪽에서도 손해입니다. 원인이 구분되지 않으면 확인은 매번 처음부터 시작해야 하고, 같은 질문을 다시 하게 됩니다.
상태를 몇 개로 나누면 되나요?
일곱 개면 대부분의 화면이 덮입니다. 더 늘리면 지켜지지 않고, 줄이면 앞에서 말한 흰 판이 다시 생깁니다. 각 상태에 필요한 것은 그림이 아니라 화면에 남는 한 문장입니다.
저는 화면을 만들기 전에 이 표부터 채웁니다. 일곱 줄을 다 채우지 못하면 아직 이 화면이 무엇을 하는지 정리되지 않은 것이라, 그 상태로 만들기를 시작하면 대개 다시 만들게 됩니다.
| 상태 | 화면에 남겨야 할 것 |
|---|---|
| 정상 | 내용과 다음에 할 수 있는 동작 |
| 비어 있음 | 왜 비었는지와 채우는 방법 |
| 로딩 | 지금 무엇을 기다리는지 |
| 오류 | 무엇이 실패했는지와 다시 하는 방법 |
| 성공 | 무엇이 끝났는지 |
| 비활성 | 왜 지금은 누를 수 없는지 |
| 권한 거절 | 누구에게 무엇을 요청해야 하는지 |
비어 있음과 로딩은 왜 따로 두나요?
둘 다 내용이 없는 화면이지만 사용자가 해야 할 일이 정반대입니다. 로딩이면 기다리면 되고, 비어 있음이면 기다려도 아무 일도 일어나지 않습니다.
이 둘을 합쳐 두면 확인하는 사람도 헷갈립니다. 화면이 그대로일 때 아직 안 끝난 것인지 이미 끝났는데 결과가 없는 것인지 알 수 없기 때문입니다.
그래서 두 상태는 문장부터 다르게 적습니다. 하나는 불러오는 중이라는 사실을, 다른 하나는 결과가 없다는 사실과 다음 행동을 담습니다.
- 로딩 — 지금 진행 중이며 기다리면 바뀐다
- 비어 있음 — 확인이 끝났고 결과가 없다
- 구분 기준 — 기다리면 화면이 바뀌는가
오류 화면에는 무엇을 적나요?
오류가 났습니다라는 문장만 있으면 다음에 할 일이 없습니다. 오류 화면에는 무엇을 하려다 실패했는지, 지금 다시 해도 되는지, 다시 해도 같으면 무엇을 확인할지가 있어야 합니다.
원문 메시지를 화면 어딘가에 남겨 두는 것도 도움이 됩니다. 사람이 읽기 어려운 문장이라도, 확인할 때는 그 한 줄이 가장 빠른 단서가 됩니다.
다만 원문에 계정이나 키 같은 값이 섞이지 않는지는 따로 봐야 합니다. 화면에 그대로 나오면 그것도 사고입니다.
권한 거절 상태는 왜 따로 두나요?
권한 문제는 다른 실패와 성격이 다릅니다. 다시 시도해도 결과가 바뀌지 않고, 고치는 사람도 화면 앞에 있는 사람이 아닐 때가 많습니다.
그런데 화면에서는 오류나 빈 목록과 똑같이 보이기 쉽습니다. 폴더가 목록에 보인다고 해서 그 안에 파일을 만들 수 있는 것은 아닌데, 화면은 둘을 구분해 주지 않습니다.
그래서 권한 거절은 별도의 상태로 두고, 누구에게 무엇을 요청해야 하는지까지 문장에 담습니다. 그래야 다시 눌러 보는 시간이 사라집니다.
일곱 가지를 함께 설계하면 무엇이 달라지나요?
무엇보다 다시 물어보는 일이 줄었습니다. AI에게 화면을 맡길 때 상태 목록을 함께 주면, 빠진 상태가 결과물에서 바로 눈에 띕니다.
확인하는 순서도 단순해졌습니다. 화면을 켜고 이것저것 눌러 보는 대신, 일곱 상태를 하나씩 만들어 보고 각 문장이 실제로 나오는지만 봅니다. 확인해야 할 것이 정해져 있으니 빠뜨리기 어렵습니다.
무엇을 아직 안 했는지도 분명해집니다. 일곱 줄 중 두 줄이 비어 있다면 그 화면은 완성이 아니라 진행 중입니다. 말로 완료를 판단하지 않아도 되는 자리가 하나 늘어난 셈입니다.
| 정상 화면만 그렸을 때 | 일곱 상태를 함께 그렸을 때 |
|---|---|
| 빈 화면의 원인을 모름 | 화면 문장으로 원인이 구분됨 |
| 실패하면 다음 행동이 없음 | 다시 하는 방법이 화면에 있음 |
| 권한 문제를 반복 시도로 확인 | 요청할 대상이 화면에 적힘 |
| 빠진 부분이 사용 중에 발견됨 | 빠진 상태가 만들 때 드러남 |
자주 묻는 질문
Q. 일곱 가지를 다 만들면 작업이 너무 커지지 않나요?
A. 그림을 일곱 장 그리라는 뜻이 아닙니다. 상태마다 화면에 남길 문장 한 줄을 정하는 것으로 시작해도 됩니다. 문장이 정해지면 화면은 그다음에 붙습니다.
Q. 간단한 화면에도 다 적용해야 하나요?
A. 해당 없는 상태는 해당 없음이라고 적고 넘어갑니다. 중요한 것은 일곱 개를 다 만드는 것이 아니라 빠뜨린 채로 넘어가지 않는 것입니다.
Q. 성공 상태는 굳이 필요한가요?
A. 필요합니다. 끝났다는 표시가 없으면 사용자가 같은 동작을 한 번 더 누르게 되고, 그 결과 같은 요청이 두 번 들어가는 일이 생깁니다.
Q. AI에게는 어떻게 요청하나요?
A. 화면 이름과 함께 상태 일곱 개를 목록으로 적어 주고, 각 상태에서 보여 줄 문장을 먼저 정리해 달라고 합니다. 문장을 확인한 뒤에 화면을 만들게 합니다.
확인 자료
- AI 개발 운영 규칙 문서 v1.3 — 6장 디자인 적용 원칙, 8장 테스트 확인 항목 (확인 2026-09-09)
- AI 개발 운영 규칙 현장 부록 v1.3 — 공개된 화면에 없다와 데이터가 없다의 구분 (확인 2026-09-09)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.