기술 블로그

트리즈는 소프트웨어 문제를 자동으로 풀어 주는 만능 표가 아니라, ‘성능을 높이면 복잡성이 늘고 단순화하면 유연성이 떨어진다’ 같은 충돌을 더 선명하게 분해하게 만드는 사고 도구다. 40가지 원리 이름을 외우기보다 이상적 상태와 모순을 한 문장으로 적고, 시간·공간·조건으로 분리해 보는 습관이 실무에서는 더 쓸모 있다는 점을 정리한다.

테스트 주도 개발은 테스트를 나중에 붙이는 습관이 아니라, 실패하는 테스트부터 써서 설계 순서 자체를 바꾸는 방식이다. 레드-그린-리팩터링의 짧은 피드백 주기에서 핵심은 테스트 개수가 아니라 설계와 검증 사이의 왕복 거리이며, 마지막 단계의 리팩터링이 빠지면 TDD는 반쪽만 남는다. 진짜 가치는 커버리지 숫자보다 더 분명한 경계선과 안전한 변경 능력에 있다.

상속은 ‘무엇의 하위 타입인가’를 표현하는 데 강하지만, UI 이벤트나 객체 간 통신처럼 호출 관계가 자주 바뀌는 영역에서는 델리게이트나 시그널과 슬롯 같은 느슨한 연결이 더 잘 맞는다. C# 델리게이트와 Qt 시그널의 사례를 빌려, 좋은 설계는 상속을 줄이는 신념이 아니라 ‘타입 관계’와 ‘실행 시 연결 관계’를 분리해 보는 습관에서 나온다는 점을 정리한다.

참조 무결성은 외래 키 규칙으로만 생각하기 쉽지만, 런타임에서 포인터·핸들·식별자가 가리키는 대상의 수명을 관리하는 문제에도 거의 같은 구조가 깔려 있다. 데이터베이스가 ‘존재하는 행만 가리키게 하라’고 한다면 런타임은 ‘살아 있는 객체만 가리키게 하라’를 요구한다. 결국 핵심은 소유권과 수명, 유효성 확인을 함께 설계하는 일이다.

조엘 스폴스키의 『Joel on Software』는 거대한 이론 대신 The Joel Test, 버그 추적, 새는 추상화 같은 낮지만 치명적인 마찰을 집요하게 건드린다. 좋은 팀은 우연히 굴러가지 않는다는 감각, 즉 빌드·버그·채용 같은 기본기를 잃지 않게 만드는 운영 감각이 이 책의 가장 큰 가치라는 점을 다시 짚는다.

2010년 Google I/O를 다시 보면, 진짜 메시지는 HTML5라는 단어가 아니라 Chrome Web Store, WebM과 VP8, Android Froyo의 브라우저 개선을 한꺼번에 밀어 웹을 앱 플랫폼으로 끌어올리려 한 큰 방향에 가까웠다. 웹이 어디까지 갈 수 있는가에 대한 기대가 한꺼번에 폭발한 순간이었다는 점을 정리한다.

불변 자료구조는 매번 전체를 복사하는 비효율적인 방식처럼 보이지만, 실제 구현은 구조적 공유와 영속 자료구조를 바탕으로 훨씬 더 실용적으로 동작한다.

함수형 프로그래밍에서 재귀는 루프의 대체재라기보다 상태 변화를 인자로 드러내는 방식에 가깝다. 특히 꼬리 재귀와 누산기 패턴을 이해하면 이 차이가 분명해진다.

함수형 프로그래밍은 게임 코드를 전부 다시 쓰라는 명령이 아니다. 불변 데이터와 순수 함수의 관점을 이용해 규칙 계산, 상태 전이, 서버 메시지 처리처럼 변화를 분리해야 하는 영역을 더 다루기 쉽게 만든다.

잘 설계된 소프트웨어는 지금 동작하는 것만으로는 충분하지 않다. 요구사항 충족, 정보 은닉, 가독성, 변경 용이성, 과잉 설계 회피라는 다섯 기준으로 다시 정리한다.