테슬러의 원칙: 화면에서 사라진 복잡함은 누가 맡을까

입력란은 하나인데 안내서는 세 페이지

가상의 연락처 가져오기 도구가 있습니다. 화면에는 ‘파일 가져오기’ 버튼 하나만 보입니다. 그런데 안내서는 먼저 스프레드시트의 열 순서를 바꾸고, 전화번호 표기를 정리하고, 필요한 국가 범위를 확인하라고 합니다. 한 열만 규칙과 달라도 파일 전체가 거절됩니다. 버튼을 누르기 전에 사용자는 어디에서 어떤 일을 해야 할까요?

버튼과 준비 안내를 함께 읽어보세요

가져오기 전에 만들어야 하는 CSV

도구가 받는 파일

고정된 열 순서

1열	2열	3열
이름	이메일	전화번호

화면 밖에서 남는 준비

열 하나가 다르면

파일 전체를 다시 준비

전화번호 형식

받는 형식 확인 필요

국가 범위

확인 필요

파일 가져오기 버튼 한 개로 파일 준비가 사라진 것은 아닙니다. 개인정보나 실제 연락처를 사용하지 않는 읽기용 작업표입니다.

기존 도판의 출처와 전체 설명 읽기

가상의 연락처 가져오기 상황입니다. 아래 버튼과 안내는 읽기용 화면이며 파일을 선택하거나 전송하지 않습니다.

도구 안에서 보이는 것

화면의 버튼

파일 가져오기

처리 조건

이름·이메일·전화번호 순서의 파일만 받음. 한 열이 다르면 파일 전체를 다시 준비해야 함.

도구 밖의 준비 안내

열을 맞추기

스프레드시트에서 이름·이메일·전화번호 순서로 열을 옮깁니다.

형식을 맞추기

안내가 요구하는 전화번호 형식에 맞춰 기호와 국가 범위를 직접 확인합니다.

가상 도구에는 파일 가져오기 버튼 하나가 있지만, 그 전에 사용자가 별도 스프레드시트의 열 순서와 전화번호 형식을 준비해야 합니다. 한 열이 다르면 전체 파일이 거절되는 조건입니다.

화면 안에서만 리뷰하면 입력 단계가 하나라는 결론을 내리기 쉽습니다. 그러나 사용자의 과제는 파일을 고치는 순간 이미 시작됐습니다. 화면 밖의 준비도 같은 작업 흐름에 넣어야 버튼 하나가 얼마나 간단한지 판단할 수 있습니다. 먼저 이 파일의 열을 실제로 맞춰보는 대신, 시스템이 후보를 보여 주고 사람이 확인하는 변경안을 살펴보겠습니다.

후보를 제안하는 일과 확인하는 일

변경안에서는 시스템이 원본 열과 가져올 항목의 연결 후보를 보여 줍니다. 이 연결을 매핑이라고 합니다. ‘메일’이라는 열을 ‘이메일’ 항목에 넣겠다는 대응입니다. 열을 옮겨 저장하는 대신 원본과 후보를 나란히 읽습니다. 후보를 보여 주는 것과 사용자가 연결을 확인하는 것은 서로 다른 단계입니다.

아래의 원본 열은 ‘연락처 이름’, ‘메일’, ‘연락 번호’, ‘지역 정보’입니다. 이번 과제의 가져올 항목은 이름·이메일·전화번호 세 가지로 고정합니다. 지역 정보가 무엇을 뜻하는지와 전화번호의 국가 범위는 시스템이 마음대로 채우지 않습니다. 먼저 후보를 살펴보고, 연결을 확인한 다음 합성 결과와 반복 처리를 확인해보세요. 정답 점수나 실제 기록은 남기지 않습니다.

원본과 연결 후보를 나란히 확인하기

원본을 미리 고쳐 온 경우와 후보를 확인하는 경우를 비교해 보세요. 국가 범위를 모르는 전화번호의 뜻은 공백 정리처럼 자동 확정하지 않습니다.

전화번호의 공백을 정리할 때는 같은 번호를 다른 표기로 쓰는 것인지 검토할 수 있습니다. 이런 형식 처리에서도 값이 가리키는 대상을 바꾸지 않는지 확인해야 합니다. 빠진 국가 코드를 추측해 붙이는 일은 번호의 뜻을 바꿀 수 있습니다. 잘못 추측하면 다른 사람에게 연결될 위험이 있으므로 두 작업을 같은 종류의 자동화로 묶어서는 안 됩니다. 이 체험에서는 실제 전화번호를 사용하지 않고 그 경계만 설명합니다.

사용자가 무엇을 가져올지, 어떤 자료를 공유할지, 기존 항목을 덮어쓸지 결정하는 일도 남습니다. 서비스가 값을 추측할 수 있다는 이유만으로 그 의도를 숨겨서는 안 됩니다. 실제 연락처 서비스를 만든다면 미리보기의 접근 권한과 개인정보 보호, 안전한 수정·확인도 별도로 설계해야 합니다. 여기의 합성 상태가 그런 요구를 충족했다고 보증하지는 않습니다.

‘보존’이라는 이름을 어떻게 읽을까

Larry Tesler의 공식 기록에는 약 1984년의 원래 정식화가 남아 있습니다. 그 요지는 애플리케이션에서 과제를 이루려면 줄일 수 없는 복잡함이 남고, 이를 사용자·애플리케이션 개발자·플랫폼 개발자 중 누가 처리할지 정해야 한다는 것입니다. 연락처 파일이라면 사용자가 열 규칙을 외워 맞출 수도 있고, 앱이 여러 열 이름을 읽어 알맞은 항목과의 대응을 관리할 수도 있습니다. 이 기록은 저자의 설계 관점을 확인하는 1차 자료입니다.

이 원칙을 ‘어떤 복잡함도 없앨 수 없다’고 읽으면 없어도 되는 일까지 남기게 됩니다. 같은 정보를 두 번 묻는 단계나 이미 폐지한 규칙은 지울 수 있습니다. 과제의 목적을 바꾸면 필요한 처리도 달라집니다. 먼저 없앨 일을 찾고, 그래도 남는 일을 누가 맡을지 묻는 순서가 필요합니다.

앱과 플랫폼을 구분하는 이유는 같은 형식 처리를 여러 서비스가 각각 만들 필요가 있는지 묻기 위해서입니다. 공통 규칙을 한 곳에서 관리하고 재사용하면 사용자와 개발자의 수고를 함께 줄일 가능성도 있습니다. 테슬러의 관점은 개발을 무조건 복잡하게 만들라는 지시보다, 구현이 쉽다는 이유로 반복 수고를 사용자에게 넘기고 있지는 않은지 묻는 도구로 사용할 수 있습니다.

한 번 성공한 뒤에도 일이 남습니다

체험의 결과는 r1과 r3을 교육용 처리 완료로, r2를 검토 필요로 나눕니다. r2에는 확인할 이메일 표기와 국가 범위가 남아 있습니다. ‘전체 실패’만 보여 주면 이미 처리한 두 행까지 다시 손볼 수 있습니다. 반대로 ‘완료’만 보여 주면 남은 한 행을 놓칠 수 있습니다. 결과에는 이미 끝난 일과 아직 판단할 일을 구별해 남겨야 합니다.

‘검토 행만 다시 살피기’에서는 남은 r2만 따로 읽습니다. ‘같은 행 다시 처리하기’를 눌러도 이미 처리한 r1과 r3의 상태는 유지되고 새 복사본은 생기지 않습니다. 이처럼 같은 요청을 다시 해도 결과가 불필요하게 늘어나지 않는 성질을 멱등성이라고 합니다. 이 예에서는 각 행을 구별하는 고정 식별자를 유지해 이미 처리한 행을 알아봅니다. 실제 서비스에서는 무엇을 같은 항목으로 볼지, 내용이 달라진 파일은 어떻게 구별할지까지 따로 정해야 합니다.

불확실한 값에 필요한 자료가 없다면 확인할 사람과 이어갈 방법을 남겨야 합니다. 사용자가 바꿀 수 있는 열 연결, 어떤 값이 문제인지 알려 주는 설명, 담당자가 볼 필요한 기록을 검토할 수 있습니다. 기술 내부의 모든 판단 과정을 보여 줄 필요는 없지만 수정에 필요한 정보는 남겨야 합니다. 운영팀이 매번 파일을 손으로 고치고 있다면 그 일이 의도된 서비스인지 임시 대응인지도 구분해보세요.

사람이 예외를 처리하는 것 자체가 잘못은 아닙니다. 다만 그 시간과 오류를 빼고 자동화 성과를 계산하면 전체 수고가 보이지 않습니다. 이 사례의 끝은 모든 값이 저절로 맞춰진 화면이 아니라, 처리한 행을 유지하면서 남은 판단과 담당자를 알 수 있는 상태입니다. 위 체험의 정적 해설에는 같은 흐름의 모든 상태가 남아 있으므로 조작하지 않아도 끝까지 읽을 수 있습니다.

검색이 못 찾으면 어디로 이어질까요?

GOV.UK Design System의 Addresses 문서는 우편번호 같은 일부 정보로 영국 주소를 찾고 목록에서 선택하는 방법을 설명합니다. 동시에 국제 주소, 검색에 없거나 잘못 표시된 주소를 위해 수동 입력을 제공하도록 안내합니다. 검색의 지원 범위를 분명히 밝히고 기본 경로와 예외 경로를 함께 설계하는 공식 지침입니다.

관찰 방식

공식 문서 기반

문서에서 확인한 내용

주소 검색의 기본 흐름과 예외 상황에서의 수동 입력을 안내합니다.

적용할 때의 판단

기본 흐름을 자동화하면서 예외 처리의 부담이 커지지 않는지 확인해보세요.

근거의 범위

공식 문서에 소개된 기능을 살펴보는 사례입니다. 실제 사용 과정과 제작 의도, 제품 성과는 별도로 검토해야 합니다.

문서는 우편번호의 대소문자나 공백 같은 표기를 유연하게 받는 방법도 안내합니다. 사용자가 표현을 고쳐 제출하게 하는 대신 시스템이 지원할 입력 형식을 넓히는 사례입니다. 다만 영국 중심 지침이므로 한국 주소나 국제 배송의 규칙으로 그대로 복사하면 안 됩니다. 이 글은 공식 문서를 읽었으며 실제 정부 서비스 UI를 조작하거나 시간 절약 효과를 측정하지 않았습니다.

수동 입력란을 늘어놓는다고 예외가 모두 해결되는 것도 아닙니다. GOV.UK는 여러 입력란을 쓰려면 받을 국가를 알고 그 모두를 지원할 형식을 찾을 수 있어야 한다고 설명합니다. 여러 나라의 다양한 주소 형식을 받아야 하면서, 인쇄할 주소 형식을 정하거나 주소의 정확한 하위 부분을 사용할 필요가 없다면 textarea처럼 한 영역에 쓰는 방식도 검토할 수 있습니다. 인쇄 형식이나 부분별 사용이 필요한 배송 서비스라면 이 조건을 먼저 다시 확인해야 합니다. 어떤 정보를 왜 나눠 받는지 정한 뒤에 형식을 선택하세요.

처음의 연락처 파일도 같습니다. 자동 후보가 해결하는 기본 경로만 보지 말고, 미지정 열과 r2 같은 예외에서 누가 무엇을 보고 이어갈 수 있는지 확인합니다. 검색이 찾지 못한 주소와 뜻을 정하지 못한 열은 다르지만, 완료하지 못한 일을 숨기지 않고 이어갈 방법을 마련한다는 질문은 옮겨 사용할 수 있습니다.

‘간단해졌다’를 전체 과정에서 확인하기

화면 수나 클릭 수는 전체 수고의 일부만 보여 줍니다. 실제 제품을 평가할 때는 파일 준비부터 과제가 끝날 때까지의 시간, 필요한 사전 지식, 실패 뒤 재작업, 문의와 운영 담당자의 처리 시간을 함께 볼 수 있습니다. 자동 제안이 맞은 비율뿐 아니라 틀린 제안을 사용자가 알아차리고 고칠 수 있었는지도 확인해야 합니다.

가상 파일 도구에서 업로드 성공률이 높아졌더라도 잘못 연결된 전화번호가 늘었다면 개선으로 끝낼 수 없습니다. 반대로 연결 확인 단계가 하나 늘었지만 외부 스프레드시트 편집이 없어졌다면 전체 과제는 쉬워졌을 수 있습니다. 어떤 부담이 누구에게서 줄었고 어떤 판단이 남았는지 설명할 수 있어야 합니다.

이번 변경안은 자동 탐지, 매핑 확인, 부분 오류 처리와 반복 방지를 함께 바꿉니다. 실제 시험에서 개선이 보이더라도 그 묶음의 결과이며 자동 탐지 하나의 인과 효과로 단정할 수 없습니다. 원본 파일과 과제 목표를 맞춰 비교하고, 시스템 개발·유지 비용과 예외 처리의 부담도 검토하세요. 이 글의 표와 체험에는 실측 시간, 인지부하나 오류율이 없습니다.

화면 밖의 예외 처리도 전체 일에 넣기

한 버튼 밖의 전체 처리 기록

1. 원본 준비 열 순서·전화번호 범위
2. 연결 후보 확인 사용자의 의미 판단
3. 부분 결과 완료 행 / 검토 행
4. 예외 인계·재확인 같은 행 ID 유지
5. 규칙 유지 앱·플랫폼·운영 책임

“간단해졌다”를 확인하려면

과정	필요한 기록
사전 준비	현재 시간 미측정
사용자 검토·재작업	현재 시간·오류 미측정
운영 인계·규칙 유지	현재 비용 미측정

자동 처리 화면만으로 총수고가 줄었다고 계산할 수 없습니다. 실제 운영 인계나 성과 측정을 하지 않았습니다.

기존 도판의 출처와 전체 설명 읽기

완료한 행과 검토할 행을 나눠 둔 모습에 주목하세요. 자동화 성과를 말할 때 이 사람의 처리 시간과 규칙 유지 비용을 제외하면 전체 부담이 가려집니다.

처음의 질문으로 돌아가보세요. 버튼이 하나인 이유가 필요 없는 일이 사라졌기 때문인가요, 아니면 사용자가 다른 프로그램에서 미리 끝내야 하기 때문인가요? 입력란을 지운 뒤에도 누군가 정보를 채우고 있다면 그 일의 담당과 수정 경로를 보이게 해야 합니다. 필요한 일의 좋은 분담은 짧은 화면을 만드는 일보다 전체 과제를 이해하고 끝낼 수 있게 만드는 일에 가깝습니다.

확인해볼 질문

• 사용자가 버튼을 누르기 전에 준비하는 파일·정보·사전 지식까지 같은 과제에 넣었나요?
• 이 정보와 규칙이 정말 필요한가요? 없앨 수 있는 요구를 다른 사람에게 옮긴 것은 아닌가요?
• 시스템 후보와 사람의 확정을 구별하고, 뜻이 불확실한 값의 확인·수정 경로를 남겼나요?
• 일부만 처리됐을 때 남은 일과 담당자를 알 수 있고, 다시 처리해도 이미 끝난 일이 중복되지 않나요?
• 전체 시간·오류·재작업·운영 수고를 함께 보면서 어떤 부담을 누구에게서 줄였는지 설명할 수 있나요?

테슬러의 원래 정식화와 GOV.UK 지침의 확인 범위는 아래에서 원문 위치와 함께 읽을 수 있습니다. 이 글의 작업 분담, 연락처 체험과 국제 배송 판단은 편집적 적용입니다. 실제 학생 학습이나 제품 성과의 측정 결과로 소개하지 않습니다.