구름에서 매달 진행하는 Commit에 운이 좋게 오프라인 참석자로 당첨이 됐다.
사이드 프로젝트를 여러 개 하면서 개발에 대한 약간의 회의감과 의구심이 들던 중이었던 터라, 내가 느꼈던 점들을 정리해보고자 한다.
(단순 발표 내용 정리가 아닌 느꼈던 점들에 초점을 맞춘 글입니다.)
소프트웨어 개발이란 무엇인가?
소프트웨어 개발은 프로세스이다. 그러므로 소프트웨어 개발을 잘한다는 것은 프로세스를 잘 정의하는 것이다.
그렇다면 잘 정의된 프로세스란 뭘까? 바로 사전에 모든 작업을 예측할 수 있는 것이다.
사전에 모든 작업을 예측한다는 것은 당연히 말도 안 되는 말인데, 그 이유는 인간은 변동성이 매우 높기 때문이다.
폭포수 모델은 이런 변동성을 염두하지 않은 모델이기 때문에 좋지 않은 모델로 평가받는다.
일반적으로 폭포수 모델의 문제 해결로 나오는 것이 애자일이다. 그렇다면 과연 애자일은 성공한 프로세스일까?
애자일은 성공한 프로세스인가?
애자일의 핵심은 상황에 맞추어 점진적으로 구현하는 것이고 이는 인간의 변동성 문제를 해결할 수 있다.
애자일 중 하나인 XP(Extreme Programming)는 3개의 레이어로 나뉜다.
가장 안쪽인 첫 번째 레이어는 개발자가 되는 법,
두 번째 레이어는 효과적으로 협업하고 일하는 법,
세 번째 레이어는 다른 팀 등과 전체적으로 일하는 법이다.
각 레이어들을 잘 지킨다면 빠르고 효율적으로 좋은 소프트웨어를 개발할 수 있다. 하지만 이런 장점에도 적극적으로 도입한 회사들에서 문제가 발생하기 시작했다.
애자일은 왜 실패했을까?
이렇게 좋은 방법론이 왜 실패했을까를 생각해 보자.
XP에서 가장 중요한 핵심은 첫 번째 레이어이다. 즉 모든 것에 앞서 개발자부터 돼야 한다.(이 말이 이번 커밋의 핵심이다)
현재 널리 사용되는 애자일은 개발에 쓰이는 것(개발 프랙티스)이 아닌 프로세스(애자일)와의 상호 작용을 중시한다.
핵심인 개발이 선행되지 않고 애자일에 과의존하다보니 데일리 스크럼, 스프린트 회고 등 눈치만 보면서 앉아있게 되는 것이다.
소프트웨어 장인 정신
결국 이 문제를 해결하려면 우리가 할 수 있는 것은 정해져 있다. 바로 개발에 집중하는 것이다.
추가적으로 몇 가지 가치를 더해서 아래와 같이 소프트웨어 장인 정신을 요약할 수 있다.
- 작동하는 소프트웨어를 넘어 잘 만들어진 소프트웨어
- 변화에 대응하는 것을 넘어 꾸준히 가치를 더하는 것
- 개인과 상호 작용을 넘어 전문가 커뮤니티
- 고객 협업을 넘어 생산적인 파트너십
즉 책임감, 전문성, 실용주의, 자부심을 개발자가 가져야 한다.
깔끔한 코드와 적절한 논리력
잘 만든 소프트웨어를 위해서는 테스트 코드와 코드 퀄리티에 신경을 많이 써야 한다. 하지만 시간을 핑계로 잘 지켜지지 않는 곳이 대부분이다.
시간이 부족한 이유는 잘못된 곳에 시간을 많이 쓰기 때문이다.
코드의 품질과 개발 시간은 반비례하기 때문에 코드 퀄리티에 시간을 쓰는 것은 절대 시간 낭비가 아니다.
또한 현재 상황을 고려하여 설계(오버스펙을 하지 않는 설계)하고, 디자인을 단순화해야 한다.
이런 습관을 기르려면 꾸준한 연습이 필요하고, 필요에 따라 동료와 함께하여 동기 부여를 이끌어낼 수 있다.
좋은 개발자 되는 법
깔끔한 코드와 적절한 논리력은 이미 알고 있는 얘기인 것 같고.. 그래서 결국 좋은 개발자가 되려면 어떻게 해야 하는 것일까?
좋은 개발자는 공유하고 협업한다.
공유하면 주변이 똑똑해져서 내가 편해질 수 있다. 또한 좋은 평판과 함께 주변의 덕을 볼 확률이 올라간다.
협업을 잘하는 것은 매우 중요한 소프트 스킬이지만 그만큼 어렵다. 협업이 어려운 이유는 바로 상대가 합리적인 사람이라고 전제하기 때문이다.
인간은 본래 비합리적이기 때문에 합리적이지 않은 인간과 함께 살아가는 법을 배워야 한다.
전체 내용을 한 줄로 요약하면,
"깔끔한 코드, 적절한 논리력을 갖추고 빠른 피드백과 함께 공유하고 협업하는 능력을 길러라"
라고 할 수 있겠다.
마무리
공감되는 부분도 많고 깨달은 점도 많았던 강연이었던 것 같다. QnA 때 배운 점들도 많았다.
어떤 취준생 분의 질문이었는데, CS 공부와 알고리즘 때문에 회의감이 들어 취직을 해야 하는지에 대한 질문이었다.
이에 대해 CS와 알고리즘 같은 것은 개발자를 하기로 했으면 그냥 하는 것이라고 답변하셨는데, 쿨하면서도 공감되는 답변이었던 것 같다.
테스트 코드를 짜고 있긴 하지만 TDD의 중요성에 대해 언급을 많이 하셔서, TDD를 한 번 적용해 볼까 생각 중이다.
(TDD도 개발자라면 그냥 하는 것이라고 하셨는데... 뭐든 그냥 해야 되는 게 많은 것 같다)
다음 커밋도 신청해야지
'일상' 카테고리의 다른 글
디자인 씽킹 교육 (4/27 ~ 4/29) (0) | 2022.07.06 |
---|---|
소프트웨어 마에스트로 13기 합격 후기 (0) | 2022.04.13 |