<div id="readability-page-1" class="page"><div><p>Image by&nbsp;<a href="https://pixabay.com/ko/users/startupstockphotos-690514/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=3267505">StartupStockPhotos</a> from <a href="https://pixabay.com/ko//?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=1728448">Pixabay</a></p>
<p><img src="https://velog.velcdn.com/images/joosing/post/5321aac1-c68a-4275-8887-7dea99204605/image.png"></p>
<p>하드웨어를 다루는 회사에 오래동안 다녀왔지만 이런 느낌의 회사는 낯설다. 말로만 듣던 스타트업 문화라는게 이런 건가 하는 생각이 든다. ‘이게 정말 된다고?’ 같은 미션이 도처에 있고 기존의 상식과 프로세스로는 안될 것만 같은 일들이 널려있다. </p>
<h2 id="팀의-마인드">팀의 마인드</h2>
<p>팀은 기존의 관행(특히 국가 기관)에서 파편화 되어 거추장스럽던 일들을 하나로 단순화 해버리려는 마인드를 가지고 있는 것 같다. 그래서 불필요한 커뮤니케이션 비용을 제거해 일이되는 속도를 높이려는 것 같다. 완벽한 하나의 제품을 완성하기 보다는 일단 되게 해보자는 마인드로 뭔가를 만들고 있는 것 같다. 해봤다는 선 경험을 만들고자 하고, (가능한 실패를 하지 않으려 하지만) 만약 실패한다면 그것을 통해 의미있는 학습을 하자는 마인드를 가진 것 같다. </p>
<h2 id="불안감을-동반하는-애자일">불안감을 동반하는 애자일</h2>
<p>애자일이라는 말을 리더가 자주 꺼낸다. 애자일은 폭포수 모델과 비교했을 때 어떤면에서 불안정한 느낌을 준다. 폭포수 모델은 개발 초기에 제품에 요구되는 기본적인 전체 요구사항을 식별하고 개발을 시작한다. 이 초기 요구사항이 완벽하고 구체적이지는 않지만 전체를 커버할 수 있도록 식별된 뒤에 분석과 설계를 통해 점점 구체화된다. 그리고 구현을 통해 코드로 실현되고 테스트를 통해 검증되는 과정을 거쳐 고객에게 전달된다. 그러나 설계 과정에서, 구현 과정에서, 테스트 과정에서 앞 단계에서의 결과물에 대한 피드백을 받게 되고 이전 결과물에 수정이 생기며 뒤로 다시 돌아가기도 한다. 폭포수 모델도 (폭포처럼) 한 방향으로만 흘러가지는 않는다. 다만 애자일 모델과의 중요한 차이는 초기에 어느 정도 전체를 아우르는 요구사항을 식별하고 그것에서 출발하냐 아니냐가 핵심이 되는 듯 하다. 초기에 전체를 아우르는 뭔가가 손에 잡히면 안정적인 느낌을 받는다. 정확하지는 않을지라도 어느정도 일정을 예상할 수도 있다. 비슷한 제품을 반복해서 만들다보면 이게 가능해 진다. 반면에 애자일은 전체를 아우르는 요구사항(즉 제품의 전체 모습)이 무엇인지 미리 알기 어려울 때 적합하다. 낯선 무언가를 처음 만들다 보면 이렇게 되곤 한다. 애자일은 하나씩 도전해보며 살아있는 요구사항을 학습하고 다음 방향을 생각한다. 스프린트라는 것을 반복하며 생동감있게 방향을 조정해 나간다. 이 방법은 약간의 불안감을 동반한다. 다음에 무슨 요구사항이 나타날지 미지의 세계이고 궁극적으로 무엇이 만들어질지 완전히 예상하고 만들기를 시작하는 것이 아니기 때문이다. 전체 일정 또한 예측이 어려워 얼마를 투자하면 가치있는 제품이 완성될지 예상이 잘 안된다. 만약 우리가 진짜 제품의 모습을 미리 알 수만 있다면 (그게 잘못된 이미지가 아닌 것이 확실하다면) 그것을 미리 정의해 두고 개발을 시작하는것이 확실히 더 안정감이 있다. </p>
<h2 id="잘못된-길로-곧게-나아가는-폭포수-모델">잘못된 길로 곧게 나아가는 폭포수 모델</h2>
<p>그러나 우리가 제품의 모습을 미리 알 수 없는데 미리 그것을 정의하고 업무를 시작하면 우리는 틀린 방향으로 곧게 나아갈 수 있다. 결국은 업무의 특성에 따라 애자일이냐 폭포수 모델을 따를 것인가 결정되어야 하는 것이다. 한 번도 본적이 없는 제품에 대한 전체 그림을 미리 그리려고 멈춰서서 고민해 본다면 시간만 낭비할 수 있다. 미리 볼 수 없는 성질의 것을 미리 보려고 애써보았자 보이지 않거나 잘못된 이미지를 그리고 오히려 잘못된 방향으로 굳게 나아가기 때문이다. 따라서 이때는 멈추지 않고 일단 눈 앞에 보이는 것을 시도해 보고 작은 결과를 보며 이 길이 맞는지 한 걸음씩 나아가 보는 것이 더 낫다. 그렇게 나아갈 방향 자체를 찾아가는 것이다. 그렇게 시간이 지나면 만들고자 하는 것이 점점 분명해 지게 될 것이다.</p>
<h2 id="애자일이라고-불러도-되는가">애자일이라고 불러도 되는가?</h2>
<p>우리 일은 어느 쪽에 가까운가? 우리는 정말 미리 제품의 그림을 그릴 수 없어서 애자일하게 일하는가? 아니면 우리가 해야할 일은 세상 어딘가에 이미 확정되어 있거나, 또는 (현재 정해져 있지는 않지만) 노력해서 미리 확정해 나갈 수 있는 것들인데 그냥 애자일이라고 부르고 있는 것은 아닌가? 분명 고민해볼 문제이다. 나는 우리는 후자에 가깝다는 생각이 든다. 만들어야 할 스펙은 이미 어딘가에 정해져 있거나, 노력해서 미리 정해갈 수 있는 것 같다. 우리에게는 데드라인도 있다. 우리가 해야하는 일이 무엇인지 전체를 식별하고 데드라인 안에 할 수 있는지 리뷰도 하고, 할 수 없다면 사람을 더 투입하거나 스펙을 걸러내거나 하는 노력이 분명 필요한 시점이라 생각된다. 함께 고민하고 우리의 방향을 수정해야 할 때라는 생각이 든다.</p></div></div>

Joo's Work

JooSing

Image by StartupStockPhotos from Pixabay
하드웨어를 다루는 회사에 오래동안 다녀왔지만 이런 느낌의 회사는 낯설다. 말로만 듣던 스타트업 문화라는게 이런 건가 하는 생각이 든다. ‘이게 정말 된다고?’ 같은 미션이 도처에 있고 기존의 상식과 프로세스로는 안될 것만 같은 일들이 널려있다. 
팀의 마인드
팀은 기존의 관행(특히 국가 기관)에서 파편화 되어 거추장스럽던 일들을 하나로 단순화 해버리려는 마인드를 가지고 있는 것 같다. 그래서 불필요한 커뮤니케이션 비용을 제거해 일이되는 속도를 높이려는 것 같다. 완벽한 하나의 제품을 완성하기 보다는 일단 되게 해보자는 마인드로 뭔가를 만들고 있는 것 같다. 해봤다는 선 경험을 만들고자 하고, (가능한 실패를 하지 않으려 하지만) 만약 실패한다면 그것을 통해 의미있는 학습을 하자는 마인드를 가진 것 같다. 
불안감을 동반하는 애자일
애자일이라는 말을 리더가 자주 꺼낸다. 애자일은 폭포수 모델과 비교했을 때 어떤면에서 불안정한 느낌을 준다. 폭포수 모델은 개발 초기에 제품에 요구되는 기본적인 전체 요구사항을 식별하고 개발을 시작한다. 이 초기 요구사항이 완벽하고 구체적이지는 않지만 전체를 커버할 수 있도록 식별된 뒤에 분석과 설계를 통해 점점 구체화된다. 그리고 구현을 통해 코드로 실현되고 테스트를 통해 검증되는 과정을 거쳐 고객에게 전달된다. 그러나 설계 과정에서, 구현 과정에서, 테스트 과정에서 앞 단계에서의 결과물에 대한 피드백을 받게 되고 이전 결과물에 수정이 생기며 뒤로 다시 돌아가기도 한다. 폭포수 모델도 (폭포처럼) 한 방향으로만 흘러가지는 않는다. 다만 애자일 모델과의 중요한 차이는 초기에 어느 정도 전체를 아우르는 요구사항을 식별하고 그것에서 출발하냐 아니냐가 핵심이 되는 듯 하다. 초기에 전체를 아우르는 뭔가가 손에 잡히면 안정적인 느낌을 받는다. 정확하지는 않을지라도 어느정도 일정을 예상할 수도 있다. 비슷한 제품을 반복해서 만들다보면 이게 가능해 진다. 반면에 애자일은 전체를 아우르는 요구사항(즉 제품의 전체 모습)이 무엇인지 미리 알기 어려울 때 적합하다. 낯선 무언가를 처음 만들다 보면 이렇게 되곤 한다. 애자일은 하나씩 도전해보며 살아있는 요구사항을 학습하고 다음 방향을 생각한다. 스프린트라는 것을 반복하며 생동감있게 방향을 조정해 나간다. 이 방법은 약간의 불안감을 동반한다. 다음에 무슨 요구사항이 나타날지 미지의 세계이고 궁극적으로 무엇이 만들어질지 완전히 예상하고 만들기를 시작하는 것이 아니기 때문이다. 전체 일정 또한 예측이 어려워 얼마를 투자하면 가치있는 제품이 완성될지 예상이 잘 안된다. 만약 우리가 진짜 제품의 모습을 미리 알 수만 있다면 (그게 잘못된 이미지가 아닌 것이 확실하다면) 그것을 미리 정의해 두고 개발을 시작하는것이 확실히 더 안정감이 있다. 
잘못된 길로 곧게 나아가는 폭포수 모델
그러나 우리가 제품의 모습을 미리 알 수 없는데 미리 그것을 정의하고 업무를 시작하면 우리는 틀린 방향으로 곧게 나아갈 수 있다. 결국은 업무의 특성에 따라 애자일이냐 폭포수 모델을 따를 것인가 결정되어야 하는 것이다. 한 번도 본적이 없는 제품에 대한 전체 그림을 미리 그리려고 멈춰서서 고민해 본다면 시간만 낭비할 수 있다. 미리 볼 수 없는 성질의 것을 미리 보려고 애써보았자 보이지 않거나 잘못된 이미지를 그리고 오히려 잘못된 방향으로 굳게 나아가기 때문이다. 따라서 이때는 멈추지 않고 일단 눈 앞에 보이는 것을 시도해 보고 작은 결과를 보며 이 길이 맞는지 한 걸음씩 나아가 보는 것이 더 낫다. 그렇게 나아갈 방향 자체를 찾아가는 것이다. 그렇게 시간이 지나면 만들고자 하는 것이 점점 분명해 지게 될 것이다.
애자일이라고 불러도 되는가?
우리 일은 어느 쪽에 가까운가? 우리는 정말 미리 제품의 그림을 그릴 수 없어서 애자일하게 일하는가? 아니면 우리가 해야할 일은 세상 어딘가에 이미 확정되어 있거나, 또는 (현재 정해져 있지는 않지만) 노력해서 미리 확정해 나갈 수 있는 것들인데 그냥 애자일이라고 부르고 있는 것은 아닌가? 분명 고민해볼 문제이다. 나는 우리는 후자에 가깝다는 생각이 든다. 만들어야 할 스펙은 이미 어딘가에 정해져 있거나, 노력해서 미리 정해갈 수 있는 것 같다. 우리에게는 데드라인도 있다. 우리가 해야하는 일이 무엇인지 전체를 식별하고 데드라인 안에 할 수 있는지 리뷰도 하고, 할 수 없다면 사람을 더 투입하거나 스펙을 걸러내거나 하는 노력이 분명 필요한 시점이라 생각된다. 함께 고민하고 우리의 방향을 수정해야 할 때라는 생각이 든다.

애자일이라고 불러도 되는가?

댓글