歸天

Title : Beautiful code 38인의 코딩 명장들이 말하는 내 생애 가장 아름다운 코드.
이 책 번역서를 훑어 보다가 조금 공감되는 글이 있어서 따 와 봤습니다.

만화에서는 깨달음의 순간을 사람 머리 위에서 전구가 켜지는 모양으로 표현하곤 한다. 내 경우 그러한 갑작스러운 이해의 순간은 뒤통수를 벽돌로 맞은 느낌이라고 표현하는 게 더 합당할 것 이다. 아마 독자도 그런 경험이 있을 것이다. 충격이 가시고 정신을 차리고 나면 머릿속에 남아 있는 멋진 해법에 매료된다. 그러나 그 순간이 지나고 나면, 그 해법이 너무나 당연한 것이어서 애초에 몰랐던 것이 이상할 정도라고 느껴진다. 며칠이 지나면 아마도 알고 있었던 것이라는 생각이 들었다가 급기야는 확실히 알고 있었는데 잠깐 잊었던 것이라고 스스로를 속이게 된다. 나중에 그 해법을 다른 사람에게 전해 줄 때에는 “다들 알고 있는 거지만...“으로 말을 시작하는 자신을 발견할 수 있다.

Beautiful code 33장. “그 책“에 실릴 프로그램 짜기 – Brian Hayes 中

software 제작을 완료후 어느날 갑자기,
내일까지  수정사항을 적용해서 마무리 해야 한다는 소식을 전해 듣는다.
아뿔싸; 수정 사항은 생각보다 만만치 않아 보인다.
양도 많고... 내일까지 하려면 시간이 모자랄 것 같다.

밥먹는 것도 잊고...
코드의 품질도 잊고...
일단 완성하고 보는거다!

그리고 어떻게든 완성을 해서 다음날 보내준다.
그런데..? 알고보니 오늘이 데드라인이 아닌가벼? 또다른 수정 사항이 온다.
ㅆㅂ... 완성 하려고 코드는 떡이 됐는데, 여기서 또 수정하려니까 ..... 욕밖에 안나온다.

아씨 이럴꺼면 좀더 유연하게 짜둘껄.... 뒤늦은 후회...
그래서 다시 마음을 다잡고 제네럴 하게 설계하고 짜기 시작한다.
일이 훨씬 수월하다... 훨신 유연해서 이제는 웬간한 수정사항도 받아 드릴 수 있을정도.

그리고 일이 끝난다. 후우.................




뭐 이런 스토리를 여러번 겪는다. 이전에 인턴 할때도 당장에 보여줘야할 Demo 를 위해
코드를 겁나 때우고 또 때워서 보여주고 -_ -. 근데 그 Demo 가 무지 잦아서 고생을 했던 기억이 있다.
Demo 할때마다 내 코드의 자존심은 구겨지고, 기분도 떨떠름한게... 욕구가 완전 사라졌었는데..

Agile 방법론으로 고객의 수정사항, 요구사항을 유연하게 잘 받아 드리면 좋은것은 당연한데,
좌우간 코드의 품질은 좋게 하고 볼 일이다.

그런데 중요한건 이런 코드 품질이 엔지니어의 실력은 둘째치더라도 프로젝트의 운영에도
많은 영향을 받는다는 것 이다.

그 운영이란게 참 추상적인데,
프로젝트의 일정 관리,
팀원들간의 커뮤니케이션,
팀원들의 컨디션 관리,
등등등이 포함되지 않을까 싶다.

게다가 엔지니어의 입장도 고려해야 하고, 클라이언트의 입장과 요구사항도 잘 맞춰야 하니까..
이게 여간 쉬운게 아닌 것 같다.

학교에서 배우는 “소프트웨어 공학” 에서 이런 것들에 대해 가르치는데,
이런 지식은 엔지니어링 자체에 대한 지식이기 보다는, 엔지니어링에 대한 엔지니어링
즉, 메타적인 지식이라고 할 수 있다.

나는 그냥 실력만 있으면 뭔들 못하니...(전형적인 엔지니어들의 생각?) 라고 생각했는데
“아 ... 실력이 다가 아니구나... “
라는걸 특히 최근에 많이 깨닫고 있는 중이다.

이런 경험들을 절대 잊지않고, 나중에 혹시 프로젝트를 운영할 일이 생기면 참고해야겠구나!!

나는 Computer Science 를 공부하는 학생이다.
이제 졸업하기 까지 2년이나 남았다.

군대에서는 열심히 군 생활을 했고,
신나게 내 공부를 할 수 있었던 지난 2년이라는 시간동안
프로그래밍을 주욱 공부해 왔다.

인턴과 약간의 실무를 경험해 보기도 했고
실무에 필요한 기술들도 몇가지 익혔다.

그리고 2년이라는 시간이 다시 나에게 주어졌다.

앞으로 더 성장하기 위해서는 어떤 준비를 해야 할까?
앞으로 더 훌륭한 프로그래머가 되기 위해서는 어떤 공부를 해야할까?

곰곰히 생각하다가...
10년이 지나도 가치있는 그런 지식!

그 결과 요즘엔 어셈블리를 보고 있다.
완전 바닥으로 가는거다.

어우 좀 놀랬는데
전혀 실용적이지 않고, 학교에서는 잘 가르치지 않는 이런 지식들..
그런데 한 페이지 한 페이지 읽어 갈수록, 지금까지 공부했던
지식들이 더 명쾌해 지고 견고해지는 느낌을 받는다.

“심봤다.”

내가 소중히 여기는 대중적이지 않은 것들..

윈도우즈 아닌 리눅스 라던가...
잘 쓰이지 않는 Lisp 이라던가...

그리고 이번에 하나 더 추가

쓸일이 거의 없을 어셈블리.

아무리 생각해도 이런것들은 프로그래머로서의 인생을 통틀어 볼때
정말 가치있는 배움인데도 불구하고 사람들이 별로 신경을 안쓰더라.

언젠가 내가 더 훌륭한 프로그래머가 될 것 같아서
나는 이런거 공부하면서 신난다.

하하하...

가끔 프로그래밍 관련해서 의뢰를 받으면 일단 그 순간은 우리 모두가 하늘위로 붕 뜬다. -.-
정말 무서운건, 고객이 뭘 원하는지 알 수가 없다. 그런데 물어보면 자신도 모른다. 그러니까..... 우리 모두 모른다.(헉);

게다가 프로그래밍 실력은 둘째치고, 좌우간 컴퓨터랑 연관된 분야가 워낙 많다보니
막상 의뢰를 받으면 그쪽 관련해서 알아봐야 할 사항들도 뭉탱이로 딸려 온다.
각종 이메일 문의 부터 전화까지 여기저기 알아보면서 -_-......

결론적으로 고객은 "뭔가 멋지게 해주세요".
우리는 "이런 기능이 있으면 좋겠군요? 이 기능도 있어야 하겠고요, 그리고 알아 봤는데 이건 이렇다는군요."

뭐 이런식 이랄까.
상황이 이렇다 보니, 초기에 견적을 내서 보내주고 일을 시작하고...... 일이 끝나고 나면 깨닫는다.

"아, 일을 곱빼기로 했구나..........." ㅜ_ㅜ

프로그래머에게는 자료구조, 운영체제, 알고리즘, 컴파일러, 프로그래밍 언어, 네트워크, 어쩌고 어쩌고
뭐 이런 매우 중요한 기초 지식부터
버전 컨트롤, 각종 방법론, 각종 패러다임, 각종 프로토콜, 웹, 그외에 수많은 추상적인 개념과 스킬들 어쩌고 저쩌고 이 필요함은 물론인데......

어찌보면, 궁극에 필요한 것은 "대화법" "문제 정의" "추상에서 구체화" 등등
정확한 명세를 만드는게 아닐까......

우리는 컴퓨터를 가지고 무언가 하지만, 컴퓨터를 상대로 일을 하지는 않는다.
결국 사람에게 필요한 무언가를.... 그러니까 사람을 상대로 한다는 것.
어떠한 문제가 다가오면 계속해서 토론하고 문제에 대해 정확하게 정의를 하다보면 대개 구체적인 명세와
그 명세에 따른 구체적인 해법(코드조각, 프로토타입) 까지도 나오게 된다.
그런데 그 과정이 빈약했거나 생략을 했을경우, 방황하게 될지도 모른다..

그런데 대학에서는, 보통 추상적 이론과 약간의 스킬들만을 가르치는 것이 보통이다.
상황이 이렇다 보니, 대학교의 교육과정에만 충실하고 안심하고 있다가는 현업의 무대에서
culture shock 를 받을수도 있겠다.

겨울에 뜨뜻한 방안에서 뭔가 흥미롭고 재미난 프로그램을 만들기만 한다면 얼마나 좋겠냐마는...
현실또한 그렇지만은 않다는 것들을 조금씩 배워가고 있다.

마음가는 대로 살고 싶었다.
그래서
마음 가는 대로 하려고 노력했다.
다 내멋대로 살꺼라고 했다.
이거 내꺼니까.


그런데 살다보니
귀찮은 것들이 나를 귀찮게 했다.
이런 저런 귀찮은 것들.


그런데 그런 귀찮은 것 들을
내멋대로 그냥 그렇게 냅뒀더니
죄책감이 들더라.


아니 내가 왜?


조금더 마음가는대로 사는거다.