애자일(Agile)이란? TDD란?

기술 말고 개발자가 공부해야 할 게 뭐가 있나 검색해보니 저 생소한 단어 2개가 나왔다.

그래서 의미 정도라도 기록해두려고 이번 포스팅을 쓰게 됐다.

 

먼저 애자일(Agile)이 뭘 말하는 걸까? 애자일의 철자를 보다가 문득 떠오른 것이, 어릴 때 자주 해봤던 라그나로크다.

추억의 게임 라그나로크...

라그나로크란 온라인 게임에는 캐릭터 스탯이라는 게 있는데, 이 중 어질(Agi)이라는 게 있다. 이 스탯은 다른 게임의 민첩성을 뜻하는 덱스(Dex)와 비슷한 뉘앙스를 갖고 있어서, 덱스랑 어질이랑 뭔 차이가 있길래 나눠 놓은건지 궁금했던 적이 있다. 나중에 확인해보니 둘은 다른 의미더라.

이 어질이라는 이름은 Agility란 명사의 줄임말로 사전적 의미는 민첩, 명민함이며, 이 명사의 형용사적 표현은 Agile인데 사전적 의미는 날렵한, 민첩한, (생각이) 재빠른, 기민한 이다. 바로 이 포스팅에 기록할 애자일과 같은 이름이다!

 

그럼 프로그래머의 세계에서 애자일이 뜻하는 것은 뭘까? 어떤 것을 빠르게 한다는 뜻일 것이다.

위키백과에선 아래와 같이 설명하고 있다.

ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C

애자일 소프트웨어 개발 - 위키백과, 우리 모두의 백과사전

소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다...(중략)...애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다...(중략)...애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style이라고 할 수 있다. 애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.

일정 주기마다 프로토타입을 만들고, 요구사항이 추가되면 즉시 수정하는 방향으로 하나의 소프트웨어를 완성해 나가는 개발 방법을 애자일이라고 하는 것 같다.

영문 위키백과에선 아래와 같이 말하고 있다.

en.wikipedia.org/wiki/Agile_software_development

Agile software development - Wikipedia

애자일 관행에는 자체 구성 및 교차 기능 팀과 해당 고객 / 최종 사용자의 공동 노력을 통해 요구 사항을 발견하고 솔루션을 개발하는 것이 포함된다. 적응형 계획, 진화적 개발, 조기 전달 및 지속적인 개선을 옹호하고 변화에 대한 유연한 대응을 장려한다.

영문 위키백과에는 '애자일 소프트웨어 개발을 위한 선언문'이라는 항목도 있으니 시간 날 때 이 부분을 읽어보는 것도 좋을 것 같다.

 

위키백과는 저렇게 말하고 있는데, 다른 블로그에선 어떻게 말하고 있을까?

velog.io/@katanazero86/%EC%95%A0%EC%9E%90%EC%9D%BCagile%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

애자일(agile)이란 무엇인가?

 

애자일이란 짧은 주기의 개발단위를 반복해서 하나의 큰 프로젝트를 완성해 나가는 방식이다. 애자일의 핵심은 협력과 피드백을 자주, 빠르게 하는 것이다. 애자일은 방법론이 아닌 사상 또는 철학일 뿐이고, 이런 사상을 계승해 나온 칸반, 스크럼 등이 방법론에 속한다고 생각하면 된다.

www.lgeri.com/report/view.do?idx=19510

IT 개발 기법 그 이상으로 주목받는 애자일(Agile)

애자일 프로세스는 고객관점의 효율적이고 민첩한 변화 대응을 중시한다. 신속한 프로토타입, 변화와 요구에 맞춘 끊임없는 수정은 지금과 같이 방향 예측조차 어려운 경영 환경에서 소프트웨어 개발 기법을 넘어 조직을 운영하는 하나의 원칙이 될 만하다...(중략)...애자일 프로세스는 하나의 정해진 방법론을 이르는 말이 아니다. 애자일(Agile)이란 단어의 뜻에서 알 수 있듯 변화에 기민하면서도 효율적으로 대응하는 다양한 개발 방법론을 통칭하는 말이다. 애자일은 소프트웨어 개발에 있어서 아무런 계획이 없는 방식과 지나치게 많은 계획의 둘 사이에서 타협점을 찾는 시도로 90년대 새로운 패러다임으로 등장하였다. 특히 계획에 너무 의존하여 형식적인 절차를 따르다 시간과 비용의 낭비가 발생하거나 개발 흐름이 지연되는 단점을 개선하기 위한 고민의 산물이다. 애자일 방식은 짧은 단위로 계획을 자주 세우고 중요한 것부터 반복적으로 실행한다. 이를 통해 요구조건의 변화를 즉각적으로 반영하고 잦은 시행착오를 거쳐 지속적으로 개선해 나간다. 앞을 예측하여 계획을 세우지 않고 끊임없이 프로토타입을 만들면서 그때그때 필요한 요구를 더하고 수정해 나간다. 그러다 보면 당초에 생각하지 못했더라도 결국은 여러 니즈에 가장 잘 부합하는 결과물이 완성되는 것이다...(중략)

www.incodom.kr/%EC%95%A0%EC%9E%90%EC%9D%BC_%EB%B0%A9%EB%B2%95%EB%A1%A0

애자일 방법론

애자일 방법론의 장점
- 프로젝트 계획에 걸리는 시간을 최소화할 수 있다
- 점진적으로 테스트를 진행할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다
- 계획 혹은 기능에 대한 수정, 변경에 유연하다
- 고객 요구사항에 대한 즉각적인 피드백에 유연하며 프로토타입 모델을 빠르게 출시할 수 있다

단점
- 확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다
- 고객의 요구사항 및 계획이 크게 변경될 경우 모델이 무너질 수 있다
- 개인이 아닌 팀이 중심이 되서 공통 작업들이 많을 수 있다(회의, 로그 등)
- 반복적인 업무로 속도는 빠를 수 있지만 미흡한 기능들에 대한 대처가 필요하다
- 확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다

결론은 애자일이란 일정 주기마다 빨리빨리 개발해나가고 피드백을 즉각적으로 받아서 수정해 프로젝트를 완성해나가는 걸 말하는 듯하다.

그럼 TDD는 뭘 말하는 걸까?

 

ko.wikipedia.org/wiki/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C

테스트 주도 개발 - 위키백과, 우리 모두의 백과사전

테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. 이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다.

테스트 주도 개발이란 이름답게 테스트가 메인이 되어서 최종 목표를 향해 열심히 개발하는 프로세스를 말하는 것 같다.

위 문장들은 한글 위키백과에 설명된 내용이지만 영문 위키백과에서 확인할 경우 좀 더 많은 내용들을 볼 수 있다. 매우 짧은 개발 사이클이란 말이 있는데, 이 사이클 안에는 어떤 과정들이 있는지 확인해보자.

다음 순서는 Test-Driven Development by Example 책을 기반으로 한다.

1. 테스트 추가 : 새 기능의 추가는 사양이 충족되면 통과하는 테스트를 작성하는 걸로 시작된다. 개발자는 사용 사례 및 사용자 스토리에 대해 질문해 이런 사양을 찾을 수 있다. 테스트 기반 개발의 주요 이점은 개발자가 코드를 작성하기 전에 요구 사항에 집중할 수 있다는 것이다. 이것은 단위 테스트가 코드 후에만 ​​작성되는 일반적인 관행과는 대조적이다.

2. 모든 테스트를 실행한다. 새로운 테스트는 예상되는 이유 때문에 실패해야 한다 : 이것은 원하는 기능에 실제로 새 코드가 필요하다는 걸 보여준다. 테스트 장치가 올바르게 작동하는지 확인한다. 새 테스트에 결함이 있고 항상 통과할 가능성을 배제한다.

3. 새 테스트를 통과하는 간단한 코드 작성 : 우아하지 않거나 하드 코드는 테스트를 통과하는 한 허용된다. 코드는 5번째 단계에서 다듬어질 것이다. 테스트된 기능 외에는 코드를 추가하면 안된다.

4. 이제 모든 테스트를 통과해야 한다 : 실패하면 통과할 때까지 새 코드를 수정해야 한다. 이렇게 하면 새 코드가 테스트 요구 사항을 충족하고, 기존 기능을 손상시키지 않는다.

5. 기능이 유지되는지 확인하기 위해 각 리팩토링 이후 테스트를 사용해서 필요에 따라 리팩토링한다 : 가독성, 유지 보수성을 위해 코드가 리팩토링된다. 하드코딩된 텍스트 데이터는 제거해야 한다. 각 리팩토링 이후 테스트 스위트(Test suite)를 실행하면, 기존 기능이 손상되지 않도록 하는 데 도움이 된다.

반복 : 위 주기는 각각의 새로운 기능에 대해 반복된다. 테스트는 작고 점진적이어야 하며 자주 커밋해야 한다. 이렇게 하면 새 코드가 일부 테스트에 실패할 경우 프로그래머는 과도하게 디버깅하는 대신 간단히 실행 취소하거나 되돌릴 수 있다. 외부 라이브러리를 사용할 때 라이브러리 자체에 버그가 있거나, 모든 기능을 제공할 만큼 충분한 기능이 풍부하지 않다고 믿을만한 이유가 없는 한 라이브러리 자체만 효과적으로 테스트할 수 있을 정도로 작은 테스트를 작성하지 않는 게 중요하다.