[크래프톤정글 12~13주차 회고] 가상 메모리

드디어 끝이 안보이던 핀토스 과제가 마무리 되었다.
Pintos Project 1 ~ 2는 3주간 진행되었고, Project 3부터는 또 다른 팀으로 바뀌었다.
이전에 같이 해봤었던 팀원분들과 함께 팀이 되었다.
바로 재홍님과 윤호님이다. 마지막 힘들었던 주차를 함께 팀이 될 수 있어서 내심 좋았다.
(또한 재홍님과 윤호님의 티키타카가 넘 재밌어서 우리 팀의 케미가 좋았다)

선배 기수분들께서 핀토스 주차가 본인의 한계를 마주치며, 많이 성장해나갈 수 있었다고 들었는데,
과제를 진행하면서 정말 많이 느꼈었다. 뭘 해야할지 모르겠는 막막함과 분명 오류가 나는 것 같은데
어디서 나는지 모르겠어서 방황을 많이 했었다. 하지만 팀원분들과 여기저기 조언을 얻다보니 해결이 되고
점차 하나하나씩 과제를 진행해 나갈 수 있었다는 것만으로 뿌듯했다.

나 자신에게 수고 많았다고 해주고 싶고, 남은 나만무 프로젝트에서도 많이 성장하고싶다.

---

git branch 전략

처음 과제를 시작하기도 전에 의견 충돌이 일어났었는데, 바로 git branch 전략을 어떻게 가져갈 것이냐.였다.

1. 3주동안 각자의 팀에서 작업한 작업물을 어떻게 합칠 것인가?
   1-1. 테스트 코드가 많이 통과가 되는 코드로 진행
2. 어떻게 branch 전략을 가져갈 것인가?
   2-1. 과제 부분별로 branch를 나눠 작업
   2-2. 어차피 merge시키고 다시 본인꺼에서 작업할거니까 하나의 branch로 작업

이전 팀에서는 2-1 방식으로 진행했었다.
각자의 branch에서 작업하다가 합치게 되면 더 나은 코드의 branch로 merge를 하기로 하였고,
merge한 다음 다시 main에서 pull 받아와서 또 새로운 branch에서 작업하는 방식으로 진행했었다.
또한 이 방식이 안전하다고 생각했다.

하지만, 재홍님께서는 각자의 branch에서 작업을 하다가 merge를 각자의 branch에서 다 하기 때문에
branch를 안 나눠도 되지 않을까? 하고 의견을 내주셨다.
이때, 재홍님께서 내가 왜 저 방식이 더 안전한지 궁금하다고 여쭤봤는데 제대로 설명하지 못했다.

다시 곰곰히 생각해보았는데, 2-1방식은 과제 파트별로 branch로 나누어 작업하니까 만들어진 branch로 작업을 분리할 수 있다는 장점이 있는 반면, 그 기준이 애매하다는 단점이 있었다. 하지만 2-2방식은 각자 같은 과제 파트를 진행하다가 merge를 함께 시키고 서로 충돌나는 부분을 해결하고 다시 새로 main에서 pull을 받아와서 작업을 진행하여, 서로 코드의 진행률을 맞출 수 있다는 장점이 있다. 또한 서로의 코드를 더 들여다볼 수 있는 시간이 길어졌고 각자 자신이 짠 코드를 설명하여 테스트 코드 통과뿐만 아니라 더 나은 코드로 merge를 시킬 수 있다.

그래서 2-2 방식으로 git branch 전략을 가져가기로 하였다.

이 git branch 전략을 따르면서 느꼈던 점

• 서로의 작업물을 merge시키면서 충돌 나는 부분을 함께 해결해나가는 경험을 할 수 있었음
• 서로의 코드를 더 많이 들여다보게 됨
  • 누군가의 코드를 merge 시켜야 하는 이유를 팀원들 모두가 설득됐어야 하기 때문에
• 이슈로 작업을 분리하였기에 하나의 branch에서 해도 보기 힘들지 않았음

merge 과정 - 재홍님이 정리해주신 부분

pull request > merge to main

git checkout main >> 로컬 main 브랜치로 변경하고

git pull origin main >> 원격 저장소 main을 받아오고

git checkout "개인 로컬 브랜치명" >> 로컬 개인 브랜치로 변경

git rebase main >> 로컬 main 위치로(파일 정보를 받아옴) 재조정

----- 이때 코드 합치거나, 수정하거나 정리함-----

이후에, 수정된 내용 add (staging) 해주고

git rebase --continue >> rebase를 재개해주면서, 이때 나오는 커밋메세지를 부분 수정


<< 이 때 그냥 push하면 branch 정보 불일치로 인해 non-fast-forwards 오류로 인해 push 되지않음>>

git push origin "개인 원격 브랜치명" --force-with-lease >> 원격 개인 브랜치 저장소에 push 함

---

계속 통과안되던 테스트를 고치기 위한 여정

이틀 정도 계속 통과가 안되는 테스트를 통과시키기 위해 디버깅을 진행했었고,
“이쪽에선 잘 출력되고있고, 왜 이쪽에선 출력되지 않는걸까?” 하며
내가 짰었던 코드들을 다시 수정하고, 또 돌려보고 무한반복이었다.

하지만 건드리면 건드릴수록 Fail이 증가하는거였다.
그럼 다시 돌아가고. 또 반복하고.
그러다보니 이젠 어디가 잘못된건지 감이 잡히지 않는 상태가 왔던것같다.

그래서 이전에 같은 팀에서 많은 도움을 받았던 똑똑한 권호님께
이렇게 디버깅을 진행했고, 이런 문제가 있는거 같은데 함께 봐달라고 했다.
그렇게 권호님과 함께 디버깅을 시작했고, 결국 문제를 찾아냈다.

아직 해당 페이지가 접근되지 않아서, lazy_load_segment() 실행 시 정보가 필요하다.
하지만 부모가 read를 진행하고 그 정보를 없애버려서 다음에 진행할 fork된 자식이 진행이 불가했던 것이다.
(자세한 설명은 이곳에 정리해두었다. ➔ fork‐read.c 테스트 오류)

이때 느꼈던게 디버깅을 잘하는 것도 실력이구나.를 뼈저리게 느꼈다.
권호님과 함께 디버깅을 하니까 안보이던 부분도 보였기 때문이다.
해결한 후 테스트가 10개가 더 통과가 되어서 너무 뿌듯했다.

---

내가 공부하는 방식을 깨달아버렸다.

Pintos 과제를 진행하면서 더욱 내가 어떻게 공부해나가는지 파악해버렸다.

Todo List처럼 내가 해야할 작업들을 먼저 크게 틀을 잡아놓은 다음에
어떤 것들을 해나가야할지 세세하게 정리해두어 하나씩 해결해나갔다.
또한 과제를 진행하면서 기록하며 하는 습관이 있다는 것을 깨달았다.

나는 공부를 할 때, 계획적으로 해나간다고 생각하지 못했는데,
무언가 작업을 하거나 구현을 해나가야할때, 내가 무엇을 해야할지가 명확하지 않으면
잘 진행하지 못한다는 것을 깨달았고, 내가 해야할 것들을 정리해두어야 그것들을 하나씩 게임 퀘스트 깨나가듯이
방황하지 않고 해나갈 수 있다는 것을 알게 되었다.

잘 몰랐는데 우리 반 분들께서 정리도 잘하고, 계획적이다는 말을 해주시다보니
공부나 작업하는데에 있어선 계획적이고 정리하는 습관이 있다는걸 깨닫게 되었다.

---

운영진 티타임 - “DevOps”

이번주 운영진 티타임엔 동석 코치님께서 DevOps에 대해 소개해주셨다.
이야기를 듣고 가장 먼저 든 생각은, 개발자는 프론트엔드나 백엔드에만 국한되지 않고 훨씬 다양한 역할을 수행할 수 있다는 점이었다. 나는 정말 우물 안 개구리였던 것이다.

DevOps가 생겨난 배경은, 개발을 완료한 뒤 실제 서비스로 릴리즈하고 배포하기까지의 과정이 너무 오래 걸려,
시장에서 빠르게 반응하지 못하는 문제가 있었기 때문이다.

이러한 문제를 해결하기 위해 개발과 운영의 경계를 허물고,
코드 작성부터 배포, 운영, 모니터링까지의 전체 과정을 자동화하고 효율화하려는 흐름이 생겨났다.
DevOps는 이 과정에서 배포 자동화, 모니터링 시스템 구축, 장애 대응 및 롤백 시스템 구성 등을 맡는다.
그 결과 몇 달이 걸리던 배포 주기를 며칠, 심지어 하루 단위로 줄일 수 있게 되었고, 장애 대응 속도도 빨라졌다.

또한 개발팀, 운영팀, 보안팀 간의 협업이 활발해지면서, 커뮤니케이션 역량도 매우 중요하다고 하셨다.

이 역할을 수행하기 위해선 서버, 운영체제, 네트워크와 같은 인프라 지식이 꼭 필요하며,
시스템 전반에 대한 깊은 이해를 바탕으로 안정적인 서비스를 유지하는 것이 핵심이라고 느꼈다.