harchiving

[코드트리] 갭체크로 한 달간 약점 유형 돌아본 후기

harchiving — Mon, 22 Jun 2026 22:31:27 +0900

이번 글은 코드트리 청약챌린지 7회차 미션으로 작성하는 중간점검 후기다.
이번 회차 미션은 다시 한 번 갭체크를 응시하고, 지난 4주 동안의 학습이 어떤 변화를 만들었는지 돌아보는 것이었다. 처음 갭체크를 봤을 때는 내가 어떤 부분이 부족한지도 정확히 모르는 상태였다. 문제를 풀면서 막히는 부분은 있었지만, 그것이 단순한 실수인지 개념 부족인지 구분하기 어려웠다. 그래서 이번 두 번째 갭체크는 단순한 실력 확인이라기보다, 한 달 동안의 학습 방향이 잘 맞았는지 확인하는 의미가 컸다.

첫 번째 갭체크 때는 기본 문법이나 단순 구현 문제는 어느 정도 따라갈 수 있었지만, 문제 조건을 차분히 정리하고 코드로 옮기는 과정에서 자주 막혔다. 특히 반복문 범위, 조건 처리, 함수로 코드를 나누는 부분에서 실수가 있었다. 당시에는 문제를 맞혔는지 틀렸는지만 신경 썼는데, 갭체크 결과를 보고 나니 내가 반복적으로 흔들리는 지점이 있다는 것을 알게 되었다.

이번 갭체크를 응시하면서는 이전보다 문제를 대하는 태도가 조금 달라졌다고 느꼈다. 처음에는 문제를 읽자마자 바로 코드를 작성하려고 했다면, 이번에는 입력 조건과 출력 형식, 반복해야 하는 범위부터 먼저 확인하려고 했다. 모든 문제가 쉽게 풀린 것은 아니었지만, 최소한 막막하게 손이 멈추는 시간은 줄어든 것 같았다. 이 점이 첫 번째 갭체크와 비교했을 때 가장 크게 달라진 부분이었다.

before

after

비포와 애프터를 비교해 보니, 아직 완벽하게 약점이 사라졌다고 말하기는 어렵지만 문제를 바라보는 방식은 분명 달라졌다고 느꼈다. 첫 갭체크에서는 결과를 보고 부족한 부분을 확인하는 데 그쳤다면, 이번에는 내가 어떤 부분을 보완했고 어떤 점이 아직 남아 있는지 조금 더 구체적으로 볼 수 있었다. 단순히 점수나 결과만 비교하는 것이 아니라, 지난 한 달 동안의 학습 습관이 어떻게 바뀌었는지를 확인할 수 있었다는 점에서 의미가 있었다.

지난 한 달 동안 약점을 보완하기 위해 코드트리에서 한 노력은 크게 세 가지였다. 첫째, 갭체크 결과를 바탕으로 추천 학습 경로를 따라가며 부족한 부분을 다시 확인했다. 둘째, 레슨 단위로 기본 개념과 연습 문제를 차례대로 풀면서 학습 흐름을 이어갔다. 셋째, 다시 봐야 할 문제는 북마크해 두고 나중에 복습하는 방식으로 오답노트처럼 활용했다.

특히 기억에 남는 학습은 Trail 2 프로그래밍 연습의 챕터 1 함수 중 레슨 1 값을 반환하지 않는 함수였다. 처음에는 함수가 단순히 문법 개념이라고 생각했는데, 학습을 하면서 코드를 역할별로 나누는 연습이 된다는 점을 알게 되었다. 값을 반환하지 않는 함수는 특정 동작을 수행하거나 반복되는 코드를 정리할 때 유용했다. 문제를 풀 때 모든 코드를 한 번에 길게 작성하기보다, 기능별로 나누어 생각하는 습관을 들이는 데 도움이 되었다.

처음에는 함수나 구현 문제를 풀 때 어디서부터 정리해야 할지 막막했다. 하지만 레슨을 따라가며 기본 문제, 연습 문제, 테스트 문제를 차례대로 풀다 보니 조금씩 풀이 감각이 생겼다. 특히 예전에는 문제를 풀면서 중간에 조건을 빠뜨리는 경우가 많았는데, 이제는 코드를 작성하기 전에 어떤 동작이 필요한지 먼저 생각하려고 한다. 아직 완전히 강점이 되었다고 말하기는 어렵지만, 예전처럼 막연하게 어렵게만 느껴지지는 않는다.

코드트리의 장점은 학습 흐름이 끊기지 않도록 도와준다는 점이었다. 갭체크로 현재 위치를 확인하고, 추천 학습 경로를 따라 부족한 부분을 채우고, 북마크 기능으로 다시 볼 문제를 모아둘 수 있었다. 단순히 문제를 많이 푸는 것이 아니라 진단, 학습, 복습이 연결되는 느낌이었다. 다른 학습 서비스에서는 문제를 직접 고르는 데 시간이 걸리거나, 내가 어떤 부분을 복습해야 하는지 놓칠 때가 있었는데 코드트리는 그런 점에서 방향을 잡아주는 역할을 했다.

코드트리는 아래 링크에서 확인할 수 있다.
코드트리 바로가기

Codetree: Master Coding Interviews - Data Structures & Algorithms

Master algorithms, ace tech interviews, and elevate your coding skills with Codetree's systematic curriculum and expert-crafted problem sets.

www.codetree.ai

물론 아직 아쉬운 점도 있다. 두 번째 갭체크를 봤다고 해서 모든 약점이 바로 해결된 것은 아니다. 여전히 조건이 복잡한 문제에서는 시간이 걸리고, 구현 과정에서 작은 실수가 생기기도 한다. 하지만 이번 중간점검을 통해 중요한 것은 한 번에 완벽해지는 것이 아니라, 내가 어떤 부분에서 나아지고 있는지 확인하며 꾸준히 이어가는 것이라는 생각이 들었다.

앞으로 코드트리에서 달성하고 싶은 최종 목표는 코딩테스트 문제를 봤을 때 당황하지 않고, 문제 조건을 차분히 분석한 뒤 안정적으로 구현하는 것이다. 단순히 정답 개수를 늘리는 것보다, 풀이 과정을 스스로 설명할 수 있는 실력을 만들고 싶다. 이를 위해 앞으로도 갭체크 결과를 참고하고, 추천 학습 경로를 따라가며, 북마크해 둔 문제를 주기적으로 다시 풀어볼 계획이다.

이번 7회차 미션은 지난 한 달을 돌아볼 수 있는 좋은 중간점검이었다. 처음에는 막막했던 약점들이 아직 완전히 사라진 것은 아니지만, 적어도 어떻게 공부해야 할지는 조금씩 보이기 시작했다. 앞으로도 코드트리와 함께 꾸준히 학습하면서 부족한 부분을 하나씩 채워가고 싶다. 다음 갭체크에서는 지금보다 더 성장한 결과를 확인할 수 있도록 계속 루틴을 이어가야겠다

[코드트리 후기] 북마크로 나만의 복습 루틴 만들기

harchiving — Mon, 15 Jun 2026 15:42:29 +0900

이번 글은 코드트리 청약챌린지 6회차 미션으로 작성하는 후기다.
이번 회차 미션의 주제는 코드트리의 북마크 기능을 활용해 나만의 오답노트와 복습 루틴을 만들어보는 것이었다. 코딩테스트 공부를 하다 보면 문제를 푸는 것만큼이나 다시 보는 과정이 중요하다고 느낀다. 한 번 맞힌 문제라도 풀이가 완전히 내 것이 아닐 때가 있고, 틀린 문제는 시간이 지나면 왜 틀렸는지조차 흐려지는 경우가 많기 때문이다. 그래서 이번에는 다시 보고 싶은 문제를 북마크로 모아두고 복습하는 방식으로 학습을 진행해 보았다.

코드트리의 북마크 기능은 다시 풀고 싶은 문제를 따로 저장해둘 수 있는 기능이다. 단순히 문제를 즐겨찾기하는 정도라고 생각할 수도 있지만, 실제로 사용해 보니 나만의 오답노트를 만드는 데 꽤 유용했다. 특히 코드트리 커리큘럼을 따라 학습하다가 헷갈렸던 문제나 다시 풀어보고 싶은 문제를 바로 저장할 수 있어서, 복습할 문제를 따로 찾는 시간을 줄일 수 있었다.

이번에 북마크해 둔 문제를 다시 풀면서 가장 크게 깨달은 점은, 처음 풀 때 막혔던 부분이 시간이 지난 뒤에도 비슷하게 다시 막힌다는 것이었다. 처음에는 단순한 실수라고 생각했던 부분도 다시 보니 반복되는 약점이었다. 예를 들어 조건을 꼼꼼히 읽지 않거나, 반복문의 범위를 정확히 잡지 못하는 경우가 있었다. 한 번 틀리고 넘어갔다면 그냥 잊혔을 문제였지만, 북마크해 두고 다시 풀어보니 내가 어떤 유형에서 실수를 반복하는지 확인할 수 있었다.

또 하나 느낀 점은 복습할 때는 정답 여부보다 풀이 과정이 더 중요하다는 점이었다. 처음 풀 때는 정답을 맞히는 데 집중했다면, 다시 풀 때는 “왜 이 방식으로 접근했는지”, “다른 풀이가 가능한지”, “이전에 실수한 부분을 이번에는 피했는지”를 더 생각하게 되었다. 북마크 기능을 활용하니 이런 문제들을 따로 모아둘 수 있어서, 복습이 훨씬 체계적으로 느껴졌다.

코드트리의 커리큘럼과 북마크 기능을 함께 사용하니 나만의 복습 루틴도 만들 수 있었다. 먼저 커리큘럼을 따라 새로운 개념이나 문제를 학습하고, 그중에서 헷갈렸던 문제를 북마크에 저장한다. 이후 며칠 뒤 북마크 폴더에 들어가 다시 풀어보면서 처음 풀이와 비교한다. 다시 풀었을 때도 막히는 문제는 계속 남겨두고, 충분히 익숙해진 문제는 복습 완료로 정리하는 방식이다. 이렇게 하니 학습이 단순히 앞으로만 진행되는 것이 아니라, 부족한 부분을 다시 점검하면서 이어지는 느낌이 들었다.

코드트리는 아래 링크에서 확인할 수 있다.

코드트리 바로가기

Codetree: Master Coding Interviews - Data Structures & Algorithms

Master algorithms, ace tech interviews, and elevate your coding skills with Codetree's systematic curriculum and expert-crafted problem sets.

www.codetree.ai

다른 학습 서비스와 비교했을 때 코드트리의 장점은 커리큘럼 학습과 복습 기능을 함께 활용하기 좋다는 점이었다. 다른 곳에서도 즐겨찾기 기능은 있을 수 있지만, 코드트리는 학습 흐름 안에서 바로 북마크하고 다시 돌아볼 수 있어서 복습 루틴을 만들기 편했다. 특히 코딩테스트 공부처럼 누적 학습이 중요한 분야에서는 내가 틀렸던 문제를 다시 확인하는 과정이 꼭 필요하다고 생각한다.

아쉬운 점을 하나 적어보자면, 북마크한 문제마다 간단한 메모를 남길 수 있는 기능이 더 잘 보이면 좋겠다고 느꼈다. 문제를 북마크할 때 “조건 실수”, “반복문 범위 헷갈림”, “함수 개념 복습 필요”처럼 이유를 함께 적어둘 수 있다면 나중에 복습할 때 훨씬 도움이 될 것 같다. 물론 지금도 폴더 이름을 나누어 어느 정도 관리할 수 있지만, 개인 오답노트처럼 활용하려면 문제별 메모 기능이 더해지면 좋겠다고 생각했다.

이번 6회차 미션을 통해 복습은 단순히 틀린 문제를 다시 보는 것이 아니라, 내가 어떤 방식으로 사고했고 어디에서 실수했는지 확인하는 과정이라는 것을 느꼈다. 북마크 기능은 그 과정을 더 쉽게 만들어주는 도구였다. 앞으로도 새로운 문제를 풀다가 헷갈리거나 다시 풀어볼 필요가 있는 문제는 바로 북마크에 저장하고, 일정 시간이 지난 뒤 다시 풀어보는 루틴을 이어가고 싶다.

코딩테스트 공부에서 중요한 것은 많이 푸는 것만이 아니라, 틀린 문제를 확실히 내 것으로 만드는 일이라고 생각한다. 이번 북마크 기능 활용을 통해 나만의 오답노트와 복습 루틴을 조금씩 만들어갈 수 있었다. 앞으로도 코드트리 커리큘럼을 따라가면서 북마크를 적극적으로 활용해, 놓친 개념과 실수를 하나씩 줄여가야겠다

[코딩테스트] 코드트리 알림톡으로 매일 학습 루틴 만들기

harchiving — Mon, 8 Jun 2026 12:23:13 +0900

이번 글은 코드트리 청약챌린지 5회차 미션으로 작성하는 후기다.
이번 회차 미션의 주제는 다양한 동기부여 방식을 활용해 꾸준히 학습한 경험을 공유하는 것이었다. 코딩테스트 공부는 한 번에 몰아서 하는 것보다 매일 조금씩 이어가는 것이 중요하다고 생각하지만, 실제로 꾸준히 실천하는 일은 생각보다 쉽지 않았다. 그래서 이번에는 코드트리의 학습 리마인더 알림톡을 활용해 학습 루틴을 만들어보았다.

코드트리의 학습 리마인더 알림톡은 정해진 시간에 학습을 잊지 않도록 알려주는 기능이다. 단순한 알림처럼 보일 수도 있지만, 막상 받아보니 “오늘도 조금이라도 공부해야겠다”는 생각을 하게 만들어 주었다. 특히 코딩테스트 공부는 하루를 놓치면 다시 시작하기가 귀찮아지는 경우가 많기 때문에, 이렇게 외부에서 한 번 더 상기시켜 주는 장치가 꽤 도움이 되었다.

이전에는 공부해야겠다는 생각만 하고 실제로는 미루는 날이 많았다. 문제를 풀려면 노트북을 켜야 하고, 어떤 문제를 풀지 골라야 하고, 집중할 시간도 확보해야 한다. 이런 과정이 쌓이다 보면 시작 자체가 부담스럽게 느껴질 때도 있었다. 그런데 알림톡을 받으니 적어도 “오늘 코드트리에 들어가서 한 문제라도 확인해보자”는 작은 행동으로 이어졌다. 학습을 거창하게 시작하지 않아도 된다는 점에서 부담이 줄었다.

코드트리 학습을 하면서 느낀 점은 커리큘럼이 정리되어 있어 알림을 받은 뒤 바로 이어서 공부하기 좋다는 점이었다. 다른 학습 서비스에서는 문제를 고르는 데 시간이 걸리거나, 내가 어디까지 공부했는지 다시 확인해야 하는 경우가 있었다. 반면 코드트리는 내가 학습하던 흐름을 이어가기 쉬워서 알림을 받은 뒤 바로 접속해 다음 내용을 확인하기 좋았다. 알림이 단순히 접속을 유도하는 데서 끝나는 것이 아니라, 실제 학습으로 이어지기 쉬운 구조라는 점이 좋았다.

이번에 내가 선택한 동기 유지 방식은 거창한 목표를 세우는 것이 아니라, 알림톡을 통해 매일 학습을 떠올리는 방식이었다. 코딩테스트 공부를 할 때 매일 많은 문제를 풀겠다고 목표를 세우면 오히려 부담이 커질 수 있다. 그래서 나는 “하루에 아주 조금이라도 코드트리에 들어가 보기”, “문제 하나라도 읽어보기”, “어제 풀던 레슨을 이어서 확인하기”처럼 낮은 기준으로 시작하려고 했다. 이 방식이 오히려 꾸준함을 유지하는 데 더 현실적이라고 느꼈다.

알림톡의 체감 효과는 생각보다 분명했다. 평소 같으면 그냥 지나쳤을 시간에도 알림을 보고 학습을 떠올릴 수 있었고, 공부를 완전히 잊어버리는 날이 줄었다. 물론 알림이 온다고 해서 자동으로 실력이 늘어나는 것은 아니다. 결국 직접 문제를 풀고, 틀린 부분을 다시 확인하고, 풀이 과정을 정리하는 것은 내가 해야 할 일이다. 하지만 그 시작점을 만들어준다는 점에서 알림톡은 좋은 동기부여 도구라고 생각했다.

코드트리에서는 코딩테스트 학습을 위한 다양한 커리큘럼과 문제를 확인할 수 있다.

코드트리 바로가기

Codetree: Master Coding Interviews - Data Structures & Algorithms

Master algorithms, ace tech interviews, and elevate your coding skills with Codetree's systematic curriculum and expert-crafted problem sets.

www.codetree.ai

타 서비스와 비교했을 때 코드트리의 장점은 학습 흐름을 이어가기 좋다는 점이었다. 단순히 문제만 제공하는 서비스도 많지만, 코드트리는 학습 커리큘럼과 레슨 구조가 있어 내가 어떤 내용을 공부하고 있는지 파악하기 쉬웠다. 여기에 알림톡까지 함께 활용하니 “공부해야지”라는 생각에서 끝나는 것이 아니라 실제 접속과 학습으로 이어질 가능성이 높아졌다.

아쉬운 점을 하나 적어보자면, 알림톡에서 오늘 이어서 학습하면 좋은 레슨이나 최근 풀던 문제로 바로 연결되는 안내가 더 자세히 보이면 좋겠다는 생각이 들었다. 지금도 학습을 떠올리게 해주는 역할은 충분하지만, 알림을 눌렀을 때 바로 오늘의 학습 목표가 더 구체적으로 보이면 실천으로 이어지기 더 쉬울 것 같았다.

이번 5회차 미션을 통해 꾸준한 학습을 위해서는 의지만큼이나 환경을 만드는 것이 중요하다는 것을 느꼈다. 코딩테스트 공부는 단기간에 끝나는 공부가 아니기 때문에, 계속 이어갈 수 있는 장치가 필요하다. 나에게는 코드트리 알림톡이 그런 장치가 되었다. 앞으로도 알림을 받으면 가볍게라도 코드트리에 접속하고, 하루에 한 문제 또는 한 레슨이라도 이어가는 방식으로 학습 습관을 만들어가고 싶다.

결국 꾸준함은 큰 결심보다 작은 반복에서 만들어진다고 생각한다. 이번 경험을 계기로 코딩테스트 공부를 너무 무겁게만 생각하지 않고, 매일 조금씩 이어가는 루틴으로 만들어가야겠다. 다음 회차에서도 지금의 흐름을 놓치지 않고 코드트리와 함께 학습을 이어가고 싶다

[코드트리] 함수 알고리즘 기초 학습 후기

harchiving — Mon, 25 May 2026 16:37:11 +0900

이번 글은 코드트리 청약챌린지 3주차 미션으로 작성하는 학습 후기다.
2주차에는 갭체크를 통해 현재 내 실력을 점검했고, 3주차에는 그 결과를 바탕으로 실제 커리큘럼을 따라가며 부족한 부분을 채워보았다. 이번에 내가 학습한 내용은 Trail 2 프로그래밍 연습의 챕터 1 함수 중 레슨 1 ‘값을 반환하지 않는 함수’였다.

코드트리의 커리큘럼은 큰 Trail 안에 챕터가 있고, 다시 그 안에서 레슨 단위로 학습이 이어지는 구조였다. 단순히 문제만 풀게 하는 방식이 아니라, 먼저 개념을 확인하고 그 내용을 바탕으로 연습 문제를 풀어보는 흐름이라 처음 학습하는 내용도 부담 없이 따라갈 수 있었다. 이번에 학습한 함수 레슨도 기본 개념을 이해한 뒤, 직접 코드를 작성하면서 익숙해지는 방식으로 구성되어 있었다.

이번 레슨에서 다룬 값을 반환하지 않는 함수는 말 그대로 특정 값을 돌려주는 것이 목적이 아니라, 함수 안에서 정해진 동작을 수행하는 형태였다. 처음에는 함수라고 하면 결과값을 return으로 돌려줘야 한다는 이미지가 강했는데, 이번 레슨을 통해 출력이나 반복되는 동작을 정리하는 데에도 함수를 사용할 수 있다는 점을 다시 이해하게 되었다.

문제를 풀면서 가장 많이 신경 쓴 부분은 “어떤 코드를 함수로 분리해야 하는가”였다. 평소에는 짧은 문제를 풀 때 코드를 위에서부터 순서대로 작성하는 편이었는데, 함수 단원에서는 반복되거나 의미가 분명한 동작을 따로 묶는 연습이 필요했다. 처음에는 굳이 함수를 만들어야 하나 싶기도 했지만, 문제를 풀다 보니 함수로 나누면 코드의 역할이 더 잘 보인다는 점을 느꼈다.

예를 들어 같은 출력 형식이 반복되거나 특정 작업을 여러 번 수행해야 하는 경우, 함수를 사용하면 코드가 훨씬 정리되어 보였다. 단순히 정답을 맞히는 것뿐만 아니라, 다른 사람이 봐도 이해하기 쉬운 코드를 작성하는 연습이 된다고 느꼈다. 코딩테스트에서도 복잡한 구현 문제를 풀 때 기능을 적절히 나누는 습관이 도움이 될 것 같았다.

레슨을 끝까지 풀고 나니, 함수에 대한 감각이 조금 더 선명해졌다. 이전에는 문제를 풀 때 필요한 코드를 한 번에 작성하는 데 집중했다면, 이번에는 “이 부분은 함수로 따로 빼면 더 보기 좋을까?”, “이 함수는 어떤 동작을 담당해야 할까?”를 생각하게 되었다. 기본 문제부터 연습 문제까지 따라가면서 같은 개념을 여러 번 적용해 볼 수 있었던 점도 도움이 되었다.

코드트리의 장점은 학습 흐름이 단계적으로 이어진다는 점이었다. 다른 학습 서비스에서는 문제를 고르는 것부터 고민해야 하는 경우가 있었는데, 코드트리는 정해진 커리큘럼을 따라가면 자연스럽게 개념 학습과 문제 풀이가 이어졌다. 특히 함수처럼 기초 개념이지만 앞으로 계속 사용하게 될 내용을 레슨 단위로 나누어 학습할 수 있어서 좋았다.

해설과 모범코드도 복습할 때 도움이 되었다. 내가 작성한 코드와 비교하면서 함수 이름을 어떻게 정리했는지, 함수 안에 어떤 동작을 넣었는지 확인할 수 있었다. 내가 푼 코드가 정답이더라도 모범코드를 보면 더 간결하게 작성할 수 있는 부분이 보였다. 이 과정에서 단순히 답을 맞히는 것보다 코드를 더 깔끔하게 만드는 연습도 중요하다고 느꼈다.

아쉬운 점을 하나 꼽자면, 함수가 실제 코딩테스트 문제에서 어떻게 활용되는지 예시가 조금 더 많으면 좋겠다고 생각했다. 기초 레슨에서는 개념을 익히는 것이 우선이지만, 나중에 구현이나 시뮬레이션 문제에서 함수를 어떻게 나누면 좋은지까지 연결해서 보여주면 더 도움이 될 것 같았다.

코드트리는 아래 링크에서 확인할 수 있다.
코드트리 바로가기

Codetree: Master Coding Interviews - Data Structures & Algorithms

Master algorithms, ace tech interviews, and elevate your coding skills with Codetree's systematic curriculum and expert-crafted problem sets.

www.codetree.ai

이번 3주차 학습을 통해 함수는 단순히 문법을 배우는 단원이 아니라, 코드를 더 구조적으로 작성하기 위한 기본 도구라는 것을 느꼈다. 특히 값을 반환하지 않는 함수는 반복되는 출력이나 특정 동작을 정리할 때 유용했고, 문제를 더 깔끔하게 풀 수 있도록 도와주었다.

아직은 간단한 함수부터 연습하는 단계지만, 이번 레슨을 통해 코드를 역할별로 나누는 습관을 조금씩 들일 수 있었다. 앞으로 더 복잡한 문제를 풀 때도 무작정 코드를 길게 작성하기보다, 필요한 기능을 함수로 분리하면서 풀이 과정을 정리해 보고 싶다. 이번 3주차는 함수 기초를 다시 다지고, 앞으로의 코딩테스트 공부 방향을 잡는 의미 있는 시간이었다

코드트리 코딩테스트 갭체크 후기: 2주차부터 시작한 첫 미션 기록

harchiving — Mon, 18 May 2026 23:36:26 +0900

이번 글은 코드트리 청약챌린지 2주차 미션으로 작성하는 후기다.
1주차에는 아직 통장 개설 전이라 참여하지 못했고, 이번 2주차가 사실상 나의 첫 미션이었다. 그래서 이번 미션은 본격적으로 문제를 많이 풀기보다, 먼저 내 현재 실력을 점검해 보는 의미가 컸다. 그 과정에서 응시한 것이 바로 갭체크였다.

갭체크 안내 화면을 처음 확인했을 때는 생각보다 긴장됐다.
평소에도 코딩테스트 공부를 해야 한다는 생각은 하고 있었지만, 막상 내 실력을 진단한다고 하니 실제 시험을 앞둔 것 같은 느낌이 들었다. 그래도 지금 내가 어느 정도 수준인지 알아야 앞으로의 학습 방향도 정할 수 있다고 생각했다.

무작정 문제를 많이 푸는 것도 중요하지만, 그보다 먼저 내가 어떤 유형에 강하고 어떤 부분에서 자주 막히는지 파악하는 과정이 필요하다고 느꼈다. 그런 점에서 갭체크는 챌린지를 시작하는 첫 단계로 적당한 미션이었다고 생각했다.

갭체크 문제를 풀면서 느낀 점은, 문제 난이도가 단순히 어렵다기보다는 기본기를 정확히 확인하는 방식에 가깝다는 것이었다.
처음에는 익숙한 유형도 있었기 때문에 비교적 차분하게 풀 수 있었다. 하지만 조건을 꼼꼼하게 읽어야 하거나 구현 과정에서 예외를 생각해야 하는 문제에서는 시간이 걸렸다.

특히 문제를 읽고 바로 코드를 작성하는 습관이 아직 남아 있다는 점을 느꼈다. 입력 조건, 반복 범위, 예외 상황을 먼저 정리하고 풀이 방향을 잡은 뒤 코드를 작성해야 하는데, 급하게 접근하면 중간에 다시 수정하는 일이 생겼다. 코딩테스트에서는 풀이 아이디어도 중요하지만, 그 아이디어를 실수 없이 코드로 옮기는 능력이 정말 중요하다는 것을 다시 느꼈다

내가 비교적 안정적으로 풀 수 있었던 부분은 조건문, 반복문, 배열을 활용하는 기본 구현 문제였다. 반대로 조건이 조금 복잡해지거나 여러 경우를 나누어 생각해야 하는 문제에서는 풀이 방향을 정리하는 데 시간이 더 필요했다. 이번 갭체크를 통해 단순히 “문제를 맞혔다, 틀렸다”가 아니라 내가 어떤 과정에서 막히는지를 확인할 수 있었다.

결과를 확인하면서 내 강점과 약점을 조금 더 분명하게 알 수 있었다.
강점은 기본 문법과 단순 구현 문제에서는 크게 흔들리지 않는다는 점이었다. 반면 약점은 문제를 차분히 분석하고, 구현 과정에서 실수를 줄이는 부분이었다.

평소에는 틀린 문제를 보면 단순히 실수라고 생각하고 넘어간 적도 많았다. 하지만 이번 갭체크를 통해 그런 실수도 반복되면 결국 보완해야 할 약점이라는 생각이 들었다. 특히 인덱스 범위, 조건 처리, 예외 케이스처럼 사소해 보이는 부분이 실제 정답 여부를 크게 좌우한다는 점을 다시 확인했다.

갭체크 이후 추천 학습 경로가 제시된 점도 도움이 됐다. 단순히 결과만 보여주는 것이 아니라, 부족한 부분을 보완하기 위해 어떤 순서로 학습하면 좋을지 안내해 주는 점이 좋았다. 코딩테스트 공부를 하다 보면 어떤 문제부터 풀어야 할지 막막할 때가 있는데, 코드트리는 현재 상태를 기준으로 학습 방향을 잡아준다는 점에서 유용했다.

코드트리는 아래 링크에서 확인할 수 있다.

https://www.codetree.ai/ko/trail-info

코딩 테스트 학습 안내 | 코드트리

막막한 코딩테스트 준비, 혼자 헤매지 말고 체계적인 코딩 학습과 단계별 가이드로 빠르게 실력을 쌓아 취업에 성공하세요.

www.codetree.ai

다른 학습 서비스와 비교했을 때 코드트리의 장점은 진단과 학습이 자연스럽게 이어진다는 점이었다. 단순히 문제를 많이 제공하는 데서 끝나는 것이 아니라, 현재 내 실력을 확인하고 그에 맞는 학습 경로를 추천해 주는 흐름이 좋았다. 다만 아쉬운 점도 있었다. 약점 분석이 조금 더 구체적으로 제공되면 더 도움이 될 것 같았다. 예를 들어 개념 이해가 부족한 것인지, 구현 실수가 많은 것인지, 문제 해석에서 시간이 오래 걸리는 것인지까지 나뉘어 보이면 이후 학습 계획을 세우는 데 더 유용할 것 같았다.

이번 2주차 미션은 나에게 코드트리 청약챌린지를 시작하는 첫 기록이었다. 1주차를 놓친 점은 아쉬웠지만, 오히려 갭체크를 통해 현재 위치를 먼저 확인하고 시작할 수 있었다는 점은 좋았다. 앞으로는 추천 학습 경로를 따라가며 부족한 부분을 하나씩 채워가고 싶다.

이번 갭체크를 통해 내가 무엇을 잘하고, 무엇을 더 연습해야 하는지 알 수 있었다. 아직 부족한 부분이 많지만, 그만큼 앞으로 채워갈 부분도 분명해졌다고 생각한다. 다음 미션부터는 문제를 푸는 양뿐만 아니라 풀이 과정과 실수한 부분까지 함께 기록하면서 코딩테스트 실력을 조금씩 키워가야겠다

오픈소스 프로젝트에 첫 기여해보기

harchiving — Tue, 5 Aug 2025 06:37:57 +0900

오픈소스에 기여한다고 하면 상당히 거창하고 어려운 일처럼 보인다. 나도 그렇게 생각했기 때문이다.

이번에 좋은 기회로 관심 있던 오픈소스 컨트리뷰션 아카데미(OSSCA)에 멘티로 참여하게 되면서 처음으로 오픈소스 문화에 입문하게 되었다.

나처럼 무엇을 기여할지 고민하기 이전에, 어떻게 기여를 시도할 수 있는지조차 어려움을 겪는, 정말 아무것도 모르는(!) 비기너들을 위해 오픈소스 기여 방법을 소개해보고자 한다.

기여할 프로젝트 고르기

먼저 Github에서 기여하고 싶은 오픈소스 프로젝트를 골라야 한다.

나같은 경우에는 아카데미에서 지원하는 여러 오픈소스 프로젝트 중 하나를 골라 그 팀에 합류하였기 때문에 기여할 프로젝트가 정해져 있었지만, 일반적인 경우에는 후보지 없이 자유롭게 고르게 될 것이다.

오픈소스 기여는 무엇보다 재미가 가장 중요하다고 생각한다.

자신이 기여하면서 즐거움을 느낄 수 있는 프로젝트, 이슈를 선정하는 게 좋다.

평소에 자신이 관심 있는 라이브러리, 프로젝트를 진행하면서 사용해 본 오픈소스가 있는지 생각해보길 바란다.

만약 없다면, 다양한 오픈소스 프로젝트를 안내하는 사이트를 참고해도 좋다.

참고할만한 사이트들
https://github.com/explore
https://github.com/topics/open-source
https://www.codetriage.com/

또한 본인에게 익숙한 언어나 프레임워크를 사용하고 있는 프로젝트가 좋을 것이다.

처음 보는 코드 읽기도 벅찬데, 모르는 언어로 작성되었다면... 그때부터는 기여 문제가 아니게 된다.

오픈소스 기여 활동이 활발한 프로젝트를 선정하는 것도 아주 좋은 방법이다.

해당 레포지토리에 이슈나 PR이 활발하게 일어나는지, 기여를 위한 커뮤니티가 잘 조성되어 있는지 확인해보길 바란다.

예컨대 내가 참여 중인 Yorkie 프로젝트에는 소통창구로 Discord 링크가 README에 적혀져 있다.

피드백이 빠르고, 잘 관리되며, 새로운 기여자들에게 우호적인 프로젝트를 선택한다면 기여에 보람을 느끼기 좋기 때문이다!

환경 세팅하기

기여할 프로젝트를 골랐다면, 이제 본인이 개발하는 프로젝트를 다룰 때처럼 코드를 읽고 수정할 수 있어야 한다.

IDE에서 레포지토리를 열어보는 오픈소스 기여 환경을 세팅하기 위해서는 몇가지 절차가 필요하다.

내가 이 글을 포스팅하게 된 이유이다.

fork

가장 먼저 원본 레포지토리를 fork한다.

fork 버튼은 레포지토리의 우측 상단에서 찾아볼 수 있다.

fork는 해당 레포지토리를 자신의 Github에 복제하는 것이라고 보면 된다. ~~말 그대로 포크로 떠온다고 한다~~

그럼 내 깃허브에 있는 레포지토리는 내가 fork한 레포지토리의 복사본이 되고, 원본 레포지토리와의 커넥션을 갖는다.

나는 fork를 어떤 레포지토리 안에서 작업할 브랜치를 만드는 것처럼, 레포지토리 자체를 브랜치로 생성하는 것이라고 이해했다.

fork를 하는 이유는 무엇일까?

어딘가에서 계속 사용될지도 모르는 오픈소스의 원본 레포지토리를 아무나 직접 건들고 수정할 수 있으면 당연히 안 된다.

내가 열심히 개발한 프로젝트의 레포지토리를 누가 클론해서 코드를 삭제하고 push한 게 반영된다면? 끔찍할 것이다.

이를 위해 fork를 하는 것이다.

원본 레포지토리는 권한에 제한을 두어 함부로 망가지지 않게 하고, 기여자들은 fork를 통해 자신의 레포지토리에서 작업 후 원본 레포지토리로 PR을 올려, 권한을 가진 관리자들에게 승인되면 원본 레포지토리에 내 작업물이 반영된다.

이것이 fork의 장점이다. 내가 복사한 레포지토리는 원본 레포지토리와 연결되어 있어, 내 레포지토리에서 수정하게 되면 이 변경사항을 원본 레포지토리에 반영해달라고 요청할 수 있고, 원본 레포지토리의 변경사항도 내 레포지토리로 계속 받아올 수 있다.

또한, 내 fork한 레포지토리에서 작업을 한다면 아무리 코드를 망가뜨리고 바꿔놓아도 원본 레포지토리에 피해가 가지 않게 된다.

그러니 너무 부담갖지 말고 마음 편하게 작업하자!

fork 버튼을 누르면 위와 같은 화면이 보인다.

원본 레포지토리에서 작업 중인 브랜치에서 이어서 작업할 이슈가 있지 않은 이상, 보통은 main 브랜치만 가져오면 된다.

Create fork 버튼을 누르면 내 깃허브에 해당 레포지토리가 복사된다.

내 깃허브에 있는 복사본. Update branch가 필요하다.

'codepair'라는 레포지토리를 fork한 뒤, fork한 레포지토리를 내 깃허브에서 본 화면이다.

어떤 레포지토리를 fork했는지 링크가 걸려 있는 것을 확인할 수 있다.

이때 나만 쓰는 이 복사본을 origin이라 하고, 원본 레포지토리를 upstream이라고 한다.

기여를 하다 보면, 내 복사 시점 이후로 원본 레포지토리가 기여들로 인해 업데이트되어 내 복사본과 달라질 수 있다.

예를 들면 위 이미지에 있는 알림 문구에서는 이 브랜치가 upstream보다 2개의 커밋이 뒤처져있다고 알려주고 있다.

따라서 Sync fork - Update branch를 통해 origin 레포지토리를 계속 갱신(최신화)해주어야 한다.

이를 오랫동안 안 하게 되면 내 새로운 작업물과 원본 레포지토리 간 충돌이 나는 것은 당연한 일이다.

clone

이제 fork한 origin 레포지토리를 내 로컬 환경에 깔아주어야 한다.

clone을 통해 내 컴퓨터의 원하는 곳에 레포지토리를 복제해주면, 자신이 사용하는 IDE 환경에서 코드를 읽고 수정할 수 있게 된다.

즉 fork와 달리, 내 origin 레포지토리를 정말 그대로 사용할 수 있게 가져오는 것이다.

내 레포지토리의 우측 상단에 있는 Code 버튼을 누르면 클론을 위한 URL이 보인다.

해당 URL을 복사하여 터미널에 실행해 원하는 곳에 레포지토리를 깔아주면 된다.

git clone https://github.com/내 ID/레포지토리명.git

그리고 원본 레포지토리도 연결시켜 주어야 한다.

git remote -v

를 실행해보면, origin 태그와 함께 방금 clone한 URL이 보일 것이다.

git remote add upstream https://github.com/원본 레포지토리.git

원본 레포지토리의 URL을 가져와 위 명령어를 실행하여 원본 레포지토리를 추가로 연결하고, 다시 git remote -v를 확인해보면, 아래 사진처럼 보이게 된다.

또한 git status 명령을 통해 내가 어디에 있고 어떤 상태인지 알 수 있다.

우리는 로컬의 origin 레포지토리에서 브랜치를 생성해 작업하면 된다.

이렇게 모든 세팅을 로컬 환경에 완료하면, 다양한 git 명령어를 통해 작업을 진행할 수 있다.

우리는 결국 원격의 원본 레포지토리(upstream), 이를 내 깃허브에 포크한 원격의 복사본 레포지토리(origin), 이를 클론한 로컬 레포지토리로 총 3개의 레포지토리를 다루게 된다고 볼 수 있다.

따라서 깃허브에서 원본 레포지토리와 포크한 내 레포지토리 간 Sync fork를 해주었듯이, 원격 origin 레포지토리와 이를 클론한 로컬과의 동기화도 마찬가지로 진행해주어야 한다. (git pull origin main)

코드 읽기

기여를 시작할 때 가장 먼저 해야할 것은 레포지토리의 README.md와 CONTRIBUTING.md를 읽는 것이다!

README.md에는 보통 해당 프로젝트의 간략한 개요와 개발 환경을 구축하는 가이드라인이 적혀 있다.

설명에 따라 프로젝트를 실행하면 된다.

CONTRIBUTING.md에는 기여자들을 위한 가이드라인이 적혀 있다.

보통 해당 프로젝트의 기여 방법과 규칙이 적혀 있어, 반드시 읽어보고 이를 준수하여 기여 활동을 진행하면 된다.

그 다음으로는 로컬 환경에서 해당 프로젝트의 코드들을 읽어보면 되는데, 대부분 방대한 파일과 코드 양을 자랑할 것이다(...).

나같은 경우에는 적당한 규모의 프로젝트의 frontend 폴더만 열어서 읽었기 때문에 일단 주요 파일들을 다 읽고 시작했지만(물론 그래도 정말 많다), 어렵다면 이슈를 먼저 고르고 그와 관련된 코드들을 찾아가도 된다.

사실 오픈소스 기여는 코드 읽기가 7할이라고 보아도 무방하다.

난생 처음 보는 프로젝트의 엄청난 양의 코드들을 읽어내는 것은 쉽지 않다.

개인적으로 나는 공부할 때 목차부터 보는 스타일이라, 폴더별로 파일 이름들을 적어두고 파일을 하나씩 읽으면서 이 파일이 어떤 행동을 하는 파일인지 적으며 코드 읽기를 진행하였다.

즉 각 파일들이 어떤 파일인지 의도를 먼저 파악하고자 하였다.

프론트엔드를 예로 들어보면, 가장 먼저 route 파일을 확인해 어떤 라우트들이 있는지 보았다.

그리고 pages 폴더에 있는 페이지 파일명들을 적어두고, 한 파일씩 읽으며 이 페이지가 어떤 페이지인지 이해하고, components 폴더에 있는 컴포넌트 이름들을 적어두고 해당 컴포넌트가 어떤 컴포넌트인지 이해하면서 점점 구조화해나갔다.

페이지 내에서 컴포넌트들이 어떻게 쓰이는지 확인하면서 자연스럽게 UI/UX와 관련해 개선할 이슈들을 찾게 되었다.

이슈 선정하기

기여할 준비가 되었으면, 이제 이슈를 할당받아야 한다.

즉 어떤 기여 작업을 할 것인지 결정하는 것이다.

나처럼 코드를 먼저 읽어도 되고, 원본 레포지토리의 Issues 탭에 가서 기여가 필요한 목록들을 먼저 살펴보아도 된다.

이슈 목록

Issues 탭에서는 사람들이 해당 프로젝트에 대해 개선이 필요한 점들을 찾아 적어둔 내용들을 확인할 수 있다.

bug일 수도 있고, 새로운 기능을 구현하는 것일 수도 있고, 단순한 번역이나 오탈자 수정같은 문서 작업이 필요한 것일 수도 있다.

첫 기여는 언제나 떨린다! ~~나만 그런걸까~~

따라서 오픈소스에 처음 기여하게 된다면, 처음에는 아주 사소하고 작은 이슈를 해결하면서 오픈소스 기여 방법을 익히는 발판으로 삼는 것이 좋다. 한 번만 해보면 다음부터는 쉬워지고, 오픈소스 기여의 재미를 느끼게 될 것이다!

정말 별 거 아닌 문제 해결도 누군가는 해야 할 일이기 때문에, 사소하다고 기여를 망설이지 않았으면 좋겠다.

이슈마다 달려 있는 라벨을 통해 이슈를 목적에 따라 분류할 수 있으며, 대부분의 오픈소스 프로젝트에 들어가 보면 위에 내가 올려둔 화면처럼 'good first issue' 라벨을 따로 분류해둔 것을 확인할 수 있다.

이는 오픈소스 기여 비기너들의 기여 독려를 위해 처음 기여해보기 좋은 쉽고 간단한 이슈들을 마련해 둔 라벨이다!

얼마나 따뜻하고 아름다운 세상인가

이를 적극 활용하기 바란다.

나는 코드를 읽으며 import한 라이브러리에서 더 이상 지원하지 않는 컴포넌트를 사용하여 코드 취소선이 그어져 있는 것을 보고, 이를 업데이트하는 것을 첫 기여 대상으로 삼았다.

내가 찾은 이슈는 Issues 탭을 검토했을 때 존재하지 않는 이슈였기 때문에, 새로운 이슈로 작성해 등록하였다.

새로운 이슈를 찾아 등록하여도 되고, 이슈 목록에서 해결하고 싶은 이슈를 찾아도 된다.

새로운 이슈를 찾는 것도 일종의 기여 활동이라고 볼 수 있다.

누군가 올린 이슈를 해결하고 싶다면, 오른쪽 상단의 Assignees를 먼저 확인해보면 된다.

이슈 목록에서도 이슈마다 오른쪽 끝에서 Assignees의 프로필을 확인할 수 있다.

내가 등록한 이슈. 이슈를 등록할 때 생성된 양식에 맞추어 내용을 작성하였다.

Assignees에 누군가 할당되어 있다면, 그 사람이 해당 이슈를 해결하고 있는 담당자라고 보면 된다.

만약 할당된 사람이 없는 이슈에 기여하고 싶다면 해당 이슈에 기여하고 싶다고 comment를 남기면 된다.

관리자(메인테이너, 커미터)가 확인하고 할당해줄 것이다.

그럼 기여 활동을 시작하면 된다!

그밖에도 만약 이미 할당된 사람이 있는데 오랫동안 작업이 이루어지지 않는 것 같아 이슈를 할당받고 싶거나, 작업하다가 논의할 사항이 생겨도 이 이슈의 comment를 이용하면 된다.

기여 활동

이슈를 할당받았다면 해당 이슈를 해결하기 위한 브랜치를 생성해 개발을 진행하면 된다.

로컬 환경의 내 origin 레포지토리에 브랜치를 생성하고, 브랜치에서 작업을 한 뒤 작업 내용을 커밋하고 원격의 origin 레포지토리에 push한다.

그럼 자동으로 원본 레포지토리인 upstream에 PR이 가능하게 된다.

PR

PR 작성하기

이제 깃허브로 돌아와 Pull Request을 작성한다.

위 사진과 같이, 내가 fork해서 만든 나의 origin 레포지토리의 한 브랜치(지금은 main이라 적혀 있지만, 특정 브랜치에서 작업한 경우 해당 브랜치의 이름이 오게 된다)에서 원본 레포지토리의 main으로 pull 요청을 보내게 된다.

내가 한 첫 기여의 PR

내가 작성했던 PR이다.

이슈와 마찬가지로 생성된 작성 양식에 따라 내용을 채워 PR을 올렸다.

이슈나 PR을 작성할 때 포맷이 정해져 있지 않다면 메인테이너와 커미터가 이를 이해할 수 있게끔 자세하게 작성하면 된다.

이슈 목록에 있는 이슈를 해결하는 PR이라면 자신이 해결한 이슈 번호를 반드시 태깅해야 한다!

PR을 올리고 나면 해당 프로젝트에 걸려 있는 CI 파이프라인에 따라 1차 검토가 수행된다.

일반적으로는 린트 오류나 빌드 오류가 없는지 기본적인 코드 품질 검사를 거치게 되는데, 이때 오류가 발생한다면 반드시 다시 커밋을 통해 고쳐야 한다.

따라서 작업 내용을 커밋하기 전에 패키징 매니저의 스크립트를 통해 오류가 없는지 확인하고 사전에 수정하는 것이 좋다.

또한 처음 기여하는 프로젝트라면 CLA 사인을 요청받게 된다.

이는 Contributor License Agreement로, 해당 프로젝트에 기여한 코드에 대한 권한에 관한 법적 동의를 구하는 절차이다.

해당 내용에 사인하지 않으면 기여할 수 없게 된다.

CLA에 서명하고 코드 품질 검사도 통과하면 이제 관리자의 리뷰만 기다리면 된다.

관리자가 우리의 PR을 읽어보고 수정 사항이나 의견을 리뷰로 달아주면, 이를 반영하는 커밋을 거듭한다.

실수가 많으면 검토 과정에서 리뷰어도, 계속 수정하는 나도 고통받을 수 있다(...). 나의 능력이 허용하는 선에서 최대한 리뷰하기 쉽도록 가독성 좋고, 실수가 없는지 확인한 뒤 신중하게 PR을 올리도록 하자.

나도 컨트리뷰터!

모든 검토 작업이 성공적으로 끝나면, 관리자가 이를 approve하여 원본 레포지토리에 병합하고 자동으로 PR이 닫힌다.

즉, 오픈소스에 기여하게 된 것이다!

merge가 완료되었으면 작업이 끝난 내 브랜치는 삭제해도 좋다.

PR에 이슈가 연결되어 있었다면, PR과 함께 이슈도 자동으로 함께 닫힌다.

메인테이너의 감사 인사와, 오픈소스에 내 코드가 적혀 있는 것, 컨트리뷰터로 내 프로필이 올라가 있는 것을 보면 오픈소스 기여의 보람과 재미를 비로소 느끼게 될 것이다.

2개의 커밋으로 12등에 랭크된 나...

README의 컨트리뷰터 명단에 올라간 내 프로필

오픈소스에 기여해보기 전에는 '내가 감히 어떻게 그런 걸'이라는 생각에 도전하기를 주저했다.

물론 그 방대한 코드를 읽고, 내가 기여할 부분을 찾고, 개발한다는 것이 간단한 일은 아니다.

아무런 대가 없이 시간을 할애하는 일이기 때문이다.

그러나 어려운 일은 아니라는 생각이 든다.

내가 처음으로 기여한 이슈는 사실 개발 실력이 없어도 가능한 내용이었다.

즉 기여하는 루트만 알면 허들이 높지는 않다는 의미이다. 이 글로 이제 루트도 알지 않았는가

오픈소스에 기여하고자 하는 마음만 있다면, AI와 구글링의 도움을 받아서라도 충분히 할 수 있다고 생각한다.

오픈소스를 운영하는 사람들 입장에서 생각해보면, 대가 없이 프로젝트를 도와주는 컨트리뷰터들은 정말 소중할 수밖에 없다.

개발 활동을 하면서 감사하게 많은 오픈소스를 쓰는 만큼 오픈소스 생태계에도 많은 관심을 가져보길 바란다!

SQLD 제57회 벼락치기 합격 후기와 팁

harchiving — Mon, 21 Jul 2025 17:54:32 +0900

지난 5월 31일에 있었던 제57회 SQLD, SQL 개발자 자격증을 취득했다.

개정 이후 가장 어려웠다는 제57회 SQLD를 SQL 활용 파트를 버리고 간단하게 합격한 과정과 몇 가지 팁을 적어보고자 한다.

턱걸이 합격

배경

나는 컴퓨터공학 전공 학부생이지만, 데이터베이스는 올해 5월 처음 공부하게 되었다.

이번 학기에 데이터베이스 이론 과목을 수강하면서 중간고사와 기말고사 사이에 있는 SQLD 시험 응시를 병행해서 효율을 높이자는 생각이었고, 5월 초 중간고사에서 시험 범위였던 SQLD 1과목 일부를 학습해둔 뒤, 많은 내용을 잊어버리고(?) 벼락치기로 SQLD를 응시한 뒤에 6월에 있는 기말고사를 응시하게 되었다.

SQLD 1과목 일부라 함은, 데이터 모델링의 개념이나 데이터베이스 연산이 뭐가 있는지, 대충 어떤 원리의 연산인지 정도였다.

만약 데이터베이스 수업을 듣는 전공 학부생이라면, 나와 같은 일정으로 SQLD를 따는 것도 추천한다.

SQLD는 3일 정도 준비를 하긴 했지만, ~~극효율을 위해 자료 조사한 시간이 훨씬 많았고~~ 사실상 집중 공부한 건 시험 전날이 다였다.

솔직히, 정석적으로 공부한 건 아니라 참고만 하면 좋을 것 같다.

나는 전공생이기 때문에 아무리 베이스가 없었다고 해도 유리한 면이 분명히 있었을 것이기 때문이다.

하지만 찾아보니 SQLD는 요령껏 따는 응시자들이 대부분이기에(...) 자신의 실력을 보고 판단하면 될 것 같다.

시험 개요

SQLD는 SQL 개발자라는 국가 공인 자격증이다.

SQL과 관련된 자격증으로 SQLD보다 따기 어려운 SQLP, SQL 전문가 자격증도 있다.

SQLD는 이에 비해선 기초 자격증이라고 보면 된다.

하지만 SQLD의 합격률은 약 50% 내외로 그렇게 만만하지만은 않다.

SQLD 시험은 2024년, 제52회부터 출제 범위와 방식이 바뀌었다.

출처: 홍쌤의 데이터랩

출제 방식

시험 응시는 90분이며, 개정이 되면서 주관식이 사라지고 50문제 모두 4지선다 객관식으로 바뀌었다.

1과목 10문제(20점), 2과목 40문제(80점)로 문항 당 차등 없이 2점씩으로 2과목 배점이 훨씬 크다.

그러나 1과목 4문제(8점), 2과목 16문제(32점) 이상 맞히지 못하면 과락으로 탈락하니 전략을 잘 세워야 한다.

과락을 주의하며 100점 만점 중 총점 60점을 넘기면 합격이다.

출제 범위

주요 내용으로는 1과목에서 반정규화가 빠졌고, 2과목에서 Top N 쿼리나 PIVOT절이 추가되었으며, SQL 최적화 기본 원리 파트가 빠졌다.

개인적으로는 좀 더 컴팩트해진 느낌이다.

문제는 최근 개정되었다 보니, 최신 자료가 부족했다는 점인데, 이를 대비한 방법은 아래에서 소개하겠다.

응시 유의사항

시험은 분기별로 1년에 총 4번 있으며, 주말 오전에 치뤄진다.

나는 토요일 오전 10시에 응시하였고, 9시 30분까지 입실하여야 했다.

원하는 고사장에서 보기 위해서 미리미리 접수하는 것을 추천한다.

나는 접수 기간 초반에 접수하여 교통편이 가장 편한 곳에 있는 고사장에서 응시하였다.

응시료는 50,000원이다.

지참할 것은 컴퓨터용 사인펜과 신분증, 문제를 풀 때 쓸 펜(샤프)이다.

시험은 컴퓨터가 아닌 지필로 이루어져 종이 시험지를 보고 별도 OMR 답안지에 마킹하면 된다.

수험표의 경우 확인하지 않았고 고사실을 찾을 때와 답안지에 적을 때를 위한 내 수험번호만 알면 된다.

나 같은 경우에도 출력 없이 수험번호만 적어 갔다.

특이사항은 수정액과 수정테이프를 쓸 수 없다. ~~이런 시험은 처음 봤다~~

잘못 마킹한 경우 답안지를 교체해야 하며, 시험 종료 5분 전에는 교체도 불가하니 주의해야 한다.

실제로 우리 고사실에는 답안을 잘못 마킹했는데 답안지 교체 시간이 지나 그대로 제출한 응시자가 있었다...ㅠ

시험 도중 화장실을 갈 수 없고, 퇴실은 시험 종료 30분 전부터 가능했던 것 같으나 확실하진 않다.

별도 연습지는 제공되지 않아 시험지 여백에 풀면 된다.

시험지는 유명한 노랭이 책과 같은 양식으로 출력되어 있었다. (페이지 당 1~2문제)

공부 방식

일단 최대의 효율을 내기 위해 블로그를 뒤져가며 다른 사람들이 어떻게 공부했는지 봤다.

어느 정도 난이도인지, 얼마나 공부해야 하고 어떤 식으로 해야 하는지, 어떤 문제들이 나오는지 살펴보았다.

시간이 없던 나의 전략은, 2과목에서 주로 킬러로 많은 문제가 나오는 SQL 활용 파트를 통째로 버리고(!), 1과목과 2과목의 쉬운 문제들을 최대한 많이 맞혀서 60점을 넘기자는 것이었다.

지금 생각하면 말도 안 되는 과감하고 리스크가 큰 전략이긴 하지만... 돌아가도 그럴 것 같다...ㅎ ~~성공했기 때문에~~

1. 1과목 이론 공부&자료

어려운 2과목을 공부할 시간에 먼저 1과목을 제대로 익히고 외워 기본 점수를 얻고 갈 전략을 세웠다.

나 같은 경우는 학교 중간고사로 대충 어떤 원리인지 알고 있었기 때문에, 다시 개념을 보고 머리로 정리하면서 벌써 까먹은 기억을 되살리고 외우는 과정이 필요했다.

그 수단으로 유튜브 @홍쌤의 데이터랩에 올라와 있는 [2025 개정] SQLD 1과목 완벽 정리를 쭉 들었다.

개정 전 자료들이 훨씬 많아, 개정 후 이론만 찾아보기 어려웠는데 개정 후 정리 영상이 있어 편하게 자료를 영상으로 보면서 익혔다.

자료로는 다양한 자료를 찾았지만, 가장 좋았던 자료는 블로그에 올라온 개정판 개념정리 pdf 였다!

개정이 된 지 얼마 되지 않았고, 개념서를 따로 구입하지 않았다 보니 개념을 눈으로 보고 익힐 만한 최신 요약본이 필요했는데 이 블로그에 올라온 pdf가 정말 많이 도움이 되었다. 너무 너무 정리를 잘 해주셨다 !

이 pdf를 굿노트에 옮겨서 위의 유튜브 정리 영상을 보며 같이 읽었다.

다만, 영상을 보면 아시다시피 짚어주고 넘어가는 식이기 때문에 이론을 아예 모르고 들으면 어려울 수 있을 것 같다.

요약본으로도 머리에 잘 들어오지 않는 경우엔 시간을 더 두고 개념을 공부해야 하는데, 나는 개념을 전공 서적(데이터베이스개론)으로 공부했었으나, 오로지 자격증 취득 목적이라면 차라리 SQLD를 위한 유료 인강 패키지같은 것을 끊어 수강하거나 개념서를 구매해 보는 게 더 효율적일 것 같기는 하다.

이 블로그의 데이터베이스 카테고리에는 전공 강의를 들으며 데이터베이스개론 책을 중심으로 이미지와 함께 정리된 내용이 있으니 이론 공부를 할 때 가볍게 참고해도 좋다. 이론의 경우 전공이라고 해도 쉬운 편이기 때문에 시간이 있다면 책을 읽는 것도 나쁘진 않을 것 같다.

대충 영상으로 내용을 훑은 뒤엔 유명한 일명 노랭이를 풀었다.

노랭이는 시험을 주관하는 한국데이터산업진흥원에서 출간하는 실전문제집으로, 시험 범위에 해당하는 문제만 수록되어 있다.

기출 문제는 아니고, 예시 문제라고 생각하면 된다.

문제 수가 많지 않아 오래 걸리지는 않는다.

노랭이 개정판

확실히 모르는 경우엔 답을 적지 않았고, 빠르게 푼 뒤에 틀린 문제의 해설지를 읽으며 개념을 읽혔다.

또 요약본 pdf에서 해당 개념 부분을 찾아 읽거나 표시했다.

2. 2과목 공부

나는 말했다시피 2과목의 핵심인 SQL 활용 부분을 버렸다.

따라서 먼저 SQL 기본 부분을 요약본과 해당 파트를 설명하는 유튜브 영상 몇 개를 무작위로 보며 익히고, 노랭이를 풀었다.

충분히 어려웠고 엄청 많이 틀렸다. (ㅋㅋ) 하지만 노랭이를 풀며 어떤 식으로 풀어야 하는지 감이 왔다.

예를 들면 선지가 엄청 긴 SQL 문제들을 자세히 보면 긴 SQL문에서 딱 하나의 절만 바꾸어 써두었기에 그 부분만 보면 된다던지..!

자주 출제하는 유형, 또는 함수들이 있다.

SQLD 문제는 4지선다이기 때문에 소거법으로 풀어도 된다.

물론 공부를 할 때에는 왜 이게 답이고, 뭘 물어보려는 건지 해설을 읽어보며 대충은 알아야 한다.

SQL 기본 파트를 공부하고 나서는 SQL 활용 파트를 건너뛰고, 관리 구문 파트를 공부했다.

SQL 기본 파트에서 나오는 데이터베이스 이론과, 관리 구문 파트는 그냥 암기이기 때문에 점수를 주는 문제다.

따라서 이 부분과, 1과목에서 최대한 점수를 따려고 했다.

노랭이를 풀다 보면 해설을 봐도 이해가 잘 안 되는 부분들이 있는데, 그 부분들은 네이버 카페인 데이터 전문가 포럼에서 알아냈다.

모르는 문제를 검색하면 대부분 나와 같은 질문을 해서 질문글 댓글을 통해 궁금증을 해소할 수 있었다.

물론 해소되지 않을 때도 있었지만, 시간이 없었기 때문에 어려우면 굳이 붙잡고 있지 않았다...

해당 카페는 이 용도 말고도 굉장히 많은 응시자가 활동하기 때문에 기타 정보들을 얻기 유용했으므로 가입을 추천한다.

또, 노랭이가 실제 시험 난이도보다 어렵다고 하길래, 너무 어렵거나 어려워 보인다(...) 싶은 몇 문제는 풀지 않고 출제 내용이 무엇인지만 해설지로 확인했다.

실제로, 시험장에서 풀어 보니 시험 문제가 훨씬 쉽게 느껴졌다.

시험 개정이 되면서 노랭이도 개정이 되어 문제 번호가 다르거나 바뀐 것들이 있었는데, 그건 카페의 이 글에서 알 수 있다.

검색할 때 참고하면 된다.

요약본과 노랭이를 대충 훑은 뒤엔, 공부하지 않은 SQL 활용 부분의 요약본을 읽었다.

문제는 풀기 싫고, 풀 자신도, 시간도 없었기 때문에 어떤 개념이 있는지 보고, 외울 수 있는 부분은 대강 살펴 보았다.

조인이 포함된 기본 쿼리문을 알면, 서브쿼리문도 복잡할 뿐이지 대충 원리는 알 수 있기 때문에, 현장에서 잘 찍겠거니 하고 뒷부분의 함수들이 뭐가 있나 보았다.

3. 기출 풀이

여기까지 한 뒤에는 기출 문제들을 검색해 살펴보았다.

다른 유료 교재나 모의고사를 구매하지 않은 이상, 기출 문제는 정석적인 자료가 있진 않았다.

몇몇 사이트들이 있긴 했지만 대부분 개정 전 자료들 기반이라 오히려 혼란을 줄 것 같아서 예전 기출은 보지 않고, 이 사이트의 52회 이후 복원 글과 아까 말한 카페의 SQLD 관련 카테고리에서 지난 응시자들이 머리를 맞대고 적어둔 복원 글을 참고해 문제와 정답을 시험 날 아침에 벼락치기로 읽다가 시험을 쳤다.

실제로 도움이 꽤 되었다.

시험 후기

시험 동안은 배고프고 피곤한 게 더 컸고... 확실히 노랭이보다는 평이~비슷한 느낌이었다.

시간은 적당히 남았고 풀지 못한 몇 문제 빼고는 금방 풀어 생각보다 빠듯하지는 않았다.

1과목은 확실하게 외우지 않으면 풀지 못하기 때문에 헷갈리는 문제들이 많아 고민하다가 시간을 꽤 썼는데, 2과목은 오히려 쉬운 문제를 빠르게 쳐낼 수 있었다.

선지가 보통 4개 중에 2개는 확실히 답이 아니고, 2개 중에 헷갈리게 출제된다.

일단 자신의 감(...)을 믿고 한번 끝까지 완주한 뒤에 못 풀었던 문제를 풀기를 바란다.

1과목 같은 경우는 헷갈려도 더 끌리는 선지에 찍고 넘어갔고, 2과목 같은 경우는 어려워 보이거나 복잡한 문제는 그냥 넘기고 풀었다. 어차피 그 문제 못 풀어도, 50문제 중에 20문제 틀려도 합격이라는 점을 잊으면 안 된다!

아는 문제를 잘못 풀거나 잘못 마킹하지 않는 것에 더 집중했다.

나는 마킹까지 다 한 뒤에 남은 문제들은 끝까지 보고 풀 수 있는 건 풀고 적당히 찍었다.

1과목과 2과목 기본 문제를 맞히고, 나머지는 잘 찍어서 합격하자는 내 전략은 아무튼 성공했다.

'학습'을 위해 추천하는 건 아니지만... 합격을 위해서라면 추천한다.

확실히 다른 문제는 평이하게 나오고, 1과목의 어려운 문제와 SQL 활용 문제 중 어려운 문제들이 있는데, 이 문제들까지 맞히려면 열심히 공부해야 할 듯 하다.

다만, 내 체감상으로도 그렇고 다른 응시자들 후기를 보았을 때 노랭이 책의 문제가 상당히 도움이 된다.

아예 똑같이 출제되는 문제들도 있다.

다른 응시자들의 공부 전략을 보면 노랭이를 3회독 이상 하던데, 시간이 된다면 좋은 것 같다.

다만 노랭이 책이 만듦새가 좋지 않다. 정오표도 엄청 길고... 노랭이 책을 다 공부하고도 불안하다면 다른 사람들은 유료 모의고사를 많이 푸는 것 같다.

물론 나는 돈 쓰는 게 아까워서 사서 공부하진 않았다. +시간도 없었다.

개정 이후 출제 방향에 관해 궁금해하는 사람들이 많다.

개정 이후 내용이 크게 달라지지 않아 개정 전 자료로 공부해도 된다고 하는데, 나는 시간이 없는 관계로 괜히 없는 내용 공부하기 싫어 개정 후 자료만 찾아보았다. 개인 취향인 것 같다.

개정 이후에 새로 추가된 범위(PIVOT절 등)에 대해 신유형들이 매회차 나오고 있다고 한다.

공부하지 않아서 모르겠지만... 몇 문제 되지 않아도 2과목 중 반 이상은 맞혀야 합격 선을 넘기기 때문에 전략을 잘 세우는 게 좋겠다. 불합격자들도 한두 문제 차이로 불합격하는 사람들이 많다.

체감상으로는 1과목이 생각보다 어려웠고, 2과목 기본 문제는 상당수의 문제가 생각보다 더 쉽게 나왔다.

SQLD 시험이 점점 어려워지고 있다고 한다. 제57회가 지금까지 중에 가장 어려웠다는 반응들을 보았다.

내 생각에, 베이스가 있는 경우 일주일 잡고 노랭이를 열심히 풀면서 모르는 부분을 찾아보는 식으로 하면 충분히 합격할 것 같고,

베이스가 없는 경우 깔끔하게 강사의 유료 패키지를 끊어 커리큘럼에 맞춰 개념부터 2주~한 달 공부하면 합격할 듯 하다.

시간이 될수록, 노랭이와 예전 복원 문제들을 풀기를 추천한다.

자료의 경우에는 이것저것 모두 찾아보긴 했으나, 도움이 되고 결정적으로 공부할 때 사용한 것은 위에 적은 블로그 pdf와 네이버 카페, 홍쌤 유튜브 영상이 전부였다.

덧붙여, 서울시에 거주하는 청년이라면 미취업청년 응시료지원 사업을 통해 SQLD 응시료를 환급받을 수 있다.

구체적인 내용은 각 구청 홈페이지에서 확인할 수 있다.

후기 끝!

[운영체제] 8. 메모리 관리

harchiving — Sat, 14 Jun 2025 22:09:35 +0900

해당 내용은 공룡책(Operating System Concepts 10th Ed: Abraham Silberschatz, Peter Baer Galvin, Greg Gagne)과 대학 강의를 기반으로 재구성하여 정리한 공부 내용입니다.
+) 6장부터는 사자책(명품 운영체제: 황기태)에 더 중점을 두고 전개됩니다.

1. 메모리 계층 구조와 메모리 관리 핵심

메모리 계층 구조: CPU 레지스터 - 캐시 메모리 - 메인 메모리 - 보조 기억 장치 ...

읽기쓰기의 속도와 용량에 따라 계층 구조를 이루는 것

중심에 메인 메모리 존재!(일반적으로 메모리 = 메인 메모리 지칭)

메인 메모리(RAM): 휘발성, 하드 디스크: 비휘발성

메인 메모리 없이 컴퓨터 존재할 수 없음

CPU의 빠른 명령 처리 속도와 메모리 응답 속도의 차이 문제

→ CPU가 명령과 데이터를 가져오는 메모리 액세스 시간을 단축시켜야 하는 문제 (메모리 계층 구조의 목적!)

→ 메인 메모리보다 빠른 캐시 메모리를 CPU와 메인 메모리 사이에 설치해 사용

캐시 메모리: CPU가 현재 실행하는 프로세스 코드와 데이터 중 당장 실행할 일부를 메인 메모리에서 가져다 실행

일부만 두는 데도 효과적인 이유 → 참조의 지역성 때문

지역성의 두 종류:

1) 시간적 지역성(Temporal Locality): 한 번 참조된 데이터는 가까운 미래에 다시 참조될 가능성이 높음

2) 공간적 지역성(Spatial Locality): 메모리의 특정 부분이 참조되면, 그 인접한 메모리 위치도 곧 참조될 가능성이 높음

하드 디스크나 SSD 같이 대용량이면서 값이 싼 보조 기억 장치를 메인 메모리의 연장된 저장 공간으로 활용

메모리 계층 구조 요소

1. CPU 레지스터

CPU가 현재 실행할 코드와 데이터, 다음에 실행할 몇 개의 코드와 데이터를 미리 저장할 목적

일반적으로 8~30개

레지스터 1개 크기 32비트

2. 캐시 메모리

주기억장치로 사용하고 있는 메인 메모리보다 더 빠른 메모리

CPU의 빠른 처리 속도를 맞추기 위해 도입됨

가격이 비싸 소량만 사용됨

응답 속도와 위치에 따라 여러 레벨로 나누어 사용 - 현대의 멀티 코어 CPU의 경우 코어별로 L1/L2, 공유하는 L3 캐시를 두는 식

3. 메인 메모리

현재 실행 중인 모든 프로세스 코드와 데이터, 읽고 쓰는 여러 파일들의 블록, 운영체제의 커널 코드와 데이터 저장되어 있음

(캐시 메모리에서 일부 복사하는 코드와 데이터는 사용자 프로그램과 커널 구분 없이 복사됨)

4. 보조기억장치

전원을 꺼도 지워지지 않는 대용량 저장 장치

메인 메모리 크기 한계로 인해 적재된 프로그램 코드와 데이터 일부를 일시 저장하는 용도(스왑 영역)로도 사용됨

프로그램 실행과 메모리 계층 구조

1. 운영체제가 보조기억장치에 저장된 실행 파일을 메인 메모리에 적재

2. 메인 메모리에 적재된 코드와 데이터 중 실행할 일부 코드와 실행에 필요한 데이터가 L3 캐시로 복사

3. L3 캐시에서 당장 실행할 코드와 데이터 일부가 L1/L2 캐시로 복사

4. CPU 코어가 L1/L2 캐시에서 현재 실행할 명령과 데이터를 레지스터로 읽어 들인 후 연산 실행

L1, L2, L3 캐시 모두 컴퓨터 시스템에 따라 존재 유무 다를 수 O

→ 캐시 없는 경우 CPU가 메인 메모리로부터 코드와 데이터를 액세스해 명령 실행

→ 캐시 있는 경우 CPU가 캐시로부터만 코드와 데이터를 읽고 실행 → 반드시 실행에 필요한 내용 캐시로 복사되어야 함

메인 메모리 ↔ 캐시

CPU가 현재 프로세스나 스레드 실행을 중단하고 다른 프로세스나 스레드 실행 시 L1/L2 캐시에는 새로 실행하고자 하는 프로세스나 스레드의 명령과 데이터를 찾을 수 없는 캐시 미스(cache miss) 발생 → 연쇄적으로 메인 메모리로부터 L3 캐시, L1/L2 캐시로 새 프로세스 코드와 데이터 이동. 그전에 현재 캐시에 들어 있는 데이터 중 수정된 데이터는 L3 캐시나 메인 메모리에 기록돼야 함

→ 캐시로 인해 프로세스나 스레드의 컨텍스트 스위칭이 코드와 데이터를 이동시키는 보이지 않는 오버헤드 초래

캐시 미스는 프로그램 실행 중에도 발생

메인 메모리 ↔ 보조기억장치

메인 메모리 전체가 사용 중이거나 빈 영역이 일정 이하로 줄어들면 메인 메모리에 적재된 코드나 데이터 일부를 하드디스크나 SSD에 저장해 공간을 확보하는 기법 → 가상 메모리

메모리 계층화가 효율적인 이유: 참조의 지역성(locality of reference)

: 코드나 데이터, 자원 등이 아주 짧은 시간 내에 다시 사용되는 프로그램의 특성

→ 빠른 캐시를 사용해 얻는 이득 > 캐시를 다시 채우기 위해 CPU가 대기하는 실

메모리 보호

프로세스 간 독립된 메모리 공간을 가지도록 보장해야 하며, 프로세스별 메모리 공간은 서로를 보호하고 병행 실행을 위해 여러 프로세스가 메모리에 적재되게 해야 함

base 레지스터와 limit 레지스터를 사용하여 보호 기법 제공

base 레지스터는 가장 작은 물리 메모리 주소 값을 저장하고, limit 레지스터는 주어진 영역의 크기를 저장한다.

CPU는 사용자 모드에서 만들어진 모든 주소와 레지스터를 비교하여 다른 사용자 프로그램 또는 운영체제의 메모리 공간에 접근하면 트랩을 발생시킨다.

주소가 base보다 크거나 같은지, base+limit보다 작은지 확인

메모리 관리

메모리를 운영체제에 의해 관리해야 하는 이유:

1. 여러 프로세스에 의해 사용되는 공유 자원으로, 프로세스가 임의의 메모리 영역을 사용하게 할 수 없기 때문 - 메모리 할당 관리 필요

2. 메모리를 보호하기 위함. - 사용 중인 메모리에 대해 프로세스 접근 제어 및 사용자 모드에서 커널 공간 접근 제어 위한 보호 기능

3. 메모리의 용량 한계를 극복하기 위함. - 메모리의 물리적 크기 한계를 극복하는 가상 메모리 같은 메모리 관리 정책 필요

4. 메모리 사용 효율을 높이기 위함. - 다중프로그래밍정도(DOM);운영체제가 메모리에 동시 적재하여 실행시키는 프로세스 개수 = 운영체제 메모리 관리 효율성을 나타내는 지표. 메모리 용량 대비 많은 프로세스를 실행시켜 시스템 처리율을 높여야 함

→ 기본적인 메모리 관리 기능: 할당과 보호 - 프로세스에 메모리 배분, 자신 영역 외 침범하거나 훼손하지 못하게 제어

메모리 주소

메모리는 오직 주소를 이용해서만 접근됨

1. 물리 주소: 실제 메모리 주소(하드웨어 주소); address bus에 연결됨.

2. 논리/가상 주소: 프로그램 내에서 사용되는 주소; 코드나 데이터(변수나 동적 할당 메모리)의 주소

CPU가 프로세스 실행 동안 다루는 모든 주소는 논리 주소이다.

커널도 논리 주소로 이루어져 커널 코드가 실행될 때에도 논리 주소가 물리 주소로 바뀌어야 한다.

논리 주소의 물리 주소 변환

메모리를 액세스하기 위해서는 논리 주소가 물리 주소로 바뀌어, 물리 주소가 물리 메모리에 전달되어야 한다.

(위 그림처럼) CPU가 논리 주소를 사용해 물리 메모리에 데이터를 저장하고자 하면, 이 명령을 실행하기 위해 논리 주소 4번지를 발생 → 주소 변환 하드웨어(MMU)에 의해 물리 주소로 변환 → 주소가 CPU 패키지 바깥으로 빠져 나가 물리 메모리에 전달

주소 변환 하드웨어 MMU(Memory Management Unit): 프로세스의 논리 주소와 물리 주소의 매핑 정보를 담은 매핑 테이블을 참고하여 논리 주소를 물리 주소로 변환한다.

메모리 관리 방식에 따라 다르게 구현되며, CPU 패키지 내에 구성된다.

매핑 테이블과 MMU 덕분에 컴파일러는 프로그램을 논리 주소로 컴파일하는 데 부담이 없고, 운영체제도 프로세스의 코드와 데이터를 물리 메모리 빈 곳 아무데나 할당하고 적재해도 되며, 프로그램 개발자도 응용프로그램이 어디에 적재될지 몰라도 된다.(알 수도 없다.)

동적 로딩

프로세스가 실행되기 위해서는 그 프로세스 전체가 미리 메모리에 올라와있어야 했지만, 메모리 공간의 효율적 이용을 위해 동적 로딩을 사용하면 각 루틴(함수)이 실제 호출되기 전까지는 메모리에 올라오지 않고 재배치 가능한 상태로 디스크에 대기하고 있다.

메모리에 있는 루틴이 다른 루틴을 호출하면 호출된 루틴이 메모리에 적재되어 있는지 조사하고, 안 되어 있다면 relocatable linking loader가 불려 요구된 루틴을 메모리에 가져온 뒤 변화를 테이블에 기록한다.

장점은 루틴이 필요한 경우에만 적재되는 것 → 오류 처리 루틴처럼 빈도가 낮은데 실행할 코드가 많은 경우에 유용

운영체제의 특별한 지원 필요 없지만, 동적 로딩을 구현하는 라이브러리 루틴을 제공해줄 수는 있다.

동적 링킹

링킹을 실행 시기까지 미룸

Static linking의 경우: 시스템 라이브러리와 사용자 코드가 로더에 의해 실행 파일 이미지 내에 통합

Dynamic linking의 경우: 코드와 라이브러리가 분리되어 있어 필요 시 로드됨

동적 링킹은 주로 시스템 라이브러리에 사용되어 메모리 낭비를 줄인다.

또한 공유된 시스템 라이브러리를 참조, 즉 이러한 라이브러리를 여러 프로세스 간에 공유할 수 있게 하여 패치나 보안 업데이트 적용도 용이하다. → 버전 관리 필요

(동적 링킹 라이브러리를 공유 라이브러리라고도 한다.)

스텁(stub): 프로그램이 실행될 때 동적 라이브러리에 있는 함수 호출을 처리하기 위해 사용되는 코드 조각

주로 PLT(Procedure Linkage Table)에 위치

PLT는 각 외부 함수 호출을 위한 stub 코드들의 집합이다.

프로그램이 동적 라이브러리 함수를 호출할 때 실제 주소를 찾을 수 있도록 지원한다.

함수의 첫번째 호출 시 동적 링커에 의해 실제 함수 주소를 찾아 GOT(Global Offset Table)에 저장

이후 호출 시에는 GOT에 저장된 실제 주소로 점프

동적 링커는 실행 파일이 로드될 때 NEEDED 정보를 참고해 필요한 라이브러리들을 메모리에 로드

로드 과정에서 라이브러리 내의 함수와 변수 심볼을 실행 파일의 심볼 테이블과 매칭함

MMU(memory management unit)

논리 주소를 물리 주소로 바꾸어 주는 하드웨어 장치

base 레지스터 = relocation 레지스터

동적으로 논리 주소에 재배치 레지스터 값을 더해 주소를 변환

물리 메모리 관리

메모리 할당

메모리 할당: 운영체제가 새 프로세스를 실행시키거나 실행중인 프로세스가 메모리를 필요로 할 때 프로세스에게 물리 메모리를 할당하는 것

1) 프로세스의 코드와 데이터를 적재하기 위한 공간 할당 2) 프로세스 실행 중 동적으로 스택이나 힙을 사용할 때 필요한 공간 할당

→ 전적으로 운영체제 커널에 의해 수행됨

명령어와 데이터를 메모리 주소로 주소 바인딩하는 것은 3개의 다른 단계에 발생할 수 있다.

Compile time: absoute code 생성 (메모리 위치가 바뀌면 재컴파일되어야 한다)

Load time: relocatable code 생성 (프로그램이 메모리에 적재될 때 실제 메모리 주소가 할당된다.)

Execution time: 실행 시간까지 바인딩을 지연. 주소 맵을 위한 하드웨어 지원이 필요하다.

컴파일 타임 및 로드 타임 바인딩 → 컴파일러와 링커에 의해 매겨진 주소

실행 타임 바인딩 → 가상 메모리 시스템으로, 운영체제가 메모리 보호 및 접근 제어를 담당

논리 주소와 물리 주소 분리 효과

1. 논리 주소 공간을 물리 주소 공간보다 크게 설정 가능:

사용 가능한 실제 메모리 크기를 초과하는 데이터와 코드 처리 가능

개발자가 실제 메모리 제약 없이 프로그램을 더 자유롭게 설계할 수 있음

2. 동적 메모리 할당 시 효율성:

프로세스가 물리적 메모리의 어떤 특정 위치에 구속받지 않고, 필요에 따라 어디에나 위치 가능

메모리 조각화 문제를 완화할 수 있으며, 물리 메모리 이용률을 최적화

3. 프로그램의 독립성:

논리 주소를 사용하여 프로그램은 물리적 메모리와 독립적으로 작동

개발자가 메모리 관리에 대한 복잡성을 신경 쓰지 않고 코드를 작성할 수 있음

운영체제의 메모리 할당 기법

연속 메모리 할당

연속 메모리 할당(contiguous memory allocation): 각 프로세스에게 메모리 한 덩어리씩 할당하는 기법

→ 프로세스가 할당받은 메모리가 한 덩어리로 연속된 공간임을 의미함

1) 고정 크기 할당(fixed size partition allocation)

: 메모리 전체를 파티션으로 불리는 고정 크기로 나누고, 프로세스마다 1개의 파티션을 할당하는 기법

= 고정 할당, 정적 할당이라고도 부름

파티션의 크기는 모두 같거나 다를 수 있다.

프로세스 크기에 가장 가까운 파티션을 할당한다.

고정 크기 할당을 사용한 대표 사례: IBM OS/360 MFT 운영체제

메모리 전체를 n개의 동일한 크기의 파티션으로 분할해두고, 프로세스를 실행시킬 때 각 프로세스에게 1개의 파티션을 할당함

동시에 실행시킬 수 있는 프로세스 개수는 n개로 제한, 새로운 프로세스가 도착하면 작업 큐에서 대기해야 한다.

프로세스가 파티션 크기보다 작은 경우 메모리 일부가 낭비되는 문제(=내부 단편화)

파티션 크기보다 큰 프로세스는 처음부터 실행될 수 없는 문제

→ 시스템 운영자가 실행시킬 전체 응용프로그램들의 크기를 사전에 계산하여 파티션 크기를 정하는 방식으로 해결

(당시에 실행시킬 응용프로그램이 정해져 있었기에 가능한 방법이다.)

2) 가변 크기 할당(variable size partition allocation)

: 프로세스마다 프로세스와 동일한 크기의 메모리를 할당하는 기법

= 동적 할당이라고도 부름

파티션이 미리 나누어져 있지 않고 프로세스 크기나 요청에 따라 파티션 크기가 정해진다.

가변 크기 할당을 사용한 대표 사례: IBM OS/360 MVT 운영체제

수용 가능한 프로세스의 개수가 가변적

프로세스가 도착했을 때 가용 메모리가 부족 → 실행 중인 프로세스가 종료되어 필요한 만큼 가용 공간이 생길 때까지 작업 큐에서 대기한다.

단편화(fragmentation)

단편화: 프로세스에게 할당할 수 없는 작은 크기의 조각 메모리(hole)들이 생기는 현상

위치에 따라 내부 단편화, 외부 단편화로 분류

어떤 메모리 정책을 사용해도 단편화는 발생 → 단편화로 인한 메모리 낭비를 줄이는 메모리 할당 정책 강구

내부 단편화

프로세스에게 할당된 메모리 영역 내에 활용할 수 없는 홀이 생기는 경우

고정 크기 파티션에서 발생

프로세스 크기와 파티션 크기의 차이만큼 내부에 홀이 발생 → 다른 프로세스에게 할당할 수 없는 낭비 메모리임

외부 단편화

할당된 메모리들 사이에 활용할 수 없는 홀이 생기는 경우

가변 크기 파티션에서 발생

외부 단편화로 인해 할당할 메모리가 부족해지면 파티션을 이동시켜 홀을 없애는 메모리 압축(memory compaction) 기법을 사용할 수 있다.

연속 메모리 할당 구현

하드웨어 지원

하드웨어적 구현이 필요한 부분:

1) 프로세스 실행 중 논리 주소를 물리 주소로 변환하는 기능

2) 프로세스가 다른 프로세스의 메모리 액세스를 금지하는 기능

구현을 위해 필요한 CPU 레지스터 및 장치:

- base 레지스터: 현재 실행 중인 프로세스에게 할당된 물리 메모리 시작 주소

- limit 레지스터: 현재 실행 중인 프로세스에게 할당된 메모리 크기

- 주소 레지스터: 현재 액세스하는 메모리의 논리 주소

- 주소 변환 하드웨어(MMU): CPU에서 나오는 논리 주소를 물리 주소로 변환하는 장치

명령 레지스터에 있는 명령을 실행하기 위해 논리 주소 300이 물리 주소로 변환되어야 함

→ CPU가 주소 레지스터에 담긴 논리 주소 300 출력 → MMU가 논리 주소를 limit 레지스터의 값과 비교해 할당된 메모리 범위 내인지 체크함(다른 프로세스 메모리 보호 위함) → 범위를 넘어서면 시스템 오류 신호를 발생시켜 CPU가 오류를 처리하는 커널 코드를 실행하고 현재 프로세스를 강제 중단 / 정상 범위이면 MMU가 'base 레지스터에 저장된 물리 주소 1000 + 주소 레지스터에 담긴 논리 주소 300 = 물리 주소 1300 생성하여 CPU 패키지 바깥으로 내보냄 → 물리 주소 1300이 주소 버스를 타고 메모리에 전달 → 메모리는 1300번지에 저장된 데이터를 데이터 버스에 내놓음 → CPU가 이 값을 CPU 내부로 전달

운영체제 지원

모든 프로세스에 대해 프로세스별로 할당된 물리 메모리의 시작 주소와 크기 정보를 저장 관리

비어 있는 메모리 영역 관리

→ 새 프로세스를 스케줄링하여 실행시킬 때마다 물리 메모리의 시작 주소와 크기 정보를 CPU 내부 base, limit 레지스터에 적재

홀 선택 알고리즘

hole selection algorithm = 동적 메모리 할당(dynamic memory allocation); 운영체제가 프로세스를 처음 실행시키거나 프로세스의 실행 도중 메모리가 요구될 때 적당한 홀을 선택해서 할당해야 한다.

고정 크기 할당 시: 홀들을 가용 메모리 리스트로 만들어 관리하고, 이중 하나를 선택하면 됨

가변 크기 할당 시: 메모리 전체에 있는 홀마다 시작 주소와 크기 정보를 구성하고, 이들을 홀 리스트(또는 가용 메모리 리스트)로 만들어 관리해야 함. 그리고 메모리 할당 요청이 발생하면 홀 리스트에서 적절한 홀을 선택해야 함. → 어떤 홀을 선택하느냐에 따라 성능이 상이하여 선택이 중요!

1. first-fit(최초 적합)

홀 리스트를 검색하여 처음으로 만나는, 요청 크기보다 큰(수용 가능한) 홀 선택

good: 알고리즘 속도는 빠름

bad: 외부 단편화로 인한 메모리 낭비 큼

2. best-fit(최적 적합)

홀 리스트를 검색하여 요청 크기를 수용하는 것 중 가장 작은 홀을 선택

good: 메모리 낭비 적음

bad: 홀 리스트가 크기별로 정렬되어 있지 않은 경우, 홀을 전부 검색해야 하는 부담이 존재

3. worst-fit(최악 적합)

홀 리스트를 검색하여 요청 크기를 수용하는 것 중 가장 큰 홀을 선택

bad: 홀 리스트가 크기별로 정렬되어 있지 않은 경우, 홀을 전부 검색해야 하는 부담이 존재

잘 사용하지 않음!

연속 메모리 할당의 장단점

good:

메모리 할당 알고리즘이 단순하여 구현이 용이

논리 주소를 물리 주소로 바꾸는 과정이 단순하여 CPU의 메모리 액세스 속도가 상대적으로 빠름(시작 위치, 크기 정보만 관리하면 됨)

bad:

프로세스에게 하나의 연속된 메모리를 할당하여 메모리 할당의 유연성이 부족하다.

메모리 전체에 비어 있는 작은 공간(홀)들을 합하면 충분한 공간이 있음에도 불구하고, 프로세스를 적재할 만큼은 연속된 메모리가 없어 프로세스를 적재할 수 없는 경우가 발생한다.

→ 분할 메모리 할당 기법으로 해결

→ 홀들을 한쪽으로 모아 큰 빈 메모리 공간을 만드는 메모리 압축 과정이 필요

처음부터 프로세스에게 필요한 메모리를 예측하여 큰 메모리를 할당한다면 내부 단편화를 초래하는 메모리 낭비가 생길 수 있다.

버디 시스템

오늘날 리눅스의 커널 메모리 관리에 사용되는 메모리 할당 알고리즘

메모리 할당과 반환 속도를 높이기 위해, 고정 크기 할당과 가변 크기 할당의 장점을 결합한 연속 메모리 할당 정책을 사용하는 것

분할 메모리 할당

분할 메모리 할당(non-contiguous memory allocation): 프로세스에게 필요한 메모리를 여러 덩어리로 나누어 분산 할당하는 기법

1) 가변 크기 할당 - 세그먼테이션(segmentation)

: 프로세스에게 크기가 다른 여러 개의 덩어리 메모리를 할당하는 기법.

프로세스를 여러 개의 논리적인 덩어리(=세그먼트)로 분할한다.

이때 각 덩어리가 세그먼트(segment)이다.

각 논리 세그먼트에 한 덩어리의 물리 메모리를 할당하는 정책이다.

세그먼트: 프로세스 내에서 하나의 단위로 다룰 수 있는 의미 있는 블록(논리 블록) ex. 함수, 객체

→ 프로세스를 구성하는 각 세그먼트들의 크기가 다를 수 밖에 없다.

프로세스를 구성하는 세그먼트들을 물리 메모리에 분산 할당(주로 코드, 데이터, 스택, 힙 4개 세그먼트로 분할)

코드 세그먼트 - 프로그램 전체에 걸쳐 작성된 모든 코드들을 모음

데이터 세그먼트 - 프로그램 전체에 걸쳐 선언된 전역 변수들과 정적 변수들을 모음

스택 세그먼트 - 함수가 호출될 때 지역 변수나 매개변수, 리턴값을 저장하는 메모리 공간

힙 세그먼트 - 프로세스가 실행 중에 동적으로 할당받는 메모리 영역

컴파일러와 링커, 로더의 도움이 필요

컴파일러와 링커 - 응용 프로그램과 라이브러리의 코드를 한 군데로 모아 코드 세그먼트를 구성시키고, 전역 변수들과 정적 변수들을 모아 데이터 세그먼트를 구성한 후 실행 파일을 생성한다.

로더 - 프로그램 실행 시 실행 파일 내에 구성되어 있는 각 논리 세그먼트에 대해 물리 메모리에서 동일한 크기로 물리 세그먼트를 할당하고, 논리 세그먼트를 물리 세그먼트에 적재한다.

운영체제는 프로세스 실행 시 필요한 크기의 스택 세그먼트와 동적 할당을 위한 힙 세그먼트를 물리 메모리에 할당한다.

논리 세그먼트와 물리 세그먼트의 매핑

세그먼트 테이블은 시스템 전체에 1개! 프로세스 당 세그먼트 개수가 작기 때문

현재 적재한 모든 프로세스들의 세그먼트들을 관리 → 논리 세그먼트 당 하나의 항목이 저장됨

항목은 논리 세그먼트가 적재된 세그먼트의 시작 물리 주소(base)와 세그먼트의 크기(limit)로 구성

프로세스가 실행되고 사라지는 과정이 반복되면서 자연스럽게 물리 세그먼트 사이에 홀 발생 → 외부 단편화 초래

새로운 프로세스 실행 시 프로세스의 각 세그먼트를 적재할 빈 홀을 찾기 위해 홀 선택 알고리즘을 사용

세그먼테이션의 구현

하드웨어 지원

- 논리 주소 구성: 프로그램에서 사용되는 논리 주소는 세그먼트 번호와 옵셋(세그먼트 내에서의 상대 주소)으로 구성

- CPU: CPU에 의해 발생되는 논리주소는 [세그먼트 번호, 옵셋] 형태. CPU에 세그먼트 테이블의 시작 주소를 가리키는 레지스터 필요

- MMU: 메모리 보호(논리 주소가 세그먼트 크기를 넘어서는지 판별)와 주소 변환(논리 주소를 물리 주소로 바꿈) 구현

CPU에서 논리 주소 발생 → 메모리에 저장된 세그먼트 테이블에서 세그먼트 번호에 해당하는 항목이 일단 읽힘 → 이 항목의 limit값과 논리 주소의 옵셋을 비교 → offset이 limit보다 크면 논리 주소가 세그먼트의 영역을 벗어난 것이므로 시스템 오류 발생 / offset이 limit보다 작으면 세그먼트 테이블의 항목에 들어 있는 물리 세그먼트 시작 주소 + 옵셋 = 물리 주소 출력

- 세그먼트 테이블: 세그먼트 테이블을 메모리에 두면 CPU가 논리 주소를 발생시켜 메모리를 액세스할 때마다 현재 세그먼트(s)의 limit과 base 값을 알아내기 위해 메모리에 있는 세그먼트 테이블 항목을 읽어와야 해서 실행 속도에 큰 부담이 됨. → 주소 변환 속도를 위해 세그먼트 테이블 일부를 MMU 내에 두기도 함

운영체제 지원

현재 할당된 물리 세그먼트들의 리스트와 홀 리스트 생성, 관리

세그먼트 테이블 생성, 유지, 관리

프로세스 생성마다 논리 세그먼트를 적재할 물리 세그먼트를 홀 리스트에서 찾아 할당하고, 프로세스가 종료할 때마다 할당된 물리 세그먼트를 반환하는 기능을 가져야 함

컴파일러, 링커, 로더 지원

사용자 프로그램을 사전에 정의된 세그먼트들로 분할하고 링킹

기계 명령에 들어가는 메모리 주소도 [세그먼트 번호, 옵셋] 형식으로 컴파일

실행 파일에 만들어진 논리 세그먼트들을 인지하고, 이들을 물리 메모리의 빈 영역을 할당받아 적재하여 세그먼트 테이블을 갱신함

단편화 문제

프로세스에 가변 크기로 물리 세그먼트들을 할당

논리 세그먼트와 동일한 크기의 물리 세그먼트를 할당 → 내부 단편화는 없음

But 세그먼트마다 크기가 서로 달라, 세그먼트들 사이에 빈 공간이 있을 때 크기가 작아 새 프로세스에 할당하지 못하는 메모리 낭비가 발생할 수 있다. → 외부 단편화 문제 → 페이징 기법 도입

2) 고정 크기 할당 - 페이징(paging)

: 프로세스에게 동일한 크기의 덩어리를 여러 개 할당하는 기법

프로세스를 논리적인 단위로 분할하지 않고, 논리 주소 0번지부터 페이지라고 부르는 고정 크기로 분할한다.

물리 메모리 역시 페이지와 동일한 크기로 분할(프레임 단위)하여, 프로세스의 각 페이지를 물리 메모리의 프레임에 하나씩 분산 할당한다.

페이징 메모리 관리

: 프로세스의 주소 공간을 0번지부터 페이지로 불리는 고정 크기로 나누고, 물리 메모리도 동일한 크기로 0번지부터 분할하여, 프로세스의 각 페이지를 물리 메모리의 임의의 페이지에 분산 할당하는 메모리 관리 기법

물리 메모리에서 페이지 크기의 메모리 블록을 프레임(=페이지 프레임, 물리 페이지)이라고 한다.

대부분 4KB로 설정된다.(8, 16KB도 존재)

- 프로세스 주소 공간을 페이지 크기로 일률적으로 나눔

- 페이지 경계를 고려하지 않고 코드, 데이터, 힙을 이어서 배치

- 페이지 테이블의 각 항목(PTE, Page Table Entry)에는 페이지 프레임 번호(물리 메모리에서 해당 페이지의 위치) 기록

- 프로세스마다 페이지와 물리 프레임을 매핑하는 페이지 테이블 존재

- MMU 장치가 페이지 테이블을 이용해 논리 주소를 물리 주소로 변환

장점

1. 구현이 쉽다. 고정 크기 페이지로 분할하여 이해도 더 쉽다.

2. 이식성이 높다. CPU에 의존적이지 않다.

3. 융통성이 높다. 시스템에 따라 페이지 크기를 변경할 수 있다.

4. 세그먼테이션에서 발생하는 외부 단편화 존재X, 홀 선택 알고리즘 실행할 필요X → 메모리 활용, 시간 오버헤드 면에서 우수

내부 단편화가 발생하기는 함! 다만 크기가 매우 작음.

세그먼테이션과 페이징 기법은 서로 장단점이 있어 현대 컴퓨터 시스템에서는 페이징을 기반으로 세그먼테이션을 혼합 사용한다.

페이지 테이블

char *p = (char*)malloc(200); 을 실행한 경우:

프로세스 힙 영역에 페이지 5를 할당하고, 비어 있는 물리 프레임 2를 할당하여 프로세스 페이지 테이블 항목 5에 프레임 번호 2를 기록한다. 그리고 페이지 5의 앞 200바이트를 할당해준다.

malloc(200) 함수는 페이지 번호 5의 논리 주소인 20480을 리턴하여 포인터 변수 p에는 20480이 저장

페이지 5의 시작 주소는 5*4KB = 20KB = 20*1024 = 20480으로 계산된 주소

프레임 2의 물리 주소는 2*4KB = 8192번지이다.

이때 *p = 'a'; 실행 시 MMU에 의해 논리 주소 20480이 물리 주소 8192로 바뀌어 물리 메모리 8192번지에 'a'가 저장된다.

프로세스에서 시스템 호출을 실행하는 경우:

커널 공간에 있는 페이지 k의 커널 코드를 실행하는 경우 현재 프로세스의 페이지 테이블에서 물리 프레임 번호를 알아내어 이에 적재된 커널 코드를 실행하게 된다.

즉 커널 코드도 논리 주소로 되어 있다!

단편화

페이징에는 외부 단편화가 발생하지 않는다. 내부 단편화가 발생하지만, 스택이나 힙 영역에 할당된 메모리는 실행 중에 계속 변하므로 단편화 계산에서 배제한다면, 프로세스 코드나 데이터가 주소 공간에 연속되어 있으므로 내부 단편화는 마지막 페이지에만 생긴다. 즉 프로세스 당 단편화로 인해 낭비되는 메모리 평균 크기는 1/2페이지, 즉 2KB로 매우 작다.

페이지 크기가 커지면 단편화도 커지며, 프로세스를 구성하는 페이지 개수는 줄어들고, 페이지 테이블 크기도 작아진다.

페이징 주소 체계

페이징의 논리 주소

논리 주소 = [페이지 번호(p), 옵셋(offset)]

페이지 크기가 4KB(=2^12)라면, 페이지 내 각 바이트 주소(옵셋 주소)를 12비트로 나타낼 수 있다. = 옵셋 크기는 12비트

32비트의 논리 주소에서 하위 12비트는 페이지 내 옵셋 주소, 상위 20비트는 페이지 번호가 된다.

논리 주소의 물리 주소 변환

p를 페이지 테이블의 인덱스로 하여 페이지 테이블 항목을 찾음 → 페이지 p가 할당된 프레임 번호 f 획득 → 프레임 번호 f에 대해 옵셋을 그대로 사용하면 물리 주소가 된다.

* 페이지 테이블은 물리 메모리에 저장된다는 것을 잊지 말 것

페이징의 구현

CPU와 MMU, 운영체제의 지원이 필요하다.

하드웨어 지원

CPU 칩 내에 현재 실행 중인 프로세스의 페이지 테이블이 적재된 물리 메모리 주소를 가진 레지스터, PTBR(Page Table Base Register)가 필요하다.

레지스터의 값은 PCB에 저장된다.

논리 주소를 물리 주소로 변환하기 위한 MMU 장치가 CPU 칩에 패키징되며, CPU에 따라 페이징 테이블 일부를 MMU 장치 내에 저장하기도 한다.

Page-table base register(PTBR): 페이지 테이블을 가리키는 포인터

Page-table length register(PTLR): 페이지 테이블의 사이즈를 표현

→ 이 두 레지스터를 MMU가 관리

PCB가 테이블 관련 레지스터를 다른 레지스터드롸 함께 보관하다가, 문맥 전환 시 테이블 레지스터 값들을 MMU로 전달

운영체제 지원

물리 메모리의 빈 프레임 리스트를 생성, 관리, 유지하여 메모리 프레임을 동적으로 할당/반환하는 기능

이에 따라 페이지 테이블을 관리하는 기능

각 프로세스마다 PCB에 주소 저장, 실행될 때마다 PTBR 레지스터에 옮기는 기능

페이지 테이블의 문제점과 TLB

1) 페이지 테이블로 인한 성능 저하

2) 공간 낭비

1) 페이지 테이블은 크기 때문에 메모리에 두게 되어 CPU가 메모리를 액세스할 때마다 물리 메모리를 2번 액세스하여 실행 속도를 심각하게 저하시킨다.

2) 페이지 테이블의 크기는 프로세스의 최대 크기(주소 공간)에 맞추어 생성되지만 실제 프로세스 크기는 그에 못 미치므로 페이지 테이블이 많이 비어 있어 메모리 낭비를 가져온다.

1) 2번의 물리 메모리 액세스 문제 해결: TLB의 사용

메모리 액세스 = 페이지 테이블 항목 읽기 1번 + 데이터 액세스 1번

→ 페이지 테이블을 읽어오는 과정을 없애면 된다.

TLB

Translation Look-aside Buffer (=주소 변환용 캐시)

CPU가 최근에 액세스한 페이지 번호가 페이지가 적재된 프레임 번호의 쌍을 저장하는 캐시 메모리

MMU 내에 둔다.

TLB의 항목 = [페이지 번호 p, 프레임 번호 f]

일반 메모리와 달리, 페이지 번호를 모든 항목과 동시에 비교하여 프레임 번호를 출력한다.

→ 주소 번지를 사용하지 않고, 내용을 직접 비교하여 찾는 메모리라 하여 '내용-주소화 기억 장치(content addressable memory, CAM)', '연관 메모리(associative memory)'라고도 부른다.

상용 CPU 내 TLB의 경우 가격이 비싸고 공간 제약 때문에 64~1024개 정도로 작은 편이다.

→ 페이지 테이블 전체를 저장할 수 없고, 최근 액세스한 소수의 페이지와 프레임 번호를 저장하여 활용성을 높인다.

TLB를 활용한 메모리 액세스

TLB를 사용하는 경우 TLB 히트가 일어나면 바로 주소 변환 발생 → 1번만 물리 메모리를 액세스해 액세스 시간을 반으로 줄임

동일한 페이지를 연속해서 액세스하는 동안 TLB 히트가 바로 발생하므로 실행 속도가 대폭 향상된다.

단, 모든 프로그램의 실행 속도가 개선되는 것은 아님!

순차 메모리 액세스 패턴을 가진 프로그램에 매우 효과적

프로그램은 참조의 지역성을 띄는데, 이 경우 효과적이지만, 랜덤하게 메모리를 액세스할 경우 TLB 미스가 자주 발생할 것이다.

* 참조의 지역성(locality of reference): 프로그램이 실행되는 동안 짧은 시간 범위 내에 일정 구간의 메모리 영역을 반복 액세스하는 경향성

TLB 성능 = TLB 히트율 = TLB 히트 횟수 비율 / CPU 메모리 액세스 횟수

TLB의 항목 수와 페이지 크기에 비례 → 항목 수를 늘린다면 비용 상승, 페이지 크기를 늘리면 내부 단편화 증가로 메모리 낭비

→ 적절한 선택이 필요

TLB 도달 범위(TLB reach): TLB 캐시의 항목 수 * 페이지 크기로 계산 (성능 지표가 된다.)

실질 메모리 접근 시간(effective memory access time, EAT): hit ratio*메인 메모리 접근 시간+(1-hit ratio)*데이터 접근 시간

메모리 보호

보호 비트를 이용해 읽기 전용 페이지에 쓰기 작업이 이뤄지지 않도록 함 → 무효 비트가 설정된 페이지에서 매핑 시도 시 트랩 발생

page-table length register(PTLR)이 페이지 범위 넘어서는 접근을 방지하는 방법도 있음 → 모든 논리 주소 값을 PTLR과 비교해 오류가 나면 트랩 발생

2) 페이지 테이블의 낭비 문제 해결: 역페이지 테이블, 멀티레벨 페이지 테이블

페이지 테이블로 메모리가 낭비되는 2가지 요인

- 페이지 테이블의 일부 항목만 사용

- 프로세스마다 페이지 테이블 존재

32비트 주소 체계를 사용하는 경우 프로세스의 주소 공간은 4GB, 페이지가 4KB면 최대 페이지 개수는 100만개이다.

페이지 테이블 항목이 4바이트이면 프로세스의 페이지 테이블 크기는 4MB이다.

그러나 실제 크기가 10MB라면 프로세스를 위해 실제 활용되는 페이지 테이블 항목 수는 2560개이다.

또한 100개의 프로세스가 실행 중이면 페이지 테이블로만 소모되는 메모리가 100*4MB=400MB이다.

역 페이지 테이블

프레임을 중심으로 물리 메모리의 전체 프레임에 대해 각 프레임이 어떤 프로세스의 어떤 페이지에 할당되었는지 나타내는 테이블

시스템에 1개

데이터베이스 권한 관리

harchiving — Tue, 10 Jun 2025 20:23:16 +0900

보안

데이터베이스 보안의 목표 → 조직에서 허가한 사용자만 데이터베이스에 접근할 수 있도록 통제하여 보안을 유지하는 것

물리적 환경에 대한 보안

자연 재해처럼 데이터베이스에 물리적 손실을 발생시키는 위험으로부터 데이터베이스 보호

권한 관리를 통한 보안

접근이 허락된 사용자만 권한 내에서 데이터베이스를 사용하도록 보호

계정이 발급된 사용자만 데이터베이스에 접근할 수 있도록 통제하고, 사용자별로 사용 범위와 수행 가능한 작업 내용을 제한

운영 관리를 통한 보안

접근이 허락된 사용자가 권한 내에서 데이터베이스를 사용하는 동안 데이터 무결성을 유지하도록 제약조건을 정의하고 위반하지 않도록 통제

권한 관리

접근 제어(access control): 계정이 발급된 사용자가 로그인에 성공했을 경우에만 데이터베이스에 접근 허용, DB 관리자가 사용자 계정을 관리

각 사용자는 허용된 권한 내에서만 DB를 사용하며, 로그인에 성공한 사용자도 DB 사용 범위와 수행 가능한 작업이 제한된다.

보안을 위한 데이터 단위는 DB 전체 ~ 특정 데이터 값까지 다양할 수 O

데이터베이스의 모든 객체는 객체를 생성한 사용자만 사용 권한을 갖는다.

데이터베이스 객체의 소유자는 필요에 따라 SQL문을 이용해 다른 사용자에게 사용 권한을 부여하거나 취소할 수 있다.

객체 권한 부여: GRANT문

객체의 소유자가 다른 사용자에게 객체에 대한 사용 권한을 부여

INSERT, DELETE, UPDATE, SELECT, REFERENCES 등

REFERENCES: 외래키 제약조건을 정의할 수 있는 권한

UPDATE나 SELECT같은 경우, 테이블 일부 속성에 대한 권한 부여도 가능

여러 권한을 한번에 부여도 가능

* 기본적으로 GRANT문으로 부여받은 권한을 다른 사용자에게 부여할 수 X

PUBLIC: 모든 사용자에게 권한을 똑같이 부여하고 싶을 때 사용자 지정 대신 PUBLIC으로 작성

WITH GRANT OPTION: 사용자가 자신이 부여받은 권한을 다른 사용자에게 부여할 수 있도록 함

시스템 권한 부여: GRANT문

데이터베이스 관리자가 부여

시스템 권한: 데이터베이스 관리와 관련된 작업에 대한 권한 ex. CREATE TABLE 등 DDL 관련 권한

객체 지정 없이 GRANT 권한 TO 사용자로 사용

객체 권한 취소: REVOKE문

객체 소유자가 다른 사용자에게 부여한 객체의 사용 권한을 취소

사용자 A가 B에게 권한을 부여하여 B가 C에게 같은 권한을 부여한 경우

CASCADE 옵션: 권한 취소할 A가 B, C 모두 연쇄적으로 권한을 함께 취소

RESTRICT 옵션: 권한을 취소할 A가 C가 부여받은 권한까지 취소하지 X

시스템 권한 취소: REVOKE문

데이터베이스 관리자가 다른 사용자에게 부여한 시스템 권한을 취소

객체 지정 X

권한 목록

권한 부여에 대한 내용을 기록한 것

역할(role)

여러 권한을 그룹으로 묶어놓은 것

여러 사용자에게 동일한 권한들을 부여하고 취소하는 작업을 편리하게 수행할 수 있도록 함 → 권한 관리가 쉬워짐

역할 생성: CREATE ROLE문

새로운 역할 생성은 DB 관리자가 담당

역할에 권한 추가: GRANT문

객체와 관련된 권한을 역할에 추가하는 작업은 객체의 소유자가 담당

역할 부여: GRANT문

역할을 사용자에게 부여하는 것은 DB 관리자가 담당

역할 취소: REVOKE문

사용자에게 부여한 역할 취소는 DB 관리자가 담당

역할 제거: DROP ROLE문

역할 제거는 DB 관리자가 담당

출처: 데이터베이스 개론 2판 김연희 저, MySQL로 배우는 데이터베이스 개론과 실습 박우창 외2

데이터베이스 회복과 병행 제어

harchiving — Tue, 10 Jun 2025 20:22:59 +0900

트랜잭션

개념

하나의 작업을 수행하는데 필요한 데이터베이스 연산들을 모아놓은 것

작업 수행에 필요한 SQL문들의 모임(특히 DB를 변경하는 INSERT, DELETE, UPDATE문 관리)

논리적인 작업의 단위

장애 발생 시 복구 작업이나 병행 제어 작업을 위한 중요한 단위로 사용된다.

데이터베이스 무결성과 일관성을 보장하기 위해 작업 수행에 필요한 연산들을 하나의 트랜잭션으로 제대로 정의, 관리해야 한다.

특성

= ACID 특성

원자성, 일관성, 격리성, 지속성

원자성(atomicity)

트랜잭션의 연산들이 모두 정상적으로 실행되거나, 하나도 실행되지 않아야 하는 all-or-nothing 방식을 의미

트랜잭션 수행 도중 장애 발생 → 지금까지 실행한 연산 처리를 모두 취소, 데이터베이스를 트랜잭션 작업 전 상태로 되돌려야 함

→ 원자성 보장을 위해 장애 발생 시 회복 기능 필요

일관성(consistency)

트랜잭션이 성공했는데 성공한 결과가 아님!

트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관된 상태를 유지해야 함을 의미

격리성(isolation)

계좌이체 트랜잭션 중간 연산 결과에 계좌입금 트랜잭션이 접근해 은경 계좌 잔액이 1,000원과 5,000원이 됨

수행 중인 트랜잭션이 완료될 때까지 다른 트랜잭션들이 중간 연산 결과에 접근할 수 없음을 의미

격리성 보장을 위해서 여러 트랜잭션이 동시에 수행되더라도 마치 순서대로 하나씩 수행되는 것처럼 정확하고 일관된 결과를 얻을 수 있도록 제어하는 기능 필요

지속성(durability)

트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 영구적이어야 함을 의미

지속성 보장을 위해 발생 시 회복 기능 필요

트랜잭션의 4가지 특성을 보장하기 위해 필요한 기능

트랜잭션의 주요 연산

commit 연산

트랜잭션이 성공적으로 수행되었음을 선언(작업 완료)

commit 연산이 실행되면 트랜잭션 수행 결과가 DB에 반영되고 일관된 상태를 지속적으로 유지하게 된다.

rollback 연산

트랜잭션을 수행하는 데 실패했음을 선언(작업 취소)

rollback 연산이 실행되면 트랜잭션이 지금까지 실행한 연산의 결과가 취소되고 DB가 트랜잭션 수행 전의 일관된 상태로 되돌아간다.

트랜잭션의 상태

활동(active) 상태

트랜잭션이 수행되기 시작하여 현재 수행 중인 상태

부분 완료(partially committed) 상태

트랜잭션의 마지막 연산이 실행을 끝낸 직후의 상태

완료(committed) 상태

트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태. 최종 결과를 DB에 반영함

실패(failed) 상태

장애가 발생하여 트랜잭션의 수행이 중단된 상태

철회(aborted) 상태

트랜잭션 수행 실패로 rollback 연산을 실행한 상태. 철회 상태로 종료된 트랜잭션은 상황에 따라 다시 수행되거나 폐기됨

장애와 회복

장애(failure)

시스템이 제대로 동작하지 않는 상태

데이터베이스를 저장하는 저장장치의 종류

트랜잭션 수행을 위해 필요한 데이터 연산

디스크 ↔ 메인 메모리 데이터 이동 연산: input/output

일반적으로 DB는 비휘발성 저장 장치인 디스크에 상주하므로, 트랜잭션이 DB의 데이터를 처리하기 위해서는 데이터를 디스크에서 메인 메모리로 가져와 처리 후, 그 결과를 디스크로 보내는 작업이 필요하다.

블록 단위로 수행됨(디스크 블록/버퍼 블록)

메인 메모리 ↔ 프로그램 변수 데이터 이동 연산: read/write

응용 프로그램에서 트랜잭션의 수행을 지시하면 메인 메모리 버퍼 블록에 있는 데이터를 프로그램의 변수로 가져오고, 데이터 처리 결과를 저장한 변수 값을 메인 메모리 버퍼 블록으로 옮기는 작업이 필요하다.

회복(recovery)

장애가 발생했을 때 데이터베이스를 장애가 발생하기 전의 일관된 상태로 복구시키는 것

트랜잭션의 특성을 보장하고, DB를 일관된 상태로 유지하기 위해 필수적인 기능

회복 관리자가 담당하여, 장애 발생을 탐지하고, 장애가 탐지되면 DB 복구 기능을 제공한다.

회복을 위해 데이터베이스 복사본 생성

데이터베이스 회복의 핵심 원리 = 데이터 중복!

회복을 위한 기본 연산

로그 파일

데이터 변경 전 값과 변경 후 값을 기록한 파일

레코드 단위로 트랜잭션 수행과 함께 기록된다.

회복 기법

1. 로그 회복 기법 - 즉시 갱신 회복 기법

트랜잭션 수행 중에 데이터 변경 연산 결과를 데이터베이스에 즉시 반영

장애 발생에 대비하기 위해 데이터 변경에 대한 내용을 로그 파일에 기록

데이터 변경 연산이 실행되면, 로그 파일에 로그 레코드를 먼저 기록한 다음 데이터베이스에 변경 연산을 반영

장애 발생 시점에 따라 redo나 undo 연산으로 데이터베이스를 복구

- 트랜잭션 완료 전 장애 발생 시 = 로그 파일에 <Ti, start>는 존재하지만 <Ti, commit>은 존재하지 않는 상태: undo 연산

- 트랜잭션 완료 후 장애 발생 시 = 로그 파일에 <Ti, start>와 <Ti, commit> 모두 존재하는 상태: redo 연산

2. 로그 회복 기법 - 지연 갱신 회복 기법

트랜잭션 수행 중에 데이터 변경 연산의 결과를 로그에만 기록해두고, 트랜잭션이 부분 완료된 후에 로그에 기록된 내용을 이용해 데이터베이스에 한번에 반영

트랜잭션 수행 중 장애가 발생할 경우, 로그에 기록된 내용을 버리기만 하면 DB가 원래 상태를 그대로 유지하게 됨

undo 연산이 필요 없고, redo 연산만 사용

- 트랜잭션 완료 전 장애 발생 시: 로그 내용을 무시하고 버림

- 트랜잭션 완료 후 장애 발생 시: redo 연산

로그 레코드에는 변경 후 값만 기록하면 됨: <Ti, X, new_value>

3. 검사 시점 회복 방법

로그 기록을 사용하되, 일정 시간 간격으로 검사 시점(checkpoint)을 만듦

검사 시점이 되면 모든 로그 레코드를 로그 파일에 기록하고, 데이터 변경 내용을 데이터베이스에 반영한 후, 검사 시점을 표시하는 <checkpoint L> 로그 레코드를 로그 파일에 기록(L은 현재 실행 중인 트랜잭션 리스트)

장애 발생 시 가장 최근 검사 시점 이후의 트랜잭션에만 회복 작업 수행; 회복 작업은 로그 회복 기법 중 하나로 사용

→ 로그 전체를 대상으로 회복 기법을 적용할 때 발생할 수 있는 비효율성 문제 해결

검사 시점으로 작업 범위가 정해지므로 불필요한 회복 작업이 없어 시간이 단축된다.

4. 미디어 회복 기법

디스크에 발생할 수 있는 장애에 대비한 회복 기법

덤프(복사본) 이용 → 전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사

디스크 장애 발생 시: 가장 최근에 복사해둔 덤프를 이용해 장애 발생 이전의 DB 상태로 복구, 필요에 따라 redo 연산 수행

병행 제어

병행 수행(concurrency): 여러 사용자가 데이터베이스를 동시 공유할 수 있도록 여러 개의 트랜잭션을 동시에 수행하는 것

여러 트랜잭션이 차례로 번갈아 수행되는 인터리빙(interleaving) 방식으로 진행

병행 제어(concurrency control) = 동시성 제어: 병행 수행 시 같은 데이터에 접근해 연산을 수행해도 문제가 발생하지 않고, 정확한 수행 결과를 얻을 수 있도록 트랜잭션 수행을 제어하는 것

병행 수행 시 발생할 수 있는 문제점

갱신 분실(lost update)

하나의 트랜잭션이 수행한 데이터 변경 연산 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것

여러 트랜잭션이 동시에 수행되더라도 갱신 분실 문제가 발생하지 않고, 마치 트랜잭션들을 순차 수행한 것과 같은 결과 값을 얻을 수 있어야 한다.

모순성(inconsistency)

하나의 트랜잭션이 여러 개 데이터 변경 연산을 실행할 때 일관성 없는 상태의 데이터베이스에서 데이터를 가져와 연산함으로써 모순된 결과가 발생하는 것

연쇄 복귀(cascading rollback)

트랜잭션이 완료되기 전 장애가 발생하여 rollback 연산을 수행하면, 장애 발생 전에 이 트랜잭션이 변경한 데이터를 가져가, 변경 연산을 실행한 다른 트랜잭션에도 rollback 연산을 연쇄적으로 실행해야 한다는 것

트랜잭션 스케줄

트랜잭션에 포함되어 있는 연산들을 수행하는 순서

1. 직렬 스케줄(serial schedule)

인터리빙 방식을 이용하지 않고, 각 트랜잭션별로 연산들을 순차적으로 실행시키는 것

다른 트랜잭션의 방해를 받지 않고 독립적으로 수행되어 항상 모순 없는 정확한 결과를 얻게 된다.

다양한 직렬 스케줄이 만들어질 수 있고, 결과는 모두 정확하다.

But 병행 수행으로 볼 수 없음!

2. 비직렬 스케줄(nonserial schedule)

인터리빙 방식을 이용하여 트랜잭션을 병행 수행하는 것

트랜잭션이 번갈아 연산 실행 → 한 트랜잭션이 완료되기 전에 다른 트랜잭션의 연산 실행 가능

갱신 분실, 모순성, 연쇄 복귀 등의 문제가 발생할 수 있어 결과의 정확성 보장 불가

다양한 비직렬 스케줄이 만들어질 수 있고, 그중 잘못된 결과를 생성하는 것도 존재한다.

한 트랜잭션의 read와 write 사이에 다른 트랜잭션에서 관련된 변수의 연산 수행 시 문제 발생

3. 직렬 가능 스케줄

직렬 스케줄에 따라 수행한 것과 같이 정확한 결과를 생성하는 비직렬 스케줄

비직렬 스케줄 중에서 수행 결과가 동일한 직렬 스케줄이 있는 것

인터리빙 방식으로 병행 수행하면서도 정확한 결과를 얻을 수 있음

직렬 가능 스케줄인지 판단하는 것의 어려움 → 직렬 가능성을 보장하는 병행 제어 기법을 사용하는 것이 일반적

병행 제어 기법

병행 수행하면서도 직렬 가능성을 보장하기 위한 기법

모든 트랜잭션이 준수하면 직렬 가능성이 보장되는 규약을 정의하고, 트랜잭션들이 이 규약을 따르도록 한다.

로킹(locking) 기법

기본 원리: 한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 끝낼 때까지는 다른 트랜잭션이 그 데이터에 접근하지 못하도록 상호 배제(mutual exclusion)한다.

방법: 병행 수행되는 트랜잭션들이 같은 데이터에 동시에 접근하지 못하도록 lock과 unlock 연산을 이용해 제어

- lock: 트랜잭션이 데이터에 대한 독점권을 요청하는 연산

- unlock: 트랜잭션이 데이터에 대한 독점권을 반환하는 연산

기본 로킹 규약:

트랜잭션이 데이터에 접근하기 위해 먼저 read나 write 실행 전 lock 연산으로 독점권 획득

다른 트랜잭션에 의해 lock 연산이 실행된 데이터에는 lock 연산 실행 불가

독점권을 획득한 데이터에 대한 모든 연산 수행이 끝난 뒤 unlock 연산을 실행해 독점권을 반납

로킹 단위:

lock 연산을 실행하는 대상 데이터의 크기

전체 DB부터 릴레이션, 투플, 속성까지도 가능

로킹 단위가 커질수록 병행성은 낮아지지만 제어가 쉽고, 단위가 작아질수록 제어는 어렵지만 병행성은 높아진다.

T1의 COMMIT된 결과에 대해 T2가 연산 수행

기본 로킹 규약의 효율성을 높이기 위한 방법

트랜잭션들이 같은 데이터에 동시에 read 연산을 실행하는 것을 허용

서로 다른 트랜잭션이 같은 데이터에 공용 lock 연산만 동시에 실행 가능

전용 lock을 실행한 데이터에는 모두 실행 불가

기본 로킹 규약으로 직렬 가능성이 보장되지 않는 스케줄 예

트랜잭션 T1이 너무 빨리 unlock 연산을 실행하여 트랜잭션 T2가 일관성 없는 데이터에 접근하게 됨

T1의 데이터 Y에 대한 연산이 끝나기 전에 T2에서 Y에 대한 연산을 수행해 Y의 데이터 값이 일관성을 잃게 됨

2단계 로킹 규약(2PLP; 2 Phase Locking Protocol)

기본 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해 lock과 unlock 연산의 수행 시점에 대한 새로운 규약을 추가한 것

방법:

트랜잭션이 lock과 unlock 연산을 확장 단계와 축소 단계로 나누어 실행

트랜잭션 처음 실행 시 확장 단계로 들어가 lock 연산만 실행 가능

unlock 연산을 실행하면 축소 단계로 들어가 unlock 연산만 실행 가능

트랜잭션은 첫번째 unlock 연산 실행 전에 필요한 모든 lock 연산을 실행해야 함

트랜잭션 시작 → 확장 단계 → lock 연산(1) → lock 연산(2) → unlock 연산(2) → 축소 단계 → unlock 연산(1) → 완료

즉, 한 트랙잭션 안에서 lock-unlock 과정이 교차되지 않고 중첩되어 발생하도록 제한함

교착 상태(deadlock)

트랜잭션들이 상대가 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리면서 트랜잭션 수행을 중단하고 있는 상태

→ 발생하지 않도록 예방하거나, 빨리 탐지해 조치해야 함

Time 8: T1이 X를 읽고자 하지만 T2의 read_lock(X)로 읽지 못하고 중단됨

출처: 데이터베이스 개론 2판 김연희 저, MySQL로 배우는 데이터베이스 개론과 실습 박우창 외2