소프트웨어 아키텍트가 알아야 할 97가지 (Richard Monson-Haefel, 2011) 독후감

소프트웨어 아키텍트가 되려면 어떤 걸 알아야 할까? 이걸 가장 잘 얘기해 줄 수 있는 사람은 아키텍트라는 직함을 가진 사람이다. 이 책은 그래서 의미가 있다고 생각한다. 실제 아키텍트라 불리는 여러 사람이 어떤 걸 알아야 하는지 직접 얘기하는 걸 묶었으니깐.

하지만, 나는 읽는데 지겨웠다. 비즈니스 얘기가 조금 추가됐다는 것 빼고는 같았다. 이제까지 다른 책에서 들어온 좋은 소프트웨어 개발자가 되기 위해 알아야 하는 것들과 같았다. 아키텍트가 알아야 하는 것도 그리 다르지 않다고 느꼈다. 더 깊이 이해하고 얼마나 더 많이 실천할 것인가에서 승부가 결정되지 않을까?

읽으면서 인상적인 문장을 적어보았다. 지금 바빠서 땜질 코드를 사용하지만, 이후에는 제대로 고쳐야 하는 것들을 뭐라 부르면 좋겠냐는 질문을 들은 적이 있다. 그때 괜찮은 용어가 안 떠올랐는데, 적절한 용어가 여기에 나오는구만. 바로 ’기술 채무’.

• 만일 소통이 ’왕’이라면 명확성과 리더쉽은 소통을 위해 반드시 수반되어야 하는 ’신하’입니다. from 9
• 요구되는 기능이나 요구사항에서 의도하고 있는 가치를 질문함으로써, 아키텍트는 실질적인 문제에 집중하고, 잘되면, 고객이 말한 것보다 더 좋고 비용이 적게 드는 해결책을 제시할 수 있습니다. from 12
• 일어서는 행위는 무의식적으로 권위와 자신감을 갖고 대화를 나누게 합니다. 회의실을 지배하십시오. from 14
• 추측을 통한 일반화보다는 경험을 통한 단순화가 더 낫습니다. from 36
• 기술 채무(technical debt)를 갚아라. from 174
• 만약 개발자들이 그들의 경험적 지식을 활용하는 능력을 알고 싶다면 다음과 같이 질문해 보세요. “만약 가장 최근에 진행했던 프로젝트를 다시 처음부터 시작한다면 무엇을 바꿔보고 싶은지요?” from 180
• 최종사용자에게는 인터페이스가 시스템이다. from 192