시작하는 말
전역 후 과거를 톺아보며 블로그를 시작해야겠다 마음먹었다. 순간순간의 흔적들이, 나의 고민이, 그리고 서투른 결론들이, 훗날에 가지는 가치를 깨달았기 때문이다. 그렇기에 나의 블로그는 어떠한 정보 전달을 목적으로 하지 않는다. 대신에 내가 겪었던, 그리고 느꼈던, 고민했던 질문의 집합소다.
달에 1개의 게시글을 목표로 블로그를 시작했는데, 그래도 약 1년 반 동안은 목표를 이뤘다. 하지만 올해 여름방학이 시작되고 이런저런 일이 겹치며, 작성해 놓았던 초고조차 게시하지 못했다. 그나마 최근, 초고 하나를 성공적으로 출하(?)했지만, 여전히 나의 임시저장 목록에는 3개가 남아있었다.
난 미루기 장인이기에, 일정 기한 이상 밀려버린 일들은 평생 하지 못한다는 사실을 잘 알고 있다. 그래서 오늘 이 자리에서, 미뤄왔던 나의 흔적을 한 번에 정리하고자 한다. 단순히 밀린 일을 처리하는 것을 넘어서서, 초고를 작성한 이후로 변화한 나의 생각과 깨달음을 함께 반영할 것이기에 충분히 의미 있으리라 기대한다.
대화의 기본
"Definition을 명확히 해야 해!"
여름의 어느 날, 대학 축제에서 술을 마시다 개발 얘기가 화두에 올랐다. Integrity Checker에 대한 얘기였는데, 잘 모르지만 적당히 말을 얹어볼 만하도록 이야기가 전개됐다. 그중에서도 기억에 남는 대화는 Stop The World에 대한 의문에서 시작되었다.
Integirty Checker는 여러 Module 간 정합성 검증을 위해 DB의 Snapshot을 필요로 하는데, 이 과정에서 Stop The World가 불가피하다. 이 말을 듣던 나는, 각 모듈의 Instance(WAS) 또한 DB로 처리 중인 내용을 "Flush"해야 하며, 이는 더욱 큰 Overhead를 유발한다는 결론에 다다랐다. 하지만, 이 질문을 던졌을 때, 이야기는 빙빙 돌기 시작했고, 대화는 답답한 수렁에 빠져들었다.
결과적으로 내 의문은 타당했으며, Integrity Checker를 대규모 시스템에 적용하기 어렵게 만드는 원인 중 하나였다. 어찌 되었든 소통이 잘 이뤄지지 않았던 데에는 "Flush"라는 용어가 있었다. 화자분은 "Write Back"과 "Flush"를 구분했지만, 난 둘을 구분하지 않았다. 정확히는 "Flush"를 "Write Back"의 의미로 사용했다. 대화를 나누는 두 사람 사이에 용어가 정의되지 않았던 것이다!
나는 대화에 소질이 없을지도...
늘 대화에 어려움을 겪어 왔다. 나와의 대화에서 피로를 호소하는 사람이 많았다. 문제를 인식했고 개선하길 원했기에, 원인 분석을 쉬지 않았다. 그렇게 그전까지 내가 특정했던 원인은 아래와 같다.
- 말이 빠르고, 발음이 부정확하다.
- 대화를 미괄식으로 전개한다. (생각을 정리하지 않고 일단 뱉는다)
- 청자가 듣고 싶은 말보다는, 내가 하고 싶은 말을 쏟아붇는데 집중한다.
위 사항을 개선하기 위해 늘 의식하고 신경 쓴다. 실제로 효과가 있다고 생각하고, (여전히 많이 부족하지만) 주변으로부터 많이 나아졌다는 인정도 받았다.
그런데, 위 축젯날을 계기로 하나의 항목이 추가되었다. "서로 간에 합의된 용어를 통해 대화를 시도하고 있는가? 그저 내 생각을 표현하기 위한 용어를 즉석에서 창조하고, 상대가 알아주길 바라지는 않는가? 잘 모르는 내용을 이야기할 때, 정의를 명확히 하였는가?"
되돌아보면, 난 '용어'를 멸시했다
어렸을 적부터, 암기를 굉장히 싫어했다. 종이가, 디스크가 할 수 있는 일을 사람이 하는 것을 낭비라고 생각했고, 용어를 외우지 않더라도, 개념을 이해하고 활용을 잘하면 충분하리라 믿었다.
가령, 어떤 Collection이 있는지만 알면, cppreference를 통해 찾아내는건 어렵지 않잖은가? 이러한 태도는 안 좋은 방향으로 발전해 여러모로 골치 아픈 결과를 낳았고,,, 발생했던 문제는 이번 일 하나만이 아니다.
DB 과목을 수강하고 시험을 쳤다. 점수를 확인했는데, 내 예상보다 성적이 너무 낮았다. 실수를 고려하더라도, 정도 이상으로 낮은 성적이었다. 그렇게 나는 인생 처음으로 시험지를 확인하러 교수님을 찾아뵀다.
그렇게 확인한 시험지에는, 한 챕터가 통으로 날아가 있었다. 이유는 단순했는데, 용어를 착각해서 전혀 다른 내용을 서술했기 때문이다. 그래도 다행히(?) 틀린 내용을 작성하지는 않았더라. 사실, 이런 상황은 흔했고, "난 잘 알고 있었는데, 용어를 착각했을 뿐이야! 모르지 않았다고!"라고 생각하며 대수롭지 않게 넘겨왔다. 하지만 위 사례를 경험한 뒤 정말 그럴까 회의적이다.
당시 당황하던 내게 교수님께서 말씀하시길, 평소에도 내게 용어를 짚어주고 싶으셨다고 한다. 강의 내용에 대한 질문을 받을 때, 내가 OS 용어와 DB 용어를 혼용해서 사용하곤 했다고 하셨다. 가령, Meta Data Block을 Superblock이라 표현했으며, Extendable Hashing을 얘기하며 Directory 대신 In-directed란 용어를 사용했다. 의미상 무슨 말을 하고 싶은지는 알아챌 수 있었지만, 이런 용어를 사용하는 학생은 너무나 생소하셨다고...
대화란 사회적 합의에 기반하고, 앎이란 설명할 수 있어야 완성된다. 그렇다면, 얘기하고자 하는 내용을 어떠한 용어로 표현하는지가 굉장히 중요하지 않았을까?
덧붙여서, 질문을 향한 작은 고찰
내가 모르는걸 "잘 알 사람"에게 묻는 것만이 질문일까?
내가 모르는걸 "모르는 사람"에게 함께 고민하자 얘기하는 건 질문이 아닐까?
내가 아는 내용, 그리고 추론한 내용을, 당신이 아는 내용, 추론한 내용과 비교하며 사고를 전개해 나간다면, 그 끝에 도달한 건 질문의 답이 될 수 없는 걸까?
어느새 "잘 알고 있는 것처럼 보이기 위해서" 질문을 꺼리고 있지는 않았을까?
대화하다가 모르는 내용이 나오면, 질문하는 용기는 언젠가부터 잃어버렸을까?
어느새 대화 자체보다도, 대화하는 척에 집중하게 된 건 아닐까?
대화 속 모르는 용어를 무시하게 된 건 언제부터였을까?
Bottom-up으로 사고하기
나는 Top-down으로 사고하는데 익숙하다. 정신을 차리고 보니 언젠가부터 그러했다. 늘 스스로 불안하다 여겼던건, 아마 결론의 근거가, 그 기반이 불안하다는 사실을 잘 알고 있었기 때문이 아니었을까. Top-down도 나쁘진 않지만, 기반이 없다면 소설을 쓰는 것과 다를 바 없다.
더 알 수 없을거라 생각했다
주변을 보면 멋진 사람이 정말 많다. 떄로는 "와~!" 하는 감탄밖에 나오지 않는 분도 있다. 어느 날 문득 그런 생각이 들었다. "잘하는 사람"과 "엄청난 사람"을 나누는게 무엇인가? 두 유형 모두 멋진 사람이다. 하지만 나의 태도에서는 후자를 명확히 더 대단하게 보는게 느껴진다.
단순히 잘하면, 잘하는 사람으로 느낀다. 하지만, 그 분야에 뛰어든 지 얼마 되지 않은 사람이 잘하면, 엄청나다 느낀다. 특히 어린 나이에 높은 성취를 보이는 분들이 그러하다.
나보다 나이가 많은 사람이, 나의 선배가, 뛰어난 모습을 보여주면, "나도 저쯤 되면 저 정도로 잘 하지 않을까?"하는 안일한 생각을 했던 것 같다. 그들이 그곳에 도달하기 위해 했던 수많은 노력을 폄하했던건 아니었을까?
그러다가, 나와 비슷한 나이의, 어쩌면 더 어린 분이, 내가 고개를 꺾어 까마득히 올려다봐야 할 정도로 뛰어난 성취를 보이면, 그때는 더 이상 "언젠간 나도..."하는 변명을 할 수 없다. 그렇기에 엄청나다고 느꼈던게 아닐까.
무의식적으로, 내가 할 수 있는 일에 한계를 짓고, 그 잣대를 다른 사람에게 씌워보았던게 아닐까? "내 나이에는, 내 학년에는, 내 환경에서는..." 하지만 나와 달리, 내가 만들었던 한계를 넘어선 사람들이 존재했고, 그렇기에 더욱 특별하게 느꼈던 걸지도 모르겠다.
Bottom-up을 위한 재료 모으기가 힘드니까
돌이켜보면, 파고 내려가다 보면 언제나 멈춰야 하는 순간이 왔다. 안타까운 점은, 어렸을 적 나의 호기심이 원하던 부분은, 도달하기 어려운 영역에 있었으며, 그렇기에 늘 "내가 다 알 순 없는 거야"라는 체념으로 마무리했다는 것이다.
하지만 정말 불가능했을까? 누군간 이뤄내지 않았는가? 그런데 또 이런 생각을 하면 우울해진다. 사람마다 할 수 있는 일의, 끈기의 상한이 다르니까. 더 이상 내가 이루지 못한 일에 집중하고 싶지는 않다. 대신에, "이제는 할 수 있다"는, "나도 준비되었다"는 상쾌한 주장을 하고자 한다.
무작정 위키백과 뒤져보기
학교에서 배운 내용들, 분명 교수님께 배웠지만 개중 내가 "안다"고 할 수 있는게 얼마나 될까? 결국 그럴듯한 수준으로 이해할 뿐이다. 예로 들어 보자면 CFS(Completely Fair Scheduler)와 같은 것들이 있겠다.
최근 어쩌다 보니 조금 "제대로" 알아봐야 할 일이 생겼다. 그래서 어떻게 해야 할까 고민하다가 그냥 위키백과에 접속했다. 달려있는 링크 하나하나를 눌러다보며, O(1) Scheduler 문서를 읽어보기도 하고, Red-black Tree를 다시 찾아보기도 하고, 그러다가 Associative Container를 찾아보고, Java 8의 Hashmap을 알아보고, EEVDF Scheduler란 친구를 알게 되기도 하고.
여전히 어렵다. 내가 잘못 이해한 내용도 많을 것이다. 실제로 위 주제에 대해서 알아보며 "140개 Priority Pointer"라는 대목에서 O(1) Scheduler를 MLFQ기반으로 착각하기도 했다. (교수님께 여쭤봤는데, Priority를 OS가 조정하지 않는다는 점에서 MLFQ로 바라보긴 어렵다고 하셨다) "기존 O(1) Scheduler가 상수 시간에 동작하길 선택했음에도, RB Tree의 로그 시간이 괜찮은 이유가 뭘까?" 교수님께 질문드렸는데, "Fair한 Scheduling을 성능보다 중요하게 바라본게 아닐까?"라는 사고의 전환도 경험했다.
결론
내가 만들었던 한계는, 생각보다 넘어갈 만했다. 그렇게 어렵진 않더라. 지난 4년에 회의적이었는데, 그래도 의미 없진 않았노라. 지난 4년간 이리저리 얻었던 지식이, 모르는 내용을 무작정 파고들 수 있는 기초 체력이 되어있었다.
오히려 조금 더 일찍 시도하지 않았음에 아쉽다. 당장 문서만으론 부족해서 교수님을 찾아뵙고 질문하며 알아내야 했는데, 금방 졸업을 앞둔 내게 질문할 수 있는 기회가 얼마나 더 남아 있을까? 하루하루 한 걸음 더 나아가며, 지금의 환경을 조금이라도 더 누려야겠다.
