'코딩'에 해당되는 글 3건

연구에 대한 실험 코드를 고쳐 가며 새로 데이터를 뽑고, 또 문제가 있거나 개선할 부분이 보이면 다시 고치기를 반복하고 있다. 이 과정에서 내가 개인적으로 유난히 시간을 많이 소비하는 단계가 있음을 알게 되었는데, 바로 어떤 설계(design)으로 개선해서 목적을 달성할 것인지 결정하는 단계이다.

예를 들어, 라우팅 프로토콜을 고치는 과정에서, source node가 자신이 트래픽을 보내기 위해서 먼저 경로를 탐색(route discovery)하고 선택해야 하는데, 이러한 과정을 자주 하게 되면 그만큼 네트워크 전체에 부정적인 영향을 끼치게 된다. 이러한 route discovery 자체를 줄이기 위해서 먼저 실제로 route discovery를 몇 번씩 했는지 파악을 할 필요가 생겼다. 이것을 어떻게 기록할 것인지 생각을 해 보았는데,

1. 그냥 각 source node의 ID로 된 텍스트 파일을 만들고, 매 초마다 route discovery를 몇 번 했는지 숫자를 텍스트 파일에 시간 순서대로 한 줄씩 기록하는 방법
2. Route discovery 전체를 기록하는 텍스트 파일 한 개를 만들고, 모든 source node가 같은 파일 포인터에 접근해서 시간, 노드ID, route discovery를 수행했다는 flag를 한 줄로 기록하는 방법

위의 두 가지 외에도 다양한 방법들로 기록할 수 있어 보였다.

그런데 나중에 통계를 내고 엑셀 파일 같은 곳에 가져다 쓸 것까지 생각을 해 봤을 때 어느 방법이 가장 좋은지 쉽게 판단이 잘 안 되는 것이었다. 이게 깔끔하게 마음 편한 방법으로 잘 정리가 되지 않자, 이것 때문에 하루 종일 다른 작업을 못하고 그냥 고민만 하고 딴짓만 하다가 시간을 보내고 말았다.

사실은 내가 연구 측면에서 정의한 문제를 해결하는 방법이 아니고, 라우팅프로토콜의 성능을 측정하는 데 필요한 작은 통계 생성 방법일 뿐이고 어떤 설계를 따르던지 어차피 시뮬레이션 성능에 큰 영향을 주지는 않기 때문에 무시하고 한 가지를 얼른 정해서 진행을 해도 되는 것이었는데, 어느 한 가지를 고르는 것이 속 시원하지 못하다는 이유로 연구 전체를 진행하지 못하고 마치 트랩에 걸리듯이 꼼짝하지 못했다.

결국 지금 밤이 되어서 그냥 첫 번째 방법으로 진행해서 얼른 경로 탐색에 대한 기록부터 만들어내고, 그렇게 각 source node별로 만들어진 기록을 합산하는 스크립트를 파이썬으로 빨리 만들어서 붙이기로 했다. 사실 이미 각 노드마다 flow 트래픽 사용량에 대한 통계를 똑같은 방식으로 만들어 내고 똑같이 파이썬 코드로 후처리(post-processing)를 하고 있었기 때문에 기존의 코드를 재활용해서 가장 적은 시간을 들여서 통계를 만들어낼 수 있는 것이기도 했다. (지저분하게 파일 개수가 많아지는 것, ns-3 코드 상에서 파일 포인터가 많아지는 것 외에는 그 어떤 문제도 없기도 하고...)

나는 지나치게 조심스러운 것이 단점이므로, 그냥 가급적이면 조금 더 빨리 결정한 다음, 뒤도 돌아보지 말고 밀어붙인 뒤에 나중에 문제가 터지면 그것을 그 시점에서 재빨리 고쳐 나가서 목적부터 달성하기 위해 노력해야겠다.

그러므로 내일 일을 걱정하지 말아라. 내일 일은 내일 걱정할 것이오. 한 날의 괴로움은 그 날의 것으로 충분하다 (마태복음 6:34)

국제학회 논문의 3저자 자격으로(1저자는 이미 졸업, 2저자는 다른 학회에 다녀왔고, 지도교수님은 가까운 시간 안에 다른 출장) 발표하러 미국 애틀랜타에 출장을 가게 됐다. 직항 대신 값싼 유나이티드 항공을 이용하면서 샌프란시스코를 경유하게 되었고, 대략 11시간 정도를 샌프란시스코에서 머물게 되면서 시내를 구경하려고 공항에서 나왔다.

(잠깐이었지만 즐거웠던 샌프란시스코 시내 탐방)

여기저기 구경하고 다니다가, 롬바드 거리에서 시내 기차역까지 빨리 이동해야 해서 이 때 우버를 처음 써 보았다. 구글 맵을 통해서 길찾기 검색을 했더니 교통 수단 옵션 중에서 우버 풀(Uber Pool)이 연동되어서 뜨길래 우버 풀을 선택했다. 그리고 얼마 후에 내가 호출한 차가 도착해서 그 차를 타고 목적지까지 편하게 이동할 수 있었다. 첫 사용으로 인해 약간 긴장이 되었지만, 한국에서 쓰던 카카오택시와 다를 바 없는 인터페이스 덕분에 사용이 어렵지는 않았다. (카카오택시가 우버보다 나중에 개발되었으므로 전체적인 구성을 참고했을 것이다.)

아무튼 우버 엑스(X)가 아니고 우버 풀(Pool)이었기 때문에, 중간에 다른 사람이 합승도 하고 먼저 내리기도 하는 등 합승 기능까지 처음으로 써보게 되면서 좀 특이한 경험이었다.

이렇게 긴장한 채 타고 가는데 더 신기한건, 그 와중에 내 스마트폰이 코딩 문제를 풀어볼 거냐고 나한테 묻는 것이었다. ㅡㅡ;;

(이건 앞서 한 문제를 풀고 나서 두번째 문제를 풀다 말고 찍은 스크린샷이다.

스크린샷은 제시된 알고리즘의 계산 복잡도를 묻는 문제.)

정신없던 당시의 기억을 돌이켜 보면, 우리와 같이 문제를 해결하고 싶다면 코딩 문제를 한번 풀어보라는 식의 안내가 있었고, 그걸 수락했더니 바로 타이머와 함께 코딩 문제가 눈앞에 나타났다. ㄷㄷㄷ

첫 번째 문제는 주어진 퀵소트 코드 중에서 버그가 있는 라인을 찾으라는 거였는데, 그나마 몇 달 전에 퀵소트 코드를 연습했던 덕분에 주어진 시간 안에 정답을 맞출 수 있었다. 하지만, 위의 두 번째 문제를 풀다 말고 중단해야만 했는데, 저렇게 문제를 푸는 와중에 갑자기 사람이 합승도 하고, 샌프란시스코에서 잠시 만나기로 한 친구에게서 페이스북 메신저로 메세지도 오는 등 정신이 없었기 때문이었다. 그런데 나중에 다시 찾아보니, 저 문제를 푸는 과정이 바로 우버의 채용과정이었다. 이럴 줄 알았으면 열심히 풀 걸 그랬다. ㅜㅜ

아무튼 처음 가 본 샌프란시스코에서 처음 써 보는 우버에, 처음 쓰는 환승 기능에, 처음 겪는 해커 챌린지 문제풀이까지 정신없는 반나절이었던 기억이 난다. 지금 생각해 보면 별 일 아닌데, 또 우버 쓰다가 위와 같이 물어보면 꼭 집중해서 풀어봐야겠다. 그런다고 해서 내가 문제를 다 맞출 거라는 보장은 전혀 없지만.. ㅋㅋㅋ

전화상으로 진행하는 코딩 면접을 위해서 예상 문제들을 살펴보며 어떻게 해결할 수 있을지 머리속으로 그려 보고, 더러는 종이나 메모장에 바로 pseudo code를 작성해 보고 있다. 그런데, 내 생각을 정리해서 "깔끔하게" 문제를 해결하는 순서를 설명하기가 예상하는 것보다 쉽지 않다. 

주어진 문제를 보고 입력과 출력이 어떻게 되어야 하는지는 비교적 쉽게 정의할 수 있다. 문제는 입력으로부터 출력까지 도달하기 위해, 거시적인 안목에서 어떤 순서를 거쳐야 하는지를 단번에 나열하는 것은 쉽지 않다. 거시적인 안목, 즉 top-down approach로써 문제를 생각해 보려고 노력하는데, 일단 top-down 측면에서 옳다고 생각해서 나열한 순서를 다시 한번 자세히 따져 보면 비효율적인 방법임을 깨닫게 되는 것이다. 예를 들어, 일단 큰 그림에서 문제 해결의 순서를 plain text 형식의 코멘트로 써 놓고, 해당 코멘트에 대응하는 실제에 가까운 코드를 작성하다 보면 뒤늦게 지금 작성중인 이 방법이 결코 효율적이지 않다는 사실을 깨닫는 것이다.

Top-down 관점에서 큰 순서에 영향이 없이 세부적인 부분을 개선하는 방식으로 생각을 좁혀 가는 것이 문제를 해결하는 가장 이상적인 방법이지만, 충분히 고민하지 않은 채로 큰 그림을 얼른 대충 만들게 되면 나중에 top-down 측면의 순서를 모두 고쳐야 하는 불상사가 생기기도 한다. 즉, 근본적으로 방향을 잘못 짚는 경우에 해당한다.

그러면 어떻게 해야 할까? 가장 이상적인 방법은 두말할 것도 없이 처음부터 효율적인 해결책을 top-down 관점에서 설명하고, 그 순서대로 코드를 구체화시켜 가는 것이다. 하지만 그렇게 바로 생각해낼 수 없다면, 위와 같이 해결방법에 큰 수정이 발생하더라도 이를 감수하고 다시 차근차근 고쳐 가는 것이 안전할 것이다. 일단 간단한 해결책부터 먼저 제시해 놓고, 그것을 검토하면서 더 효율적인 방법으로 코드를 수정해 가겠다고 지속적으로 면접관들에게 설명하면서 멈추지 않고 진행하는 것이다.

적어도 이렇게 하는 것이 심리적 압박감으로 인해서 아무 것도 생각해 내지 못하고 머리가 하얗게 되어 버리는 것보다는 나을 것이다. 결국 어떤 상황에서도 평정심을 유지한 채 점진적이고 지속적으로 답을 발전시켜 나가는 마인드 컨트롤의 문제로 볼 수도 있다.

처음부터 조금 더 효율적인 알고리즘의 큰 그림부터 그려나갈 수 있도록 꾸준히 예상문제들의 해결 방법을 생각하고 코드로 연습하는 것 외에는 왕도가 없어 보인다. 조금 더 노력해 보자...