🤔 Chapter 7: 코딩하는 동안

🍭 Topic 37. 파충류의 뇌에 귀 기울이기

프로그래머로서 경험이 늘어 갈수록 여러분의 뇌에는 암묵적인 지식이 켜켜이 쌓인다. 잘 되는 방법, 잘 안되는 방법, 오류 형태별로 가능한 원인 등 일하는 동안 보고 듣고 느끼는 모든 것이 쌓인다.
어디에서 왔는지에 상관없이 모든 본능에는 공통점이 있다. 바로 말로 표현할 수 없다는 것, 생각이 아니라 느낌이라는 점이다. 본능이 반응한ㄴ다고 머리 위에 반짝이는 전구가 나타나지는 않는다. 오히려 그저 불안하고 초조해지기만 한다. 감당하기 어려운 일처럼 느껴질 수도 있다.
이럴 때의 해결책은 일단 본능이 반응하고 있음을 인지하는 것이다. 그리고 왜 그런 느낌이 드는지 알아내야 한다.

🥕 백지의 공포

새로운 프로젝트를 시작하는 일도 두렵기는 마찬가지다. 심지어 이미 있는 프로젝트에 새로운 모듈을 추가하는 일도 그렇다. 많은 사람이 일을 시작하는 첫 발짝을 미루고 싶어 한다. 우리 생각에 이런 문제에는 두 가지 원인이 있는데, 한 가지 방법으로 둘다 해결할 수 있다.

첫 번째 원인은 파충류의 뇌가 여러분에게 무언가 할 말이 있어서다. 인식의 지평 바로 밑에 도사리고 있는 모종의 의심이 있다. 이런 의심은 중요하다.
여러분은 개발자로서 여러 가지를 시도해 보면서 잘 되는 것과 안되는 것들을 보아 왔다. 경험과 지혜를 축적해 온 것이다. 어떤 작업을 앞두고 마음 속에 의심이 계속 남아 있거나 왠지 꺼림칙하다면, 여러분의 경험이 여러분에게 말을 거는 중일지도 모른다. 그 느낌을 따라라. 어떤 것이 문제라고 정확하게 짚지는 못하더라도, 시간을 좀 주면 여러분의 의심은 아마도 좀 더 실체가 있고 대응책을 생각할 수 있는 무엇으로 구체화될 것이다. 직감이 여러분의 역량에 일조하도록 하라.

다른 원인은 좀 더 진부한데, 여러분은 그저 실수할까 봐 두려운 것일 수 있다.
합리적인 두려움이다. 우리 개발자들은 코드에 많은 것을 투자한다. 그래서 코드의 오류를 자신의 부족한 능력 때문이라고 받아들일 수도 있다. 아마 가면 증후군의 요소 또한 있을 것이다. 이 프로젝트는 자신의 능력 밖이라고 생각할 수도 있다. 우리는 이 길의 끝에 무엇이 기다리고 있는지 모른다. 어쩌면 너무 멀리까지 가버린 후에 사실은 길을 잃었다는 것을 인정하게 될지도 모른다.

🥕 자신과 싸우기

코딩이 진창에서 오르막길을 걷는 것처럼 느껴지는 날이 있다. 한 걸음을 떼려면 어마어마한 노력이 필요하고, 세 걸음 나아갔더니 두 걸음 미끄러지기도 한다.

하지만 전문가라면 여러분은 계속해 나가야 하지 않을까? 안타깝지만 진짜로 여러분이 해야 하는 일은 정반대다.
여러분의 코드가 무언가 말하려는 것이다. 지금 하는 작업이 필요 이사으로 힘들다고 말이다. 어쩌면 구조나 설계가 틀렸을 수도 있고, 엉뚱한 문제를 붙들고 있을 수도 있다. 이유가 무엇이든 코드가 보내는 피드백을 파충류의 뇌가 느끼고 있다. 그래서 여러분의 주의를 끌기 위해 필사적으로 노력하는 것이다.

🥕 파충류와 이야기하는 법

여러분의 본능, 여러분의 무의식, 파충류의 뇌에게 귀 기울이고 또 기울이기 바란다. 비법은 언제나 동일하다.

Tip 61. 여러분 내면의 파충류에게 귀 기울여라.

일단, 하고 있는 일을 멈춰라. 여러분의 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보라라. 코드에 대해 생각하지 말고 키보드에서 떨어져서 잠깐 머리를 비운 채로 할 수 있는 일을 하라. 생각이 저절로 여러분의 뇌 층층이 스며들도록 놔둬라. 억지로 쑤셔넣을 수는 없다.

이 방법이 잘 안되면 문제를 표면으로 끄집어내 보라. 작성하는 코드에 대한 그림을 그려 보라. 동료에게 설명해 보라. 그리고 여러분이 어려움을 겪는 부분을 더 잘 처리할 수 있는 부위가 있는지 보라. 우리 둘 중 하나가 이렇게 다른 사람에게 문제를 설명하다가 갑자기 대화가 중단된 적은 그 수를 헤아릴 수 없을 만큼 많다.

하지만 여러분이 이런 방법들을 시도해 보았는데도 여전히 막혀 있을 수도 있다. 행동해야 할 시간이다. 여러분의 뇌에 여러분이 하려는 일은 별 문제가 없다고 알려줘야 한다. 바로 프로토타이핑을 하면 된다.

🥕 놀이 시간이다!

빈 스크린을 마주하고 있다면 프로젝트에서 시도해 보고 싶은 특정한 측면을 찾아보라. 새로운 프레임워크를 사용하고 있다면 데이터 바인딩이 어떻게 일어나는지 보고 싶을 수 있다. 아니면 새로운 알고리즘이 특수한 상황에서는 어떻게 되는지 고찰해 보고 싶을 수 있다.

이미 존재하는 코드 위에서 작업하고 있어서 기존 코드 때문에 문제 해결이 여의치 않다면, 기존 코드를 잠시 다른 곳으로 밀어 두고 비슷한 것을 대신 프로토타이핑으로 만들어라.

1. 포스트잇에 "프로토타이핑 중"이라고 써서 모니터 옆에 붙여라.
2. 프로토타이핑은 원래 실패한다고 자신에게 상기시켜라. 실패하지 않더라도 프로토타이핑은 버리는 것이라는 점도 함께 상기시켜야 한다. 프로토타이핑으로 손해 볼 일은 없다.
3. 텅 빈 에디터 화면에 여러분이 배우고 싶은 것 혹은 하고 싶은 것을 한 문장의 주석으로 표현해 보라.
4. 코딩을 시작하라.

의심이 들기 시작하면 포스트잇을 보라. 꺼림칙했던 느낌이 코딩 도중에 갑자기 명확한 문제로 구체화되면 즉각 해결하라. 실혐이 끝마쳤는데도 여전히 불안한 마음이 들면 다시 처음부터 시작하라. 첫 단계는 산책과 수다, 그리고 휴식이다.

🥕 "여러분"의 코드뿐이 아니다

다른 사람의 코드를 기계적으로 읽으면서 중요해 보이는 대목은 메모해 가며 묵묵히 시간을 투자할 수도 있다. 따분한 일이기는 하지만 가능한 일이다.
아니면 실험을 해 볼 수도 있다. 처리 방식이 이상해 보이는 부분이 눈에 띄면 적어 놓아라. 계쏙 작업하면서 패턴을 찾아보라. 만약 그런 식으로 코드를 작성해야만 했던 원인을 찾아낼 수 있다면 코드를 이해하는 일이 훨씬 더 쉬워질지도 모른다. 다른 사람들이 은연중에 적용한 패턴을 여러분은 의식적으로 적용할 수도 있다. 그 과정에서 여러분이 새로운 것을 배울 수도 있다.

🥕 코드뿐이 아니다

직감에 귀 기울이는 방법은 계속 갈고닦아야 할 중요한 기술이다. 가끔은 설계가 왠지 이상하게 느껴질 수도 있고, 어떤 요구 사항이 마음을 불편하게 할 수도 있다. 하던 일을 멈추고 그 느낌을 분석하라. 여러분의 목소리에 귀를 기울여 주는 환경에 있다면 적극적으로 표현하라. 탐험하라. 어두운 출구에 무언가가 숨어있을 것이다.
본능에 귀를 기울이고 문제가 여러분 앞에 튀어나오기 전에 미리 대처하라.

🍭 Topic 38. 우연에 맡기는 프로그래밍

개발자인 우리는 지뢰밭에서 일한다. 하루에도 수백 개게 넘는 함정이 우리가 빠지기를 기다리고 있다. 우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다. 대신 "의도적으로 프로그래밍"해야 한다.

🥕 우연에 맡기는 프로그래밍 하기

프레드라는 프로그래머에게 할 일이 하나 생겼다고 해 보자. 프레드는 키보드를 두들겨 코드를 약간 작성한다. 시험 삼아 돌려보니 잘 돌아가는 것 같다. 코드를 조금 더 덧붙이고, 또 돌려본다. 이런식으로 몇 주 동안 계속 코딩을 하는데 갑자기 프로그램이 잘 돌아가지 않는다. 몇 시간 동안 고치려고 노력했지만 프레드는 글도 원인을 모른다.

왜 코드가 망가졌는지 프레드가 모르는 까닭은 애초에 코드가 왜 잘 돌아가는지도 몰랐기 때문이다. 프레드가 제한적으로 "테스트"를 했을 때는 코드가 잘 돌아가는 것처럼 보였지만, 그것은 단지 그때 운이 좋았을 뿐이다.

구현에서 생기는 우연

단순히 코드가 지금 작성된 방식이 그렇기 때문에 생기는 우연한 일들이 있다. 이런 우연에 기대다 보면 결국 문서화되지 않은 에러나 예외적인 경우의 동작에 의존하게 되고 만다.

잘 작동하는 데 괜히 건드려서 일을 만들 필요가 있을까? 우리가 보기에는 그래야 할 이유가 몇 가지 있다.

• 정말로 제대로 돌아가는 게 아닐지도 모른다. 그저 돌아가는 듯이 보이는 것일 수도 있다.
• 여러분이 의존하는 조건이 단지 우연인 경우도 있다. 회면 해상도가 다른 경우나 CPU 코어가 더 많은 경우 등 다른 상황에서는 이상하게 작동할지도 모른다.
• 문서화되지 않은 동작은 라이브러리의 다음 릴리즈에서 변경될 수도 있다.
• 불필요한 추가 호출은 코드를 더 느리게 만든다.
• 추가로 호출한 루틴에 새로운 버그가 생길 수도 있다.

다른 사람이 호출할 코드를 작성하고 있다면 모듈화를 잘하는 것, 그리고 잘 문서화한 적은 수의 인터페이스 아래에 구현을 숨기는 것 같은 기본 원칙들이 모두 도움이 된다.

다른 루틴을 호출할 떄도 문서화된 동작에만 의존하라. 어떤 이유로든 그럴 수 없다면 추측을 문서로 상세히 남겨라.

유령 패턴

로그 파일에 요청 1,000개당 한 번꼴로 간헐적으로 발생하는 오류가 남아있다면 분석하기 어려운 경합 조건이 있을 수도 있지만 그냥 오래된 버그일 수도 있다. 테스트가 여러분의 장비에서는 통과했던 것 같은데 서버에서는 통과하지 못하는 이유는 두 환경의 차이 떄문일 수도 있지만 어쩌면 그저 우연일 수도 있다.

가정하리 말라. 증명하라.

상황에서 생기는 우연

여러분은 사용자의 언어가 언제나 한국어이거나 영어일 것이라고 가정하고 있지는 않는가? 언제나 사용자가 글을 읽을 수 있다고 생각하는가? 확실한 것이 아닌데도 의존하고 있는 것은 또 무엇이 있을까?
인터넷 검색으로 찾은 첫 번째 답에서 코드를 복사해 올 때 여러분과 동일한 상황이라고 확신하는가? 아니면 의미는 신경 쓰지 않고 그냥 따라 하는 화물 숭배 코드를 만들고 있나?
잘 되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다.

Tip 62. 우연에 맡기는 프로그래밍을 하지 말라.

암묵적인 가정

우연은 여러 단계에서 우리를 오도할 수 있다. 요구 사항을 만들어내는 단계부터 테스틍에 이르기까지 이 모든 단계에서 말이다. 테스트가 특히 가짜 원인과 우연한 결과로 가득 찬 영역이다. 가정하지 말라. 증명하라

확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다.

🥕 의도적으로 프로그래밍하기

• 언제나 여러분이 지금 무엇을 하고 있는지 알아야 한다.
• 더 경험이 적은 프로그래머에게 코드를 상세히 설명할 수 있는가? 그렇지 않다면 아마 우연에 기대고 있는 것일 터이다.
• 자신도 잘 모르는 코드를 만들지 말라.
• 계획을 세우고 그것을 바탕으로 진행하라.
• 신뢰할 수 있는 것에만 기대라. 가정에 의존하지 말라. 무언가를 신뢰할 수 있을지 판단하기 어렵다면 일단 최악의 상황을 가정하라.
• 가정을 기록으로 남겨라.
• 코드뿐 아니라 여러분이 세운 가정도 테스트해 보아야 한다. 어떤 일이든 추측만 하지 말고 실제로 시험해 보라. 여러분의 가정을 시험할 수 있는 단정문을 작성하라.
• 노력을 기울일 대상의 우선순위를 정하라. 중요한 것에 먼저 시간을 투자하라. 중요한 부분이 가장 어려운 부분이기도 한 경우가 많다.
• 과거의 노예가 되지 말라. 기존 코드가 앞으로 짤 코드를 지배하도록 놓아 두지 말라. 더는 적절한 코드가 아니다 싶으면 어떤 코드라도 교체할 수 있다. 언제나 리팩터링할 자세가 되어있어야 한다. 이런 결정이 프로젝트 일정에 영향을 줄지도 모른다. 그러니 필요한 변경을 하지 않을 경우의 비용보다 일정이 늦어져서 발생하는 비용이 적어야 한다는 것을 염두에 두어라.

🍭 Topic 39. 알고리즘의 속도

🥕 알고리즘을 추정한다는 말의 의미

우리는 반복문이나 재귀 호출을 담고 있는 코드를 작성할 때면 언제나 무의식적으로 수행 시간과 필요한 메모리 양을 계산한다. 정식 계산은 아니고, 주어진 환경에서 우리가 하는 일이 말이 되는지 가볍게 확인해 보는 정도에 가깝다. 하지만 생각보다 훨씬 상세한 분석을 해야 하는 경우도 종종 실제로 있다. 이럴 때 대문제 O 표기법이 유용하다.

🥕 대문자 O 표기법

대문자 O 표기법은 근삿값을 다루는 수학적 방법으로 O()와 같이 표기한다. 어떤 정렬 루틴이 원소 n개를 정렬하는 데 O(n^2^) 시간이 걸린다고 말할 때, 이는 그저 최악의 경우에 걸리는 시간이 n의 제곱에 비례하여 늘어난다고 얘기하는 것이다..

O() 표기법은 우리가 측정하는 값-시간, 메모리 등-의 상한을 기술하는 표기법이다. 예를 들어 어떤 함수가 O(n^2^) 시간이 걸린다고 하면, 이 말은 이 함수가 실행되는 데 걸리는 시간이 최댓값이 n^2^보다 더 빨리 늘어나지 않는 다는 뜻이다.

O(n^2^/2 + 3n)은 O(n^2^/2)와 같고, O(n^2^)과도 같다.

대문자 O 표기법은 수행 시간이든 메모리든, 아니면 다른 무엇을 나타내든 실제 숫자를 알려주지 않는다. 그저 입력의 크기가 바뀜에 따라 이 값이 어떻게 바뀔지를 알려줄 뿐이다.

O() 표기법은 시간에만 국한되지 않는다. 알고리즘이 사용하는 어떤 리소스든 O() 표기법으로 표현할 수 있다. 예를 들어 메모리 사용량을 모델링하는 데에도 유용하다.

🥕 실전에서의 알고리즘 속도

회사에서는 대게 정렬 루틴을 작성하느라 시간을 많이 쓰지 않는다. 이미 나와 있는 라이브러리에 들어 있는 정렬 루틴이 상당한 노력을 들이지 않는 한 대부분 여러분이 작성하는 것보다 성능이 더 나을 것이다.

입력값으로 얼마나 큰 숫자가 올 수 있는지 스스로에게 물어봐야 한다. 만약에 들어올 수 있는 최댓값이 정해져 있다면 그 코드를 실행하는 데 시간이 얼마나 걸릴지 알 수 있다.

Tip 63. 사용하는 알고리즘의 차수를 추정하라.

잠재적인 문제점을 해결하기 위해 생각해 볼 수 있는 방법이 몇 가지 있다. 코드의 실행 시간이 얼마나 될지 또는 메모리를 얼마나 사용할지 확실하지 않다면 직접 실행해 보라. 어떤 일을 하는 코드인지 코드 자체에 대해서도 생각해 보라. 입력값 n이 작을 경우, 단순한 O(n^2^) 코드가 복잡한 O(nlgn) 코드보다 더 좋은 성능을 내기도 한다. O(nlgn) 알고리즘의 반복문 안에 무거운 작업이 들어 있는 경우라면 특히 더 그렇다.

이론적 요인과 실무적 요인을 모두 고려하려고 노력하라. 추정을 이미 했다고 하더라도 실제 서비스에서 실제 데이터로 돌아가는 코드의 수행 시간만이 정말로 의미 있는 수치다. 이 사실에서 우리의 다음 팁이 나온다.

Tip 64. 여러분의 추정을 테스트하라.

최고라고 언제나 최고는 아니다

적당한 알고리즘을 선택할 때도 실용적이어야 할 필요가 있다. 가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다. 입력값의 규모가 작다면 단순한 삽입 정렬도 퀵 정렬과 비슷한 성능을 낸다. 그러나 삽입 정렬을 작성하고 디버깅하는 데 걸리는 시간은 퀵 정렬보다 적다. 여러분이 선택한 일고리즘이 요구하는 형식으로 입력 데이터를 준비하는 데 비용이 많이 드는 것은 아닌지 주의 깊게 보아야 한다.
일벽 데이터의 규모가 작으면 데이터를 준비하는 데 걸리는 시간이 알고리즘을 돌리는 시간보다 오히려 더 길어지는 일이 생기기도 한다. 이렇게 되면 이 알고리즘은 적절한 선택이 아닐 것이다.

그리고 성급한 최적화를 조심하라. 언제나 어떤 알고리즘을 개선하느라 여러분의 귀중한 시간을 투지하기 전에 그 알고리즘이 정말 병목인지 먼저 확인하는 것이 좋다.

🍭 Topic 40. 리팩터링

프로그램이 발전함에 따라 점점 초기에 내린 결정을 다시 고려하고 코드의 일부분을 다시 작성할 일이 생긴다. 코드는 정적인 존재가 아니다. 코드는 발전해야 한다.

리팩터링에서 마틴 파울러는 "리팩터링"을 다음과 같이 정의한다.

밖에서 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법.

이 정의에서 핵심적인 부분은 다음 두 가지다.

1. 이 활동은 체계적이다. 아무렇게나 하는 것이 아니다.
2. 밖으로 드러나는 동작은 바뀌지 않는다. 기는을 추가하는 작업이 아니다.

무질서하게 대규모로 코드를 다시 쓰는 것이 아니라, 정확한 목적을 가지고 정밀하게 접근하는 활동이다. 그래서 코드를 바꾸기 쉽게 유지하는 것이다.
밖으로 드러나는 동작이 바뀌지 않는다는 것을 보장하려면 코드의 동작을 검증하는 좋은 자동화된 단위 테스트가 필요하다.

🥕 리팩터링은 언제 하는가?

리팩터링은 여러분이 무언가를 알게 되었을 때 한다. 여러분이 작년이나 어제, 심지어 10분 전과 비교해서 더 많이 알게 되었다면, 리팩터링을 한다.

어쩌면 코드가 더는 잘 맞지 않아서 장애물에 부딪혔을 떄, 두 가지가 사실은 하나로 합쳐져 있어야 한다는 것을 발견했을 때, 무엇이든 "잘못"되었다는 생각이 들 때가 있을 것이다. 주저하지 말고 변경하라. 언제나 바로 지금이 최적기다. 코드를 리팩터링할 이유는 아주 많다.

중복

• DRY 원칙 위반을 발견했다.

직교적이지 않은 설계

• 더 직교적으로 바꿀 수 있는 무언가를 발견했다.

더 이상 유효하지 않은 지식

• 사물은 변하고, 요구 사항은 변경되며, 지금 처리하고 있는 문제에 대한 여러분의 지식은 점점 늘어난다. 코드는 지금 상황에 뒤떨어지지 않아야 한다.

사용 사례

• 진짜 사람들이 실제 상황에서 시스템을 사용하게 되면, 여러분은 어떤 기능은 예전에 생각했던 것보다 더 중요하고, "꼭 필요하다"고 생각했던 기능은 그렇지 않은 경우도 있다는 것을 깨닫게 될 것이다.

성능

• 성능을 개선하려면 시스템의 한 영역에서 다른 영역으로 기능을 옮겨야 한다.

테스트 통과

• 맞다. 진짜다. 앞에서 설명했듯이 리팩터링은 작은 규모의 할동이고, 좋은 테스트가 뒷받침되어야 한다. 그러니 여러분이 코드를 조금 추가한 후 추가한 테스트가 통과했을 때가, 방금 추가한 코드로 다시 뛰어들어 깔끔하게 정리하기에 최고의 타이밍이다.

여러분의 코드를 리팩터링하는 것 - 기능을 이리저리 옮기고 이전에 내린 결정을 바꾸는 것 - 은 사실 고통 관리를 실천하는 것이다. 현실을 피하지 말자. 소스 코드를 이곳저곳 변경하는 것은 광장히 고통스러운 작업일 수도 있다. 작동하는 코드이니 괜히 긁어 부스럼 만들지 않는 편이 나을 수도 있다. 많은 개발자들이 코드에 조금 개선할 부분이 있다는 이유만으로는 다시 돌아가서 코드 열기를 주저한다.

현실 세계의 복잡한 문제들

일정의 압박은 리팩터링을 하지 않는 단골 핑계다. 하지만 이는 설득력이 떨어진다. 지금 리팩터링을 하지 않으면 일이 더 진척되었을 때, 즉 신경 써야 할 의존성이 더 많아졌을 때 문제를 고쳐야 하고, 따라서 훨씬 더 많은 사긴을 투자해야 한다. 그때가 되면 일정에 더 여유가 생길까? 그럴 리가.

다른 사람에게 이 점을 설명할 때는 병에 비유하면 좋다. 리팩터링이 필요한 코드를 일종의 "종양"이라고 생각하자. 종양을 제거하려면 수술이 필요하다. 지금 바로 수술해서 아직 종양이 작을 때 제거할 수도 있다. 아니면 종양이 자라고 다른 곳으로 전이할 때까지 놓아둘 수도 있다. 하지만 그때가 되면 제거하는 데 드는 비용도 더 늘어날뿐더러 위험도 훨씬 커진다. 시간을 더 끌면 환자는 생명을 잃을지도 모른다.

Tip 65. 일찍 리패터링하고, 자주 리팩터링하라.

대부분의 일처럼 리팩터링도 문제가 작을 때, 코딩하는 동안 함꼐 진행하는 편이 더 쉽다. 코드 한 부분 떄문에 "리팩터링만 하는 일주일"이 필요해서는 안 된다. 그건 완전 재작성이다. 만약 이 정도로 시간이 많이 필요하다면 즉시 해치울 수 없는 것도 당연하다. 그 대신 일정에 리팩터링할 시간을 확실히 포함시켜 두도록 하라. 그 코드를 시용하는 사람들이 코드가 조만간 재작성될 것이라는 사실과 재작성이 그들의 코드에 미칠 영향이 인지하도록 해야 한다.

🥕 리팩터링은 어떻게 하는가?

리팩터링의 본질은 재설계다. 여러분 또는 여러분 팀의 다른 사람이 설계한 모든 것은 새로운 사실이 밝혀지거나, 문제에 대한 이해가 더 깊어지거나, 요구 사항이 바뀐다면 언제라도 재설계의 대상이 될 수 있다. 하지만 그렇다고 거대한 규모의 코드를 닥치는 대로 헤집어 놓으면, 나중에는 리패터링 전보다 더 안 좋은 처지에 놓일지도 모른다.

분명히 리팩터링은 천천히, 신중하게, 조심스럽게 진행해야 하는 작업이다. 마틴 파이룰러는 오히려 손해 보는 일이 없도록 리팩터링 하는 방법에 대하여 몇 가지 간단한 조언을 해 주었다.

1. 리팩터링과 기능 추가를 동시에 하지 말라.
2. 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라. 할 수 있는 한 자주 테스트를 돌려 보라. 이렇게 하면 여러분이 바꾼 것 떄문에 무언가 망가졌을 경우 그 사실을 재빨리 알 수 있다.
3. 단꼐를 작게 나누어서 신중하게 작업하라. 클래스의 필드 하나를 다른 클래스로 옮기기, 메서드 하나 쪼개기, 변수명 하나 바꾸기 같이 작은 단위로 작업해야 한다. 단꼐를 작게 나누고, 한 단께가 끝날 때마다 테스트를 돌린다면 기나긴 디버깅 작업을 피할 수 있다.

마틴 파울러가 한 조언의 핵심은 탄탄한 회귀 테스트를 유지하는 것이야말로 안전한 리팩터링의 비결이라는 것이다.

리팩터링만으로는 부족해서 결국 외부에서 보이는 동작이나 API를 바꿔야 한다면, 일부러 빌드를 깨트려 보는 것이 유용할 수도 있다. 리팩터링 대상 코드에 의존하는 옛날 코드들은 컴파일이 안 되게 만드는 것이다. 이렇게 하면 고쳐야 하는 부분이 어디인지 알아낼 수 있다. 다음에 여러분이 기대하는 수준에 못 미치는 코드를 발견하면, 고쳐라. 고통을 관리하라. 지금은 고통스러울지라도 앞으로 더욱 고통스러워질 것 같으면 지금 고치는 편이 낫다.

🍭 Topic 41. 테스트로 코딩하기

개발자들에게 왜 테스트를 쓰냐고 물어보면 우리가 천공 카드에 코딩하냐고 물어본 것처럼 우리를 처다본다. 그러고는 "우리 코드가 잘 작동하는지 확이하려는 거죠."라고 대답한다. 말끝에 차마 입에 담지 못한 "바보같이"가 들리는 것이다. 하지만 우리는 이 대답이 틀렸다고 생각한다.

그렇다면 우리가 생각하는 테스트의 중요한 가치는 무엇일까? 여러분은 왜 테스트를 해야 한다고 생각하는가?

Tip 66. 테스트는 버그를 찾기 위한 것이 아니다.

우리는 테스트의 주요한 이득이 테스트를 실행할 때가 아니라 테스트에 대해 생각하고, 테스트를 작성할 때 생긴다고 믿는다.

🥕 테스트에 대해 생각하기

일단 함수를 작성했다고 가정해 보자. 이제 테스트를 해야 한다. 어떻게 해야 할까? 일단 테스트 데이터를 사용해야 할 것이다. 아마 여러분이 관리하는 데이터베이스를 연결할 것이다.

def return_avid_users(db) do

그다음으로는 어떻게 테스트 데이터를 채울지 생각해야 한다. 요구 사항은 "한 주에 동영상을 10개 넘게 보는 사람 목록"이다. 테스트 데이터를 작성하려면 어떤 필드르 쓸지 알아야 한다. 하지만 우리는 요구 사항이 정확하게 무엇을 의미하는지 모르고 사업 부서 담당자는 연락이 안 된다. 필드 이름을 매개 변수로 넘기는 꼼수를 쓰자. 그러면 일단 현재 코드의 테스트가 가능하다. 필요하면 나중에 바꾸면 될 것이다.

def return_avid_users(db, qualifying_fields_name) do

테스트에 대해 생각하는 것으로 시작했는데 코드 한 줄 쓰지 않고도 두 가지를 발견했다. 그리고 이를 바탕으로 우리 메서드의 API를 변경했다.

🥕 테스트가 코딩을 주도한다

이전 예에서 테스트에 대해 생각함으로써 우리 코드의 결합도는 낮추고 유연성은 올릴 수 있었다. 우리 메서드의 테스트 작성에 대해 생각함으로써 코드의 작성자가 아니라 사용자인 것처럼 메서드를 외부의 시선으로 보게 되었다.

Tip 67. 테스트가 코드의 첫 번째 사용자다.

이것이 테스트가 주는 가장 큰 이득일지 모른다. 테스트는 우리의 코딩을 인도하는 필수 피드백이다.
다른 코드와 긴밀하게 결합된 함수나 메서드는 테스트하기 힘들다. 메서드를 실행하기도 전에 온갖 환경 구성을 한참 해야 하기 때문이다. 즉, 무언가를 테스트하기 좋게 만들면 결합도도 낮아진다.

게다가 무언가를 테스트하려면 그것을 이해해야만 한다. 코딩을 시작하기 전에 경계 조건의 테스트와 경계 조건에서 어떻게 동작해야 하는지를 먼저 생각해본다면, 아마 함수를 단순하게 만드는 코드 패턴을 찾을 수 있을 것이다. 테스트해야 하는 오류 조건에 대해 생각해 본다면 그에 맞게 함수 구조를 잡을 것이다.

테스트 주도 개발

테스트를 먼저 생각하는 것의 이점이 이렇게 많다 보니 아예 테스트를 먼저 작성하자고 주장하는 프로그래밍 유파도 있다. 그들은 "테스트 주도 개발(TDD)"이라고 부르는 기법을 사용한다. 테스트 우선 개발이라고 부르기도 한다.

TDD의 기본 주기는 다음과 같다.

1. 추가하고 싶은 작은 기능 하나를 결정한다.
2. 그 기능을 구현되었을 때 통과하게 될 테스트를 하나 작성한다.
3. 테스트를 실행한다. 다른 테스트는 통과하고 방금 추가한 테스트 딱 하나만 실패햐아 한다.
4. 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성한다. 그리고 이제 모든 테스트가 통과하는지 확인한다.
5. 코드를 리팩터링한다. 방금 작성한 테스트나 함수를 개선할 수 있는 부분이 없는지 살펴본다. 개선한 후에도 테스트가 계속 통과하는지 확인한다.

TDD 발상의 핵심은 이 반복 주기가 기껏해야 몇 분 정도로 매우 짧아야 한다는 것이다. 따라서 끊임없이 테스트 작성과 테스트를 통과하게 만들기를 반복하게 된다. TDD 작업 방식을 따르면 여러분의 코드는 언제나 테스트가 있을 수밖에 없다. 그리고 이는 언제나 테스트에 대해 생각하게 된다는 의미다.
하지만 우리는 TDD의 노예가 된 사람들도 보았다. 다음과 같은 징후로 알아볼 수 있다.

• 늘 테스트 커버리지 100%를 달성하기 위해 과도하게 많은 시간을 투자한다.
• 많은 수의 중복 테스트가 생긴다. 예를 들어 많은 TDD 지지자들은 크래스를 처음으로 작성하기 전에 단순히 클래스 이름만 참조해서 실패하는 테스트를 만든다. 테스트가 실패하고 나면 그제야 빈 클래스 정의를 작성하고, 테스트가 통과하게 된다. 하지만 이제 그 테스트는 아무 일도 하지 않는 테스탁 되고 만다. 다음으로 작성하는 테스트도 당연히 클래스를 참조할 것이므로 첫 번째 테스트는 불필요해진다. 나중에 클래스 이름을 바꿔야 하는 곳만 많아질 뿐이다. 그리고 이건 중복 테스트의 사소한 예일 뿐이다.
• 밑에서부터 시작하여 위로 올라가는 방식으로 설계를 한다.

어떻게든 TDD를 실천하라. 하지만 도중에 이따금 멈추어 큰 그리을 살피는 것을 잊지 말라. 초록색 "테스트 통과" 메시지에 중독된 나머지 진짜 문제 해결에는 보탬이 안되는 코드를 한 무더기나 쓰게 되기 쉽다.

🥕 TDD: 목표가 어디인지 알아야 한다

전체 문제를 완전히 파악하기 힘들 때 한 번에 테스트 하나씩 작은 단계들을 밟는 것이다. 하지만 이런 접근 방법이 여러분을 잘못된 길로 인도할 수 있다. 코딩을 하는 진짜 이유는 무시한 채 계속해서 쉬운 문제들만 만지작거리도록 유도할 수 있다.

상향식 대 하향식, 그리고 여러분이 따라야 하는 방식
상향식 하향식 둘 다 소프트웨어 개발의 가장 중요한 측면을 놓치고 있다. 바로 개발을 처음 시작할 때는 우리가 무엇을 하고 있는지 모른다는 것이다. 하향식 설계는 전체 요구사항을 시작할 때 다 알고 있다고 가정하지만 사실은 알 수 없다. 상향식 설계는 추상화 계층을 쌓다 보면 결국에는 하나의 최상위 해결 계층에 도착할 것이라고 가정하지만, 목표가 어디인지 모르는데 어떻게 각 계층의 기능을 결정할 수 있단 말인가?
Tip 68. 상향식이나 하향식이 아니라 끝에서 끝까지(end to-end) 만들어라.
우리는 소프트웨어를 만드는 유일한 방법이 점진적인 방법이라고 굳게 믿는다. 한쪽 끝과 다른 쪽 끝을 잇는 조그만 기능 조각들을 만들고, 그 과정에서 문제에 대하여 배워라. 코드를 채워 나가면서 배운 것을 적용하고, 각 단계마다 고객을 참여시켜서 전체 과정을 안내하도록 하라.

🥕 다시 코드로

소프트웨어를 만들 때 맨 처음부터 테스트가 가능하도록 만들고, 코드들을 서로 연결하기 전에 코드를 하나하나 철저하게 테스트해야만 한다.

🥕 단위 테스트

소프트웨어 단위 테스트란 일종의 인위적인 환경을 구축한 다음, 테스트할 모듈의 루틴들을 호출한다. 그런 다음 반환된 결과들을 이미 알고 있는 값과 비교해 보거나 똑같은 테스트를 이전에 돌렸을 때 나온 값과 비교하여 올바른지 검사한다. 동일한 테스트를 코드 수정 후 다시 돌려보는 것을 회귀 테스트라고 한다.

🥕 계약을 지키는지 테스트하기

우리는 단위 테스트를 계약을 잘 지키는지 보는 테스트라고 여긴다. 우리는 어떤 코드 단위가 자신이 맺은 계약을 지키는지 확인하는 테스트 케이스를 작성하고자 한다. 이런 테스트는 우리에게 두 가지를 알려준다. 하나는 코드가 계약을 지키는지 여부고, 다른 하나는 코드로 표현된 계약의 의미가 우리가 생각한 것과 일치하는지 여부다. 우리는 다양한 종류의 테스트 케이스와 경계 조건에서도 모듈이 약속한 대로 기능을 잘 수행하는지 테스트하고 싶다.

어떤 모듈이 있을 떄 그 모듈의 하위 컴포넌트들을 먼저 테스트하는 방식이다. 하위 컴포넌트들을 모두 검증한 후에야 해당 모듈을 테스트할 수 있다. 만약 DataFeed와 LinearRegression은 테스트를 통과하는데 테스트를 통과하지 못했다면, 문제가 있거나 아님 하위 컴포넌트를 사용하는 방식에 있다고 거의 확신할 수 있따. 이 기법은 디버깅에 들어가는 노력을 줄여 주는 멋진 방법이다.

왜 이렇게 번잡한 일을 하는 것일까? 무엇보다도 "시한폭탄", 즉 문제가 프로젝트에서 알려지지 않은 채로 숨어 있다가 나중에 곤란한 시점에 터져 버리는 일을 피하고 싶어서다. 계약을 잘 지키는지 확인하는 테스트를 강조함으로써 프로젝트에서 이후에 벌어질지 모를 재앙을 피하려고 노력하는 것이다.

Tip 69. 테스트할 수 있도록 설계하라.

🥕 임시 테스트

임시(Ad-hoc) 테스트는 우리가 직접 코드를 이리저리 찔러보는 것이다. console.log() 한 줄일 수도 있고, 디버거나 IDE 환경, REPL에 직접 실행하면서 입력하느 코드 조각일 수도 있다.

디버깅 작업이 끝나면 이런 임시 테스트를 정식 테스트의 형태로 만들어두어야 한다. 한 번 잘못된 코드라면 다시 잘못될 가능성이 높다. 여러분이 만든 테스트를 그냥 버리지 말고 기존의 단위 테스트 군단에 합류시켜라.

🥕 테스트 접점 만들기

아무리 테스트를 잘 갖추었어도 모든 버그를 발견할 수는 없다.

이 말은 소프트웨어를 배포한 후에도 테스트할 일이 자주 생긴다는 것이다. 이때 소프트웨어를 배포한 후에도 테스트할 일이 자주 생긴다는 것이다. 어떤 모듈의 내부 상태를 디버거 없이 다양한 형태로 볼 수 있는 방법을 제공할 수도 있다.
로그 파일에 쌓이는 추적 메시지가 이런 메커니즘 가운데 하나다. 로그 메시지는 반드시 규칙적이고 일관된 형식이어야 한다.

실행 중인 코드의 내부로 들어갈 수 있는 또 다른 메커니증므로 단축키 조핳ㅂ이나 숨겨진 URL 방식이 있다. 어떤 특정한 키 조합을 누르거나 특정 URL에 접속하면, 상태 정보와 그 외의 것들이 들어 있는 진단 제어 창이 열리게 만드는 것이다.

더 일반적으로는 기능 스위치를 활용하여 특정 사용자나 사용자 집단에 대해서는 진단 메시지를 더 많이 남기도록 할 수도 있다.

🥕 테스트 문화

여러분이 작성하는 모든 소프트웨어는 언젠가는 테스트된다. 여러분이나 여러분의 팀이 테스트하지 않으면 결과적으로 사용자들이 테스트하게 된다. 그러니 소프트웨어를 철저하게 테스트할 계획을 세우는 것이 좋다.

여러분에게 있는 선택지는 그리 많지 않다. "테스트 먼저", "코드와 테스트를 함께", "테스트하지 않음" 셋 중 하나다.

"테스트 먼저"가 대부분의 상황에서 최상의 선택일 것이다. 테스트를 할 수 밖에 없기 때문이다. 테스트 주도 설계도 여기에 포함된다. 하지만 때에 따라 테스트를 먼저 쓰기가 어렵거나 의미가 없을 수도 있다. 그렇다면 "코드와 테스트를 함꼐"가 대안이 될 수 있다. 코드를 조금 작성하고, 이리저리 만지작저리다가 테스트를 작성하라. 그리고 다시 코드로 넘어간다. 최악의 선택은 흔히들 "나중에 테스트"라고 부르는 것인데, 완전 헛소리다. "나중에 테스트"는 사실 "테스트하지 않음"이란 뜻이다.

제대로 된 테스트 문화를 가졌다면 모든 테스트가 언제나 통과해야 한다.
"언제나 실패"하는 불량 테스트를 무시하다 보면 모든 테스트를 무시하게 되기 쉽다. 그리고 악순환의 고리가 시작된다.

테스트 코드를 다른 제품 코드와 마찬가지로 다뤄라. 결합도를 낮추고, 꺠끗하고 견고하게 유지하라. GUI 시스템의 위젯 위치나 서버 로그에 찍힌 현재 시간, 에러 메시지의 문구처럼 신뢰할 수 없는 것에 의존하지 말라. 이런 종류의 것을 테스트하면 테스트가 더 잘 깨지게 된다.

Tip 70. 여러분의 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 된다.

명심하라. 테스트는 프로그래밍의 일부다. 다른 사람이나 다른 부서에 떠넘길 수 있는 것이 아니다.
테스트, 설계, 코딩, 이 모든 것이 프로그래밍이다.

고백
나 데이브는 사람들에게 더는 테스트를 쓰지 않는다고 말해 왔다. 테스트를 종교처럼 떠받드는 사람들의 믿음을 흔들기 위한 것도 있고, 또 어느 정도는 테스트를 쓰지 않는 것이 사실이기 때문이기도 하다.
나는 45년간 코딩을 해 왔고, 30년 넘게 늘 자동화 테스트를 써 왔다. 코딩을 시작할 때면 자연스럽게 테스트에 대해 생각한다. 아주 편안하게 느껴진다. 그리고 나느 ㄴ무언가가 편안하게 느껴지면 또 다른 시도를 해 봐야 하는 천성을 타고났다.
그래서 나는 몇 달 전 테스트 쓰기를 그만두고 내 코드에 무슨 일이 벌어지는지 한번 보기로 했다. 놀랍게도 변화는 "크지 않았다." 그래서 왜 그런지 곰곰이 생각해 보았다.
내 생각에 나에게 있어 테스트의 이득은 대부분 테스트에 대하여, 그리고 테스트가 코드에 주는 영향에 대하여 고민하는 과정에서 생기는 듯 하다. 그리고 꽤 오래 이 일을 해 오다보니 실제로 테스트를 쓰지 않고도 테스트에 대해 생각할 수 있게 되었다. 내 코드는 여전히 테스트하기 쉽다. 아직 테스트하지 않았을 뿐이다.
하지만 이런 관점은 테스트가 다른 개발자와 소통하는 수단이기도 하다는 측면을 무시한 것이다. 그래서 이제는 다른 사람들과 공유하는 코드 혹은 외부 라이브러리의 어떤 특성에 의존하는 코드만 테스트를 작성한다.
앤디는 이 상자의 내용을 싣지 말자고 했다. 경험이 부족한 개발자들이 괜히 따라서 테스트를 쓰지 않을까 봐 걱정이라는 것이다. 그래서 나의 타협안은 다음과 같다.
여러분이 테스트를 써야 할까? 그렇다. 하지만 테스트 작성 경험이 30년 정도 쌓였다면 테스트가 어떤 면에서 도움이 되는지 직접 실험을 해 봐도 좋을 것이다.

🍭 Topic 42. 속성 기반 테스트

🥕 계약, 불변식, 속성

선행 조건에 맞추어 입력을 넣으면 코드가 생산하는 출력이 주어진 후행 조건에 맞음을 보장해 준다.

불변식이라는 것도 있었는데, 함수 실행 전후로 계속 어떤 부분의 상태에 대하여 참이 되는 조건을 말한다. 코드에 존재하는 계약과 불변식을 뭉뚱그려서 속성이라고 부른다. 코드에서 속성을 찾아내서 테스트 자동화에 사용할 수 있는데, 이것을 속성 기반 테스트(property-based testing)라고 한다.

Tip 71. 속성 기반 테스트로 가정을 검증하라.

인위적인 예를 하나 생각해 보자면 리스트 정렬 기능의 테스트를 만들 수 있다. 정렬된 리스트는 원래 리스트와 길이가 같다. 정렬된 리스트에서 모든 원소는 다음 원소보다 클 수 없다는 속성도 추가할 수 있다.

from hypothesis import given
import hypothesis.strategies as some

@given(some.lists(some.integers()))
def test_list_size_is_invariant_across_sorting(a_list):
  original_length = len(a_list)
  a_list.sort()
  assert len(a_list) == original_length

@given(some.lists(some.text()))
def test_sorted_result_is_ordered(a_list):
  a_list.sort()
  for i in range(len(a_list) - 1):
    assert a_list[i] <= a_list[i + 1]

예상 가능한 결과다. 하지만 보이지 않은 곳에서 hypothesis는 우리 테스트를 백 번씩이나 돌렸다. 리스트의 길이도 바꾸고 내용도 바꿔 가면서 매번 다른 리스트를 입력으로 넘겼다.

🥕 속성 기반 테스트는 우리를 자주 놀래킨다

속성 기반 테스트가 강력한 까닭은 그저 입력을 생성하는 규칙과 출력을 검증하는 단정문만 설정한 채 제멋대로 작동하도록 놔두기 떄문이다. 정확히 어떤 일이 일어날지 절대 알 수 없다. 테스트가 통과할 수도, 단정문이 실패할 수도 있다. 아니면 코드가 주어진 입력을 제대로 처리하지 못하고 중간에 멈춰버릴 수도 있다.

좌절감은 정확히 무엇이 실패했는지 찾아내기 까다로울 수도 있다는 것이다. 속성 기반 테스트가 실패했다면 테스트 함수가 어떤 매개 변수를 사용했는지 알아낸 다음 그 값을 이용하여 별도의 단위 테스트를 정식으로 추가하는 것이 좋다. 이 단위 테스트는 두 가지 역할을 한다. 첫 번째는 속성 기반 테스트의 여러 가지 다른 수행 결과와 상관없이 문제가 발생하는 상황에 집중할 수 있게 해 준다. 두 번째는 단위 테스트가 "회귀 테스트" 역할을 한다.
속성 기반 테스트는 임의의 값을 생성하여 사용하기 때문에 다음번에 실행했을 때 똑같은 값을 테스트 함수에 넘긴다는 보장이 없다. 무제를 일으켰던 값을 사용하는 단위 테스트를 만들어 두면 버그가 완전히 해결되었음을 보장할 수 있다.

🥕 속성 기벤 테스트는 설계에도 도움을 준다

단위 테스트의 주요 장점 중에 코드에 대해 생각하게 만드는 것이 잇다고 설명했었다. 단위 테스트가 여러분이 만드는 API의 첫 번째 고객이라고 했다.

속성 기반 테스트는 여러분이 코드를 불변식과 계약이라는 관점으로 바라보게 한다. 여러분은 무엇이 변하지 않아야 하고, 어떤 조건을 만족해야 하는지 생각하게 된다. 이런 관점으로 보면 코드에 마법과 같은 효과가 일어난다. 경계 조건은 줄어들고, 데이터의 일관성을 해치는 함수는 더 도드라진다.

우리는 속성 기반 테스트가 단위 테스트를 보완한다고 믿는다. 둘은 서로 다른 문제를 해결하고 각각의 장점이 있다. 둘 중에 사용하지 않는 것이 있다면 한번 시도해 보라.

🍭 Topic 43. 바깥에서는 안전에 주의하라

🥕 나머지 90%

고된 오르막길을 오르는동안 고비와 난관을 여럿 거치고나면 자신에게 이렇게 말하기 일쑤다. "휴, 이제 된다!" 그러고는 코드가 완성되었음을 선포한다. 물론 아직 완성되지 않았따. 여러분은 90% 완성한 것이다. 하지만 이제 나머지 90%를 고려해야 한다.

여러분이 다음으로 해야 하는 일은 코드가 잘못될 수 있는 경우를 찾아보고, 각 경우에 대한 단위 테스트를 추가하는 것이다. 잘못된 매개 변수를 넘기거나 리소스를 흘리거나 리소스가 모자라는 경우 따위를 생각해 보아야 한다.

내부에서 발생하는 오류뿐 아니라 외부에서 시스템을 망가트리려 하는 시도까지 고려해야 한다. 조용히 숨어 있는 것으로 보안을 대신하려는 생각은 통하지 않는다.

🥕 기본 보안 원칙

우리는 우리가 실수도 하고 한계도 있다는 것을 안다. 외부의 공격자가 우리가 남겨 놓은 어떤 틈이든 벌리고 들어와 시스팀을 망가트리려 할 것도 안다. 개발하고 배포하는 환경에 따라 제각각 보안을 위해 해야 할 일들이 있겠지만, 우리가 언제나 명심해야 하는 기본 원칙이 몇 가지 있다.

1. 공격 표면을 최소화하라.
2. 최소 권한 원칙.
3. 안전한 기본값.
4. 민감 정보를 암호화하라.
5. 보안 업데이트를 적용하라.

공격 표면을 최소화하라

시스템의 공격 표면 영역은 공격자가 데이터를 입력하거나, 데이터를 추출하거나 서비스를 실행시킬 수 있는 모든 접근 지점을 합한 것이다.

• 코드의 복잡성은 공격 매개체를 유발한다. 복잡한 코드는 예상 외의 부작용이 일어날 확률을 높이고, 결과적으로 공격 표면을 넓힌다.

• 입력 데이터는 공격 매개체다. 외부의 데이터를 절대 신뢰하지 말라. 데이터베이스나 화면 렌더링, 그 밖의 다른 처리 루틴에 전달하기 전에 언제나 나쁜 내용을 제거하라.

• 인증이 없는 서비스는 공격 매개체다. 본질적으로 인증이 없는 서비스는 전 세계 누구든지 호출할 수 있다. 따라서 별도로 처리하거나 제한을 두는 조치를 하지 않으면 최소한 "서비스 거부 공격, DoS"은 가능해진다.

• 인증을 요구하는 서비스도 공격 매개체다. 인증 받은 사용자의 수를 언제나 최소로 유지하라. 쓰이지 않거나, 오래되고, 유효하지 않은 사용자나 서비스를 정리하라.

• 출력 데이터는 공격 매개체다. 정보를 누설하지 말라. 응답에 들어 있는 데이터가 사용자의 권한에 적절한지 늘 확인하라. 주민 등록 번호나 다른 신원 정보처럼 위험도가 높은 정보는 일부만 노출하거나 알아볼 수 없게 변형하라.

• 디버깅 정보는 공격 매개체다. 테스트 접점 만들기이나 실행 시점 예외 정보가 훔쳐보는 이들의 눈에 띄지 않도록 잘 보호하라.

Tip 72. 단순함을 유지하고 공격 표면을 최소화하라.

최소 권한 원칙

최소한의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라는 게 또다른 핵심 원칙이다. 다시 말하자면 아무 생각 없이 root나 Administrator 같은 최고 수준 권한을 사용하지 말라는 것이다.

이 기법은 공격 표면을 최소화한다는 발상과도 일맥상통한다. 시간과 권한 차원에서 공격 매개체의 유효 범위를 줄이는 것이다. 권한이야말로 "적을수록 낫다."

안전한 기본값

여러분의 애플리케이션 혹은 웹 사이트 사용자의 기본 설정은 가장 안전한 값이어야 한다. 가장 안전한 값이 가장 사용자 친화적인 값이나 편리한 값은 아닐 수 있겠지만, 각 사용자가 직접 보안과 편리함 사이에서 고르도록 하는 편이 낫다.

민감 정보를 암호화하라

개인 식ㅂ졀 정보나 금융 데이터, 비밀번호, 다른 인증 정보를 일반 텍스트로 남기지 말라. 데이터베이스든 다른 파일이든 동일하다. 실제 데이터가 유출되더라도 암호가 안전장치 역할을 할 수 있어야 한다.

암호나 API키, SSH 키, 암호화 비밀번호, 그 밖의 다른 인증 정보를 소스 코드용 버전 관리 시스템에 넣지 말라.
키나 암호는 다른 방법으로 관리해야 한다. 보통 빌드나 배포 프로세스 내에서 설정 파일이나 환경 변수로 관리한다.

보안 업데이트를 적용하라

보안 패치는 물론 필요하지만, 패치의 부작용으로 여러분 애플리케이션의 일부가 망가진다. 여러분은 일단 기다리기로 하고 업데이트를 나중으로 미룰지도 모른다. 하지만 끔찍한 생각이다. 이제 여러분의 시스템은 알려진 공격 방법으로 뚫릴 수 있다.

Tip 73. 보안 패치를 신속히 적용하라.

이 팁은 인터넷에 연결된 모든 장비에 해당된다. 꼭 업데이트를 해야 하나 싶은 생각이 든다면, 지금까지 발생한 데이터 유출 사고 중 가장 큰 사고는 업데이트를 하지 않은 시스템 떄문에 발생했다는 사실만 기억하기 바란다.

🥕 상식 대 암호

암호학에 있어서는 여러분의 상식이 맞지 않을 수 있다는 점을 명심해야 한다. 암호화에 있어서 첫 번째 규칙이자 가장 중요한 규칙은 절대 직접 만들지 말라는 것이다. 비밀번호처럼 간단한 것마저도 일반적인 관행이 틀렸을 수 있다.

여러분이 만든 기발한 수제 암호화 알고리즘은 전문가가 몇 분 내로 풀어 버릴 것이다. 엄호화는 직접 하지 않는 편이 낫다.

신뢰할 수 있는 것에만 의지하라. 많이 검토하고, 철저하게 검사하고, 잘 유지 보수되며 자주 업데이트되는 라이브러리와 프레임워크를 사ㅏ용하라. 가급적 오픈 소스가 좋다.

간단한 암호화 작업 외에도 여러분의 웹 사이트나 애플리케이션의 보안 관련 기능을 주의 깊게 검토하라.
아니면 실용주의적 접근 방법을 선택하여 다른 사람이 대신 고민하도록 할 수도 있다. 외부의 인증 서비스를 사용하는 것이다. 여러분의 조직 내에서 운영하는 인증 서비스를 함께 사용할 수도 있고, 외부 클라우드가 제공하는 것을 사용할 수도 있다.

🍭 Topic 44. 이름 짓기

프로그래밍에서는 이름이 "모든 것!"이다.

우리는 이름을 붙인다. 애플리케이션, 서브시스템, 모듈, 함수, 변수 등 새로운 것을 끊임없이 만들고 그것에 이름이 부여한다. 그리고 아주아주 중요하다. 이름은 여러분의 의도와 믿음을 잔뜩 드러내기 때문이다.

우리는 코드에서 하는 역할을 따라 이름을 지어야 한다고 믿는다. 이 말은 무언가를 말들 때마다 잠시 멈춰서 "내가 이것을 왜 만드는 거지?"하고 생각해야 한다는 뜻이다.

변수나 함수의 역할을 고려하려면 그 변수나 함수가 무엇이 특별한지, 무엇을 할 수 있는지, 무엇과 상호작용하는지를 생각해야만 한다.

이름을 지을 떄는 여러분이 표현하고 싶은 것을 더 명확하게 다듬기 위해 끊임없이 노력해야 한다. 이렇게 명확하게 다듬는 작업이 여러분이 코드를 작성할 때 코드를 더 잘 이해할 수 있도록 도울 것이다.
하지만 모든 이름은 문학상 후보에 올라야 하는 것은 아니다.

🥕 문화를 존중하라

컴퓨터 과학에는 어려운 문제가 딱 두 개 있다. 캐시 무효화와 이름 짓기.

대부분의 컴퓨터 입문용 교재는 i, j, k 같은 한 글자 변수명을 절대 사용하지 말라고 강조한다.
우리는 이런 견해가 조금은 틀렸다고 생각한다.

사실 이는 각 프로그래밍 언어나 환경의 문화에 달린 것이다. C 프로그래밍 언어에서 i, j, k는 전통적으로 반복문에서 증가하는 변수로 쓰여 왔다. 이런 환경에서 프로그래밍한다면 이런 코드와 계쏙 맞닥트리게 될 것이고, 이 관습을 어긴다면 문제가 될 - 그리고 아마 클린 것일 - 수 있다. 반면에 이런 관습이 없는 환경이라면 당연히 한 글지 변수명을 사용하면 안 된다.

어떤 언어 사용자들은 이름 가운데에 대문자를 넣는 낙타 표기법(camelCase)을 선호하고, 다른 언어 사용자들은 밑줄로 단어를 구분하는 뱀 표기법(snake_case)을 선호한다. 언어 자체의 문법에선 어느 쪽이든 상관없다고 하더라도 아무것이나 쓰면 안 된다. 그 분야의 문화를 존중하라.

어떤 언어는 이름에 일부 유니코느 문자를 허용하기도 한다.

🥕 일관성

모든 프로젝트에는 팀 내에서 특별한 의미가 있는 용어들을 비롯하여 고유의 어휘들이 있다. "Order"가 온라인 상점을 만드는 팀에게는 "주문"이겠지만, 종교 단체의 역사를 보여주는 앱을 만드는 팀에게는 "교단"을 의미할 것이다.
반드시 탐의 모든 사람이 각 단어의 뜻을 알고 일관성 있게 사용해야 한다.

한 가지 방법은 많은 의사소통을 장려하는 것이다. 모든 사람이 짝 프로그래밍을 하고 자주 짝을 바꾼다면 용어의 의미는 자연스럽게 퍼져 나갈 것이다. 팀에게 특별한 의미가 있는 단어를 모두 모은 프로젝트 용어 사전을 만드는 방법도 있다. 이 문서에 따로 형식을 정해 둘 필요는 없다.

시간이 흐르다 보면 프로젝트 용어들은 자리를 잡아 나갈 것이다. 모든 사람이 어휘에 익숙해지면 짧은 단어를 말하는 것만으로도 많은 의미를 정확하고 짧게 전달할 수 있게 된다.

🥕 이름 바꾸기는 더 어렵다

컴퓨터 과학에는 어려운 문제가 딱 두 개 있다. 캐시 무효화, 이름 짓기, 그리고 하나 차이(off-by-one) 오류.

아무리 좋은 이름을 짓기 위해 노력하더라도 모든 것은 변한다. 코드는 리팩터링되고, 사용 방식은 바뀌고, 의미는 미묘하게 달라진다. 부지런히 이름을 계속 바꾸지 않으면 악몽 같은 상황에 빠지게 된다. 무의미한 이름보다 더 고약한 잘못된 이름을 사용하는 코드가 되는 것이다.

문제를 발견했으면 고쳐라. 당장 바로 그 자리에서. 의도를 제대로 표현하지 못하거나 오해를 부를 수 있거나 헷갈리는 이름을 바견했다면 고쳐야 한다. 혹시 이름 바꾸는 것을 뺴먹은 곳이 있더라도 회귀 테스트가 있으니 여러분의 실수를 발견해 줄 것이다.

Tip 74. 이름을 잘 지어라. 필요하면 이름을 바꿔라.

잘못된 이름을 바꿀 수 없는 상황이라면 더 큰 문제가 있는 것이다. 바로 ETC 위반이다. 그 문제를 고치고 나서 잘못된 이름을 바꿔라. 아름을 바꾸기 쉽게 만들고, 자주 이름을 바꿔라.

그렇지 않으면 팀에 새로운 사람이 올 때마다 시치미를 뚝 떼고 getData가 사실은 데이터를 파일에 쓴다는 것을 설명해야 할 것이다.