[독후감] 주니어 시선에서 바라본 소프트웨어 장인정신

  미래 커리어에 대해 고민이 많았다. 미래에는 어떤 일을 해야할지 무엇을 준비해야 할지에 대한 고민들로 머리가 어지러웠다. 관리자나 컨설턴트, 아키텍처를 설계만 하는 그런 일을 해야할지 등이 고민이 됐다. 이런 고민 끝에 우선 나는 이직이라는 결심을 하게됐다.

  하지만 이직은 이런 고민에 대한 완벽한 해답은 아니라는 생각이 들었다. 단순히 외부적 환경 변화만 있었을 뿐 이런 고민을 해결할 수 없었다. 결국 내 스스로 답을 찾아야 했다. 내 커리어에 대한 생각을 정리할 시간이 필요했다.

  이후 시간이 지나 팀원분들에게 이직한다는 소식을 전하며 아쉬운 작별 인사를 드렸다. 그리고 마지막 근무일날, 윤현준님이라는 선임 개발자분께서 새 책 한권을 선물 해주셨다. 평소 스터디를 이끌어 주시고 기술적 이슈들을 함께 나눠 주시던 멋진 분이셨다. 그래서 그런지 내가 어떤 부분을 고민하고 있을지 대략 알고 계셨던 것 같다. 그 분은 내게 이 시기에 읽으면 좋을 책이라며 ‘소프트웨어장인’이라는 책을 선물해 주셨다. 덕분에 이 책을 읽으며 내 생각을 어느 정도 정리해 볼 수 있었다. 개발자라면 어느 시기든지 이 책을 읽어보는건 정말 좋을 것 같다. 새로운 회사로 입사하기 전인 이 시기를 이용해 주니어 개발자 시선에서 이 책을 읽고 느꼈던 부분을 글로나마 정리하고 기록해보려고 한다.

  이 책의 저자는 현재 기업들은 시키는 일만 하는 값싼 코더가 아니라 프로페셔널 개발자를 원하고 있다고 한다. 이로 인해 소프트웨어 개발자의 권한 영역이 넓어지고 책임은 더 무거워지고 있다고 한다. 한국 기업들도 미국기업의 개발자 구인 트랜드를 시기적으로 조금 느리지만 비슷하게 따라가고 있다는 느낌을 받았다. 우리의 커리어를 위해서라면 저 흐름을 놓치지 말아야 하지 않을까. 그렇다면 프로페셔널한 개발자는 어떤 개발자일까. 또한 소프트웨어 장인정신과 어떤 상관이 있는 걸까.

  이 책에서는 소프트웨어 장인정신을 다음과 같이 한줄로 정의하고 있다. “소프트웨어 장인정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다.” 많은 개발자들은 소프트웨어 장인정신에서 이야기하는 많은 것들을 이미 실행하고 있다고 말할 수 있다. 소프트웨어 장인의 태도에 대해 정리해보면 다음과 같다.

1. 주인의식을 가지기
2. 고객이 원하는 것은 무엇이든 달성할 수 있도록 돕기
3. 다른 개발자들에게 배우기
4. 자신의 지식을 나누기
5. 경험이 부족한 개발자들을 멘토링 하기
6. 동작하는 소프트웨어뿐만 아니라, 정교하며 솜씨 있게 만들어진 작품을 만들기
7. 끊임없는 자기계발
8. 팔로우할 리더 찾기
9. 끊임없는 훈련
10. 카타
11. 펫 프로젝트
12. 오픈소스
13. 페어프로그래밍
    

  이제 주니어 관점에서 위 내용에 대해서 어떻게 느꼈고 어떻게 하면 좋을지에 대해 주관적인 의견을 적어보려고 한다.

1. 주인의식을 가지기

  요즘 다수의 회사들이 MSA 환경을 지향하고 있어 부서별로 권한이 명확해졌다. 이 덕분에 개발자들이 더욱 자신의 담당 프로젝트에 주인의식을 갖기 쉬운 환경을 제공받고 있다는 생각이 들었다. 주니어 개발자로서 주인의식을 갖고 행동하는 모습은 어떤 것일지 생각해봤다. 장애처리에 적극적으로 참여하고 레거시 코드를 다룰 필요가 생긴 경우 적극적으로 리펙토링하고 테스트코드를 적극적으로 작성하는 모습이지 않을까라는 생각이 들었다.

2. 고객이 원하는 것은 무엇이든 달성할 수 있도록 돕기

  이 부분이 업무를 수행하는데 가장 중요하다고 생각됐다. 우선 고객이 원하는 바를 정확히 파악하지 않는다면 삽오브삽질을 할 가능성이 아주 농후하다. 그렇기 때문에 고객이 원하는 바를 먼저 파악하는게 아주 중요해 보인다. 하지만 주니어 시절 때 가장 힘든 관문이 될 것 같다는 생각 또한 들었다. 우선 고객이 원하는 것을 알기 위해서는 고객과 원만한 의사소통이 필요시 되는데 내가 겪었던 바와 주위 사람들의 근무환경에 대해 듣게 됐을 때 여러 장애물이 있을 것 같다는 생각이 들었다. 주로 도메인 지식이 부족한 점, 내성적인 성격의 경우, 관료적인 회사의 구조적 문제 등이 넘어야 하는 장애물이 될수 있을 것 같았다. 이를 극복하기 위해서는 빠른 시일내에 주인의식을 가지고 내가 담당하는 프로젝트에 대해 빠르게 파악해 전문성을 가지거나, 의사소통 자체에 익숙해지도록 의도적으로 시도해볼 수 있을것 같다. 단, 회사의 구조적인 문제를 주니어 입장에서 해결하기는 정말 어려울 것 같다는 생각이 들었다. “절이 싫으면 중이 떠나라”라는 말이 있듯이 구조적인 문제를 돌파하기에는 누구에게도 쉬운 일이 아닌것 같다.

  의사소통이 원할한 구조에서 일한다면 개인이 노력했을 때 고객의 니즈를 파악하는 일은 꽤 쉬운일이 될 수 있을 것이다. 고객이 원하는 것을 알았다면 이제는 달성할 수 있도록 도와야 한다. 이 부분 또한 주니어 개발자에게 큰 난관이라고 생각된다. 내가 담당하는 부분을 잘 알고 있더라도 더 많은 도메인 지식이 필요해지는 순간이 꽤 많다. 프로젝트, API 관리 권한이 여러 부서로 나눠져 있는 경우가 많다. 그렇다면 부서 간의 협의가 필요해지고 내가 생각하지 못했던 많은 이슈 들을 접해야 한다. 이럴 때에도 제일 중요한 것은 바로 의사소통인 것 같다. 현업에서 이슈를 파악하기 위해서는 IOS 개발자, 안드로이드 개발자, 서버개발자, 웹프론트개발자, 마크업 디자이너 등 많은 이해 관계자 들과 의사소통을 한다. 그리고 네이티브 이슈, 히스토리적인 이슈 등을 파악해 이를 종합하고 고객에게 가능할 지 불가능할 지를 알린 후 불가능 한 경우는 이슈들을 우회할 수 있는 대안을 제시해야지 진정 고객을 돕는 일이라는 생각이 들었다.

3. 다른 개발자들에게 배우기

  주니어 시기에는 정말 열심히 배워야 한다는 말을 많이 들었다. 스스로 학습하는 방법과 다른 사람을 통해 직간접적으로 배우는 방법이 있다. 스스로 학습하는 방법도 정말 중요하지만 주니어 시기에는 다른 개발자들에게 배우는 것이 아주 중요한 시기인것 같다. 구성원들의 지식의 깊음을 수치화하고 시각화 한다면 피라미드와 비슷할 것 같다. 아직 지식의 깊음이 얕다면 오히려 다른 사람에게 배울 수 있는 기회가 아주 많고 더 빠르게 성장할 수 있을 것이라고 생각이 들었다. 하지만 마스터의 경지에 이르렀다면 피라미드의 꼭대기 근처에 이르렀을 것이고 주니어 시기보다 다른 사람에게 배울 수 있는 기회가 상대적으로 훨씬 줄어들 수도 있을 것이라는 생각이 들었다. 다른 개발자들에게 배우기 위해서는 무엇을 하면 좋을까. 책에서는 스터디, 커뮤니티 활동, 페어 프로그래밍 등을 해볼 것을 권유하고 있다.

4. 자신의 지식을 나누기

  자신의 지식을 나누는 것은 주변 개발자들에게 도움이 되며 내 자신에게도 도움이 된다고 생각된다. 또한 내가 모른다는 사실 조차 모르는 경우가 있는데 지식을 나누기 위해서 준비하는 과정에서 혹은 나눈 이후 나의 무지를 알 수 있는 좋은 기회가 되기 때문에 아주 중요한 덕목이라고 생각한다.

5. 경험이 부족한 개발자들을 멘토링 하기

  장인이 제자를 키우듯 소프트웨어 장인으로서 미래를 이끌 개발자를 양성하는 건 아주 중요하다. 하지만 아직 내가 그런 경지에 오르지 못했기에 멘토링이라기 보다 같은 주니어로서 내가 어려워 했던 부분에 대해 공유드리고 편하게 물어볼 수 있는 동료가 되어야 겠다는 생각이 들었다.

6. 동작하는 소프트웨어뿐만 아니라, 정교하며 솜씨 있게 만들어진 작품을 만들기

  TODO:: 계속 정리하기

13. 페어 프로그래밍

  익숙하지 않은 애자일 개발방법론이다. 회사에서 이 방법을 권장하고 있다면 자연스럽게 접해볼 수 있겠지만 그렇지 않은 경우 쉽게 접해 보기 힘든 방법이다. 또한 자신이 코딩하는 과정을 옆 사람이 계속 지켜보며 코멘트를 한다는 점은 여간 부담스러운게 아니다. 하지만 페어 프로그래밍을 자체적으로나마 시도해본다면 그 효과는 생각 이상이라고 한다. 서로의 코드를 직접 한줄 한줄 보면서 리펙토링할 수 있어 그 과정에서 자연스럽게 부족한 부분을 보완할 수 있기 때문이다. 용기를 가지고 가까운 동료부터 시작해 페어 프로그래밍 시도해 봐야 겠다는 생각이 들었다.

TODO:: 계속 정리하기