GPT 로 알아보는 UI 프로그래밍의 발전과정 (feat. Deep research 후기)

 

최근 ChatGPT Pro 버전을 구독하고, 여러 가지 실험을 해보고 있다.

특히 deep research 후기는 일상 블로그에 남겨두었으니 궁금하신 분은 참고해보시면 좋겠다.

 

GPT deep research 체험한다고 30만원 쓴 후기

 

 

그러던 중, 웹 기반 프론트엔드 개발자로서 문득 궁금한 점이 생겼다.

 

우리는 보통 React를 활용해 UI를 구성하면서 자연스럽게 선언형 / 함수형 사고방식을 접하는데,
모바일, 데스크톱, 게임 엔진 등의 분야도 결국 (G) UI를 만든다는 점에서, 과연 어떤 흐름을 거쳐 발전해 왔을까?

그들도 UI 프로그래밍이라는 공통 분모가 있는데,
역사와 이론적 배경은 어떠하며, 어떻게 지금의 선언형 UI로 자리 잡게 되었을까?

 

 

이런 호기심들을 해결하고자,

“UI 프로그래밍의 역사와 이론적 배경, 그리고 선언형 UI가 어떻게 주류가 됐는지”

에 대한 깊이 있는 분석 보고서를 GPT에게 요청해 보았다.

 

이 보고서가 나오기까지 간단한 과정과 개인적 감상을 덧붙여

리뷰 형식으로 정리해 두면 좋겠다는 생각이 들어 이 글을 작성한다.

 

 

GPT와 질문 구체화 하기

 

우선 딥 리서치로 질문하기 전, 내 궁금증을 먼저 구체화시키기로 했다.

그 과정을 GPT와 함께 하면 효과가 배가 된다.

이제는 대략적인 키워드만, 의식의 흐름으로, 카톡 하듯이 질문을 던져도 그럴듯하게 알아듣는 수준까지 온 듯 하다.

o1 pro 모드로 돌려본 질문, 2분30초동안 생각을 한다.

이후 질문 답변을 반복하며 여러 대화를 나누고 생각을 구체화시켰다.

모든 대화를 정리해서 프롬프트를 작성해보기

딥리서치에게 물어보기 위한 프롬프트를 GPT에게 요청한다. 

이 과정을 거치면 조금 더 좋은 결과를 뽑을 수 있더라.

 

최종 질문 프롬프트

[목표 / Goal]

UI 프로그래밍의 핵심 이론과 구현 방식(이벤트 루프, 렌더링 파이프라인, 상태관리, 반응형 모델 등)이 어떻게 발전해 왔으며, 코드 표현 양식(명령형/OOP → 마크업/DSL → 선언형/함수형)의 변화가 어떤 철학적·역사적 배경을 갖고 있는지 깊이 있게 분석하고 싶습니다. 또한 이러한 변화가 현재와 미래의 UI 개발 트렌드에 어떤 영향을 미치고, 다양한 플랫폼(웹, 모바일, 데스크톱, 임베디드, 게임)에서 어떤 공통점과 차이점을 보이는지, 그리고 앞으로 어떤 방향으로 나아갈 것인지 통찰을 얻고자 합니다.

[질의 내용 / Questions]

1. UI 프로그래밍의 근본 요소
   • 이벤트 루프(Event Loop), 렌더링(Rendering) 파이프라인, 상태(State)와 반응성(Reactivity), 동시성(Concurrency) 등 UI 개발에서 ‘필수적으로 고려해야 할’ 핵심 요소와 그 상호작용을 설명해 주세요.
   • 각 요소가 시대적, 기술적 변화에 따라 어떻게 변천되어 왔는지 궁금합니다.
2. 코드 표현 방식의 역사적·철학적 맥락
   • 초기 명령형/객체지향(UI 객체 생성, 속성 설정, 메서드 호출) 방식에서 마크업/DSL(XML, XAML, QML 등) 기반, 그리고 현대적 선언형/함수형(React, SwiftUI, Jetpack Compose, Flutter 등) 접근으로 이어지는 과정을 기술적인 관점뿐 아니라 철학적(왜 이런 접근이 필요했는지) 관점에서 분석해 주세요.
   • 마크업/DSL과 코드가 분리되는 구조, 그리고 선언형 + 함수형 패러다임으로 옮겨간 핵심 동기와 장단점을 다뤄주시면 좋겠습니다.
3. 객체지향(OOP) vs 함수형(FP) 관점의 공존
   • React, SwiftUI, Flutter, Jetpack Compose 등에서 ‘함수형’ 혹은 ‘선언형’을 내세우지만, 실제 구현이나 개발 스타일에는 객체지향 요소도 여전히 존재합니다.
   • 이 둘이 어떤 식으로 혼합·타협되고 있으며, 앞으로 이런 혼합 양식이 계속될지, 혹은 더욱 극단적인 함수형/선언형으로 치우칠 가능성이 있는지 알고 싶습니다.
4. 성능과 최적화, 아키텍처 패턴
   • 선언형 UI가 “상태가 변하면 전체 UI를 다시 그린다”는 단순화된 모델을 제시하는데, 내부적으로 Virtual DOM, Diffing, Reconciliation, Memoization, Dirty Checking 등 다양한 최적화 기법을 사용합니다.
   • 이러한 내부 구조와 아키텍처(Flux/Redux, MVVM, MVU 등)가 어떻게 성능 문제를 해결하고, 대규모 UI 코드베이스를 관리 가능하게 만드는지, 그리고 각각의 트레이드오프는 무엇인지 심층적으로 설명 바랍니다.
5. 플랫폼 간 공통점과 차이점
   • 웹, 모바일(iOS, Android), 데스크톱(. NET, Qt, Electron 등), 임베디드, 게임(Unity, Unreal 등)에서 UI 시스템이 어떻게 유사하거나 다른지, 구체적인 예와 함께 비교해 주세요.
   • 게임 엔진이나 임베디드 디바이스(UI가 제한적인 환경)에서는 선언형/함수형 접근이 어느 정도 자리 잡고 있는지, 혹은 다른 특수한 요구사항이 있는지 궁금합니다.
6. 미래 전망
   • 현재의 “선언형 + 반응형” 패러다임은 앞으로도 주류가 될 가능성이 높은 것으로 보이는데, 더 나아가 어떤 형태로 진화할 것인지 예측해 주세요.
   • 언어·프레임워크 차원에서 DSL이 더욱 강력해지거나, AI 기반 UI 생성/자동화와 결합될 가능성은 어떻게 보시는지 궁금합니다.
7. 추가 자료 및 학술적 참고문헌
   • 위와 같은 변화과정과 구현 방식, 철학적 배경을 심도 있게 다룬 논문, 서적, 기술 블로그, 학계·산업계의 발표자료 등을 추천받고 싶습니다.
   • 각 자료가 주로 다루는 관점(엔지니어링, UX, 함수형 프로그래밍 이론, 소프트웨어 아키텍처 등)도 함께 알려주세요.

[응답 형식 / Format]

• 가급적이면 단계별(역사/철학 → 현재 프레임워크 → 내부 구현/최적화 → 미래 전망)로 구체적인 예시와 함께 설명해 주세요.
• 대답이 길어지면, 각 소주제를 구분하여 인덱스나 소제목을 붙여 주시면 좋겠습니다.
• 인용이나 참고자료(링크, 서적명, 논문명 등)를 함께 제시해 주시면 더욱 좋습니다.

 

이런 식으로 질문 준비가 완료되었다.

 

이제 딥리서치 모드로 질문하기, 분석 전 나에게 되물어본다.

질문을 영어로 바꿔서 하면, 더 좋은 성능/길이를 내는 것 같더라

뽑아낸 프롬프트를 영어로 변환해 딥리서치 모드로 물어보기 시작했다.

 

분석을 시작 전 다시 조금 더 명확한 정보를 달라고 묻는다.

답변 - 분석결과

답변까지 약 10분 정도 걸렸다. 분량은 이정도 (마크다운문법, url, 을뺴고 봐도 10만자는 넘는듯)

10분 동안 에이전트가 인터넷을 돌아다니며, 정보를 검색하고, 읽고, 생각한다.

결과물 링크

UI 프로그래밍 이론과 역사와 미래 - 명령형에서 선언형 UI가 되기까지 | Notion

 

답변 영문을 GPT을 이용해 번역 후 노션에 정리한 링크,

PDF export 시 약 20장의 분량의 아주 긴 글이 작성되었다.

어떻게 한번의 인풋으로 (2번이긴한데..) 이런 아웃풋이 나올까? 정말정말 놀랍고 경이롭다.....

 

다 읽어보면 아주 정말 재밌는 글이지만 (저는 30분 넘게 걸렸어요..)

바쁜 현대인을 위해 맛보기 용 분석과 리뷰를 적어본다.

 

내용 분석

1장

1장 도입부

1장에서는 먼저 UI 프로그래밍의 근본 요소부터 짚어본다.

• 컴퓨터가 UI 요소를 어떻게 그릴지,
• 사용자 입력을 어떻게 감지하고 처리할지,
• 그 입력에 따라 화면을 어떻게 갱신할지,
• 그리고 이 모든 과정이 동시에 일어날 때 어떻게 관리할지

를 살펴본다.

 

결국 UI 프로그래밍이란, 바로 이 문제들을 효율적으로 해결하는 작업이다.

 

우리가 종종 접하는 task queue, repaint, reflow 등의 개념들은,

사실상 “UI 요소를 어떻게 그리고, 어떻게 반영할지” 같은

UI 프로그래밍의 핵심 문제들이 브라우저 내부에 구현된 사례라는 것을 떠올리게 된다.

 

1장의 정리 부분

 

1장에서는 UI 프로그래밍의 근본 요소와 이들이 어떻게 발전해 왔는지를 짚으면서,

결국 그것이 현대 선언형 UI프로그래밍으로 전환하는 배경이 되었다고 설명한다.

 

2장

2장 도입부

2장에서는 UI를 코드로 나타내는 방식에 대한 역사적 배경을 살펴본다.

과거 Java(Swing) 나 PyQt를 사용해 본 경험이 있었는데,

이들은 아래처럼 명령형으로 UI 위젯을 만들고 배치해야 했다.

// java 
Button btn = new Button("Click me");
btn.setText("Hello");
panel.add(btn);

// pyqt
button = QPushButton("Click me")
layout.addWidget(button)

 

 

이처럼 객체를 직접 생성하고, 속성을 설정한 뒤, 패널(레이아웃)에 하나씩 추가하는 작업은,

UI 구조가 코드 여러 곳에 흩어지기 쉽고, 규모가 커질수록 “UI가 실제로 어떻게 생겼는지” 한눈에 파악하기 어려웠다.

 

반면, 마크업(HTML/XML) 기반 접근 방식이 확산되면서,

<div>
  <button>Hello</button>
</div>

 

 

처럼 선언적으로 UI 구조를 서술하고, 스타일이나 로직은 다른 영역에서 처리할 수 있게 되었다.

이건 마치 Android XML 레이아웃이나 iOS 스토리보드, 웹의 HTML+CSS와 유사하며, 명령형 코드보다 한결 이해하기 쉬웠다.

 

이후 React나 Vue, Flutter, Jetpack Compose 등에서

“상태 -> UI”를 강조하는 완전한 선언형 패러다임이 등장했다. 

"React(2013)는 “UI는 상태의 순수 함수이다(UI = f(state))”라는 아이디어를 대중화"  1.3 절에 존재

 

 

2장에서는 이 명령형 -> 마크업(DSL) -> 선언형 전환 과정에서,

각각이 어떤 문제를 해결했고, 어떤 철학을 반영했는지를 짚어준다.

 

이처럼 UI를 명령형 코드에서 마크업/DSL로, 그리고 완전한 선언형으로까지 확장하는 흐름은,

현대 UI 프로그래밍의 중요한 발판이 되었다.

2장의 마무리 부분 중

 

3장 

3장의 도입부

3장은 현대 선언형 UI에서의 FP(Functional Programming)와

OOP(Object-Oriented Programming)의 혼합사례에 대해서 설명한다.

 

개발자에게 노출되는 인터페이스는 FP , 내부 구현은 OOP 스타일로 정리하며,

객체지향형 인프라 위 선언형 UI가 동작한다고 이야기한다.

 

이런 실용적 결합 사이에서 앞으로도 이런 혼합 접근이 유지될 가능성이 크다고 말한다.

 

 

 

4장에서는 선언형 UI가 지닌 핵심 과제

즉, 상태가 변할 때마다 “전체를 다시 그리는” 방식의 성능 문제를 어떻게 해결했는지 다룬다. 

(실제로 해당 알고리즘을 자세히 다루지는 않고 소개만 한다)

 

선언형 모델에서는 UI가 “현재 상태의 순수 함수”라는 관점으로 설계되기에,

이론상 상태가 조금이라도 바뀌면 해당 UI 부분(또는 전체)을 다시 렌더링해야 한다.

 

이 방식은 개발자에게 단순한 코딩 경험을 제공하지만,

아무런 최적화를 적용하지 않으면 크고 복잡한 화면에서 큰 오버헤드를 초래할 수 있다.

 

이를 방지하기 위해,

프레임워크 설계자들은 Virtual DOM, diff 알고리즘, Reconciliation 등 다양한 기법을 고안했다.

 

뿐만 아니라, Flux/Redux, MVVM, MVU 같은 상태 관리 아키텍처도 개발되어,

“상태와 UI가 어떻게 소통해야 하는지”를 체계적으로 정의해 주었다.

 

 

이 장을 읽고 나니, 기존에 어렵게 느껴졌던

React의 가상 DOM과 diff 알고리즘이 어떤 역사를 거쳐 탄생했고, 왜 필요한지 조금 더 명확히 이해하게 되었다.

 

과거 UI 프로그래밍의 배경과 역사를 따라오다 보니, 결국 “상태가 바뀌면 UI를 재계산한다”는 아이디어가

어떻게 현실화될 수 있었는지 실감할 수 있었달까. 여러 부분이 퍼즐처럼 맞아떨어지는 느낌이다.

 

 

4.1 의 마무리 구절 / 이런 최적화 덕분에 선언형 UI는 “전체를 다시 그리는 것 같은 직관적 모델”을 유지하면서도 실제 성능 문제가 없도록 할 수 있었다.

 

5장

5장은 다양한 분야의 UI 프로그래밍 발전 사례들을 제시한다. 

 

5장 게임 클라이언트 예시

특히 게임 클라이언트에서 "즉시모드", "유지모드"라는 부분이 흥미로웠던 기억이 있다.

 

5장의 결론 부분

5장의 결론은 이러하다. 

 

6장

6장의 도입부

 

React, Svelte의 컴파일 이야기가 언급된다.

예측 기반 렌더링: 사용자 행동을 미리 예측해 필요한 UI를 사전에 렌더링 하는 연구도 활발합니다.

 

이 부분은 정말 흥미로웠다. 통계 기반 pre-rendering?

 

 

또 GUI를 넘어선 AR/VR , 음성 UI 등의 새로운 UI 형태,

피그마 플러그인과 같은 Design To Code, 자연어 UI 생성과 같은 현재 유행하는 것들에 대한 언급도 존재한다.

 

 

선언형 패러다임을 AI와 결합시켜 

"무엇을 달성해야 하는가"만 정의 후 구현은 자동화에 맡긴다

 

라는 구절도 인상 깊었다.

6장의 결론

 

후기

처음엔 “AI한테 내 궁금증을 가볍게 한 번 던져보자” 정도의 사소한 생각에서 출발했는데,

막상 진행하다 보니 20장이 넘는 보고서를 끌어낼 줄은 전혀 예상 못 했다.

 

작은 호기심이 이렇게 깊어질 수 있다니, 그 과정을 지켜보는 내내 상당히 흥미롭고 즐거웠다.

 

이제는 원본 출처를 함께 명시해 주긴 하지만,

여전히 세세한 부분에서 잘못된 정보나 오래된 데이터를 섞어 쓰는 경우가 종종 있었다.

 

그런데도 AI가 본문 내에 원문 링크나 출처를 같이 제시해 주니까,

교차 검증하는 수고가 오히려 조금은 덜어지는 느낌이었다.

 

물론 아직은 내가 직접 확인하고 보완해야 하는 부분이 남아있긴 하지만,

적어도 어디서 더 찾아봐야 할지가 뚜렷해진 점이 긍정적이었다.

 

 

한편, 이런 경험을 하면서

“앞으로 이 AI를 어떻게 다루고, 무엇을 물어볼지, 어떤 식으로 새 지식을 습득해 나갈지”

에 대해 많이 생각하게 되었다.

 

기술이 워낙 빠르게 변하는데,

이런 도구가 등장함으로써

학습과 탐구 방법론 자체가 확 바뀔 가능성이 크지 않을까 하는 기대감도 생긴다.

 

개발자든, 연구자든, 혹은 단순 호기심을 가진 사람이든

 

누구나 폭넓은 정보를 빠르게 얻고,

그걸 기반으로 새로운 시도를 해볼 수 있는 환경이 열리는 것 같다는 생각이 든다.

 

 

그래서 앞으로도 이렇게 AI와 함께 다양한 주제에 대해 심도 있게 파고들어 보고,

그 과정에서 나온 의견, 결과물 등을 공유해 볼 예정이다.

 

개인적으로는 “과연 내가 이 도구를 어디까지 활용할 수 있을까?”

하는 궁금증과 설렘이 조금씩 커져 가고 있다.

 

여튼, 이 변화하는 시대에 이런 좋은 도구들이 더 발전하는 모습을 보는 게 정말 기대된다.