Archive for January, 2010
불안
http://www.yes24.com/24/goods/1794971
“불안은 욕망의 하녀다”라는 말이 내 머릿속을 적나라하게 표현해준다는 느낌이 들었다. 철학과 종교, 예술, 역사를 넘나들며 불안의 원인과 해법을 파헤치는 “알랭 드 보통”은 참 박식하다. 그리고, 같은 말을 해도 어쩌면 이렇게 멋지게 비유할까라는 생각이 끊이지 않을 정도로 글도 잘쓴다. “불안” 이외에도 사람이 느끼는 감정을 적나라하게 파헤치는 책이 시리즈로 나왔으면 좋겠다.
- 지위로 인한 불안
- 사회에서 제시한 성공의 이상에 부응하지 못할 위협에 처했으며, 그 결과 존엄을 잃고 존중을 받지 못할지도 모른다는 걱정.
- 원인
- 사랑결핍
- 물질이나 권력보다는 사랑을 받을 수 있기 때문일지도.
- 속물근성
- 속물적인 세상에서는 지위가 낮으면 무시와 외면을 당하므로.
- 기대
- 계급 사회가 무너지면서 누구나 성공할 수 있는 기회가 열렸음.
- 그 결과 기대감이 커지지만 실제로 성공할 수 있는 사람은 많지 않다.
- 기대가 커져서 많은 것을 가지고도 불안해 하게 되었다.
- 능력주의
- 태어날 때부터 정해지던 지위가 능력에 따라 정해지게 되었다.
- 지위가 낮은 사람은 운이 나쁜 것이 아니라 능력이 없는 것이 되었다.
- 가난이라는 고통에 수치라는 모욕까지 갖게 되었다.
- 불확실성
- 재능, 운, 실직, 회사의 안정성, 세계 경제등은 예상할 수 없는 불안정한 것.
- 언제라도 낮은 지위로 떨어질 수 있다는 불안감이 생긴다.
- 사랑결핍
- 해법
- 철학
- 외부의 인정이나 비난의 표시보다는 우리 내부의 양심을 따른다.
- 예술
- 많은 소설에서는 속물적인 지위 체계과 정반대인 내면 기준의 지위체계를 보여준다.
- 비극적인 작품을 통해 누구나 운나쁘게 실패할 수 있다는 것을 알게되고, 실패는 수모가 아닌 것이 된다.
- 풍자적인 희극을 통해 남들도 우리와 같은 불만이나 비밀을 가지고 있다는 것에 안도감을 느낀다.
- 정치
- 지위 체계는 시간에 따라 변해 왔으며, 체제의 키를 가진 사람이 만든 것에 불과하다.
- 신에게 부여받은 절대적인 기준이 아니다.
- 기독교
- 죽음이나 대자연 앞에서는 인간의 지위란 보잘 것 없음을 깨닫는다.
- 세속적인 지위와는 다른 영적인 지위를 제시한다.
- 보헤미아
- 품위라는 부르주아적 개념에 들어맞지 않는 광범위한 사람들.
- 속물적인 지위체계에 따르는 대신 대안적인 삶의 방식 추구에 정통성을 부여했다.
- 철학
지위에 대한 불안의 성숙한 해결책은 우리가 다양한 사람들로부터 지위를 인정받을 수 있다는 사실을 인식하는 데서 시작한다. 산업가로부터 인정받을 수도 있고 보헤미안으로부터 인정받을 수도 있으며, 가족으로부터 인정받을 수도 있고 철학자로부터 인정받을 수도 있다. 누구로부터 인정받기를 원하느냐 하는 것은 우리의 의지에 따른 자유로운 선택이다.
p.384
스크럼 일기 3 – 모자
어떤 모자를 썼는지 명확하게 하자
자격증을 가진 스크럼 마스터가 있는 것도 아니고 기존의 조직 체계도 있다보니 한 사람이 여러 역할을 맡을 수 밖에 없다. 우리 팀장님은 실장님, 팀장님, 프로덕트 오우너, 경력많은 개발자(조언자) 역할을 해야하고, 노예형 스크럼 마스터는 개발자 역할을 병행해야 한다.
그러다보니 지금 “경력많은 개발자”의 모자를 쓰고 조언을 해주는 것인지, “프로덕트 오우너”의 모자를 쓰고 요청을 하는 것인지 오해가 생기기 쉽다. 이렇게 설계하는게 좋았다라는 경험을 말해주는 것 뿐인데, 명령으로 받아들여 프로덕트 백로그에도 없는 일을 열심히 하고 있는 불상사가 생길 수도 있다.
지금 어떤 모자를 쓰고서 말하는 것인지 오해하지 않도록 서로 신경 쓸 필요가 있다.
소프트웨어 공학의 사실과 오해 10 – 연구, 마무리
http://www.yes24.com/24/goods/1418676
연구
그런데, 소프트웨어 연구에는 문제가 있다. 평가적 연구(방법, 모델, 이론 등을 검토하는 연구)가 거의 없다는 것이다. 소프트웨어 공학 연구 유형의 스펙트럼에서 14%만이 평가적 연구다. 컴퓨터 과학 연구도 단지 11%만이 평가적 연구다. 이와는 대조적으로, 정보 시스템과 같은 다른 주요 컴퓨팅 분야에서는 평가적 연구가 67%에 이른다.
p.265
Potts(1993)은 이런 잘못된 연구 방법을 ‘연구한 다음 전파하는 방식’이라고 불렀는데, 이는 새로 연구한 접근방법의 제안과 이를 실무에 전파하기 위해 제시하는 중간에 평가가 없다는 것을 뜻한다. 나는 동일한 상황을 나타내는데 ‘옹호적 연구’란 용어를 사용했다. (…) Tichy와 그의 동료들(1995)은 컴퓨팅 분야에 대한 400개의 연구 논문을 검토해 소프트웨어 공학과 컴퓨터 과학에 대한 40~50%의 논문에 평가적 요소가 결여돼 있음을 알아냈다.
p.266
학계의 소프트웨어 연구자들은 너무도 자주 새로운 개념을 제안하고, 이 새로운 개념이 대단히 중요한 것인 양 과장하고, 이를 즉각적으로 실무에 적용하지 않는 이들을 비난한다. 정형방법도 그런 사례 중 하나다. 연구자들이 평가적 연구를 시작하기 전까지는 그 아이디어의 이득에 대해 잘못 인도했고, 또 잘못 인도할 것이다.
p.267
소프트웨어 업계에는 검증되지 않은 개념이나 기술이 과대 선전되고 있다는 얘기. 하지만 결국 은 탄환Siver Bullet은 발견되지 않았다.
마무리
책을 읽고나서 그 내용을 깨끗하게 잊어버리는 데까지 그리 많은 시간이 걸리지 않는다는 걸 알려준 책이다. -_-;; 한 번 정독을 하고 나서, 블로그에 올릴 부분을 고르려고 다시 정독을 하게 되었는데, 처음에 감탄하면서 읽은 내용에 다시 한 번 감탄하고 있는 나를 발견할 수 있었다.
블로그에 올리면서 다시 또 훑어보았으니 3번은 읽은 셈이다. 예전 같았으면 시간이 아까웠을텐데, 오히려 앞으로 좋은 책은 꼭 여러 번 읽어야겠다는 다짐을 하게 되었다. Debugging Applications를 쓴 존 로빈스 아저씨가 자기는 매년 Code Complete을 다시 읽는다고 했을때, 왜 그럴까 했었는데 이제는 좀 이해가 간다.
스크럼 일기 2 – 프로덕트 로그
프로덕트 로그도 점진적으로 발전한다
개발팀에게 전달되는 요구사항이나 스펙이 완벽하지 않다고 불만을 가질 일이 아니다. 좋은 설계를 반복없이 한 번에 만들어 낼 수 없는 것처럼 좋은 프로덕트 로그도 한 번에 만들어 낼 수 없다.
보통 고객이란 불특정 다수이므로 완벽한 요구사항을 건네줄 사람이 있는 것도 아니고, 개발 도중에도 시장환경이나 조직의 상황이 계속 변하므로 스펙이나 우선순위 조정이 불가피하고, 기술적인 한계나 복잡성에도 영향을 받는데 이는 개발팀이 연구, 조사, 스파이크 같은 것을 해봐야 알 수 있는 것이라 초기에는 예상하기 힘들다. 이런 이유들로 처음부터 완벽한 프로덕트 로그를 만드는 것은 어렵다.
지난 글에서는 오우너와 개발팀의 역할을 명확히 나눠야 한다고 했지만, 기술적인 한계, 기술의 장단점과 같이 오우너가 프로덕트 로그를 개선하는 것을 돕기 위해서 개발팀이 오우너에게 제공해야 하는 정보도 있다. 다시 말해 개발팀도 좋은 프로덕트 로그를 만드는 일에 일정 부분 공헌할 필요가 있다는 얘기. (스프린트 준비회의에서 많은 대화가 필요하다.)
프로덕트 로그가 완벽하지 않다거나, 자주 변한다고 투덜대지 말자.
소프트웨어 공학의 사실과 오해 9 – 품질
http://www.yes24.com/24/goods/1418676
품질
소프트웨어 분야에서 품질이란 좋은 품질의 소프트웨어 제품이 가져야하는 7개의 속성의 집합을 말한다. 이 집합은 이식성(portability), 신뢰성(reliability), 효율(efficiency), 사용 편의성(usability), 테스트 용이성(testability), 이해 용이성(understandability), 수정 용이성(modifiability)으로 구성된다.
p.233
사실 여기 나오는 속성 7개가 중요하다기 보다는 품질이란 여러 가지 속성의 집합이라는 사실이 요점인 것 같다.
이 속성에 우선순위를 매기는 것은 불가능하다. 즉, 소프트웨어 품질 속성을 모두 만족시키기 위한 시도에서 일반적인, 올바른 순서는 없는 것이다. 그러나 이 말이 속성에 순서를 매기면 안 된다는 뜻은 아니다. 어떤 프로젝트든 시작할 때부터 이 속성에 우선순위를 정해두는 것은 매우 중요하다.
p.234
이 일은 정말 중요하다! 그렇지 않으면 모두가 자기만의 우선순위를 가지고 개발을 하게 되므로 어떤 사람이 봤을 때는 좋은 코드인데 다른 사람이 봤을 때는 나쁜 코드가 될 수 있다. 리드 프로그래머와 같이 전체 품질에 책임을 지는 사람이 품질 속성에 우선순위를 매겨서 모두가 합의하게 되면, 매번 설계할 때마다 고민할 일도 줄어들고, 피어 리뷰에서 싸우는 일도 줄어들게 된다.
품질은 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성, 또는 신뢰성이 아니다.
p.238
사용자 만족 = 요구사항 충족 + 납기일 준수 + 적절한 비용 + 좋은 품질의 제품
p.238
사용자 만족의 정의에서 볼 수 있듯이 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성은 품질에 속하는 것이 아니다. 신뢰성 역시 품질의 한 가지 속성일 뿐인데, 신뢰성(오류 존재 여부)만을 품질이라고 생각하는 사람도 있다.
이런 개념이 정리되어 있지 않으면 “사용자가 만족하지 못하니 품질이 나쁜 것”이라고 단정하는 실수를 하기 쉽다.
오류는 항상 남아 있다. 심각한 오류를 제거하거나 최소화하는 것이 목표가 돼야 한다. (…) 심각한 오류는 반드시 소프트웨어 에서 제거돼야 한다. 다른 오류도 모두 제거하면 좋겠지만(예를 들면 문서화 오류, 중복된 코드 오류, 도달할 수 없는 경로 오류, 알고리즘에서 무시할 수 있을 정도의 수치상 오류 등), 항상 그럴 필요는 없다.
p.248
개인적으로 “리펙토링할 코드는 항상 남아 있다.”는 생각을 가지고 있는데, 이런 생각은 100% 완벽한 코드를 만들려는 강박관념을 없애주고, 좋지 못한 코드를 발견했을 때 “아, 이 소스코드는 엉망진창이군. 대충 필요한 코드나 추가해야지.”라고 생각하기 보다는, “소스코드란 영원히 부족한 법이지. 우선 이부분만 리펙토링 해볼까.”라고 생각하도록 도와준다.
얼마나 많은 사람들이 제품의 품질을 관리 쪽 책임이라 믿든, 소프트웨어 품질이란 주제에는 기술적 요소가 너무 많아 이를 관리만의 책임으로 미룰 수는 없다는 것이 내 대답이었다. 그리고는 거의 모든 품질 속성이 기술자만이 해결할 수 있는 상당히 기술적인 면을 갖고 있다는 것을 지적했다.
p.281
경영진은 ‘품질 제일’과 같은 슬로건을 걸고 ‘총체적 품질 관리(TQM, Total Quality Management)’와 같은 방법론을 사용하는 것이 소프트웨어 제품의 품질 달성을 위한 주요 접근방법이라 생각하는 것 같다. (…) 경영진은 한 손에는 동기부여와 방법론을 들고 다른 쪽 손에는 일정 압박이란 반 품질적 요소를 적용하려 한다. 두 가지를 모두 하는 것은 불가능하고, 대부분의 기술자들도 이를 알 만큼은 똑똑하다.
p.281, 282