What I did?
이번 주차에는 user program 과제를 해결하는데 집중했다. 이전까지는 커널 영역에서 곧바로 테스트를 돌렸다. 즉, 운영체제 단에서 작업이 잘 이뤄지고 있는지를 테스트한 것. 하지만 운영체제가 존재하는 이유는 사용자 프로그램을 보다 쉽게 돌리기 위함이다. 사용자 프로세스에서 write() 기능을 구현하기 위해 직접 입출력 장치까지 가지 않고도 시스템 콜을 이용해 운영체제가 알아서 작업할 수 있도록 일을 시키는 것을 구현하는 게 이번 주차 목표였다.
이를 위해서 했던 과제는 크게 두 가지. 첫번째는 argument passing. 명령어는 여러 가지 뜻을 담은 인자들의 집합으로 전달된다. 하지만 컴퓨터 입장에서는 그저 숫자들의 나열일 뿐이다. 따라서 컴퓨터가 이를 분리해서 각각의 명령어를 인식할 수 있도록 커맨드 라인 문자열을 토큰으로 분리하도록 기능을 구현한다.
명령어 분리 작업이 끝났으면 무엇을 실행해야 하는지를 인식하고 그에 맞는 인자를 명령어로부터 받아 메모리에 올리는 작업을 수행해야 한다. 이를 위해 process_exec() 코드를 수정했다. process_exec()은 위에서 말한 명령어 parsing 뿐만 아니라 명령어로부터 입력 받은 해당 프로그램을 디스크로부터 가져와서 메모리에 올리는 기능을 수행한다. process_exec()에서 호출하는 load()를 통해 유저 스택에 프로그램 실행 관련 인자를 쌓고나면 사용자 프로그램을 실행할 준비를 마치게 된다. 해당 과제는 마무리된다.
두 번째 과제는 system call. 위 과정은 입력받은 프로그램을 실행하기 위해 컴퓨터가 부팅되고 나서 사용자 프로그램이 실행되기 전까지의 과정을 나타낸 것이다. 프로그램 실행 관련 인자를 스택에 쌓고 나면 사용자 프로그램 main()이 실행되는데, 이 사용자 프로그램은 다양한 요청을 운영체제에 전달한다. 예컨대 입출력 장치에 뭔가를 쓰고 싶다던지(write), 자식 프로세스를 생성하고 싶다던지(fork) 등등. 현재는 운영체제 내 시스템 콜 코드가 하나도 작성되어 있지 않다. 이를 하나씩 구현해나가는 것이 두 번째 과제였다.
회고
체력이 매우 많이 떨어진 주차였다. 한 주에 주어진 시간이 길면 좋을 것이라 생각했는데 오히려 기니까(특히 2주차는 1.5주나 되어버리니..) 텐션이 떨어지는 감이 없잖아 있는듯..빠르게 휙휙 돌아가는 게 더 좋더라.
어느덧 절반이 끝났다. 남은 건 2개월 남짓. 이제 중간까지 왔다. 기분이 어떻냐..글쎄. 사실 요즘 별 생각이 없다. 주어진 과정을 묵묵히 해내는 한편 곧 있을 취준을 대비해 어떤 마인드셋을 가져야 하는지 수시로 점검하는 것 외에는 그다지 신경을 쓰지 않는듯.
다만 한 가지 있다면, 취준과 별개로 뛰어난 개발자로 성장하는 데 있어 어떤 펀더멘털이 필요할지에 대해 고민이 많다. 스스로 봤을 때, 객관적으로 뛰어난 개발 센스가 있다고 보기 힘든 편이다. 겸손이나 좌절 뭐 그런게 아니다. 어떤 면에서 남들보다 확연히 잘하는 게 있다는 것도 안다. 리얼 메타인지 측면에서 개발만 놓고 보면 그렇다. 하지만 상위 10%의 실력을 갖춘 개발자로 성장하는 건 앞으로 목표를 향해 가는 과정에서 반드시 필요하다. 그리고 여기까지는 누구든 올바른 방법으로 노력한다면 도달할 수 있는 영역이라는 믿음이 있다. 그런데 여기서 포인트는 노력이 아니라 올바른 방법이다. 노력은 디폴트다. 더 빠르게 이 지점에 도달하기 위해서는 그냥 많이 하는 것만으로는 부족하다. 이미 전철을 밟은 수많은 선배들의 조언을 바탕으로 삽질도 현명하게 할 필요가 있다. 그런 측면에서 아래 질문이 더없이 중요하다.
되새겨볼 질문들: 코딩이란 무엇인가? 코딩을 잘한다는 것은 무엇인가?
코딩을 잘한다는 것은 무엇일까? 아니, 그 전에 코딩이란 무엇일까? 오늘 티타임 시간에 질문을 던졌다. 코치님 대답은 이랬다.
자기에게 주어진 조건을 이해하고 이를 컴퓨터가 해결하도록 시키는 과정
크게 나눠보면 두 가지였다.
1. 주어진 조건을 "이해"하고
2. 이를 "컴퓨터가 해결"하도록 "시킨다".
이제까지 핀토스 과제를 수행하면서 코드를 따라가며 이 코드가 어떤 의미이고, 함수 사이에 어떤 연관성을 지녔으며 그것들이 어떤 추상의 맥락에서 그려졌는지를 이해하는 건 1번에 해당한다. 나아가 이를 바탕으로 코드를 구현해 컴퓨터를 동작시켜 문제를 해결하는 것은 2번에 해당한다. 즉, 공부 자체도 코딩의 일환이라는 말씀. 하지만 백프로 정답이 아니다. 결국 코드로 구현해내지 못하면 말짱 쓸모 없기 때문. 따라서 코드 구현을 의미없다고 치부했던 것도 틀렸다고 봐야 한다.
코딩을 나무위키에서는 이렇게 풀어서 설명하더라.
하나 이상의 관련된 추상 알고리즘을 특정한 프로그래밍 언어를 이용해 구체적인 컴퓨터 프로그램으로 구현하는 기술을 말한다. - 나무위키
이 말을 하나씩 뜯어보자. 각각 나무위키에서 긁어왔다. 신뢰도가 낮을 수 있으나 내용이 좋아 긁어왔다.
추상
추상화란, 컴퓨터공학에서 추상화는 어떤 종류의 대상들에 대해 그것이 가져야 할 핵심적인 특징들을 가지는 모델을 만드는 것이다. 예컨대, '메모리 공간'이라는 모델은 '어떤 시점에 값을 가지며, 그곳에 다른 값을 기록하지 않는 한 다음에도 계속 그 값을 유지한다.'는 핵심적인 특징을 가지고 있다.
컴퓨터공학에서 추상화된 모델을 세운다는 것은 어떤 이점이 있는가? 우선 추상화 계층(abstraction layer)의 1) 아래쪽-구현 측면부터 살펴보면, 모델은 그에 해당하는 것을 구현할 때 그것이 어떤 특징들을 가지도록 만들어야 하는지에 대한 명세(specification)가 된다. 무엇을 이용하건 메모리 공간은 '어떤 시점에 값을 가지며, 그곳에 다른 값을 기록하지 않는 한 다음에도 계속 그 값을 유지하'도록 만들면 된다.
다음으로, 추상화 계층의 2) 위쪽-활용 측면에서 살펴보면, 우리는 이 모델에 해당하는 것의 특징들이 어떠한지 알고 있으므로, 모델은 대상이 내부에서 어떻게 동작하는지의 세부사항을 모르더라도 다른 것을 만들 때 활용할 수 있게끔 하는 인터페이스(interface)의 역할을 한다. 우리가 메모리 공간을 가지고 간단한 프로그램을 만들 때, 그 메모리 공간이 플립플롭으로 만들어진 레지스터에 있는지 축전기로 만들어진 DRAM에 있는지에 상관없이 우리는 그 메모리 공간이 '어떤 시점에 값을 가지며, 그곳에 다른 값을 기록하지 않는 한 다음에도 계속 그 값을 유지하'는 특징을 가진다는 것을 알고 있으므로 이를 활용하여 프로그램을 만들 수 있다. 심지어 그것이 일반적으로 생각하는 메인 메모리가 아니라 디스크 같은 곳에 있거나 아예 네트워크상의 어딘가에 있더라도 신경쓸 필요가 없다.
우리는 앞에서 설명한 추상화의 두 가지 측면을 이용하여 복잡한 구조의 어떤 부분을 만들 때 만약 그 부분이 가져야 할 특성들을 명세한 모델을 세워 놓았다면 그 세부사항의 구현과 그 부분을 활용하는 구현을 분리해 구현할 수 있다.
알고리즘
알고리즘: 알고리즘이라는 용어는 문제를 해결하기 위한 절차나 방법을 의미하는 단어로 넓은 범위에서 사용된다. 조금 더 정확한 의미를 따져보자면 알고리즘은 어떠한 행동을 하기 위해서 만들어진 명령어들의 유한 집합(finite set)이다.
프로그래밍 언어
기계(컴퓨터)에게 명령이나 연산을 시킬 목적으로 설계되어 기계와 의사소통을 할 수 있게 해주는 언어를 뜻한다. 그 결과, 사람이 원하는 작업을 컴퓨터가 수행할 수 있도록 프로그래밍 언어로 일련의 과정을 작성하여 일을 시킨다. 쉽게 말하면 컴퓨터를 이용하기 위한 언어이다. 소프트웨어를 만드는데 기본이 되고, 이 소프트웨어는 논리 연산의 집합이기 때문에 수리 언어의 일종으로 보는 시각도 있다.
코딩을 단순히 언어를 익히고 기술을 다루는 측면이라고만 해석하면 완전히 틀린 생각이다. 문제를 해결하는(정확히는 컴퓨터가 문제를 해결하도록 시키는) 과정의 일환이자 방법론이 코딩인 것. 아래 조은 님의 말을 참조하며 글을 마무리한다.
단순히 언어를 익히고 기술을 다루는 것은 사실 실무에서는 크게 중요하지 않습니다. 오히려 '문제가 무엇이며, 왜 이 문제를 해결하려고 하는가? 이 문제는 어떻게 해결할 수 있는가?'에 집중하는 사람을 개발자로서 더 높게 평가합니다. 특히 개발에는 완전히 정해진 정답이라는 게 없기 때문에 더욱 이 능력은 중요한데, 이는 '문제 해결능력'으로 귀결됩니다. -조은