부트캠프를 수료하고 나서,
내가 아는 개발자분들과 이야기하던도중 몇 가지의 책을 추천 받았는데,
그 중의 한권인 소프트웨어 장인이라는 책을 읽은 회고를 하고자 한다.
산드로 만쿠소 지음 /권오인 옮김 /길벗
이 책에서는 소프트웨어 장인이 되기 위한 이념이나 태도에 대해서 저자의 생각이 잘 정리되어져 있는데, 사실 여태까지 개발관련으로 책을 읽어보거나, 방법론적인 부분은 한번도 고려를 해보지 않은데다가, 이제 막 프로젝트 1~2개 정도(부트캠프에서 2주짜리, 4주짜리)만 경험해보고, 실제 클라이언트의 니즈를 수용하며 프로젝트를 진행해보지 않았던 내가 읽기에는 다소 어려운 부분이나 이해하기 어려운 부분이 많았다.
하지만 책을 읽으면서 내가 이전 일본에서 3년간 일해온 경험,
부트캠프 프로젝트를 진행하면서 느끼거나 생각했던 부분에 대해서 다시 한번 생각 및 회고하게 되었고, 내가 앞으로 개발자로서 계속 성장하려면 어떠한 마음가짐으로 개발에 임해야 하는지에 대해서 조금이라도 생각하게 되는 책이였던것 같다.
책을 읽으며 감명깊었던 문구나, 개념에 대해서 내 생각을 조금 정리해보려고 한다.
'아니오'라고 말하는 방법 배우기
소프트웨어 장인이 갖추어야 할 핵심적인 자질중 '정직','용기'가 있으며 이는 필요한 상황에서 고객에게 '아니오'라고 말할 수 있는 것을 의미함. 그저 '아니오'라고 답하는 것은 장인의 태도가 아니며 모든 '아니오'에는 항상 대안을 제시해야 한다.이 부분에 대해서는 망치로 머리를 한대 쌔게 맞은것 같은 느낌을 받았다.
이전 일본에서의 3년간의 경력중 내게 붙었던 별명은 '예스맨'이었다.
상사나 동료에게 무엇인가 부탁을 받거나 고객으로부터 요청이 있으면 거절을 해본적이 거의 없었다.
나에게 요청을 하는 것은 내가 어느정도 이 일에 대해 인정을 받은것 같은 느낌이 들었고 회사나 아르바이트처에서 임금을 받고 일을 하는 것이다 보니 위에서 시키는 것은 무조건 해야하고, 내가 이 요청을 거절 하게 되면 상대방은 나에게 실망을 하거나 회사의 평가나 내 자신에 대한 평가가 낮아질 것 같다는 우려속에 '아니오'라고 이야기를 하지 못하고 '하겠습니다'로 답변하곤 했다.
이전 회사에서는 고객측에서 오는 요청은 무조건 적으로 다 수용해서 반영해야 한다라는 방침이 있어서 거절을 못하는 경우가 많았다.
가끔 터무니 없는 요청에 대해서는 반박자료를 가지고 반박했던 기억은 있지만
이 또한 내가 한것은 아니고 상사분들이 대처를 해주셨다보니 나는 여전히 '아니오'로만 대답하는 인간이였다.
하지만 이 책을 보면서 문득 '아니오'로 대답을 하면서 왜 아니오라고 했는지에 대한 설명을 내 선에서 제시했다면 위에서 했던 나의 걱정 또한 없어지지 않을까? 라는 생각이 들었다. 물론 나혼자서 독단적으로 아니오 라고 대답하지는 않고, 팀원과 충분한 논의 끝에 '아니오'라고 대답할것 같긴하지만 무조건 예스로 수용하지 않고 주어진 환경이나 상황에 맞게끔 생각할 수 있게끔 나 자신을 회고해 볼 수 있는 좋은 기회가 된것 같다.
애자일
사실 이런이야기를 하는것이 굉장히 부끄럽지만, 이 책을 통해서 애자일이라는 단어를 처음 접해보았다.. 취업을 하기전에 알았으니 다행일수도 있지만, 내가 애자일에 대해 전혀 모르는 체로 일을 시작했다면 엄청나게 후회하고 기존과 동일하게 상명하복식으로 일을 하게 될것 같은 생각이 들어서 이 부분도 한번 정리와 회고가 필요할것 같아서 기재해본다.
애자일이란?
사전적 의미로는 '날렵한', '민첩한'이라는 의미를 가지고 있다.
소프트웨어 개발 방식중 하나이며, 작업 계획을 짧은 단위로 세우고 시제품을 만들어 나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고 신속하게 대응하는 개발 방법론
애자일 매니페스토(선언문)
우리는 스스로 소프트웨어를 개발하고, 다른사람들이 개발하는 것을 도와주면서 더 나은 소프트웨어 개발 방법들을 찾고 있다. 이 과정에서 우리는 다음과 같은 가치를 중요하게 생각한다.
절차와 도구보다는 **개성과 화합을**
방대한 문서 작업보다는 **동작하는 소프트웨어를**
계약 조건에 대한 협상보다는 **고객과의 협력을**
계획을 따르는 것을 넘어서서 **변화에 대처하는 것을**
더 가치있게 여긴다.
좌측 사항도 가치가 있음을 인정하지만 우리는 우측의 사항에 더 높은 가치를 둔다는 것이다.애자일 매니페스토 원칙들
1. 가치있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다.
3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.
4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.
5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.
6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주보고 대화하는 것이다.
7. 프로젝트의 진척도를 가늠하는 가장 기본요소는 동작하는 소프트웨어이다.
8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발속도를 계속 수용할 수 있어야 한다.
9. 기술적인 탁월함과 좋은 설계에 대한 지속적인 관심은 기민함을 높인다.
10. 단순함, 즉 하지 않아도 될 일은 최대한 하지 않아야 한다.
11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.
12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로 잡는다.애자일의 대해서 매니페이스와 매니페스토의 원칙을 보면서
고객의 요청에 맞추어 최대한 빠르게 소프트웨어를 전달하여 지속반복적으로 고객방향성으로 수정 가능하게끔 하는것이 애자일의 궁극적인 목표이지 않을까 라는 생각이 들었다.
책을 읽어보면서 애자일에 대해 곰곰히 생각을 해봤는데 위의 12가지 원칙들이 모두다 지켜진다면 정말 멋진 프로젝트 결과가 나올것으로 생각되면서도
이를 모두다 성취하기에는 굉장한 어려움이 따를것 같다는 생각이 들었다.
팀원이나 담당자가 애자일하게 일을 하지 않거나 애자일에 대해 중요하게 생각하지 않는다면 그 팀에서 애자일하게 일을 하려고 해도 제대로 시너지를 내지 못할것 같다는 생각이 들었다. 결국에는 사람과 사람끼리 방법론을 정하고 일을 하는것이기 때문에 애자일하게 일을 하기 위해서는 사람이 제일 중요할것 같다.
그리고 애자일 원칙들중 1,2번이나 다른 몇가지 정도라도 지킬수 있는 방안을 도입하더라도 멋진 결과나 성취감을 이룰 수 있을것 같다는 생각이 들면서도 내가 과연 저렇게 할 수 있을까 라는 걱정이 들면서도 추후 개발자로써 일을 하게 된다면 애자일 매니페스토 원칙들을 상기해가면서 일을 한다면 팀에도 조금은 도움이 되지 않을까?? 라는 생각이 들었고 이런 생각을 하는 사람들이 한두명씩 늘어나게 되면 그 팀이 애자일하게 일을 할 수 있지 않을까?? 라는 생각이 든다.
소프트웨어 장인으로서의 열정
이 책에서 소프트웨어 장인에게 필요한 것은 '열정'이라고 한다.
소프트웨어 개발과 자신의 직무에 대한 열정
문제를 단순한 방법으로 푸는것에 대한 열정
배우고 가르치고 공유하는 열정
소프트웨어 산업이 진화호도록 돕는 열정
코드를 공유하고 초보개발자를 멘토링하고 블로그/책 등을 통해 경험을 공유하는 열정
기술 커뮤니티 활동에 열정사실 내가 개발자로써의 길을 걷게된 것은 일본에서 하던 업무에 대해 아래와 같은 문제로 인해 충분히 고민하고 내린 결론이였다.
- 일본과 한국의 중간에서 기술적인 통역 번역을 하며, 기술지원을 하는 업무이기 때문에 일본어와 한국어를 할 수 있는 사람이면 누구나 다 할 수 있고 쉽게 대체제를 구할 수 있음
- 기존 회사에서는 기존회사 만의 툴과 기술을 가지고 일을 해야 했기 때문에 그 회사를 그만두게 되면 기존의 경력을 인정받지 못할 수도 있을것 같다는 불안감
- 개발자가 없으면 일이 펜딩되어 할 수 있는게 없을 정도로 내가 주도적으로 일을 할 수 없는 현실
사실 3번이 가장 큰 이유였던것 같다. 문제가 발생하였을때 나는 문제에 대해 개발자의 의견을 듣고 그 의견을 고객에게 전달하는 직무가 주된 업무였는데, 두 나라의 언어가 서로 다르다보니 잘못된 의견 전달을 하는 경우도 종종 있거나, 개발자가 부재중일 경우에는 어떻게든 시간을 끌어보는.. 업무적으로 한계를 느끼게 되었고 이럴바에는 내가 개발 공부를 하여 직접 개발자가 되어 이 한계를 벗어나서 내가 일을 주도한다면 더 재밌게 일을 할 수 있지 않을까?? 라는 생각으로 개발자로 진로를 변경하게 되었다.
최초에는 열정이 가득하였지만, 부트캠프를 수료한 지금은.. 번아웃이 온건지 개발에 대한 열정이 조금 식은것 같은 느낌도 들었지만 이 책을 읽으면서 조금은 동기부여가 된것 같아 좋았다.
아직은 주니어 개발자로서 시작하는 단계이지만 언젠가는 이 책에서 말한 소프트웨어 장인으로써의 길을 걷는 개발자가 되고 싶다.
