안녕하세요.
책을 읽고 난 뒤, 무엇이 남았는지 이야기하는 시간입니다.
요즘 AI가 코드를 뚝딱 만들어내는 시대에, 개발자에게는 무엇이 중요할까요?
단순히 최신 기술을 아는 것보다, 어떤 사고 습관과 운영 기준을 가져야 할지, 저는 늘 고민하고 있습니다.
이런 질문을 안고, 앤드류 헌트와 데이비드 토마스의 『실용주의 프로그래머』 두 번째 읽기를 시작했습니다.
사실 처음
이 책을 집었을 때는, 좀 오래된 조언들이 모여 있을 거라고 예상했어요.
하지만 읽으면 읽을수록, 이 책은 최신 도구에 대한 이야기가 아니라, 오래도록 변치 않는 개발자의 운영 체계,
그러니까 '소프트웨어를 어떻게 바뀔 수 있게 만들 것인가'를 묻고 있다는 걸 깨달았습니다.
기술의 변화 속도가 빨라질수록, 오히려 이런 본질적인 질문이 더욱 중요해지는 것 같아요.
이번 두 번째 읽기에서 제가 가장 집중했던 부분은 바로 '중복을 줄이고 바뀔 수 있게 만들기'였습니다.
책은 좋은 설계란 오늘의 답을 박제하지 않고, 내일의 변경권을 남겨두는 것이라고 말합니다.
우리가 만드는 소프트웨어가 처음부터 완벽할 수 없다는 것을 인정하고, 변화에 유연하게 대응할 수 있는 힘을 어디에
남겨둘 것인가에 대한 깊은 통찰을 제공하죠.
특히 제 마음을 사로잡았던 세 가지 개념이 있습니다.
첫째는 'DRY' 원칙입니다.
흔히 "똑같은 코드를 두 번 치지 마라"는 표면적인 조언을 넘어, '지식의 단일 출처'를 지키는 원칙이라는 거죠.
같은 정책이나 규칙이 여러 장소에서 서로 다르게 자라나는 것이, 똑같은 코드가 두 번 있는 것보다
훨씬 위험하다는 말에 정말 공감했습니다.
프로젝트에서 여러 팀원이 각자의 방식으로 동일한 규칙을 해석하고 구현할 때 생기는 혼란을 떠올려보면, 이 원칙의
중요성을 더욱 실감하게 됩니다.
둘째는 '직교성'입니다.
한 부분의 변화가 다른 부분을 흔들지 않게 만드는 힘을 말하는데요.
특히 AI 에이전트 개발에 몰두하고 있는 제게는 이 '직교성'이 아주 와닿았습니다.
도구, 프롬프트, 데이터, 검증 로직이 서로 엉켜 있으면, 에이전트가 한 번 실패할 때 전체 루프가 무너지는 경험을
자주 하거든요.
각 요소를 독립적으로 나눌 수 있어야만, 문제가 생겼을 때 고치기도 쉽고, 새로운 기능을 추가하기도 용이하다는 것을
다시 한번 깨달았습니다.
마지막으로 '트레이서 불릿'입니다.
이건 완성본이 아니라 방향 감각을 잡는 데 쓰인다고 해요.
완벽한 계획서보다, 아주 얇더라도 실제로 작동하는 흐름을 먼저 만들어 현실과 부딪혀보라는 이야기입니다.
저도 블로그 자동화 작업을 할 때, 처음부터 모든 기능을 완벽하게 만들려 하기보다, 입력부터 배포까지의 핵심 흐름을
먼저 얇게 뚫어보면서 방향을 잡아야겠다고 생각했습니다.
계획은 언제든 바뀔 수 있지만, 작동하는 피드백은 우리에게 가장 빠르게 현실을 알려주니까요.
이 책을 읽고 나서, 저는 제 작업 방식에 한 가지 변화를 주기로 했습니다.
현재 진행 중인 프로젝트에서 중복된 지식이 숨어 있는 파일 두 곳을 찾아내고, 그것들을 하나의 명확한 출처로
통합하는 작업을 할 예정입니다.
그리고 불확실한 기능을 개발할 때는, 일단 프로토타입과 실제 제품 코드를 분리해서, 미래의 변경 가능성을 열어두는
태도를 유지하려고 합니다.
『실용주의 프로그래머』는 단순히 개발 기술을 알려주는 책이 아닙니다.
새로운 기술에 휘둘리지 않고, 자기만의 탄탄한 개발 철학을 세우고 싶은 분들, 그리고 변화하는 환경 속에서 유연하게
대처하는 방법을 고민하는 모든 분들에게 큰 의미가 있을 책이라고 생각합니다.
좋은 설계는 오늘의 답을 박제하지 않고, 내일의 변경권을 남겨둡니다.
AI가 코드 대부분을 생성하는 시대에, 실용주의 개발자의 책임은 과연 어디로 이동할까요?
다음
독서에서 이 질문에 대한 답의 실마리를 찾아보려 합니다.
오늘도 책과 함께 좋은 하루 보내세요.
감사합니다.