덩치에 맞는 옷을 입자.

개발에 그렇게 많은 문서가 필요 없다는 글. 정말로 업데이트할 수 있을 정도의 핵심 문서만 만들어야 한다는 글.
저작권법때문에 인용글 삭제

via [소프트웨어 개발의 극과 극](http://allofsoftware.net/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C%EC%9D%98-%EA%B7%B9%EA%B3%BC-%EA%B7%B9)

100% 동감. 매 단계마다 몇 가지의 문서를 만들어내야 하고, 그런 과제 몇 개를 동시에 진행하면서 문서의 품질을 기대한다는 것 자체가 무리한 요구 아닌가? 창피하지만 우린 그런 문서 쓰는 거 교육 받은 적도 없다고. -_-

Waterfall과 Agile? 현실은?

> 이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다

via [Waterfall과 Agile :: All of Software](http://allofsoftware.net/entry/Waterfall)

정말일까? 현실적으로 대부분 Waterfall 방식을 사용할 듯한데.
왜냐하면? 대부분의 기업에서(인터넷이나 벤처는 잘 모르겠다) Project 를 관리하는 역할이나 그 관리자를 관리하는 사람이 저것밖에 모를텐데. Agile? Scrum? XP? 정말 들어본 적이나 있을까?

최소한 내 주변에 있는 백명이 넘는 개발자 중에 저 세가지 단어를 들어본 사람의 수는 손가락으로 꼽을 수 있다고 장담한다.

내가 우물한 개구리이거나(상당부분 그렇긴 하지만) 혹은 현실은 인터넷에서 떠드는 소프트웨어 공학과는 아직 거리가 있거나.

새로운 역할

피했으면 했던 PA(Project Assistant?)를 하게 됐다.

내년 4월에 끝나는 과제라고 한다. 크게 바뀌는 것은 없어 보이지만 하드웨어가 일부 변경되는 터라 구미에서 진행하는 신뢰성시험도 거쳐야 한다.

어차피 의중을 묻는 것이 아니라 면담형식을 가진 업무 할당이라 거부할 수는 없었다. 회사생활에서 이런 경우에 “No”를 주장하는 것이 얼마나 쉽지 않은 지는 직장인이라면 대부분 알 것이다. 게다가 요즘은 바쁘게 하는 일도 없는 터라.

면담 중에 이런 저런 이야기를 부장님게 털어놨다.

– PA라는 역할에 대한 나의 생각
– 직급 연수가 올라감에 따라 생가는 운신의 폭이 줄어듬
– 부서 분위기
– 커리어 패스에 대한 개인적인 생각
– 부서 운영에 대한 아쉬움.

많지는 않지만 어떤 회사들은 개발자가 기획부터 설계, 구현, 검증까지 모든 것을 한다고 한다.
또 어떤 회사는 모토가 나이 50까지(평생 이던가?) 엔지니어 하자 란다.

즉 경력이 쌓이고, 나이가 들어도 개발자로써의 역할을 빼앗지 않는 다는 것이다.
하지만 여기는 그렇지 않다. 직급이 어느 정도 되면 의례 그 동안의 업무를 하지 못하게 한다. 하지만 그러면서 제시하는 길은 단 3가지이다. 과제를 관리하는 PA, 부서를 관리하는 매니저(이 두 개를 함께 하기도 하지만) 아니면 Skill Leader.

하지만 어찌 보면 가장 많아야 할 Skill Leader 자리는 별로 없고 대부분 PA를 시킨다.
PA라는 것이 과제를 잘 관리하도록 하는 업무이긴 하지만 근본적으로는 뒤치닥거리 라는 것이 나의 생각이다. 뭔가 창의력을 발휘해서 뭔가를 개선하는 것이 아니라 윗 사람이 제시한 일정, 제시한 요구사항을 일반 개발자들이 잘 준수하고 있는 지를 관리 감독하는 것이 업무의 대부분이다.

그러니 재미가 없을 수 밖에.

대학원때부터 느낀 것이지만 난 사람 눈에 안 보이는 core technology보다는 사람과 밀접한 관계를 갖는 UI 쪽이 맞지 않나 싶다. 그냥 기능을 잘 동작하게 하는 것만큼(보다?) 사용자가 어떻게 사용할 까? 어떻게 하면 보다 쉽게 사용할 수 있을 까? 라는 고민을 많이 하는 편이라(물론 내 주변 사람들보다 그렇다는 것이고, “그렇다”고 하는 것 조차도 내 생각이지만)

그나저나 한동안 했던 “다른 사람 채근하기”를 본격적으로 내년 4월까지 해야 할텐데 어떻게 해야 할 지 고민스럽다.
그나마 다행인 것은 큰 일이 있는 것은 아니지만 지금 맡은 블럭은 그대로 유지해야 한다고 부장님이 반색하는 것이 오히려 감사하다. 그래도 한숨을 쉬며 편안함을 즐길 수 있는 개발 업무를 빼앗아 가지 않은 것은 얼마나 다행인 지. 부담을 덜어주겠다고 일을 빼았아 간다고 했어도 내가 반대했을 듯.

꼬랑지) 코딩용 키보드를 빼앗긴 사람들이 얼마나 무료해 하는 잘 안다. S/W 개발자면 다 그럴 것같지만 개발/코딩을 좋아하는 사람은 손에 꼽을 정도인데 그 사람에게서 그 일을 빼앗아 가면 힘들어 한다. 나도 실력은 보잘 것 없지만 코딩을 좋아서 하는 사람이고.

꼬랑지2) 오늘도 미국 현지에 있는 사람들이 사용할 간단한 스크립트를 신나게 만들어서 보냈다. 그 사람들의 번거로움을 조금이라도 줄이면서 더 잘 동작하고, 더 다양한 기능을 제공하도록 코드 고치고 시험하는 일이 얼마나 즐겁던지 🙂

완전 무결한 S/W는 없다.

최근 출시된 삼성 소울 폰에 112로 전화하면 119로 연결되는 [문제](http://clien.career.co.kr/zboard/view.php?id=news&page=1&page_num=30&select_arrange=headnum&desc=&sn=off&ss=on&sc=on&keyword=&no=21032&category=) 가 있다고 한다.

해당 문제점을 경험한 사람 입장에서는 정말 열불 날 노릇일 것이고, 이 소식을 들은 일반 소비자들은 저런 어처구니 없는 버그를 지닌 제품을 출시한 회사가 한심해 보일 것이다.

하지만 한 명의 개발자 입장에서 보면 그 회사의 입장이 조금은 이해된다.
어찌 보면 개발자가 가져서는 안되는 마인드일 수 있겠지만 여러가지 테스팅 관련 내용 강연을 통해 배운 내용은 “회사는 그럴 수 있다”는 것이다. 가끔은 “그래야 한다”는.

아래는 클리앙 게시판에 올라온 글에 대해 내가 적은 댓글이다.
내 입장을 아는 사람이라면 곡해할 수 도 있겠지만 말이다.

> 완벽한 S/W가 출시되는 경우는 없습니다. S/W 대표 기업인 MS 역시 제품 출시 전 검증 과정에서 발견한 수만개의 버그를 기록만 한 채로 제품을 출시합니다. 완벽한 S/W란 절대 있을 수 없기 때문입니다. 대신 제품 출시했을 경우 문제가 크게 될 만한 문제점만 수정하는 단계를 거친 채로 제품을 출시합니다. 그리고는 제품의 버그를 줄이는 작업을 지속적으로 합니다.
>
> 이런 과정은 대부분의 S/W 업체가 유사합니다. 저 문제점을 제품 출시를 연기할 만큼 큰 문제(중요한 문제 측면이 아니라)가 아니라고 판단했을 수 있습니다(문제 발생 확률 등을 고려해서)

단말기도 그렇고 최근의 S/W의 복잡도는 상상 이상이다. 복잡도가 높아지면 아쉽지만 버그가 발생할 확률도 함께 증가한다. 그러므로 시장에 일정 시점에 제품을 출시해야 하는 S/W 회사들은 제품 출시전에 버그를 줄이기 위해 최선의 노력을 다한다.
그렇지만 하나의 버그를 수정하면 지금 껏 잘 동작하던 것이 동작하지 않는 문제가 발생할 수 있다. 결국 Zero-defect를 목표로 하지만 현실적으로는 일정 갯수의 버그를 가진 S/W를 출시하게 된다.

그렇다고 무턱대고 제품을 출시하는 것은 아니다. 개발 일정에 맞춰 일정 시점이 되면 더 이상 신규 기능으로 인한 코드 수정은 허용하지 않고 버그 픽스만 집중한다. 그래도 모든 버그를 없앨 수는 없는 법. 최종적으로는 사내 검증 절차를 통해 확인된 버그 리스트에 수 백, 수 천, 수 만개(심지어는 그 이상)의 버그를 이미 알고 있는 상태에서 제품을 출시한다. 단 이 버그들은 치명적이거나 자주 발생하는 것은 아니다. 만일 그렇다면 제품 출시를 연기해야할 테니.

그리고 제품 출시 후에도 신규 기능 외에도 버그 픽스를 계속 진행한다.

이런 과정이 통상적인 S/W 개발 절차이다.(위 예는 MS에서 testing 관련 업무 만 10년 넘게 하다 입사하신 어느 임원이 직접 발표한 내용이라 믿을 수 있다)

예전에도 글을 적은 듯 한데 회사나 경영자 입장에서는 제품의 완성도도 중요하지만 결국은 이윤 창출을 목표로 하기 마련이다. 아주 가끔 발생하는 버그때문에 출시를 연기하여 매출이 줄어든다면 대부분의 경영자들은 제품 출시를 선택할 것이다. 낮은 확률 덕에 기회비용이 아주 낮기 때문이다. 이런 것이 제품의 품질만을 보는 일반 개발자와 경영자의 차이가 아닐까 싶다.

"Linux is evolution, not intelligent design"

내가 아는 거의 모든 S/W manager들이 이 말을 들으시면 기겁을 하겠지만 Open source 개발의 대표 중의 하나인 리눅스 커널은 그분들이 보기엔 정말 엉망인 S/W 개발 과제다.

> The Kernel has no obvious design

커널은 설계부터 시작한 것이 아니라(물론 처음에 토발즈씨가 할 때는 그랬을 지도 모르지만) 진화하는 방식이고, 무수히 많은 사람들이 함께 개발하는 거라 오히려 설계, 설계 리뷰, 구현, 시험의 통상적인 개발 process 를 지키기 어렵다.

차라리 (개인적인 수준의 설계), 구현, commit, 다수에 의한 리뷰/시험, 수정의 개발 process가 더 효과적이다.

> Open-source development violates almost all known management theories.

혹시나 이글에서 언급하고 있는 내용을 말씀드리면 그런 말을 하지 않으실까?

> 그 S/W 개발자랑 우리 개발자는 다르잖아.

개발자의 역량이 다른 것도 사실이지만, 다른 점 측면에서는 그런 점은 새발의 피가 아닐까?

재밌는 글이다.

> Documentation/stable_api_nonsense.txt

리눅스 커널의 경우 필요하다면 user application에 제공하는 API까지 바꿔버린다고 한다. 이 점에 대해서는 논쟁 거리가 많을 듯하다. 호환성을 중시할 것인지(MS Windows나 99% 이상의 S/W manager가 그렇듯이) 아니면 S/W 코드를 심플하게 유지하고, 개발자들을 늘 긴장하게 하여 커널 변경에 따라 코드를 함께 수정하게 할 것인지.

일단 코드 변경은 불안정성을 발생시킨다는 통념에 따르면 이 역시 관리자 입장에서는 말도 안되는 생각이라고 할 것이다.

재밌는 글이다.

– [리눅스 커널에 대한 신화, 거짓, 그리고 진실] (http://barosl.com/blog/entry/myths-lies-and-truths-about-the-linux-kernel) – [원문](http://www.kroah.com/log/linux/ols_2006_keynote.html)