Thoughts2014.04.02 16:32

오픈소스 프로젝트는 세상에 기여하는 방법일 뿐 아니라, 자기 경력을 개발하는 데도 중요한 수단이 되고 있다. 하지만 오픈소스 프로젝트는 전세계 개발자와의 협업을 전제로 하기 때문에, 몇 가지 주의할 점이 있다. 이 사항들은 전적으로 필자의 경험에 비추어 나열하는 것에 불과하며, 다른 분들은 다르게 생각할 수도 있다. 그러니 참고만 하기 바란다. 





1. 인터페이스는 주의깊게 설계하라 


주의깊게 설계하지 않은 인터페이스는 나중에 시스템 확장을 어렵게 만든다. 단순히 개선하기 어렵다는 측면의 문제점만 있는 것은 아니다. 다른 사람들이 여러분의 소스를 받아 사용하기 시작하면, 그 소스코드의 문제점과 개선 방안을 신속히 반영하기가 점차로 어려워진다. 다른 사람들이 사용하는 코드에 대한 하위 호환성을 어떻게 보장할 것이냐의 문제 때문이다. 


그러니 오픈소스 프로젝트를 섣불리 시작하는 것은 삼가는 것이 좋다. 소스 코드가 어느 정도 안정되어, 그 개선 작업이 인터페이스나 API 규격에 미칠 영향이 적다고 여겨질 때 오픈소스로 공개하는 것이 바람직하다. 


2. 기본적인 문서는 갖춘 후에 공개하라 


소스코드가 아무리 쓸만해도 기본적인 문서가 없으면 관심을 갖는 이가 적다. 사용법, 확장법, 기본적인 예제 몇 가지 정도는 반드시 포함시키는 것이 좋다. 소스코드 패키지의 일부로 튜토리얼 문서를 넣는 것도 한 방법이다. 많은 사람의 호응을 얻는 소프트웨어가 되려면 신경써야 하는 일이 많다.


3. 많은 플랫폼에 테스트한 뒤 공개하라 


리눅스 사용자만을 위한 소프트웨어라 해도, 데비안, 우분투 등등 패키지 별로 다른 의존성을 갖게 되는 경우는 흔하다. 가능한 한 의존성이 적은 소프트웨어를 만드는 것이 최선이겠지만, 그럴 수 없을 때는 개발에 의존하는 패키지들을 정확하게 식별하고, 그 의존성을 해소하는 방법을 상세히 알려주는 것이 바람직하다. 


4. 피드백을 받을 준비를 하라 


오픈소스 프로젝트가 제 궤도에 오르면 수많은 개발자들로부터의 피드백을 받게 된다. 일일이 응대하는 것이 정신적으로 피곤한 일임은 분명하지만, 그럴만한 가치가 있는 일인 것도 사실이다. 피드백을 받기 위한 수단을 생각하고 도입하라. 구글 그룹스(google groups) 등의 온라인 포럼을 활용하면 좋다. 


5. 소스 공개 플랫폼은 신중하게 고르라


많은 사람들이 GitHub를 선호하고 있지만, 소프트웨어에 따라서는 다른 플랫폼이 더 좋을 수도 있다. 아예 독자적인 플랫폼을 꾸리는 것도 방법일 것이다. 이견이 있겠지만, 필자는 GitHub를 비롯한 Git 기반 플랫폼을 선호한다. 문제가 생길 가능성이 가장 적은 플랫폼들이기 때문이다. 



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2013.12.28 08:28

요즘 신문을 보면 개발자의 처우에 관한 글을 어렵지 않게 만날 수 있습니다. 많은 개발자들이 '갑을병정무기' 가운데 '무기'에 해당하는 하청을 하는 일도 적지 않다는 이유로, 자신을 '무기'라는 자조섞인 용어로 부르기도 한다는 이야기도 들리더군요. 그러니까 이런 기사의 요지는, 많은 개발자들이 다단계 하청구조에서 발생하는 여러가지 폐해들로 고생하고 있다는 이야기였습니다. 그런 폐해들로는 어떤 것이 있을까요?


(1) 낮은 임금

(2) 비정상적인 납기일


이 두 가지 요인은 개발자들의 삶의 질을 결정적으로 떨어뜨리고, 결국 IT 업계에서 개발자로 일하는 것을 포기하게 만듭니다. 당연한 결과죠. 월급도 코딱지만큼 주는데 비정상적인 데드라인때문에 집에도 갈 수 없는 날이 많다면, 어떤 사람이 미쳤다고 개발자로 일하고 싶어하겠어요?



그런데 문제는, 모 기사에서 지적한 것과 같이, 상황이 이런데도 아직 업체에서는 인력부족 타령을 한다는 겁니다. 그렇다면 이런 궁금증이 생길 수 있겠어요. 아니 사람이 부족한데 왜 개발자의 임금은 아직 저 모양이지? 사실 그렇짆아요. 수요는 많은데 공급이 부족하면 당연히 그 가격은 올라가야 맞습니다. 그런데 지금은 수요는 많고 공급이 절대적으로 부족한데도 개발자들의 가치가 전혀 올라가질 않아요. 비정상적이죠.


사실 이런 비정상적인 상황은, 개발자들에게 등급을 매길 때 부터 어느 정도 예견되었다고 보는 것이 옳습니다. 정부에서 나서서 모든 개발자들에게 '초급, 중급, 고급'의 딱지를 매기려고 했던 것을 여러분들은 기억하실겁니다. 그리고 그 결과, 지금 모든 개발자들은 이 바닥에서 일한 기간, 학위 소지 여부 등등 다양한 기준에 따른 '딱지'를 한 장씩 가지고 있죠. 문제는 이 딱지들이 하청 개발자들이 받을 수 있는 임금의 최대치를 규정하는 데 쓰인다는 겁니다. 


보통 하청을 줄 때 쓰는 공급 계약서를 보면, 인건비 비목이 있어요. 그런데 이 인건비 비목을 작성할 때 어떻게 쓰게 되어 있느냐면, 초급개발자 몇명 중급개발자 몇명 고급개발자 몇명을 프로젝트에 투입할 예정이냐에 따라 쓰도록 되어 있어요. 전부 고급개발자라면 인건비로 소요될 비용이 올라가게 될 것이고, 전부 초급이면 인건비로 소요될 비용은 내려가게 되어 있죠. 어쨌든 중요한 것은 말이에요. 최대치가 정해져 있다는 겁니다. 이런 상황에서는 공급이 아무리 딸리는 상황에서 하청을 줘도 하청 단가가 올라갈래야 올라갈 수가 없어요. 그러니까 하청 일을 하는 사람이 존 카멕이라고 해도 돈을 더 받을 수는 없게 되어 있다는 거죠. (응?)


그러니 많은 개발자들은 '개발자 10만 양병론'같은 이야기를 헛소리로 받아들일 수 밖에 없어요. 왜 그렇죠? 이런 형태의 시장에 개발자들을 잔뜩 양성해서 부어 놓으면 (김영삼 정부때 그랬었습니다만) 개발자 1인이 갖는 가치, 다시 말해 한 건의 프로젝트를 끝내기 위해 투입되어야 하는 인건비는 더 내려갈 것이 뻔하기 때문입니다. 아마 기업들은 당장 사람들이 부족하니까 개발자들을 더 양성해야 한다는 이야기를 하는 모양이고, 정부에서는 그런 요구에 맞춰 춤을 추는 모양인데 이런 상황을 안다면 사실 내 놓을 수 없는 정책이죠.


자. 그렇다면 대체 하청구조는 왜 생기는 거죠?


하청구조는 '내가 직접 하는 것 보다 다른 사람 시키는 것이 싸니까' 생긴다고 볼 수 있습니다. 그럼 IT 프로젝트를 하는 데 있어서, '다른 사람 시키는 것이 더 저렴한' 이유는 무엇인가요? 여러 가지 이유를 생각해 볼 수 있겠습니다. 


(1) 직접 개발하려고 해도 개발자가 없어서

(2) 외주 개발 단가가 저렴해서 


자. 제도적으로 외주 개발 단가를 올릴 방법을 차단한 현 시점에서, 외주 개발 단가는 당연히 저렴할 수밖에 없죠. 그런데 외주 개발 단가가 지금처럼 저렴해지기 전에는 하청이 없었나요? 아마 아닐 겁니다. 이 바닥에 사람이 없다는 이야기는 한 두 해 한 것이 아니고, 개발자 등급제가 시행되기 전에도 이미 하청 구조는 있었거든요. 대한민국의 개발 하청제는 역사가 깊어요. 개발자 등급제가 낮은 개발 단가를 고착시키는 역할을 하긴 했지만, 그 전에도 분명히 있었습니다. (사실 개발자 등급제 전에도 개발자들을 등급으로 나눠 분류하는 방법은 있었습니다. 그리고 그 기준에 따라 인건비를 산정했죠. 개발자 등급제는 그것을 명문화했을 뿐이라고 보는 분들도 있습니다.) 


그렇다면 이 문제는 우리가 생각하는 것 보다 훨씬 더 복잡한 것임에 분명합니다. 그리고 이 문제에 대해 올바른 답을 하려면, 다음의 질문들을 좀 더 깊이 있게 생각해 봐야 할 것이 분명해요. 


(1) 정말로 개발할 사람이 없나?

(2) 개발자들이 하청일을 떠나지 못하는 이유는 무엇인가?

(3) 하청 업체가 생기는 이유는 무엇인가?

(4) 하청 업체가 하청 일만 죽어라 하게 되는 이유는 무엇인가? 


개발할 사람이 없는 것은 사실인 것 같으니까 (저희 회사에서도 실제로 겪고 있는 문제입니다) 넘어가기로 하죠. 사실 이 문제를 깊이 있게 따지는 것은 지금의 상황에서 시간낭비에 가까와요. 우리 모두 왜 개발자가 부족한지는 알고 있는데, 이 문제의 근본적인 원인을 따지는 것은 이미 '닭이 먼저냐 달걀이 먼저냐'라는 식의 질문에 가까와서 전혀 생산적이지가 않죠. 다만 한가지는 언급할 필요가 있겠습니다. '개발자가 부족하다'는 것은 실상 정말로 개발자의 수가 적어서라기 보다는, 개발자를 뽑으려고 하는 회사가 정한 특정한 기준을 충족하는 개발자가 적다는 뜻일 수 있다는 것을요. 그렇게 본다면, 우리는 왜 개발자가 부족한지를 묻기 이전에, 대한민국에서 왜 개발자가 성장하지 못하는 지를 물어야 합니다. 그래야만, 실제로 구인 공고를 내는 회사들이 내건 기준을 충족하는 개발자들이 적은 이유가 무엇인지를 제대로 설명할 수 있을 것으로 보이기 때문이죠. 그리고 그 당위성을 인정한다면, 위의 (2)~(4)의 질문에 집중할 수 있죠. 하청구조라는 것이 개발자를 성장시키지 못하는 한 원인이 되고 있음은 분명해 보이니까요. (그렇지 않다면 개발자들이 왜 그렇게 아우성이겠어요?) 


자. 그럼 본격적으로 두 번째 질문으로 넘어가보죠. 그렇다면 개발자들이 하청일을 떠나지 못하는 이유는 무엇인가요? 하청일이 싫으면 때려 치고 다른 회사로 가면 되지 않느냐고 누가 물으면, 어떤 대답을 해 주어야 하나요? 


(1) 옮길 회사가 없다

(2) 옮겨도 마찬가지다

(3) 옮기면 받아야 할 돈을 못 받을 것 같다


[다음 글에서 계속]



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 이런식의 발전으로 국내 대기업들이 얼마나 발전할지 모르겠습니다. 새마을운동도 아니고 다같이 으쌰으쌰하는 비즈니스가 아닌 갑을관계의 착치구조는 분명 언젠가는 붕괴될거라고 굳게 믿고, 그래야한다고 생각합니다.
    대기업들의 무리한 원가절감이나, 무리한 요구에의한 lead타임감소가 아닌, SCM에 의한 물류효율화 또한 올바른 사회발전과 경제발전에 큰 힘이 된다는것을 마음 깊히 알고 실천해야, 진정한 선진 기업으로 나갈 수 있는 글로벌이 아닌가 생각해봅니다.

    2013.12.28 08:51 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2013.12.21 12:24

개발 프로젝트건, 영어 공부건 간에, 단기간에 좋은 성과를 내야 할 때가 있습니다. 그럴 때는 이렇게 해 보면 도움이 됩니다. (제 개인적인 경험에 따라 정리한 것이므로, 맘에 들지 않는 부분도 있으실 수 있습니다. 그런 부분은 가볍게 무시해주세요.)


1. 평가 일정을 먼저 잡으세요.


가령 'TOEIC 시험에서 좋은 성적을 내고 싶다'는 목표를 잡았다면, 석달 뒤에 TOEIC 시험 날짜를 미리 예약해 두세요. 그래 놓으면 중간에 포기하고 싶다는 생각은 안 들겁니다. 제가 이렇게 해서 TOEIC 시험 준비를 했는데요. 시작할 때 760점이었던 점수가 TOEIC 시험 볼 때쯤에는 만점 가까이 나왔습니다. 


2. 장기적인 목표보다 단기적인 목표에 집중하세요. 


'프로젝트를 성공적으로 마친다'는 장기적이고도 추상적인 목표보다는, 단기적이고 구체적인 목표를 잡는 것이 좋습니다. '이 클래스는 오늘 내로 리팩터링한다', '저 코드는 내일까지 디버깅을 마친다', '이 제품의 디자인은 무슨 수를 써서라도 이번 주 내로 마무리한다'. 




단기적인 목표는 집중력을 높여서 생산성을 올리는 데 도움이 됩니다. 제 경험으로는, 단기적인 목표가 명확하지 않은 주는 그냥 날리는 주였습니다. (Orz)


3. 그날 그날 무엇을 성취했는지 기록해 두세요.


저 같은 경우에는 포스트잇, 프랭클린 플래너, 그리고 하루 일정을 시간별로 적을 수 있는 수첩을 활용했습니다. 제가 가장 좋아했던 것은 기자 수첩처럼 위 아래로 긴 스프링노트였는데요. 안에 하루 일정을 시간별로 적을 수 있어서 좋았습니다. 뭔가 하나를 마칠 때 마다, 이 수첩에 '오늘, 이 시간에, 이런 일을 마쳤다'고 적었습니다. (TO-DO 리스트는 프랭클린 플래너에 적었으므로 이 수첩과 병행했습니다.) 



제가 근무하는 회사에는 '주간업무보고'라는 제도가 있는데, 이 주간업무보고 시에 사용되는 보고서를 만들 때 방금 말씀드린 스프링노트에 적은 내용을 옮겼습니다. '내가 왜 이런 일을 했고 어떻게 해결했다'까지 적은 보고서를 만들었기 때문에, 가끔 '개조식으로 한 일만 적은 보고서'와 비교하여 칭찬을 듣기도 했습니다.


이렇게 매일 매일 무엇을 했는지 기록해 두면, '장기적인 목표'에 얼마나 가까이 다가갔는지 계량적으로 측정할 수 있다는 장점도 생깁니다. 


4. 자신에게 보상을 해 주세요.


'하루 종일 자리에 앉아서 일 생각만 한다'는 목표를 세웠던 날에는, '퇴근할 때 좋은 커피를 한 잔 마신다. 오늘은 한 잔도 못 마셨으니까.' 같은 보상을 해 줍니다. '오늘 이 강의를 다 들으면, 주말에는 일 생각하지 않고 운동만 한다.' 같은 것도 제가 만들었던 보상 중 하나였습니다. 사실 그렇게 한다고 일상이 크게 달라지는 것은 아니었지만, '보상이 있다'는 생각을 하는 것 만으로도 '같은 일도 다르게 여겨지는' 일이 생기기도 합니다.


단기적인 성과를 위해 달리는 과정은 100m 달리기나 비슷해서, 지치기 쉽습니다. 스스로 마음을 달래는 보상 같은 것을 정기적으로 해 주는 것이 좋죠. (술이나 담배는 제외.) 


5. 실패는 생각하지 마세요.


그건 그 때 가서 생각해도 됩니다. 


6. 생산성을 높이는 도구를 활용하세요. 


'주석을 정말 잘 달고 싶다!' 같은 목표를 세웠다면, 그 목표를 달성할 수 있도록 해 주는 좋은 도구를 찾으세요. 대가들의 코드에서 가끔 발견되는 '주석 내 다이어그램' 같은 것이 필요하다면, AsciiFlow 같은 도구를 활용하면 좋겠죠. 



클립이던, 포스트 잇이던, 도움될 만한 모든 도구를 활용하세요. 저는 책이나 개발 스펙 문서를 읽을 때는 독서대를 사용하고, 노트북으로 장시간 작업을 해야 할 때는 노트북 스탠드를 활용하고 있으며, 구할 수 있는 가장 좋은 키보드와 마우스를 사용하고 있습니다. 하지만 뭐니 뭐니해도 가장 좋았던 도구는...


지우개 달린 노란 연필이랄까요. (수줍) 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2011.09.14 09:55
소프트웨어 개발 방법론 중 가장 널리 쓰이고 있는 것은, 아마 아직도 폭포수(waterfall) 방법론일 것 같습니다. 요구사항 분석 - 설계 - 개발 - 검증으로 이어지는 이 단순한 방법론은 그 단순성과 명료함 때문에 '그다지 심각한 고민 없이도' 현업에 도입되어 쓰이고 있습니다. 

그런데 폭포수 방법론에는 대관절 무슨 문제점이 있길래 그토록 많은 비난의 대상이 되고 있는 걸까요?

이미 많은 증거들이 있어서 사실 제가 또 언급할 필요까지는 없는건데, 집으로 돌아오는 비행기 안에서 이런 저런 생각하다보니 이런 결론에 이르게 되더군요. '단순성'

폭포수 방법론은 사실 프로젝트 진행중에 벌어지는 다양한 상황을 처리하기에는 좀 지나치게 단순합니다. 일단 요구사항 분석이 끝났다고 치죠. 그러면 설계 단계가 진행되는데, 이 와중에 새로운 요구사항이 등장한다면? 제품을 개발하는 사람들이 어떻게 대응할 것이냐와는 별개로, 방법론 자체는 그런 상황을 처리하기에 그다지 걸맞지 않습니다. 사람들이 유연하게 대처하면 괜찮습니다만, 사실 그런 지경에 이르면 '방법론'이라고 부르기 껄끄러워지죠. 지키지 않는 방법론을 과연 방법론이라고 부를 수 있을까요?

사실 폭포수 방법론은 그 단순성을 커버하기 위해 굉장히 많은 문서들을 요구합니다. (아마 해 보신분들은 아실 듯.) 가능한한 모든 시나리오를 문서에 적어두고, 그 틀을 벗어나는 상황이 벌어지지 않기를 기대하죠. 유스케이스 문서에 장황하게 적혀있는 개발 시나리오는 그 중 한 예입니다. 하지만 예외 상황(exceptional case)이 한 가지만 새로 생기더라도, 유스케이스 문서는 고쳐져야 합니다. 유스케이스 문서의 양이 너무 많아서, 대체 어디를 고쳤는지 추적하기가 좀 난감하다는 점도 문제죠.

폭포수 방법론의 대척점에 서 있는 개발 방법론들은, 그래서 가능하면 프로젝트 개발의 각 단계를 '제어 가능한' 작은 단계들로 쪼개려고 합니다. 스프린트(sprint) 같은 것은 그 좋은 예로, 한두주 단위로 쪼개진 기간 안에 설계-개발-검증을 완료하고 또 그 다음 구간에 설계-개발-검증을 반복합니다. 각각의 구간이 굉장히 짧기 때문에, 그 구간이 진행되는 만큼은 불확실성(uncertainty)을 적절히 통제할 수 있습니다. 그 구간이 끝나야만 새롭게 등장한 요구사항들을 검토할 수 있죠. (애자일 개발 방법론도 그 중 한가지입니다.) 

그런데 단순히 하나의 방법론에서 다른 방법론으로 이행한다고 해서 크게 나아지지 않는 것이 있습니다. 그건 프로젝트에 참여하는 사람 사이에 발생하는 역학관계죠. 그런 역학관계때문에 발생하는 문제를 해결하려면, 누군가는 프로젝트에 참여하는 사람에게 긍정적인 영향을 끼칠 수 있도록 수직적 관리방식에 영향력을 행사하거나, 아니면 팀원들간의 소통방식을 개선해야 합니다. 

이 문제는 사실 개발 방법론의 한 부분일수도 있고 아닐 수도 있습니다만, 적어도 프로젝트의 성공을 위해서는 반드시 고려해야 하는 부분입니다. 방법론이 달라진다고 해서 프로젝트에 대한 압박이 사라지지는 않겠습니다만, 그런 스트레스에 대응하는 내적 능력은 달라질 수 있습니다. 프로젝트를 수행하는 데 필요한 방법론을 개선하는 데 있어서 가장 크게 고려해야 하는 부분은 그런 내적 능력을 증진시켜 팀원 모두가 적절한 수준의 항상성을 유지할 수 있도록 만드는 것이 되어야 할 겁니다.

보통 스트레스가 적절한 수준 이상으로 늘어나면 그런 항상성을 유지하는 것이 불가능하기 때문에, 결국 프로젝트를 성공으로 이끄는 것은 (적절한 능력을 가진 팀원들이 모여있다는 가정 하에서) 결국 스트레스를 어떻게 관리할 것이냐 하는 부분으로 귀결되는 일이 많죠.


스트레스를 관리하는 방식은 여러가지가 있겠습니다만, 최근까지 등장한 방법들은 대략

1. 업무 시간이 일정 시간 이상이 되지 않도록 하여 팀원들이 휴식할 수 있도록 하는 방법
2. 팀원들에게 프로젝트 결과후 성과에 대한 유무형의 보상을 제시하여 감내하도록 하는 방법
3. 팀원들의 의사소통 방식을 개선하여 업무와 관련한 스트레스를 줄이는 방법
4. 프로젝트 수행에 관계된 수직적 관리 오버헤드와 태스크 스위칭을 줄이는 방법
5. 프로젝트 진도와 성과를 정량적으로 추정할 수 있도록 하여 보고 오버헤드를 줄이는 방법


등등이 있겠습니다. 이 중 5는 4와 관련이 있고, 3은 1과 관련이 있습니다. 1이 되도록 하면 가장 좋겠지만, 프로젝트 말미에는 불가능한 경우가 많기 때문에 2가 반드시 있어야 합니다. 2를 흔히 우리는 비전(vision)이라고 부르는데, 비전 없는 프로젝트가 팀원의 이직을 초래하는 경우가 많기 때문에 주의해야 합니다.

비전을 제시할 때 주의해야 할 것은, 비전에 대한 착시효과입니다. 팀원들은 비전이 없다고 생각하는데, 관리자는 비전이 있다고 생각하는 경우가 그 한 예입니다. 관리자가 보는 비전과, 팀원들이 생각하는 비전은 굉장히 많이 차이가 날 수 있습니다. 따라서 2는 3과도 관련이 있습니다. 비전이 하나로 수렴되려면, 관리자와 팀원 간의 의사소통 방식이 개선될 필요가 있습니다. 비전은 이야기하지 않으면 알 수 없는 부분 중 하나이기 때문에, 관리자와 팀원은 서로를 설득하거나 비전에 대한 간격을 줄이기 위해 애쓸 필요가 있습니다.

비전을 제시하는 가장 좋은 방법은, '무엇이 어떻게 나아질 것인지'에 대한 정량화된 지표를 제시하는 것입니다. 아쉽게도, 사람들은 '심증'이라도 없으면 아무것도 믿지 않습니다. 프로젝트가 종료된 후 팀원들이 떠나는 것은, 아무도 그 부분을 어떻게 제시할 것인지 고민하지 않기 때문이기도 합니다.

그래서 떄로 프로젝트를 관리하는 것은 단순히 야근을 하지 않는 회사를 만드는 것 그 이상입니다. 성공적인 프로젝트 개발 방법론을 만들고 싶으신가요? 어쩌면 정말로 중요한 것은 그 너머 어딘가에 있을지 모릅니다. 방법론이 잘못되어 프로젝트가 실패하는 것이 아닌지 의심하고 계시다면, 여러분의 프로젝트가 팀원들에게 어떤 비전을 제시하고 있는지 자문해 보세요. 

세상에는 비전 하나만으로 야근을 견뎌낼 사람들이, 아직은 많으니까요


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2011.04.28 16:07
언더커버 보스라는 텔레비전 프로그램이 있습니다. 회사의 CEO (그러니까 보스죠)로 하여금 회사의 밑바닥 생활을 경험하게 하는 것이 골자인 프로그램이죠.



이 프로그램의 구성은 단순합니다. CEO를 변장시켜서 회사의 말단 직원으로 투입합니다. 그런 다음 한 일주일 동안 뺑이(?)를 치게 합니다. 이 과정을 통해 CEO는 회사를 지탱하는 말단 직원들의 고충과 비효율을 경험하죠. 그런 다음 다시 자기 자리로 돌아갑니다. 그리고 나서는 그들의 근무 환경과 효율을 개선할 새로운 아이디어나 제도를 내놓고, 자신에게 풍성한(?) 교훈을 안겨준 직원들에게 포상을 합니다. 그리고는 끝.

물론 이런 식의 프로그램이 갖는 문제점을 나열하라면 한도 끝도 없습니다. 포상을 받는 직원을 제외한 다른 직원들은, 그런 기회를 누릴 자격이 없었던 걸까요? 아마 아닐 겁니다. 그러니, 오늘은 그냥 리더쉽 이야기만 하도록 하죠.

언더커버 보스라는 프로그램이 나름대로 고정 시청자를 확보하면서 지속적으로 방영되고 있는 이유를 곱씹어보면 별게 없습니다. 그저 옛 성현의 말을 그대로 실천했을 뿐이죠.

"니가 한번 해봐라. 말만큼 쉽나."

겪어 보지 않으면 모른다

일반적인 관리자들이 빠지기 쉬운 함정 중 하나는, '위에서 보면 모든 것이 단순해 보인다'라는 점입니다. 그도 그럴 것이, 관리자들이 갖게 되는 지식의 대부분은 '보고 체계'를 통해 전달된 것들입니다. 보고라는 것은 보통 텍스트와 이미지로 구성된 문서입니다. 보고하는 사람에 의해 한 번 추상화(abstraction)된 결과물이죠.

관리자는 보통 이 추상화된 결과물들이 만들어 내는 다이어그램들의 연결관계로 문제를 파악합니다. 추상화의 핵심은 단순화(simplification)입니다. 단순하게 정리되지 않은 결과물을 보고하는 사람은 없습니다. 관리자는 보통 한번에 여러 직원들과 문제들을 상대하게 마련이고, 스스로 결과물을 분석할 시간적 여력이 없습니다. 그러니 관리자에게 보고되는 내용들은 가능한 한 단순화되어야 하고, 그 과정에서 문제의 세부사항은 생략되게 마련입니다.

어떻게 보고 해야 하나

세부사항이 생략될 경우에 발생하는 가장 큰 위험은 '관리자가 보는 일정 추정치'와 '직원들이 보는 일정 추정치'가 달라진다는 점입니다. 관리자들은 태스크 스위칭 오버헤드 같은 세부사항에 신경을 쓰지 않기 때문에 직원들에게 가능한 한 많은 일거리를 주려는 경향이 있고, 이런 일거리들이 어떻게 프로젝트를 지연시키는 지에 대해서는 신경을 쓰지 않습니다.

그런 상황에서 '참 또는 거짓' 그러니까 '무엇이 됐고 무엇이 실패했다'는 식으로 보고를 하게 되면, 일정 추정치를 정확하게 만들수가 없게 됩니다. 해결책은 문제를 둘러싼 상황적 맥락(context)을 기술하는 것이죠.

문제는 '상황적 맥락'이라는 것이 굉장히 모호하다는 겁니다. 여러분은 여러분이 처한 환경을 몇 줄 만으로, 가능한한 정확하게 묘사하려는 시도를 해 보신적이 있으십니까? 상황적 맥락은 텍스트로 추상화하기 가장 어려운 부분 중 하나입니다.

문제점 리스트가 왜 중요한가

상황적 맥락을 기술하기가 어렵다면, 프로젝트 진행 중간에 발생하는 이벤트들을 기록해 두는 것이 도움이 됩니다. 이런 이벤트들은 이슈 추적 시스템(issue tracking system)을 통해서 나열해 둘 수 있습니다. 이슈들의 발생 빈도, 이슈들의 양 등을 정확하게 기록해두면, 프로젝트 중간중간에 어떤 일들이 발생했고 그 일이 어떤 환경에서 발생했으며 어떤 맥락에서 처리되었는지 확인할 수 있습니다.

문제점 리스트가 갖는 가장 큰 장점은 '관리자들이 좋아하는 추상화된 형태'로 보여주기 좋다는 점이죠. 개수, 양, 그래프 등등 고도로 추상화된 수단을 동원해 시각화하기 편하다는 거에요.말로 설명하면 납득하지 못하는 사람도, 제대로 정리된 그래프를 보여주면서 이야기하면 프로젝트 중간에 발생한 불확실성의 수준을 이해하는 경향이 있으니까요.


위의 사진에서처럼 '실제로 겪어본다는 것'에는 영감을 불러 일으키는 마력이 있습니다. 지금 관리자인 사람들도 과거에는 말단 직원이었을 거에요. '경험'이라는 것에는 마력같은 부분이 있죠. 보통 관리자들이 갖고 있는 '과거의 기억'은 윤색되기 마련입니다. '과거에 나는 이랬어!' 뭐 이런 자부심 같은 것들이죠.

문제는 그런 자부심이 나쁘다는 것이 아니라, 그런 자부심이 때로 프로젝트 진행 당사자가 겪는 문제들을 올바르게 파악하지 못하도록 방해한다는 점입니다.

언더커버 보스의 CEO들도 회사의 발전을 위해 고군분투하고 있다는 점에서는 다른 직원들과 다를 바가 없는 사람들입니다. 다만 그들에게 주어지는 정보의 양이 제한적이다 보니, 프로젝트 진도와 방향에 대해, 더 나아가서는 회사의 발전 방향에 대해 '오해'를 할 수 있다는 것이 문제일 뿐이죠.

관리자들이 여러분 주변의 문제를 더 자주 파악할 수 있도록, 눈에 잘 띄는 곳에 문제점 리스트를 두세요. 그리고 그 문제점 리스트가 왁자지껄해지도록 만드세요. 할 수 있다면, 익명 게시판 같은 형태도 나쁘진 않을 겁니다. (많은 사람들이 선호하는 방법은 아니지만요.) 그럼 아마 관리자들은 여러분들이 무슨 생각을 하고 있는지, 현장에서 무슨 일들이 벌어지고 있는지 더 잘 파악할 수 있을겁니다.

물론 어떤 관리자들은 그런 정보를 봐도 '그건 네가 잘 몰라서 그래'라고 말할지 모릅니다. 하지만 그런 상황에 처하더라도, 어떤 의미에서건 '문제를 노출한다는 것'은 좋은 거에요.

한두번이면 모르겠지만, 잽도 여러번 때리다 보면 결정적 한방이 될 수 있거든요.





신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 잘보고 갑니다

    2011.04.28 16:17 신고 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2010.10.14 07:51
소프트웨어 프로젝트를 진행할 때 여러가지 이유로 추정을 하게 됩니다. "이 일을 하는 데 시간이 얼마나 걸릴까요?" 이 질문에 답을 하는 행위를 추정(estimation)이라고 합니다. 보통 계획은 추정 결과로 나온 추정치를 보고 잡습니다.

추정이 실패하는 데에는 여러가지 이유가 있습니다. 가장 최근의 사례를 예로 들어볼까요? 어떤 작업을 하는데 A라는 사람이 한 달이 필요할 거라고 추산했습니다. A는 해당 팀에서 소프트웨어 개발에 가장 정통한 사람이라고 부를 만한 능력을 가진 사람이었습니다. 그런데 막상 뚜껑을 열고 보니,그 일은 네 시간 만에 끝났습니다. 이런 경우, 추정은 실패했다고 보아야 합니다. 하지만 실제 업무 시간이 단축된 경우이니, 정말로 부정적인 효과로 이어진 추정이라고 보긴 힘듭니다. 만일 추정 대상이 된 업무가 프로젝트의 critical chain에 물려 있는 업무였다면, 이 실패한 추정은 프로젝트 기간 단축으로 이어졌을 것이고, 아무도 피를 보지 않았을 겁니다. 하지만 반대였다면?

위에서 예로 든 업무의 경우, 추정 실패 원인으로는 다음과 같은 것들을 들 수 있었습니다.

  • cross-compiling에 대한 이해 부족
  • autoconf와 같은 툴에 대한 이해 부족

따라서, 지식(knowledge)또는 노하우(know-how)가 부족했던 것을 추정 실패의 원인으로 추상화해 볼 수 있습니다. 대부분의 프로젝트가 그렇습니다. 추정은 '잘 모르기 때문에 하는' 행위라고 생각할 수 있습니다. 잘 알고 있다면, 추정할 필요가 없습니다.

소프트웨어 개발에서, 추정의 정확도를 높이는 가장 좋은 방법은 실험(experiment)입니다. 제 경험상, 실험은 다음과 같은 범주로 나누어볼 수 있었습니다.

  • 구조 실험 (experiment on architecture)
  • 성능 실험 (experiment on performance)

구조를 실험하는 것은 소프트웨어의 구조의 정당성을 확인하는 행위이고, 성능 실험은 어떤 소프트웨어가 실제 쓰이기에 합당한 성능을 보여주는지 알아보는 행위입니다. 이런 실험은 종종 테스트(test)와 혼동되기도 합니다만, 실험이 포괄하는 범위가 좀 더 넓기 때문에, 테스트는 그 하위 개념인 것으로 보는 것이 타당합니다.

에자일 세계에서는 실험을 종종 spike라고 부릅니다. 스파이크는 뭔가 잘 모를 때, 뭘 모르는지, 그리고 무엇을 몰랐는지 알아내기 위한 유용한 도구입니다. 소프트웨어 프로젝트를 진행하는 데 있어 가장 문제가 되는 지식의 불확정성(uncertainty)을 해결하는 가장 좋은 방법 중에 하나입니다.

스파이크를 진행하고 추정을 하면 추정의 정확도를 높일 수 있지만, 불확실성이 극도로 높을 때에는 스파이크를 진행하는 데 얼마나 걸릴 지 아는 것도 어렵다는 것이 문제가 되곤 합니다. 따라서 스파이크는 굉장히 숙련도가 높고 경험이 많은 사람들 한 두 명 정도가 모여 진행하는, 굉장히 집중적인 활동이 되어야 합니다. 아니면 프로젝트 후반부에 들어가는 시간과 맞먹을 정도의 오버헤드를 낳을 수도 있습니다.

추정이 보통 프로젝트나 스프린트 초반에 일어나는 행위라는 점을 감안하면, 스파이크도 가급적이면 사전적인 활동이 되어야 합니다. 그래야 추정치의 정확도를 높일 수 있고, 추정이 실패할 확률을 낮출 수 있습니다.

그러니, 무언가를 추정해야 하는데 그 무언가가 굉장히 중요하다면, 가급적 빨리 실험을 진행하는 것이 좋습니다. 회의를 해서 해결되는 문제라면 모두 모여서 머리 싸매고 해결책을 논하는 것이 좋겠습니다만, 회의를 해서 해결될 문제가 아니라면 무작정 비관적인 추산을 하는 것 보다는 하루라도 빨리 컴퓨터 앞에 앉아서 여러가지 대안들을 검증해 보는 것이 전체 프로젝트 진행을 위해서도 바람직합니다.

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 기억상실

    동감합니다.
    추정을 하기위한 실험을 완료하면 연달아 프로그램도 완성되곤 합니다.
    결국 실험하는데 몇 일이 걸리고 공식적인 일하는데는 하루 이틀 밖에 안걸리는 셈이죠.
    이런 과정을 거치면 대부분의 경우 결과가 매우 만족스럽습니다.

    문제는 주위에서 바라보는 눈길이 곱지 못합니다.
    금새 될 일을 분석한답시고 몇일씩 끼고 앉아서 놀았다는 오해를 받지요.

    2010.10.14 10:45 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2009.09.24 13:42

오늘 또 재미있는 이야기를 하나 들었습니다.

이 프로젝트는 국내 굴지의 D모 그룹과 관계된 이야기인데요.

제가 아는 회사 한군데에 프로젝트를 줬답니다. 이 회사에서는 그 회사가 원하는 스팩 대로 성실하게 소프트웨어를 만들어서 납품하였는데... (통신 관련 소프트웨어였습니다.)

나중에 현장에 설치되고 보니 소프트웨어가 통신을 못하고 쩔쩔매는 현상이 발생하더라는 겁니다.

결국 소프트웨어 개발자가 심하게 족쳐지는 상황이 발생하였는데...

나중에 알고보니 원인은 하드웨어 때문이었습니다. 당시 관계된 회사가 하드웨어 개발사, 소프트웨어 개발사 이렇게 두 군데였는데, 하드웨어 개발사가 현장에서 자사 하드웨어로 통신 테스트를 할 때 달랑 몇 군데에서만 테스트를 해보고는 위에 "통신 잘 됩니다"라고 보고를 해 버린 겁니다.

하지만 최종 솔루션이 설치될 장소는 그렇게 만만한 장소가 아니었으니...

무선 신호가 흘러다닐 경로 곳곳마다 장애물과 전파 방해물이 존재하는, 최악의 장소였던 겁니다.

결국 장기간 수행된 프로젝트 결과물은 갈곳을 잃어버렸죠. 설계(6개월)와 개발(6개월)에 장장 1년이 걸린 프로젝트가 말입니다.

처음에 통신 테스트만 제대로 했어도 일년을 허송하지는 않았을텐데 말이에요...


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 대부분의 경우 소프트웨어의 결함은 용납치 않으면서 하드웨어의 결함은 쉽게 용서하곤 합니다.

    2009.09.24 15:25 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2009.08.31 09:42
요즘 업체와 공동 연구/개발 과제를 진행하고 있습니다.

공동 연구/개발 과제를 진행함에 있어서 최근에 느꼈던 점들을 간단하게 정리해 보겠습니다. (제가 갑의 위치이고, 공동 연구 과제를 진행하는 타 업체가 을의 관계입니다. 그러니, 제가 요구사항을 주고 그 쪽에서 그 요구사항에 맞추는 관계에 가깝습니다.)

제가 이분들과 작업을 함에 있어, Agile 적으로 진행해보려고 했습니다만, 아마 그 분들은 제가 그러고 있는지도 눈치를 잘 못채셨을 겁니다. 그냥 좀 다른 식으로 프로젝트 관리를 하는구나... 하셨겠죠. 굳이 강제한 부분이라면 일일 빌드 서버를 만들어 달라, 뭐 그정도였습니다.

1. 실무자와의 미팅에서 Pair Programming이 특히 효과적이다.

개발을 진행할 경우에, 실무자와의 미팅이 가장 중요합니다. 양쪽이 공동 개발을 진행하는 경우, 코드의 독점적인 소유권을 주장하여야 하는 부분에 있어서는 선을 지킬 필요도 있습니다만, 그렇지 않은 부분에 있어서는 실무자와 자주 대화를 갖는 것이 중요합니다. 미팅 시간은 가능한한 짧게 하고, 이슈가 되는 부분에 대해서는 집중적으로 토론을 하는 식으로 진행하여, 가급적 회의 시간이 한 시간이 넘지 않도록, 부드러운 분위기에서 진행될 수 있도록 했습니다.

이 과정에서 필요할 경우에는 Pair Programming을 진행하여 코드를 상호 검토했습니다. 가능하면 개발 쪽에서는 코드 수준에서 대화가 이루어지도록 신경을 썼습니다. 그러다보니 코드에 대한 상호 이해도가 높아져 시간이 흐르자 더욱 편안한 분위기에서 대화를 진행할 수 있었습니다.

Pair Programming이 어느 정도 익숙해지자 나중에는 전화로도 코드를 상호 검토할 수 있게 되었습니다만, 아무래도 실험 환경이 갖추어져야 확인할 수 있는 버그는 원격지에서 상호 검토하기가 어려웠습니다. 그런 부분은 어떻게 해결해야 할 지 좀 더 연구를 해 보아야 할 것 같습니다.

2. 일정을 맞추는 데는 1주 단위의 이터레이션이 효과적이다

9월 초까지 개발을 완료해야 한다는 압박때문에 1주 단위로 이터레이션을 진행한 부분이 있었습니다. 매주 이슈를 확인하고, 매주 일의 우선순위를 재검토했습니다. 다행히 우선순위가 자주 바뀌는 일은 없었습니다만, 그래도 매주 결과물을 확인하고 진도를 재검토했기 때문에 모두 긴장감을 유지하면서 작업을 진행할 수 있었습니다. 1주가 효과적으로 먹힐 수 있었던 데는 프로젝트에 참여햇던 개발자의 역량이 뛰어났던 것도 한 몫을 했겠습니다만, 매주 시연을 하고 결과물을 확인할 수 있었던 것은 아무래도 초기부터 '매주 결과물을 시연한다'는 원칙을 세우고 작업을 했기 때문에 가능했던 일일 것 같습니다. 덕분에 개발 시스템은 언제나 '통합 가능한 상태'를 유지할 수 있었습니다.

문서를 만든다거나 하는, 개발자에게 자칫 부담으로 다가올 수 있는 부분은 제가 최대한 지원하고, 남은 부분을 그쪽에서 매꿔 넣는 식으로 결과물을 만들어 냈습니다.

3. 제품 책임자(Product Owner)는 가능하면 갑과 을이라는 관계를 잊어야 한다

'마이클 콘'도 저와의 개인적 서신에서 언급한 바 있습니다만, 제품 책임자는 제품의 성공을 담보할 책임을 지는 사람이지 갑과 을의 관계를 관리하는 책임을 지는 사람이 아닙니다. 갑과 을이라는 관계는 잠시 잊고, 공동선을 추구하는 것이 바람직합니다. 가급적이면 실무에 직접 뛰어들 수도 있는 역량을 가져야 하고, 외부로부터의 갑작스러운 요구사항 변동을 적절한 수준에서 차단할 영향력도 가지고 있어야 합니다. 특히 제품 개발에 있어서 '추가될 기능의 우선순위'를 정하는 데 영향력을 행사할 수 있어야 합니다.

그래야 원활한 프로젝트 진행이 가능해 집니다. 특히 제품 책임자로서 사람들과 대화를 할 때는 가급적 NVC 원칙 (Non-violent communication) 원칙을 지키도록 해야 합니다. 대화에 감정이 끼어들기 시작하면, 소통이 불가능해집니다. 일이 꼬이고 있다면, 가급적 그 책임은 자신에게 있다는 자세를 가질 필요도 있습니다.

- - -

요즘 머리가 아픈 일이 많아서 블로그 업데이트를 잘 못했습니다. 체중도 현재 63키로입니다. (제 키는 171입니다) 운동 중독증에 가깝게 운동을 해 댄 탓도 있겠습니다만, 식사를 제때 못하거나 건너뛴 탓도 있는 것 같습니다. 가끔 들러 제 글을 기다려주신 분들께 사과말씀 드립니다.

개인적인 문제도 있습니다만, 요즘 프로젝트 일정이 너무 빡빡합니다. 9월 8일로 예정된 시연도 차질 없이 준비해야 하고요.
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. soultemple

    고생한 만큼의 결과가 나올때 기쁜거죠. 마무리 잘하시고 유익한글 남겨주시길 ...

    2009.08.31 13:06 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 재미있는 프로젝트네요.
    좀 더 많은 프로젝트가 재미있어지면 좋겠는데요...^^

    물론, 일일빌드 성공, 1주의 이터레이션, 짝프로그래밍의 적용이
    개발자에게 상당한 부담이 될 수도 있을 것 같습니다.
    중간에 한눈 팔 수 없게 하니까요...^^

    2009.09.01 10:37 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그래서 많은 부분을 개발자의 자율에 맡겼습니다. 간섭은 최대한 배재하려고 했죠. (간섭하기도 힘든 상황이었습니다만...) 어쨌든 좋은 결과를 얻고 있습니다.

      2009.09.01 13:53 신고 [ ADDR : EDIT/ DEL ]
  3. 수고하셨습니다. 후배들에게 사례로 언급해도 될까요?

    2009.09.05 14:31 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 비밀댓글입니다

    2009.12.10 13:51 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2009.02.18 13:24
순서는 아무 의미가 없으므로 개의치 마시길. CVS가 자주 언급되긴 하지만, Subversion 사용자라면 CVS를 Subversion으로 바꾸어 읽으시기만 하면 OK.

1. CVS에 남겨진 변경 로그에 아무 메시지도 적혀있지 않다

변경 로그에 아무 메시지도 남기지 않는 것은 프로그래머들 사이에는 널리 만연된 관습 가운데 하나로, 보통 '자신이 만든 코드상의 변경이 로그를 적을 만큼 중요한 것이 아니'라고 보기 때문에 저질러지는 실수이다.

어떤 종류의 변경이건, 로그는 남겨져야 한다. 그래야 다른 프로그래머들이 CI 서버로부터 유용한 정보를 얻을 수 있을 것이기 때문이다. 로그를 볼수 없다면 프로그래머는 다른 프로그래머가 자신의 모듈을 사용하면서 저지른 실수를 추적할 수 없다. 물론 그런 문제를 해결하는 가장 좋은 방법은 자신의 코드를 최대한 robust하게 만들고 타입 검사를 명확히 하고 인자 검사를 엄격히 하도록 하여 단위 테스트 단계에서 문제가 드러나도록 하는 것이다.

2. 자동 빌드를 위해 추가한 CVS 사용자 계정을 프로그래머들이 돌려쓴다

CVS 사용자 계정은 프로그래머들마다 하나씩 만들어져야 한다. 계정을 만드는 데 오랜 시간이 걸리는 것도 아니기 때문에, 하나의 계정을 돌려쓰고 있다면 그것은 CI 프로젝트 관리자가 되기에는 너무 게으르다는 뜻 밖에 되지 않는다.

3. CI 관리자가 프로그래머들과 대화를 하지 않는다

이슈 추적 시스템을 맹신하거나 CI 관리자가 본인의 능력을 너무 과대평가할 경우 흔히 벌어지는 일이다. CI 관리자는 그저 관리자일 따름이지 신이 아니기 때문에, 빌드 상에서 발생하는 문제를 스스로 해결하려고 해서는 안된다. 프로그래머들과 대화한 후에 프로그래머들이 직접 문제를 해결하도록 두는 편이 좋다. 그 편이 팀 전체의 능력 향상이나 화합에도 도움이 된다.

4. 단위 테스트 결과가 fail로 나온 이후에도 오랫동안 방치된다

이 문제의 원인은 다음과 같다.
1. 개발자가 CI 서버의 보고서를 보지 않는다.
2. 보았더라도 자기 문제가 아니라고 생각한다.

'보았더라도 자기 문제가 아니라고 생각하'는 이유는 다음과 같다.
1. 개발 서버의 문제라고 생각한다.
2. 다른 프로그래머의 문제라고 생각한다.

개발 서버의 문제가 아니라는 점을 알려주는 건 ci관리자의 몫이다. 자신이 commit한 소스로 인해 발생하는 빌드 문제는 해당 프로그래머의 문제이다. 해당 프로그래머는 자신의 소스가 필요로하는 라이브러리나 설정 파일을 지정된 디렉터리에 commit하여 빌드가 정상적으로 이루어지도록 할 의무가 있다. 그러므로 console output을 주의깊게 살펴야 한다. CI 관리자와 프로그래머간의 의사소통이 원활하지 않으면, fail된 단위 테스트나 망가진 build 프로세스는 오래 방치된다.

자신이 올린 소스가 다른 사람이 만든 테스트 케이스를 망가뜨리는 경우도 종종 있다. 이런 경우 테스트 케이스를 설계한 프로그래머와 새로운 소스 코드를 올린 프로그래머는 의사소통을 통해 문제를 해결하여야 한다. 의사소통이 되지 않으면 '서로 상대방 책임이라고 주장'하면서 fail된 단위 테스트가 방치되는 일이 생긴다.

5. 의미있는 빌드에 tag를 부여하지 않는다

CVS를 쓰건 Subversion을 쓰건 의미있는 빌드가 만들어졌다는 판단이 서면, 그 상태에 태깅을 해 주는 것이 좋다. 태깅을 하지 않는다는 것은 시스템 복원 지점을 설정하지 않고 Windows XP를 사용하는 것과 비슷한 일이다. 어떻게든 사용은 할 수 있겠지만, 비상시에 해야 하는 삽질의 양이 늘어난다는 점에서 그렇다.

6. CI 서버가 보여주는 빌드 리포트가 너무 건조하다

건조하다는 이야기는 재미가 없다는 이야기이고, 재미가 없다는 것은 빌드가 너무 평온하게 발전해 나가고 있다는 뜻이다. 빌드가 평온하게 발전해 나가고 있다는 것은 좋은 일이긴 하지만, 좀 나쁘게 해석하자면 '문제가 감춰진채로 드러나지 않고 있다'는 뜻일 수도 있다. 이럴 때는 테스트의 커버리지를 재점검하고, 테스트가 너무 말랑말랑하게 작성되어 있지는 않은지 점검해보는 것이 좋다. 테스트는 가급적 공격적인 것이 바람직하다.

[계속 수정됨...]


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. dhyi123

    CI 라는 것이 무엇의 약자인지요? CI 서버라는 것은 cvs 서버이면서 테스트도 같이 해서 리포트도 보내는 등 여러가지 역할이 있는 거 같네요. 개발자가 신규로 개발하는 경우는 해당 단위 테스트를 새로 추가해야 CI 서버도 자종으로 동작하겠죠? (제가 좀 무식해서.. ^ ^)

    2009.02.18 14:46 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • Continuous Integration의 약자입니다. Hudson, CruiseControl 등의 제품이 있는데 저는 Hudson을 사용합니다. ^^

      2009.02.18 14:53 신고 [ ADDR : EDIT/ DEL ]
  2. 이병준 선배님, 저 조영일입니다.
    오래간만에 인터넷에서 뵙네요.
    메타블로그에서 이것저것 찾다가 우연히 발견해서 들어오게 되었습니다.
    OO 전문가에 소설도 쓰시니 딱 알아보겠더라구요.
    잘 지내시죠? 식구들 모두 건강하시구요?
    둘째가 아주 귀엽던데, 건강하게 잘 크는지 궁금합니다.

    2009.02.23 18:30 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 100% 공감합니다. 특히 3번 항목은 제가 얼마전까지도 잘못 하고 있던 내용이군요.
    '불확실성과 화해하는..'책을 읽기 시작하면서 블로그 방문해 보았습니다.
    좋은 글들 많이 부탁드립니다.

    2009.03.24 13:11 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 좋은 글 잘 봤습니다. 다 공감합니다.
    1번 같은 경우는 예전에 써놓은 글이 있어서 트랙백으로 겁니다.

    2011.06.20 09:47 신고 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2008.01.22 05:55

SW 프로젝트는 일입니다. 모든 일이 다 그렇듯, 시간이 지나면 남은 일의 양은 차츰 감소하게 마련입니다. 하지만 대부분의 SW 프로젝트의 경우, 그렇지 않을 떄도 많습니다. 가장 흔한 것은, 마감 시간에 맞추어 밤을 새우는 일입니다. 일의 총량은 정해져 있을 터인데, 왜 프로젝트가 끝나갈 무렵까지 일의 양은 전혀 줄어들지 않고, 결국에는 철야를 하게 되는 것일까요?

애자일 방법론을 만든 사람들은 이 문제를 깊이 있게 연구했습니다. 그리고 그 결과, 이런 결론을 얻습니다.

일은 빵과 같다. 빵을 먹으면, 빵은 줄어든다. 일도 마찬가지이다. 일을 하면, 남은 일의 크기는 점점 작아진다. 하지만 '내가 먹으려는 이 빵이 정말로 내가 먹고 싶었던 빵인지' 한 입 베어물어 보기 전에는 정확하게 알 수 없는 것과 마찬가지로, 고객에게 소프트웨어를 인도하기 전까지는 누구도 그것이 정말로 고객이 원했던 그것인지 확신할 수가 없다.

고객이 원하지 않는 기능을 구현하게 되면, 그 기능을 구현하는 데 투자했던 시간들이 고스란히 오버헤드가 되고, 결국 고객이 정말로 원하는 기능을 구현하기 위해 프로젝트 후반부에 날밤을 새우게 됩니다. 이런 문제에 대해서는 마이크 콘(Mike Cohn)을 비롯한 여러 사람들이 많은 연구를 했고, 좋은 책도 많이 있습니다. Agile Estimating and Planning은 그 중 하나입니다.

하지만 오늘은 그 보다는 좀 더 개인적인 이야기를 해 볼까 합니다. 개인적인 견지에서 보면, 프로젝트 막바지에 더 바쁜 가장 결정적인 이유는, 프로젝트 중간 중간에 박혀있는 마일스톤 점검 시점에 반드시 해야 할 몇 가지 일들을 하지 않고 넘어갔기 때문입니다.

마일스톤 점검시에, 제가 속한 팀은 주로 그 때 까지 개발한 소프트웨어의 큰 틀이 정상동작하는지를 점검합니다. 속칭 '연동시험'을 하는 것이죠. 이 연동시험은 개발에 참여하는 여러 업체와 개발자들로 하여금 '다른 사람의 관점에서' 시스템을 바라볼 수 있도록 해 주기 때문에 굉장히 중요합니다. 그 과정에서 '개발에는 별로 적합하지 않은' 업체나 개발자가 가려지기도 하죠. ('다른 사람의 입장을 전혀 고려하지 않는 개발자'는 그 한 예가 되겠습니다. 이런 개발자일수록 '개발자의 자질'에 대해 더 많이 이야기하곤 한다는 것은 아이러니 한 일이죠. 좋은 코더가 되는 것도 중요하지만, 사실 더 중요한 것은 존중의 자세입니다.)

그런데 이 마일스톤 점검시에는 보통 자질구레한 사항이나 버그들에 신경을 쓰기 보다는, 서로 다른 사람들이 만든 시스템이 별 탈 없이 연동되어 돌아가는지를 살펴보는데 집중하는 일이 많습니다. 자잘한 문제들은 TO-DO 리스트에 적어놓는 것으로 점검을 마무리 짓곤 하죠.

문제는 그렇게 만들어진 TO-DO 리스트를 나중에는 아무도 거들떠보지 않는다는 사실입니다. 그러다보니, 데드라인이 다가오면 최종 연동시험과 병행해서 '자질구레한' 버그들도 함께 잡아 나가야 하는 일이 벌어지게 되고, 결국은 잠을 줄이게 되는 것이죠.

'엉뚱한 기능'을 구현하는 것도 위험천만한 일이지만, 진짜 '일'을 남겨두는 것도 위험천만하기는 마찬가지라는 거에요. 그런데 이런 실수를 되풀이하게 되는 이유는 대체 뭘까요?

가장 큰 이유는, 그런 '뒷마무리 작업'이 대체로 재미가 없기 때문입니다. 뭔가 그럴듯한 새 기능을 시스템에 추가하는 건 재미있습니다만, 그 부산물들을 치우는 것은 사실 지루한 일이죠. 물론, 그런 뒷마무리 작업을 충실히 할 만큼 넉넉한 시간이 주어지지 않는 경우도 있습니다. 자고 일어나면 세상은 달라져 있고 또 뭔가 새로운 요구사항은 생겨나게 마련이니까요.


PS.

이 글은 새벽 네시쯤 쓴 것 같군요.
저도 날밤을 새고 있었다는 이야기죠. ㅋㄷ



 

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. SW개발은 아니지만 나름 개발일을 하고 있는 완전공감이에요 ;ㅁ;
    내일까지 프로젝트마감을 맞추기위해 1주일전부터 완전철야중. 하루에 2~3시간밖에 못자는것 같아요 ;ㅁ;
    지금도 밤샘중 흑흑흑;;;
    왜 마지막날이 되면 온갖 수정사항들이 나오는건지 TO DO LIST가 줄질않네요.
    한개 지우면 2~3개 추가되고. orz

    2008.01.22 06:27 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그러게요. 이런 문제를 극복해 나가는 현명한 방법을 찾는 것이 개발자들이 해야 할 일이겠죠. 개인적으로는 TO-DO LIST를 관리하는 것 보다는, TO-DO BOARD(해야할 일 게시판)을 만들어 모두가 볼 수 있는 자리에 배치하는 것도 한 방법이 되지 않을까 생각하고 있습니다. 그러면 시간이 지날수록 그 게시판에 나열된 개선 항목들이 줄어드는 모습을 볼 수 있어서 좋을 거라고 생각해요. 어쩐지 '사용자 스토리'의 동어반복같다는 생각도 드는군요. 덧글 감사합니다.

      2008.01.22 06:44 신고 [ ADDR : EDIT/ DEL ]
  2. 개발자만 공감하는 얘기는 아니랍니다 ;ㅁ;
    기획자도 똑같은 짓(?)을 하고 있다죠

    제 시간관리 능력을 탓해야 겠지요 쩝

    2008.01.22 07:47 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 기획자도 개발팀의 일원이니 개발자라고 보는 것이 좋겠죠. 시간관리라는 문제를 개인 차원의 문제로 접근하면 전반적인 상황은 크게 개선되지 않을 수도 있다고 생각합니다. 가급적 팀 단위의 해결책을 찾는 것이 좋겠죠.

      2008.01.22 09:25 신고 [ ADDR : EDIT/ DEL ]
  3. 아직 프로젝트에 대한 경험이 없어서 선배분들의 얘기가 마냥 멀리 느껴집니다.OTL.....
    하지만 토이박스를 몇 번 만들어본터라 막바지에 자질구레한 일 때문에 지겹고 바빠진다는 것을 매번 느꼈습니다.;;ㅜㅜ

    2008.01.22 08:54 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그런 일들이 쌓이고 쌓이면 결국 개발이라는 것이 막판에는 재미없는 일이 되어버리겠죠.

      2008.01.22 09:26 신고 [ ADDR : EDIT/ DEL ]
  4. 저는 프로그램 개발과는 완전 거리가 먼....출판 편집을 하고 있지만 와닿네요. ㅡㅡ;;

    2008.01.22 22:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. ㅡㅡ;

    [펌] 해가겠습니다. ^^; 당연히 펌한 url 과 명시는 꼭 하겠습니다. ^^;
    감사합니다. 펌한 사이트 : http://cafe.daum.net/aspdotnet

    2008.02.13 00:36 신고 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2007.11.25 21:12
오늘 이런 글을 하나 봤습니다. 개발자 부족이 낳은 기이한 현상들이라는 제목의 글이더군요. 다른건 둘째치고 그 글에 달린 덧글들이 굉장히 인상적이었습니다. 현재 개발자로 일하고 계시는 분들이 원 글을 쓰신 분을 비난하는 듯한 덧글들이 굉장히 많았는데요. 저는 이분의 문제 제기 자체는 정당했다고 생각합니다. 다만 현재 개발자가 아닌 다른 위치에 계시는 분이니까, 같은 문제를 보는 시각이 개발자들 분과는 좀 다를 뿐입니다.

어쨌건 이 분이 지적한 문제는 대략 다음과 같습니다.

(1) 초급 개발자의 능력 문제
(2) 초급 개발자의 능력에 비해 과도한 보수
(3) 프로페셔널리즘의 부재


이중 (3)은 괜히 논란만 불러 일으킬 뿐이지 현재 상황을 생산적으로 극복하는데 별 도움은 안되는 것 같군요. 그러니 (3)은 이야기하지 않는 편이 더 나았을 겁니다. 개발자의 자존심 문제하고 관련이 있거든요.

그러면 (1)과 (2)의 문제를 생각해 보죠. 사실 (1)이나 (2) 모두 사람이 부족하니까 생기는 문제입니다. 개발자 층이 풍부하다면, 초급 개발자의 능력 문제를 따질 필요가 없습니다. 초급 개발자는 초급 개발자답게, 스스로의 역량을 키우는 데 집중하면 될 것이고, 프로젝트를 이끌어 가는 것은 중고급 개발자들이 하면 됩니다. 그럼 왜 이렇게 개발자들이 부족한 것일까요? 거기에는 여러가지 요인이 있습니다. 그 중 가장 뻔한 것 부터 살펴보죠.

A. 개발자들이 부족하기 때문이다.

네. 말장난같지만 개발자들이 부족하기 때문에 개발자들은 더 부족해지고 있습니다. 개발자들이 부족하다는 것은 프로젝트 인력 수급이 비정상적으로 될 수 밖에 없다는 것을 암시합니다. 이미 존재하는 팀이 프로젝트를 맡는 것이 아니라, 프로젝트 계약이 성사되면 그 시점에 프로그래머들을 구하기 시작합니다. (이렇게 해서 구해진 프로그래머들 대부분은 초급입니다. 중/고급 프로그래머들은 대부분 이미 다른 일이 있습니다.) 계약이 성사된 시점에 이미 데드라인은 받은 상태이고, 어떤 기능을 언제까지 내놓을지는 모호한 상태입니다. 구해온 프로그래머는 관리자 입장에서 보면 그야말로 '어디서 데려온 프로그래머들'이기 때문에, 프로젝트 관리자는 이들을 고객과 대면시킬 생각도 없고, 그럴 계획도 없습니다. (그런 경우가 대부분입니다.) 따라서 프로그래머들은 모든 지시를 프로젝트 관리자로부터 받는데, 문제는 관리자가 각각의 프로그래머의 능력을 정확하게 알지 못하므로, 이 관리자가 '누가 어떤 작업을 언제까지 마무리 지을 것이다'라는 추정을 할 경우, 그 추정은 백발백중 실패하게 되리라는 사실입니다[각주:1].

이렇게 될 경우, 결국 프로젝트 일정은 날이 갈수록 타이트해지고, 후반부로 갈 수록 빡빡해지며(원래는 일이 진척되어 갈 수록 일의 양이 줄어들어야 하잖아요?), 프로그래머에게 아무 예고 없이 요구사항 변경이 통보되는 빈도수도 증가합니다(고객과 대면할 기회가 없으니 당연하죠). 결국, 개발자들이 체감하는 삶의 질은 프로젝트가 진행될 수록 나아지고 예측 가능해 지는 것이 아니라, 프로젝트가 끝날 때 쯤 되면 완벽하게 피폐해지게 됩니다. 그러니, 개발자들이 이 바닥에서 오래 버틸 리가 있겠어요?

B. 질적인 성장을 담보하지 못한 양적인 팽창

한떄 대학교가 IT 관련 학과들의 정원을 무차별적으로 늘리면서, 업계에 몸담는 프로그래머의 수도 늘어났습니다. 한때 닷컴 열풍이 불면서, 이 때 쏟아져 나온 프로그래머들 대부분이 자연스럽게 업계로 이동했고, 프로그래머와 일자리 간의 수급 균형이 얼핏 맞는 것 같아 보이게 되었습니다.

하지만 닷컴 열풍은 오래가지 못했고, IMF가 찾아왔고, 대부분의 프로그래머들의 고용이 불안정한 지경에 놓이게 되었습니다. 어쩌면 프로그래머들이 프로그래밍으로부터 등을 돌리기 시작한 시점은 이때부터 일겁니다. 고용이 불안정한 일거리에 누가 붙어 있으려고 하나요?

하지만 그렇다고 IT 전반이 한꺼번에 죽어버린건 아닙니다. 아직도 많은 SW 프로젝트들이 만들어지고 있고, 한국 IT 인프라를 보는 많은 사람들은 아직도 긍정적인 전망을 내 놓고 있습니다. 그러다 보니 이제 프로그래머를 둘러싼 수요와 공급 간의 불균형이 두드러집니다. 아직도 프로그래머들을 원하는 새로운 일거리는 꾸준히 있는데, 소위 '쓸만한' 프로그래머는 많지 않습니다. 그러다보니 자연스럽게 중고급 프로그래머가 느끼는 일의 강도는 상승합니다. 일이 몰리는거죠. (반면에 보수는 그다지 높지 않죠.) 그러다보면 작업 결과의 질이 떨어져 '좀 쓸만해 보였던 프로그래머'가 일순간에 '생각보다는 쓸만하지 않은 프로그래머'로 전락하기도 합니다.

이런 상황에서 중고급 프로그래머가 초급 프로그래머에게 바람직한 역할 모델을 보여줄 기회는 많지 않습니다. 다들 자기 앞가림 하기에 바쁘죠. 실제로, 대부분의 중고급 프로그래머들은 자신이 몸담고 있는 IT 업계에서의 '프로그래머의 미래'를 그다지 낙관적으로 보고 있지 않습니다. 많은 사람들이 이야기하듯이, 35이 넘어가면 프로그래밍을 떠나 다른 일을 하게 될 가능성이 높지만 (정말로 이상한 현상 중의 하나입니다만) 그렇더라도 프로그래머에게 주어지는 그 '또다른 기회'의 질이 그다지 높은 것도 아니거든요.

그러다보니 이제 'IT 돌려막기'의 최전선으로 나서는 중고급 프로그래머들, 소위 이 바닥의 잘나간다는 IT 프로젝트를 왔다갔다 하면서 책임지는 새로운 프리렌서 집단이 나타나게 되었습니다. 이런 부류의 프로그래머 분들은 붙박이 직장이 주는 스트레스에서 한발 떨어져 있으면서, 자신이 가진 프로그래밍 노하우를 활용하여 더 많은 금전적 혜택을 얻고자 하는 분들입니다.

결국 업계 전반적으로 만연된 '쓸만한 프로그래머가 없다'는 푸념은 애초에 이 바닥이 양적으로 팽창했다가 차갑게 식어갈 무렵, 예정되어 있던 것이라고 보는 것이 맞겠어요. 그리고, 이런 인력 부족 현상은 초급 프로그래머에게 있어서 보다(초급 프로그래머는 어쨌던 계속해서 시장에 나오게 되어 있습니다. 많던 적던), 중고급 프로그래머들을 대상으로 훨씬 심하게 나타나고 있습니다. 이런 결과는 (1) 과도한 업무량 (2) 낮은 보수 (3) 불투명한 미래 (4) 불확실한 보장 등등이 맞불려 일어나는 현상이죠. 앞서 말씀드린 35세라는 나이 문제도 있구요. 35세 이전에 아키텍트가 되지 못하면 영원히 되지 못하는거죠 ㅎㅎ

그러니 초급 프로그래머에 대해서는 '보수' 문제가 불거지고(왜케 비싼거냐?), 회사에서는 '쓸만한 인재가 없다'는 투덜거림(쓸만한 놈들 다 어디갔어? 우리 회사에 있는 놈들은 다 왜이래?)이 나올 밖에요.

그러면 이런 문제는 어떻게 해결해야 하나요?

이런 문제를 해결하려면 IT 업체들이나 새로 이 바닥에 뛰어들려는 사람들이 개발자라는 사람이 원하는 것을 조금 더 이해하도록 노력해야 하고, IT SW 프로젝트의 라이프사이클에 대해서 좀 더 치밀한 연구를 해야 합니다. 프로그래머의 수를 늘리는 방법이 나오질 않아서 의아하시죠? 저는 지금 프로그래머의 수 자체는 적정 수준이라고 생각합니다. 중고급 프로그래머들이 적어서 문제죠. 피라미드는 피라미드인데, 밑이 너무 넓어요.

중고급 개발자의 수를 늘리려면 사실 '프로그래밍 언어를 가르치는 수준'에서 한발짝도 더 나아가지 못하는 IT 교육 과정의 문제점부터 사실 개선해야 합니다. 김창준님 같은 분에게 부탁해서 "프로그래머라면 반드시 읽어야 하는 추천 도서" 목록이라도 한번 배포하고 나면 문제가 어느 정도는 개선이 될지도 모르죠. 저는 중고급 프로그래머가 되려면 적어도 설계+구현+테스트에 필요한 잘 알려진 솔루션을 한가지씩은 섭렵하고 있어야 한다고 생각합니다. UML도 불편하지 않을 정도로 하고, 언어들 중 한두가지 정도는 불편하지 않을 정도는 쓸수 있고, 프로그램을 넘기기 전에 단위 테스트를 충실히 해야한다는 것 정도는 알고 있고, 알고리즘을 어떻게 만들고 개선해 나가면 되는지에 대한 기본적인 지식 정도는 있어야 하겠죠. (부분적인 예에 불과합니다. 이것보다 더 많은 것들이 '기본적인 지식'으로 꼽힐 수 있을겁니다.)

그런데 중고급 개발자의 층을 두텁게 하기 위해서는 사실 교육보다도 환경의 문제가 먼저 개선이 되어야 합니다. 그렇게 고된 삽질에 시달리다보면 스스로에게 지적 영감을 줄만한 깨달음을 얻기가 참 힘들죠. 만사 귀찮아지는 생활을 몇년 하다 보면 매너리즘에 젖어서 나중에는 (1) 개발에 넌덜머리가 나거나 (2) 스스로의 지식만이 최고라고 믿는 양극단 중 한쪽으로 가기가 쉽거든요. 그럼 환경의 문제는 어떻게 개선을 해야 하나요?

잘 알려진 이야기 몇 가지를 해 보죠.

  1. 여러가지 업무를 동시에 하는 프로그래머의 업무 효율은 한 가지 업무를 할 때보다 떨어진다
  2. 기능이 아닌 '활동' 기반의 프로젝트 Planning은 실패할 가능성이 높다
  3. 그러므로 Gantt Chart는 실제로는 아무 쓸모가 없다
  4. 야근을 한다고 업무 효율이 증가하는 것은 아니다
  5. 끊임없이 재검토되지 않은 요구사항은, 프로젝트 말미에 가면 아무도 원하지 않는 요구사항이 될 가능성이 높다
  6. 따라서 요구사항은 끊임없이 재검토 해야 한다
  7. 일정을 맞추기 위해 제품의 질을 희생하는 것은 좋은 생각이 아니다
  8. 일정을 맞추기 위해 새로운 프로그래머를 채용하는 것은 그다지 큰 효과가 없다
아마 이런 이야기들을 한귀로 흘려듣지 않고 좀 깊게 생각해 볼 화두로 받아들이기만 해도, IT 프로젝트가 실패하거나 프로그래머들에게 고통을 줄 가능성은 굉장히 줄어들 겁니다.

프로그래머와 프로젝트가 win-win할 수 있는 가장 좋은 방법은, 프로젝트를 planning할 때 프로그래머를 참여시키는 것입니다. (물론 그러려면 프로젝트가 요구사항을 검토하기 시작할 때 부터 이미 팀은 꾸려져 있어야 합니다.) 프로그래머가 추정한 일정이나 규모 추정치를 가장 현실적인 것으로 받아들이고, 야근과 같은 잔업을 프로젝트 일정 추정 과정에서 철저히 배재시켜야 프로그래머도 인간적인 환경에서 일을 할 수 있고, 프로젝트도 그 일정에 관한 한 보다 현실적인 추정을 할 수 있습니다. 현실적인 추정이 될 때, 그에 기반한 계획(Planning)이 가능하고, 그런 계획이 만들어질 때 프로그래머는 계획한 일을 하고 남는 시간을 자신을 위해 투자할 수 있습니다. 프로그래머는 프로젝트를 진행하는 사람이지 간트 차트에 그려진 일정을 맞추기 위한 기계나, 프로젝트의 소모품이 아닙니다. 프로그래머도 쉴때는 쉬어야 합니다. 일자리가 주는 삶의 질이나 기회가 높아질 때, 초급이 중급으로, 그리고 중급이 고급 프로그래머로 나아갈 수 있습니다. 그때가 되면 아마 "쓸만한 개발자가 없어"라는 말도 좀 덜 나올 수 있겠죠. "쓸만한 개발자"는 사실 "여러분 주변"에 있는 개발자입니다. 조직이 그 사람들에게 "쓸만한 개발자로 스스로를 갈고 닦을 시간"을 주지 않거나, "머리를 좀 굴려서 눈 앞의 석탄을 다이아몬드로 바꿀 방법을 고안해 낼 시간"을 주지 않기 때문에 쓸만한 개발자로 보이지 않을 뿐입니다.

그리고 중고급 프로그래머를 나이가 좀 들었다고 다른 업무로 돌리는 식의 인사 행태도 좀 달리 생각해봐야 합니다. 그런 분들이 프로젝트 초기 부터 SW 아키텍처 작업에 주도적으로 참여하고 Chief Programmer로서 일하게 되면, 최종적으로 나오게 될 프로그래밍 결과물은 굉장히 달라질 수 있습니다.

물론 이렇게 이야기하면 또 이런 질문이 나올겁니다.

A. 사람이 없는데 어떻게 인간적인 일자리를 만드나?
B. 일정이 빡빡한데 어떻게 그렇게 낭만적으로 일할 수 있나?

A에 대해서라면, 인간적인 근무환경을 보장하는 것으로 프로그래머들을 모을 수 있다는 사례 1 2가 있습니다. B에 대해서라면, 위에 언급한 '잘 알려진 이야기'들에 대한 연구 사례들을 조금 더 주의깊게 읽어 보셔야 할 것 같습니다. 이 '잘 알려진 이야기'들은 전부 지금의 IT 바닥에서 매일같이 일어나고 있는 일들에 대한 아주 '현실적인' 이야기들입니다. 프로그래머를 족친다고 문제가 해결되는게 아니라구요! ㅋㅋ

  1. 추정을 정확하게 하려면, 고객이 '자신이 원하는 기능'에 대한 명세를 개발자들에게 보여주고, 개발자들이 그 기능을 구현하는 데 소요될 시간을 추정하게 한 다음에, 그에 기반해서 최종 소프트웨어에 탑재할 기능을 취사선택하도록 해야 합니다. 개발자들이 정확한 추정을 할 지 못믿으시겠다구요? 그러면 본인의 추정치는 무슨 근거로 확신하세요? [본문으로]
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 늙은개발자

    정확히 합시다. 부족한게 아닙니다.
    전혀...

    다만 마구 양성했던 싼값에 진행했던 또는 그런데로 진행되고 있다고 느끼게 했던 그
    현상이 사라져서 느끼는게 부족하게 느끼는거죠...

    부족이란 말과 적정 및 과도하다는 말은 공급쪽 팩터에 뭔가 균형을 헤치는
    힘이 존재하기 때문인데.. 그런게 과도한 적은 있었지만.. ( 정부 지원 학원 난립시절 )
    현재를 보면 수요나 공급쪽에 전혀 인위적 개입이 없습니다. 수요가 크면
    공급은 일어납니다만.. 현재 전혀 공급이 늘어나지 않는것은 수요가 사실 없기 때문입니다.

    그냥 막연히 업계 시공사에서 하는 말은 무시하세요. 안되면 말마따나 인도쪽이나 배트남쪽을
    알아보겠죠.

    중요한건..... 부족이라고 판단하는것 자체가 어떤 근거가 있는게 아니라는 겁니다.
    게다가 초보가 월 300이라니? 란 말도 전혀 근거가 없는 그냥 감정상의 느낌일 뿐이라는 거죠...
    과거와 비교되기 때문에 느껴지는 그런 느낌.

    엔지니어이거나 과학자라면... 그냥 느낌으로 판단해서는 안되겠죠? 애초에 엔지니어 공급을
    양쩍으로 팽창시킨다고해서 산업이 건강해지는건 아닙니다. 생태계가 건강해야죠.... ^^

    또 한번 느낌으로 일을 저지르면 ( 학원에 돈 퍼주기 같은거 다시 하면..)
    이젠 영영 복구하기 힘든 지경이 될겁니다.

    2007.11.30 11:37 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 늙은개발자

    참고로 ...

    보통의 기업에서 경영기획이나 관리파트사람들은 판단을 느낌 + 읽었던 책에 나온말..
    로 하는 경향이 있습니다. 원글자 ( 기이하다고 했던.)
    도 MIS 관련일을 했을수는 있지만.

    실제 엔지니어는 아니었을거라고 짐작합니다. ( 학교에서 배웠다 하더라도
    실무를 직접했던 경험이 많지 않은 경우나 바로 PM 생활했거나..)

    2007.11.30 11:40 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 늙은개발자

    님의 잘알려진 사항들 잘 읽어보시면..

    고객이 무지 좋아하는 걸로 이루어져 있지요?

    기이하다고 했던 분도 저같은 코더들에게는 다른

    고객과 별로 차이없는 어쩌면 더 난해한 고객입니다.

    2007.11.30 11:42 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그 '잘 알려진 사항'들은 고객이 좋아하는 사항은 아닙니다. 사실은 개발자가 몸담고 있는 조직에서 조차도 그닥 선호하는 이야기는 아니죠. '그분들'은 그렇게 기민하게 반응하면 애초에 계획했던 대로 프로젝트가 굴러갈 리 없다고 믿거든요.

      위의 '잘 알려진 사항'은 '비현실적 추정'으로 프로그래머들을 압사시키는 대신 '현실적인 추정'이 이루어져야 한다는 연구결과입니다. 고객에게 만족스러운 부분은 아마 고객이 프로젝트 진행 중에 요구사항을 바꾸는 것이 '당연한 현상'이라고 보는 부분 정도일거에요.

      하지만 그것을 '당연한 현상'이라고 보지 않으면, 프로젝트 말미에 '이미 완결된 아키텍처까지도 뒤엎어야 하는' 일이 발생할 가능성이 점점 더 높아집니다.

      요는, 그런 요구사항 변화에 기민하게 대응할 수 있으면서, 프로그래머에게 인간적인 근무 환경을 보장할 수 있으려면, 현실적인 추정과 그에 입각한 프로젝트 플래닝이 이루어져야 한다, 뭐 그런 겁니다. :-)

      와주셔셔 감사합니다. 좋은 의견 주신 점도 감사드립니다.

      2007.12.01 06:49 신고 [ ADDR : EDIT/ DEL ]
  4. 늙은개발자

    일이 몰리면 초급하나 더 밖아주고..
    일정이 반으로 줄거라고 생각하죠.. 머리들은..

    2007.12.18 13:06 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그런 분들에게는 "프로그래머의 수가 늘어난다고 프로젝트가 빨리 끝나지는 않는다"는 연구 결과를 보여드리는게 좋을 것 같습니다. agile.egloos.com 어딘가에서 읽었었는데 링크를 다시 찾아보려니 못찾겠네요.

      2007.12.18 13:29 신고 [ ADDR : EDIT/ DEL ]