[ TWIL 1주차 ]

- 코드스테이츠 1일차 (5월 4일)

강좌는 프로그래밍을 접한 사람이면 무난하게 넘어갈 수 있는 수준이었다. 하지만 처음 접한 사람에게는 강좌를 다 듣고 중간중간 이해가 안 돼서 뒤로가기 누르고 다시 찬찬히 보기엔 빠듯해보였다.

코드스테이츠만의 특별한 프로그램 중 하나가 페어프로그래밍이 아닌가 싶다. 코칭하시는 분들이 페어프로그래밍을 하기 전에 대체 어떤 식으로 흘러가는지 개념으로 이해가 되지 않을 거라 생각해서 페어프로그래밍 게임을 다같이 해보는 시간을 가졌다. 페어프로그래밍 게임은 두 사람이 짝을 지어 시작하고 한 사람에게 그림을 하나 보여준 후 그림을 보지 않은 다른 한 사람에게 그림을 설명하고 똑같이 그리도록 해 정답을 맞추는 방식이다.

처음엔 쉬워서 웃으며 진행했는데 갈수록 어려워지는 문제에 초조해졌다. 절로 페어에게 잘 해내지 못해서 미안하다는 소리가 나왔다. 하지만 페어는 자신이 잘 못 따라 그리는 것 같아도 속상해하거나 미안한 기색을 보이지 않았다. 묵묵히 그려보고 잘 모르겠으면 다시 설명해달라고 요청했다. 모르는 게 미안한 일은 아닌데... 실제로 페어프로그래밍을 하면서, 페어분께서 잘 몰라서 미안하다고 얘기했을 때 나도 저렇게 비춰지진 않았을까 생각이 들었다. 미안하다는 말보다 해보고 잘 안되면 무엇 때문일까? 나는 이런 사고과정으로 이해했는데 맞는지 되묻는 그런 태도, 자세를 가져야겠다는 생각이 들었다.

1일차가 끝날 무렵 1시간 동안 Zoom을 사용해서 실제로 페어프로그래밍을 진행했다. Zoom 사용법에 익숙하지도 않고 페어프로그래밍에 대해 아직도 감을 잡지 못한 상태였다. 그래서 문제를 보고 문제에 대한 해결과정 즉, 내가 생각해낸 코드를 하나하나 불러주면서 페어분께 작성하도록 요청했다. 이 방식이 과연 페어프로그래밍이 맞는 걸까?

- 코드스테이츠 2일차 (5월 5일)

오늘은 코드스테이츠 과정의 유일한 휴무일이다. 휴무일이라 하지만 휴무가 아니라고 일정엔 없지만 엄청 빡빡한 일정이 있다고 생각하라는 코칭님의 말씀이 떠올라 웃음이 난다.

코드스테이츠를 수강하기 전 Mac 사용자가 아닌 분들은 되도록 OS를 Ubuntu를 사용해야 이후 개발환경에 의해 생기는 문제를 해결하는 데 도움을 줄 수 있다는 문구를 봤었다. 생소한 Linux환경에 거부감이 들었고 기존에 사용하고 있는 Window를 포기하고 싶지 않았다. 참 별거 아닌데 익숙한 거를 버리고 새로운 걸 받아들이는 건 두렵고 겁난다. 그래서 가상머신을 설치하고 가상머신으로 Ubuntu를 실행시키려는 꼼수를 썼다. 그런데 코치님께서 가상머신으로 돌릴 경우 데이터 송수신에 문제가 발생할 수도 있다고 하셨다. 아아...이제 Window와 작별할 시간이 되었구나. 어차피 개발자의 길을 걷는다고 마음 먹은 이상 Linux나 Mac 환경에 익숙해야한다. Ubuntu 설치과정에서 Window 삭제 여부를 묻는 창에 Yes를 누를지 말지 망설였다. 온몸에 털이 곤두선 긴장감이 흘렀다. 침을 꼴깍 넘기고 Yes 클릭!! Window야, 그동안 고마웠어..잘가

Window와 작별 후유증을 추스릴 틈도 없이 Ubuntu의 생소한 프로그램 설치방식에 당혹스러웠다. Window에서는 어떤 프로그램을 설치하고 싶으면 해당 사이트에서 Download만 클릭하고 exe 파일만 실행시켜주면 끝이었다. Ubuntu는 터미널 창에서 명령어를 사용해 프로그램을 설치한다. 하나 설치하는 데 다른 것들도 다 설치해야 하는 경우가 많아 머리가 어지러웠다. 거진 필요한 프로그램을 다 설치했다고 판단하고 숨을 고를 때 예상치 못한 문제에 맞닥뜨렸다.

어제 못 다한 페어프로그래밍을 하려고 Zoom을 켰는데 사운드가 먹통이었다. 페어분께 사과의 말을 전한 후 사운드 문제를 해결하기 위해 몇 시간 동안 매달렸다. 프로그래밍은 할 줄 알지만 컴퓨터 환경과 관련된 내용은 무지했다. 구글링해서 알려준 방식들을 이것저것 해봤지만 전혀 해결될 낌새가 보이지 않았다. 설마 Ubuntu설치 과정에서 내 노트북이 고장난 건 아닌가. 구매한 지 1년도 채 되지 않은 내 노트북에 문제가 생겼을까 발을 동동 굴렀다.

처음으로 github help-desk를 이용해봤다. 하루종일 여러 사이트를 탐방하며 이것저것 시도했는데 따로 참고한 링크와 방법을 기록하지 않아서 내가 시도한 노력들을 다 담아내지 못했다. 놓친게 있지 않을까 걱정이다.

자정을 넘기기 전에 답변을 받았다. 내장카드가 문제인 경우엔 똑같은 상황에 놓인 사람이 아닌 한 도와드릴 수 없다고 했다. 내장카드명과 사운드, Ubuntu 키워드를 사용해서 검색해보라고 했다. 맙소사...수많은 노트북 중에 Asus zenbook 14를 쓰는 사람이 얼마나 있으며 Ubuntu를 설치하다가 사운드가 고장난 케이스가 과연 있을까? 반 포기 상태로 마지막 카드를 썼다. 코드스테이츠에서 Ubuntu 설치 시 18.04 버전을 권장했기 때문에 계속 그 방법은 사용하지 않고 다른 방법만 시도했었다. 또 다른 답변 중에 20.04 버전 업그레이드를 해보라는 말을 보고 마지막 카드로 남겨둔 방법을 사용했다. 결과는 참담했다. 문제는 해결되지 않았다. 불편하지만 강의를 듣거나 페어프로그래밍, 전체 회의 시간엔 휴대폰을 쓸 수 밖에...

- 코드스테이츠 3일차 (5월 6일)

아침에 노트북을 키고 혹시나 하는 마음에 유튜브 영상 아무거나 틀었다. 소리가 들린다!!! 기쁜 마음에 소리를 질렀다. 얼른 github help-desk 에 해결 소식을 알렸다. 기쁜 소식도 잠시 이번엔 페어분 목소리가 들리지 않는다. 내 목소리는 잘 들리는 걸 보니 내 노트북 문제는 아닌 것 같은데... 어쩔 수 없이 오전 페어프로그래밍 시간 내내 내가 navigator 역할을 했다. 오후 페어프로그래밍 시간엔 해결되었느냐? NO! 결국 코칭님 찬스를 썼다. 알고보니 내 Zoom 환경설정 탓이었다. 상대방 사운드 소리를 완전히 꺼버린 상태였다. 최대 볼륨으로 조절하니 잘 들렸다. 엉뚱하게 페어분 컴퓨터에서 원인을 찾으려다 시간을 허비했다.

office hour시간은 코칭님과 모든 수강생들이 한 자리에 모여 학습한 것들을 복습하고 질의응답하는 시간이다. 왜 예외가 많은, 골칫덩어리인 == 과 != 이 존재하는지 알게 됐다. 예전에 브라우저를 어떻게든 화면표시가 되도록 하기 위해 느슨한 체크를 허용했던 것이다. 그리고 수치적 비교와 논리적 비교를 오해해 당연한 사실을 물어버려 창피했다. 에잇! 부끄러워도 내가 어떤 잘못된 사고를 하는 지 알게 됐으니 좋은 거 아닌가? 남들 보기에 쉬운 걸 물어본다고 생각해 입을 닫는 거보다 이렇게 용기내서 묻는 게 더 좋다. 계속 질문을 하자.

- 코드스테이츠 4일차 (5월 7일)

페어프로그래밍은 거의 매일 페어가 바뀌었다. 아마 모든 수강생과 한 번씩은 페어를 해보도록 할 생각인가 보다. 페어프로그래밍 강좌를 보고 난 후 어떤 식으로 진행할지 방식을 틀었다. 문제를 같이 읽고 문제의 조건, 문제가 원하는 결과값(주로 반환값), 필요한 개념을 먼저 언급한 후 코드를 작성한다. 초반에 내가 생각 한 방식을 무의식적으로 강요해버렸다. 다음 페어부터는 페어 방식을 존중하고 내가 네비게이터할 때만 내 방식을 보여준 후 페어가 내 방식이 마음에 들면 차용하고 아니면 안 하는 선택지를 줘야지.

페어분께서 미리 문제를 읽고 문제에 필요한 스킬 혹은 지식을 생각해와서 새롭게 알게 된 내용들이 많다. 그 내용은 아래와 같다.

NaN은 isNaN으로만 falsey여부를 확인할 수 있다.
** 연산자의 존재 : pow기능과 똑같다!
문자열 변환시 toString보다 String 생성자를 활용하는 게 안정적!

생각보다 일찍 페어프로그래밍이 끝나서 같이 github help-desk에 올라 온 질문들 중 하나를 골라 같이 답변을 생각해봤다. 이미 푼 문제라 가볍게 넘겼던 질문이 있는데 생각지 못한 부분을 물었다. falsey와 false의 차이를 이해해야하는 문제였다.

'=== false'가 값과 타입을 모두 체크한다는거. 그러니까 가끔 참, 거짓의 의미상으로 접근할 때가 많은 데 false도 엄연히 특정 값으로 메모리상에 저장된 값이라는 거!! 가령 if문 조건식에 null, 0, undefined, "", NaN이 false로 취급되긴 하지만 false라는 의미가 아니다. 그렇기에 앞에 나열한 값들이 === false가 될 수 없는 것이다.

- 코드스테이츠 5일차 (5월 8일)

새로운 페어를 만나 또 내가 말하는 방식에 대해 생각해보는 시간을 가질 수 있었다. 이전 페어분들과는 얼버부려도 척척 알아들어주셨다. 하지만 불분명한 말을 곧바로 이해하는 사람들이 어디든지 있으리란 보장이 없다. 어떻게 하면 정확하게 요구사항을 전달할지 고민한다. 천천히 차근차근 말을 하는 연습시간이었다.

누군가 계속 옆에서 하나하나 질문받는 게 부담스러울 수 있는데 내색하지 않고 어떻게든 답하기 위해 애쓰는 페어의 모습을 보고 문득 과거의 나가 떠올랐다. 아..그때의 나였다면 자존심 상해 상대방을 미워하지 않았나.. 지금도 여전히 나보다 수준이 높다고 생각하면 주눅이 들고 그 앞에서 실수할까봐 노심초사하는데.. 페어분은 그래도 꿋꿋히 답을 하려고 했다. 틀린 답을 말해도 다시 또 일어선다. 페어분께 배워야 할 점이다.

페어프로그래밍은 단순히 각자가 미리 짜놓은 코드를 그대로 옮기는 과정이 아니다.
그건 솔로프로그래밍과 다름없다. 내 사고과정을 드러내고 그에 대해 다른 의견이나 더 나은 방법 혹은 실수로 범한 오류, 설명이 부족해 이해가 어렵다는 등의 피드백을 받을 수 있는 자리다.

혼자 문제를 다풀고나서 페어프로그래밍을 처음엔 했지만 지금은 페어프로그래밍시간에 곧장 문제를 보고 푸는 연습이 더 나은 것 같다. 실제로 코딩면접에는 문제를 미리 풀어볼 시간이 없고 있어도 짧은 시간 내에 해결과정을 구상해야하기 때문에 그런 연습을 사전에 해보는 게 좋은 것 같다.

페어프로그래밍 덕분에 의사코드 작성하는 습관을 길들이고 있는 중이다. 추가로 명확한 의사전달도 점차 익숙해지는 듯하다. 더 분발하자.