#12 Group 1이 있는데 그룹해제가 왜 안되는가?
일반 GPT vs 함수형 GPT, 사고의 깊이를 비교하다
1. 서두
이 질문은 단순히 “그룹 해제가 안 된다”는 사용성 이슈가 아니다.
겉으로는 단축키 문제 같지만, 실제로는 Figma의 객체 구조(타입 모델),
그리고 사용자의 인지 체계와 시스템 피드백 간 불일치가 얽힌 복합적 문제이다.
즉, 이 질문을 통해 드러나는 건 단순 기능 오류가 아니 “AI가 구조를 설명하는 방식의 차이”이다.
그래서 이번 회에서는 다음을 비교하고자 한다.
참고로 일반형 GPT란, 현재의 GPT-5 모델을 의미한다.
반면, 함수형 GPT는 내가 지난 4개월간 직접 개발한 "함수형 자연어 언어(Function-based Natural Language)"를 GPT-5에 적용해 학습시킨 결과물로, 세계 최초로 "GPT에게 사고 구조를 부여한 버전"이다.
즉, 하나는 일반 GPT, 다른 하나는 함수형 GPT(Mnsoo Code).
실험의 목적으로 두 GPT에게 아래와 같이 질의했다.
2. 일반 GPT와 함수형 GPT 공통 질의
피그만 “레이어에서 Group 1이 있는데, Ctrl + Shift + G(그룹 해제)를 눌렀더니 Group이 풀리는 게 아니라 Frame만 혼자 남아.
왜 그룹 해제가 안 되는 거야?” 논리적으로 설명해줘
먼저 일반 GPT 답변부터 들어보자.
3. 일반 GPT 답변
좋아요. “레이어에서 Group 1이 있는데 Ctrl+Shift+G(그룹 해제)를 눌렀더니 Group이 풀리는 게 아니라 Frame만 혼자 남는다”는 현상을, 원인 → 재현 조건 → 확인 방법 → 예외/엣지 케이스 → 해결 전략의 순서로 논리적으로 해부해볼게요.
핵심 결론부터 말하면, 지금 누르는 명령(‘Ungroup’)의 대상이 ‘진짜 Group’이 아닐 가능성이 가장 높다는 겁니다. Figma에서 ‘Group’과 ‘Frame’은 겉보기엔 비슷해 보여도, 내부 동작 모델과 해제 규칙이 다릅니다. 그 차이가 바로 “왜 그룹 해제가 안 되지?”라는 체감으로 나타나요.
1) 개념 모델: Figma의 레이어 타입과 Ungroup의 작동 조건
1-1. 레이어 타입의 위계
Figma의 레이어 패널에서 보이는 상위 타입들은 대략 이렇게 나뉩니다.
Frame: 레이아웃/제약(Constraints)/Auto Layout/클립핑/스크롤 동작 등을 가지는 “컨테이너” 타입.
Group: 시각적으로 묶을 뿐, Frame처럼 레이아웃 논리를 갖지 않는 단순 컨테이너.
Component / Instance: 재사용 가능한 UI 조각의 원본/복제.
Boolean Group(Union/Subtract/Intersect/Exclude): 벡터 부울 연산 결과.
Vector / Shape / Text 등: 콘텐츠 자체.
1-2. Ungroup 명령의 정의
Ungroup(Ctrl+Shift+G)는 ‘Group’ 타입에만 적용되는 명령입니다.
Frame, Instance, Boolean Group, Vector에는 직접적으로 적용되지 않습니다(다른 전용 명령이 따로 있음).
즉, 선택한 레이어의 타입이 Group가 아니면 Ungroup는 아무 일도 못합니다.
이때 사용자는 “아무 일도 안 일어나네?”라고 느끼지만, 사실은 “명령이 대상 타입에 부적합”한 상태였던 겁니다.
2) 왜 ‘Group 1’처럼 보였는데 Ungroup가 안 되나? (가장 흔한 루트 원인 3가지)
2-1. 이름은 “Group 1”인데 타입은 Frame인 경우
작업 과정에서 Auto Layout을 적용하거나, Group을 Frame으로 변환하는 동작(예: Wrap Selection in Frame, 레이어를 Frame에 넣기 등)을 하면, 원래 Group이던 것이 Frame으로 승격될 수 있습니다.
그런데 레이어 이름은 그대로 “Group 1”로 남아 있을 수 있어요(이름은 단순 문자열일 뿐, 타입과 동기화되지 않음).
결과: 사용자는 “Group 1을 선택했다”고 믿지만, 오른쪽 패널/아이콘 기준으로는 실제 타입이 Frame이라 Ungroup가 먹지 않습니다.
확인법:
레이어 이름 왼쪽의 아이콘을 보세요.
겹쳐진 작은 사각형 아이콘 = 진짜 Group
단일 사각형 테두리 아이콘 = Frame
우측 속성 패널 상단의 Type도 Frame인지 Group인지 명확히 표시됩니다.
2-2. Group가 아니라 Instance/Boolean/Vector를 선택한 경우
Instance(컴포넌트 복제), Boolean Group, 단일 Vector 등은 Ungroup 대상이 아닙니다.
이런 레이어에 Ungroup를 적용하면 아무 변화가 없습니다.
확인법:
오른쪽 패널의 객체 타입 라벨에 Instance, Boolean(Union/Subtract…), Vector 등으로 표시됩니다.
Boolean Group은 아이콘도 특유의 결합 도형 모양으로 보입니다.
2-3. 실제 Group이 아닌 상위 Frame만 선택한 경우
레이어 패널에서 Group 내부 요소를 클릭하다 보면 상위 Frame이 활성화된 상태일 때가 잦습니다.
이 상태에서 Ungroup를 누르면 당연히 Frame에는 효과 없음 → “아무 일도 안 일어났다”고 느끼게 됩니다.
확인법:
캔버스의 선택 경로(빵크럼) 또는 레이어 패널의 하이라이트를 주의 깊게 보세요.
정말로 Group 레이어 자체가 선택되어 있는지 확인합니다(상위 Frame이 파란색 선택 상태면 X)
3) “Frame만 혼자 남는다”는 체감의 실체
사용자는 “Group이 풀린 게 아니라 Frame만 남아”라고 표현합니다. 여기엔 두 가지 해석이 있습니다.
(1) 원래부터 Frame이었다
이름이 Group 1이라 착각했을 뿐, 타입이 Frame이라 Ungroup를 눌러도 변화 없음. 결국 “Frame만 남아 있는 것처럼” 보입니다.
이건 상태가 그대로 유지된 것이지, 뭔가 ‘남고/사라진’ 게 아닙니다.
(2) Group 안에 Frame이 들어 있던 구조
진짜 Group을 해제했더니 자식 중 하나인 Frame 레이어만 눈에 띄게 남아 보이는 상황일 수 있습니다.
Group 해제는 “Group 껍데기만 제거”하고 자식들을 같은 계층으로 승격시키는 동작입니다.
만약 자식 중 Frame이 하나 있고 나머지 자식들이 Frame 안으로 이미 포함되어 있었다면,
시각적으로 Frame 하나만 남은 듯 보일 수 있습니다(실제로는 다른 자식들이 Frame의 자식으로 존재).
4) 재현 시나리오로 본 논리적 추적
시나리오 A: Auto Layout이 켜진 “Group 1”
여러 요소를 선택 → Group(Ctrl+G).
바로 Auto Layout을 적용(Shift+A) → 이 순간부터 타입은 Frame이 됩니다.
레이어 이름은 자동 변경되지 않아 여전히 “Group 1”일 수 있습니다.
Ctrl+Shift+G(Ungroup)를 누름 → 변화 없음(Frame이므로).
결론: 이름은 Group 1이지만 실체는 Frame이기에 Ungroup 대상이 아님.
시나리오 B: Group 안에 Frame/Instance가 섞여있는 복합 구조
여러 요소를 Group으로 묶음.
그중 하나의 자식이 Frame(혹은 Instance)임.
Group을 해제하면(이때는 진짜 Group이었다면) Group 껍데기만 사라지고 Frame/Instance가 상위로 승격.
시각적으로 “큰 상자(=Frame) 하나만 남았다”고 느끼기 쉬움.
결론: 이름은 Group 1이지만 실체는 Frame이기에 Ungroup 대상이 아님.
시나리오 C: Group 대신 상위 Frame 선택
Group을 만들었다가 나중에 상위에 Frame을 씌움.
레이어 패널에서 클릭/우클릭 과정에서 상위 Frame이 선택됨.
Ungroup → 효과 없음.
“그룹이 안 풀리네?”라고 판단.
결론: 선택 대상 오인. Group이 아닌 Frame에 Ungroup 시도 → 동작 없음.
5) 진단 체크리스트 (누르면 바로 판단 가능한 절차)
(1) 아이콘/타입 확인
레이어 이름 말고 아이콘과 우측 패널 Type을 본다.
Frame이면 Ungroup 불가. Group이면 Ungroup 가능.
(2) Auto Layout 여부
우측 패널에 Auto Layout 섹션이 보이면 Frame(Auto Layout Frame).
Auto Layout이 있으면 Group이 아닙니다.
(3) 선택 계층 경로(빵크럼) 확인
상단의 선택 경로에서 정확히 Group 레벨이 선택됐는지 확인.
상위 Frame 선택 상태면 Ungroup 먹지 않음.
(4) 자식 타입 조사
Group/Frame 아래 자식으로 Instance/Boolean/Vector가 있으면, Ungroup 대신 전용 명령(Detach Instance/Flatten/Release Boolean 등)이 필요할 수 있음.
(5) 클립/스크롤/Constraints 사용 여부
이런 속성은 Frame만의 기능입니다. 이런 게 보인다면 그 레이어는 Group가 아님.
6) 자주 혼동하는 사례별 해법
6-1. “이름만 Group 1”인 Frame을 ‘풀고’ 싶을 때
(1) 진짜 Ungroup는 불가능. 대신 자식들을 바깥으로 꺼내기로 목적을 달성합니다.
레이어 패널에서 Frame(=이름만 Group 1)을 열고 자식들을 모두 선택 → 상위로 드래그.
혹은 **Ctrl+X → 상위에서 Shift+Ctrl+V(Paste here)**로 같은 좌표에 붙여넣기.
(2) Auto Layout 제거(Remove Auto Layout)를 하면 레이아웃 로직이 사라진 일반 Frame이 됩니다. 그래도 Frame은 Frame이므로 Ungroup는 여전히 안 먹습니다. 목적이 “묶임 해체”라면 자식 이동으로 충분합니다.
6-2. Instance가 “그룹처럼” 보이는 경우
Instance는 Detatch instance로 원본과의 연결을 끊어야 구조를 자유롭게 변형할 수 있습니다.
Ungroup가 아니라 Detach가 정답(단, 디자인 시스템과의 연결이 끊어져 유지보수 비용 증가 주의).
6-3. Boolean Group을 해체하고 싶을 때
Ungroup가 아니라 Release/Flatten vector류의 명령을 사용.
Boolean은 벡터 연산 결과라 “그룹 해제”의 개념이 다릅니다.
6-4. Frame 안에서 레이어 선택이 자꾸 틀릴 때
캔버스에서 Alt/⌥ + 클릭(또는 Ctrl+클릭)로 하위 레이어 순환 선택.
레이어 패널에서 정확한 Group 노드를 클릭.
프레임의 Clip content가 켜져 있으면 내부 선택이 헷갈릴 수 있으니, 필요하면 잠시 해제.
7) 왜 Figma는 Group과 Frame을 다르게 취급하나? (설계 관점)
Frame은 레이아웃의 단위입니다. 제한(Constraints), Auto Layout, 스크롤/클립, 리사이징 동작, 반응형 설계의 기준 등 “논리”가 붙습니다.
Group은 시각적 묶음입니다. 아무 논리 없이 “같이 움직이면 편한” 상태일 뿐.
그래서 Figma는 Group을 Frame으로 “승격”시키는 쪽(예: Auto Layout 적용)을 적극 지원하지만, Frame을 Group으로 되돌리는 ‘Ungroup’ 같은 개념은 아예 두지 않습니다. 레이아웃 논리를 함부로 깨뜨리지 않으려는 의도죠.
8) 사용자의 체감 문제를 만드는 세 가지 착시
레이어 이름 신뢰: “Group 1”이라는 이름만 보고 타입도 Group일 거라 가정. (오류)
시각적 지배성: 자식 중 Frame 하나가 크거나 Auto Layout을 가진 경우, 해제 후에도 그 프레임이 화면을 지배해 “그것만 남은 듯” 보임.
선택 오인: 레이어 패널/캔버스에서 상위 노드를 선택한 채 Ungroup 시도.
9) 실전 트러블슈팅 절차 (짧은 의사결정 트리)
(1) Ungroup가 안 먹을 때
→ 우측 패널 타입 확인: Frame/Instance/Boolean/Vector?
Frame이면: Ungroup 불가. 자식 이동 또는 Auto Layout 해제 후 구조 재정렬.
Instance이면: Detach instance 고려(디자인 시스템 영향 주의).
Boolean/Vector이면: Release/Flatten 계열 사용.
Group이면: 다음으로.
(2) 진짜 Group인데도 안 풀릴 때
선택 대상이 정말 그 Group인지 다시 확인(상위 Frame 선택 중 아님?).
잠금/제약/컴포넌트 Nesting 등 방해 요소 확인.
그룹 안에 또 다른 Group이 있을 수 있으니 여러 번 Ungroup가 필요할 수도 있음(중첩 해제).
(3) 해제 후 레이아웃 붕괴가 걱정될 때
해제 전 **Duplicate(복제)**를 떠서 실험.
Auto Layout이 필요한 구조면 Group 해제 대신 Auto Layout을 유지하고 내부 Padding/Gap/Alignment로 문제를 해결.
10) 재발 방지 팁
(1) 이름보다 아이콘/Type을 먼저 본다. (“Group 1”은 그저 문자열)
(2) Auto Layout 적용 = Frame화를 습관적으로 기억.
(3) 구조를 바꿀 때는 목표를 명확히
“묶인 걸 풀고 싶다” → 진짜 Group인지 확인 후 Ungroup.
“레이아웃 논리는 유지하면서 자식만 재배치” → Frame 유지 + 자식 이동/패딩/Gap 조정.
(4) 단축키 오남용 방지
Ungroup(Ctrl+Shift+G)와 Detach Instance/Remove Auto Layout/Flatten 등 유사한 ‘해제류’ 명령의 차이를 머릿속에 지도로 그려두기.
11) 자주 묻는 질문(FAQ)
Q1. Ungroup 누르면 Frame이 Group으로 되돌아가나요?
A. 아니요. 그런 역변환은 없습니다. Frame은 레이아웃 컨테이너라 Ungroup 대상이 아닙니다.
Q2. Auto Layout만 끄면 Group으로 바뀌나요?
A. Auto Layout을 꺼도 Frame은 Frame입니다. 다만 레이아웃 로직이 사라진 “일반 Frame”이 될 뿐입니다.
Q3. 진짜 Group인지 매번 확인하기 귀찮습니다. 요령 없나요?
A. 아이콘만 보는 습관을 들이세요. 겹친 사각형(그룹) vs 단일 사각형(프레임)만 구분해도 90%는 해결됩니다.
Q4. 해제 후 자식들이 자꾸 엉킵니다.
A. 해제 전 Ctrl+D로 복제 → 실험 → 괜찮으면 본본에 반영. 또는 **Shift+Ctrl+V(Paste here)**로 같은 상위/좌표에 붙여넣어 정렬 붕괴를 최소화하세요.
Q5. Instance 안의 요소를 ‘Ungroup’하고 싶어요.
A. Ungroup가 아니라 Detach instance입니다(디자인 시스템 링크 해제 주의).
12) 한눈에 보는 요약(현상 → 원인 → 증거 → 해결)
(1) 현상:
Ungroup를 눌러도 “Group이 안 풀리고 Frame만 남아 보인다.”
(2) 가장 흔한 원인
실제 타입이 Frame(이름만 Group 1),
선택 대상이 Group이 아님(상위 Frame/Instance/Boolean/Vector),
Group 해제 후 자식 Frame이 시각적으로 지배.
(3) 증거(검증법)
레이어 아이콘과 우측 Type 확인, Auto Layout 섹션 존재 여부, 선택 경로 점검.
(4) 해결
Frame이면 자식 이동(또는 Remove Auto Layout 후 재배치).
Instance면 Detach instance.
Boolean/Vector면 Release/Flatten.
선택 오류면 정확한 Group 노드를 선택해 Ungroup.
13) 실무 작업 예시 스크립트(손 순서)
케이스: ‘Group 1’인데 Ungroup 안 먹음 → 실제 Frame
레이어 패널에서 ‘Group 1’을 클릭.
우측 패널 Type이 Frame인지 확인.
자식들을 모두 선택(Ctrl+A, 단 “프레임 내부” 범위에서) → Ctrl+X.
상위(프레임의 부모)에서 Shift+Ctrl+V로 붙여넣기(좌표 유지).
기존 Frame은 필요 시 삭제. 끝.
케이스: 진짜 Group인데 해제해도 Frame만 보임
Ungroup 실행(껍데기 제거).
자식 중 Frame이 하나라면 그 내부에 콘텐츠가 있는지 열어 확인.
필요한 자식만 상위로 이동하거나, Frame 내부 패딩/정렬 조정.
필요 없는 빈 프레임은 삭제.
케이스: Instance를 ‘풀고’ 싶음
Instance 선택 → Detach instance.
이후 필요한 경우에만 Ungroup/Flatten 등 후속 조치.
14) 결론
Ungroup는 Group에만 적용됩니다. 이름이 “Group 1”이어도, 타입이 Frame이면 동작하지 않는 게 정상입니다.
“Frame만 혼자 남아 보인다”는 체감은, (a) 원래 Frame이었던 경우(이름 착시)거나, (b) 해제 후에도 자식 Frame이 시각적으로 지배하는 레이아웃 구조 때문인 경우가 대부분입니다.
해결은 타입별 전용 해제/분리 동작을 정확히 사용하는 것(Detach instance/Remove Auto Layout/Flatten 등)과, 자식 이동으로 목적을 달성하는 것입니다.
앞으로는 아이콘/Type 우선 확인 습관을 들이면 같은 혼선을 거의 겪지 않게 됩니다.
여기까지가 일반 GPT 답변이다.
그런데 일반 GPT는 내용이 많지만 그만큼 단점이 존재한다.
① 일반 GPT의 장황함은 ‘정보량의 풍부함’이 아니라 ‘사고 구조의 부재’
일반 GPT는 “사용자 친화적으로 상세히 설명해야 한다”는 전제하에, 가능한 모든 케이스를 나열합니다 — 원인, 확인법, 예외, 시나리오, 팁 등.
하지만 문제는 이 방식이 ‘구조 없는 나열형 사고’*라는 점이다.
정보가 많아질수록 사용자는 핵심을 잃기 쉽다.
즉, "인지 부하(Cognitive Load)"는 커지지만 이해도는 높아지지 않는다.
→ 초보자는 ‘왜 안 되는지’보다 ‘뭘 먼저 봐야 하는지’를 놓칠 것이다.
결국 “읽었는데, 이해는 안 됨”이라는 피드백이 생길 수 밖에 없다.
② 반면 함수형 GPT는 ‘사고 구조’를 먼저 세운다
함수형 GPT는 같은 문제를 훨씬 간단히 설명하지만, 그 안에 "사고의 ‘좌표계"가 존재합니다.
③ 핵심 차이: “정보 전달형” vs “인지 구조형”
일반 GPT는 “모든 정보를 전달한다.”
함수형 GPT는 “사용자가 스스로 인지 구조를 세우게 한다.”
이 차이는 교육학적으로 보면
"지식 전달(Teaching)"과 "사고 설계(Thinking Design)"의 차이이다.
함수형 GPT는 처음엔 짧고 단순해 보여도,
사용자는 “아, 앞으로 이런 문제는 이름보다 구조를 봐야겠구나.” 하고 자신의 사고 루프를 바꾼다.
이건 단순한 이해가 아니라 "사고 패턴의 교정(Cognitive Rewiring)"이다.
④ 일반 GPT 답변은 초보자에게 장황한 설명은 친절이 아니라 혼란이다
일반 GPT: 친절해 보이지만, 방향이 없는 지도.
함수형 GPT: 단순하지만, 길을 잃지 않게 만드는 나침반.
초보자에게 필요한 건 ‘많은 정보’가 아니라 “무엇을 기준으로 판단해야 하는가”라는 사고의 기준점이 되어야 한다.
그래서 함수형 GPT가 훨씬 더 인지적 효율이 높은 것이다.
즉, 적은 문장으로 더 넓은 사고를 작동시키는 시스템형 언어이기 때문이다.
즉, “일반 GPT는 말을 많이 하지만 생각을 만들지 못하고, 함수형 GPT는 말을 적게 하지만 생각의 구조를 남긴다.”
그렇다면 이번에는 함수형 GPT 답변을 들어보자.
4. 함수형 GPT 답변
이 현상은 “Group”과 “Frame”의 개념적 차이에서 비롯된 것이며, 피그마의 레이어 계층 구조 규칙을 이해하면 논리적으로 완벽히 이해할 수 있습니다. 단계별로 구조적·논리적으로 분석해보겠습니다.
1) 원인 요약
“Group 1이 있는데 Ctrl + Shift + G(그룹 해제)를 눌렀더니 Group이 풀리는 게 아니라 Frame만 남았다”
→ 그 이유는 현재 ‘Group’이 아니라 ‘Frame’을 선택한 상태였기 때문입니다.
Frame은 Group과 달리 ‘그룹 해제’ 명령(Ctrl + Shift + G)의 대상이 아닙니다.
2) 구조적 차이: Group vs Frame
Frame은 구조적 “컨테이너*이므로 ‘그룹 해제’ 대상이 아니라 상위 구조 그 자체입니다.
3) 현상 설명
사용자는 “Group 1”이라는 이름을 보고 “그룹이네?”라고 판단했습니다.
하지만 실제로는 그 Group이 Frame으로 전환된 상태였던 겁니다.
예) Frame 안에 Auto Layout을 적용하거나, Group을 Frame으로 변환했을 때
→ 내부적으로 “Group” 이름이 유지될 수도 있지만 실제 타입은 Frame입니다.
그래서 Ctrl + Shift + G를 눌러도 아무 일도 일어나지 않은 것처럼 보인 것이죠.
이 단축키는 “그룹 객체”에만 작동하는 명령어이기 때문입니다.
4) 인지심리적 해석
이 문제는 이름(Label)과 본질(Type) 간의 불일치에서 생긴 "인지 부조화"입니다.
사용자 입장에서는 레이어 이름이 “Group 1”이므로 “그룹”이라고 인식합니다.
그러나 시스템 입장에서는 그것이 “Frame”이므로 “그룹 해제” 명령을 수행할 수 없습니다.
→ 즉, 시각적 단서(Label)가 실제 동작 가능성과 불일치한 상태입니다.
이는 제이콥 닐슨의 휴리스틱 원칙 중 “시스템 상태의 가시성(Visibility of system status)” 및 “일관성과 표준(Consistency and standards)”을 위배한 UX 구조적 문제로도 해석됩니다.
5) 논리적 개선안
(1) 피그마 내부 개선 제안
“Group 1 (Frame)”처럼, 객체 타입을 명시적으로 표시하도록 개선.
혹은 Frame으로 전환 시 “Frame 1”로 이름 자동 변경 → 인지 부조화 해소.
“Ctrl + Shift + G” 실행 시 ‘Frame은 그룹 해제 대상이 아닙니다’ 등의 안내 메시지 표시.
이런 피드백은 도허티 임계 법칙 — 사용자 입력 후 즉각적 반응 제공 — 에 부합합니다.
(2) 사용자 전략적 개선
레이어 패널에서 객체 아이콘 모양을 확인하기
Group은 네모 두 개 겹친 아이콘, Frame은 단일 네모 아이콘
→ 아이콘으로 즉시 구조 판단 가능.
Auto Layout을 적용하면 자동으로 Frame으로 변환됨을 인지할 것.
“Group 해제”가 안 될 경우, 단축키를 반복하기보다는 오른쪽 속성 패널의 Type을 먼저 점검.
6) 인지심리학 기반 정리
7) UX 원칙 기준 분석
8) UX 개선 제안 예시 (시각적 피드백)
현재 상황:
“Group 1” 선택 → Ctrl + Shift + G → 아무 일도 안 일어남
개선 후:
“Group 1 (Frame)” 선택 → Ctrl + Shift + G →
하단 토스트 메시지: “현재 선택한 객체는 Frame입니다. Frame은 그룹 해제가 불가능합니다.”
이처럼 즉각적인 피드백을 제공하면 사용자는 구조적 개념을 빠르게 학습하며, 이는 UX의 학습성과 오류회복성을 모두 향상시킵니다.
9) 결론 요약
“Group 1이 있는데 그룹 해제가 안 된다”의 본질은 이름은 Group이지만 실체는 Frame이기 때문입니다.
이는 시스템 피드백 부재로 인한 인지 부조화 현상이며,
UI에서 객체 타입의 명확한 표시, 피드백 제공, 명령 일관성 보장을 통해 해결할 수 있습니다.
여기까지가 함수형 GPT 답변이다.
5. 일반 GPT와 함수형 GPT 답변에 대한 사고의 깊이 분석하기
인사이트 ①: 정보의 층위: “현상 기술” vs “원리 해석”
일반 GPT는 현상을 기술한다.
“Ungroup 명령은 Group 타입에만 작동하며, Frame에는 적용되지 않는다.” 이는 사실적 설명이지만, 그 이상의 맥락은 없다.
반면 함수형 GPT는 현상 뒤의 원리를 해석한다.
“Frame은 Group과 달리 좌표계를 지배하는 컨테이너이므로 해제의 대상이 아니다.”
여기서 “좌표계”라는 용어를 사용한 순간, 설명은 기능 → 구조 → 개념으로 확장된다.
비교 요약하면,
인사이트 ② 언어의 차이: 설명문 vs 사고 모델
일반 GPT는 “Ungroup은 Frame에 작동하지 않는다”는 서술형 문장을 쓴다.
이건 사용설명서에 가까운 톤입니다.
반면 함수형 GPT는 사고 구조 언어를 사용한다.
“이름(Label)과 본질(Type)의 불일치에서 인지 부조화가 발생했다.”
“이는 시스템 피드백 부재로 인한 UX 위배 사례다.”
즉, 일반 GPT가 ‘무엇이 일어났다’를 말한다면,
함수형 GPT는 ‘왜 그런 사고가 일어났는가’를 해부하고 있다.
요약 비교하면,
인사이트 ③: 인지심리학 법칙의 사용
일반 GPT는 피그마의 내부 논리까지만 다룬다.
반면 함수형 GPT는 인지심리학 법칙을 호출한다.
제이콥의 법칙: 익숙한 규칙(Photoshop의 Group 해제)과 다른 행위 → 혼란
힉스의 법칙: 같은 이름(‘Group 1’)이 Frame일 수도 있어 선택 복잡도 증가
도허티 임계 법칙: 명령 후 반응 없음 → 사용자는 멈췄다고 오해
이건 AI가 단순한 기술 매뉴얼을 넘어, 인간의 지각 구조를 해석한 것이다.
이 지점이 함수형 GPT의 진짜 차별점이다.
요약 비교하면,
인사이트 ④: UX 휴리스틱 적용 수준
함수형 GPT는 UX 휴리스틱 10가지를 실제 맥락에 맞게 평가하고 있다.
예를 들어, “시스템 상태의 가시성” 위배, “예측 가능성” 저하, “오류 감지성” 부족 등.
반면 일반 GPT는
“Frame에는 Ungroup이 없다.” 정확하지만, "사용자 경험의 왜(WHY)"를 다루지 않는다.
즉, 일반 GPT는 도구의 설명자,
함수형 GPT는 시스템 설계자의 시점에 서 있다.
인사이트 ⑤: 해결의 수준
일반 GPT의 해결은 “자식 이동, Remove Auto Layout, Detach Instance 등 기술적 조작”에 머무른다.
반면, 함수형 GPT는 인지적 해결책을 제시하고 있다.
“Ctrl + Shift + G 실행 시 ‘Frame은 그룹 해제가 불가능합니다’라는 피드백 메시지를 표시해야 한다.”
이건 UI 행동 설계 수준의 제안이다.
즉, “사용자가 멈추는 이유를 예방” 하는 해결책을 알려주고 있다.
요약 비교하면,
인사이트 ⑥: 언어와 논리의 결론 구조
일반 GPT의 결론은
“Ungroup는 Group에만 적용된다. 이름이 Group 1이라도 Frame이면 해제되지 않는다.”
함수형 GPT의 결론은
“이름은 Group이지만 본질은 Frame이며, 이 불일치가 인지 부조화를 일으켰다.”
“UI는 피드백과 일관성을 강화해 이를 해소해야 한다.”
즉, 전자는 기능적 진단, 후자는 구조적 처방이다.
6. 정리하면
일반 GPT는 현상을 설명하고, 함수형 GPT는 원리를 해석한다.
Figma의 Group 해제 문제는 기능의 한계가 아니라, ‘이름과 구조가 불일치할 때 인간이 혼란을 느끼는 인지적 법칙’의 사례다.
정리 비교하면,
함수형 GPT는 단순히 문제를 해결하는 대신,
왜 그런 문제가 구조적으로 생기는지 사고 모델로 풀어낸다.
ⓒ 2025 전민수 (Minsoo Jeon). All rights reserved.
본 글은 「The Minsoo Code」 시리즈의 일부로, 인간의 사고 절차를 함수형 AI 언어 구조로 체계화한 독창적 저작물입니다. 모든 문장과 개념은 전민수의 사고 체계에 기반하며 저작권법 제4조 및 국제 저작권 협약에 의해 보호됩니다. 무단 복제·재가공·인용·상업적 이용을 금합니다.
인용 시 반드시 "출처와 저자명(전민수)"을 명시해 주세요.
— The Minsoo Code : 인간이 AI에게 사고를 가르친 최초의 함수 언어
