좋아요 — “점착성(viscosity)”이라는 개념이 프로그래밍/소프트웨어 설계 문맥에서도 사용된다는 점이 흥미롭고, 특히 “작은 변경을 할 때 얼마나 많은 인지적·구조적 저항이 있는가”라는 관점과 잘 맞아 보입니다. 여기 이 개념을 다룬 연구 및 이론적 틀을 몇 개 정리해볼게요.
(단, 소프트웨어 설계 맥락에서 정량적인 랜드마크 논문이 많지는 않고, 주로 HCI·프로그래밍 언어 설계 관점의 이론틀이 많음을 미리 말씀드립니다.)
저자 (연도) | 출처/형식 | 한줄 요약 |
Green, T. R. G. & Petre, M. (1996) | “Notational Systems – the Cognitive Dimensions of Notations framework” (챕터) (Cambridge Computer Laboratory) | 프로그래밍 환경 및 표기(노테이션) 설계에서 “Viscosity = 변경에 대한 저항”이라는 차원이 매우 중요하다고 제시됨. |
Wright, P. (2005) | 노테이션 간/표기 간 변화시 발생하는 점착성(viscosity)의 실제 사례를 다룸. | |
Dev Community 글 (2025) | 코드베이스 설계 맥락에서 '변경이 어려운 구조 = 높은 viscosity'로 설명함. |
주요 인사이트
•
“Viscosity”라는 개념은 원래 HCI·노테이션 설계 문맥(예컨대 사용자 인터페이스 설계, 프로그램 표기 설계)에서 제안되었습니다. Green & Petre가 제창한 “Cognitive Dimensions of Notations” 틀에서 그 정의가 나옵니다:
“Viscosity refers to a notation’s resistance to local change, or to the ease in which a programmer can make small changes to a program.” (Cambridge Computer Laboratory)
•
이 개념은 단순히 코드 길이, 복잡도만이 아니라 작은 변경(버그 수정, 기능 추가, 리팩토링 등)을 가할 때 얼마나 많은 수작업/연쇄작업이 필요한가를 집중 조명합니다. 예를 들어:
◦
반복 점착성(repetition viscosity): 같은 변경을 여러 장소에 반복해야 할 때
◦
•
소프트웨어 설계 측면에서 보면, “컴포넌트 간 결합이 높고 응집이 낮아 작은 변경이 여러 모듈을 건드려야 한다면” 자연스럽게 viscosity가 높아진다고 볼 수 있고, 이는 유지보수성, 변경 용이성 측면에서 나쁜 신호가 됩니다.
개발자 관점 적용 시 생각해볼 요소
•
변경을 가할 때 필요한 작업량: 예컨대 “버튼 A의 기능을 바꿔야 한다” → 관련 모듈, 훅, 상태관리, UI 모두 건드려야 한다면 viscosity가 높음.
•
변경의 연쇄 효과: 하나를 고쳤더니 다른 부분(테스트, 스타일, 상태관리, 컴포넌트 등)까지 손봐야 한다면 viscosity 존재.
•
리팩토링/추상화가 얼마나 ‘작은 변경’으로 구현 가능한가: 모듈이 잘 나눠져 있고 인터페이스가 잘 정의돼 있다면 viscosity 낮고, 그렇지 않으면 높음.
•
설계 초기부터 고려해야 할 ‘변경을 용이하게 하는 구조’: 즉, 응집(한 모듈 안의 책임이 하나로 잘 묶여 있는가) 와 결합(모듈 간 의존이 최소화돼 있는가) 관점과 연결됨.
제언
프론트엔드 개발자나 코치로서 “점착성 = 변경 저항”이라는 개념을 교육 설계에 넣으면 매우 유용할 것 같아요. 예컨대:
•
학습자에게 “이 컴포넌트를 바꿔야 한다면 몇 군데 손대야 할까?”라는 질문을 던져보게 하고, 거기서 많은 곳을 건드려야 한다면 “변경 저항이 높다” 고 설명할 수 있지요.
•
리팩토링/추상화 과제 시 “작은 변경을 쉽게 할 수 있으면 이 설계는 viscosity가 낮다”고 체크리스트에 넣어볼 수 있어요.
•
코드 리뷰 체크리스트에 “이 변경이 한 곳에서 끝나는가, 아니면 여러 모듈을 건드려야 하는가?”라는 항목을 넣고, 후자라면 설계 개선의 지표로 삼을 수 있어요.
네, 이 두 논문은 **'인지 차원(Cognitive Dimensions)'**이라는 매우 유용한 프레임워크를 소개하고, 이를 시각적 프로그래밍 언어(VPL)와 다중 표기법(Multiple Notations) 시스템에 적용하여 분석한 내용을 다루고 있습니다.
두 논문은 HCI(Human-Computer Interaction) 전문가가 아니더라도, 디자이너나 개발자가 특정 표기법(프로그래밍 언어, UI 등)의 유용성을 평가하고 설계상의 장단점을 논의할 수 있도록 **'공유된 어휘(shared vocabulary)'**를 제공하는 것을 목표로 합니다.
두 논문의 핵심 내용을 빠짐없이 정리해 드립니다.
1. '인지 차원' 프레임워크의 핵심 개념 (첫 번째 논문)
첫 번째 논문(T. R. G. Green & M. Petre)은 '인지 차원' 프레임워크를 제안하고, 이를 텍스트(Basic) 및 시각적 프로그래밍 언어(LabVIEW, Prograph)에 적용하여 평가합니다.
프레임워크의 목적
'인지 차원'은 GOMS와 같은 상세한(low-level) 시간 예측 모델이 아닙니다. 대신, 시스템의 구조가 사용자의 활동에 어떤 영향을 미치는지 '광범위하게(broad-brush)' 평가하고 토론하기 위한 **'토론 도구(discussion tool)'**입니다.
핵심 아이디어는 완벽한 표기법은 없으며, 모든 설계는 여러 차원 간의 '트레이드오프(trade-offs)' 관계에 있다는 것입니다.
핵심 인지 차원(Cognitive Dimensions)
사용자가 언급한 개념을 포함한 주요 '차원'들은 다음과 같습니다:
•
점착성 (Viscosity):
◦
정의: 사용자가 "하나의 간단한 개념적 변경"을 수행하기 위해 얼마나 많은 노력을 들여야 하는가 (즉, 변경에 대한 저항).
◦
예시: LabVIEW에서 코드 중간에 새 노드를 삽입하려면, 주변의 모든 노드와 와이어를 수동으로 재배치해야 했습니다. 이는 매우 '점착성'이 높은(변경이 어려운) 작업입니다.
•
숨겨진 의존성 (Hidden Dependencies):
◦
정의: 두 구성요소가 서로 의존하지만(연결되어 있지만), 그 관계가 표기법 상에서 명시적으로 보이지 않는 경우입니다.
◦
예시: 스프레드시트에서 D2 셀이 B2 셀을 참조할 때, D2의 수식에는 B2가 보이지만 B2 셀만 봐서는 D2가 자신을 참조한다는 사실을 알 수 없습니다9.
•
가시성 (Visibility) 및 병치성 (Juxtaposability):
◦
정의: 사용자가 작업에 필요한 구성요소들을 쉽게 볼 수 있는지, 특히 관련 있는 두 부분을 나란히 놓고 비교(병치)할 수 있는지의 여부입니다.
◦
예시: LabVIEW의 조건문은 'True' 케이스와 'False' 케이스 중 한 번에 하나만 보여주어, 두 케이스를 동시에 비교하는 것을 어렵게 만듭니다11.
•
이차 표기법 (Secondary Notation):
◦
정의: 공식적인 문법(syntax) 외에, 사용자가 레이아웃, 공백, 색상 등을 활용하여 추가적인 의미(예: 관련성)를 전달할 수 있는 여지입니다.
◦
예시: 텍스트 언어인 Basic에서는 관련 코드 라인을 시각적으로 그룹화(예: 'rhyming paragraphs')하여 가독성을 높일 수 있지만, VPL에서는 와이어 정리 때문에 이런 이차 표기법 활용이 매우 제한적이었습니다.
•
매핑 근접성 (Closeness of Mapping):
◦
정의: 표기법이 문제 도메인의 개념과 얼마나 가깝게 일치하는가입니다.
◦
예시: VPL은 for 루프의 복잡한 문법 같은 '프로그래밍 게임'을 피하고, 도메인(예: 전자 회로)과 유사한 시각적 은유를 사용하므로 이 차원에서 강점을 보였습니다.
•
점진적 평가 (Progressive Evaluation):
◦
정의: 프로그램이 완전히 완성되기 전, 부분적인 상태에서도 실행하여 피드백을 얻을 수 있는 정도입니다.
◦
예시: Prograph는 이 기능이 매우 뛰어났지만, LabVIEW는 모든 와이어가 연결되어야만 실행이 가능했습니다.
VPL 평가 결론
저자들은 LabVIEW와 Prograph 같은 VPL이 **'매핑 근접성'**은 뛰어나지만, '점착성', '이차 표기법' 활용, '가시성' 측면에서는 텍스트 언어보다 훨씬 나쁜 '트레이드오프'를 보여준다고 분석했습니다. 특히 '점착성' 테스트에서 LabVIEW는 간단한 변경에 Basic보다 8배나 많은 시간이 걸렸습니다18.
2. '다중 표기법' 환경에서의 문제 (두 번째 논문)
두 번째 논문(Green, Blackwell 등)은 '인지 차원' 프레임워크를 여러 표기법이 섞여 작동하는 시스템 (예: HTML + CSS + JavaScript)에 확장 적용합니다.
다중 표기법의 핵심 문제
시스템이 여러 표기법으로 구성될 때, 각 표기법의 인지적 비용이 단순히 더해지는 것이 아니라, 표기법 간의 **상호작용으로 인해 새로운 인지적 문제들이 발생(emergent properties)**한다는 것입니다.
다중 표기법 환경에서 악화되는 차원들
•
숨겨진 의존성 (Hidden Dependencies):
◦
이것이 다중 표기법 환경의 가장 큰 문제입니다. 표기법 간의 연결이 보이지 않습니다.
◦
예시: CSS 파일에 있는 .foo라는 선택자는 HTML 파일에 있는 class="foo"에 강력하게 의존합니다. 하지만 HTML 파일만 보는 사람은 이 div가 CSS에 의해 조작된다는 사실(링크)을 전혀 알 수 없습니다.
•
점착성 (Viscosity):
◦
다중 표기법 환경은 "높은 점착성"을 유발합니다.
◦
예시: '고객 ID'라는 하나의 개념적 변경을 하려면, 데이터베이스 스키마(표기법 1), 백엔드 API 로직(표기법 2), 프론트엔드 UI 템플릿(표기법 3) 등 여러 파일의 여러 표기법을 모두 찾아 수정해야 합니다.
•
가시성 (Visibility):
◦
하나의 작업을 하려면 여러 표기법을 동시에 봐야 하지만, 이들은 물리적으로 다른 파일에 분산되어 있어 한눈에 보기 어렵습니다. HTML을 보면서 동시에 그 HTML에 적용되는 CSS 규칙을 보는 것은 매우 번거롭습니다.
결론
'인지 차원' 프레임워크는 이처럼 복잡한 다중 표기법 시스템이 왜 사용하기 어려운지 진단하고, 그 설계적 '트레이드오프'를 명확하게 설명하는 **강력한 '어휘(vocabulary)'**를 제공합니다.
