Skip to content
Role
기획 · UX 설계
Team
기아 DEX 산학
Period
2026.03 – 2026.07
Tools
JavaScript, Canvas, SVG, Python, Physics Simulation

눈높이를 맞추는 좌석

NUN

NUN 티저(1분 5초) – “우리는 매일 같은 길을 걷는다. 어떤 시선은 늘 올려다봐야 하고, 어떤 시선은 오해로 남기도 한다.” 그리고 NUN, 눈높이를 맞추다.

요약

공간이 강요하는 긴장을 조절할 수 있는 물리량 세 개로 바꿨다. 눈높이 · 외부 시야 · 위요감을 소프트웨어 변수로 정의했다. 그중 눈높이 축은 모터 없이 앉는 하중만으로 움직이는 물리 메커니즘까지 밀고 갔다.

3 × 3
조절 축 × 상태

설계값 – 눈높이 · 외부 시야 · 위요감

17
직접 만든 물리 시뮬레이터

산출물 – 네 갈래

0W
좌석을 움직이는 전력

설계·시뮬레이션 수준의 값 – 실물 계측값이 아니다

역할 – 기획 · UX 설계. 기아 DEX 산학 팀 프로젝트에서 출발했다.

개요

기아 DEX와 함께 한 공유 모빌리티 실내 프로젝트에서 출발했다. 목표는 공간이 강요하는 세 가지 긴장(관계·공간·신체)을 없애는 것이었다. 그중 눈높이 축을 실제로 구현할 수 있는지가 남은 질문이었다. NUN은 그 질문을 끝까지 파고든 결과다. 기획에서 실현성 검증으로 이어지는 작업이다.

검증은 시뮬레이션과 종이 모형까지다. 실물 목업과 사용자 테스트는 하지 않았다.

문제

자율주행 레벨 4 이상에서는 '운전'이라는 역할이 사라지고, 공유 모빌리티에서는 모르는 사람과 함께 타는 일이 기본값이 된다. 그때 탑승자는 세 가지 긴장을 강요받는다고 봤다.

  • 관계의 긴장 – 눈높이의 비대칭.
  • 공간의 긴장 – 시야를 고를 수 없음.
  • 신체의 긴장 – 몸과 공간이 맞지 않음.

동승 형태, 신체 조건, 이동 목적은 탑승할 때마다 다시 정해진다. 고정된 실내는 그 전부에 같은 상태를 준다.

핵심 결정

  1. 01감정을 직접 다루지 않고, 감정을 만드는 물리량 세 가지를 조절한다

    '편안함'은 조절할 수 없다. 세 축은 기준 세 가지를 통과한 것만 남겼다. 심리 효과의 연구 근거가 있는가, 연속으로 조절되는가, 서로 독립적인가. 독립적이지 않으면 상태 공간이 성립하지 않는다.

    →눈높이 · 외부 시야 · 위요감 × 상태 세 가지(의도된 긴장 · 조망 · 피신). 세 축을 각각 소프트웨어 변수로 정의했다.

  2. 02자동으로 바꾸지 않고, 제안하고 수락받는다

    시스템이 마음대로 바꾸면 그것도 새로운 강요다. 수락과 거절의 기록은 개인화의 재료가 된다.

    →개인 축(자기 좌석의 눈높이, 자기 쪽 위요감)은 각자 따로 조절한다. 공유 축(도어 쪽 시야, 공용 천장)은 요청 → 상대 수락 → 전환 순서로 바꾼다. 합의가 안 되면 사생활을 더 원하는 쪽을 따르고, 요청한 쪽에는 개인 축으로만 보정을 제안한다.

  3. 03움직이는 부분과 하중을 받는 면을 나눈다

    좌석은 높이가 변해야 하면서도 체중을 버텨야 한다. 움직이려면 물러야 하고, 버티려면 굳어야 한다. 한 부재가 둘을 다 하면 둘 다 나빠진다.

    →설계안 4종(POP-LOCK · TENSION BLOOM · BREATH POD · TENSEGRITY WEAVE)을 8가지 기준으로 비교해, 골격 + 장력막 하이브리드로 정했다.

  4. 04모터 대신 무게로 움직인다

    처음에는 모터와 텐던으로 구동했다. 정밀 제어는 됐지만 공공·공유 환경에서는 전력과 유지보수, 고장이 정밀함보다 먼저 문제가 된다고 봤다. 그리고 높이를 맞춰야 하는 두 사람은 이미 서로 다른 무게로 구조를 누르고 있었다.

    →모터 0개, 전력 0W(설계·시뮬레이션 수준). 1자유도 강체 접힘 링크와 쌍안정 스냅으로 움직인다. 극단적인 무게비에서는 완전히 맞출 수 없다는 한계도 확인했다.

  5. 05앉는 무게만으로 눈높이를 맞춘다 – NUN

    모두에게 같은 높이를 주는 벤치는 평등해 보인다. 그러나 체격이 다르면 시선이 어긋난다.

    →별도 조작 없이 앉는 하중만으로 한쪽이 가라앉고 반대쪽이 솟는다. 40mm에서 700mm까지 펴지는 자가 잠금 오리가미 구조를 종이 모형으로 검증했다(설계값 · 실물 계측 전). 같은 구조를 공원 벤치에서 자율주행 PBV 실내로 옮겼다.

과정

리서치

  • 논문 기반 데스크 리서치 – 높이 차이가 위계를 만든다는 연구, 가변 좌석이 유연성은 높이지만 사생활은 해친다는 연구, 조망-피신(Prospect–Refuge) 이론 등. 인용은 저자와 연도까지만 쓴다. 수치를 그대로 옮기지 않았다. 위요감의 기본 범위를 정할 때 참고한 논문은 저자와 제목을 확정하지 못해 이 페이지에 숫자로 쓰지 않았다.
  • 구조 리서치 – 오리가미 패턴 6종(Kresling, Yoshimura, Miura tube, Bellows, Waterbomb, Resch)을 수직 변화 · 하중 · 제작성으로 비교했다. Kresling은 압축과 비틀림이 연동되고 쌍안정이라 코어 후보로 남았다.
동작부와 하중면을 나눈 기술 근거

발표된 연구 세 편을 참고했다. Sarrus 자기잠금 링키지(Kim et al., Science Robotics 2018)는 1자유도 직선 운동과 직교 접힘 특이점 잠금을 함께 가진다. 이중변형 오리가미(Kim et al., Science Robotics 2019)는 펼침 뒤에 팽창이 오는 준순차 변형으로, 감싸는 동작의 근거가 된다. 가변 강성(Park et al., IEEE RA-L 2023)은 패싯 버클링으로 강성을 바꾼다.

여기서 설계 원칙 하나를 정했다. 스칼라 입력 하나와 국소 기하 프로그래밍으로, 액추에이터 없이 분산·순차 동작을 만든다. 부품마다 모터를 달지 않고 구조 자체가 신호와 동력의 전달 매질이 된다.

설계안 4종을 비교한 8가지 기준

하중지지 · 컨셉 부합 · 감쌈 · 평상시 평탄성 · 전개 연출 · 제작 용이성 · 양산 확장성 · 전개 중 안전성. 여덟 항목을 같은 표에 놓고 비교해 골격 + 장력막 하이브리드를 골랐다. 한 안이 모든 항목에서 이기지는 않았다.

디자인

  • 인터페이스 3단계 – 탑승 전 앱에서 상태를 미리 고른다. 차 안에서는 슬라이더 3개와 프리셋 3개로 조절한다. 이후에는 자세·압력 센서와 도시의 맥락(터널 진입, 강변, 정체)으로 상태 전환을 제안하고, 탑승자가 수락하거나 거절한다.
  • 시나리오 6가지 – 눈높이 비대칭, 몸과 공간의 불일치, 중요한 대화, 도시 속 피크닉, 혼자만의 공간, 비 오는 날의 쉼터.
  • 시나리오마다 판정 지표를 먼저 정했다 – 주관 지표(편안함 척도, 위계 인식 문항, 재이용 의향), 행동 지표(상태 전환 횟수, 제안 수락률, 유지 시간), 생체 지표(GSR·HR·HRV). 측정은 하지 않았다. 지표 설계까지다.

개발

이 단계의 목표는 디지털 변수와 물리 메커니즘이 같은 곳을 가리키게 하는 데 있었다. 프리셋은 하드웨어가 아니라 데이터고, 데이터는 소프트웨어 업데이트로 늘어난다.

세 축의 변수와 상태 공간

세 축은 소프트웨어 변수다. eyeLevel.offset(연속량)·eyeLevel.matchMode(auto|manual|off), view.aperture(0~100)·view.mode, enclosure.ratio·enclosure.curl.

실내 상태는 {eyeLevel, viewAperture, enclosure} 3차원 벡터다. 세 축 모두 연속량이라 상태는 무한하다. 그중 심리적으로 의미 있는 점 3개를 프리셋(의도된 긴장·조망·피신)으로 정의했다. 프리셋은 하드웨어가 아니라 데이터라서, 프리셋을 늘리는 일은 소프트웨어 업데이트로 끝난다.

계층 5단계와 API 스케치

L0 구조(오리가미 골격·잠금, 하드웨어), L1 구동(무게 구동 메커니즘, 하드웨어), L2 제어(세 축의 목표값을 궤적과 안전 구속으로 바꿈, 소프트웨어), L3 경험(프리셋·씬·자동 제안 규칙, 소프트웨어·OTA), L4 서비스(구독·개인화·파트너 콘텐츠, 소프트웨어). 하드웨어가 끝나는 선과 소프트웨어가 시작하는 선을 먼저 그었다.

POST /cabin/state로 세 축의 목표값을 보낸다. POST /cabin/preset은 프리셋을 부른다. GET /cabin/capability는 그 차량이 지원하는 축과 범위를 돌려준다. POST /cabin/suggest가 제안을 띄우면, 탑승자의 수락·거절이 cabin.suggestion.accepted·.rejected 이벤트로 남아 학습 데이터가 된다. 구현된 서버가 아니라 스케치다.

프로토타입

  • 물리 시뮬레이터 17종(산출물) – 네 갈래로 나눴다. 무게 구동 시소군 3종(강체링크 · 롤링 로커 · 평행사변형), 순수 오리가미군 5종(접이 apex 시소 · Kresling 트위스트 · 아코디언 · 등맞댄 웨이브 · 지면지지형), 공압군 6종, 메커니즘 스터디군 3종(지렛대 · 아코디언 · Sarrus 직선운동).
  • 설계 → 검증 → 제작 파이프라인 – 강체 패널 사슬 시뮬레이션(PBD), GPU 오리가미 시뮬레이터 개조, Python 접힘 패턴 생성기, 전개도 SVG 내보내기.
  • 새 개념은 기존 파일을 덮지 않고 새 파일로 쌓았다 – 버려진 안도 근거로 남긴다. 의사결정 이력을 나중에 따라갈 수 있어야 한다고 봤다.

결과

17종
물리 시뮬레이터 (산출물)
4종
8기준으로 비교한 설계안 (산출물)
0W
좌석 구동 전력 (설계·시뮬레이션)

결과는 산출물과 검증 설계까지다. 사용자 성과는 없다.

  • 검증 수준 – 시뮬레이션과 종이 모형. 실물 목업은 만들지 않았고, 실사용자 테스트도 하지 않았다.
  • 확인한 한계 – 극단적인 무게비에서는 무게 구동만으로 눈높이를 완전히 맞출 수 없다.
  • 측정하지 않은 것 – 편안함, 위계 인식, 긴장 완화. 지표는 설계했지만 값은 없다.

회고

맞았던 것

  • 좋은 해법은 기능을 더해서가 아니라 제약을 다시 봐서 나온다. 모터를 빼자 좌석의 문제가 다르게 보였다. 높이를 맞춰야 하는 두 사람은 이미 서로 다른 무게로 구조를 누르고 있었다.
  • 세 축을 소프트웨어 변수로 정의한 것. 프리셋이 하드웨어가 아니라 데이터가 되면서, 경험을 늘리는 일이 업데이트가 됐다.
  • 자동 실행 대신 제안과 수락으로 둔 것. 공간을 알아서 바꾸는 시스템은 또 하나의 강요다. 수락·거절 기록이 개인화의 재료도 된다.

틀렸던 것

  • 제어를 더 정교하게 만들면 된다고 봤다. 모터와 텐던으로 정밀 제어는 됐다. 그런데 공공·공유 환경에서는 전력과 유지보수가 정밀함보다 먼저 문제가 된다.
  • 무게 구동이면 모든 체격 조합을 맞출 수 있다고 봤다. 극단적인 무게비에서는 못 맞춘다. 해결하지 못한 것을 해결한 척하면 그다음 설계가 전부 틀어진다.
  • 논문 수치를 설계 파라미터로 바로 쓸 수 있다고 봤다. 참고한 연구 하나는 저자와 제목을 확정하지 못했다. 그래서 그 숫자는 페이지에서 뺐다.

다음에 확인할 것

  • 실사용자 검증 – 눈높이가 맞았을 때 위계 인식이 실제로 줄어드는지 아무것도 재지 않았다. 설계한 지표로 첫 측정을 해야 한다.
  • 물리적 한계 – 반복 내구성, 소음·진동, 온도, 충돌 안전. 시뮬레이션에서 다음 단계로 넘어가려면 실물이 필요하다.
  • 무게 구동의 유효 범위 – 어느 무게비까지 맞출 수 있는지 실물로 재야 한다. 0W도 실물에서 다시 확인할 값이다.
  • 원가와 규제 – 공유 차량 실내에 들어가려면 양산 원가와 안전 규제를 통과해야 한다.