정글 개발일지 week10 핀토스의 마무리

진짜 드럽게 힘들었던 핀토스 주차가 끝나간다... 지금까지 프로젝트를 하면서 느꼈던 것들을 마구잡이로 내뱉으며 이번 프로젝트를 마무리하려고 한다. 정신이 나가있어서 무슨 글을 쓸지는 나조차 모르고, 나중에 보면 이불킥을 갈길지도 모르지만 일단 써보자..!

범부

가장 처음 프로젝트를 진행하면서 느낀 건, 잘하는 사람들이 정말 많다는 것이다, 잘하는 사람들은 진짜 톡 튀어나온 것처럼 눈에 띄는 게 느껴졌다. 나는 그저 한낱 범부에 지나지 않다는 걸 새삼 느꼈다. ( 그래도 뭐 내가 하고 싶은 거니까 그것과는 상관없이 계속해야징 ㅎㅎ)

디버그는 엉덩이로

핀토스를 진행하면서(특히 프로젝트 3) 디버그에 가장 많은 시간을 보냈다. 디버그는 마치 엄마의 곰탕 같다... 처음에는 맛있지만 일주일 삼시세끼 내내 먹고 있으면 물려버리는... 그런 것...

버그 하나에 몇 시간을 보내고 있으면 진짜 지겹고 답답해 미쳐버릴 것 같았다. 진짜 너무 지겹다... 하지만 아무리 지겨워도 의자에 엉덩이 붙이고 버그를 붙잡고 있다 보니 결국에는 버그를 잡아내는 경험을 하면서 역시 디버그는 엉덩이로 하는 거구나라는 걸 느꼈다.

멘탈 탈탈 털린 상태에서 일을 진행하는 방법

최상의 컨디션에서는 당연히 코드도 잘 써지고, 머리도 쌩쌩 돌고 막혀도 어떻게든 뚫어낼 수 있다.
하지만 체력이 떨어지고, 비도 오고, 꿀꿀해지고, 어떤 미친 버그를 만나면 의지가 꺾이고 시간효율이 한도 끝도 없이 내려간다.

위에서 말한 것처럼 "공부는 엉덩이로 하는 거야!" 하면서 무작정 죽치고 앉아서 모니터만 보면 킬링타임 밖에 안된다. 차라리 그냥 들어가서 자는 게 훨씬 좋을 것이다.
실제로 나는 메탈이 털렸을 때 나는 차근차근이라는 단어를 잊고, 기도메타로 전향해 버렸다. "제발 돌아가주세요...ㅠㅠ" 하면서 아무런 근거도 없는 코드를 치고 있는 나를 발견할 수 있었다.

그때는 효율이 팍 죽는다... 그럼에도 어떻게든 효율을 짜내려면, 조금이지만 뭐라도 남길 수 있게, 쌓일 수 있게 시간을 보내려면 자기만의 루틴이나 방법을 찾는 게 중요하다는 걸 느꼈다.

나는 방법을 찾을 때, 정글 모집 공고에서 말한 공학적 사고가 떠올랐다.
힘들어 죽겠는데... 컨디션도 안 좋고 아무것도 하기 싫은데 해야 하는 일이 있을 때, 그 일이 너무 커 보여 압도될 때 그 일을 쪼개고 쪼개 가능한 최대한 작은 일로 만드는 과정이 필요하다. 그리고 공학적 사고란 이런 과정을 자연스럽게 해내는 사고를 말하는 게 아닐까 하는 생각이 들었다.

무튼 그래서 , 내가 정한 최악의 컨디션에서 일을 진행하는 방법은 위에서 말한 것처럼, 하기 싫은 일을 최대한 작은 단위로 쪼개고 추가로, 쪼갠 일 하나하나에 할애할 시간을 정하는 것이다.
시간제한은, 쪼개서 작아진 일이라도 시간의 제한이 없다면, 또 자신이 뭔 자신감인지 갑자기 여유를 부리고 멍하니 시간을 보낼 때가 있어서 추가했다.

남의 코드 디버깅

남의 코드 디버깅은 배로 힘들다. 다른 팀의 코드가 궁금해서 구경 가거나, 우리 팀이 해결한 문제를 다른 팀이 겪고 있을 때 도와주기 위해 가보면, 우리 코드와 비슷한 경우도 있지만, 너무 다른 방식으로 되어있는 경우가 대부분이었다. 디버깅하기는 무슨 이해부터 해야 했다. 그리고 이해를 했다 해도 어디서 손 봐야할 지 감도 잘 안 잡히는 경우가 태반이었다.

팀업

팀업은 빡세지만 생각보다 재밌다..? 서로 코드 스타일도 다르고, 속도도 다르기 때문에 그 차이를 맞춰가는 과정이 쉽지는 않았다. 눈치도 봐야 하고, 말도 조심해서 할 수 밖에 없었다. 팀 분위기도 생각을 해야 했고, 팀이 함께 가기 위해서는 누구 하나 뒤처지지 않아야 했다. 그래서 열심히 따라가는 경험도 했고, 어떤 부분에서는 다른 팀원을 뒤처지지 않게 신경쓰고 내가 아는 내용을 알려주기도 했다.
팀원들끼리 얘기하고 토론하기도 했지만, 다른 팀에게 협업을 제안해서 서로 다른 생각들을 공유하고, 토론하는 하는 등 새로운 시도를 해보는 경험도 할 수 있었다.

cs 지식

진짜 컴퓨터를 만든 사람은 천잰가 하는 생각이 절로 든다. 처음에는 "진짜 미친 건가? 왜 이따구로 만들지?" 하다가, "아 그놈의 추상화..." -> "그래 추상화를 잘해야 하지... 그럼 그럼" -> "... 와 진짜 사람 맞나? 신인가?ㅎㅎㅎ"
이해하기 심 들고 어려운 지식들을 공부해야 했지만, 그래도 배우고 싶었던 지식을 마음껏 공부할 수 있었던 시간이었다.
이전부터 계속 "내가 쓴 코드가 어떻게 돌아가는지? ", "내 코드는 어떤 과정을 거쳐서 하드웨어에 접근하지", "좀 더 로우 단계인 어셈블리어는 어떻게 생겼지?", "비트단위까지 가는 연산은 언제 왜 어떻게 쓰지?", "최적화는 왜 어떻게 하는 거지?" 등과 같은 생각을 했었는데 그에 대한 어느 정도의 대답을 공부할 수 있었다. 그래서 나에게는 만족스러운 시간이었다.

그밖의 티타임, 경험에서 배운점

1. 1차적으로 습득한 지식, 정보는 직접 내뱉고 적어야 정리가 되고 내 것이 된다.
2. 밤에 공부하면서 하나도 진도가 안 나가는데 엄청 열심히 하고 있는 착각을 할 때가 있다. 남들 다 안 보이니까... 그런데 낮에 퍼지면서 그러면 무슨 소용인가 싶다.
3. 지금 힘들고 고생하는 경험을 통해, 고생에 내성이 생기고 있는 것 같다. 고생근육을 키우는 중이라고 생각한다. 그리고 그만큼 고생해서 버그 하나 잡으면 그게 그렇게 짜릿하다.
4. 자신만의 루틴(위에서 말한 최악의 컨디션에서의 루틴 같은), 업무 습관, 취향들이 무엇인지 알아가고 있다. 나는 한번 학습하면 좀 딥하게 들어가서 채화를 많이 시키지만 그만큼 느리다. 꼬리 질문들이 엄청 많아서. 그러니까 부지런해야 한다.
5. 선택에 이유가 보여야 한다. 무슨 선택이든 개발자라면 그 이유가 있어야 한고 설명할 수 있어야 한다. 그래야 내 코드에 문제가 있어 보인다고 하는 사람이 생긴다면 건설적인 대화가 가능하다. 만약 그때 아무 말도 못 하고 그냥이라고 할 수밖에 없다면 스스로 좀 부끄러울 것 같다. 자신의 선택에 "그냥"이라는 이유는 빼야 한다. 그게 "대충 짰어요"랑 뭐가 다른가.
6. 뭐든 왜?라는 의문을 가지고 살자. 누구는 그냥이라는 대답을 할 수도 있지만, 누군가는 그 사람만의 합당한 이유와 새로운 시각을 나에게 공유해 줄 수도 있다.
7. 팀업을 하면서 내가 먼저 바보 같은 모습을 보인다면, 같이 있는 팀원들도 다가오기 편하고 긴장도 풀린다.
8. 가끔 진행하는 프로젝트가 너무 막히고 잘 안될 때가 있다, 그래서 난 왜 이렇게 못하지 진짜 범부인가 내가 이 길을 가느게 맞나? 나 같은 게? 하면서 부정적으로 생각될 때, 프로젝트와 나를 일체화하지 말자. 어차피 내가 좋아서 하는 개발인데 비교해서 뭐 하냐, 내가 좋아하는 것을 하고 있다는 것에 집중하자
9. 너무 책만 보면 이제는 안 쓰는 것들, 너무 옛날 것들도 공부하거나 타고 타고 들어가다 엉뚱한 곳을 공부하는 실수를 할 수도 있다.