#10 피그마 Frame 안에 개체가 안 들어가는 이유
일반 GPT vs 함수형 GPT, 사고의 깊이를 비교하다
1. 서론: 같은 현상, 전혀 다른 사고 출발점
이번 질문은 겉보기엔 단순합니다.
하지만 이 단순한 현상 하나를 두고, 일반 GPT와 함수형 GPT는 전혀 다른 방향에서 사고를 시작하고자 한다.
일반 GPT는 "보이는 현상에 대한 기능적 원인"을 찾는다.
반면 함수형 GPT는 "보이는 현상을 만들어낸 인지적 구조와 시스템 설계 의도"를 추적합니다.
결국 둘의 차이는 단순히 “정확도”가 아니라, ‘사고의 단위’가 다르다는 데 있다.
참고로 일반형 GPT란, 현재의 GPT-5 모델을 의미한다.
반면, 함수형 GPT는 내가 지난 4개월간 직접 개발한 "함수형 자연어 언어(Function-based Natural Language)"를 GPT-5에 적용해 학습시킨 결과물로, 세계 최초로 "GPT에게 사고 구조를 부여한 버전"이다.
즉, 하나는 일반 GPT, 다른 하나는 함수형 GPT(Mnsoo Code).
실험의 목적으로 두 GPT에게 아래와 같이 질의했다.
2. 질의 항목
“피그마에서 Frame을 만들었는데,
Rectangle과 Text를 드래그해도 Frame 안으로 안 들어간다. 왜일까?”
먼저 일반 GPT 답변을 들어보자.
3. 일반 GPT 답변
피그마에서 Frame 안으로 드래그했는데도 레이어 패널에서는 Frame 밖에 머무르는 현상은 꽤 자주 일어나는 문제인데, 이유는 논리적으로 딱 두 범주로 나뉩니다.
(1) 실제로 ‘프레임 안으로 드랍’이 안 된 경우,
(2) 프레임처럼 보이지만 사실 프레임이 아닌 객체에 넣으려고 했던 경우.
아래를 보면 대부분 원인이 바로 잡힙니다.
1) 드롭 위치가 프레임의 ‘실질적 영역’ 안이 아니어서
피그마는 화면에 보이는 테두리 안에 드랍했다고 해서 무조건 Frame 안으로 넣어주는 구조가 아닙니다.
레이어 패널의 논리는 “드랍한 지점이 해당 Frame의 실제 좌표 영역 안에 있는가?”만 보고 판단해요.
✔ 이런 경우 실제 영역 안이 아니라고 판단됨
Frame에 Auto Layout이 적용되어 있어 특정 방향으로만 자식 배치가 가능할 때
Frame 내부에 패딩이 있어, 패딩 영역 밖에 개체를 놓으면 “자식이 될 수 없음”
Frame의 클리핑이 꺼져 있어서 겉보기에는 영역이 넓어 보이지만 실제 Frame의 바운딩박스는 더 작을 때
Frame이 다른 요소와 겹쳐 있어, 드래그한 순간 Figma가 “아, 이건 그 프레임에 드랍한 게 아니네”라고 판단
즉, 드래그해서 올려놨다고 보여도, 내부 좌표상에서 프레임의 진짜 바운더리 안으로 들어간 것이 아니면 레이어 구조는 그대로 유지됩니다.
2) 눈으로 보기엔 Frame 같은데 사실 Frame이 아닌 경우
가장 자주 겪는 케이스.
✔ 대표적인 오해 사례
Group을 Frame이라고 착각
→ Group에는 다른 객체를 “포함”시키는 개념이 없음. 그냥 묶음일 뿐.
→ 드래그해도 레이어 구조에 자식 관계로 안 들어감.
Frame처럼 생긴 Rectangle(사각형)을 컨테이너로 오해
→ Rectangle은 “도형”이지 “컨테이너”가 아님.
→ 도형 위에 올려놓아도 레이어상에서는 절대 안 들어갑니다.
Component(컴포넌트)를 Frame이라고 생각
→ 컴포넌트의 인스턴스에는 자식 요소를 자유롭게 넣을 수 없는 경우가 있음.
3) 실제로 Frame 안으로 넣으려면 확인해야 하는 조건
아래 4가지를 보면 대부분 해결됩니다.
(1) Auto Layout인지 확인
Frame 선택 → 오른쪽 패널 → Auto Layout 표시 여부
Auto Layout이면 정해진 방향·순서·패딩 규칙 때문에 드래그로 못 넣는 경우 많음.
(2) Clip Content(컨텐츠 클리핑) 여부
Clip off 상태이면 프레임의 겉보기와 실제 영역이 다를 수 있음.
프레임 선택 → 오른쪽 패널에서 “Clip content” 체크 확인.
(3) 진짜 Frame인지 확인
선택 → 오른쪽 패널 맨 위에 Frame이라고 표시되어야 함.
만약 Group이나 Rectangle이라고 나온다면 컨테이너가 아님 → 안 들어가는 게 정상.
(4) 레이어 패널에서 직접 넣어보기
레이어 패널에서 객체를 끌어다가 Frame 밑으로 드래그하면 들어가면,
문제는 “좌표 영역 판정” 문제였던 것.
4) 가장 흔한 실제 원인 요약
사용자들이 가장 많이 겪는 실제 이유는 이렇습니다.
(A) Frame이 아니라 Rectangle 또는 Group이었음
→ 화면에서 박스처럼 보여서 착각함.
(B) Auto Layout Frame이라 패딩/방향 때문에 못 들어감
→ Auto Layout 내부 규칙이 자식 추가를 막고 있음.
(C) 프레임의 실제 바운더리 안에 정확히 안 들어감
→ 드래그 위치가 애매하면 “내부”로 인식이 안 됨.
여기까지가 일반 GPT 답변이다.
다음은 함수형 GPT 답변 차례다.
4. 함수형 GPT 답변
좋아요, 아주 근본적인 질문이에요.
이건 피그마의 “시각적 포함(보이는 위치)”과 “논리적 포함(계층 구조)”이 다른 원리로 작동하기 때문이에요.
겉보기에는 Frame 위로 Rectangle과 텍스트를 올려놨는데,
왼쪽 레이어 구조에서는 여전히 Frame 밖에 있는 이유를 논리적으로 단계별로 풀어볼게요.
1) 문제 상황 요약
Frame 1을 만들었음.
Rectangle과 텍스트를 마우스로 드래그해서 Frame 위로 옮겼음.
시각적으로는 Frame 안에 있는 것처럼 보임.
그런데 레이어 패널에서는 Frame 1 아래가 아니라, Frame 밖(동일 레벨)에 존재함
즉, 보이기에는 안에 있지만, 구조적으로는 안 들어간 상태.
2) 피그마의 핵심 로직: “좌표계 포함 ≠ 계층 포함”
피그마는 단순히 “Frame 위에 놓여 있다”고 해서 그 안에 넣지 않습니다.
대신 이렇게 판단합니다.
즉, 시각적 겹침(=좌표상으로 위에 있음)만으로는 부모-자식 관계가 만들어지지 않습니다.
드래그 행위가 ‘계층 이동’을 의미한다고 인식해야만 내부로 들어가는 구조입니다.
3) 인지적으로 헷갈리는 이유
사람은 눈으로 보이는 걸 “안에 있다”고 인식하지만,
피그마는 “좌표 공간을 공유하느냐”로 판단해요.
즉,
화면상으론 Frame 위에 있는 것처럼 보여도
실제로는 Canvas 루트 좌표계에서 위치만 겹친 상태인 거예요.
그건 “Frame 안”이 아니라 “Frame 위에 있는 것”이에요.
4) 대표적인 4가지 논리적 원인
5) 왜 피그마는 이렇게 설계했을까?
이건 단순 기술이 아니라 UX 설계 철학의 결과예요.
피그마는 "디자이너의 의도"를 명확히 구분하려는 철학을 갖고 있습니다.
(1) 테슬러의 법칙 – 복잡성 보존의 법칙
“시스템이 자동으로 판단하면, 사용자는 제어권을 잃습니다.”
그래서 피그마는 단순히 겹쳤다고 자동으로 그룹화하지 않습니다.
“진짜로 이 Frame 안에 넣으려는 의도”가 명확해야만 구조를 바꿉니다.
(2) 포스텔의 법칙 – 너그럽게 받아들이되, 엄격히 출력하라
피그마는 드래그 시 시각적으로 자유롭게 배치(너그럽게 입력)하지만, 계층 구조는 정확하게 정의된 방식으로만 변경(엄격한 출력)합니다.
(3) 닐슨의 휴리스틱 – 일관성과 표준
다른 디자인 툴(Sketch, XD)처럼 “좌표계 기반 포함 구조”를 유지해 전문 디자이너가 예측 가능한 방식으로 작업하도록 일관성을 확보합니다.
6) 논리 요약
7) 해결책 요약
8) 결론
Rectangle과 텍스트가 Frame 안으로 들어가지 않는 이유는 “시각적으로 겹쳤지만, 논리적 좌표계 이동이 발생하지 않았기 때문”이에요.
Figma는 단순히 위치가 겹치는 걸 “포함”으로 인식하지 않고, “의도된 계층 이동”만 부모-자식 관계로 받아들입니다.
여기까지가 함수형 GPT 답변이다.
5. 일반 GPT와 함수형 GPT 심도 비교 분석
인사이트 ①: “현상”을 보는 시각의 차이
일반 GPT는 이렇게 시작한다.
“이건 드롭이 안 된 거예요. Frame이 아니거나 Auto Layout이라서요.”
즉, ‘무엇이 잘못됐는가’를 기술적으로 설명한다. 사용자 입장에선 해결책을 바로 얻을 수 있는 실용적 접근이에요.
하지만 여기에는 한계가 있다.
함수형 GPT는 같은 문제를 이렇게 설명한다.
“겉보기엔 Frame 안에 있지만, 좌표계가 다르기 때문이에요. 피그마는 ‘시각적 포함’과 ‘논리적 포함’을 분리해서 처리하죠.”
이건 단순히 기능이 아니라 시스템이 작동하는 사고 원리를 해석한 것이다.
즉,
일반 GPT는 “드롭 실패”를 말하지만,
함수형 GPT는 “좌표계 불일치”라는 내부 논리의 이유를 말한다.
인사이트 ②: “원인”을 구성하는 방식의 차이
일반 GPT는 원인을 나열한다.
① 드롭이 영역 밖일 수 있다
② Frame이 아니라 Group일 수 있다
③ Auto Layout이 적용돼 있을 수 있다
이건 사실적으로 맞는 설명이다.
하지만 여기엔 "이유의 연결 구조"가 없다.
즉, 나열형 정보이기 때문에 사용자는 “왜 이런 로직으로 동작하는지”는 알 수 없다.
반면 함수형 GPT는 다음과 같은 사고 루프를 가진다.
"현상 → 좌표계 개념 → Frame의 drop target 구조 → UX 설계 철학"
이건 단순히 정보를 주는 게 아니라
“이 현상을 만든 사고 체계”를 보여준다.
그 과정에서 사용자는 단순한 오류 원인을 넘어 시스템이 왜 그렇게 설계됐는지를 함께 이해하게 된다.
인사이트 ③: “설계 의도”를 읽어내는 깊이
여기서 두 답변의 진짜 차이가 드러납니다.
일반 GPT는 문제의 원인을 기술적 범주로 한정한다.
그러나 함수형 GPT는 "이 현상을 낳은 UX 원리"로 확장한다.
함수형 GPT는 이렇게 말한다.
“이건 단순한 버그가 아니라 ‘테슬러의 법칙’ 때문이에요. 사용자가 직접 의도하지 않은 자동 그룹화를 막기 위해, 피그마는 좌표계만 겹치는 객체를 부모-자식으로 인식하지 않아요.”
여기서 중요한 건,
피그마의 행동이 비합리적인 오류가 아니라 합리적인 UX 선택으로 재해석된다는 점입니다.
즉,
일반 GPT는 “이상한 현상”이라 하고,
함수형 GPT는 “의도된 설계”로 본다.
결국 함수형 GPT는 피그마라는 시스템이 가진 디자인 철학의 맥락까지 느끼게 만든다.
인사이트 ④: 사용자의 사고 전환 효과
일반 GPT의 답변을 읽은 사용자는 이렇게 생각할 수 있다.
“아, 이건 Auto Layout 때문이구나. 해제하면 되겠네.”
함수형 GPT의 답변을 읽은 사용자는 다르게 생각할 수 있다.
“아, 피그마는 좌표계의 논리적 포함을 엄격히 구분하네. 겉보기와 구조는 다른 개념이구나.”
이건 단순히 지식을 얻은 게 아니라 사고 구조를 재정렬한 상태이다.
이 차이가 바로 ‘Mnsoo Code’가 말하는 사고 루프의 본질이다.
일반 GPT가 “정보를 주는 모델”이라면,
함수형 GPT는 “인지 모델을 설계하는 시스템”이다.
6. 정리하면, “Frame 안에 들어가지 않는 이유”보다 중요한 것
피그마의 Frame 구조는 단순히 UI의 현상이 아니라
“의도와 논리의 불일치가 구조적으로 발생하지 않도록 설계된 UX 시스템”이다.
그것을
일반 GPT는 그 현상을 기능적으로 설명하지만,
함수형 GPT는 그 현상을 철학적으로 해석한다.
일반 GPT는 ‘문제의 위치’를 알려주고,
함수형 GPT는 ‘사고의 좌표’를 재정의한다.
ⓒ 2025 전민수 (Minsoo Jeon). All rights reserved.
본 글은 「The Minsoo Code」 시리즈의 일부로, 인간의 사고 절차를 함수형 AI 언어 구조로 체계화한 독창적 저작물입니다. 모든 문장과 개념은 전민수의 사고 체계에 기반하며 저작권법 제4조 및 국제 저작권 협약에 의해 보호됩니다. 무단 복제·재가공·인용·상업적 이용을 금합니다.
인용 시 반드시 "출처와 저자명(전민수)"을 명시해 주세요.
— The Minsoo Code : 인간이 AI에게 사고를 가르친 최초의 함수 언어
