Scientia Conditorium

[책리뷰] 레트로의 유니티 성능 최적화

크썸 — Sun, 29 Mar 2026 21:44:33 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

[책리뷰] 레트로의 유니티 성능 최적화

https://www.hanbit.co.kr/store/books/look.php?p_code=B4508580257

전반적인 소감 및 마음에 드는 부분

그래픽 프로그래밍 관련 업계에서 일하고 있기 때문에 이 책은 굉장히 마음에 들었다. 최근 개발 추세를 보면 생산성이다 뭐다 하면서 일단 빠르게 개발하는 것에 초점을 맞추고 있다. 여기까지는 괜찮지만 그 다음이 문제다. 우선 결과물을 내놓고 성능이 안 좋으면 컴퓨터 사양을 더 높이라고 한다. 즉 프로그램, 앱의 성능을 높이거나 최적화 하는 방향이 아니라 구동시키는 컴퓨터, 하드웨어의 성능을 더 높이라고들 한다. 이런 방식은 느린 로딩, 버벅임, 잦은 프레임 드랍 등으로 결국 사용 불가로 이어지게 된다. 사실상 저사양 기기 사용자, 저속 네트워크 사용자, 예산이 적은 사용자들을 버리겠다는 말이다. 또한 유지보수 역시 어려워지기 때문에 사업적으로도 손해로 이어진다고 본다.

따라서 AI를 이용해 빠른 결과물을 내놓는 책이 만연한 요즘, 최적화라는 근본 서적이 나와서 정말 마음에 들었다. 이건 AI에도 적용시킬 수 있는데 더 적은 메모리, 더 빠른 알고리즘, 더 성능 좋은 프로그램은 AI 토큰 사용 시간/비용을 줄일 수 있기 때문이다. 게다가 이 책은 단순히 유니티 프로파일러 사용 방법을 알려주는 것이 아니라 병목 현상 분석부터 실질적인 해결까지 이어지는 올바른 접근 방식과 성능 최적화의 본질을 제대로 알려주고 있다.

대상 독자 및 책 난이도

책 제목에도 유니티가 포함되어 있듯이 기본적으로는 유니티를 활용해 실제 프로젝트를 개발하고 있으며, 성능 문제를 체계적으로 분석하고 해결하고 하는 개발자를 대상으로 한다. 저자가 말한 대상 독자는 다음과 같다.

유니티로 게임을 개발한 경험은 있으나 프레임 드롭, 메모리 증가, 로딩 지연과 같은 성능 문제의 원인을 명확히 설명하기 어려운 개발자
프로파일러를 사용해본 경험은 있지만 수집된 데이터를 어떻게 해석하고 최적화로 연결해야 할지 막막했던 개발자
감에 의존한 최적화가 아니라 지표와 근거를 기반으로 성능 문제를 정의하고 개선하고자 하는 실무 개발자
모바일, 콘솔, PC 등 다양한 플랫폼 환경에서 유니티 프로젝트의 성능 안정성을 확보해야 하는 개발자

그러나 유니티와 상관없이 그래픽 프로그래밍을 다루는 개발자라면 한 번쯤은 읽어볼 만하다고 생각한다. 최적화 대상이 유니티여서 그렇지 책에서 설명하는 내용은 그래픽 프로그래밍 분야 전부 동일하게 적용되기 때문이다. 특히 3장 스레드와 병목, 7장 메모리 구조의 이해는 반드시 읽어보았으면 한다.

예를 들어 챕터13을 보면 최적화 방법 중 하나의 오브젝트 풀 기법을 설명하고 있다. 오브젝트를 미리 많이 생성해두어서 생성/파괴 과정을 최대한 줄여서 FPS를 높이는 방법 중 하나다. 이런 기법은 특정 도구를 써야지만 사용할 수 있는 것이 아니기 엔진 프로그머들은 알아두면 좋은 내용이다.

다루는 내용과 범위

프로파일러 기본 도구가 유니티와 iOS에 맞춰져있긴 하지만 어차피 대부분의 프로파일러 도구들이 비슷하기 때문에 큰 상관없이 볼 수 있다. 중요한 것은 해당 프로파일러 도구들을 이용해 성능 측정 및 최적화를 어떻게 하는지를 봐야한다.

최적화의 기본 개념과 접근법
프로파일링과 데이터 분석
메모리 구조와 관리 전략
그래픽스 최적화
CPU와 스크립트 최적화
프로젝트 최적화

6장 챕터 설명하는 페이지를 보면 각 OS별로 어떤 GPU 프로파일러를 대표적으로 사용하는지 알려준다. 책에서 설명은 iOS · macOS 환경에서 사용하는 Xcode Metal 디버거를 활용했지만, 윈도우나 안드로이드라면 다른 프로파일러를 사용하면 된다.

결론

성능 최적화는 단순히 저사양 기기 사용자, 저속 네트워크 사용자, 예산이 적은 사용자들을 위한 것이 아니다. 예를 들어 성능 최적화를 통해 기존에 10가지 기능밖에 없는 프로그램이 100가지 기능을 가질 수 있게 될 수도 있다. AI 토큰을 사용할 때 서버 이용 시간이 1분이였던 것이 최적화를 통해 100ms로 줄어든다면, 그만큼 서버 이용 비용을 아낄 수 있게 된다. 아무리 AI 등장으로 개발 방법이 바뀌고 있다고 하더라도 근본적인 개발론은 바뀌지 않을 것이라 본다. 여기서 말하는 근본적인 개발론은 오랫 시간 동안 축척되어온 소프트웨어 개발론, 문제를 분석하고 해결하는 전문가의 사고 방식이다. 이 책은 성능 최적화에 대한 전문가의 사고 방식을 기를 수 있는 아주 좋은 참고서이다.

[책리뷰] 러스트로 갈아타기

크썸 — Mon, 2 Mar 2026 19:14:48 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."

[책리뷰] 러스트로 갈아타기 - 레거시 코드는 살리고 성능은 높이는 단계별 리팩터링 전략

전반적인 소감 및 마음에 드는 부분

소위 RIIR(Rewrite It In Rust) 이라는 밈이 있다. 말 그대로 모든 것을 러스트로 다시 재작성하라는 얘기다. 러스트가 메모리 안전성면에서 뛰어나니 다시 재작성하고 싶기는 한데, 러스트 기본 문법을 모르니 어떻게 시작해야할지 막막했다. 그런 와중에 이 책이 엄청나게 도움됐다. 저자 말대로 이 책은 기존 시스템을 분해하고 다시 작성하는 데 초점을 맞춘 언어를 활용해, 그런 상황에서 유용한 여러 패턴을 제공하는 것이다. 따라서 RIIR에 관심있는 프로그래머에게 딱 어울리는 책이다. 다른 언어와 비교하여 설명해야 하기 때문에 처음에 러스트 문법에 대해 다루기는 하지만 기본적으로 이미 러스트 언어를 조금 알고 있다고 가정하고 진행된다. 애시당초 어떤 언어로 작성된 프로젝트를 러스트로 전환하려는 시도를 하려는 것부터 초보가 아니기 때문에 당연한 가정이다.

대상 독자 및 책 난이도

이 책은 러스트가 아닌 다른 언어로 애플리케이션을 다년간 개발한 경험이 있고 애플리케이션의 성능, 안전성, 유지 보수성을 개선할 방법을 찾고 있는 프로그래머를 대상으로 한다. 다른 언어라고는 했지만 주로 C/C++과 파이썬 언어를 중심으로 다룬다. 따라서 각 언어에 대한 기본적인 문법 설명은 없다고 보면 된다. 구조체(struct), 변수 선언이 어떻고, 함수는 어떻게 해야되는지 등등에 대한 설명이 없다는 의미다. 숙련된 프로그래머라면 대략적인 구조만 보고 문법이 비슷하니 대강 파악할 수 있을 것이다. 따라서 단순히 러스트를 익히고 싶은 주니어급 보단 어느 정도 개발 경험이 있는 시니어급 프로그래머가 대상 독자다.

Rust에서 소유권 개념을 시각화하여 설명

위 이미지는 책에서 알려준 러스트의 소유권 개념을 시각화한 이미지다. 코드로 설명하는 것보다 훨씬 더 이해하기 쉽다. 이를 확실하게 이해하기 위해선 러스트 기본 문법을 하나도 몰라도 오른쪽에 적힌 코드가 대충 어떤 일을 하는지 알 수는 있어야 한다.

다루는 내용과 범위

크게 3파트로 나뉜다. 러스트에 대한 설명으로 1~2장을 시작하지만 이 부분은 건너뛴다.

3~4장에서 C/C++과 같은 정적 타입 언어를, 6~8장에서 파이썬과 같은 동적 타입 언어를, 9~10장에서 웹어셈블리를 통한 고급 러스트 활용법을 다룬다. 러스트 언어가 주력으로 밀고있는 특징은 메모리 안전성과 성능이다. 따라서 C/C++보다 메모리 안전성이 뛰어나니 이를 변환하는 방법, 파이썬보다 성능이 뛰어나니 이를 변환하는 방법으로 나뉜 것이다. 이를 위해 FFI와 PyO3를 사용한다.

러스트 코드를 기존 애플리케이션에 통합되는 두 가지 주요 기술을 소개한다.

프로그램에서 러스트 함수를 직접 호출하기(C FFI / PyO3 크레이트 활용)
네트워크를 통한 러스트 서비스 통신

실습 환경은 리눅스 운영체제를 구동하는 컴퓨터 또는 가상머신으로 진행되는데, 윈도우나 맥에서 진행해도 상관없다.

게다가 전체적인 구조도 역시 그림으로 설명해주기 때문에 이해하기 편하다.

결론

RIIR 생각이 있지만 러스트에 대해 아는 것이 없다면 이 책을 적극 추천한다. 단순히 러스트 기본 서적을 보고 다시 작성하는 것보다 이 책을 통해 러스트 기본 개념을 익히고 어떻게 리팩토링 하면 되는지 알면 훨씬 더 수월하다. 다만 아쉬운 점은 C/C++에서 러스트로 갈아타는 이유가 메모리 안전성 때문이라고 하지만 이에 대한 내용이 조금 부족하다. 예를 들어 C/C++에서는 이런 코드를 작성하면 메모리 누수가 날 수 있지만 이걸 러스트로 바꾸면 바로 알 수 있다! 하는 부분은 없다. 단순히 C/C++ 코드를 러스트로 갈아탈 때 어떤 점을 주의해야 하는지에 초점을 맞추고 있다. 책에서 중점적으로 다루는 내용은 러스트로 전환하는 방법이기 때문에 이 이상 깊게 들어갈 필요는 없긴 하다. 어쨌든 정리하자면 러스트로 전환을 고민하는 프로그래머들보다는 러스트로 전환을 결정한 프로그래머들에게 꼭 필요한 책이다.

[책리뷰] 관성 끊기(Do One Thing Different)

크썸 — Fri, 20 Feb 2026 00:32:50 +0900

※ 이 서평은 터닝페이지 출판사로부터 책을 제공받아 작성되었습니다.

[책리뷰] 관성 끊기

전반적인 소감 및 마음에 드는 부분

사례가 굉장히 많다. 보통 이런 부류의 책은 대표적인 사례 1개만 가지고 마치 전체를 통달한 듯한 주장을 펼치는데, 이 책에서는 여러 사례들을 계속 소개한다. 그 덕분에 술술 읽게 된다. 사례는 무수히 많지만 결국 저자가 말하는 것은 동일하다. 해결 지향적 접근법으로 문제를 조금씩 천천히 하나하나 해결해나가자는 것이다. 물론 어떤 사례는 너무 과장된 것 아닌가 싶은 내용도 있다. 대표적으로 이 접근법으로 알레르기를 고쳤다는 내용도 있긴 하다. 저자가 말하는 해결 지향적 접근법의 요점을 다음과 같다.

반복되는 문제의 패턴에 주목할 것(관찰할 것)
그 중 바꿀 수 있는 일이 있다면 무엇이든 바꿀 것(아주 사소한 것이라도 뭐든지)
일이 잘 풀렸을 때 했던 행동을 떠올리고 그것을 더 많이 반복할 것

즉 반복되는 문제 속에서 아주 조금씩 해결할 수 있는 것들부터 하나씩 해결해나가자는 것이다.

대상 독자 및 책 난이도

매번 똑같은 결심을 하고 실패하거나, 똑같은 문제로 계속해서 고통받고 있는 사람들이 대상 독자다.

삶이 무기력해지고 내 삶에 조그마한 변화를 주고 싶다는 생각이 드는 사람들도 이 책이 도움이 될 것이다.

위에서 말한대로 사례가 굉장히 많기 때문에 책은 금방 읽을 수 있으며 어려운 내용은 하나도 없다.

다루는 내용과 범위

책 구성은 다음과 같다.

문제 대응 방식 바꾸기
1. 패턴 깨기
2. 효과 있는 것 시도하기
문제를 바라보는 관점 바꾸기
1. 과거와 감정에서 벗어나기
2. 주의 전환하기
3. 문제 해결을 위해 미래 이용하기
4. 문제적 신념을 해결 지향적 생각으로 바꾸기
5. 영성 이용하기
해결 지향적 접근법 구체적으로 적용하기
1. 해결 지향적 관계
2. 해결 지향적 성생활
3. 풀리지 않은 일을 해결하고 문제 예방 의식 행하기
4. 해결 지향적 삶

책에서 다루는 내용은 크게 보면 한 가지 주제로 동일하다. 반복되는 문제에 대해 하나씩, 조금씩 다르게 행동해서 해결해보자는 것이다.

결론

책 제목이 아쉽다. 영문 제목은 Do one thing different로 '하나만 다르게 행동하라' 정도로 번역된다. 이 책의 내용과 가장 의미있는 국내 서적을 꼽으라면 이민규 교수님의 '1%만 바꿔도 인생이 달라진다'가 있겠다. 왜 '관성 끊기'라고 번역되었는지는 책을 읽다보면 이해하게 된다. '관성'이라하면 쉽게 말해 그대로 유지하려는 성질을 의미한다. 만약 어떤 문제로 오랫동안 고민하고 있거나 고통스러워할 때, 관성을 끊으라는 것이다. 즉 어떤 문제로 고민하거나 고통스러워 하는 그 행동 자체를 끊으라는 의미에서 '관성 끊기'가 나왔다고 생각한다. 이 말 자체가 책 내용 전체를 아우르는 말이긴 하다. 그러나 제목만 봐서는 한번에 어떤 내용인지 파악하기 힘들기 때문에 약간은 아쉽지 않나라는 생각을 해본다.

[책리뷰] 유니티와 OpenAI API로 만드는 인공지능 NPC

크썸 — Sun, 1 Feb 2026 18:12:18 +0900

※ 이 서평은 제이펍 출판사로부터 책을 제공받아 작성되었습니다.

[책리뷰] 유니티와 OpenAI API로 만드는 인공지능 NPC

전반적인 소감 및 마음에 드는 부분

불과 몇년 전까지만 해도 유니티에 인공지능을 넣는다고 하면 하나하나 개발하는 형태를 떠올렸다. 예를 들어 유니티 게임 AI프로그래밍 책을 보면 유한 상태 기계 개념과 랜덤, 확률의 활용 방법, 센싱 기술의 구현 방식, 길 찾기 알고리즘 적용, 행동 트리의 활용, 퍼지 로직 등등 이런 것들을 전부 구현해야 했다. 그러나 이제는 OpenAI API 연동만으로 진짜 상호작용 하듯이 거의 모든 경우를 다룬다고 보면 되겠다.

책에서는 OpenAI API Key 토큰 비용에 기본 금액인 10달러를 세팅하고 사용하기를 권장하고 있다. 그러나 개인적으로는 이런 10달러조차 부담되고 어차피 API 사용 방법을 익히는 학습이 목적이기 때문에 그냥 무료 계정으로 제한된 상태에서 사용하는 것을 추천한다. OpenAI의 정책에 따르면 일부 모델에 대해 API 사용 데이터를 학습 목적으로 공유할 경우, 매일 100만 개의 무료 토큰을 제공한다는 소식이 있다. 더 많은 토큰을 사용하고 싶다면 이용해보는 것도 좋아보인다. 물론 이런 정책들은 언제 어떻게 바뀔지 모르기 때문에 책에서 알려주기에는 부담이 너무 크니 제외된 것으로 보인다. 여담으로 100만토큰이면 문장을 구성하는 수에 따라 다르겠지만 한국어로 대충 2만 문장 정도라고 생각하면 편하다.

서평 쓸때마다 말하는거지만 쓸데없는 기본 문법 설명이나 인터페이스 설명이 없어서 굉장히 좋다. 예를 들어 굉장히 안 좋은 책들은 C# 기본 문법 설명과 유니티 기본 인터페이스 설명에 대충 50페이지 이상을 할애한다. 그러나 이 책에서는 그런 점 없이 깔끔하게 Unity와 OpenAI API 사용법에 대해 다룬다. 유니티 설치 방법도 4페이지로 끝난다. 이 얼마나 책 제목에 충실한 내용인가.

중간중간 보충 설명해주는 지식 포션도 마음에 들었다. 그냥 넘어갈 수 있는 부분을 세심하게 알려주고 있다.

대상 독자 및 책 난이도

유니티에 인공지능을 접목시키려는 개발자가 대상 독자다. 사전 지식이 없어도 이 책을 따라서 학습할 수 있지만, 사전 지식을 갖춘다면 좀 더 수월하게 책의 내용을 이해할 수 있다. 아래는 저자가 언급한 필요 사전 지식이다.

필요 사전 지식
- Unity 엔진의 기본적인 인터페이스와 기능에 대한 기본적인 이해
- Unity 엔진의 씬 구성, 게임 오브젝트 관리, UI 캔버스 제작등의 기초 지식
- C# 기초 문법에 대한 이해(변수, 함수, 클래스와 같은 기본적인 프로그램밍 개념)
- Unity의 MonoBehaviour 클래스와 기본적인 이벤트 함수에 대한 지식
- API 기본 개념 및 API 토큰과 비용 개념, JSON 데이터 형식에 대한 이해
- https의 요청(request)과 응답(response)의 형태로 작동하는 웹 리퀘스트 데이터 통신 방법에 대한 이해

필요 사전 지식이 많은 것 같아보이지만 요약하자면 그냥 유니티를 써본 적이 있는 사람이어야 한다. 최소한 유니티를 설치하고 실행 시켜본 적이 있어야 한다.

다루는 내용과 범위

총 9장으로 일반적으로 생각하는 생성형 AI 기술을 Unity에 연동하여 인공지능 NPC를 구현하는 과정을 다룬다. 코드부터 실행, 결과 화면까지 자세하게 설명해주기 때문에 쉽게 따라할 수 있다.

1장 : 최신 AI API 종류들 소개와 비교
2장 : OpenAI 문장 생성 API를 Unity에 연동하고 챗봇 구현하는 방법
3장 : 다국어 음성 인식 기능 연동
4장 : OpenAI TTS(Text to Speech)와 구글 TTS API 연동 방법과 Unity에서 자연스러운 AI 음성 내레이션 구현 방법
5장 : DALL-E API로 AI 이미지 생성과 Unity에서의 활용
6장 : 립싱크 기술을 활용하여 자연스러운 얼굴 애니메이션 구현 방법
7장 : 앞서 소개한 AI 기술들을 하나로 통합하여 자유롭게 소통하고 반응할 수 있는 인공지능 NPC 완성
8장 : 프롬프트 엔지니어링을 통해 프롬프트를 좀 더 효율적으로 다루는 방법
9장 : AI 기술과 Unity 미래 발전 방향 전망

개인적으로 7장이 가장 마음에 드는데, 단순히 OpenAI API 연동에서 끝나는 것이 아니라 다음 단계로 넘어가서 이렇게 활용하면 된다는 것을 보여주었기 때문이다.

결론

책에서도 언급되었듯이 시중에 chatGPT 활용 서적은 굉장히 많지만 OpenAI를 접목한 프로젝트를 다루는 책은 많지 않다. 그런 점에서 OpenAI API들을 접목한 프로젝트를 소개하는 이 책은 정말 좋았다. 게다가 인공지능 기술이 빠르게 발전된다고 하더라도 해당 모델을 가져다 어떤 제품을 만들어야 하는데, 아직까지는 이런 식으로 API 연동하는 방식이 바뀌지 않을거라 보인다.

현재까지 MMORPG 게임에서 NPC는 정해진 대사를 하고 정해진 물품을 팔아야 하는 형태였다. 앞으로는 NPC가 플레이어들과 상호 작용을 하고 정해진 물품이 아니라 현실에서처럼 사고 파는 물품들이 매번 바뀌고 퀘스트 형태로 실시간으로 바뀌고 NPC가 죽는 일도 발생할 수 있을 것이다. 소설로만 있었던 가상 현실 게임이 얼마 남지 않은 느낌도 들어서 앞으로의 게임들이 굉장히 기대된다. 이 책이 그런 게임을 만드려는 개발자들에게 도움이 되기에 유니티 개발자들에게 적극 추천한다.

[책리뷰] 그림으로 이해하는 챗GPT 구조와 기술

크썸 — Thu, 1 Jan 2026 19:31:25 +0900

[책리뷰] 그림으로 이해하는 챗GPT 구조와 기술

※ 이 서평은 길벗출판사로부터 책을 제공받아 작성되었습니다.

전반적인 소감 및 마음에 드는 부분

GPU 설명 부분이 마음에 들었다. CPU와 GPU 차이를 설명할 때 툭하면 엔비디아의 모나리자 그림 그리는 페인팅 영상을 갖고와서 마치 GPU가 CPU보다 좋은 것처럼 소개하는 부분이 짜증났다. 그러나 이 책에서는 왜 딥러닝에서 GPU가 사용되고 어떤 점에서 CPU보다 더 좋은지 명확하게 설명해준다. 그리고 엔비디아 CUDA 코어의 본래 목적인 그래픽 처리를 효율적으로 수행할 수 있도록 설계한다는 내용을 확실하게 알려주기 때문에 속이 다 시원했다.

LLM 모델을 설명할 때 전체 구조를 설명하는 그림 덕분에 이해하기 편했다. 책에서 소개하는 내용 그대로 그림으로 한눈에 이해하기 좋았다. 복잡한 수식도 없기 때문에 챗GPT가 이런 구조를 가지고 있고 이런 원리에 의해 동작되는구나를 이해하기 쉬웠다. 물론 이 책을 읽었다고 해서 챗GPT의 구조와 원리는 완벽하게 이해하고 파악했다고는 하기 어려울 수 있다. 그러나 주요 개념과 매커니즘은 확실하게 이해했다고 말할 수는 있다.

대상 독자 및 책 난이도

책 제목 그대로 챗GPT 구조와 원리에 대해 알고 싶은 독자들을 대상으로 한다. 자세하게 이해하려고 하지 않는다면 고등학교 수학 지식을 갖고 있는 정도가 적당하고 생각한다. 그렇지 않으면 최소한 머신러닝 기본 개념을 알고 있는 사람들에게 추천한다. 여기서 말한 머신러닝 기본 개념은 신경망, 선형대수학, 미적분 등을 의미한다. 적어도 벡터가 무엇인지는 알고 있으면 읽는데 불편함이 없을 것이다. 그렇지 않다고 하더라도 대충 이런 느낌이구나만 생각한다면 부담없이 읽을 수 있다.

다루는 내용과 범위

이 책은 챗GPT의 높은 범용성을 가능하게 한 핵심 기술, 즉 대규모 언어 모델(LLM)의 구조와 원리에 대해 설명한다. 챗GPT를 사용해본 사람들은 많지만 GPT가 뭐에 약자인지 모르는 사람들이 대부분일거라 생각한다. Generative Pretrained Transformer의 약자로 트랜스포머의 디코더 부분을 이용하여 구축한 텍스트 생성 작업에 특화시킨 자기 회귀형 언어 모델이다. GPT를 비롯하여 현재 주류를 이루고 있는 대부분의 생성형 AI 모델들이 이 트랜스포머를 기반으로 한다. 따라서 이 책은 이 트랜스포머가 무엇인지 알기 위해 머신러닝 밑바닥부터 하나씩 차례대로 설명한다.

1장 챗GPT에서는 이 책에서 최종적으로 설명하고자 하는 챗GPT가 어떤 것이고 무엇이 가능한지 알려준다. 2장에서는 이런 것들이 가능한 이유가 인공지능 발달 덕분인데 그렇다면 인공지능이 무엇인지부터 어떻게 발전해 왔는지를 다룬다.

크게 보자면 1,2장은 챗GPT 구조와 원리 설명 관점에서 보자면 필요없는 챕터이긴 하다. 그래도 이미 알고있는 사람들에게는 요약 정리 느낌으로 훑어보면 되고 몰랐던 사람들에게는 핵심만 간추려 놓은 것이니 가볍게 보면 된다. 3장부터 본격적인 머신러닝 기본 개념이 등장하는데 너무 자세하게 이해하려고 할 필요는 없다. 대충 이런 느낌으로 인공지능이 계산되고 결과를 내놓는다만 알면 된다.

결론

챗GPT의 구조와 원리에 대해 쉽고 빠르게 이해하고 싶다면 이 책을 추천한다. 그러나 생성형 AI를 업무에 활용하거나 다른 기술에 접목해야 하는 독자라면 추천하지 않는다. 이 책은 말 그대로 챗GPT의 구조와 원리를 알려주는데 초점이 맞춰져있다. 책의 뒷편에는 AI의 성능과 정확도를 높이는 요소부터 응용 가능성과 활용 전망까지 폭넓게 고찰한다고 되어있지만 지나친 과장이라 생각한다.

진짜 딱 챗GPT의 구조와 원리, 조금 더 나아가자면 현재 주류를 이루고 있는 대규모 언어모델(LLM)들의 구조와 원리에 대해 설명한 책이기 때문에 핵심 부분만 빠르게 알고 싶은 사람들에게 권장한다.

NeRF 학습을 위해 알아야 할 자료 정리

크썸 — Thu, 1 Jan 2026 17:12:26 +0900

NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis

논문 : [2003.08934] NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis

Githud : GitHub - bmild/nerf: Code release for NeRF (Neural Radiance Fields)

NeRF : 신경 방사장

2차원 이미지의 부분적인 세트에서 복잡한 3차원 장면을 재구성할 수 있는 신경망

특정 장면의 장면 지오메트리, 물체 및 각도를 학습한 후 새로운 관점에서 사실적인 3D 뷰를 렌더링하고

자동으로 합성 데이터를 생성하여 허점을 메우는 방식

완전히 연결된 신경망 아키텍처인 다층 퍼셉트론(MLP)이라는 신경망 측면을 사용하여 3D 장면을 표현

MLP는 신경망과 딥러닝의 파운데이션 모델로, 공간 좌표와 시야 방향을 색상 및 밀도 값에 매핑하도록 훈련

MLP는 3D 공간에서의 위치 또는 2D 시야 방향과 같은 입력을 구성하는 일련의 수학적 구조를 사용하여,

3D 이미지에서 각 지점의 색상 및 밀도 값을 결정

NeRF 이해하기 위한 중요한 개념

1. 카메라 파라미터를 기반으로 픽셀 광선 계산

2. 원점과 방향을 사용하여 단일 광선을 따라 점 샘플링

3. 광선 색상과 알파값의 누적

구면 좌표계

확률 분포(Probability Distributions) : 광선에 따른 색상 및 밀도의 학률 분포를 학습하며, 계층적 샘플링(hierarchical sampling)기법에 사용

최적화 이론

광선 추적(Ray Tracing) : 카메라 원점에서 각 픽셀을 통해 3D 공간으로 광선을 쏘는 개념

체적 렌더링(Volumetric Rendering) : 광선을 따라 샘플링된 점들의 색상과 밀도를 누적하여 최종 픽셀 색상을 결정하는 핵심 기술. 복셀 기반의 적분 개념을 포함

레이 트레이싱 공부#001 - Ray Tracing in One Weekend

크썸 — Wed, 19 Nov 2025 23:59:42 +0900

레이 트레이싱 공부 - Ray Tracing in One Weekend

원본 : https://raytracing.github.io/books/RayTracingInOneWeekend.html

이 포스팅은 원본 Ray Tracing in One Weekend 글을 나름대로 번역하고 정리한 글입니다. 원본 글을 그대로 번역하지 않으니 원본 내용이 궁금하신 분들은 최상단 링크를 통해 보시면 되겠습니다. 먼저 레이트레이싱이 무엇인지 부터 살펴보고 넘어가겠습니다.

Ray Tracing

Ray
n. 광선, 선, 빛살

Tracing
n. 투사, 추적기, 추적법
v (Trace). 추적하다, (추적하여)찾아내다

영문 해석 그대로 광선 추적기, 즉 빛의 경로를 추적하는 것을 뜻합니다. 다시 말하면 컴퓨터 그래픽스 기술에서 조명 시뮬레이션입니다. 컴퓨터 그래픽스 기술에서 일반적으로 그림자나 명암을 표현하는 것은 그냥 그럴듯하게 나타냅니다. 무슨 말이냐면 마치 빛이 어느 지점에 있어서 그림자가 이렇게 생길거다 라고 가정하고 렌더링 합니다. 물론 최근에는 아닌 부분이 더 많습니다. 그러면 레이트레이싱이 뭐가 더 좋으냐면 더욱 사실적입니다. 그림자가 이렇게 생길거다라고 가정하는 것이 아니라 진짜로 빛을 쏴서 그림자나 명암을 표현합니다. 따라서 레이트레이싱 기술을 제대로 구현하면 거울, 유리, 강, 물 웅덩이, 금속 광택 등등 여러 표면의 미묘한 반사까지 사실적으로 표현할 수 있습니다.

다만 빛의 경로를 추적해서 계산해야 하기 때문에 어마어마한 연산량이 필요합니다. 그렇기 때문에 이를 실시간 렌더링을 하려면 CPU와 GPU가 받쳐주어야 합니다. 하지만 여기서는 레이트레이싱 구현 방법에 대해 공부할 볼 것이기 때문에 하드웨어 성능은 중요하지 않습니다. 그럼 시작해보죠

1. 이미지 출력 - PPM 이미지 형식

PPM 이미지란 Portable Pixmap Format의 약자로 텍스트 기반의 간단한 비트맵 이미지 파일 형식입니다. 강좌에서 이 파일 포맷을 선택한 이유는 이미지 파일 형식이 너무 많아서라고 합니다. 어쨌든 우리는 레이트레이싱 작업 결과물을 눈으로 봐야합니다.

계속 작성 중

결론

[정리] 리얼 타임 렌더링(Real-Time Rendering, 4/e) 3장 - 그래픽 처리 장치

크썸 — Wed, 5 Nov 2025 02:00:16 +0900

[정리] 리얼 타임 렌더링(Real-Time Rendering, 4/e) 3장 - 그래픽 처리 장치

https://kr.freepik.com/free-ai-image/anime-character-using-virtual-reality-glasses-metaverse_207687388.htm#fromView=search&page=1&position=2&uuid=0f521947-05d4-4dcd-85e1-832dacca0165&query=GPU+anime

그래픽 처리 장치(Graphics Processing Unit)

CPU에 비해 전용 그래픽 하드웨어가 갖는 장점은 계산 속도가 빠르다는 것뿐이지만 속도 향상은 매우 중요하다.
하드웨어 정점 처리를 포함하는 최초의 소비자용 그래픽 칩 : NVIDIA GeForce 256 (1999)
- 이전에 사용 가능한 래스터 및 전용 칩과 GeForce 256을 구별하고자 그래픽 처리 장치(GPU) 용어 만듬
GPU는 고도로 병렬화활 수 있기 때문에 속도가 매우 빠르다.
GPU에서 프로그래밍 가능한 쉐이더가 어떻게 병렬성을 갖는가를 아는 것이 중요
모든 처리 장치가 당면하는 문제는 지연(Latency)
- 데이터에 접근하는 데는 일정한 시간이 필요
- 지연에 대한 기본 개념은 처리할 정보가 처리 장치에서 멀어질수록 대기 시간이 길어지는 것
- 메모리칩에 저장한 정보는 지역 레지스터에 저장한 것보다 접근 시간이 더 오래 걸림
- 데이터 검색을 기다림으로 인해 처리 장치가 정지 대기(Stall)돼 성능이 떨어지는 것이 요점

데이터 - 병렬 아키텍처

GPU 칩 영역의 대부분은 수천 개의 쉐이더 코어라 하는 대규모 처리 장치 집합으로 구성
GPU는 정렬된 유사한 데이터 집합을 차례대로 처리하는 스트림 프로세서(stream processor)
- 이러한 유사성(ex. 정점이나 픽셀 집합)으로 인해 대규모 병렬 방식으로 처리 가능
병렬 처리 연산이 최대한 독립적으로 일어남
병렬 처리 중 병렬 처리 중인 다른 부분에 정보가 필요 없게 하고 쓰기 가능한 메모리 위치를 공유하지 않음
- 프로세서들이 일찍 (계산이)끝나더라도 제일 늦은 프로세서가 끝날 때까지 대기하게 돼 성능 저하 원인
데이터를 처리할 수 있는 최대 속도로 정의되는 처리량(Throughput)에 최적화
- 캐시 메모리와 제어 로직 전용 칩 영역이 적기 때문에 각 쉐이더 코어의 지연 시간은 CPU보다 높음
GPU는 연산 수행 논리를 데이터에서 분리
2천 개의 프래그먼트를 현대 GPU로 전환하면 프래그먼트에 대한 각 픽셀 쉐이더 호출(invocation)은 스레드(thread)라 불림
- 이 스레드는 CPU 스레드와 다름
- 쉐이더의 입력값에 대한 약간의 메모리와 쉐이더 실행에 필요한 레지스터 공간으로 이뤄짐
- 동일 쉐이더 프로그램을 사용하는 스레드는 집합으로 묶임 : NVIDIA의 워프(warp), AMD의 웨이브프론트(wavefront)
  - 8 ~ 64개 사이 일정 수의 GPU 쉐이더 코어에서 실행돼 있으며, SIMD 처리를 사용
  - 워프의 실행은 단일 GPU 처리 장치의 예와 유사
- 각 스레드는 SIMD 레인(lane)에 할당
실행할 수 있는 2천 개의 스레드가 있다고 가정
- NVIDIA 워프는 32개 스레드를 가짐
- 2000 / 32 = 62.5 워프이기 때문에 63개의 워프가 할당되고 63번째 워프는 절반이 빈 형태
- 쉐이더 프로그램은 32개 처리 장치 모두가 락스텝(lock-step) 형태로 처리
- 메모리 인출을 만나면 모든 스레드가 동시에 만나게 됨
- 인출은 이 스레드 워프가 정지 대기할 것이라고 결과를 기다리는 모든 장치에 전달
- 정지 대기 대신 워프는 다른 32개 스레드의 워프로 교체돼 32코어에서 실행
  - 각 스레드 안의 데이터 워프를 변경시키지 않기 때문에 단일 처리 장치 시스템에서처럼 빠름
- 각 스레드는 각자의 레지스터를 가지며 각 워프는 실행되는 연산을 기록
- 새 워프로 교체하는 것은 다른 스레드의 집합에서 코어의 집합으로 단순히 가리키는 것만이 바뀜(다른 부하 없음)
- 워프는 모두 완료될 때까지 실행되거나 교체
워프-교체(warp-swapping)는 모든 GPU에서 사용되는 주된 지연 은닉(latency-hiding) 메커니즘
쉐이더 프로그램의 구조체는 효율성에 영향을 주는 중요한 특징 중 하나
중요한 것은 각 스레드가 사용하는 레지스터의 양
- 필요한 레지스터가 많을수록 더 적은 스레드, 즉 더 적은 워프가 GPU에 거주할 수 있음
- 워프의 부족은 치환으로 완화시킬 수 없는 정지 대기를 의미
- 거주하는 워프를 비행 중(in flight)이라고 하며, 그 수를 점유율(occupancy)이라고 함
  - 높은 점유율은 처리를 위한 많은 워프가 가용하다는 것으로, 쉬는 처리 정치가 적을 가능성이 높음
전체적인 효율성에 영향을 주는 다른 인자는 동적 분기(Dynamic branching)
- if 명령과 반복문으로 인해 발생
  - 일부 혹은 하나의 스레드가 if 명령에 의해 다른 경로를 타면 워프는 반드시 두 분기를 실행해야 함.
    이러면 각 특정 스레드에서 불필요한 결과를 버리는 문제가 발생하는 데 이것이 스레드 분산(thread divergence)

GPU 파이프라인 개요

렌더링 파이프라인의 GPU 구현 순서
1. 버텍스 쉐이더
  - 완전히 프로그래밍 가능한 단계
  - 지오메트리 구조 처리 단계를 구현하는 데 사용
2. 테셀레이션
3. 지오메트리 쉐이더
  - 완전히 프로그래밍 가능한 단계
  - 기본체(점, 선, 삼각형)의 정점 위에서 처리
  - 기본체 단위 음영 연산을 처리하고, 기본체를 소멸시키거나 새로운 것을 생성하는 데 사용
  - 테셀레이션, 지오메트리 둘 다 선택적이라 모든 GPU가 지원하지 않음
4. 클리핑
  - 고정 함수 하드웨어에서 구현
5. 화면 매핑
  - 윈도우와 뷰 볼륨 설정에 영향 받음
  - 내부적으로는 단순한 크기 조절과 위치 재조정으로 구성
6. 삼각형 설정 & 탐색
  - 고정 함수 하드웨어에서 구현
7. 픽셀 쉐이더
  - 완전히 프로그래밍 가능한 단계
8. 병합기
  1. 프로그래밍 가능하지는 않지만 설정 가능
  2. 넓은 범위의 연산을 처리하도록 설정할 수 있음
  3. Z버퍼, 혼합(Blend), 스텐실(Stencil), 다른 출력과 연관된 버퍼의 변경을 담당
  4. 픽셀 쉐이더와 병합 단계가 함께 실행돼 픽셀 처리 단계를 형성

프로그래밍 가능한 쉐이더 단계

쉐이더 프로그램은 통합된 쉐이더 설계를 사용
- 정점, 픽셀, 지오메트리 구조, 테셀레이션 관련 쉐이더가 공통된 프로그래밍 모델을 공유한다는 것
- 내부적으로 동일한 명령 집합 구조(ISA, Istruction Set Architecture)
- 버텍스 쉐이더와 픽셀 쉐이더 코어가 개별 풀을 가진 GPU는 이상적으로
  모든 코어를 바쁘게 유지하기 위한 작업 부포가 미리 지정돼 있음
- 통합 쉐이더 코어로 GPU는 이 부하를 어떻게 조정할지 결정할 수 있음
쉐이더는 C언어와 비슷한 형태
- DirectX : HLSL(High-Level Shading Language)
- OpenGL : GLSL(opnGL Shading Language)
  - HLSL은 가상머신 바이트코드로 컴파일될 수 있음
기본 데이터형은 32비트 단일 정밀도 부동소수점 스칼라와 벡터
- 벡터는 단지 쉐이더 코드의 일부이며 하드웨어에서 지원하지 않음
- 현대 GPU에서 32비트 정수와 64비트 부동소수점 역시 원천적으로 지원
- 부동소수점 벡터는 위치, 법선 벡터는 행렬 행, 컬러, 텍스처 좌표 같은 데이터를 포함
- 정수는 계수기(counters), 색인(indices), 비트마스크(bitmasks) 등을 표현하는 데 사용
- 구조체, 배열, 행렬 같은 혼합 데이터형도 지원
그리기 호출(드로우콜, Draw call)은 기본체 집합을 그리는 그래픽 API를 호출해 파이프라인이 실행되고 쉐이더를 실행하게 함
각 프로그래밍 가능한 쉐이더 단계는 입력의 2가지 형을 가짐
- 균일 입력(uniform input) : 드로우콜 동안 상수로 유지되는 값
- 범용 입력(varying input) : 삼각형의 정점이나 래스터화에서 오는 데이터
  - 텍스처는 특별한 종류의 균일 입력으로 한때 표면에 적용되는 컬러 이미지로만 사용됐으나
    이제는 임의의 데이터의 큰 배열로 간주
기본 가상 머신(underlying virtual machine)
- 다른 형의 입력과 출력에 대한 특별한 래지스터를 제공
- 균일하게 하고자 사용할 수 있는 상수 레지스터(constant registers)의 수는
  다양한 입력이나 출력에 사용할 수 있는 레지스터보다 훨씬 큼
  - 범용 입력과 출력이 각 정점이나 픽셀에 대해 따로 저정해야 하기 때문에 필요한 수량에 제한이 있음
  - 균일 입력은 한 번 저장되고 드로우콜의 모든 정점이나 픽셀에서 재사용
- 스크래치 공간(scratch space)에 사용되는 범용 임시 레지스터(temporary register)도 있음
- 모든 유형의 레지스터는 임시 레지스터 안의 정수 값을 사용해 배열 색인을 할 수 있음
그래픽 계산에서 공통적인 연산은 현대 GPU에서 효율적으로 실행
- 쉐이딩 언어는 이 연산의 대부분을 공개하며 연산자 * 나 + 등을 사용
- 나머지는 내재 함수로 공개돼 있으며 GPU에 최적화
- 벡터 정규화나 반사, 외적, 행렬 전치와 행렬식 계산 등과 같은 더 복잡한 연산 함수도 있음
- 쉐이더는 2가지 종류의 흐름 제어를 지원
  - 정적 흐름 제어(static flow control) : 코드 흐름이 드로우콜 안에서 고정적
    - 동일 쉐이더가 다양한 다른 상황에서 사용할 수 있음
    - 모든 호출(invocations)은 동일 코드 경로를 갖기에 스레드 분산(thread divergence)이 없음
  - 동적 흐름 제어(dynamic flow control) : 범용 입력의 값에 기반을 두며 각 프래그먼트가 코드를 다르게 실행
    - 정적 흐름 제어보다 훨씬 강력하지만 쉐이더 호출 사이에 코드 흐름이 비정상적으로 변경되는 경우
      성능 저하가 일어날 수 있음

프로그래밍 가능한 음영과 API의 진화

NVIDIA의 GeForce 3 : 프로그래밍 가능한 버텍스 쉐이더를 지원한 최초의 GPU
- DirectX 8.0과 OpenGL Extension을 통해 공개
쉐이더 모델 2.0 (SM, Shader Model)
- DirectX에서 다른 쉐이더 능력을 가진 하드웨어 사이를 구분하고자 도입한 개념
- 진정한 프로그래밍 가능한 버텍스와 픽셀 쉐이더
- 비슷한 기능성이 OpenGL에서 다양한 확장을 통해 공개
- 쉐이더에서 흐름 제어 허용 및 추가
쉐이더 모델 3.0
- 동적 흐름 제어 추가
- 버텍스 쉐이더에서 텍스처 읽기 지원 추가
- 추가 기능 요구 사항을 반영해 더욱 더 증가된 자원 지원 추가
- XBOX 360, 플레이스테이션3 게임 콘솔에 쉐이더 모델 3.0 수준의 GPU 장착
쉐이더 모델 4.0
- DirectX 10.0에서 포함
- 지오메트리 쉐이더와 스트림 출력 등 주요한 여러 기능이 도입
- 모든 쉐이더(버텍스, 픽셀, 지오메트리)에 대한 균일 프로그래밍 모델을 포함하며 통합 쉐이더 설계 방식으로 구성
- 정수 데이터형의 지원(비트 연산 포함)
- OpenGL 3.3에서 GLSL 3.30의 도입 역시 비슷한 쉐이더 모델을 제공
쉐이더 모델 5.0
- DirectX 11과 함께 테셀레이션 단계쉐이더와 컴퓨트 쉐이더 추가
- CPU 멀티프로세싱을 더 효과적으로 사용 가능
- OpenGL 4.0부터 테셀레이션 추가, 4.3부터 컴퓨트 쉐이더 추가
2013년 AMD의 Mantle API
- 그래픽 하드웨어의 부하 대부분을 걷어내고 이 제어를 개발자에게 직접 제공
- 리팩토링과 동시에 효과적인 CPU 멀티프로세싱을 지원
  - CPU가 드라이버에서 사용하는 시간을 엄청나게 감소
  - 좀 더 효과적인 CPU 다중 프로세서 지원에 집중하게 함
- 2015년에 마이크로소프트가 이 API 개념을 채용해 DirectX 12에 적용
  - 새 GPU 기능성을 공개하지는 않았고 DirectX 11.3과 동일 하드웨어 기능을 제공
  - 최신 GPU 아키텍처에 더 잘 매핑되는 근본적인 API의 재설계
- 애플은 Metal이라 불리는 자체 저부하 API를 2014년에 공개
  - iPhone 5S, iPad Air 같은 모바일 장치에서 먼저 사용
  - 1년 후 OS X El Capitan을 통해 새로운 매킨토시에서 사용 가능
  - 효율성을 넘어서 CPU 사용을 감소시키는 것은 전력을 절약할 수 있는 것으로 모바일 장치에서 중요
  - 이 API는 고유의 쉐이딩 언어를 가지며 그래픽과 GPU 계산 프로그램 모두 사용
- 2016년, AMD는 Mantle 작업을 크로노스 그룹에 기부했으며 Vulkan이라는 자체 API를 공개
  - OpenGL과 같이 여러 운영체제에서 작동
  - 쉐이더와 일반 GPU 계산에서 둘 다 사용 가능한 새로운 고수준 중간 언어인 SPIR-V를 사용
    - 미리 컴파일된 쉐이더는 무겁지 않으며 필요한 기능을 지원하는 어떤 GPU에서든 사용 가능
  - 디스플레이 윈도우가 필요하지 않는 그래픽이 아닌 GPU 계산에서 사용 가능
  - 다른 부하가 적은 드라이버와의 차이는 Vulkan이 워크스테이션부터 모바일 장치까지 지원한다는 점
모바일 장치에서는 표준적으로 OpenGL ES를 사용
- ES(Embedded System)의 약어이며 API 자체가 모바일 장치를 고려해서 개발
- OpenGL ES 3.0은 2012년에 공개
  - 다중 렌더 타겟, 텍스처 압축, 변환 피드백, 인스턴싱 및 훨씬 더 다양한 텍스처 포맷과 방식을 지원
- OpenGL ES 3.1에서 컴퓨트 쉐이더 추가
- OpenGL ES 3.2에서 다른 기능과 함께 지오메트리 쉐이더와 테셀레이션 쉐이더 추가
OpenGL ES에서 파생된 브라우저 기반 API인 WebGL은 자바스크립트로 호출
- 2011년에 공개된 뒤에 대부분의 모바일 장치에서 사용 가능했으며 OpenGL Es 2.0에 비해 기능적으로도 동일
- WebGL 2는 OpenGL ES 3.0 지원을 가정
- 크로스 플랫폼이라 모든 PC와 거의 대부분의 모바일 장치에서 동작
- 드라이버 승인이 브라우저에 의해 처리.
  심지어 한 브라우저가 특정 GPU나 확장을 지원하지 않아도 다른 브라우저가 지원
- 코드는 컴파일되지 않고 해석(interpret)되며, 단지 텍스처 에디터만이 개발에 필요
- 디버거(Debugger)가 대부분의 브라우저에 내장돼 있으며, 어떤 웹 사이트에서 실행되는 코드든 디버깅 가능
- 프로그램은 웹 사이트나 깃허브에 올려 제공될 수 있음

버텍스 쉐이더

테셀레이션 단계

지오메트리 쉐이더

픽셀 쉐이더

병합 단계

컴퓨트 쉐이더

[정리] 리얼 타임 렌더링(Real-Time Rendering, 4/e) 2장 - 그래픽 렌더링 파이프라인

크썸 — Sun, 2 Nov 2025 23:41:24 +0900

[정리] 리얼 타임 렌더링(Real-Time Rendering, 4/e) 2장 - 그래픽 렌더링 파이프라인

https://kr.freepik.com/free-photo/3d-render-modern-landscape-extruding-hexagons_13477699.htm#fromView=search&page=1&position=6&uuid=83caf2df-5bfd-4d39-8dc8-011883432887&query=graphics+rendering+pipeline

그래픽 렌더링 파이프라인 - 아키텍처

주된 기능은 가상 카메라, 3차원 오브젝트, 광원 등을 생성하거나 렌더링하는 것
각 단계는 병렬로 실행되며 이전 단계 결과의 영향을 받음
- 이상적으로는 파이프라인화되지 않은 시스템을 n개의 파이프라인으로 나누면 속도가 n배 향상
가장 기본적으로 4단계로 나눔
- 응용 단계(Application)
  - 애플리케이션에 의해 동작되며 보통 CPU에서 실행되는 소프트웨어로 구현
  - 충돌 검출, 가속 알고리듬, 애니메이션, 물리 시뮬레이션 등을 포함
- 기하 처리 단계(Geometry processing)
  - 변환, 투영, 기타 지오메트리 구조 처리
  - 무엇을, 어떻게, 어디에 그릴 것인지 계산
  - 일반적으로 GPU에서 처리
- 래스터화 단계(Raterization)
  - 보통 3개의 정점(Vertex)을 입력으로 한 삼각형을 구성해 해당 삼각형 안의 모든 픽셀을 찾은 후 다음 단계로 전달
- 픽셀 처리 단계(Pixel processing)
  - 프로그램을 실행해 색상을 결정하고 깊이 테스트(Depth testing)를 수행해 가시성을 판단
  - 기존 색상과 새로 계산된 색상을 혼합하는 것과 같은 픽셀 단위 작업을 수행
각 단계는 그 자체가 하나의 파이프라인이기 때문에 여러 개의 하위 단계로 구성될 수 있음
렌더링 속도는 초당 프레임(FPS, Frames Per Second)으로 표현하며 초당 렌더링되는 이미지의 수

응용 단계(Application)

일반적으로 CPU에서 소프트웨어로 실행되기 때문에 개발자는 이 단계에서 일어나는 것을 완전히 통제 가능
응용 단계의 변경은 이후 단계의 성능에 영향을 줌
- 렌더링될 삼각형 수를 줄이면 이후 단계에서 처리해야 할 일이 줄어 렌더링 속도가 높아짐
컴퓨트 쉐이더(Compute Shader)라고 불리는 별도 모드를 사용해서 GPU에서 수행 가능
- GPU를 매우 병렬적인 일반 처리 장치로 취급하고 그래픽 렌더링을 위한 특수 기능을 무시
일반적으로 구현되는 프로세스 중 하나는 충돌 검출
- 두 오브젝트 사이에서 충돌이 검출되면 그에 대한 응답을 생성해 충돌한 오브젝트들과 포스 피드백 장치로 보냄
응용 단계를 마치면 렌더링할 기하 모델은 파이프라인의 다음 단계로 공급
- 기하 모델은 최종적으로 화면에 그려지는 점, 선, 삼각형과 같은 렌더링 기본체(Primitives)
- 응용 단계에서 가장 중요한 작업
키보드, 마우스 등 다양한 입력 장치 처리
특정 컬링 알고리듬(Culling Algorithm) 같은 가속 알고리듬도 나머지 파이프라인에서 처리할 수 없는 것과 함께
이 단계에서 처리

기하 처리 단계(Geomtry Processing)

주로 삼각형이나 정점 단위로 수행되는 연산을 담당
4단계의 세부적인 기능으로 나뉠 수 있음
- 버텍스 쉐이딩(Vertex Shading)
- 투영(Projection)
- 클리핑(Clipping)
- 화면 매핑(Screen mapping)
버텍스 쉐이딩(Vertex Shading)
1. 정점 위치를 계산하고 프로그래머가 필요로 하는 정점 출력 데이터를 평가하는 것
  - 항상 필요한 좌표 집합인 정점 위치를 계산하는 방법을 설명하는 것으로 시작
  - 모델은 아무런 변환도 적용되지 않은 고유의 모델 공간에 존재
  - 각 모델은 모델 변환(Model transform)을 이용해 위치와 방향을 지정
  - 모델 변환에 의해 변형되는 것은 모델의 정점과 법선 벡터들
    - 오브젝트의 좌표를 모델 좌표(Model coordinates) 또는 지역 좌표(local coordinates)라고 하며
      모델 변환이 적용되면 전역 좌표(World coordinates) 또는 전역 공간(World space)에 위치
    - 전역 공간은 유일하게 하나만 존재하며 각 모델들이 고유의 모델 변환에 의해 변환되면
      모든 모델은 동일한 전역 공간에 존재
  - 카메라는 전역 공간에 배치하기 위한 위치 정보와 바라보는 방향 정보를 가지고 있음
  - 투영과 클리핑(Clipping)을 하고자 카메라와 모든 모델은 뷰 변환으로 변환
    - 뷰 변환의 목적은 카메라를 원점에 배치하고 바라보는 방향을 -z축 방향으로 향하게 하기 위해서
    - 이와 같은 공간을 카메라 공간(Camera space), 뷰 공간(View space), 눈 공간(Eye space)라 함
2. 각 오브젝트의 재질과 오브젝트를 비추는 광원의 효과 같은 외향도 반드시 필요
  - 음영(Shading) : 재질에 대한 빛의 효과를 결정하는 작업
    오브젝트를 구성하는 정점에서 음영 방정식(Shading Equation)을 계산하는 것
  - 일반적으로 이 계산의 일부는 모델의 정점에 대해 기하 처리 단계에서 수행되고 일부는 픽셀당 처리 과정에서 수행
  - 버텍스 쉐이딩 결과는 래스터화 단계로 전달돼 픽셀 처리 단게에서 보간되고
    최종적으로 표면의 음영을 계산하는 데 사용
투영(Projection) - 일반적으로 2가지
- 직교 투영(Orthographic projection) 또는 평행 투영(Parallel projection)
  - 뷰 볼륨은 보통 직사각형 모양이고 직교 투영에 의한 뷰 볼륨은 단위 정육면체로 변환
  - 평행선이 변환 후에도 평행을 유지
- 원근 투영(Perspective projection)
  - 오브젝트가 카메라에서 멀어질수록 투영한 후에 더 작게 보임
  - 평행선은 수평선에서 한 점으로 수렴(소실점)
  - 인간이 오브젝트의 크기를 인지하는 방법을 모사한 것
  - 절두체라 불리는 뷰 볼륨은 직사각형의 바닥면을 갖고 머리 쪽이 잘려진 피라미드 모양
    이 절두체를 단위 정육면체로 변환
- 렌더링 시스템은 버텍스 쉐이딩의 한 부분으로 투영 변환 후 클리핑 연산을 처리하는 데,
  이는 뷰 볼륨을 양끝 점이 (-1, -1, -1)과 (1, 1, 1)인 단위 정육면체 크리로 변환하는 과정
  - 이와 같은 단위 정육면체를 정규 뷰 볼륨(Canonical view volume)
  - 투영 변환이 먼저 처리되고 GPU의 버텍스 쉐이더에 의해 실행
- 하나의 영역을 다른 것으로 변형하는 것이지만 화면에 그려진 영상에는 z축을 따로 저장하지 않고
  z버퍼 안에 저장되기 때문에 투영이라고 부름. 이런 방법으로 모델은 3차원에서 2차원으로 투영
선택적 정점 처리
- 모든 파이프라인은 정점 처리 단계를 가짐
- 이 처리 후 테셀레이션(Tessellation), 지오메트리 쉐이딩(Geometry shading), 스트림 출력(Stream output)과 같은
  GPU에서 처리할 수 있는 몇 가지 선택적인 단계가 존재
- 테셀레이션(Tessellation)
  - 헐 쉐이더(Hull shader), 테셀레이터(Tessellator), 도메인 쉐이더(Domain shader)와 같은 여러 단계로 구성
  - 공과 같은 곡면을 묘사할 때 패치(Patch)의 집합으로 설정할 수 있고 각 패치는 정점의 집합으로 만들어짐.
    패치 정점의 집합을 더 큰 정점의 집합으로 변환해 새로운 삼각형 집합으로 만드는 데 사용
  - 한 장면에서 카메라는 얼마나 많은 삼각형이 생성되는지를 결정하기 때문에 가까울 때 정점이 많아지고,
    멀어지면 적어짐
- 지오메트리 쉐이더(Geomtry shader)
  - 테셀레이션 쉐이더보다 먼저 생겨났기 때문에 GPU에서 좀 더 일반적
  - 테셀레이션 쉐이더는 다양한 종류의 기본체(primitives) 안에 있어 새로운 정점을 생성할 수 있지만
    일정 범위로 제한돼 있고 출력 기본체가 생성보다 더 제한돼 있기 때문에 단순하게 진행됨.
    반면 지오메트리 쉐이더는 다양하게 활용할 수 있으며 입자 생성(Particle generation)에서 사용
  - 예를 들어 불꽃놀이 폭발을 모사한다고 했을 때 각 불꽃은 단일 정점인 점으로 표현될 수 있음.
    지오메트리 쉐이더에서는 각 점을 취해서 시점을 향하게 하고 몇 개의 픽셀을 커버하는 정사각형으로
    변환 가능하기 때문에 좀 더 그럴듯하게 표현할 수 있는 기본 요소를 제공
- 스트림 출력(Stream output)
  - GPU를 지오메트리 구조 엔진으로 사용
  - 처리된 정점을 파이프라인 후반부로 보내 화면에 렌더링하는 대신 현 시점 이후 처리를 위해 선택적으로 출력
  - 이 데이터는 이후 단계에서 CPU나 GPU로 직접 처리 가능
  - 일반적으로 불꽃놀이와 같은 입자 시뮬레이션에 사용
클리핑(Clipping)
- 뷰 볼륨에 포함되는 기하 요소만 화면에 그려지기 때문에 완전히 벗어나 있는 기하 요소들은 제거할 필요가 있음
- 한 정점이 뷰 볼륨의 바깥쪽에 있고 다른 정점이 안쪽에 있다면 뷰 볼륨의 경계를 기준으로 잘라서 바깥쪽에 있는
  정점은 뷰 볼륨의 교차점에 위치하는 지점에 새로운 정점으로 대치
- 이전 단계에서 투영 변환을 한 후 변환된 기하 요소들은 단위 정육면체(Unit cube)를 기준으로 클리핑
- 투영으로 생성된 4개의 값을 갖고 있는 동차 좌표계를 사용
  - 일반적으로 이 값은 원근 공간 안의 삼각형에서는 선형 보간되지 않음
- 원근 분할(perspective division)이 실행되며 이는 결과적으로 삼각형을
  3차원 정규 장치 좌표(nomalized device coordinates)에 놓이게 함.
- 지오메트리 구조 단계의 마지막은 이 공간을 윈도우 좌표계로 변환하는 것
화면 매핑(Screen mapping)
- 뷰 볼륨 안쪽 클리핑된 기하 요소들만 화면 매핑 단계로 전달
- 이 단계에 진입할 때까지 좌표는 3차원
  - 전달된 기하 요소들의 x/y 좌표는 화면 좌표계를 형성하고자 변환
  - 화면 좌표와 z 좌표를 윈도우 좌표(Window coordinates)라고 부름
- 어떤 장면이 모서리 최솟값이 (X1, Y1)이고 모서리 최댓값이 (X2, Y2)인 윈도우에 렌더링한다고 가정
  - 그 후 화면 매핑은 이동 연산과 연속적인 크기 조절(scaling) 연산
  - 여기서 새로운 x/y 좌표를 화면 좌표(screen coordinates)라고 함
  - z 좌표 또한 [Z1, Z2]로 매핑되고 Z값을 가진 윈도우 좌표가 래스터화 단계로 전달
    - OpenGL : [-1, +1]
    - DirectX, Vulkan, metal : [0, 1]
- 주어진 수평 픽셀 배열과 데카르트 좌표(Cartesian coordinates)를 사용하는 경우
  가장 왼쪽 위의 픽셀은 부동소수점 좌표에서 0.0
- 모든 API가 픽셀 위치 값을 왼쪽에서 오른쪽으로 증가하게 사용하지만 위, 아래의 경우 OpenGL과 DirectX가 다름
  - OpenGL : 이미지의 왼쪽 아래 모서리가 (0, 0)
  - DirectX, Vulkan, metal : 이미지의 왼쪽 위 모서리가 (0, 0)

래스터화 단계(Rasterization)

렌더링되는 기본체 안에 있는 모든 픽셀을 찾는 것
스캔 변환(Scan conversion)이라고도 불리며 화면 공간의 2차원 정점에서 화면의 픽셀로 변환
삼각형이 3개의 정점에서 형성돼 결국 픽셀 처리로 보내지기 때문에 기하학 처리와 픽셀 처리 사이의 동기화 과정이기도 함
기능적으로 삼각형 준비(setup) 단계와 삼각형 순회(traversal) 단계로 나뉨
- 삼각형 준비
  - 삼각형에 대한 미분, 에지 방정식(Edge equations), 기타 데이터를 계산
  - 삼각형 순회와 지오메트리 구조 단계에서 생성된 다양한 음영 데이터의 보간에 사용
  - 고정 함수 하드웨어(Fixed-function hardware)를 사용
- 삼각형 순회
  - 어떤 샘플 혹은 픽셀이 삼각형 안에 있는지 검사하는 것
  - 각 픽셀의 중점이 삼각형에 포함되는지 검사하고 삼각형과 겹치는 픽셀에 대해 생성된 프래그먼트를 확인
  - 각 삼각형 내부 프래그먼트 속성 값은 3개의 삼각형 정점 사이 보간된 데이터를 사용.
    이 속성 값은 프래그먼트 깊이 값과 지오메트리 구조 단계의 음영 데이터도 포함

픽셀 처리 단계(Pixel Processing)

픽셀당 또는 샘플당 계산 및 작업이 기본체 내부에 있는 픽셀이나 샘플에서 처리되는 단계
픽셀 음영(Pixel shading)과 병합(merging)으로 나뉨
- 픽셀 음영
  - 보간된 음영 데이터를 입력으로 사용해 픽셀당 음영이 이뤄짐
  - 최종 결과는 각 프래그먼트에 대한 컬러 값이며 이 값이 다음 단계로 하나 이상의 컬러를 전달
  - 프로그램 가능한 GPU 코어에 의해 실행되며 이를 위해 프로그래머에게 원하는 계산을 포함할 수 있는
    픽셀 쉐이더(또는 프래그먼트 쉐이더)용 프로그램을 제공
  - 가장 중요한 기술 중 하나는 텍스처링(Texturing)
    - 하나 이상의 이미지를 해당 오브젝트에 붙이는 것
    - 텍스처링에 사용될 이미지는 1, 2, 3차원이 될 수 있으며 2차원 이미지가 가장 일반적
- 병합
  - 각 픽셀에 대한 정보는 컬러의 직사각형 배열인 컬러 버퍼(Color buffer)에 저장
  - 픽셀 음영 단계에서 생성된 프래그먼트 컬러를 현재 버퍼에 저장된 컬러와 병합
    ROP(Raster Operations Pipeline 또는 Render Output unit이라고 부름)
  - 이 단계를 처리하는 GPU 세부 장치는 일반적으로 프로그래밍 가능하지 않지만
    구성 가능한 설정이 많아 다양한 효과를 사용할 수 있음
  - 가시성(Visibility)을 결정하는 역할도 함
    - Z버퍼(깊이 버퍼(Depth buffer) 라고도 함) 알고리듬을 사용해 처리
      - 컬러 버퍼와 크기 및 모양이 같으며 각 픽셀들은 현재 카메라에서 가장 가까운 기본체의 깊이 값을 저장
      - 이는 기본체가 특정 픽셀로 렌더링될 때 해당 기본체의 z값이 계산되고
        동일한 픽셀의 z 버퍼 내용과 비교됨을 의미
      - 새로운 z값이 z버퍼에 저장돼 있던 값보다 작으면 렌더링되는 기본체는 지금까지 해당 픽셀에서 가장
        가까웠던 기본체보다 더 가까운 것을 의미하므로 z값과 해당 픽셀의 컬러는 그려지는 기본체의 z값과
        컬러로 각각 z버퍼와 컬러 버퍼에서 교체
      - 계산된 z값이 z버퍼에 저장된 값보다 크다면 기존에 저장됐던 컬러 버퍼와 z 버퍼의 내용은 그대로 유지
      - O(n)의 복잡도를 가지며 각 픽셀에서 깊이 값을 계산할 수만 있다면 그려질 어떤 기본체에도 적용 가능
      - 단, 화면의 각 지점에 대해 단 하나의 깊이 값만 저장하기 때문에 부분적으로 투명한 기본체에는 사용X
        반투명성은 기본 Z버퍼 알고리듬의 가장 큰 한계 중 하나
  - 프래그먼트 정보를 필터링하고 캡처하는 데 다른 채널과 버퍼를 사용할 수 있음
    - 알파 채널(Alpha channel)은 컬러 버퍼와 관련이 있으며 각 픽셀에 대응되는 불투명도 값을 저장
  - 스텐실 버퍼(Stencil buffer)는 오프스크린 버퍼(Offscreen buffer)로 렌더링된 기본체의 위치를 저장하는 데 사용
    (화면상 보이는 버퍼가 아닌 추가 계산을 위한 버퍼라는 의미)
    - 기본체를 스텐실 버퍼에 렌더링한 다음 이 버퍼의 값으로 컬러 버퍼와 Z버퍼로의 렌더링을 제어 가능
    - 속이 채워진 원이 스텐실 버퍼에 렌더링됐다고 가정했을 때, 컬러 버퍼에 원이 있는 부분에만
      기본체의 렌더링을 허용하도록 스텐실 버퍼 연산자와 연동할 수 있음
    - 파이프라인 끝에 있는 이런 모든 기능을 래스터 연산(Raster Operation) 또는 블렌드 연산(Blend operation)
    - 현재 컬러 버퍼에 있는 컬러와 삼각형 내부에서 처리 중인 픽셀의 컬러를 혼합할 수 있음
  - 프레임 버퍼(Frame buffer)는 일반적으로 시스템의 모든 버퍼로 이뤄짐
    - 기본체가 래스터화 단계에 도달하고 이를 지날 때 카메라 시점에서 보이는 것을 화면에 디스플레이
    - 화면 디스플레이는 컬러 버퍼에 저장된 내용을 보여주는 것
    - 기본체가 래스터화돼 화면으로 보내지는 과정을 관측자가 볼 수 없도록 이중 버퍼링(Double buffering 사용
      - 한 장면히 화면 밖 후면 버퍼(Back buffer)에서 렌더링되면 후면 버퍼의 내용은
        이전에 화면에 디스플레이된 전면 버퍼(Front buffer)의 내용과 교체
      - 교체 작업은 보통 안전한 시기인 모니터의 수직 회귀(Vertical retrace) 동안 일어남

파이프라인을 통해

파이프라인은 실시간 렌더링 애플리케이션을 목표로 지난 수십 년간 API와 그래픽 하드웨어가 발전한 결과
- 단, 유일하게 가능한 렌더링 파이프라인은 아님
- 오프라인 렌더링 파이프라인 역시 다른 진화 과정을 거침
영화 제작을 위한 렌더링은 종종 마이크로폴리곤 파이프라인(micropolygon pipeline)으로 처리
- 최근 광선 추적(Ray tracing)과 경로 추적(Path tracing) 기법을 도입
- 건축 설계와 디자인 사전 시각화에도 사용

[책리뷰] 개발자답게 코드로 익히는 강화학습

크썸 — Fri, 19 Sep 2025 21:46:53 +0900

"프리렉 출판사로부터 책을 제공받아 작성된 서평입니다."

[책리뷰] 개발자답게 코드로 익히는 강화학습

전반적인 소감 및 마음에 드는 부분

책 제목을 오해하면 안된다. '수학적 장벽 없이'를 '수학 없이'로 잘못 받아들이면 안된다는 뜻이다. 그렇다고 해서 코드가 많다거나 코드를 아주 자세하게 설명해주거나 그런 것도 아니다. 딱 핵심적인 코드만 짧고 간결하게 설명해준다. 강화 학습 올인원 기초라는 부가 설명이 딱 알맞은 책이다. 책에 나온 코드를 그대로 적용하기는 어렵겠지만 적어도 어떤 흐름에 의해서 어떤 결과가 나오는지 쉽게 알 수 있다. 내가 다른 리뷰에서도 자주 언급하지만 파이썬 기초 문법 설명이 없다. 따라서 쓸데없이 프로그래밍 문법 설명하느라 지면을 낭비하는 부분이 전혀 없다. 기본 개념부터 최신 알고리즘과 어떤 분야에서 주로 사용하는지도 설명해주어서 좋았다.

대상 독자 및 책 난이도

기본적으로 강화 학습을 공부하고 싶은 개발자들이 대상 독자다. 그러나 강화 학습이 무엇인지 알고 싶은 사람들에게도 충분히 좋은 학습서다. 게다가 인공지능 기본 개념도 포함하고 있기 때문에 개발자가 아니더라도 개발자들이 하는 용어를 정확히 이해하고 싶은 사람들에게 추천한다. 특히 금융 분야에서 쓰이는 강화 학습을 많이 다루고 있기 때문에 금융권 종사자들에게 권유하고 싶다. 단 행렬과 미분이 어떤 것인지 조금이나마 접해본 사람들이어야 한다. 물론 책에서 미분이 뭔지 개념 설명은 해준다.

수학적 장벽이 없다고 했지 수학이 없다고는 안했다!!

다루는 내용과 범위

강화 학습 학습을 위한 기초 개념부터 PPO, A2C 등 최신 정책 기반 알고리즘과 Optuna와 같은 자동화 도구도 함께 다룬다.

강화 학습 기본 개념
강화 학습 기본 알고리즘
다이나믹 프로그래밍과 몬테카를로 방법
시간차 학습, 살사, Q러닝
인공지능 개념
함수 근사법
가치기반 강화 학습과 DQN 알고리즘
정책 기반 강화 학습 Reinforce 알고리즘
정책 기반 A2C 알고리즘
정책 기반 PPO 알고리즘
인공신경망 튜닝
베이지안 최적화 기법
Stable-Baseline3
인공지능 자산 배분 전략
인공지능 자산 배분 전략 튜닝

결론

강화 학습을 어렴풋이 알고 있었는데 이 책을 통해 개념을 좀 더 명확하게 잡을 수 있을 것 같다. 신가하게도 금융권에서 강화 학습을 사용할 줄은 몰랐다. 주식 시장에서의 자동 매매 시스템, 고빈도 트레이딩 전략, 원자재 선물 시장에서의 리스크 조절 모델 등 이런 것들이 강화 학습으로 이루어지고 있다고 한다. 금융 시장의 경우 변수가 워낙 많아서 인공지능 활용이 어려울거라 생각했는데, 강화 학습을 통해 이미 보편적으로 사용되고 있는게 재밌었다. 본래 강화 학습을 통해 인공생명체 분야에 좀 더 연구를 진행해보고 싶었는데 난이도 있어 바로 적용하기는 어려웠다. 그래도 이 책 덕분에 강화 학습 기본 개념들을 정리할 수 있었으니 천천히 시도해봐야겠다.