📃 애자일 아버지의 고함과 호통 ✍️ 들어만 보고 좋다고는 하는데 막상 팀 내에 도입하려면 상당한 시행착오가 있어 결국 기존대로 흘러가곤 하는 그것. 애자일(Agile). 사전적 정의로는 "소프

📃 애자일 아버지의 고함과 호통 ✍️ 들어만 보고 좋다고는 하는데 막상 팀 내에 도입하려면 상당한 시행착오가 있어 결국 기존대로 흘러가곤 하는 그것. 애자일(Agile). 사전적 정의로는 "소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기 동안 반복적인 개발을 촉진한다."라고 나와있습니다. 처음 들었을 땐 개념을 이해하기가 다소 어려웠는데 결국 "업무를 작은 단위로 진행하라는 거 아니야?"라고 편협적으로만 이해하고 도입하게 되면 대부분 앞서 이야기 한 것처럼 얼마 가지 못해서 이도 저도 아닌 업무 프로세스가 될게 뻔합니다. ( 애자일에 대한 전반적인 내용을 이해하려면 애자일의 아버지가 쓰신 "클린 애자일" 이라는 책을 추천합니다. ) 그럼 개발자 입장에서는 애자일을 어떻게 바라봐야 할까요? 대부분의 소프트웨어 제품을 만드는 팀 혹은 조직은 개발자 만으로 구성되진 않고 기획부터 설계, 디자인 등 다양한 직군과 협업을 하며 진행됩니다. 그때 지속적 통합(continuous integration, CI)은 기본이고 테스트 코드 및 리펙터링 등 개발자가 챙길 수 있는 것들을 잘 구성(톱니바퀴 사이클) 해야 원활한 애자일 스러운 업무 프로세스가 될 것으로 기대합니다. 물론, 애자일을 위해 개발자의 시선에서 챙겨야 할 여러 요소들이 원활히 돌아가려면 당연히 코드의 품질이 단단히 받쳐줘야 설계했던 톱니바퀴가 잘 돌아가지 않을까 싶습니다. 결국 애자일 또한 "읽기 좋은 코드를 작성해야 한다"부터 시작되는 것 같기도 하네요.