kgr0831

[이산수학] 1장 - 이산수학이 뭘까?

kgr0831 — Fri, 24 Apr 2026 04:02:47 +0900

본 글은 코딩에 대한 아주아주아주 기초중의 기초가 있다는 걸 가정하고 작성했다.

"이산"수학은 우리가 프로그래밍에서 사용하는 Integer, 즉 정수같은 연속되지 않고, 뚝 떨어지는 수들을 다룬 수학이다.

반대로, float같은 연속적이고 뚝 떨어지지 않는 수들을 다룬 수학은 미적분 같은걸 배우는 연속수학이다.

이렇게만 들으면 무슨 말인지 잘 이해하기 어려울거다.

이 이산수학은 과학이나 공학에서 응용의 핵심으로 쓰이는 수학으로,

현실에 존재하는 여러 복잡한 문제들을 효과적으로, 논리적으로 해결하기 위해 존재한다.

공학과 수학 교집합인 학문이라고 생각하면 편하다.

그럼 이산수학은 어떻게 문제를 해결할까?

일반적으로 위 사진과 같은 문제 상황을 인지 > 문제를 추상화 > 문제를 수학적 모델링 해야한다.

차근차근히 알아보자(문제 상황을 인지하는거는 굳이 알아보지 않겠다.)

1. 추상화

이산수학에서의 추상화는 우리가 흔히 생각하는 아래 사진과 같은 미술에서의 추상화와는 다르다.

이건 Abstract Art 라고 부른다. 우리가 다룰추상화는 Abstraction 이다.

영어로는 Abstraction 이라고도 부르는 이 추상화는 C++ 창시자인 비야네 스트로스트룹에 의해 아래와 같이 정의 되었다.

"구현 세부 정보를 숨기는 일반 인터페이스를 지정하는 행위"

음.. 너무 어려우니 이걸 좀 풀어서 설명하면, 아래 사진과 비슷한 느낌이다.

추상화의 대표적인 예시이다. 오른쪽으로 갈수록 추상화가 심해진거다. 추상화도 너무 많이 하면 좋지 않다.

더 쉽게 정의 하자면

추상화란,

문제 해결에 필요한 요소를 제외한 모든 요소를 제거하는 과정 또는 문제의 핵심만 남기는 과정을 의미한다.

프로그래밍에서 대표적인 추상화의 예시는 프로그래밍 언어이다.

우리는 0101 같은 바이너리를 이용하여 코딩을 하지 않는다.

ISA를 쉽게 설명하자면, 0101이 무슨 명령인지를 정리한 아주 Low-Level의 명령어 집합이라고 보면 된다. 우리가 흔히 이야기하는 x86이 대표적이고 많이 쓰는 ISA이다.

바이너리들은 ISA라는 것에 의해 정의되어, 우리는 이를 쓰기 쉽게 영어 단어들로 추상화한 프로그래밍 언어로 코딩을 한다.

(ISA가 뭔지는 굳이 알필요 없다.)

문제가 이 추상화를 걸쳐서,

이제 이걸 토대로 실제로 연산이 가능한 수학적 구조로 매핑하는 과정이 필요하다.

이걸 수학적 모델링이라고 부른다.

2. 수학적 모델링

수학적 모델링이란,

수학적 구조로 매핑시켜 체계적으로 문제를 해결하는 방법론

이다.

이것도 좀 쉽게 풀어서 설명하자면, 수학적으로 계산이 가능하도록 매핑하는거라고 할 수 있다.

이산수학 교재에서는 이 수학적 모델링이 다음 3가지 요소로 이루어진다고 명확히 정의한다.

주어진 문제의 상황과 배경 파악
주어진 문제와 수학적 구조와의 매핑
수학적 기초 개념을 이용한 문제 해결

이게 무슨 말인지 우리가 겪을법한 일상적인 문제에 적용해 보자.

"1개에 1,000원인 사과 x개와 1개에 2,000원인 배 10개를 사면, 총 30,000원일 때 사과를 몇 개 샀는지 구하시오"

라는 문제가 주어졌다고 가정해 보자.

주어진 문제의 상황과 배경 : 과일 가게에서 한정된 예산으로 사과와 배를 사는 일상적 상황을 파악한다.
주어진 문제와 수학적 구조와의 매핑 : 현실의 상황을 컴퓨터가 풀 수 있게 아래와 같은 '방정식'이라는 구조로 변환(매핑)한다. 1000x + (2000 * 10) = 30000
수학적 기초 개념을 이용한 문제 해결 : 수식을 계산하여 x = 10이라는 정답을 도출해 낸다.

이처럼 현실의 문제를 계산 가능한 식으로 세우고 답을 내는 전체 과정이 수학적 모델링이다.

우리가 방금 든 예시는 '방정식'을 썼지만,

보통 이산수학에서는 이를 그래프나 명제, 진리표 같은 이산적인 구조로 표현하여 매핑한다.

대표적인 그래프 중 하나인 트리 그래프이다.

지금까지의 과정을 요약하자면,

이산수학은 불연속적이고 딱 떨어지는 수를 다루는 수학이고,
이산수학은 현실의 문제를 풀기위해,
문제의 핵심만 남기는 추상화를 하고,
이걸 계산 가능한 수식으로 표현하는 수학적 모델링을 하는 과정을 거친다.

라고 할 수 있다.

이러한 이산수학은 컴퓨터 과학 분야의 수학적 바탕이라고 할 수 있는 자료구조, 알고리즘, 운영체제 등을 확립하고,

최근에 대두된 인공지능의 이론과 활요의 바탕이 되었기에, AI를 포함한 CS 분야에서 매우 중요한 학문이라고 할 수 있다.

럭포터가 cs를 먹고 있다 이게 말이 되는 행동일까 과연

롤로 따지면 cs막타 와 같은 영역이다.

이제 이 이산수학의 문제 해결 방식을 더 자세하게,

이산수학에서 문제 해결을 위해서 어떤 효율적인 방법들을 쓰는지와

효과적인 모델링 방법에 대해 알아보겠다.

3. 문제 해결을 위한 효율적인 방법

이산수학은 결국 문제를 컴퓨터나 기계로 얼마나 효율적으로 푸는지에 관한 학문이기에,

아래와 같은 흐름으로 좀 더 효율적으로 문제를 풀 수 있다.

문제의 기본 개념과 원리를 파악하여 아이디어를 스케치함
다양한 관점으로 문제의 핵심에 접근함
어렵게 보이는 문제를 단순화시키는 방법을 점검함
자유로운 생각으로 문제 해결의 실마리를 이끌어냄
복잡한 문제를 여러 부분으로 잘게 나누어 해결함
모델링의 방법으로 문제를 해결함

이걸 현실에 SDLC에 적용해서 예시를 들면,

클라이언트의 요구사항을 듣고, 회의실 화이트보드에 전체 시스템이 굴러갈 밑그림을 그리는 초기 기획
"이걸 OOP로 짤까? 데이터베이스는 RDB로 설계할까?" 등등 어떤 기술과 관점으로 문제를 풀지 구조를 고민
프로그램에 꼭 필요한 핵심 속성만 뽑아내어 Class로 설계
뼈대가 잡힌 상태에서 "아, 여기서는 이런 루프문을 돌리면 되겠다" 같이 코딩의 구체적인 로직을 떠올림.
수만 줄짜리 스파게티 코드로 짜지 않고, 유지보수가 쉽도록 여러 개의 독립적인 함수나 컴포넌트로 잘게 쪼갬.
잘게 쪼개진 아이디어들을 실제 컴퓨터가 연산할 수 있는 수학적 구조(방정식, 이진 논리, 그래프 등)로 완벽하게 매핑하고, 최종 코드를 완성하여 실행

이라고 할 수 있다.

4. 효과적인 문제 해결 모델링

이제 이걸 모델링 과정에서 보면, 아래의 6단계가 나온다.

1단계 [주어진 문제] : 해결해야 할 문제 상황이 주어짐
2단계 [아이디어 스케치] : 전제 조건과 상황에 대해 아이디어를 스케치함
3단계 [추상적 모델 구상] : 불필요한 것을 단순화하여 모델을 구상함 (추상화)
4단계 [수학적 모델링] : 추상적 모델을 수학적 구조에 매핑함
5단계 [문제 풀이 및 적용] : 계산 결과를 원래 문제에 적용해 봄
6단계 [해결] : 문제가 해결됨

이거는 그냥 외워두고 앞으로 쓰는게 좋을 것 같다.

[AI] 학부 1학년의 트랜스포머 만들기 도전.....???

kgr0831 — Sun, 29 Mar 2026 23:01:12 +0900

애해해해햏

안녕하세요! 올해 3월 숭실대 AI소프트웨어학부로 갓 입학한 1학년 말하는 감자입니다.

오늘은 지난 크래프톤 AI R&D 해커톤 예선 1일차 문제였던 MultiplierBoard 제작기를 써보려고 합니다.

(문제 공개 허락 받았어요!!)

솔직히 학부 1학년이라 아직 선형대수고 ML/DL이고 머릿속에 제대로 안 들어왔지만...

그동안 Unity나 Pintos 만지던 짬바?로 어떻게든 비벼본 후기입니다.

에반게리온 언제쯤 볼 수 있을까

가보자고~!!!!!!!

세상에서 제일 쪼잔한 계산기 만들기

목표는 심플했습니다.

6비트 숫자 두 개를 넣으면 12비트 정답을 뱉는 AI 계산기 만들기!!

근데 조건이 좀 변태(?) 같습니다.

말이 됩니까 이거를 4시간 안에 어케해요 나 1학년이라고요 ㅠㅠ

AI의 뇌세포라고 할 수 있는 파라미터를 99%의 정확도를 보장하는 선에서 최소한으로... 하랍니다... 흑흑흑.,.

보통 이런 짓을 하려면 기본 5만 개는 깔고 가야 한다고 생각하는데,

뇌 용량을 1/10 수준으로 극한의 다이어트를 시켜야 했습니다.

다...다이어트요?????? 그게 무슨 말씀이십니까???

아니 제 몸도 다이어트 하기 빡센데, AI를 다이어트 시키라고 하십니다....

그래도 다이어트를 해야하는 저의 생존 전략은 바로 '노가다 로직 최적화' 였습니다.

(1) 맵 재활용의 달인 => 유니버셜 트랜스포머

곱셈할 때 제일 킹받는 게 올림수 넘기는 거잖아요?

기존 AI들은 이걸 해결하려고 스테이지를 일렬로 무식하게 길게 지어놓습니다.

메모리 거지 흑흑흑..

하지만 우린 메모리가 없죠.

그래서 아주 똑똑한 레이어 딱 하나만 만들고, 데이터를 그 안에서 10번 반복해서 뺑뺑이 돌렸습니다.

Unity의 Update() 루프처럼 10번 사이클을 돌며 일의 자리 올림수를 십의 자리로,

백의 자리로 끝까지 배달하게 만든 겁니다.

(참고로 테스트할 때 6번 미만으로 돌렸더니 올림수 배달 사고가 나서 상위 비트 정확도가 10% 밑으로 떡락하더군요... )

(2) 시력 포기하고 픽셀 아트 깎기 => Low-Rank Attention

AI가 정답을 맞히려면 어떤 숫자끼리 곱해야 할지 짝꿍을 찾아야 합니다.

(i+j=k 라는 인덱스 규칙이 있음)

이걸 다 찾아보려면 눈이 너무 피곤하니까, 어텐션 랭크를 10에서 6으로 확 낮춰버렸습니다.

이것도 추상화..?? 일까요..???

마치 고해상도 그래픽을 포기하고 핵심 윤곽선만 남긴 픽셀 아트 느낌?? 이죠

d_{model} = 24 라는 좁쌀만 한 시야 안에서도,

로우 랭크 기법 덕분에 엉뚱한 거 안 보고 찰떡같이 필요한 비트 쌍만 골라냅니다.

(3) 깐깐한 입구컷 => SwiGLU FFN

단순 무식한 계산기 대신 SwiGLU라는 아주 깐깐한 게이트를 달았습니다.

이 녀석은 고성능 if문이나 논리적 AND 게이트처럼 작동해서,

쓸모없는 숫자 조합은 가차 없이 필터링하고 진짜 유효한 부분합만 더해줍니다.

d_{ff}=40의 아담한 사이즈로 이진 로직을 완벽하게 소화해냈죠.

진짜 레전드는 그로킹

제가 목표로 정한 파라미터가 4.6k밖에 안 되다 보니,

10만 개나 되는 훈련 데이터를 그냥 무지성으로 암기하는 건 물리적으로 불가능했습니다.

처음에 AI는 정답을 못 외워서 아무거나 찍어대며 처참하게 틀렸습니다.

그런데 계속 굴리다 보니... 어느 순간 모델이 억지 암기를 포기하고

'곱셈의 수학적 원리' 자체를 스스로 깨달아버렸습니다!!

정확도가 바닥을 기다가 갑자기 99% 이상으로 떡상하는 걸 보면서 진짜 소름이 쫙 돋았습니다.

머리가 너무 작아서 차마 외우지는 못하고, 그냥 수학을 이해해버린 우리 AI... 대견하다 녀석.

도티낳음.

20살에 육아의 기쁨을 알아버렸습니다.

마무리

5060으로도 이게 가능하게 해준 대 젠슨황님께 감사를..ㅠㅠ

제 오멘 16으로도 잘 돌아가서 모델 훈련하고 테스트하는 맛이 아주 쏠쏠했습니다.

아직 선형대수 짬바는 부족했지만, 한정된 자원 안에서 구조를 쥐어짜 내어 극한의 효율을 뽑아낸 엄청난 경험이었네요.

클로드 코드 + 안티그래비티 딸깍 킼킼ㅋㅣㅋ킼ㅋㅋㅋ

물론 엄청엄청 LLM의 도움을 받았지만, 뭔가 트랜스포머를 직접 구현하고 경량화 한다는게 참 재밌는 경험이었습니다.

평소 링크드인에서 구글 관련 DL 정보글들을 읽어둔게 여기서 도움이 되네요.

이상, 1학년의 우당탕탕 트랜스포머 압축기였습니다!

질문은... 전공 수업 좀 더 듣고 와서 받겠습니다.

근데 3학년때 받는걸로 ㅎㅎ

돔황차

이제 도망갈게요.

[KRAFTON AI R&D HACKATHON] DAY1.html

0.02MB

[잡다한 궁금증] 인터넷 에러 났다고 매번 다시 보내주는 거 아니었음?

kgr0831 — Sun, 15 Mar 2026 21:43:21 +0900

안녕하세요!

최근 전공 과제로 '2차원 패리티 비트를 활용한 오류 검출 알고리즘'을 빡빡하게 설계하면서

골머리를 앓았던 이슈가 하나 있었는데요.

오류를 복구하는 방식에 대한 제 고정관념이 산산조각 난 경험이었습니다.

과제를 해결하기 위한 알고리즘을 설계하다 보니,

"에러가 나면 수신자가 복잡한 수학 연산을 돌려서 직접 오류 위치를 찾아 복구해야 한다"

라는 결론에 도달하게 되었습니다.

생각해 보니, 저는 인터넷 통신에서 데이터가 깨지면 무조건 송신자한테

"야, 통신 불량이다! 다시 보내!" 라고 요청하는 아주 정직한 방식만 고수한다고 굳게 믿고 있었더라고요.

"어차피 다시 보내달라고 하면 되는데, 왜 수신자가 오버헤드를 감수하면서까지 빡빡하게 연산을 돌려 스스로 고쳐야 하는 거지?"

과제를 마친 후 이 찝찝함을 참지 못하고 파헤쳐 본 가벼운 리서치 결과, 제 오해를 바로 잡아준 통신 최적화 기법,

FEC(전진 오류 수정)와 현대 네트워크 프로토콜(TCP/UDP)의 차이에 대해 제 개인 개발일지에 공유해 봅니다.

1. 빡빡하게 수학으로 묶어서 스스로 고치는 방식, FEC

제가 과제로 설계했던 것처럼 패리티를 이중 삼중으로 덧대어 검사하는 방식의 목표는 단 하나입니다.

데이터가 망가졌을 때 송신자에게 다시 보내달라고 징징대지 않는 것이죠.

송신자가 데이터를 보낼 때 가로, 세로, 심지어 대각선까지 빡빡하게 패리티(검사 힌트)를 잔뜩 붙여서 보냅니다.

그러면 수신자는 에러가 났을 때 연립방정식 풀듯이 교차점을 찾아내서 스스로 데이터를 원상복구해 버립니다.

이런 훌륭하고 독립적인 방식을 통신 공학에서는 FEC(Forward Error Correction)라고 부릅니다.

하지만 이 방식은 치명적인 비효율성을 안고 있습니다. 진짜 데이터를 지키겠다고 검사식을 잔뜩 붙이다 보니,

전체 전송량이 너무 무거워져서 결국 '검사용 패리티 비트' 자체가 통신 중 깨져버리는 역효과가 나기 쉽다는 겁니다.

2. 현대 네트워크는 어떻게 에러를 대할까? TCP vs UDP

그렇다면 우리가 평소에 쓰는 인터넷 통신은 어떨까요?

리서치를 통해 알아낸 현대 네트워크의 오류 처리 방식은 크게 두 가지로 나뉩니다.

(1) TCP - 꼼꼼한 A/S 고객

무거운 패리티 연산 대신, 데이터가 멀쩡한지만 확인하는 아주 가벼운 꼬리표만 붙여 보냅니다.

에러가 나면 쿨하게 버리고 송신자에게 "다시 보내!"라고 재전송을 요청하죠.

파일 다운로드처럼 데이터의 무결성이 중요한 상황에서 쓰는 정직한 방식입니다.

(2) UDP - 일단 던지는 쿨가이

속도가 생명입니다.

에러가 나면? 복구고 뭐고 그냥 쓰레기통에 버립니다.

재전송 요청도 안 합니다. 그냥 뒤따라오는 최신 데이터를 1밀리초라도 빨리 화면에 띄우는 데 집중하죠.

실제 통신망에서는 저처럼 무겁게 16비트 검사식을 돌리는 대신, 상황에 맞춰 철저하게 분업화를 하고 있었습니다.

3. 리서치 과정에서 얻은 소소한 깨달음

사실 오랫동안 통신의 지배자는 데이터 무결성을 보장하는 TCP였습니다.

하지만 롤 한타나 배틀그라운드 같은 실시간 게임 환경에서는 얘기가 다릅니다.

과거의 위치 데이터가 깨졌다고 꼼꼼하게 재전송을 기다리면 핑이 튀고 캐릭터가 멈춰버리니까요.

그래서 요즘은 무조건 빠른 UDP가 게임이나 실시간 스트리밍 분야의 대세로 떠오르고 있습니다.

근데 가만히 생각해 보면,

속도 때문에 일단 냅다 던지고 보는 UDP 환경이야말로 제가 과제로 설계했던 FEC 방식이 절실하게 필요한 곳이더라고요.

게임 서버에서 UDP로 최신 데이터를 미친 듯이 쏘면서 그 사이에 빡빡한 FEC 연산 힌트들을 섞어 보내면,

클라이언트는 재전송 딜레이 없이 즉각적으로 깨진 데이터를 자체 복구하며 화면을 부드럽게 이어갈 수 있으니까요.

'에러 나면 무조건 다시 받으면 된다'는 단편적인 고정관념에서 벗어나,

네트워크 환경(속도 vs 무결성)에 따라 에러를 다루는 통신 공학의 치열한 최적화 방식을 알게 된 아주 유익한 리서치였습니다.

긴 글 읽어주셔서 감사합니다!

[잡다한 궁금증] Python은 인터프리터 언어인데 컴파일을 한다고?

kgr0831 — Wed, 11 Mar 2026 14:58:25 +0900

오늘부로 신설 코너를 하나 개설했습니다 ㅎㅎ

바로 제가 그때 그때 생기는 잡다한 여러 분야의 궁금증을 해결하기 위해 리서치 하여 글로 남기는 잡다한 궁금증 코너입니다.

신설 코너도 잘 부탁드립니다 흐흐흫

오늘의 궁금증은 최근에 있었던 전공 강의로 파이썬 기초를 듣는 과정에서 발생했습니다.

요즘 수업을 들으면서 제 기존 지식과 정면으로 충돌해 머릿속에 물음표를 띄운 이슈가 하나 있었는데요.

바로

"Python 인터프리터가 코드를 실행하는 과정에서 일부가 컴파일된다"

라는 교수님의 설명이었습니다.

생각해 보니, 저는 Python이 소스 코드를 바이트 코드로 바꾼 뒤 무조건 1줄씩 순차적으로 통역하는 아주 정직한 방식만 고수한다고 굳게 믿고 있었더라고요.

"어떻게 1줄씩 번역하는 인터프리터 언어에서 컴파일이 일어난다는 거지?"

수업이 끝난 후 이 찝찝함을 참지 못하고 파헤쳐 본 가벼운 리서치 결과, 제 오해를 바로 잡아준 Python의 숨겨진 최적화 기법인

JIT 컴파일에 대해 공유해 봅니다.

1. 1줄씩 해석하는 방식은 생각보다 무겁다.

Python 은 코드를 바이트 코드로 변환해 한 줄씩 통역하며 실행합니다.

Java와 같이 OS를 타지 않는 유연한 방식이죠.

하지만 수만 번 반복되는 루프문 안에서 매번 똑같은 통역 연산을 수행한다면 비효율의 끝판왕이 될 겁니다.

그래서 파이썬 생태계는 이 끔찍한 연산량을 줄이면서도 유연함을 유지할 수 있는 똑똑한 우회로를 찾았습니다.

2. 반복되면 번역하고, 아니면 통역해라

제가 리서치를 통해 알아낸 이 최적화 기술, JIT 컴파일의 목표는 단 하나입니다.

무거운 실시간 통역 연산을 최대한 안 쓰는 것이죠.

파이썬 코드가 실행될 때, 뒤에서 조용히 실행 패턴을 감시하다가 엄청나게 반복되는 Hot Code 구간을 발견하면 전략을 바꿉니다.

상황 A (반복이 적은 코드): 몇 번 실행되지 않는 함수라면, 기존처럼 인터프리터가 한 줄씩 통역하며 지나갑니다. 이땐 컴파일을 하는 오버헤드가 더 크기 때문입니다.
상황 B (핫 코드 발견): 특정 루프나 함수가 미친 듯이 반복되면, 그 순간 통역을 멈추고 해당 구간 전체를 CPU가 바로 읽을 수 있는 '기계어'로 한 번에 컴파일해 버립니다.

프로그램 실행 시간의 80% 이상은 핵심 반복문 20%에서 발생하니까요.

이 구조를 통해 실행 속도를 눈에 띄게 끌어올리게 됩니다.

근데 가만히 생각해 보면, 이 방식은 운영체제에서 가상 메모리를 관리할 때 사용하는 OS의 캐시와 그 원리가 완벽하게 똑같습니다.

운영체제가 엄청나게 느린 보조기억장치에서 데이터를 퍼오는 불상사인 페이지 폴트를 막기 위해,

한 번 읽어온 데이터를 속도가 빠른 메인 메모리의 페이지 캐시에 쟁여두고 바로바로 꺼내 쓰잖아요?

파이썬도 마찬가지입니다.

매번 바이트 코드를 한 줄씩 해석하는 느린 통역 과정을 피하기 위해,

한 번 번역해 둔 기계어를 메모리에 쟁여두고 꺼내 쓰는 것이죠.

하드웨어든 소프트웨어든 느린 병목 작업을 피하기 위해 결과물을 빠른 공간에 미리 모아둔다는

컴퓨터 공학의 캐싱 철학을 그대로 따르고 있는 셈입니다.

그래서 파이썬이 번역된 기계어를 저장해 두는 이 임시 공간의 공식 명칭도 코드 캐시라네요.

3. 리서치 과정에서 얻은 소소한 팁

사실 오랫동안 기본 CPython에는 이 기능이 없어서 파이썬은 무조건 느리다는 편견이 있었습니다.

속도를 내려면 PyPy 같은 대안을 써야만 했죠.

하지만 최신 파이썬 3.13 버전부터는 공식적으로 이 동적 컴파일 기능이 도입되기 시작했다고 합니다.

'1줄씩 통역한다'는 단편적인 고정관념에서 벗어나,

내부적으로 성능을 끌어올리기 위한 파이썬의 치열한 최적화 방식을 알게 된 유익한 리서치였습니다.

긴 글 읽어주셔서 감사합니다!

[Unitrio 개발일지] - 무거운 A* 알고리즘 100배 가볍게 쓰기

kgr0831 — Tue, 10 Mar 2026 18:35:52 +0900

안녕하세요!

최근 소속된 인디 게임 개발 팀 'Unitrio'에서 2D 탑다운 게임 프로젝트를 한창 진행하고 있습니다.

요즘 개발을 하면서 가장 골머리를 앓았던 이슈가 하나 있었는데요.

바로 맵에 몬스터를 수십 마리 풀었더니 프레임이 뚝뚝 떨어지는 최적화 문제였습니다.

원인을 분석해 보니, 몬스터들이 플레이어를 쫓아가기 위해 매 프레임마다 무거운 A* 알고리즘을 돌리고 있더라고요.

"어떻게 하면 몬스터를 바보로 만들지 않으면서 연산량을 줄일 수 있을까?"

치열한 리서치와 테스트 끝에, 이번 프로젝트에 최종 적용하기로 한 실무 표준 최적화 기법,

FSM + Raycast + A* 하이브리드 추적 AI 구축 과정을 제 개인 개발일지에 공유해 봅니다.

1. A* 알고리즘은 생각보다 무겁다.

A* 알고리즘은 타일맵 기반의 2D 게임에서 목적지까지의 최단 경로를 찾아주는 훌륭한 알고리즘입니다.

하지만 몬스터 수십 마리가 매 프레임마다 길찾기 연산을 수행한다면 CPU는 금방 비명을 지르게 됩니다.

그래서 몬스터의 역할을 아래와 같이 뇌, 눈, 다리 세 가지로 완벽하게 분업화하기로 했습니다.

FSM (뇌): 몬스터의 현재 상태(순찰, 추적 등)를 통제하는 뼈대.
Raycast (눈): 몬스터와 플레이어 사이의 장애물을 판별하는 가장 가벼운 연산.
A* & Vector (다리): 시야 확보 여부에 따라 '단순 직선 이동'을 할지 'A* 우회'를 할지 결정.

2. 보이면 뛰고, 안 보이면 길을 찾아라

제가 고안한 하이브리드 AI의 목표는 단 하나입니다.

무거운 A 알고리즘을 최대한 안 쓰는 것이죠.

몬스터가 플레이어를 발견해 추적 상태에 돌입하면,

무작정 길찾기를 시작하는 대신 플레이어를 향해 투명한 레이저를 쏩니다.

상황 A (시야가 뚫림): 중간에 벽이 없다면 A* 연산을 아예 끄고, 방향 벡터만 구해서 직선으로 뛰어갑니다. 연산량이 사실상 상수 시간 O(1)에 수렴합니다.
상황 B (벽에 가려짐): 플레이어가 코너로 숨어 레이저가 벽에 막히면, 그때서야 비로소 A*를 호출해 우회 경로를 계산합니다.

저희 게임 플레이의 80% 이상은 시야가 트인 공간에서 이루어집니다.

이 구조를 도입하기만 해도 프로젝트의 CPU 오버헤드를 눈에 띄게 줄일 수 있게 되었습니다.

3. 실제 프로젝트에 적용한 C# 핵심 코드

매 프레임마다 Update를 통해 시야를 검사하는 것도 낭비라고 판단하여,

코루틴을 사용해 0.2초마다 AI가 상황을 판단하도록 최적화했습니다.

제가 다듬은 뼈대 코드를 공개합니다.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class MonsterAI : MonoBehaviour
{
    public enum State { Idle, Patrol, Chase, Attack }
    public State currentState = State.Idle;

    public Transform player;
    public LayerMask targetLayerMask; 
    public float moveSpeed = 3f;
    
    private bool isPathfinding = false;

    void Start()
    {
        StartCoroutine(UpdateChaseLogicRoutine());
    }

    IEnumerator UpdateChaseLogicRoutine()
    {
        while (true)
        {
            if (currentState == State.Chase && player != null)
            {
                PerformHybridChase();
            }
            yield return new WaitForSeconds(0.2f); // 0.2초마다 추적 판단을 가동하는 코루틴
        }
    }

    void PerformHybridChase()
    {
        Vector2 dirToPlayer = (player.position - transform.position).normalized;
        float distToPlayer = Vector2.Distance(transform.position, player.position);

        RaycastHit2D hit = Physics2D.Raycast(transform.position, dirToPlayer, distToPlayer, targetLayerMask);

        if (hit.collider != null && hit.collider.CompareTag("Player"))
        {
            isPathfinding = false;
            MoveTowards(player.position); 
        }
        else
        {
            if (!isPathfinding)
            {
                isPathfinding = true;
                // AStarManager.Instance.GetPath(transform.position, player.position); 호출
            }
            FollowAStarPath(); 
        }
    }

    void MoveTowards(Vector2 targetPos)
    {
        transform.position = Vector2.MoveTowards(transform.position, targetPos, moveSpeed * Time.deltaTime);
    }

    void FollowAStarPath()
    {
        // A* 경로를 순차적으로 따라가는 로직 구현부
    }
}

4. 개발 과정에서 얻은 소소한 팁

몬스터의 떨림 현상 방지: 코너를 돌 때 1프레임 단위로 시야가 닿았다 안 닿았다를 반복하면 몬스터가 덜덜 떱니다.

위 코드처럼 코루틴 주기를 .2초 정도로 두어 딜레이를 주면 훨씬 묵직하고 자연스러운 움직임이 완성됩니다.

이 방식 덕분에 Unitrio 프로젝트의 몬스터 AI 최적화 큰 산을 하나 넘었습니다.

긴 글 읽어주셔서 감사합니다!

Unitrio가 출시할 게임을 기대해주세요!

정글 수료 1달 후의 근황과 앞으로의 계획 1달 후의 근황과 앞으로의 계획

kgr0831 — Thu, 5 Mar 2026 22:09:21 +0900

안녕하세요

그동안 잘 지내셨죠?

정글도 이제 수료한지 1달이 넘어가는 지금, 제가 어떻게 살아왔는지에 대해, 앞으로는 뭘 할건지에 대해 써보고자 합니다.

정글을 수료한 직후 저는 후련한 마음 보다는 앞으로 무엇을 해야할지에 대한 막막함이 가득했습니다.

그렇게 몇일을 놀았습니다.

술을 마시거나,,, 롤을 한다거나,, 한 1주 정도는 재밌더라고요.

하지만 1주가 지나니 시간도 아깝고, 취업을 준비하고 목표를 위해 달려가는 남들과 달리 저는 앞으로 정말 뭘 해야할지 모르겠어서

막막함만 가득했습니다.

그러다 문득, 제가 그동안 치열하게 만들어왔던 결과물들을 다시 돌아보게 되었습니다.

정글에서 밤낮없이 매달렸던 실시간 통역 및 무한 캔버스 협업 플랫폼 'EUM',

소켓 통신을 활용해 만들었던 실시간 PVP 웹 게임 '정글몬' 등등....

돌아보면 저는 항상 무언가를 기획하고, 개발하고, 완성해내는 과정 자체를 진심으로 즐기고 있었습니다.

다시 찾은 방향성: 2D 인디 게임 개발

막막함을 털어내기 위해 제가 선택한 건 결국 다시 '게임'이었습니다.

현재는 마음이 맞는 팀원들(프로그래머 2명, 그래픽 디자이너 1명)을 꾸려 2D 인디 게임 개발을 시작했습니다.

방황하던 1주일이 무색하게도, 다시 픽셀 아트와 코드 사이를 오가며 게임을 만드는 지금이 가장 저다운 시간이라는 생각이 듭니다.

앞으로의 계획: 숭실대학교 진학과 게임 AI 연구

작년 말에 합격한 숭실대학교 AI소프트웨어학부에 진학하여 본격적으로 학업을 이어갈 계획입니다.

제가 앞으로 가장 깊게 파고들고 싶은 분야는 한정된 하드웨어 리소스 환경에서 온디바이스 SLM을 효율적으로 게임에 도입하는

방법입니다.

크래프톤의 CPC처럼 유저와 자연스럽게 상호작용하며 완전히 새로운 경험을 주는 AI를 개발하는 것이 제 당면한 목표입니다.

궁극적인 목표

제 궁극적인 꿈은 아오누마 에이지, 이와타 사토루 등 제가 깊이 존경하는 개발자들이 만들어낸 '젤다의 전설' 시리즈처럼,

누군가에게 인생 최고의 경험을 선사하는 훌륭한 게임을 제 손으로 직접 개발하는 것입니다.

그리고 언젠가는 제가 동경하는 모노리스 소프트나 크래프톤에서 그 꿈을 온전히 펼쳐보고 싶습니다.

아직 갈 길이 멀지만, 막연했던 불안감은 이제 명확한 목표로 바뀌었습니다.

앞으로 이 블로그에는 진행 중인 인디 게임 개발기부터, AI를 게임에 접목하기 위한 제 치열한 고민과 공부 기록들을 꾸준히

남겨보려 합니다.

앞으로의 여정도 지켜봐 주시고, 많은 응원 부탁드립니다!

[Week17 - 나.만.무] 정신 승리,,,,

kgr0831 — Thu, 8 Jan 2026 18:03:25 +0900

안녕하세요!

지난 포스팅에서 WebGPU랑 Pixi.js 써서

"와! 내 화이트보드 렌더링 진짜 빠르다! 144Hz 방어 개꿀!"

하면서 신나했던 거 기억하시나요?

네, 사실 그건 반쪽짜리 승리였습니다.

기능 좀 더 붙이려고 코드를 뜯어보다가, 제가 만든 게 화이트보드가 아니라 그냥 성능 좋은 그림판이라는 걸 깨달았거든요.

오늘은 그 처절한 깨달음과, 이걸 어떻게 뜯어고칠지 행복회로를 돌려본 이야기를 풀어보려고 합니다.

1. 예쁜 쓰레기였던 건에 대하여

지금 제 프로젝트의 상태를 한 줄로 요약하면 이렇습니다.

"그리는 건 빛의 속도인데, 그린 걸 다시 잡을 수가 없음."

현재 방식은 비트맵 방식이라서, 화면에 선을 긋는 순간 그건 그냥 배경이랑 한 몸이 되어버립니다.

포토샵에서 레이어 하나에 다 때려 박고 저장한 거랑 똑같죠.

선을 클릭해서 옮기거나 지우고 싶은데, 컴퓨터 입장에서는 그게 선인지 그냥 배경 점인지 알 길이 없는 겁니다.

게다가 이걸 해결하겠답시고

"그럼 그려진 좌표 다 기억했다가 마우스 클릭할 때마다 반복문 돌려서 찾지 뭐"

라고 생각했다가 바로 접었습니다.

객체가 1만 개쯤 되면 마우스 클릭 한 번에 CPU가 비명을 지를 게 뻔하거든요.

결국 지금 상태로는 그냥 낙서장 그 이상 그 이하도 아니게 된 거죠.

2. 하이브리드 베이킹 : 박쥐 작전

그래서 고민 끝에 내린 결론은 이겁니다.

"평소엔 비트맵인 척하고, 필요할 때만 벡터인 척하자."

이걸 있어 보이는 말로 하이브리드 베이킹이라고 이름 붙였습니다.

작동 방식은 꽤 교활합니다.

평상시에는 그냥 화면에 보이는 영역을 타일 모양 이미지로 구워버립니다.

이러면 GPU는 그냥 이미지 한 장만 그리면 되니까 세상 편하죠.

근데 사용자가 마우스를 슬쩍 가져가면?

그때 그 근처에 있는 녀석만 뿅 하고 벡터 객체로 변신시킵니다.

수정이 끝나면?

다시 이미지로 구워서 박제해버리고요.

이렇게 하면 수정도 할 수 있으면서, 평소 렌더링 성능은 그대로 유지할 수 있습니다.

마치 구글 지도가 타일 이미지를 불러오는 방식이랑 비슷하게 무한 캔버스를 구현할 예정이라 메모리 터질 걱정도 덜었습니다.

3. 쿼드트리 : 술래잡기 최적화

앞서 말했던 CPU 비명 지르는 문제도 해결책을 찾았습니다.

1만 개의 객체를 for문 돌려서 "너 나랑 부딪혔니?" 하고 물어보는 건 너무 무식한 방법이잖아요.

그래서 쿼드트리를 도입하기로 했습니다.

쉽게 말해서 운동장에 학생 1만 명을 세워두고 김철수를 찾는다고 칩시다.

일렬로 세워서 한 명씩 확인하는 게 기존 방식이라면,

쿼드트리는 운동장을 4등분, 또 4등분... 이렇게 구역을 나눠서 "1구역에 있는 사람 손!" 하고 찾는 겁니다.

이러면 객체가 10만 개가 되어도 순식간에 클릭한 녀석을 찾아낼 수 있습니다. 이제 렉 걸릴까 봐 쫄지 않아도 됩니다.

4. 앞으로의 삽질 계획

설계도는 나왔으니 이제 공사를 시작해야겠죠?

대충 이런 순서로 진행해볼 생각입니다.

첫 번째는 신분 세탁입니다.

지금은 그냥 좌표 덩어리인 데이터들에 ID도 붙여주고, 위치, 회전, 크기 같은 정보를 가진 어엿한 객체로 승격시켜줘야 합니다.

두 번째는 눈속임 구현입니다.

이미지 붙여넣기 기능을 먼저 만들고,

이걸 드래그할 때 진짜 옮기는 게 아니라 투명한 가짜(고스트)가 따라다니게 해서 가볍게 구현해볼 생각입니다.

세 번째가 진짜 보스전인데,

앞서 말한 쿼드트리랑 기즈모(크기 조절 핸들)를 붙여서 진짜 파워포인트처럼 도형을 요리조리 만질 수 있게 만드는 겁니다.

이때 전체를 다시 그리는 게 아니라 변환 행렬값만 싹 바꿔치기하는 게 포인트고요.

여기까지 성공하면 미니맵이나 레이저 포인터, 무한 실행 취소 같은 기능은 그냥 보너스 게임처럼 쉽게 붙일 수 있을 것 같습니다.

5. 마치며

처음엔 그냥 "선 긋는 거? 쉬운 거 아님?" 하고 덤볐다가 아주 호되게 당하고 있습니다.

그래도 다행인 건, 이렇게 구조를 바꾸면 네트워크로 데이터를 보낼 때도 캔버스를 통째로 보내는 짓을 안 해도 된다는 겁니다.

그냥 "야, 3번 객체 오른쪽으로 5칸 이동함" 이렇게만 보내면 되니까요.

당분간은 이미지 붙여넣기 같은 쉬운 기능부터 붙이면서 정신 승리 좀 하다가,

조만간 쿼드트리랑 씨름하고 돌아오겠습니다.

진정한 협업 툴로 거듭나는 그날까지, 제 삽질은 계속됩니다. 지켜봐 주세요!

즐코딩!

[Week15 - 나.만.무] 초보 개발자의 WebGPU 찍먹기 (feat. 144Hz 화이트보드 도전)

kgr0831 — Tue, 23 Dec 2025 16:33:52 +0900

안녕하세요!

요즘 나만의 무기 갖기 프로젝트로서 화상 회의 웹사이트 프로젝트를 진행하면서,

매일매일 새로운 벽을 만나고 있는 중입니다.

오늘은 이 프로젝트에서 제게 기술적 챌린지라고 할 수 있는 '화이트보드' 기능을 구현하는 도중에 겪은 고민과,

결국 WebGPU라는 기술을 선택하게 된 과정을 정리해보려고 합니다.

처음엔 "그냥 유명한 라이브러리 쓰면 되지 않을까?" 라고 단순하게 생각했었는데,

파고들수록 그게 아니더라고요.

1. 문제 발견 - 우리 CPU가 너무 바빠요.

보통 웹에서 그림판 만들 때 Fabric.js 같은 캔버스 라이브러리를 많이 씁니다.

자료도 많고 편하니까요. 저도 처음엔 이걸로 프로토타입을 만들었는데,

테스트하다가 중요한 문제를 발견했습니다.

바로 CPU 점유율이었습니다.

저희 프로젝트 특성상 화상 통화와 AI 모델이 이미 CPU자원을 꽤 많이 쓰고 있었거든요.

여기에 렌더링까지 CPU에 의존하는 라이브러리를 얹으니까,

마우스가 뚝뚝 끊기는 현상이 발생했습니다.

"화상 통화 품질을 유지하면서 그림도 부드럽게 그릴 순 없을까?"

이 고민 끝에, CPU 대신 놀고 있는 GPU를 활용해야겠다는 결론을 내렸습니다.

2. WebGL vs WebGPU

GPU를 쓰려면 보통 WebGL을 떠올리죠.

그런데 자료를 찾아보니 WebGL 구조상 유효성 검사 때문에 CPU 오버헤드가 발생한다는 걸 알게 됐습니다.

쉽게 말해, GPU한테 일을 시킬 때마다 CPU가 "이거 맞아? 문제없어?" 하고 계속 검사를 하는 구조더라고요.

CPU 부담을 줄이려고 GPU를 쓰는 건데, 검사 때문에 CPU가 또 일을 하면 안 되잖아요?

그래서 눈을 돌린 게 바로 WebGPU입니다.

이 WebGPU는 초기 설정 때 한 번만 검사하고, 렌더링할 땐 검사 없이 바로 GPU로 쏩니다

마치 Pintos 프로젝트에서 Alarm Clock을 구현할 때 Busy Waiting에서 Timer Interupt 를 통한 확인 방식으로 바꾼 것 같이,

검사를 줄이는 방식이죠.

그 결과, CPU 오버헤드가 거의 0에 수렴합니다.

최신 기술이라 자료가 좀 부족하긴 하지만, 저희 프로젝트의 병목 현상을 해결할 유일한 열쇠라는 확신이 들었습니다.

3. Pixi.js + WGSL 하이브리드

WebGPU를 쓰기로 했지만, 바닥부터 모든 걸 구현하기엔 1달이라는 시간이 부족하고 난이도도 너무 높았습니다.

그래서 생산성과 성능 두 마리 토끼를 잡기 위해 전략을 짰습니다.

첫번째로, 기본 기능은 Pixi.js v8을 활용합니다.

객체 관리나 이벤트 처리 같은 기본적인 부분은 WebGPU를 지원하는 Pixi.js v8 엔진의 힘을 빌리기로 했습니다.

잘 만들어진 바퀴를 다시 만들 필요는 없으니까요.

두번째로, 특수 효과는 커스텀 쉐이더(WGSL)로 직접 구현합니다.

대신 프로젝트의 핵심인 '잉크 번짐'이나 '파티클' 같은 고성능 효과는 엔진 기능만으론 부족했습니다.

이 부분은 제가 직접 WGSL을 공부해서 쉐이더 코드를 짜기로 했습니다.

조금 어렵긴 하겠지만, 렌더링 파이프라인을 직접 제어해 볼 수 있는 좋은 기회라고 생각했습니다.

4. 이유 있는 고집

이렇게 아키텍처를 잡고 나니 기대되는 효과가 명확해졌습니다.

자원 격리: 화상 통화는 CPU가, 그림은 GPU가 담당하니 서로 간섭이 없습니다.
성능 확보: 저사양 환경에서도 144Hz의 부드러운 사용성을 기대할 수 있습니다.

남들이 잘 안 쓰는 기술을 도입하는 게 조금 두렵기도 하지만,

왜 이 기술을 써야 하는가? 에 대한 답이 명확하기에 즐겁게 도전해보고 있습니다.

열심히 쉐이더 깎아서, 다음엔 멋진 결과물 들고 오겠습니다. 읽어주셔서 감사합니다!

아 맞다 여러분 저 숭실대 AI소프트웨어 합격했어요!!!!!!

즐코딩!!!

[Week14 - 나.만.무] 로딩 0.1초 줄여보겠다고 밤샌 썰 푼다.

kgr0831 — Tue, 16 Dec 2025 16:06:35 +0900

살려주세요.

...가 아니라,

반갑습니다. (말투 오늘부터 바꿔봄...)

오랜만에 생존 신고합니다.

그동안 여러가지... Pintos나... 프레임 워크 공부하며 살았습니다.

어제는 저희가 만든 Tistory의 클론 코딩 프로젝트인 Snuggle의 피드 기능을 깎느라 도 닦는 시간을 좀 보냈습니다.

"아니, 그냥 글 목록 가져와서 보여주는 게 뭐가 어렵다고 유난임?"

이라고 하실까 봐 미리 변명하자면,

"그냥 보여주는 건" 쉽습니다.

하지만 "겁나 빠르고 부드럽게 보여주는 건" 차원이 다른 문제더군요.

오늘은 제가 피드를 만들면서 겪은 두 번의 멘붕과, 그걸 어떻게 해결했는지에 대한 썰을 풀어볼까 합니다.

서버나 클라이언트가 뭔지 아신다면, 아마 팝콘 씹으면서 보시기 딱 좋을 겁니다.

멘붕 1. 병렬 처리 - "왜 이렇게 느려? 줄 서서 기다리니?"

처음 피드 페이지를 만들었을 때, 저는 아주 정직한 모범생처럼 코드를 짰습니다.

피드 화면에 필요한 건 3가지였거든요.

친구들 새 글 (메인 요리)
내 팔로워 숫자 (사이드 메뉴)
추천 블로그 목록 (디저트)

그래서 클라이언트(브라우저)가 서버한테 심부름을 시켰죠.

[초보자 시절의 나]

"야 서버야, 글 좀 가져와 봐." (1초 대기... 도착!)
"오케이, 이번엔 내 팔로워 숫자 세어 봐." (0.5초 대기... 도착!)
"좋아, 마지막으로 추천 블로그 좀 찾아봐." (0.5초 대기... 도착!)

=> 총 걸린 시간: 2초

사용자가 화면 띄우는 데 2초나 걸립니다.

한국인은 0.5초 안에 안 뜨면 새로고침 누르는 민족인데 말이죠.

가만히 보니, 이건 마치 라면 끓일 때 물이 다 끓을 때까지 스프 봉지도 안 뜯고 멍하니 서 있는 것과 똑같았습니다.

그래서 전략을 바꿨습니다. 순서대로 시키지 말고, 세 명을 동시에 출발시키기로요.

[각성한 나] "자, 지금부터 너네 셋, 동시에 출발한다. 실시!"

(글 가져오는 애) ─전력질주─>
(숫자 세는 애) ─전력질주─>
(추천 찾는 애) ─전력질주─>

이렇게 하니까 제일 느린 놈(1초)이 도착할 때쯤엔,

이미 나머지 둘도 도착해서 숨 고르고 있더군요.

결과적으로 2초 걸리던 게 1초 만에 끝났습니다.

이 단순한 차이가 사용자에게는 "어? 이 사이트 빠릿빠릿한데?"라는 인상을 줍니다.

멘붕 2. N+1 문제 - "서버야, 너 왜 같은 말 10번 식 하니?"

속도는 좀 빨라졌는데, 이번엔 서버 창을 보다가 기절할 뻔했습니다.

글 목록을 가져오는 과정이 너무 비효율적이었거든요.

상황은 이렇습니다. 친구가 쓴 글 10개를 가져왔는데,

글에는 작성자_ID: 'cheolsu'라고만 적혀있고 얼굴 사진이 없었습니다.

그래서 서버가 DB한테 꼬치꼬치 캐묻기 시작합니다.

[답답한 서버의 질문]

(게시글 10개 가져옴) "야 DB야 잘 받았어. 근데 얘네 얼굴 사진이 없네?"

"1번 글 쓴 '철수' 사진 좀 줘." (DB: 여기 있다...)
"2번 글 쓴 '영희' 사진 좀 줘." (DB: 여기.. 있다...) ...
"10번 글 쓴 '민수' 사진 좀 줘." (DB: 아 그만 좀!!!)

글이 10개면 질문을 11번 하고, 글이 100개면 101번을 합니다.

개발자들은 이걸 'N+1 문제'라고 부릅니다.

이러면 사용자가 몰릴 때 DB가 과로로 쓰러집니다.

답답해서 제가 서버 로직을 뜯어고쳤습니다.

한 명씩 묻지 말고, 명단을 만들어서 한 번에 물어보라고 시켰죠.

[똑똑해진 서버]

(게시글 10개 가져옴)

(쓱 훑어봄) "작성자가 철수, 영희, 민수네?"

"야 DB야! 여기 적힌 3명 사진, 한 방에 다 꺼내와!"

(DB: "오, 한 번에 주니까 편하네. 옛다.")

결국 100번 왔다 갔다 할 걸, 단 2번 만에 끝냈습니다.

(1. 글 가져오기 => 2. 작성자들 사진 몽땅 가져오기)

사용자들이 볼 땐 그냥 스크롤 내리면 슥- 하고 뜨는 단순한 피드일 겁니다.

하지만 그 0.1초의 부드러움을 위해,

동시 출발로 시간을 쥐어짜고,

단체 질문으로 DB의 스트레스를 줄여줬다는 사실.

여러분이 편하게 보는 웹사이트는, 개발자의 수명과 맞바꾼 결과물입니다.

그럼 전 또 버그 잡으러 가보겠습니다.

즐코딩 (제발).

[Week10 - Pintos] Pintos에 ELF라니....

kgr0831 — Wed, 26 Nov 2025 10:18:17 +0900

오랜만이다.

압도적 죄송....!!!

그동안 Pintos, WebProxy-lab, Malloc-lab등을 진행하느라, 너무 바빴다.

너무 바쁘다보니,,, 글을 못 썼는데.... 미안하다.. ㅠㅠ

이 캐릭터 누군지 알려주면 500원

제목에 어그로 끌려서 ELF가 이런 미소녀인줄 알고 온 사람들은 살며시 뒤로가기를 누르기 바란다.

오늘 다룰 ELF는 EXE같은 역할을 하는 실행 파일 포맷으로, Linux / Unix 계열 OS에서 사용된다.

오늘은 Pintos 프로젝트에서 User program 구현 단계에서 알아두면 좋은 점들을 모아와봤다.

글을 시작하기 전에 당신도 성장하고 싶다면, https://kgr0831.tistory.com/39를 봐주면 좋겠다.

그럼 시작하겠다.

1. Pintos는 실제로 ELF로더를 직접 구현한다.

Pintos 프로젝트를 진행하며 우리는 실제 ELF 실행파일을 로딩하는 코드를 직접 읽고 다룬다.

우리는 Pintos가 ELF 헤더 + 프로그램 헤더만을 사용한다.

저 소리를 들은 여러분들은 아마 저런 반응 ㅋ 일거 ㅋㅋ 같은데 ㅋㅋ킄킄킄ㅋ킄 아 진짜 ㄱ웃기네 ㅋㅋ

크흠.

아무튼 저게 뭔소린지 좀 풀어서 설명해보자면,

우선 ELF 파일에는 아래와 같은 여러 종류의 정보가 들어있다`.

ELF 헤더
프로그램 헤더 테이블
섹션 헤더 테이블
섹션 데이터

Pintos는 여기서 ELF 헤더와 프로그램 헤더 테이블만 신경 쓴다.

우선 섹션 헤더 테이블과 섹션 데이터같은 섹션쪽 정보는 링커, 디버거, 컴파일러가 필요로 하는 정보이기에,

우리가 만드는 ELF 실행기인, ELF 로더를 만들 때는 필요없다.

또한 ELF에 포함되는 아래와 같은 정보가 들어있다.

파일 실행의 시작점을 어디로 할지 - 엔트리 포인트
어떤 부분을 메모리에 로드해야하는지
읽기 전용인지, 쓰기 가능인지, 실행 가능한지
어떤 영역을 0으로 초기화해야 하는지

Pintos에서 우리는 위와 같은 실행용 정보만 필요하다.

위의 실행용 정보들은 전부 ELF 헤더와 프로그램 헤더 테이블에 들어있다.

2. Pintos는 정보를 어떻게 사용할까?

Pintos에서는 위에서 설명한 실행 정보들을 어떻게 사용하여 유저 프로그램을 실행할까?

ELF 로더는 아래의 6단계를 거쳐 프로그램을 실행한다.

매직 넘버 검사
프로그램 헤더 테이블 파싱
PT_LOAD 세그먼트 로딩
filesz/memsz 처리
권한 설정
엔트리 포인트 진입

각 단계가 어떤 일을 하는지 자세히 알아보자.

(1) 매직 넘버 검사 - 파일이 진짜 ELF인지 확인

0x7F 'E' 'L' 'F'

ELF 파일은 항상 위의 4바이트로 시작하는 Elf32_Ehdr

(또는 Elf64_Ehdr, Elf32_Ehdr는 32비트이고 Elf64_Ehdr는 64비트용이다. )

라는 구조체가 있는데, 이게 ELF 헤더이다.

이 헤더를 검사하여

매직 넘버 맞는지?
아키텍처가 32비트(또는 64비트)(x86)인지?
엔디안, 파일 타입 등이 정상인지?

를 확인하고, 이 단계에서 실패하면 즉시 로딩을 중단한다.

이걸 해야지 커널이 쓰레기 데이터를 코드로 착각해 실행하는 현상을 방지 할 수 있다.

(2) 프로그램 헤더 테이블 위치 읽기

필자는 롤에서도 정글러라서 이 핑을 애용한다. 필자는 카정이 싫다. 필자 상대로 그레이브즈 하지마라.

파일이 ELF파일이라는 것을 검사한 후에는 ELF헤더에 존재하는 프로그램 헤더 테이블의 위치를 읽는다.

정확히는 아래의 3개의 정보를 확인한다.

e_phoff → Program Header Table의 파일 오프셋
e_phentsize → Program Header 한 개의 크기
e_phnum → Program Header 개수

이걸 좀 풀어서 말하면,

“프로그램 헤더가 파일의 어디에서 시작하고, 몇 개가 있으니 이걸 참고해서 로드해야 할 세그먼트를 찾아라.”

가 되겠다.

Pintos에서는 e_phoff 와 seek 함수를 이용해서 프로그램 헤더를 한 개씩 읽기 시작한다.

(3) 데이터 필터링 하기 - 프로그램 헤더에서 PT_LOAD만 골라내기

이것은 필자다.

프로그램 헤더 테이블에는 p_type이

동적 링킹 정보인 PT_DYNAMIC,

인터프리터 정보인 PT_INTERP,

노트 정보인 PT_NOTE 등..

여러 데이터들이 살고 있는데, 우리는 여기서 p_type이 PT_LOAD인 것만 메모리에 올려야 한다.

이 PT_LOAD들만 진짜 우리가 실행할 코드이고, 데이터이기에 나머지는 전부 무시해준다.

(4) BSS - filesz와 memsz의 차이

PT_Load 세그먼트를 찾았다면, 이제 메모리에 복사할 차례다.

여기서 많은 사람들이 햇갈리는 부분이 나온다.

바로 p_filesz와 p_memsz의 차이이다.

p_filesz는 파일에 실제로 저장된 실행파일의 데이터의 크기이고,

p_memsz는 메모리에 할당되어 차지해야 할 크기이다.

일반적으로는 파일에 실제로 저장된 크기만큼 메모리에 공간을 할당해야하기에 둘의 크기가 같다.

하지만 가끔 p_memsz가 더 큰 경우가 있다.

이것은 여러분이다.

이게 무슨 상황일까?

파일에는 100bytes만 있는데, 150bytes만큼 메모리 할당을 요구하는 경우가 있다.

이 차이만큼인 p_memsz - p_filesz (위 예시에서는 50bytes)가 바로 초기화되지 않은 전역 변수인 BSS 영역이다.

int a;

위와 같이 c언어에서 변수를 선언만 하고 값을 안 넣은 전역 변수가 있다고 가정해보자.

이 전역 변수는 파일공간을 차지할 필요가 없다.

이거 ㄹㅇ 볼때마다 웃기다 ㅋㅋㅋㅋㅋㅋㅋ

그냥 실행할 때 0으로 싹 밀라고만 약속이 되어있기만 하지 실제로는 0이라는 데이터를 공간으로 차지하고 있지않다.

그래서 Pintos의 ELF 로더는 파일에서 p_filesz 만큼 읽어서 메모리에 쓰고,

남은 공간인 BSS는 memset(..., 0, ...)을 이용하여 0으로 꽉 채운다.

오우 가비지!!!!!!

만약 이걸 안해준다면, 초기화를 하지 않은 변수에서 쓰레기 값이 튀어나와서 변수값이 -1239123 같은 값이 되어

엄청난 난장판이 일어나서 디버깅 지옥에 빠지게 된다.

(5) RWX - 권한 설정

이제 메모리에 올리는게 끝났으면, 권한을 설정해서 보안을 지켜야 한다.

우리가 올린 데이터의 메모리의 영역이 읽기 전용인지, 쓰기 가능인지 커널에게 정확하게 알려줘야한다.

아무곳에나 막 쓰고 실행하는 것이 바이러스이고, 해킹이기에 OS는 철저하게 권한을 쪼갠다.

이때 사용하는 것이 바로 프로그램 헤더의 p_flogs 필드이다.

ELF는 보통 아래의 3가지 비트 플래그를 조합해서 권한을 나타낸다.

PF_X : 실행 가능(= Execute) → 주로 Code(= Text) 영역
PF_W : 쓰기 가능(= Write) → 주로 Data / BSS 영역
PF_R : 읽기 가능(= Read) → 거의 모든 영역

그럼 Pintos 코드는 이 권한들을 어떻게 처리할까?

Pintos 안에있는 process.c의 load_segment 함수를 보면

// process.c 내부 로직 예시

// p_flags와 PF_W(쓰기 권한 비트)를 AND 연산한다.
// 결과가 참이면 writable = true, 아니면 false (Read-Only)
bool writable = (phdr->p_flags & PF_W);

이렇게 아주 심플하게 비트 연산을 통해 writable 변수를 만들어낸다.

이 심플한 논리의 한줄이 매우 중요하다.

우선 코드 영역은 보통 PF_X나 PF_R의 권한을 가지기에 PF_W가 없다.

따라서 writable은 false가 된다.

즉, 프로그램이 실행되는 도중에 자기 자신의 코드를 수정하려고 시도한다면 CPU가 Page Falut를 일으켜서 프로그램을

강제로 종료한다.

데이터 영역은 전역 변수 같은 친구들이 들어있는 영역이기에, 값을 당연히 바꿔야하기에,

보통 PF_R이나 PF_W 권한을 가지고 있다.

그래서 writable은 true가 된다.

이렇게 태그들을 통해 결정된 writable 값은 최종적으로 페이지 테이블에 매핑될 때 사용한다.

if (!install_page (upage, kpage, writable)) {
			printf("fail\n");
			palloc_free_page (kpage);
			return false;
		}

Pintos에서는 이런식으로 쓰는데, 여기서 install_page(upage, kpage, writable)를 호출하면 우리는 단순히 변수 하나를

넘겨주는게 아니라, 이 함수 내부에서 CPU가 메모리를 바라보는 방식 자체를 조작한다.

요약하면, Pintos는 ELF 헤더의 p_flags를 보고 Code인지, Data인지 딱지를 붙여서 페이지 테이블에 등록하여

우리가 실수로 코드 영역을 덮어쓰는 대참사를 막아준다.

(6) 진짜 실행 - 엔트리 포인트 진입

이제 모든 세그먼트 로딩이 다 끝나고 대망의 실행만 남았다.

ELF 헤더의 e_entry 필드에는 해당 프로그램의 첫 번째 인스트럭션이 있는 주소(이 주소는 가상주소이다.)가 적혀있다.

Pintos에서는 인터럽트 프레임의 eip(또는 rip) 레지스터 값을 이 e_entry로 설정하여 iret 명령어가 실행되는 순간,

CPU는 우리가 로딩한 프로그램의 주소로 점프하여 user program의 main 함수(정확히는 _start함수이다.)가 시작된다.

Pintos의 ELF 로딩은 복잡해 보이지만 사실 필요한 것만 골라서 0으로 채울 건 채우고,

주소를 찍어주는 것이 전부이다.

위의 ELF 로딩 과정을 보면 load 함수가 조금은 더 친숙하게 보일수도 있다.

즐코딩