처음 읽어본 애자일 선언
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
첫번째 항목을 가장 곱씹어 보게 된다. 좋은 공정을 도입하고 도구를 사용하는 일은 좋은 팀이 되는 일보다 훨씬 쉽다. 안좋은 것은, 방법에 대한 집착이 진실을 가리는 역할을 하는 것인데, 이런 경우를 많이 보았던 것 같다. 물론 본인 역시 가리는 일을 적극 실천하기도 했다.
"무언가 잘돌아 가는 것 처럼 보이는 상태" 가 가장 무섭다는 생각을 한다. 문제를 그럴듯한 문서와 합리적인 도구 속에 숨겨서 드러나지 않게 하는 것은 생각보다 어렵지 않다. 이렇게 숨은 문제가 모두의 기억속에서 잊혀졌다가, 다시 모습을 드러냈을때는 훨씬 더 크고 복합적인 문제가 되어서 나타난다.
큰 규모의 문제에 대한 해석은 큰 규모의 계획에 대한 예측 만큼이나 정확도가 떨어지는 것 같다. 누군가의 책임소재를 찾는식의 대응이 대표적이다. 사실은 문제가 커지게 된 과정 전부가 문제인데, 그것을 고치려면 조직을 드러내야 하므로, 그럴 수는 없다.
agile 은 사실 fragile 이라는 말 처럼, 사실은 문제를 더 드러내야 한다. 문제가 작아져야 문제에 대한 해석이 정교해지고, 문제 자체가 중요해진다. 문제가 커지면 사람을 탓한다.
개발을 할때도 비슷한 생각을 한다. 잘되고 있는것 같아 보이는 상태를 경계해야 하고, 잘되고 있는 것 같이 보이게 만드는 구조를 조심해야 한다는 생각을 한다. 잘되고 있는것 같아 보일때는 피드백이 협소하지는 않은지, 목표 설정이 올바른지를 경계해야 하는 것 같다. 피드백 자체도 간명하게 유지하는 것이 좋다고도 생각한다. 피드백도 진실에서 멀어지는 징후는 비슷한것같다, 중복되거나, 너무 복잡하거나.
요새 가장 경계하는 것은 우수한 방법론, 설계 방법을 기계적으로 적용하는 것이다. 이것이 나쁘다라고 생각하는 이유는 구체적인 현상에서 멀어지게 하고, 뭔가 그럴듯해 보이는 것을 만들기 쉽기 때문이다. 이럴 수록 관찰과 관조, 회고를 많이 해야한다는 생각을 한다. 그 과정을 통해서 지금 이 문제, 지금 이 상황에서 가장 단순하게 해결 할 수 있는 방법을 발견해내는 것이 중요하다고 생각한다. 패턴은 그 다음이다. 이렇게 하나씩 쌓아올린 것 만이 패턴화, 추상화할 가치가 있는 경험이 된다고 생각한다.
무엇보다 위의 생각도 경계해야 하는 것이, 아직은 직업 개발자로서 충분한 경험을 갖추지 못했다. 그리고 나는 종종 지나치게 빠른 추상화와 지나치게 성급한 일반화로 많은 문제에 시달린다.
