구름 commit 우리가 함께 성장하는 방법(2023-12-20)
아래 글은 제가 2023년 12월 20일 구름 commit 프로그램을 참석한 뒤 류석문님의 강의를 토대로 개인적으로 쓴 글입니다.
소프트웨어 개발 경험과 애자일 실천, 그리고 소프트웨어 장인정신
폭포수 모델의 한계와 애자일 개발 방법론
전통적인 폭포수 모델은 논리적으로 완벽해 보이지만, 변동성이 큰 현실을 반영하지 못한다는 단점이 있습니다. 이에 대한 대안으로 등장한 애자일 개발 방법론은 상황에 맞춰 끊임없이 조정하고 점진적으로 구현하는 방식을 제시합니다. 하지만 애자일 방법론 역시 완벽한 해결책은 아닙니다.
애자일 실천의 현실과 문제점
애자일 방법론을 실천하는 과정에서 형식적인 데일리 스탠드업, 회고, 플래닝 등은 실질적인 문제 해결보다는 눈치 보기와 형식적인 절차에 치중하게 만드는 경우가 많습니다. 이는 애자일의 본질적인 가치를 훼손하고 개발 효율성을 저해하는 결과를 초래할 수 있습니다.
소프트웨어 장인정신으로 기준 상향
애자일의 한계를 극복하고 더 나은 소프트웨어 개발을 위해서는 ‘소프트웨어 장인정신’이 필요합니다. 단순히 작동하는 소프트웨어를 넘어 ‘잘 만들어진 소프트웨어’를 추구하고, 변화에 대응하는 것을 넘어 ‘꾸준히 가치를 더하는 것’을 목표로 해야 합니다. 또한, 개인과 상호작용을 넘어 ‘전문가 커뮤니티’를 형성하고, 고객과의 협업을 넘어 ‘생산적인 파트너십’을 구축해야 합니다.
XP Practices: 익스트림 프로그래밍 실천법
XP(eXtreme Programming)는 애자일 개발 방법론 중 하나로(켄트벡의 저서), 소프트웨어 개발 과정에서 실질적인 효과를 얻기 위한 구체적인 실천법을 제시합니다. XP Practices는 개발팀이 효과적으로 협업하고, 고품질의 소프트웨어를 빠르게 개발하며, 변화하는 요구사항에 유연하게 대응할 수 있도록 돕는 핵심 원칙입니다.
Test-Driven Development (TDD): 테스트 주도 개발은 개발자가 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성하는 방식입니다. 이는 개발 초기 단계부터 오류를 발견하고 수정할 수 있도록 도와주며, 코드의 품질을 향상시키고 유지보수를 용이하게 합니다.
Refactoring: 리팩토링은 코드의 기능을 변경하지 않으면서 내부 구조를 개선하는 작업입니다. 지속적인 리팩토링을 통해 코드의 가독성과 유지보수성을 높이고, 기술 부채를 줄여 장기적인 개발 생산성을 향상시킬 수 있습니다.
Simple Design: 단순한 설계는 현재 요구사항을 충족하는 가장 간단한 방법으로 소프트웨어를 설계하는 원칙입니다. 불필요한 복잡성을 제거하고, 변경에 유연하게 대응할 수 있는 유연한 설계를 통해 개발 속도를 높이고 품질을 향상시킵니다.
- Pair Programming: 짝 프로그래밍은 두 명의 개발자가 하나의 컴퓨터를 사용하여 함께 코드를 작성하는 방식입니다. 실시간 코드 리뷰, 지식 공유, 문제 해결 능력 향상 등 다양한 이점을 제공하며, 팀워크와 협업을 강화합니다.
TDD , Refactoring, Simple Design, Pair Programming 를 할 줄 알아야 개발자라고 하시는 류석문님…
Coding Standard: 코딩 표준은 팀 전체가 일관된 스타일로 코드를 작성하도록 규칙을 정의하는 것입니다. 코드의 가독성과 유지보수성을 높이고, 팀원 간의 협업을 원활하게 합니다.
Sustainable Pace: 지속 가능한 속도는 개발팀이 장기적으로 생산성을 유지할 수 있는 적절한 작업 속도를 의미합니다. 과도한 야근이나 무리한 일정을 지양하고, 팀원들의 건강과 워라밸을 존중하여 지속적인 성장을 도모합니다.
Metaphor: 메타포는 개발팀이 소프트웨어 시스템을 이해하고 설명하기 위한 공통된 비유나 은유를 사용하는 것입니다. 메타포를 통해 팀원 간의 의사소통을 원활하게 하고, 시스템에 대한 이해도를 높여 효과적인 협업을 가능하게 합니다.
Continuous Integration: 지속적인 통합은 개발자가 작성한 코드를 자주 통합하고 테스트하는 과정입니다. 이를 통해 통합 과정에서 발생하는 문제를 조기에 발견하고 해결하여 개발 속도를 높이고 품질을 향상시킵니다.
Collective Ownership: 공동 코드 소유는 모든 팀원이 모든 코드에 대한 책임을 공유하는 원칙입니다. 이는 특정 팀원에게 의존하는 것을 방지하고, 팀 전체의 역량을 활용하여 문제를 해결하고 코드 품질을 향상시킵니다.
Whole Team: 전체 팀은 개발에 필요한 모든 역할(개발자, 테스터, 분석가, 고객 등)을 팀에 포함시키는 것입니다. 팀원 간의 긴밀한 협업을 통해 요구사항을 정확하게 이해하고, 빠르게 변화하는 환경에 유연하게 대응할 수 있습니다.
Planning Game: 계획 게임은 팀 전체가 참여하여 개발 우선순위를 정하고, 작업량을 추정하는 활동입니다. 팀원 간의 활발한 논의를 통해 상호 이해를 높이고, 현실적인 계획을 수립하여 개발 목표를 효과적으로 달성할 수 있도록 돕습니다.
Small Releases: 작은 릴리스는 개발된 기능을 작은 단위로 자주 배포하는 방식입니다. 사용자 피드백을 빠르게 반영하고, 문제 발생 시 신속하게 대응하여 개발 위험을 줄이고 사용자 만족도를 높입니다.
- Customer Tests: 고객 테스트는 실제 사용자가 직접 소프트웨어를 테스트하고 피드백을 제공하는 과정입니다. 사용자의 요구사항을 정확하게 파악하고, 실제 사용 환경에서 발생하는 문제를 조기에 발견하여 소프트웨어 품질을 향상시킵니다.
좋은 개발자란 뭘까요?
좋은 개발자는 뛰어난 코드 작성 능력과 논리력을 기반으로 협업과 공유를 통해 시너지를 창출합니다. 또한, 깊이 있는 도메인 지식을 갖추고 빠른 피드백을 통해 끊임없이 성장하며, 실천력을 바탕으로 아이디어를 현실화합니다.
협업의 중요성과 어려움 극복
협업은 개발 효율성을 높이고 더 나은 결과물을 만들어내는 데 필수적입니다. 하지만 인간은 본능적으로 자기중심적인 사고를 하기 때문에 협업 과정에서 어려움을 겪을 수 있습니다. 이를 극복하기 위해서는 상대방의 입장에서 생각하고, 열린 마음으로 소통하며, 서로의 의견을 존중하는 자세가 필요합니다.
결론
소프트웨어 개발은 단순히 기술적인 문제 해결을 넘어 사람과의 상호작용, 끊임없는 학습과 성장, 그리고 협업을 통한 시너지 창출이 중요합니다. 소프트웨어 장인정신을 바탕으로 끊임없이 배우고 성장하며, 동료들과 함께 더 나은 소프트웨어를 만들어나가는 것이 진정한 개발자의 길이라고 할 수 있을 것 같습니다.
류석문님의 책
- 프로그래머로 산다는 것
- 프로그래머 철학을 만나다
- 리더의 생각
- 리더의 세상읽기
나의 생각
류석문님이 당시에 쏘카 CTO 직책을 맡고 계셨었는데, 개발이란 업을 하시면서 얼마나 많은 생각을 하셨을지 감히 짐작도 안갈만큼 깊이 있는 강의 내용이었다고 생각합니다. XP Practices나 에자일이나 그 단어가 중요한 것이 아니라 본질적인 내용이 더 중요하다고 느껴졌습니다. 저도 좋은 동료와 함께 좋은 동료가 되어 더 나은 소프트웨어를 만들어가는데 일조하는 구성원이 되었으면 좋겠고, 실질적으로 여태까지 쌓은 경험들을 공유하는 것부터 시작해보려 합니다.