애자일(Agile)

애자일(Agile) 용어를 처음 들은 건 SSAFY 교육이었다.

당시에는 "올바른 개발 절차를 위한 좋은 방식이겠지, 당연히 좋겠지..."라고 생각하면서 넘겼었다.

 

하지만, '소프트웨어 장인' 책을 읽으면서 애자일에 대해 배울 수 있었고

성장하는 개발자가 되기 위해서는 애자일의 개념을 내재화할 필요가 있었다.

 

---

💡 애자일(Agile)의 탄생

2001년 2월, 소프트웨어 업계에 영향력이 있는 17명이 유타(Utah)주의 스키 리조트에 모였다.

각자 서로 다른 기술, 새로운 소프트웨어 방법론을 실험해오던 사람들은 서로의 경험과 현재 시도하고 있는 내용들을 공유하여 더 나은 소프트웨어 프로젝트 수행 방법을 모색하고자 했다.

 

긴 토론 끝에, 애자일 매니페스토가 창안되었고 애자일 연합이 만들어졌다.

 

---

❓ 애자일이란?

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

애자일 메니페스토 : 더 나은 소프트웨어 개발을 위해 중요하게 여기는 가치를 설명하고 있다.

애자일 메니페스토와 함께, 12가지의 원칙들도 있다.

 

나도 처음에는 애자일은 어떤 단일 개념을 뜻하는 단어라고 생각했었다.

마치 품질경영에서 사용되었던 '식스시그마'처럼 프로젝트의 프로세스를 최적화하는 개념이라고 생각했다.

 

하지만 애자일은 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합이다.

 

무슨말이냐? 소프트웨어 프로젝트는 변화 자체를 기본 속성으로 가지고 있다.

따라서, 애자일은 개발팀과 기업들이 그러한 변화에 적응할 수 있도록 변화와 관련된 위험들을 줄여주는 역할을 한다.

 

애자일 원칙과 방법론들은 두 종류로 나눌 수 있다.

1. 절차적인 관점에서의 애자일 원칙

2. 기술적인 관점에서의 애자일 원칙

 

1. 절차적인 관점에서의 애자일 원칙

애자일 원칙의 절차적인 부분들은 팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들을 규정한다.

ex) 회의 방식, 구성원의 역할, 진행 상황을 개발팀 밖의 관계자에게 전달하는 방식 등

 

따라서 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중한다.

 

이러한 방법론을 통해 팀이 올바른 목표를 향해 진행 중인지 확인할 수 있다.

 

 

2. 기술적인 관점에서의 애자일 원칙

애자일 원칙의 기술적인 부분들은 개발, 확장, 유지보수, 제품을 출시(또는 납품, 서비스 배포)하면서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드한다.

ex) 테스트 주도 개발(TDD), 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등

 

 

따라서 소프트웨어 품질에 집중하여 팀이 결과물을 올바르게 만들어가는지 집중한다.

이러한 방법론을 통해 목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게 한다.

 

 

---

📌 애자일 방법론이 사용되는 경우

그렇다면 애자일은 어떤 환경에서 사용하기 적합할까? 

 

애자일이란 일정한 계획과 기존 관습에 따른 과거 방법론과 다르게 신속하고 유연하게 제품을 개발하며 개선까지 동시에 해나가는 방법론이다.

애자일(Agile) 모델

따라서, 계획부터 완성까지 완벽하게 수립 후 시행하는 것이 아니라 실행하면서 동시에 수정과 보완을 반복하는 방법론임을 인지했을 때 아래와 같은 환경에서 애자일 방법론 사용은 적합하다.

 

1. 큰 규모 프로젝트 < 작은 규모 프로젝트
2. 목표가 자주 바뀌며 유동적인 상황일 때(전통적 방식에서의 변화와 유동성은 적고 안정적이다)
3. 불확실성과 빠른 변화가 요구되며 이에 대해 적극적인 조직문화일 때

 

🔎 애자일을 따른다는 것

"애자일을 따른다"는 것은 새로운 환경에 성공적으로 적응하고 있다는 의미다. by 톰 길브(Tom Glib)

기업이 경쟁력을 유지하려면 소프트웨어를 빨리 개발하면서도 더 나은 품질을 유지할 수 있어야 한다.

애자일 소프트웨어 개발은 피드백 루프를 짧게 하고 변화와 고객의 요구에 빠르게 대응할 수 있는 기회를 준다.

 

더 빨리, 더 짧게 피드백 루프를 만들수록 애자일해진다.

그러면, 어떠한 피드백이 올 때마다 그 피드백에 대응할 기회를 얻고, 새 정보에 적절한 행동을 취하면서 프로젝트가 더 민첩해질 수 있다.

 

하지만 많은 기업들이 애자일의 절차적인 부분에는 관심을 기울이지만 기술적 실행 관례에 대해서는 무시하는 경우가 많다.

애자일은 '개발자들은 이미 훌륭하고 절차만 개선하면 된다'는 가정이 깔려 있다.

기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

 

결론 : 애자일을 따른다는 것(=애자일로 전환하는 것)에는 절차 뿐만 아니라 개발자의 역량향상에도 주의를 기울어야 한다.

 

😀 나의 생각

과거에는 '개발자 = 코딩하는 사람' 이었지만 현재는 다르다.

그저 계획에 맞춰서 지시받은 일만 하는 것이 아니라, 비즈니스와 고객 가치 창출에 개발자들이 직접 참여하고 있다.

그에 더해 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 보다 외향적인 성격을 요구하기도 한다.

 

첫 프로젝트를 진행했을 때 동작이 되는 단순한 기능이 눈앞에 나타나자 아이처럼 기뻐했었다.

하지만, 동작되는 기능을 구현하는 것은 개발자로서 매우 기본적인 행동임을 깨달았다.

 

협업이 기본단위인 프로젝트에서 개인이 개발한 코드는 곧 공동의 코드이므로 효율적이어야하며 가독성이 있어야 한다.

 

어떤 코드가 좋은 코드인지 끊임없는 집착과 고민으로 단순 동작을 뛰어넘는 훌륭한 코드작성을 위해 노력하자.

절차적인, 기술적인 관점을 모두 만족시킬줄 아는 개발자가 되자! 

 

---

[참고도서] 소프트웨어 장인