좋은 개발 문화란? - (2) 준비

소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다.

즉 소프트웨어 장인 정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다.

- 소프트웨어 장인. 3장 소프트웨어 장인정신

이전 글에서는 실패와 개발 문화의 중요성에 대해 이야기했습니다.

이번 글에서는 지금 제 환경에서 시도할 수 있는 좋은 개발 문화의 준비를 기록합니다.

 

업무	설명	기간 산정	예시
A	외부 솔루션 도입	연구가 필요하기에 단순 표기가 어려움	모니터링 솔루션
B	단순 화면 기능 개발	단순 표기 가능	API response 변경
C	업무 이해도가 필요한 개발	리팩터링 범위에 따라 다름 (테스트, 구조 수정 등)	상품 구매 후처리 로직 변경
D	기 개발 건의 QA 처리	단순 표기 가능	B, C 의 QA 오류
E	기능 변화에 영향이 없는 개선 (보통 개발팀 한정)	범위에 따라 다름	형상 관리 도입, 테스트 케이스 작성

위의 제 루틴 업무를 정리한 것입니다.
저는 기획의 요청에 따라 'A~C'의 업무를 병행하면서 'D'의 업무도 처리하고 있습니다.

이 중에서 주로 문제가 되는 것은 'C' 겠죠. 
과연 어느 정도까지 테스트를 작성해야 되고 구조를 수정해야 'D'를 원활히 처리할 수 있을까요?
어쩌면 'D'가 발생하지 않는다고 생각하고 개발해야 될까요?

'E'는 어떨까요? 
가시화하기 힘든 개선이기 때문에 어려운 설득을 준비해야 되는데 '설득을 위한 준비'를 하는 시간을 어떻게 할애해야 할까요?

일반적으로는 이슈가 있어도 제대로 관리되지 않다가 터진 후에야 숙련된 개발자들이 일정 기간을 공들여 개선안을 적용합니다.
이후에도 이슈를 미리 감지하고 개선하는 것이 좋겠지만, 보통은 또 다음 이슈가 터질 때쯤에야 하게 됩니다.
루틴 업무를 하면서 가시화되지 않은 이슈 개선을 준비하고 설득하는 일은 보통의 모티베이션으로는 매우 힘든 일이기 때문입니다.
혹자는 '조금 불편하지만 잘되고 있는데 뭐 어때요?' 또는 '지금 문제가 되는 것이 아니니 당신의 개인 시간을 할애해서라도 하시면 됩니다.'라고 할 수 있습니다. 그리고 보통은 루틴 업무로 돌아가죠.

이미 이전 글에서 정답에 가까운 개발 문화를 가져왔는데도 실패했었습니다.

그리고 그 이유 중 하나를 아래와 같이 생각했습니다.

당면한 회사의 비즈니스 목표는 상용화된 프로덕트였고 그렇기 위해서는 빠른 개발이 우선이었는데, 이런 상황에서 단기적으로 제 개선안은 걸리적거릴 뿐이었습니다.

 

그렇다면 좋은 품질의 소프트웨어 개발은 시간이 오래 걸릴까요?

'소프트웨어 장인' 은 그렇지 않다고 말합니다. 

작은 코드 조각에서는 XP 실행 관례를 마스터한 소프트웨어 장인과 일반 개발자 간의 업무 능력 차이가 별로 없을 수 있다. 하지만 다루어야 할 문제가 복잡해지면 차이가 어마어마하게 벌어진다. 애플리케이션의 크기가 크면 XP 실행 관례를 몸에 익힌 소프트웨어 장인이 XP 실행 관례를 전혀 수용하지 않은 보통의 개발자보다 훨씬 더 빨리 작업을 완료한다.

- 소프트웨어 장인. 15장 실용주의 장인정신 - 좋은 품질은 비싸고 시간이 오래 걸릴까?

문제는 개선안 그 자체가 아니라 팀의 러닝 커브를 높이기 위한 접근 방법이었다는 것을 깨달았습니다.
그렇다면 팀의 러닝 커브를 높이기 위한 접근 방법에는 무엇이 있을까요?

저는 모든 개발자가 소프트웨어 장인정신을 가지고 일하며, 주변으로는 선을 행하고 있다고 생각합니다.

하지만 개개인의 표현 방식은 다릅니다. 또한 회사와 개인의 발전은 일치하지 않기에 개인 시간을 할애하는 것을 거부할 수도 있고, 사람이기에 슬럼프에 빠질 수도 있습니다.

 

그렇기에 개인에게서 독립적인 문화로서 자주적, 심리적 안정감, 지속성이라는 키워드를 생각했습니다.

 

'왓챠' 의 짬 데이

'소프트웨어 장인: 13. 배움의 문화'에서는 '회사에서의 펫 프로젝트 시간을 허용하기'를 말하고 있습니다.

보통의 회사에서는 허용되지 않는 일이지만 이미 '왓챠'라는 회사에서는 '짬 데이'라는 문화가 운영되고 있는 것을 알았습니다.

 

저는 이 것이 건전한 개발 문화를 성장시킬 수 있는 라이프 사이클의 시작이라고 생각합니다.

 

많은 회사에서는 개발 문화를 조직할 때 단발성의 의견을 수집받지만 별 소득이 없는 경우가 대부분입니다.

평소에 생각하는 불만이나 개선 사항은 많겠지만 막상 써내라고 하면 추상적이고, 정리도 안되고 무엇보다도 귀찮기 때문이죠.

 

반면에  주기적으로 시간을 할애해준다면, 루틴 업무와 별개로 생각하고 준비할 수 있기 때문에 본 업무를 먼저 해야 된다는 강박이나 죄책감에서 벗어나 심리적 안정감을 가지고 더 좋은 방법을 귀찮지 않게 준비할 수 있을 것입니다. 예를 들자면 아래와 같은 것 들입니다.

 

• 저번 주에 개발한 업무를 페어 프로그래밍으로 리팩터링
• 테스트 케이스 정비
• 모니터링 관리
• 새로운 프레임워크, DB 연구
• 어쩌면 리프레쉬?

이런 문화의 반복은 생산성의 향상만을 목표하지 않습니다.

오히려 기반이 될 수 있는 구성원 간의 신뢰와 공감, 그리고 여러 기술의 러닝 커브를 완만하게 올려 생산성을 향상하고 비즈니스의 성공을 도울 수 있습니다.

 

물론 회사의 입장에서도 최소한의 준비는 필요합니다.

주기적인 회고와 세미나를 통해 구성원 모두의 수준을 높일 수 있도록 하고, 무엇보다도 실패의 책임을 개인에게 묻지 않는 것이 중요합니다.

 

---

 

다행히도 지금 다니는 회사에서는 2주 단위의 회고와 팀장님 재량 하에 리팩터링과 기술 연구를 지원받고 있습니다.

사실 이 정도의 문화도 훌륭하다고 생각하지만, 제도화된 것과 재량 하의 것은 심리적 안정감과 지속성에서 큰 차이가 있다고 생각합니다.

 

'소프트웨어 장인'을 읽고 이 글을 쓰면서 느낀 건데 이 모든 것이 결국 '애자일 프로세스'로 귀결된다는 것을 느꼈습니다.

1년 전까지는 그냥 새로운 패러다임이라고 생각했지만, 실무를 겪으면 겪을수록 그 필요성을 체감하고 대단하다고 느끼고 있습니다.

 

이 글은 여기에서 끝나지만 다음에는 '좋은 개발 문화란? - (3) 정착'으로 글을 작성해보고 싶습니다!

 

WATCHA WEB 팀의 2020년 회고

왓챠 개발자 이스터에그의 비법은? 짬데이?!