3장. 기본 도구

스터디 내용은 아래에 정리하고있음
https://www.notion.so/10af59ac13a14d33affe40355f5e9852

 

Topic 16. 일반 텍스트의 힘

Tip 25. 지식을 일반 텍스트로 저장하라

여기서 말하는 일반 텍스트는, 바이너리 데이터나 암호화된 데이터 등의 별도의 어플리케이션이 있어야 읽을 수 있는 문자가 아닌, 있는 그대로 읽을 수 있는 텍스트를 말하는 것이다. 다음과 같은 이유로 일반 텍스트를 사용할 것을 권장한다.

• 지원 중단에 대한 보험
• 기존 도구의 활용
• 더 쉬운 테스트

위에서 말하는 일반텍스트의 장점은 "쉽다"이다. 반대로 바이너리 파일이나 암호화된 데이터는 "어렵다". 쉬운 것을 두고 어려운 것으로 한 이유는 분명 있을 것이다.

XML이나 JSON보다는 바이너리 데이터가 크기 측면에서 효율적이기 때문에 성능이 중요한 시스템에서는 우선시 되기도 한다. 보안을 위해서 모든 평문을 암호화 하기도 한다.

맹신하기보다는 필요한 것을 필요한 곳에 적절히 쓰면 될 것 같다.

 

Topic 17. 셸 가지고 놀기

Tip 26. 명령어 셸의 힘을 사용하라

책 내용중에 아래 구절이 인상깊었다.

What you see is What you get
What you see is All you get
GUI환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.

리눅스의 BashShell은 정말 강력하다. GUI와 셸은 마치 뭐랄까. 네이버 블로그로 정해진 양식 내에서 웹페이지를 만들다가, 직접 HTML, CSS, JavaScript를 이용해서 웹페이지를 만드는 것과 같다고 생각한다.

현재 나는 BashShell을 매일 같이 다루기 보다는, 필요한 경우에만 사용하고있다. 아주 모르는 것은 아니지만 잘 다룬다고 생각하지는 않는다. 잘 다루게되면 정말 편리할 것 같다.

 

Topic 18. 파워 에디팅

Tip 27. 에디터를 유창하게 쓸 수 있게 하라

모든 동작을 일일이 생각하면서 운전하는 초보운전자와
의식하지 않고 차를 모는 경험 많은 운전자는 완전히 다르다.

현재 사용하고있는 에디터는 Eclipse이다. 팀에서 과거부터 Eclipse를 사용해왔고, 환경을 바꾸지않고 그대로 사용하다보니 지금까지 사용하고 있는 것이다.

나는 집에서는 IntelliJ를, 회사에서는 Eclipse를 사용한다. Eclipse에 여러가지 Plug-In을 많이 사용하기도 하고, IDE가 오래 됐기도 하다보니, 꼬일 때도 있긴 하다. 그런데 자주 사용하다보니 큰 불편함은 모르겠다. 오히려 익숙하다. 물론 IntelliJ가 더 편할 때도 있다. 함수가 어디서 몇번 쓰였는지 자동으로 보여주는 기능은 꽤나 유용하다. 아무튼 그래서 처음과 달리 굳이 Eclipse를 벗어나야겠다는 생각은 많지 않다. 목수의 손에 딱 맞게 닳아서 맞춰져버린 연장같은 느낌이랄까.

그렇지만 새로운 에디터를 익히는 것도 중요한 것 같다. 처음엔 불편해도, 조금씩 익숙해지다보면 새 에디터 대비 헌 에디터를 사용했을 때, 이렇게나 불편했었나? 하는 순간이 오지 않을까? 그렇게해서 작업 능률이 올라간다면, 책에서 말한대로 4%의 속도만 증가해도 1년이면 일주일을 버는 것이다.

집에서 사용중인 IntelliJ의 기능들을 더 탐구하고, 내 것으로 만들어 보아야겠다. 더 나아가서 업무에 적용 시켜보아야겠다.

 

Topic 19. 버전 관리

Tip 28. 언제나 버전 관리 시스템을 사용하라

혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나주에 버리기로 한 프로토타입일지라도, 심지어 작업하는 것이 소스 코드가 아닐지라도, 모든 것을 버전 관리 아래 둬라

회사에서 문서 작업 할 일이 참 많다. 문서가 변경될 때 마다 파일 이름 뒤에 v1, v2, v3이런 식으로 관리를 하고있다. 그런데 이 문서들을 VCS를 이용해서 버전 관리 할 생각은 한 번도 못해봤다. 왜 그 생각을 못했지!?

현재 우리팀에서는 SVN을 사용하고있는데, 회사에서 Gerrit을 사용하는 팀이 있다. Gerrit은 코드를 commit하면 프로젝트의 책임자가 그 코드를 모두 살펴보고 승인해야 merge가 된다. PM은 매번 commit된 코드를 살펴봐야한다는 번거로움이 있겠지만 코드 관리 측면에서는 매우 효율적일 것이다.

이건 좀 부러웠다. 우리팀은 각자 알아서 코드를 commit하기 때문에 코드관리가 마음처럼 잘 되지 않는다. 우리팀도 배워보려고했으나 사용법을 배우는데 오래걸리고 밀린 업무가 많아서 그냥 포기한 적이있다. 꼭 배워보고싶은 VCS이다.

 

Topic 20. 디버깅

Tip 29. 비난 대신 문제를 해결하라.

디버깅은 많은 개발자에게 예민하고 감성적인 주제이다. 디버깅을 풀어야 할 퍼즐로 공략하는 대신 현실 부정이나 손가락질, 어설픈 변명, 무관심으로 대하는 사람과 마주치기도 한다.
다른 사람의 버그를 발견한 후, 그 버그를 만들어 낸 부정한 범죄자를 비난하는 데에... (생략)

아... 위 내용을 일그면서 누군가가 떠오른다. 그 분은 아주 예민하고 감정적으로 디버깅을 받아들이는 것 같다...  버그를 만들어 낸 부정한 범죄자라고 비난한다고 생각하는 것 같다... 그래서 얘기하기가 너무 힘들다...

이 책, 이 내용을 너무너무 보여주고싶다. 하지만 그럴 수 없다... 크흑...

반면교사 삼자. 나도 모르게 내가 그렇게 될 수도 있지 않은가. 뼛속 깊이 새겨야 할 내용이다.

디버깅을 시작하기에 앞서 올바른 마음가짐이 중요하다. 자신의 자아를 보호하기 위해 늘 켜 놓는 많은 방어막을 꺼 버리고, 여러분을 짓누르고 있는 프로젝트의 압력을 무시해서 자신을 편안하게 만들어야 한다.

 

Tip 30. 당황하지 말라

버그를 목격하거나 버그 신고를 보는 순간의 첫 반응이 "그건 불가능해"라면 여러분은 두말할 필요 없이 틀렸다. '하지만 정말 그럴리가 없는데'로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라. 왜냐면 명백히 그런 일은 일어날 수 있으며, 실제로도 일어났기 때문이다.

ㅋㅋㅋㅋㅋㅋㅋ 과거의 내가 떠올라서 너무 웃기다. 누구나 한 번쯤은 이런적이 있지 않을까?

디버깅할 때 근시안의 함정에 주의하라. 표면에 보이는 증상만 고치려는 욕구를 이겨 내라. 항상 문제의 근본 원인을 찾으려고 노력하라

이 챕터의 모든 구절이 다 정곡을 찔러서 이러다가 책의 내용을 모두 인용구로 써버릴것같다.
반성하고 반성한다...

하지만 그 때는 정말 힘들었다. 매일같이 발생하는 원인을 알 수 없는 서버 장애 때문에 퇴근도 못하고, 주말도 없었다. 밀린 일도 산더미인데 장애 해결하기에 급급했다. 서버 트래픽이 내려가게 조치하기에만 바빴다. 상사에게 설명하고, 장애보고서를 쓰고, 그러다가 또 다시 장애가 발생하고, 또 트래픽을 내리는데 급급하기만 했다.

그럼 트래픽이 왜 올라가고, 왜 장애가 발생하는가? 위에서도 물어보고 나도 그걸 알고싶었지만 앞서 말한 과정이 반복되면서 알아낼 시간이 없었다.

어쩌면 이제와서 말하는거지만 그건 핑계였을지도 모른다. 얼른 다그치는 상사를 벗어나고싶은 생각에, 이 상황을 넘기고 싶다는 생각에, 퇴근하고싶다는 생각에 만들어낸 핑계.

이 책을 읽으면서 그 때가 떠오른다. 다 아는 말이지만 실천하기가 참 어렵다. 그래도 다시한번 가슴에 새기면서 그러지 않도록 해보자.

실마리 찾기
버그를 살펴보기 전에 일단 작업 중이 코드가 경고 없이 깨끗하게 빌드되는지부터 확인하라. 우리는 늘 컴파일러의 경고 수준을 최고로 높게 맞춘다.
컴퓨터가 대신 찾아 줄 수 있는 문제를 여러분이 찾느라 시간을 허비한다는건 말도 안된다!

ㅋㅋㅋ이것도 진짜 웃긴다. 컴파일러는 항상 수많은 [WARN]을 뱉어낸다. 그리고 나는 항상 그것들을 무시한다. 어쩜 이 책은 이렇게 가슴을 후벼팔까. 컴파일러의 오류메시지, 아니 경고메시지부터 차근차근 읽어가며 디버깅을 해야한다.

 

Tip 31. 코드를 고치기 전 실패하는 테스트부터

버그를 재현할 수 있게 다른 상황으로부터 분리하라는 얘기이다.

하지만 5만 줄짜리 코드가 눈앞에 있고 시간은 흘러가고있다면 불쌍한 프로그래머는 무엇을 해야 할까?

 

Tip 32. 그놈의 오류 메시지 좀 읽어라

아 ㅋㅋㅋㅋ 이 팁은 왠지 StackOverflow의 댓글에서 본 것 같은 그런 느낌이다.
갑자기 든 생각인데 이 책의 저자는 StackOverflow에서 열심히 활동하는 네임드 회원이 아닐까싶다...

 

Tip 33. "select"는 망가지지 않았다.

이 말은 내가 사용한 '라이브러리나, OS, 혹은 외부 제품에 문제가 있는게 아니다'라는 뜻이다. 문제가 내 코드에 있을 확률이 크다는 뜻이다. 그렇다. 이 말이 맞다. 내 코드가 완벽하기 때문에 외부에 문제가 있을것이라고 생각하는 경우가 많지만, 자세히 살펴보면 내 코드에 어처구니없는 실수가 있는 경우가 많다. 코드가 문제가 없다면 환경변수 값 등을 잘못 셋팅했을 수도 있다.

 

Tip 34. 가정하지 말라. 증명하라

버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 '안다'고 해서 대충 얼버무리고 지나치지 말라.
그것을 증명해라. 이 맥락 안에서, 이 데이터로,  이 경계 조건하에서 증명하라.

수 년간 문제 없던 코드에서 문제가 발생해서 놀랄 수 있다. 그럴때조차 '이 코드는 괜찮아'라고 얼버무리지 말라는 것이다. 나는 실제상황에서 정말 그렇게 할 수 있을까? 정말 어려운 챕터이다...

 

Topic 21. 텍스트 처리

Tip 35. 텍스트 처리 언어를 익혀라

텍스트 처리는 지저분하다. 하지만 강력하다. 책에서는 텍스트를 처리하기 위한 언어를 따로 익히라고 소개한다. Python이나 Ruby가 그것이다.

이런 것은 생각해본 적도 없다. 나는 거의 대부분 JAVA를 이용해서 코딩하고있고, 텍스트 처리 역시 JAVA를 이용해서 한다. 예를들면 CSV파일을 파싱하거나, 원하는 단어를 파싱하는 등의 작업 말이다.

여기에 특화되어있는 Python이나 Ruby를 사용한다면 작업시간이 훨씬 단축되고 효율이 좋아질 수도 있다.
회사에서는 바로 시도해보기 어렵고 먼저 개인 프로젝트 등에 적용해보면 좋을 것 같다.

 

Topic 22. 엔지니어링 일지

ㅁㅁ