<div id="readability-page-1" class="page"><div><p><img src="https://velog.velcdn.com/images/joosing/post/c63f61b1-d0bd-4191-b245-bb7b862c90cf/image.png"></p>
<h3 id="소프트웨어-개발의-불확실성">소프트웨어 개발의 불확실성</h3>
<p>개인적인 경험으로 소프트웨어 개발은 다른 엔지니어링 분야에 비해 불확실성이 높다고 생각한다. 똑같은 팀과 거의 비슷한 제품을 찍어내듯 매번 개발한다면 해야할 일이 명확하고 얼마만에 일이 되어질지도 예상할 수 있겠지만 현실의 일은 그렇지 않다. 제품을 개발하기 위해서 우리가 해야할 일은 무엇무엇인지 (개발을 시작하는 시점에는) 불확실하고 그것을 해내는 팀의 역량도 측정된 적이 없다. </p>
<h3 id="보다-확실한-기계-엔지니어링">보다 확실한 기계 엔지니어링</h3>
<p>기계 엔지니어 출신의 리더가 어떤 제품 (또는 기능)을 언제언제까지 만들 수 있겠냐고 확답을 요구하듯 물어온 적이 있다. 그와 대화하다 보니 기계 엔지니어들은 소프트웨어 개발 프로세스와 거의 동일한 프로세스를 가지고 있었다. 분석, 설계, 제작(구현), 시험의 과정을 그들도 거친다. 반면에 소프트웨어 프로세스와 달랐던 부분은 그들은 어떤 제품을 만들기로 하면 대략의 일정 예측이 가능하다고 했다. 해야할 일들이 명확하고 프로세스도 분명하다고 했다. </p>
<h3 id="oo-미터를-15초에-달릴-수-있어">OO 미터를 15초에 달릴 수 있어?</h3>
<p>나는 그런 이들에게 이런 설명을 해준다. 누군가 100미터를 15초에 달릴 수 있겠냐고 물어오면 예, 아니오로 분명하게 대답할 수 있다. 그런데 네가 몇 미터를 달려야 하는지는 모르상태에서 15초에 달릴 수 있냐고 물어온다면 너무 당연하게 나는 답을 할 수 없다. 현실 세계에서 소프트웨어 개발 과정에 이런 일은 무수히 일어난다. 내가 몇 미터를 달려야하는지 확인해 볼 시간도 없이 몇 초에 달릴 수 있냐부터 물어오는 것이다. 그리고 몇 초에 개발이 완료되길 바라며 개발을 시작한다. </p>
<h3 id="100미터를-10초에-달리면-1000미터는-100초에-달릴-수-있어">100미터를 10초에 달리면 1000미터는 100초에 달릴 수 있어?</h3>
<p>만약 내가 달릴 거리가 몇 미터인지 정확히 안다 치더라도(실제 그런 일은 없지만) 그 거리가 10 키로미터, 100 키로미터 같이 길어지면 수학 공식에서 배수를 곱하듯 일정을 예측할 수 없다. 소프트웨어를 개발은 단순하게 100미터를 15초에 달리면 1000미터를 150초에 달릴 수 있다고 보장할 수 없다. 달리기 역시 100미터를 15초에 달려본적이 있다고 해서 1000미터를 단순히 10배 해서 계산할 수 없을 것이다. 소프트웨어는 분석과 설계 과정을 거치며 점점 구체적인 모습을 드러낸다. 많은 경우는 코드를 작성하다가 실제적인 모습을 드러내기도 하고 어떤 경우 소프트웨어의 진짜 모습은 테스트를 통해 발견되기도 한다. 구현할 때까지 완전 잘못 알고 개발한 것이다. </p>
<h3 id="네가-생각하는-일정의-단위를-바꿔">네가 생각하는 일정의 단위를 바꿔</h3>
<p>이 처럼 소프트웨어 개발은 정말 불확실성이 높다. 그리고 일정 예측이 매우 어렵다. 많은 선배 개발자들이 농담반 진담반으로 네가 생각하는 일정에 3배를 하라고 한다. 더러는 네가 생각하는 일정의 단위를 바꾸라고 까지 한다. (3일 걸릴 것 같으면 3주로 바꾸라고) 이런 말들은 그저 농담삼아 만든 말이 아님이 확실하다. 실제로 3일이라고 생각했던 일이 3주가 걸리기도 하고 3개월이면 끝날 것 같은 일이 1년이 걸리기도 한다. </p>
<h3 id="우리는-분석과-설계가-필요해">우리는 분석과 설계가 필요해</h3>
<p>여러 대화를 통해서 우리 회사는 제품(소프트웨어를 포함하는)을 만들기 위해 우리가 해야할 일은 무엇인지 분명하게 하는 분석과 설계 단계에 조금 더 많은 시간을 투자해야 한다고 설명했다. 코드를 작성할 사람이 부족한게 아니라(물런 그런 사람도 지금 조금 부족하다고 느끼지만) 제품을 만들기 위해 우리가 해야하는 일이 무엇인지 분석해 내고 설계해 내는 사람이 절대적으로 부족하다고 느낀다. 제품이 완성되기 위해서 큰 그림을 가지고 있지 못한채 즉흥적으로 튀어나오는 해야할 일에 이리저리 휘둘려서는 안 그래도 불확실성이 높은 프로젝트를 제대로 이끌 수 없다고 생각한다. </p></div></div>

Joo's Work

JooSing

소프트웨어 개발의 불확실성
개인적인 경험으로 소프트웨어 개발은 다른 엔지니어링 분야에 비해 불확실성이 높다고 생각한다. 똑같은 팀과 거의 비슷한 제품을 찍어내듯 매번 개발한다면 해야할 일이 명확하고 얼마만에 일이 되어질지도 예상할 수 있겠지만 현실의 일은 그렇지 않다. 제품을 개발하기 위해서 우리가 해야할 일은 무엇무엇인지 (개발을 시작하는 시점에는) 불확실하고 그것을 해내는 팀의 역량도 측정된 적이 없다. 
보다 확실한 기계 엔지니어링
기계 엔지니어 출신의 리더가 어떤 제품 (또는 기능)을 언제언제까지 만들 수 있겠냐고 확답을 요구하듯 물어온 적이 있다. 그와 대화하다 보니 기계 엔지니어들은 소프트웨어 개발 프로세스와 거의 동일한 프로세스를 가지고 있었다. 분석, 설계, 제작(구현), 시험의 과정을 그들도 거친다. 반면에 소프트웨어 프로세스와 달랐던 부분은 그들은 어떤 제품을 만들기로 하면 대략의 일정 예측이 가능하다고 했다. 해야할 일들이 명확하고 프로세스도 분명하다고 했다. 
OO 미터를 15초에 달릴 수 있어?
나는 그런 이들에게 이런 설명을 해준다. 누군가 100미터를 15초에 달릴 수 있겠냐고 물어오면 예, 아니오로 분명하게 대답할 수 있다. 그런데 네가 몇 미터를 달려야 하는지는 모르상태에서 15초에 달릴 수 있냐고 물어온다면 너무 당연하게 나는 답을 할 수 없다. 현실 세계에서 소프트웨어 개발 과정에 이런 일은 무수히 일어난다. 내가 몇 미터를 달려야하는지 확인해 볼 시간도 없이 몇 초에 달릴 수 있냐부터 물어오는 것이다. 그리고 몇 초에 개발이 완료되길 바라며 개발을 시작한다. 
100미터를 10초에 달리면 1000미터는 100초에 달릴 수 있어?
만약 내가 달릴 거리가 몇 미터인지 정확히 안다 치더라도(실제 그런 일은 없지만) 그 거리가 10 키로미터, 100 키로미터 같이 길어지면 수학 공식에서 배수를 곱하듯 일정을 예측할 수 없다. 소프트웨어를 개발은 단순하게 100미터를 15초에 달리면 1000미터를 150초에 달릴 수 있다고 보장할 수 없다. 달리기 역시 100미터를 15초에 달려본적이 있다고 해서 1000미터를 단순히 10배 해서 계산할 수 없을 것이다. 소프트웨어는 분석과 설계 과정을 거치며 점점 구체적인 모습을 드러낸다. 많은 경우는 코드를 작성하다가 실제적인 모습을 드러내기도 하고 어떤 경우 소프트웨어의 진짜 모습은 테스트를 통해 발견되기도 한다. 구현할 때까지 완전 잘못 알고 개발한 것이다. 
네가 생각하는 일정의 단위를 바꿔
이 처럼 소프트웨어 개발은 정말 불확실성이 높다. 그리고 일정 예측이 매우 어렵다. 많은 선배 개발자들이 농담반 진담반으로 네가 생각하는 일정에 3배를 하라고 한다. 더러는 네가 생각하는 일정의 단위를 바꾸라고 까지 한다. (3일 걸릴 것 같으면 3주로 바꾸라고) 이런 말들은 그저 농담삼아 만든 말이 아님이 확실하다. 실제로 3일이라고 생각했던 일이 3주가 걸리기도 하고 3개월이면 끝날 것 같은 일이 1년이 걸리기도 한다. 
우리는 분석과 설계가 필요해
여러 대화를 통해서 우리 회사는 제품(소프트웨어를 포함하는)을 만들기 위해 우리가 해야할 일은 무엇인지 분명하게 하는 분석과 설계 단계에 조금 더 많은 시간을 투자해야 한다고 설명했다. 코드를 작성할 사람이 부족한게 아니라(물런 그런 사람도 지금 조금 부족하다고 느끼지만) 제품을 만들기 위해 우리가 해야하는 일이 무엇인지 분석해 내고 설계해 내는 사람이 절대적으로 부족하다고 느낀다. 제품이 완성되기 위해서 큰 그림을 가지고 있지 못한채 즉흥적으로 튀어나오는 해야할 일에 이리저리 휘둘려서는 안 그래도 불확실성이 높은 프로젝트를 제대로 이끌 수 없다고 생각한다.

소프트웨어 개발의 불확실성 : OO 미터를 15초에 달릴 수 있어?

댓글