소프트웨어 설계에서 트리즈는 정답표보다 모순을 드러내는 질문지에 가깝다
트리즈는 러시아어 약자를 옮긴 이름으로, 발명적 문제 해결 이론(TRIZ)을 뜻한다. 소련의 발명 이론가 겐리흐 알트슐러가 기술 발명의 공통 패턴을 분석하면서 만든 접근이다. 이 방법은 원래 기계와 공학 발명에 뿌리를 두고 있지만, 소프트웨어 설계에서도 의외로 쓸모가 있다.
다만 여기서 먼저 선을 그어 둘 필요가 있다. 트리즈가 소프트웨어 문제를 자동으로 풀어 주는 만능 표는 아니다. 오히려 더 현실적인 가치는, 문제를 “성능을 높이면 복잡성이 늘고, 단순하게 만들면 유연성이 떨어지는” 식의 모순으로 분해하게 만든다는 점에 있다.
소프트웨어 문제도 결국 충돌하는 요구사항으로 보일 때가 많다
실무에서 자주 만나는 설계 문제를 떠올려 보면 대부분 이런 형태다.
- 더 빠르게 만들고 싶지만 유지보수성은 잃고 싶지 않다
- 더 유연하게 만들고 싶지만 설정 복잡도는 늘리고 싶지 않다
- 더 안전하게 만들고 싶지만 사용성은 해치고 싶지 않다
- 더 재사용 가능하게 만들고 싶지만 추상화 비용은 낮추고 싶다
트리즈의 출발점은 이런 상황을 “문제가 복잡하다”로 뭉개지 않고, 무엇을 좋게 만들려는지와 그 때문에 무엇이 나빠지는지를 따로 적는 데 있다. 이 작업만으로도 해결 방식이 꽤 달라진다.
트리즈에서 바로 가져올 만한 것은 몇 가지 질문 습관이다
트리즈의 세부 도구에는 모순 행렬, 40가지 발명 원리, 이상적 최종 결과 같은 개념이 있다. 소프트웨어에 그대로 1대1 대응시키기는 어렵지만, 다음 질문들은 꽤 유용하게 옮겨 쓸 수 있다.
이상적인 상태를 먼저 적기
트리즈는 “가능하다면 시스템이 존재하지 않아도 기능은 수행되는 상태”를 이상적인 방향으로 둔다. 소프트웨어에서 이 질문은 이렇게 바뀐다.
- 이 로직을 아예 사람이 건드리지 않아도 되게 만들 수 없나
- 이 의존성을 런타임이 아니라 빌드나 배포 단계에서 정리할 수 없나
- 매번 계산하지 말고 미리 결정할 수 없나
이상적인 상태를 먼저 적으면 불필요한 복잡성을 덜어낼 실마리가 보인다.
모순을 한 문장으로 적기
예를 들어 “플러그인 시스템을 더 유연하게 만들수록 디버깅이 어려워진다”처럼 쓰는 것이다. 이렇게 적어 두면 해결책도 좀 더 선명해진다. 정말 필요한 것이 최대 유연성인지, 아니면 제한된 확장 지점 몇 개인지 따지기 쉬워진다.
문제를 분리할 수 있는지 보기
트리즈는 시간, 공간, 조건에 따라 모순을 분리하는 발상을 자주 쓴다. 소프트웨어에서는 이것이 꽤 익숙한 형태로 나타난다.
- 개발 시점에는 엄격하게 검사하고, 런타임에는 빠르게 실행하기
- 관리자 도구에는 풍부한 설정을 두고, 사용자 화면은 단순하게 유지하기
- 자주 바뀌는 부분만 데이터로 분리하고 핵심 로직은 고정하기
즉 하나의 구조 안에서 모든 요구를 동시에 만족시키려 하지 말고, 맥락을 나눠 충돌을 줄이는 쪽으로 가는 것이다.
소프트웨어에서는 “원리 이름”보다 문제 프레이밍이 더 중요하다
트리즈 책을 처음 읽으면 각종 원리 이름이 먼저 눈에 들어온다. 분할, 국소성, 사전 조치, 역발상 같은 것들이다. 하지만 소프트웨어에서 더 중요한 것은 이름 암기가 아니다. 해결 전의 문제 정의가 제대로 되어 있는가가 더 중요하다.
가령 성능 문제가 생겼을 때도 마찬가지다.
- 진짜 병목이 계산량인가, 메모리 접근인가
- 유연성이 필요한 구간인가, 아니면 반복 실행되는 뜨거운 경로인가
- 설계 전체를 바꿔야 하나, 특정 경계만 조정하면 되나
이 질문이 선명하지 않으면, 트리즈든 디자인 패턴이든 결국 그럴듯한 단어만 붙인 장식이 되기 쉽다.
핵심 정리
트리즈는 소프트웨어 설계에 그대로 복사해 쓸 수 있는 정답표가 아니다. 대신 서로 충돌하는 요구사항을 더 명확하게 드러내고, 문제를 더 좋은 문장으로 다시 쓰게 만드는 사고 도구로 보면 꽤 유용하다.
그래서 트리즈를 배운다는 것은 40가지 원리를 외우는 일보다, “무엇을 좋게 하려는가”, “그 때문에 무엇이 나빠지는가”, “이 충돌을 맥락에 따라 분리할 수 있는가”를 자꾸 묻는 습관에 더 가깝다. 설계에서 좋은 질문은 종종 좋은 해답보다 먼저 온다.