개요

구름에서 진행하는 COMMIT에 다녀왔습니다.

이번엔 쏘카 CTO 류석문님께서 소프트웨어 장인 정신에 대한 이야기를 들을 수 있었습니다.

소프트웨어 개발, 애자일(Agile)의 정의와 한계, 소프트웨어 장인 정신(Software Craftsmanship)을 목차로 하여 발표를 진행해 주셨습니다.

소프트웨어 개발

제조업 방식의 프로세스

초기 소프트웨어 개발 프로세스는 기존 제조업의 방식을 따랐습니다. 사전에 모든 작업을 정의, 예측할 수 있고 동일한 입력에 동일한 결과를 만들 수 있다는 것을 전제로 고객들이 어떤 소프트웨어를 원하는지 미리 알 수 있다는 접근입니다.

대표적인 모델은 폭포수 모델로, 논리적으로 완벽해보였지만 변동성이 높은 인간을 고려하지 못한 단점을 가지고 있습니다.

변동성을 고려한 프로세스

그렇다면 어떻게 접근해야 할까요?

예를 들어, 우리가 집에서 김치찌개를 끓일 때를 고려해 봅시다. 대충 냉장고에 있는 김치를 찾고 기호에 맞는 재료들을 찾아서 적당히 넣고 끓입니다. 어느 정도 끓은 시점에서는 간을 맞추기 위해 몇 숟가락씩 먹어보곤 합니다. 그러다가 먹을 만하다 싶으면 맛있게 먹습니다.

이를 좀 더 소프트웨어 개발 프로세스에 맞게 조정하면 다음과 같습니다.

자주 확인하고 상황에 맞추어 조정하며 점진적으로 구현
프로세스는 상황에 맞추어 수시로 변경됨
결과를 사전에 예측하기 어렵고 매번 다른 결과가 만들어짐

위와 같은 접근 방식이 바로 1960년대 부터 태동한 애자일 개발 방법론입니다.

변동 요소를 적극적으로 수용해서 해결책을 찾을 수 있게 되었습니다.

애자일(Agile)의 정의와 한계

은빛? 애자일

애자일 소프트웨어 개발 선언 은 모르는 분이 없을거라 생각합니다.

앞 절 마지막에서 결국 애자일이 도입되면 많은 문제가 해결될 거라 기대했지만 딱히 크게 바뀌지 않았습니다.

어떤 이유일까요?

애자일의 구성

애자일 방법론의 Extreme Programming(XP)에 대해 알아봅시다.

XP는 3개의 Layer로 구성이 되어있습니다.

자세한 설명은 프로그래머로 산다는 것 클립(19:53) 에서 잘 다뤄주십니다.

각 요소들에 대해서 가볍게만 다루고 넘어가겠습니다.

Core Layer

• TDD: 코드를 작성하기 전에 어떻게 테스트할 것인지를 고민해 보세요.
  • 테스트 커버리지를 갖고 있는 상태에서 프로덕션 코드를 작성하게 되므로, 리팩터링을 하게 될 때 외부에 드러나는 속성이 바뀌는지 안 바뀌는지를 쉽게 확인할 수 있게 됩니다. 언제나 깔끔한 코드를 작성할 수 있게 도움이 됩니다.
• Refactoring: 리팩터링은 외부에 드러나는 외부에 드러나는 속성이 바뀌지 않아야 합니다. 즉 구현되어 있던 기능(동작)들이 바뀌지 않아야 한다는 의미입니다.
  • 모든 코드가 작성된 후 모아서 진행하는 것이 아닌, 각각의 커밋이 되기 전에 코드의 가독성을 확보해야 합니다.
• Simple Design: 항상 가장 간단한 방법을 사용해야 합니다.
  • 우리는 모두 어려운 문제를 풀어내야 하는 사람들입니다. 복잡한 문제를 그대로 복잡하게 해결하려고 한다면 어려워집니다.
  • 복잡한 문제를 구조적으로 단순화하고, 점진적으로 구현해야 합니다.
• Pair Programming: 코드 리뷰를 실시간으로 진행하는 겁니다. 코드 리뷰의 중요성은 모두가 공감할 거라 생각합니다. 기간을 두고 리뷰하는 것이 아닌, 한명은 코드를 작성하고 한명은 동시에 리뷰를 진행하며 코드를 작성하는 것을 의미합니다.

Core Layer를 만족하는 사람은 이제 "개발자"로서의 역량을 갖추게 됩니다.

하지만, 개발자들이 항상 혼자 일을 하지는 않겠죠, 다음 Layer는 팀으로 이루어졌을 때 효과적으로 협업하기 위한 역량, 도구를 의미합니다.

Cooperation Layer

Layer의 이름은 제가 임의로..? 만들었습니다. 협업을 의미하는 Layer입니다.

• Collective Ownership: 코드에 대한 소유권을 팀이 같이 나누어 갖는 것을 의미합니다.
  • 병목 현상이 발생하는 것을 방지해줍니다.
• Coding Standard: 코딩 표준은 코드의 일관성을 유지하고 팀 전체가 쉽게 읽고 리팩터링할 수 있도록 합니다.
  • 외부의 인원이 코드를 읽었을 때, 1명이 작성한 코드처럼 보이게 작성합니다.
• Suntainable Pace: 앞선 내용에서 인간의 변동성과 관련된 내용입니다.
  • 지속 가능하고, 측정 가능하며 예측이 가능한 속도로 진행합니다.
• Metaphor: 공통된 언어로 소통합니다. Ex. DSL
• Continuous Integration: 문제를 빠르게 파악할 수 있도록 구성 요소들을 자주 통합합니다.
  • 언제나 배포가 가능할 수 있는 상태가 됩니다.

이 Layer까지 갖춘다면 이제 협업을 할 수 있는 개발자가 됩니다.

다음 Layer는 다른 팀들과의 협업, 고객과의 소통을 의미하는 Layer입니다.

이 글에서는 넘어가도록 하겠습니다.

왜 안되지?

돌아와서 왜 결국 애자일은 실패한 걸까요?

위 그림에서 Core Layer가 지켜지지 않았기 때문입니다.

개발 프랙티스가 아닌 프로세스와 상호작용들을 더 중시하게 되었기 때문입니다.

결국 폭포수 모델이 실패했던 이유와 동일합니다.

일주일에 한 번 미팅하던 것을 데일리 스탠드업을 통해 매일 깨지고, 회고나 플래닝에만 치중되었습니다.

정신차려야 할 때가 되었습니다.

소프트웨어 장인 정신(Software Craftsmanship)

기준의 상향이 필요해

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을  
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고  
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:  

- 공정과 도구보다 개인과 상호작용을  
- 포괄적인 문서보다 작동하는 소프트웨어를  
- 계약 협상보다 고객과의 협력을  
- 계획을 따르기보다 변화에 대응하기를  

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,  
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

위의 애자일 소프트웨어 개발 선언문에도 적혀있는 "작동하는 소프트웨어"를 중시한다는 이유로 "동작"만 하는 최악의 코드들을 양산하게 되었습니다.

소프트웨어 개발의 기준을 상향할 필요가 생겼습니다. 바로 소프트웨어 장인 정신입니다.

소프트웨어 장인은 소프트웨어 개발을 연습하고 다른 사람이 기술을 배울 수 있도록 지원함으로써 
전문 소프트웨어 개발의 기준을 높입니다. 이 일을 통해 다음의 가치를 깨닫게 되었습니다:

- 작동하는 소프트웨어를 넘어 잘 만들어진 소프트웨어
- 변화에 대응하는 것을 넘어 꾸준히 가치를 더하는 것
- 개인과 상호 작용을 넘어 전문가 커뮤니티
- 고객 협업을 넘어 생산적인 파트너십

왼쪽의 항목을 추구하기 위해 오른쪽의 항목이 필수 불가결합니다.

결국 소프트웨어 개발에 참여하는 사람들이 책임감, 전문성, 실용주의, 자부심을 갖게하는 것입니다.

오늘 내일 하고 있는데..?

회사가 오늘내일하고 있는데 장인 정신, 코드 품질 챙기라는 게 무슨 말이냐... 하시는 분들은 예전에 작성했던 기술 부채를 바라보는 다른 시각 글도 한번 맛보시길..바랍니다.

코드의 품질을 높게 유지하면 기능당 개발 시간을 단축할 수 있어 사이클 타임을 가져갈 수 있게 됩니다.

코드 품질은 그냥 항상 무조건 좋게 해라.

당연한 말 같지만, 이를 위해서는 개발자로서 갖추어야 할 두 가지 덕목이 필요합니다.

좋은 개발자

바로 깔끔한 코드를 작성할 수 있는 능력과 적절한 논리력입니다.

깔끔한 코드는 1) 가독성을 갖춘, 2) 변경이 용이한, 3) 유지보수 비용이 적은 코드를 의미합니다.

워낙 많이 알려진 클린 코드에 대한 내용이라 여기서는 생략하겠습니다.

적절한 논리력은 1) 원리 탐색 능력, 2) 제약 조건을 고려한 해법, 3) 단순한 디자인을 의미합니다.

기본적인 원인은 무엇이고 무엇을 구현해야 하는지 아는 능력과 제약 조건을 고려한다면 심플한 것부터 시작합니다.

언제나 극강의 오버 엔지니어링을 하는 경우를 볼 수 있는데, 상황에 맞는(제약 조건을 고려한) 해법을 찾을 수 있도록 합니다.

어떻게?

다 좋은 말들인 건 아는데 뭘 어떻게 시작해야 해? 라는 생각이 머릿속에 가득합니다.

돌고 돌아 꾸준한 연습을 해야 합니다.

정답은 없지만 방향성에 대해서는 언급을 해주셨습니다.

좋은 {도메인/기술} 개발자

서버, 웹, 클라이언트, AI 등 다양한 기술과 도메인들이 저 자리에 들어갈 수 있지만 이는 시간이 흐름에 따라서 시장의 반응, 산업의 미래가 변동적입니다.

"좋은"은 공유와 협업을 실천하는 자세를 의미하고, "개발자" 앞서 말한 개발자로서의 역량을 갖추는 것을 의미합니다.

공유를 잘하다 보면 덕을 볼 확률이 올라가고 또한 주변 사람들이 똑똑해지면 내가 편해집니다.

"좋은 개발자"는 시간 변동성이 없으므로 이를 지향점으로 삼는 것이 좋습니다.

마무리

결론적으로 핵심은 "소프트웨어 장인 정신"을 갖추자는 것입니다.

좋은 코드 작성 능력과 적절한 논리력을 갖춘 개발자가 되기 위해 노력하고,

공유와 협업을 갖추어 좋은 개발자가 된 후

도메인 지식을 갖추어 전문가가 되어야 합니다.

한참, 팀원들과 애자일, 스크럼, 회고만을 얘기하던 시점에 이 발표를 듣게 되어 팀원들과 발표 내용을 공유하게 되었습니다. 모두 기본을 놓치고 있었다는 반응을 들을 수 있었습니다.

두서가 없는 글이지만 다른 분들에게도 다시 한 번 방향성을 찾을 수 있는 글이되면 좋겠습니다.