ROS의 역사 — 연구실 프레임워크에서 산업 생태계까지

1. ROS의 역사는 왜 배워야 하는가

ROS의 역사를 외우는 목적은 연도를 맞히는 것이 아닙니다. 지금 사용하는 Node, Topic, Package, Distribution, REP와 DDS가 어떤 문제를 해결하기 위해 선택되었는지 이해하는 데 목적이 있습니다.

Software Architecture에는 만들어진 시대의 조건이 남습니다. ROS 1은 2000년대 연구실에서 빠르게 실험하고 Code를 공유하는 데 최적화되었습니다. ROS 2는 그 생태계를 공장, 자동차, 의료, 우주, 다중 Robot과 Embedded System으로 넓히기 위해 다시 설계되었습니다.

따라서 역사를 다음 네 축으로 함께 보아야 합니다.

이 네 축 중 하나만으로는 ROS의 성장을 설명할 수 없습니다. 좋은 Middleware만으로 생태계가 생기지 않고, 훌륭한 Robot 한 대만으로 국제 표준이 만들어지지도 않습니다.

2. ROS 이전 — Robot Software가 섬처럼 존재하던 시대

2000년대 초 Robot 연구자는 새 Hardware를 만들 때마다 Motor Driver, Sensor Interface, Network 통신, Visualization과 Simulation을 반복해서 작성해야 했습니다. 다른 연구실의 Algorithm을 가져와도 Hardware와 Build 환경이 달라 실행하기 어려웠습니다.

ROS가 아무것도 없는 곳에서 갑자기 등장한 것은 아닙니다. 여러 선행 Project가 중요한 생각을 제공했습니다.

• Player/Stage: Network를 통해 Robot Device를 표준 Interface로 다루고, 2D Simulation에서 같은 Client Code를 활용하는 방식을 확산했습니다.
• CARMEN: 이동 Robot Navigation을 여러 Module로 구성하는 경험을 축적했습니다.
• Orocos: Real-time Robot Control Component와 Toolchain에 집중했습니다.
• YARP: 분산된 Robot Software Component의 통신과 Port 개념을 발전시켰습니다.

이들 Project는 “모든 Robot 기능을 하나의 Program에 넣지 말고, 독립 Component를 Interface로 연결하자”는 방향을 공유했습니다. ROS의 독창성은 이 생각을 처음 만든 데만 있지 않습니다. 서로 다른 연구 성과를 Package, Tool, 문서, 배포판과 Community 운영까지 포함한 사용 가능한 전체 생태계로 묶은 데 있습니다.

역사는 흔히 한 명의 천재나 한 회사의 발명 이야기로 단순화됩니다. ROS는 여러 Open Source Robot Framework의 경험, Stanford 연구, Willow Garage의 투자와 전 세계 Contributor가 결합한 결과입니다.

3. Stanford STAIR와 Switchyard — 직접적인 뿌리

2000년대 중반 Stanford AI Lab은 STAIR(Stanford AI Robot) Project를 진행했습니다. 하나의 Robot이 사무실과 가정 환경에서 이동하고 물체를 인식하며 Manipulation을 수행하려면 여러 연구팀의 Software가 동시에 작동해야 했습니다.

Morgan Quigley가 STAIR를 지원하기 위해 개발한 Switchyard는 ROS로 이어지는 직접적인 기술적 뿌리 중 하나입니다. 이 시기에 중요한 문제의식이 선명해졌습니다.

1. 연구자가 새 Algorithm을 시험할 때 통신과 Process 관리부터 다시 만들지 않아야 한다.
2. Python과 C++처럼 언어가 달라도 Data 계약으로 연결되어야 한다.
3. 한 Computer가 아니라 여러 Computer에 기능을 나눌 수 있어야 한다.
4. Hardware Driver와 Algorithm을 느슨하게 결합해야 교체와 재사용이 가능하다.

초기 ROS 논문은 ROS를 전통적인 Operating System이 아니라, 이질적인 Computer Cluster의 Host OS 위에 놓이는 구조화된 통신 계층으로 설명했습니다. 오늘날 “ROS는 OS가 아니라 Middleware와 도구 생태계”라고 설명하는 근거가 초기부터 분명했던 셈입니다.

4. 2007년 Willow Garage — 아이디어가 Platform이 되다

Willow Garage는 Personal Robotics 연구를 대규모로 지원하면서 Stanford에서 발전하던 기술과 인력을 모아 ROS를 본격적인 Open Source Platform으로 키웠습니다. 공식 기록상 ROS의 첫 Commit은 2007년 11월 7일 Willow Garage에서 이루어졌습니다.

Willow Garage의 접근은 단순히 Middleware Code를 공개하는 데 그치지 않았습니다.

• Full-size Mobile Manipulator인 PR2를 개발했습니다.
• Driver, Perception, Navigation, Manipulation과 Visualization Tool을 함께 만들었습니다.
• Source Code와 Package를 Permissive License로 공개했습니다.
• 외부 연구기관이 같은 Hardware와 Software를 사용하도록 지원했습니다.
• Tutorial, Wiki, Mailing List와 Release 체계를 운영했습니다.

이 전략은 Web의 LAMP Stack처럼 Robot 개발에도 공통 기반을 만들려는 시도였습니다. 연구자는 “통신부터 다시 만들기”보다 자신의 연구 문제에 집중할 수 있게 되었습니다.

5. PR2 Beta Program — 공통 Hardware가 만든 Network Effect

2010년 Willow Garage는 PR2 Beta Program의 11개 수혜 기관을 발표했습니다. 참여 기관은 같은 PR2 Hardware를 사용하고 성과를 Open Source로 공개했습니다.

이 사건이 중요한 이유는 Robot Software 재사용의 가장 어려운 변수인 Hardware 차이를 일시적으로 줄였기 때문입니다.

공통 PR2 Hardware
       ↓
같은 Driver · Message · 좌표계
       ↓
한 기관의 Package를 다른 기관이 실행
       ↓
사용자 증가 → Bug Report와 개선 증가
       ↓
더 많은 Package와 사용자 유입

이것이 Network Effect입니다. 사용자가 늘수록 Platform의 가치가 커지고, 가치가 커질수록 다시 사용자가 늘어납니다. Navigation, Perception, TF, RViz, Manipulation 관련 Software는 PR2를 넘어 다른 Robot에도 이식되었습니다.

PR2 자체가 대중적인 상용 Robot이 되지는 않았지만, 공통 Hardware를 통해 Open Source 협업 방식을 증명한 점에서 큰 역사적 역할을 했습니다. 즉 PR2의 가장 오래 남은 산출물은 판매 대수가 아니라 재사용 가능한 Software와 협업 관행이었습니다.

6. 2009년 논문과 2010년 ROS 1.0·배포판

2009년 ICRA Workshop에 발표된 「ROS: an open-source Robot Operating System」은 ROS의 목표와 Architecture를 정리했습니다. 논문은 Hardware 다양성, 대규모 Robot Software의 복잡성, Code 재사용의 어려움을 출발점으로 삼았습니다.

2010년 1월 ROS 1.0이 발표되었고, 같은 해 3월 첫 공식 Distribution인 Box Turtle이 나왔습니다. 8월의 C Turtle은 두 번째 Distribution이었습니다.

Distribution은 단순 Version 번호가 아닙니다. 특정 시점에 함께 동작하도록 검증한 Core와 Package 집합입니다. 이 방식은 빠르게 변하는 수백 개 Repository를 사용자가 설치 가능한 하나의 Release로 묶었습니다.

거북이 이름은 Branding 이상의 의미가 있었다

Box Turtle, C Turtle, Diamondback, Electric, Fuerte처럼 이름이 붙은 Release는 Community가 공통 Upgrade 시점을 인식하게 했습니다. 이후 ROS 1과 ROS 2 모두 Distribution 중심 개발과 지원 정책을 유지했습니다.

Package 생태계가 핵심 제품이었다

ROS의 가치는 Core Middleware의 기능 수보다 다음 조합에서 나왔습니다.

• roscore와 Node Discovery
• Topic, Service, Parameter 통신
• roslaunch를 통한 실행 구성
• rosbag 기록과 재생
• RViz Visualization
• TF 좌표 변환
• Navigation Stack과 Sensor Driver
• Wiki, Q&A, Tutorial과 Package Index

사용자는 하나의 제품이 아니라 서로 연결되는 Modular Ecosystem을 채택했습니다.

7. ROS 1이 연구 생태계에서 성공한 이유

ROS 1의 초기 설계는 당시 목표에 매우 잘 맞았습니다.

느슨한 결합

Node는 상대 Node의 내부 Code가 아니라 Topic 이름과 Message Type만 알면 됩니다. Camera Driver를 바꾸어도 같은 Interface를 유지하면 Perception Node는 그대로 사용할 수 있습니다.

언어와 Machine의 독립성

C++와 Python Node를 연결하고 여러 Linux Computer에 Process를 분산할 수 있었습니다. 연구자는 문제에 맞는 언어와 Library를 선택할 수 있었습니다.

관찰 가능성

CLI, RViz, rqt와 rosbag을 통해 다른 사람이 만든 Node 내부를 수정하지 않고도 입출력을 관찰할 수 있었습니다. Robot 문제는 공간·시간·Hardware가 함께 얽히므로 이 도구의 가치는 매우 컸습니다.

Permissive Open Source

연구기관뿐 아니라 기업도 ROS Code를 제품과 연구에 활용하고 수정할 수 있었습니다. 공개 Package와 상용 개발이 반드시 반대 관계가 아니었습니다.

낮은 재사용 단위

완성 Robot 전체가 아니라 Driver, Message, Algorithm, Visualization Plugin 단위로 가져다 쓸 수 있었습니다. 이 작은 재사용 단위가 다양한 Robot으로 확산될 수 있게 했습니다.

8. 2012년 OSRF — 회사 Project에서 공공재로

Willow Garage는 ROS와 Gazebo가 한 회사 밖의 독립 조직으로 “졸업”해야 장기적으로 성장할 수 있다고 보았습니다. Open Source Robotics Foundation(OSRF)은 2012년 3월 22일 설립되었습니다.

이 변화의 의미는 Code 소유권 이전보다 큽니다.

• 한 Sponsor의 사업 상황과 Project 생존을 분리했습니다.
• Open Source Infrastructure와 Release 업무를 지속할 조직을 만들었습니다.
• 정부, 연구기관과 기업이 중립적인 조직을 통해 협력할 기반을 마련했습니다.
• ROS뿐 아니라 Gazebo와 이후 Open-RMF 같은 Project를 지원했습니다.

OSRF는 이후 Open Robotics라는 Brand로 활동했습니다. 2016년에는 산업 협력을 위한 영리 자회사 OSRC를 만들었고, 2022년 말 OSRC와 Singapore 자회사 사업은 Alphabet의 Intrinsic에 인수되었습니다. 비영리 OSRF 자체와 Open Source Project Governance는 별도로 유지되었습니다.

이 구분은 중요합니다. 회사 인수와 Open Source Project의 소유·운영을 같은 사건으로 오해하면 생태계의 실제 구조를 잘못 판단하게 됩니다.

9. ROSCon과 ROS-Industrial — Community가 넓어지다

ROSCon

첫 ROSCon은 2012년에 열렸습니다. 개발자가 논문 결과만 발표하는 자리가 아니라 실제 Package, 운영 경험, 실패, Tool과 Roadmap을 공유하는 Community Conference가 생겼습니다. 지역 ROSCon도 이어지며 지식 교류가 영어권과 특정 연구기관에만 머물지 않게 되었습니다.

ROS-Industrial

ROS-Industrial은 ROS의 장점을 제조용 Robot, Calibration, Motion Planning과 산업 Hardware에 적용하고 품질과 지원의 간극을 줄이려는 국제 Consortium으로 발전했습니다.

연구 Code와 산업 제품의 요구는 다릅니다. 산업 현장에는 장기 지원, 변경 관리, 안전 규격, 반복 가능한 Build, 보안과 Vendor 책임이 필요합니다. ROS-Industrial의 성장은 “ROS를 연구실 밖에서 쓴다”는 말이 단순 설치가 아니라 Engineering Process의 변화를 요구한다는 사실을 보여 줍니다.

10. 성공이 드러낸 ROS 1의 경계

ROS 1의 한계는 실패 때문에 생긴 것이 아니라 사용 범위가 초기 가정을 넘어섰기 때문에 드러났습니다.

ROS 1의 roscore와 Master는 Node가 서로를 찾도록 단순한 중앙 Registry를 제공했습니다. 연구실에서는 이해하고 설정하기 쉬웠지만, Multi-robot과 장애 격리에서는 제약이 되었습니다.

TCPROS 중심 통신은 일반적인 Data 교환에는 편리했지만, Sensor Stream과 제어 상태마다 Reliability, Deadline, Durability를 다르게 지정하는 표준 QoS Model이 없었습니다. 보안도 신뢰된 Network를 가정했으므로 기본 인증과 접근 제어가 없었습니다.

이 문제를 기존 API 안에서 조금씩 Patch하면 Compatibility는 유지할 수 있지만 구조적 복잡성이 커집니다. ROS Team은 새 사용 사례를 정면으로 다루기 위해 호환성을 깨는 ROS 2를 선택했습니다.

11. 2014년 ROS 2 설계 — 왜 새로 만들었는가

2014년에 작성된 공식 「Why ROS 2?」 문서는 초기 ROS가 상정하지 않았던 새 사용 사례를 제시했습니다.

• 여러 Robot으로 구성된 Team
• 작은 Embedded Platform과 Bare-metal Microcontroller
• Real-time System
• 불안정한 Network
• Production Environment
• Pattern이 복잡한 System과 더 넓은 Platform

여기서 중요한 판단은 “ROS 1이 나빠서 버린다”가 아닙니다. ROS 1 생태계를 계속 지원하면서 새로운 요구를 위한 ROS 2를 병행 개발하는 길을 택했습니다. 이 때문에 오랫동안 두 생태계가 공존했고 ros1_bridge가 Migration을 도왔습니다.

왜 DDS였는가

DDS(Data Distribution Service)는 이미 산업 영역에서 사용되던 Open Standard 기반 Data-centric Middleware였습니다. ROS 2는 DDS/RTPS를 기반으로 다음 능력을 얻고자 했습니다.

• 중앙 Master 없는 분산 Discovery
• Reliability, Durability, Deadline, History 등의 QoS
• 여러 Vendor 구현 사이의 선택 가능성
• DDS Security 표준을 이용한 인증·암호화·접근 제어 기반
• Real-time을 고려할 수 있는 통신 경로

ROS 2는 DDS를 사용자에게 그대로 노출하지 않고 RMW 추상화 계층을 두었습니다. 이것은 특정 Middleware Vendor에 Project 전체가 종속되는 것을 줄이기 위한 Architecture 결정입니다.

DDS를 선택했다고 모든 ROS 2 System이 자동으로 Secure하거나 Real-time이 되는 것은 아닙니다. Security는 설정하고 Key를 관리해야 하며, Real-time은 OS, Executor, Memory, User Code와 Hardware 전체를 함께 설계해야 합니다.

12. 2015~2017년 — Alpha에서 Ardent까지

ROS 2는 한 번에 완성되지 않았습니다. 2015년부터 Alpha Release가 이어졌고 2016년에는 Beta 단계로 발전했습니다. 이 기간에 Client Library, Interface Definition, DDS Mapping, Build, Launch, Logging과 Tooling이 반복적으로 바뀌었습니다.

2017년 12월 8일, 첫 정식 ROS 2 Distribution인 Ardent Apalone이 Release되었습니다. 이는 ROS 2가 완성되었다는 선언보다 Community가 Distribution 단위로 사용하고 개선할 최소 기반이 마련되었다는 뜻에 가깝습니다.

이후 Bouncy, Crystal, Dashing, Eloquent, Foxy, Galactic, Humble, Iron, Jazzy 등 Release가 이어지며 다음이 성숙했습니다.

• rclcpp, rclpy Client Library
• colcon과 ament Build
• Python 기반 Launch
• Lifecycle Node와 Component Composition
• Nav2, MoveIt 2, ros2_control
• SROS2와 DDS Security 통합
• micro-ROS를 통한 MCU 연결
• 다양한 RMW 구현 지원

새 Architecture가 안정적인 생태계가 되려면 Core만 Port해서는 부족합니다. Driver, Visualization, Navigation, Documentation, CI와 교육 자료가 모두 이동해야 하므로 ROS 2 전환에는 여러 해가 필요했습니다.

13. ROS 1 Noetic의 종료 — 단절이 아니라 세대교체

2020년 5월 공개된 Noetic Ninjemys는 ROS 1의 13번째이자 마지막 공식 Distribution이었습니다. Python 3를 지원하고 Ubuntu 20.04를 기반으로 하여 ROS 2 Migration을 준비할 현실적인 마지막 다리가 되었습니다.

Noetic의 공식 EOL(End of Life)은 2025년 5월 31일이었습니다. EOL은 기존 Robot이 그날 갑자기 멈춘다는 뜻이 아닙니다. 다음이 공식적으로 끝난다는 뜻입니다.

• 새 Package Release와 Sync
• 공식 Bug Fix와 Security Update
• 표준 Binary Repository 유지 보수
• Upstream Community의 장기 지원 기대

Legacy ROS 1 System은 이후에도 실행될 수 있지만, 사용 조직이 Patch, OS, Dependency와 Security Risk를 직접 책임져야 합니다. 따라서 Migration 판단은 “지금 동작하는가?”보다 “제품 수명 동안 안전하게 유지할 수 있는가?”를 기준으로 해야 합니다.

ROS 1의 종료는 실패가 아니라, 15년 이상 유지된 생태계가 후속 Architecture로 책임 있게 이동하는 Software Lifecycle의 사례입니다.

14. 2018~2024년 거버넌스 변화 — TSC에서 OSRA로

ROS 2가 기업 제품에 채택되면서 기술 방향을 누가 결정하는지가 더 중요해졌습니다. 2018년 구성된 ROS 2 TSC(Technical Steering Committee)는 Roadmap, Release와 개발 정책을 공개적으로 조율했습니다.

2024년 OSRF는 장기 안정성과 더 넓은 Community 참여를 위해 Open Source Robotics Alliance(OSRA)를 출범시켰습니다. 현재 구조의 핵심은 다음과 같습니다.

OSRF Board
    ↓ 최종 감독
OSRA Technical Governance Committee(TGC)
    ↓ Project별 감독
ROS Project Management Committee(PMC)
    ↓ 일상 운영
Maintainer · Committer · Working Group · Contributor

ROS 2 TSC는 OSRA 전환 과정에서 종료되었고, ROS Project의 일상적 기술 운영은 ROS PMC 구조로 이어졌습니다. OSRA는 회원사의 재정 지원과 Contributor의 Merit-based 참여를 결합하려는 Model입니다.

Governance 변화가 Source Code와 무관해 보일 수 있지만, 기업과 공공기관은 다음을 확인해야 장기 채택을 결정할 수 있습니다.

• Release와 보안 문제를 누가 책임지는가?
• 의사 결정 기록이 공개되는가?
• 한 회사의 사업 철수 후에도 유지되는가?
• 기여한 개인과 조직이 기술 방향에 참여할 통로가 있는가?

Open Source의 지속 가능성은 License만으로 보장되지 않습니다. 사람, Funding, Release Infrastructure와 의사 결정 규칙이 함께 필요합니다.

15. ROS 역사 연대표

16. 역사가 남긴 세 가지 분석

16.1 표준 Interface가 Hardware 표준화보다 먼저 확산될 수 있다

세상의 Robot을 하나의 Hardware로 통일할 수는 없습니다. ROS는 Hardware를 같게 만들기보다 Message, 좌표계, Package와 Tool Interface를 맞추는 길을 택했습니다. PR2는 초기에 공통 Hardware의 힘을 보여 주었지만, ROS의 장기 확산은 다양한 Robot을 수용하는 추상화 덕분이었습니다.

16.2 Prototype 성공 조건과 Product 성공 조건은 다르다

빠른 실험, 느슨한 보안과 재시작 가능한 Process는 연구에서 합리적일 수 있습니다. 제품에서는 Deadline, 권한, 장애 격리, 장기 지원과 Upgrade가 중요합니다. ROS 2는 기능 추가가 아니라 성공 조건의 변화를 반영한 재설계였습니다.

16.3 생태계는 Code보다 넓다

ROS가 오래 유지된 이유는 Repository 수만으로 설명되지 않습니다. 공통 Hardware, Permissive License, 문서, Q&A, Conference, Release Farm, Package Index, Foundation과 Governance가 함께 작동했습니다. 기술 Platform을 평가할 때도 API뿐 아니라 유지 조직과 Community Health를 봐야 합니다.

17. 오늘의 개발자가 역사에서 배울 점

1. ROS 1 관습을 ROS 2에 그대로 옮기기 전에 새 Architecture의 이유를 이해합니다.
2. DDS, QoS, Lifecycle과 Security를 선택 기능이 아니라 제품 요구를 표현하는 수단으로 봅니다.
3. EOL을 설치 문제로만 보지 말고 제품 수명과 Maintenance Risk로 관리합니다.
4. Package 재사용 시 Code뿐 아니라 Message 의미, REP 준수와 Maintenance 상태를 확인합니다.
5. Open Source를 무료 Code로만 소비하지 않고 Issue, 문서, Test나 Funding으로 생태계에 기여합니다.
6. 안전 기능은 ROS Version과 무관하게 Hardware와 System Level에서 독립적으로 검증합니다.

핵심 정리

• ROS는 Player/Stage 같은 선행 Framework, Stanford STAIR·Switchyard와 여러 연구 성과 위에서 발전했습니다.
• Willow Garage는 2007년부터 ROS와 PR2를 함께 개발해 Software, Hardware와 Community를 하나의 Platform으로 만들었습니다.
• 2010년 PR2 Beta Program과 Box Turtle Distribution은 Package 재사용과 Network Effect를 가속했습니다.
• 2012년 설립된 OSRF는 ROS를 특정 회사의 Project에서 장기적인 Open Source 공공재로 옮기는 기반이 되었습니다.
• ROS 1의 성공은 Multi-robot, Embedded, Real-time, Security와 제품 운영이라는 새 요구를 드러냈습니다.
• ROS 2는 2014년 설계를 시작해 DDS, QoS, RMW, Lifecycle과 Security 기반을 도입했고 2017년 Ardent로 첫 정식 배포판을 냈습니다.
• 마지막 ROS 1 배포판 Noetic은 2025년 5월 31일 공식 EOL에 도달했습니다.
• 현재 ROS Project는 OSRF 아래 OSRA의 TGC와 ROS PMC 체계로 운영됩니다.
• ROS의 역사는 Middleware만의 역사가 아니라 Hardware, Community와 Governance가 함께 만든 생태계의 역사입니다.

용어 전에 읽는 공식 참고자료

• ROS: an open-source Robot Operating System (2009)
• Why ROS 2? — ROS 2 Design
• PR2 Beta Recipients Announced — ROS News
• A Decade of Open Robotics — Open Robotics
• Noetic Ninjemys: The Last Official ROS 1 Release — Open Robotics
• ROS Noetic End-of-Life: May 31, 2025 — Open Robotics Discourse
• Announcing the Open Source Robotics Alliance — Open Robotics Discourse

연습 문제

1. ROS 이전의 Player/Stage 같은 Framework가 ROS에 남긴 핵심 생각은 무엇인가요?
2. Stanford STAIR와 Switchyard는 ROS 탄생에 어떤 역할을 했나요?
3. Willow Garage가 Middleware와 PR2 Hardware를 함께 개발한 전략이 효과적이었던 이유를 설명하세요.
4. PR2 Beta Program의 11개 기관이 같은 Hardware를 사용한 것이 Network Effect를 만든 과정을 설명하세요.
5. Distribution이 단순 Version 번호보다 넓은 개념인 이유는 무엇인가요?
6. ROS 1이 연구 환경에서 성공한 이유를 세 가지 쓰세요.
7. OSRF 설립이 ROS의 장기 지속성에 중요했던 이유는 무엇인가요?
8. ROS 1의 한계가 실패가 아니라 성공으로 사용 범위가 넓어진 결과라고 볼 수 있는 이유는 무엇인가요?
9. ROS 2가 기존 API 호환성을 깨면서 DDS를 채택한 이유를 설명하세요.
10. DDS를 사용한다는 사실만으로 Real-time과 Security가 자동 보장되지 않는 이유는 무엇인가요?
11. ROS 2 Ardent의 Release가 생태계에 의미한 것은 무엇인가요?
12. ROS 1 Noetic의 EOL이 기존 Robot이 즉시 작동을 멈춘다는 뜻이 아닌 이유는 무엇인가요?
13. TSC와 현재 OSRA의 TGC·ROS PMC 구조의 관계를 설명하세요.
14. ROS의 발전을 기술만으로 설명할 수 없는 이유를 Hardware, Community, Governance 관점에서 설명하세요.
15. ROS의 역사에서 Prototype과 Product의 성공 조건이 어떻게 달라졌는지 설명하세요.