[크래프톤 정글] 7주차 회고록: malloc 구현(Implicit, First Fit)과 성능 최적화 과정 정리 그리고 연극

짠~ 6주 차 쓰고 난지 일주일 지난 거 같은 하지만 10분 만에 쓰는 7주 차 회고록~

 

7주 차는 개인적으로 공부하는 주제가 정말 재밌었다.

 

굳이 순서를 말하자면

1. MALLOC구현

2. 수요코딩회

3. 지방러의 서울구경

4. 회고 및 정리

1. MALLOC구현

7주 차 과제는 말록 구현이다. 말록이 머냐

 

 C언어에서는 리스트에 저장할 때도 얼마나 저장할지 내가 지정해줘야 한다 그럴 때마다 메모리를 부여하는데 그 작업을 해주는 함수가 말록이다. (아닐 수 있지만 내가 기억하고 이해한 방향으로 말할 예정)

 

이게 재밌는 게 성능을 테스트하는 점수가 있다. 누가 누가 높은 점수를 받을지 대결하는 거지

 

근데 처음 들어오니까 IMPLICIT는 머고 EXPLICIT는 머고 FIRST FIT 등등 뭐가 많은데 모르니까 개념부터 공부할까? 했지만 나는 내 공부스타일을 안다. 난 무조건 코드로 보고 직접 흐름을 따라가면서 나 스스로에게 설명하고 질문하고 답을 찾으면서 이해한다.

 

그렇게 공부한 내용은 따로 필기를 안 해도 까먹지 않는다. 그만큼 깊게 몰입했다는 거지

 

쨋든 그래서 나는 코덱스랑 같이 공부했는데 말록 구현의 기본 IMPLICIT, FIRST FIT으로 내가 직접 하나하나 구현이 아니해줘! 를 시전 했다.

 

그래서 그 코드를 보고 질문을 진짜 많이 했다.

 

이 회고록은 WIL은 아니니까 간단히 말하면 

 

우리 힙이라는 공간이 있다

ㅁㅁㅁㅁㅁㅁㅁㅁㅁㅁㅁㅁㅁㅁㅁㅁ

이렇게 있는데 각각의 박스에 주소 정보가 있어서 앞에서부터 1번 2번... N번 이렇게

근데 말록이 이 공간을 부여하는데 알고리즘에 맞춰서 필요한 공간만큼 부여해야 하니 그 알고리즘을 우리가 구현하는데 그 종류 중 하나가 IMPLICIT인 거다. 그리고 이제 필요한 공간만큼 쓰고 돌려주면 쓴 공간만큼 다시 쓸 수 있는 공간이 생기는데 이걸 찾는 방식이 FIT이다 그래서 그 종류 중 하나인 FIRST FIT이다 

 

IMPLICIT는 기본적으로 힙공간을 최소 16을 쓴다. 이 16을 온전히 쓸 수 있는 공간으로 있는 게 아니라 4 8 4로 4에는 내가 부여한 공간의 정보 8에는 실제로 부여할 공간 이렇게 있다.

 

그래서 사용자가 공간 32를 요청하면 4+4를 해서 40의 공간을 찾는다 이때 FIRST FIT은 맨 앞에서부터 포인터를 옮겨가면서 40 정도 들어갈 공간을 찾는다 그래서 제일처음 발견하는 공간을 부여하는데 그 공간이 40보다 크면 40만큼만 40이랑 딱 맞으면 통째로 주는 식이다.

 

다른 방식도 많은데 나는 IMPLICIT만 했다. 왜냐면 다른 방식을 공부 안 한건 아닌데 IMPLICIT하나만 봐도 비효율이 보이고 이걸 해결하지 않고 좀 더 많은 방식을 해보자 보다는 이때 발생하는 비효율을 해결해서 IMPLICIT의 끝을 보고 싶었다.

 

점수가 있다고 했는데 이 점수가 유틸과 처리속도 두 가지가 있는데 유틸은 얼마나 힙 공간을 효율적으로 쓰냐 처리속도는 얼마나 빠르게 사용자가 원하는 공간을 찾냐 인데 처리속도가 CPU성능에 따라 점수가 낮아진다.

 

예를 들어서 인텔이면 15점 나오는 게 맥이나 라이젠이면 30점이 나온다.

 

이렇게 돼버리면 비효율적인 처리속도여도 맥에서 돌리면 점수가 잘 나오니까 포기하고 유틸만 올려서 점수를 올릴 수 있다.

 

근데 점수받자고 공부하는 것도 아니니 한번 제대로 파고들어서 비효율을 처리해 보자 생각했다.

 

또 처리속도도 40점 만점 받으려면 700만 넘기면 돼서 그냥 점수가 아닌 속도점수를 보기로 했다.

 

이게 700이랑 10000이랑 같은 40점인데 같을 수가 없으니 처리속도에는 변별력이 없다고 보고 유틸을 끌어올리되 처리속도도 올려보자 IMPLICIT의 끝을 보자고 생각했다.

 

또 이게 점수가 있으니까 팀원들끼리 내기를 해서 수요코딩회 발표를 하기로 했는데 여기서 조금 미안한 부분이 있다. 이건 4번에서 말해야겠다.

 

쨋든 그럼 IMPLICIT는 기본 16을 쓰고 FIRST FIT은 맨 앞에서부터 빈 공간을 찾으니 벌써 비효율적이다.

 

또 REALLOC이라고 기존에 공간을 24 쓰고 있는데 이 공간을 32로 늘리게 해주는 함수가 있다.

 

이때 기본은 32인 다른 공간을 찾아서 24 공간의 내용을 복사하고 24를 해제시킨다.

 

보면 벌써 비효율적이다. 그래서 우선 REALLOC부터 전략을 바꿨다.

 

나는 모든 빈 공간을 큰 블록으로 만들고 싶었다. 그래서 REALLOC 할 때 24 공간 앞뒤에 뜯어와서 32 공간이 되면 뜯어와서 합치도록 했다. 그럼 굳이 이동할 필요도 없고 공간도 더 효율적으로 쓸 거 같았다.

 

그리고 두 번째는 큰 공간을 분리할 때이다.

 

만약 24 공간을 주려고 하는데 40에서 준다면 남은 16이 빈 공간이 된다. 그럼 정상이네? 할 수 있는데 16으로 나누고 끝이다. 만약 16 뒤 공간이 빈 블록이면 합쳐주는 게 좋을 거 같아서 이걸 합치는 전략을 추가했다. 코덱스는 굳이라고 하긴 했고 굳이인 거 같긴 하지만 그래도 당장 해주는 게 유틸이 더 좋았다.

 

세 번째는 공간을 할당해 주는 거다.

 

과제는 처음부터 4096바이트를 늘리고 이 공간을 다 쓰면 4096 또 늘리는데 이게 무식하게 늘리는 게 엄청 비효율적이다. 그래서 처음에 기본으로 늘리는 걸 1024로 해서 그 공간을 알뜰하게 다 쓰면 4096을 추가하는 전략을 썼다.

이때도 1024의 끝부분이 빈블록이면 4096 추가할 때 합치는 로직을 넣었다.

 

근데 처음을 크게 주고 다음을 작게 주는 것도 좋지 않을까 생각했는데 이건 성능이 별로였다 왜냐면 새로 요청했다는 건 앞에 기본블록을 많이 썼고 그래서 추가 블록이 필요한데 이 블록을 계속 작게 준다면 여러 번 호출해야 하니 속도랑 활용도도 느려진다.

 

이렇게 최대한 빈 공간을 크게 유지하려 했고 다음은 속도를 올리기 위해 FIT을 봤다.

 

FIT는 여러 개가 있는데 

FIRST FIT

NEXT FIT

BEST FIT

 

FIRST FIT은 앞에서 말했던 것처럼 맨 앞에 힙부터 빈 공간을 찾는 방식

NEXT FIT은 마지막으로 할당했던 블록부터 시작해 빈 공간을 찾는 거 즉 가운데부터 시작

BEST FIT은 힙 전체를 돌면서 사용자가 요청하는 공간에 최대한 딱 맞는 공간 부여

 

이 세 가지 FIT들은 각각의 장단점이 있는데

FIRST FIT은 찾는 게 느리다고 생각할 수 있는데 맨 앞에서 들어갈 공간을 발견만 하면 그 공간이 크든 딱 맞든 넣어버리니까 그렇게 느리진 않다.

NEXT FIT은 마지막으로 할당한 공간을 기억해서 그다음부터 보는 거라 사실 제일 큰 블록을 제일 처음으로 볼 거다 그래서 할당들을 하고 뒤에서 해제하면 앞에 공간이 생기는데 못 보고 지나가서 공간활용도, 유틸이 떨어진다. 대신 항상 큰 블록을 보니 거의 바로 넣을 수 있다.

BEST FIT은 무조건 모든 힙을 다 돌고 제일 최적의 공간을 주니까 속도는 제일 느려도 유틸이 최고다.

 

근데 여기서 드는 의문은 이거 3개뿐일까?

 

완전 새로운 건 못 만들겠지만 BEST FIT도 사실은 FIRST FIT의 변형인 거니까 이것들을 적절히 조합할 수 있지 않을까? 해서

 

처음 시도한 게 FIRST FIT으로 시작해서 처음 공간을 찾으면 그 뒤로 10개 정도 더 봐서 그중 최적에 공간에 넣는 로직이다.

FIRST FIT  BEST FIT을 적절히 섞었다고 생각하는데 이렇게 하니 속도는 거의 그대 로고 유틸은 조금 늘었다.

그리고 생각한 게 NEXT FIT과 BEST FIT을 섞어보는 거다.

 

이건 제일 큰 블록부터 볼 건데 이것만 보지 말고 뒤에 10개도 더 봐서 최적의 공간을 찾아라 인데 결과적으로 속도도 챙기면서 유틸도 챙기게 되었다.

 

이렇게 전략은 몇 개 안 되지만 동작이 머릿속으로 그려지고 그려짐으로써 스스로 생각해 냈다는 게 뿌듯했다.

 

2. 수요코딩회

 

이건 수요코딩회 결과물이다.

 

이번 수요코딩회는 B+트리 알고리즘을 사용해서 기존에 DB에서 값을 찾을 때 앞에서부터 하나하나 확인해서 찾는 방식을 데이터들에게 ID를 부여해서 일정범위만큼 나누어서 사용자가 요청하는 ID를 기준으로 트리 노드를 타고 내려가 리프에 도착하면 거기서만 하나씩 확인해 값을 찾는다.

 

즉 노드에는 값이 있는 게 아니라 ID의 범위가 있어서 1000개의 데이터에서 432를 찾고 싶으면 400에서 450 범위까지 내려가 그 안에서 하나씩 확인해 값을 찾는 거다.

 

이렇게 하면 기존에 O(N)에서 O(LOG N)까지 속도를 단축할 수 있지만 항상 빠른 건 아니다.

 

노드를 내려가야 한다는 고정비용이 발생하기 때문에 데이터가 매우 많다면 어느 시점부터는 선형탐색이 더 빠른 경우도 있고 TOP10 같은 경우도 그냥 처음부터 봐서 등급이 제일 높은 10명만 저장하면 돼서 선형탐색이 더 빠르다.

 

그래서 실제  DBM에서도 항상 B+트리를 사용하기보다는 각자의 기준을 나누어 사용자가 그 기준에 맞는 데이터를 요청하면 더 빠른 탐색을 쓴다.

3. 지방러의 서울구경

이번 주부터 서울을 나가기로 결정했다.

 

지방러는 서울을 여행하려면 각 잡고 날을 비우고 활동해야 한다.

 

그렇지만 지금 용인에 살면서 잘 곳이 있고 적은 비용과 빠른 시간에 서울에 갈 수 있으니 이제 시내 나가서 노는 것처럼 서울을 놀러 다닐 수 있게 된 거다.

 

우리가 굳이 갈고 있는 지역에서 번화가를 나가 노는데 그 지역 전체를 돌아봐야 한다는 목표를 가진 게 아니니 편하게 놀 수 있는데 이제 교육과정이 다 끝나서 내려간다면 한 번 갔을 때 모든 지역을 돌아야 하는 여행이 되니 그런 부담감을 줄일 수 있어서 좋은 거 같다.

 

그리고 무엇보다 이 윗 지역에 적응하고 싶다.

 

그렇다면 나는 아래지역을 가든 윗지역을 가든 능숙하게 행동할 수 있는 사람이 되는 거니 나를 더 성장시킬 수 있다고 생각한다.

 

그래서 뭘 하면 좋을까 혼자 생각해 봤는데 연극을 보고 싶었다.

 

나름 영화관 알바를 오랫동안 했어서 영화와 연극의 차이를 알고 있고 원래라면 꼭 누군가와 같이 보는 걸 선호하는데 이것도 약간 혼자 보는 그림이 어색해서 회피하는 거 같아서 회피하지 않고 부딪혀보기로 했다.

 

그래서 첫 입문을 뭐로 할까 고민을 많이 했는데 역시 무난하고 흥미롭게 볼 수 있는 러브코미디 장르를 선택했다.

 

사내연애보고서라는 연극을 봤는데 우선 결과적으로 매우 만족이었다. 

 

스토리도 좋았고 나름 반전도 있었던 거 같고 좁은 연극 무대를 100% 이상 활용하고 4명의 배우가 1인 다역으로 매번 다른 이미지를 보여준다는 게 정말 놀라웠다.

 

또 연극하면 관객과 함께 만들어 나가는 것도 초반에 하고 끝이 아닌 초반에 관객과의 티키타카를 연극 안에서도 녹여낸다는 것이 정말 재밌었다.

 

이제 순수 연극의 후기를 남기면 좁은 공간에 많지 않은 관객을 모아서 그 관객을 위해 연기하는 게 영화와는 완전 다른 매력이다.

 

영화는 감독이 관객을 위해 만들었다기보다 스토리를 만들고 본인의 작품을 자랑하는 느낌이다.

 

그래서 사람마다 호불호가 있고 또 혼자 이야기를 진행해 나가서 관객의 집중을 요구하는데

 

연극은 그와 다르게 스토리가 있지만 관객에게 그 스토리를 이해시키려는 모습을 많이 보였다.

 

애초에 동영상을 보는 거랑 실제 사람을 보는 거랑은 차원이 다르기 때문에 둘을 비교하는 게 무의미하지만 요즘 영화가격과 연극 가격이 비슷해지고 있는데 나한테 영화와 연극을 선택하라고 한다면 난 연극을 선택할 거 같다.

 

물론 스토리의 질은 영화가 훨씬 위지만 연극만의 매력, 배우와 함께 이 스토리를 만들어가는 느낌은 정말 재밌다.

 

이렇게 연극을 다 보고 나서는 혜화역에서 광화문까지 걸어갔다.

 

다들 엄청 많이 걸었다고 하는데 그냥 그 거리를 기억 속에 남기고 싶었어서 힘들다거나 지친다는 생각은 안 한 거 같다.

 

또 서울은 항상 다른 누군가와 함께 와서 나를 위해 시간을 쓰기보다는 항상 누군가와 같이 써서 온전히 나만 만족하기 위해 동선을 계획한 거라 어렵지 않았다.

 

여기가 아마 경복궁?이었던 거 같다. 창경궁을 지나 경복궁을 통해 광화문으로 나왔는데 날이 너무 좋아서 사진을 찍었다.

 

사진 찍는 거를 좋아하고 나름 기준이 있는데 많이 찍기보다는 내가 눈으로 봤을 때 맘에 들고 네모 틀에 비어있는 공간 없이 전부 담을 수 있으면 찍는다. 

 

물론 사진 찍으면서 서있는걸 조금 부담스러워 하긴 하는데 그래서 사람이 없는 타이밍에 찍는다.

 

그래서 예쁜 공간은 많았는데 사람이 많아서 그냥 내 눈에만 담아둔 장소가 많다.

 

그리고는 여의도 한강공원을 갔는데 마침 축체중이었다.

 

그래서 사람이 매우 매우 많아서 진짜 사람구경 하고 왔다.

 

여기 오기 전까지는 서울에 사람이 많긴 한데 딱히 나랑 부딪히거나 너무 많아서 걷질 못하겠다 이런 느낌은 못 받았는데 여기서 진짜 사람한테 질리는 이유를 알아버렸다.

 

정말 많았고 신호등을 건너려고 기다렸는데 사람이 너무 많이 건너서 다시 기다리는 상황이 되니 너무 스트레스였다.

 

그러고 나서 다시 집에 돌아온 거 같다.

 

돌아와서는 서울에서 유명한 빵집들을 들려서 빵 사 온 거를 사람들과 나눠 먹었다.

 

사진은 뭔가 맛없어 보이지만 여기 식당 조명이 어떻게 찍어도 안 이쁘게 나온다.

 

4. 회고 및 정리

 

다시 정글로 돌아와서 회고를 정리하면 

좋았던 것

경쟁을 통한 학습은 위에서 말했듯이 말록은 점수가 있고 이 점수로 수요코딩회 발표를 하기로 했다.

 

그래서 팀원들이 진짜 열심히 공부한 게 눈에 보였다.

 

동시에 점점 피폐해저 가는 게 보이는데 마음이 아팠다. 왜냐하면 나는 어느 정도하고 빨리빨리 넘어가는 학습법인데 다른 팀원은 그게 아니고 또 점수로 내기를 하니 더 급하게 할 수도 있다고 생각한다.

 

또 말록 구현이 IMPLICIT하나만 있는 게 아닌데 다들 점수 내기가 있으니까 다른 방식을 시도하지 않고 IMPLICIT만 공부해서 점수를 먹고 가자라는 게 보여서 내가 제안했지만 아쉬웠다.

 

물론 좋았던 게 정말 열심히 하나하나 코드를 뜯어보면서 정말 좋은 경험이라고 해줘서 고마웠다.

 

상명하복은 이제 수요코딩회 때 내가 지시하고 팀원들이 그걸 수행하는 식으로 했는데 그게 오히려 명확하게 할 일을 한 거 같다.

 

기초다지기는 팀원이 MALLOC구현을 위한 예제문제를 만들어서 팀에 공유했는데 문제안에서 생각할 수 있는 여러 포인트가 있어서 좋았다.

 

RIOT API호출은 수요코딩회 데이터를 게임 닉네임과 승률 랭크를 넣었는데 이걸 실제데이터를 가지고 와보자고 해서 해보라 했다. 아이디어 자체는 참신해서 좋았다.

 

아쉬웠던 거는

세부기획부족 이건 수요코딩회 처음에 분업만 하고 폴더구조나 지켜야 할 룰을 정하지 않고 하니 개발팀이 계속 구조를 바꾸고 내용을 바꾸고 해서 속도가 느려졌었다.

 

RIOT GAME은 API호출에서 사고가 많았다. 데이터를 받아와 보니 닉네임이 없다던지, 랭크가 고르게 받아와지지 않고 아래부터 받아와서 편향되어 있다던지, 닉네임을 진짜로 받아오려고 하니 시간이 너무 오래 걸린다던지 사고가 많았다.

 

그래도 이번에 느낌으로써 다음에 한 번 더 생각할 수 있지 않을까?

 

MALLOC AI사용 이거는 그냥 말록 구현하는데 AI를 사용해서 코드 줘한 게 아쉬웠다.

 

물론 실력이 안 돼서 코드를 주라고 한 거긴 하지만 그래도 내 힘으로 만들어보고 싶었다.

 

팀원 간 동료학습 부족 이것도 점수내기 때문에 팀원이 경쟁자가 되어서 서로의 코드를 공유보다 그냥 혼자 하는 방식이 되어버려서 진짜 아쉬웠다.

 

README작성 혼동은 수요코딩회 마지막에 README를 각자 쓰고 각자 수정하고 이러니까 발표날까지 수정하는 상황이 돼버려서 아쉬웠다.

 

마무리를 하자면 이번 주는 MALLOC주제가 정말 재밌었고 서울구경도 정말 재밌었지만 팀 활동은 아쉬웠던 한 주였다