"해커와 화가"에서 일하는 방식으로 가져온 것들

좋은 책이라길래 읽어봤다

처음에는 좋은 책이라는 이야기를 많이 들어서 읽었습니다.

폴 그레이엄이라는 이름도 자주 보였고, Lisp나 스타트업 이야기도 개발자 커뮤니티에서 종종 들렸습니다. 그래서 궁금했습니다. 이 책에서 말하는 내용 중에 지금 내가 일하는 방식에 가져올 만한 것이 있을까.

읽기 전에는 기술 책에 가까울 거라고 생각했습니다. 그런데 막상 읽어보니 문법이나 아키텍처를 설명하는 책이라기보다, 만드는 사람의 태도에 대한 에세이에 가까웠습니다.

그때는 PHP 코드베이스 위에 Rails식 컨벤션을 녹이거나, 테스트 fixture를 만들거나, 웹 서비스의 배포와 수정 흐름을 고민하던 시기였습니다. 책에서 말하는 Lisp나 스타트업 이야기를 그대로 따라 할 수는 없었지만, “이걸 우리 코드와 팀의 일하는 방식에 대입하면 무엇이 남을까”라는 질문은 계속 생겼습니다.

그 점이 오히려 좋았습니다. 당시에는 코드를 잘 짜는 일이 정답을 맞히는 일처럼 느껴질 때가 많았습니다. 요구사항이 있고, 구현이 있고, 버그를 없애면 끝나는 식입니다. 그런데 이 책은 프로그래밍을 조금 다르게 보게 했습니다. 코드는 한 번에 맞히는 답안이 아니라, 보고 고치고 버리고 다시 만드는 작업물에 가깝다는 쪽이었습니다.

지금 다시 읽으면 거칠게 느껴지는 문장도 있습니다. 폴 그레이엄 특유의 단정적인 말투도 있고, 스타트업과 해커 문화에 대한 낙관도 꽤 강합니다. 그래도 그때 제게 남은 감각은 아직 유효합니다.

프로그래밍은 문제를 푸는 일이기도 하지만, 동시에 무언가를 만드는 일이라는 것.

해커는 왜 화가에 가까운가

책에서 가장 먼저 꽂힌 문장은 해커가 엔지니어나 과학자보다 화가 같은 창조자에 가깝다는 이야기였습니다.

처음에는 조금 과장처럼 느껴졌습니다. 개발자는 요구사항을 구현하고, 테스트를 통과시키고, 장애를 줄이는 일을 합니다. 화가라는 표현은 실제 업무와는 거리가 있어 보일 수도 있습니다.

그런데 책을 읽다 보니 의도는 알 것 같았습니다. 좋은 코드는 처음부터 완성된 설계도에서 바로 나오지 않습니다. 일단 윤곽을 만들고, 실제 기능에 넣어보고, 마음에 들지 않는 부분을 덜어내고, 이름을 바꾸고, 구조를 다시 잡는 과정에서 나옵니다.

이건 이후에 리팩토링 책을 읽었을 때도 비슷하게 이어졌습니다. 메서드를 빼고, 책임을 옮기고, 데이터를 더 말하게 만드는 일은 코드에 장식을 더하는 일이 아니었습니다. 만들면서 더 정확한 모양을 찾아가는 일이었습니다.

그래서 이 책을 읽은 뒤에는 “처음부터 완벽하게 설계해야 한다”는 압박이 조금 줄었습니다. 대신 처음 만든 것이 어설픈 건 자연스럽고, 중요한 건 그 어설픔을 계속 볼 수 있는 눈이라는 생각이 들었습니다. 당시 작업하던 코드에서도 한 번에 맞히기보다, 작게 만들고 팀이 이해할 수 있는 모양으로 계속 다듬는 쪽이 더 현실적이었습니다.

물론 이 말이 아무렇게나 만들고 나중에 고치면 된다는 뜻은 아닙니다. 오히려 반대에 가깝습니다. 계속 고칠 수 있으려면, 지금 만든 코드가 어디가 불편한지 알아차려야 합니다. 그 감각이 없으면 코드는 그냥 쌓입니다.

웹은 피드백 루프를 바꾼다

책의 “또 하나의 길”에서 데스크탑 애플리케이션에서 웹으로 넘어가는 이야기도 흥미로웠습니다.

지금은 웹으로 서비스를 배포하고 빠르게 고치는 일이 너무 당연합니다. 하지만 책에서 이야기하는 맥락은 조금 달랐습니다. 데스크탑 프로그램은 사용자가 직접 설치하고, 버전이 갈리고, 버그를 재현하기도 어렵습니다. 반면 웹은 서버 쪽에서 바로 고치고, 사용자는 다음 접속에서 개선된 것을 씁니다.

이 부분은 실무를 하면서 더 현실적으로 와닿았습니다.

배포가 쉬워지면 제품을 바라보는 방식이 달라집니다. 버그를 고치는 속도도 달라지고, 고객지원에서 재현하는 방식도 달라지고, “일단 작게 내고 반응을 본다”는 선택지도 생깁니다.

당시 작업하던 웹 서비스에서도 이 차이는 꽤 컸습니다. 운영 중인 기능에서 작은 버그가 발견되면, 문제를 재현하고 코드를 고친 뒤 바로 반영할 수 있다는 점이 개발자의 심리적 부담을 줄여줬습니다. 반대로 그런 흐름이 막히면 작은 수정도 무거운 일이 됩니다.

그때는 이 이야기를 읽으며 웹이 데스크탑보다 우월하다는 식으로 단순하게 받아들였던 것 같습니다. 지금은 조금 다르게 봅니다. 웹이 모든 문제를 해결해주는 건 아니지만, 배포와 피드백 루프를 짧게 만든다는 점은 확실히 큰 변화였습니다.

새 프레임워크나 새 도구를 볼 때도 비슷합니다. 구조가 좋아 보이는지보다 중요한 건 실제로 피드백 루프를 줄여주는가입니다. 사용자가 겪는 문제를 더 빨리 보고, 더 빨리 고치게 해주는가입니다.

좋은 디자인은 다시 고치는 일

책에서 가장 오래 남은 부분은 좋은 디자인에 대한 이야기였습니다.

좋은 디자인은 제대로 된 문제를 해결해야 하고, 간단해 보여야 하고, 다시 디자인하는 과정을 거쳐야 한다는 말들이 나옵니다. 당시에는 좋은 문장이라고 생각하며 밑줄을 그었습니다. 그런데 실무를 하다 보면 이 말이 생각보다 불편한 기준이라는 걸 알게 됩니다.

대부분의 코드는 처음에는 그럴듯합니다. 화면도 뜨고, API도 응답하고, 테스트도 통과합니다. 그런데 시간이 지나면 이름이 어긋나고, 데이터가 엉뚱한 곳에 모이고, 조건문이 늘어나고, 한 번에 설명하기 어려운 코드가 됩니다.

그때 필요한 건 더 대단한 추상화가 아니라, 다시 보는 일입니다.

이 함수가 정말 이 객체의 책임인지, 이 값은 배열이나 해시로 계속 둬도 되는지, 이 조건문은 정상 흐름을 가리고 있지 않은지 묻는 일입니다. 좋은 디자인은 처음에 그럴듯하게 잡는 일이 아니라, 불편함을 발견했을 때 고칠 수 있는 상태를 유지하는 일에 더 가까웠습니다.

이 기준은 PHP 코드베이스에 Rails식 컨벤션을 넣으려던 고민과도 이어졌습니다. 컨벤션은 폼을 맞추기 위한 규칙이 아니라, 다음 사람이 코드를 볼 때 추측해야 할 것을 줄이는 장치였습니다. 테스트 fixture도 마찬가지였습니다. 테스트 데이터를 깔끔하게 정리하려는 일이 아니라, 같은 상태를 다시 만들 수 있게 해서 코드를 더 안심하고 고치려는 일이었습니다.

이 지점이 좋았습니다. 책이 프로그래밍을 예술처럼 말한다고 해서 감상적인 이야기만 하는 것은 아니었습니다. 오히려 아주 실무적인 태도로 이어졌습니다. 코드를 계속 만져야 하는 사람에게 디자인은 보기 좋은 모양이 아니라, 다음 변경을 덜 무섭게 만드는 구조였습니다.

언어는 취향이 아니라 사고방식이다

프로그래밍 언어 이야기는 책에서 꽤 큰 비중을 차지합니다. Lisp 이야기도 많고, 정적 타입과 동적 타입, 객체지향과 함수형, 언어의 미래 같은 주제도 나옵니다.

처음 읽을 때는 Lisp 이야기가 먼저 눈에 들어왔습니다. 남들이 C나 Java로 일할 때 Lisp를 써서 우위를 만들었다는 식의 이야기는 개발자에게 꽤 자극적입니다. “도구 선택이 실제 생산성 차이를 만들 수 있구나” 하는 생각을 하게 됩니다.

하지만 시간이 지나고 보니 더 오래 남은 건 특정 언어가 아니라 언어를 대하는 관점이었습니다.

언어는 단순히 컴퓨터에게 명령을 전달하는 문법이 아닙니다. 개발자가 문제를 어떤 단위로 나누고, 어떤 추상화를 자연스럽게 떠올리고, 어떤 코드를 짧게 만들 수 있는지를 바꿉니다.

Ruby를 읽으면 블록과 컬렉션 중심으로 생각하게 되고, JavaScript를 쓰면 함수와 객체를 섞어 유연하게 풀게 됩니다. TypeScript를 쓰면 데이터 모양을 먼저 잡고 싶어집니다. PHP 코드베이스에 Rails식 컨벤션을 넣으려 했던 경험도 결국 비슷했습니다.

우리는 PHP를 쓰고 있었지만, 파일명과 테이블명, 모델명, 테스트 데이터의 모양에 Rails식 약속을 넣고 싶어 했습니다. 그러면 프레임워크를 바꾸지 않아도 팀이 문제를 나누고 코드를 찾는 방식은 달라질 수 있었습니다. 언어 자체보다, 그 언어 위에서 어떤 개발 흐름을 만들고 싶은지가 중요했습니다.

그래서 “좋은 언어”를 하나로 정하기는 어렵습니다. 다만 좋은 언어는 개발자가 작은 프로그램을 빨리 만들고, 마음에 들지 않는 부분을 쉽게 고치고, 필요한 추상화를 부담 없이 만들 수 있게 해줘야 한다는 생각은 남았습니다.

책에서 말하는 “해커들이 좋아하는 언어”라는 표현도 지금은 그렇게 읽힙니다. 똑똑한 사람만 알아보는 언어라는 뜻이라기보다, 만들고 고치는 감각을 방해하지 않는 언어에 가깝습니다.

불편하지만 남는 문장들

이 책을 그대로 다 동의하기는 어렵습니다.

특히 스타트업, 부, 뛰어난 사람들의 차이에 대한 대목은 지금 읽으면 꽤 세게 느껴집니다. 차이가 선형으로 벌어지지 않는다는 이야기나, 평균적인 수준으로는 스타트업이 살아남기 어렵다는 이야기는 어느 정도 맞는 말이지만, 너무 쉽게 사람을 줄 세우는 문장처럼 읽히기도 합니다.

처음 읽을 때는 그런 단정적인 말이 꽤 또렷하게 들어왔습니다. 세상은 공평하게 굴러가지 않고, 잘 만드는 사람의 차이는 크고, 좋은 도구를 아는 것이 중요하다는 말로 읽혔습니다.

그런데 일을 해볼수록 조금 더 조심스러워졌습니다. 좋은 제품은 뛰어난 개인의 번뜩임만으로 만들어지지 않았습니다. 팀의 속도, 배포 환경, 코드베이스의 상태, 고객을 만나는 방식, 운 같은 것들이 같이 작동했습니다.

그래도 이 책의 거친 문장들이 전부 무의미해지는 것은 아닙니다. 오히려 그 거침 덕분에 질문이 남습니다.

나는 지금 남들이 다 하는 방식이라서 따라 하고 있는가. 정말 좋은 도구를 쓰고 있는가. 내가 만드는 것이 사용자의 문제를 제대로 해결하고 있는가. 코드를 단순히 납품물로 보고 있는가, 아니면 계속 다듬어야 할 작업물로 보고 있는가.

이 질문들은 여전히 쓸모가 있습니다.

남은 감상

『해커와 화가』는 깔끔한 기술 요약서라기보다, 내가 일하는 방식을 다시 보게 만드는 책이었습니다.

처음 읽을 때는 Lisp나 스타트업 이야기처럼 눈에 잘 띄는 부분이 먼저 보였습니다. 그런데 시간이 지나고 나니 오히려 더 실무적인 문장들이 남았습니다. 좋은 디자인은 다시 디자인하는 일이라는 것. 사용자가 말하는 대로 따라 하는 것이 아니라, 사용자가 겪는 문제를 진단해야 한다는 것. 프로그래밍 언어는 프로그램을 작성하는 형식이면서 동시에 생각하는 방식이라는 것.

이 책이 준 가장 큰 영향은 프로그래밍을 조금 덜 시험처럼 보게 해준 점입니다. 정답을 빨리 맞히는 사람이 아니라, 계속 관찰하고 고치고 다시 만드는 사람이 더 좋은 것을 만들 수 있다는 쪽에 가까웠습니다.

그 감각은 지금도 꽤 자주 돌아옵니다.

새 기술을 볼 때도, 리팩토링을 할 때도, 테스트 도구를 만들 때도 결국 같은 질문으로 돌아옵니다. 이 선택이 내가 만들고 고치는 일을 더 잘하게 해주는가.

책 전체를 다시 추천하냐고 묻는다면 조금 망설일 것 같습니다. 시대감도 있고, 문장도 세고, 동의하기 어려운 부분도 있습니다. 하지만 만드는 일을 좋아하는 개발자라면 한 번쯤 부딪혀볼 만한 책이라고 생각합니다. 다 읽고 나서 전부 받아들이지 않아도 됩니다. 오히려 어디에 동의하고 어디에서 멈칫했는지 남는다면, 그걸로 충분합니다.

용어 짧게 정리

• 해커: 여기서는 보안 공격자가 아니라, 프로그램을 만들고 고치며 시스템을 깊게 이해하려는 개발자에 가깝습니다.
• Lisp: 함수형 프로그래밍과 매크로 시스템으로 유명한 오래된 프로그래밍 언어 계열입니다.
• 프로토타입: 완성품 전에 빠르게 만들어보는 초기 형태입니다. 문제를 직접 확인하고 고치기 위해 사용합니다.
• 피드백 루프: 만들고, 배포하고, 반응을 확인하고, 다시 고치는 순환입니다.
• 추상화: 복잡한 구현을 더 다루기 쉬운 개념이나 인터페이스로 감싸는 일입니다.