위키백과, 우리 모두의 백과사전
“최소 놀람(least astonishment)”은 여기로 연결됩니다. 위키백과에서의 적용 원칙에 대해서는 WP:POLA를 참고하십시오.
사용자 인터페이스 설계와 소프트웨어 설계에서[1] 최소 놀람의 원칙(POLA)은 최소 놀라움의 원칙(POLS)으로도 알려져 있으며,[a] 시스템의 구성요소는 대부분의 사용자가 기대하는 방식으로 동작해야 하며, 따라서 사용자에게 놀라움이나 당혹감을 주지 않아야 한다고 제안한다. 다음은 이 원칙의 따름정리(코롤러리)이다. “필수 기능이 높은 놀람 요인을 가진다면, 그 기능을 재설계할 필요가 있을 수 있다.”[4]
이 원칙은 적어도 1970년대부터 컴퓨터 상호작용과 관련하여 사용되어 왔다. 비록 컴퓨터 기술 분야에서 처음 정식화되었지만, 이 원칙은 다른 분야에도 폭넓게 적용될 수 있다. 예를 들어 글쓰기에서, 작업의 다른 부분을 가리키는 상호 참조나 하이퍼링크는 독자가 무엇을 기대해야 하는지 정확히 알 수 있도록 표현되어야 한다.
“최소 놀람의 법칙(Law of Least Astonishment)”에 대한 초기 언급은 1967년 PL/I 회보(Bulletin)에 등장했다(PL/I는 IBM이 1966년에 발표한 프로그래밍 언어이다).[5] 1960년대 후반에 이르러 PL/I는 이 법칙을 위반하는 것으로 악명이 높아졌는데,[6] 예를 들면 PL/I의 정밀도 변환 규칙 때문에[7] 25 + 1/3 및 1/3 + 25 같은 식이 치명적인 오류를 내거나, 오류를 억제했을 경우 올바른 25.33333333333이 아니라 5.33333333333을 내놓을 수 있었다.[8][9][10][11]
이 법칙이 인쇄물로 처음 등장한 것은 1972년이다.[12]
사용자 특성에 맞추어 조정할 수 없는 시스템의 부분들에 대해서는, 시스템 프로그래밍 언어의 설계자들이 “최소 놀람의 법칙”을 따라야 한다. 간단히 말해, 이 법칙은 시스템 내의 모든 구성 요소가 그 구문(syntax)이 시사하는 바와 정확히 같은 방식으로 동작해야 한다는 뜻이다. 가능하다면 널리 받아들여진 관례를 따라야 하며, 언어의 기존 규칙에서 벗어나는 예외는 최소화되어야 한다.
교과서적 정식화는 다음과 같다. “사람은 시스템의 일부이다. 설계는 사용자의 경험, 기대, 그리고 정신 모형(멘탈 모델)에 부합해야 한다.”[13]
이 원칙은 사용자의 기존 지식을 활용하여 학습 곡선을 최소화하는 것을 목표로 한다. 예컨대 사용자가 익숙할 가능성이 높은 “기능적으로 유사하거나 비슷한 프로그램”에서 많은 부분을 차용한 인터페이스를 설계하는 방식이 있다.[2] 이러한 관점에서 사용자 기대는 특정 컴퓨팅 플랫폼이나 전통과 밀접하게 연관될 수 있다. 예를 들어 유닉스(Unix) 명령줄 프로그램은 스위치에 관해 특정 관례를 따를 것으로 기대되며,[2] Microsoft Windows 프로그램의 위젯은 키보드 단축키에 관해 특정 관례를 따를 것으로 기대된다.[14] 더 추상적인 API 같은 환경에서는 함수나 메서드 이름이 직관적으로 그 동작과 일치할 것이라는 기대가 또 다른 예가 된다.[15] 이 관행은 또한 합리적인 기본값(default)의 적용을 포함한다.[4]
인터페이스의 두 요소가 서로 충돌하거나 모호한 경우, 동작은 사용자를 가장 덜 놀라게 하는 쪽이어야 한다. 특히 프로그래머는 프로그램의 내부 동작을 아는 입장에서 자연스러운 동작을 택하기보다는, 프로그램을 사용하는 사람을 가장 덜 놀라게 할 동작을 생각하려고 노력해야 한다.[4]
“가장 덜 놀라게 하는” 동작의 선택은 예상 사용자층(예: 최종 사용자, 프로그래머, 또는 시스템 관리자)에 따라 달라질 수 있다.[2]
키보드 단축키를 제공하는 웹사이트는 종종 ?를 눌러 사용 가능한 단축키를 볼 수 있도록 한다. 예로는 Gmail,[16] YouTube,[17] Jira가 있다.[18]
Windows 운영체제와 리눅스의 일부 데스크톱 환경에서는, F1 기능 키가 보통 응용 프로그램의 도움말 프로그램을 연다. macOS에서 유사한 단축키는 ⌘ Command+⇧ Shift+/이다. 사용자는 통상적인 도움말 단축키를 눌렀을 때 도움말 창이나 컨텍스트 메뉴가 나타나기를 기대한다. 그런데 소프트웨어가 이 단축키를 다른 기능에 사용하고 도움말이 나타나지 않는다면, 놀람을 유발할 가능성이 크다.[19]
프로그래밍 언어의 표준 라이브러리는 보통 의사코드 ParseInteger(string, radix)와 유사한 함수(서브루틴)를 제공하는데, 이는 사람이 읽을 수 있는 숫자로 이루어진 문자열에서 기계가 읽을 수 있는 정수를 만든다. 기수(radix)는 관례적으로 10으로 기본값이 설정되며, 이는 문자열을 10진수(밑 10)로 해석한다는 뜻이다. 이 함수는 보통 2진수(밑 2), 8진수(밑 8) 등 다른 진법도 지원하지만, 일반적으로는 이를 명시적으로 지정할 때에만 적용된다. 이러한 관례와 달리, JavaScript는 원래 “0”으로 시작하는 문자열에 대해 기본값을 밑 8로 두어 개발자의 혼란과 소프트웨어 버그를 초래했다.[20] 이는 ECMAScript 3에서 권장되지 않았고 ECMAScript 5에서 제거되었다.[21]
FreeBSD 같은 일부 개발 커뮤니티는[22] 놀라지 않는 사용자 경험을 만드는 지침 중 하나로 POLA를 사용한다.
각주
- ^ 또는 최소 놀라움의 법칙(law of least surprise), **최소 놀라움의 규칙(rule of least surprise)**이라고도 한다.[2][3]
참고 문헌
- ^ Seebach, Peter (2001-08-01). "The Principle of Least Astonishment". The cranky user. IBM DeveloperWorks. 원본 문서는 2014-02-01에 보존됨. 2014-01-23에 확인.
- ^ 위로 이동: a b c d Raymond, Eric Steven (2003). "Applying the Rule of Least Surprise". The Art of Unix Programming. faqs.org. p.20. ISBN 978-0-13-142901-7. 2020-08-23에 확인.
- ^ James, Geoffrey (1987). The Tao of Programming. InfoBooks. 4.1. ISBN 0-931137-07-1. 2014-02-05에 확인.
- ^ 위로 이동: a b c Cowlishaw, M. F. (1984). "The design of the REXX language"(PDF). IBM Systems Journal. 23 (4): 333. doi: 10.1147/sj.234.0326. 2014-01-23에 확인. 새 기능과 관련해 높은 놀람 요인이 있을 수 있는가? 사용자가 기능을 우연히 잘못 적용하여 그에게 예측 불가능한 결과처럼 보이는 것을 야기한다면, 그 기능은 높은 놀람 요인을 가지며 따라서 바람직하지 않다. 필수 기능이 높은 놀람 요인을 가진다면, 그 기능을 재설계할 필요가 있을 수 있다.
- ^ Southworth, R. N. (1967년 12월). Southworth, R. N. (편). "Proposal for PL/I Pseudo-name". ACM SIGPLAN Notices. 2 (12) (PL/I Bulletin no. 5): 6. doi: 10.1145/1139502.1139504. ISSN 0362-1340. S2CID 12180929.
- ^ Date, C. J. (2022-02-11). Database Dreaming Volume I: Relational Writings Revised and Revived. Technics Publications. 2장, 참고문헌 36. ISBN 978-1-63462-984-3. 내 친구가 한 번 내게 말하길—이건 분명 1960년대 후반의 어느 때였을 텐데—다른 것은 차치하고, PL/I가 절대로 아닌 한 가지가 있는데, 그것은 ‘최소 놀람의 언어’라는 것이다.
- ^ Tremblay, Jean-Paul; Sorenson, Paul G. (1985). The theory and practice of compiler writing. New York: McGraw-Hill. ISBN 9780070651616. 여기서 PL/I는 대표적인 나쁜 사례이며, FIXED 나눗셈에서 보이듯 프로그래머가 생각하는 대로 동작하지 않는 구문들로 가득하다.
- ^ Holt, Richard C. (1973년 5월). "Teaching the fatal disease: (or) introductory computer programming using PL/I". ACM SIGPLAN Notices. 8 (5): 8–23. doi: 10.1145/986948.986950. 불행히도, '25 + 1/3'이라는 식은 5.33333333333333을 낸다.
- ^ Golden, Donald (1980년 10월). "A plea for friendly software". ACM SIGSOFT Software Engineering Notes. 5 (4): 4–5. doi: 10.1145/1010884.1010885. PL/I를 쓰지 않는 프로그래머가 PL/I에 결함이 없다고 오해하지 않도록, PL/I의 비우호성을 보여 주는 다음 예들을 보라. PL/I의 형 변환 규칙은 프로그래머에게 위궤양을 주기에 충분하다. (25 + 1/3)이라는 식을 평가할 때 치명적 오류를 내는 언어가 또 어디 있겠는가? (오류 검사를 억제해도 마찬가지로 나쁘다. 그 경우 결과는 5.3333...이다.)
- ^ Stansifer, Ryan D. (1995). The Study of Programming Languages. Englewood Cliffs, N.J.: Prentice Hall. p.123. ISBN 978-0-13-726936-5. PL/I는 거의 모든 타입을 다른 타입으로 변환하며 때로는 놀라운 결과를 낳는다는 점에서 악명이 높다. 예로 1/3 + 25를 보라. PL/I에서 이 식의 값은 5.33333333333이다. 왜인가? 1/3은 소수점 오른쪽 14자리를 포함해 15자리 정밀도로 계산된다. 이후 25는 같은 정밀도로 강제 변환되며, 가장 중요한 자릿수인 2를 잃는다! 이는 PL/I에서 오류를 발생시키지만 기본값은 이를 무시하는 것이다. 이는 Barron 1968에서 처음 인쇄물로 등장했으며, 언어 설계의 민간 법칙인 ‘최소 놀람의 법칙’을 위반하는 사례로 제시된다.
- ^ "Enterprise PL/I for z/OS 5.3 - Language Reference"(PDF). IBM. 2021년 3월. pp.57–62. 다음 식을 고려하라: 25+1/3. 이 식의 평가 결과는 정의되지 않으며 FIXED 나눗셈이 구현에서 정의된 최대 정밀도의 값을 만들기 때문에 FIXEDOVERFLOW 조건이 발생한다. [...] 두 평가 결과는 표 29에 나타낸 대로 도출된다.
- ^ Bergeron, R.D.; Gannon, J.D.; Shecter, D.P.; Tompa, F.W.; Dam, A. Van (1972). "Systems Programming Languages". Advances in Computers. 12: 175–284. doi: 10.1016/s0065-2458(08)60510-0. ISBN 9780120121120.
- ^ Saltzer, J. H.; Kaashoek, Frans (2009). Principles of computer system design: an introduction. Morgan Kaufmann. p.85. ISBN 978-0-12-374957-4.
- ^ Petroutsos, Evangelos (2010). Mastering Microsoft Visual Basic 2010. Wiley. p.133. ISBN 978-0-470-53287-4.
- ^ Bloch, Joshua (2006). "How to design a good API and why it matters". Proceeding OOPSLA '06 Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications. Association for Computing Machinery. pp.506–7. doi: 10.1145/1176617.1176622. ISBN 1-59593-491-X. S2CID 27230400.
- ^ Vivian (2013-06-21). "Keyboard shortcuts for Gmail". Google Inc. 2013-07-27에 확인.
- ^ "Keyboard shortcuts for YouTube - YouTube Help". support.google.com. 2022-08-16에 확인.
- ^ "Using Keyboard Shortcuts". Atlassian. 2013-07-27에 확인.
- ^ Keizer, G. (2010-03-01). "Microsoft: Don't press F1 key in Windows XP". Computerworld. 2019-11-10에 확인.
- ^ "Why does the radix for JavaScript's parseInt default to 8?". Stack Overflow. 2011-04-08.
- ^ "parseInt()", Mozilla Developer Network (MDN), 2024-03-15. 입력 문자열이 "0"(0)으로 시작하면 radix는 8(8진수) 또는 10(10진수)으로 가정된다. 어떤 radix가 선택되는지는 구현에 따라 달라진다. ECMAScript 5는 10(10진수)을 사용해야 한다고 명확히 하지만, 아직 모든 브라우저가 이를 지원하는 것은 아니다.
- ^ "Frequently Asked Questions for FreeBSD 2.X, 3.X and 4.X". FreeBSD. 2002-06-11. 2023-02-15에 확인.
바깥 링크
