안녕하세요 애자에요
오늘은 제가 일하는 방법에 대해 알아볼까요~?
아 그 전에 질문 하나!
소프트웨어란 무엇인가?!
-> 컴퓨터 시스템을 효율적으로 운영하기 위해 개발된 프로그램
음... 듣고나니 여러가지 의문이 드네요
과연 시스템을 효율적으로 운영하기 위해 개발된 프로그램만이 소프트웨어일까요?
우리와 밀접한 관계를 가지고 있는 인스타그램, 유튜브, 페이스북은 소프트웨어가 아닌걸까요?
아닙니다. 그것들 또한 소프트웨어입니다.
우리의 삶을 아주 효율적으로 갉아먹으니까요!
엄마는 아들 믿어.jpg
사실 우리가 말하는 소프트웨어라는 것은 일반적으로 응용소프트웨어를 말합니다. 무언가를 위한, 다시 말해 특정 목적을 가진 컴퓨터 프로그램들을 같은? 그것이 어떤 것이든 말이죠. 저 위에 보이는 안드로이드 스튜디오, 어도비, 아나콘다, 인텔리줴이, 디스코드, 키테스트, 기타 등등 모두가 다 해당됩니다.
그래도 헷갈리신다구요? 음... 조상님들이 하신 말씀중에 그런 말이 있죠
얼리어답터 을모씨
하드웨어가 아니면 소프트웨어다 - 을지문덕
아 응용프로그램도, 운영체제도, 모든게 다 소프트웨어구나. 깨우쳤습니다
잡소리가 길어졌네요 ㅎㅎ..
제가 블로그 포스팅 경험이 없는지라.. 제 글은 제가 읽어봐도 지루하고 읽기 싫게 쓰더라구요
그래서 최대한 사진도 많이 넣고, 쓸데없는 드립도 조금씩 넣는데.. 불편하시다면 죄송합니다 ㅠㅠ
그럼에도 미숙한 제 포스팅 읽어주셔서 감사합니다. 균형있는 포스팅하도록 항상 노력하겠습니다!!
그럼 오늘의 주제에 대해 알아볼까요?
소프트웨어 방법론
1. 소프트웨어 방법론의 종류
소프트웨어 방법론에는 오늘 소개할 애자일 방법론을 제외하고도 많은 종류가 있습니다.
애자일 방법론에 대해 알아보기 전에 어떤 방법론들이 있는지, 그리고 그에 대한 간단한 설명입니다.
1) 구조적 방법론
구조, 흐름, 간결, 간단 이 네가지가 구조적 개발방법론의 특징
2) 정보공학 개발방법론
기업 전체 또는 주요부분을 계획, 분석, 설계 및 구축에 정형화된 기법들을
상호 연관성 있게 통합, 적용하는 데이터 중심 방법론
3) 객체지향 개발방법론
현실 세계의 개체를 속성과 메소드가 결합된 형태의 객체로 표현하며, 현실 세계에 존재하는 실체 및 개념들을 객체라는 독립된 단위로 구성하고 이 객체들이 메시지 교환을 통해 상호작용함으로써 전체 시스템이 운영되는 방법론
4) 컴포넌트 기반 개발방법론
개발된 소프트웨어 컴포넌트를 조립, 시스템을 개발하여 객체지향의 단점인 소프트웨어 재사용성을 극대화한 개발 방법론
본격적으로 오늘의 주제! 애자일 방법론에 대해 알아보겠습니다!
애자일 방법론
애자일 방법론이 뭔가요?
애자일 방법론은 영어로 Agile Methopology입니다.
Agile(민첩한) + Methopology(방법론)
말 그대로 민첩한 방법론입니다!
고객과의 소통에,
문서작성보다는 소프트웨어에,
철저한 계획보단 변화에 대한 민첩한 대응을 핵심가치로 두는 방법론이죠.
그럼 기존 방법론은 안그랬나요?
놀랍게도 그렇습니다.
무언가 실용적인것보다 겉보기에 좋아보이는게 중요하고,
무언가를 실제로 하는 것보다 그것을 문서로 작성하여 기록하는게 중요한,
변화보다 계획이 더 중요한.. 그런 방법론들이 대부분이였죠.
변화, 대응, 협업, 가치창출이 중요한 소프트웨어 개발에서는 그런 방법론을 지양합니다.
현재 모든 IT 기업들이 애자일 방법론을 기반으로 운영하는 이유도 그것에 있습니다.
방법론이라기보다는 개발 철학? 에 가깝다고 볼 수 있겠네요.
어찌보면 전쟁과 비슷하다고 할 수 있습니다.
분명 적군이 쳐들어올 것을 대비해 어느정도의 계획을 세워놨겠죠.
하지만 갑자기 비가 많이와서 강이 많이 불어난 것과 같은 환경적 요소,
갑작스레 나타난 지원군, 예상치 못한 공성병기 등 수많은 변수가 존재합니다.
따라서 그 순간마다 적절하게 대응하고 협력하는 것이 승패에 더 큰 영향을 미칩니다.
이렇듯 굉장히 변화에 민감한 이벤트이기 때문에 절차적인 요소들보다 '전쟁' 자체에 중점을 두는거죠.
애자일 또한 그렇습니다. 오랜 시간에 걸쳐 짜놓은 구체적이고 완벽한 계획보다
상황에 대한 발빠른 대처와 협력를 통해 변화에 민감한 소프트웨어 개발에 중점을 두는 것입니다.
애자일 방법론의 특징
- 문서화보다 소프트웨어의 개발 자체에 중점을 둠
- 고객과의 원활한 소통
- 요구사항 변경보다 대응을 목적으로 함
- 주기적인 회의를 수행함
- 빠른 출시 후 유지보수
- 변화에 발빠르게 대응함
아 이런 특징이 있군요. 근데 애자일 방법론이라는게 그 자체로 방법인가요?
방법이라기 보다는 지침서나 철학에 가깝습니다.
애자일 안에 여러 기법들이 포함되어 있고, 사상이라고 부르는 분들도 계십니다.
그럼 어떤 종류가 있나요?
애자일 방법론의 종류
1) 스크럼
스크럼.. 애자일하면 스크럼이라고 할 정도로 굉장히 응용 범위가 넓은 개발 기법입니다.
비단 소프트웨어 개발만이 아닌 다른 일반적인 프로그램, 프로젝트 관리에도 사용이 가능합니다.
진행 과정
1) 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정함
2) 프로젝트 책임자가 정한 제품의 우선순위에서 어디까지 작업할지 팀과 조율함
3) 조율 후 선정된 제품 백로그를 금번 스프린트의 목표로 설정함
4) 스프린트 목표를 구현 가능하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당함
5) 스프린트를 진행하는 동안 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 진행함
6) 매 스프린트가 종료될 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품에 대해 학습하고 이해함
7) 제품의 학습과 이해가 끝나면 스프린트 회고를 통해 팀 개발 프로세스에 대한 개선의 시간을 가짐
8) 스프린트 기간 중 다음 스프린트를 준비하기 위해 PO와 필요 인원이 모여 백로그를 준비함
2) 익스트림 프로그래밍
아 이 부분에 대해서 공부할수록 정처기 필기시험이 생각나서 어지러워요.
누구보다 빠르게 설명하고 도망가겠습니다.
익스트림 프로그래밍이란, 고객에게 <최고의 가치를 가장 빨리> 라는 목표를 가지는 방법입니다.
기능성, 퀄리티, 물론 다 중요하지만 이들은 속도에 미쳐있습니다. 속도 최대로!
- 빠른 개발
- 시장 대응 능력 향상
- 유연한 대처
- 생산성 향상
위와 같은 장점이 있는데, 이러한 장점들을 위한 여러가지 요소들 또한 존재합니다.
좋게 말하면 생산성이지만 팀원들에게는 힘들 수 있는..
- 계획을 빠르게 세운 뒤, 개발 중에 계획을 추가함
- 페어 프로그래밍을 통해 모든 코드가 리뷰됨
- 단거리 달리기처럼 짧게 개발하고 릴리즈하여 피드백을 수집함
- 인테그레이션을 자주한다. 물어보기전에 인테그레이션하고 물어보는 정도
- 지속적인 리팩토링을 통해 구조를 개선함
아직 경험해본 적은 없지만.. 단거리 달리기 선수들 같습니다.
XP의 과정은 아래와 같습니다. 대규모 프로젝트에는 적용하기 힘든 방법이 분명하네요.
1) 유저 스토리
- 사용자의 요구사항을 적어놓은 것
2) 스파이크
- 기술적/설계적 위험을 미리 탐지하기 위해 프로젝트 시작전에 핵심 기능을 간단하게 구현해보는 것
3) 릴리즈 계획
- 릴리즈 시점에 대한 일정을 세우고 각 주기마다 개발할 스토리를 유저가 선택함
4) 주기 개발
- 유저 스토리와 스파이크를 활용하여 개발함(중도 추가, 업데이트 가능)
5) 인수 테스트
- 주기가 시작됨과 동시에 고객이 테스트 시나리오를 만듬. 사용자는 테스트 시나리오를 바탕으로 인수 테스트 코드를 작성하고 주어진 스토리가 인수 테스트를 통과하면 작은 릴리즈를 실시함
익스트림 프로그래밍은 릴리즈-주기-인수테스트를 거의 동시에 진행하며 반복됩니다.
만약 주기 개발중에 스토리가 업데이트되면 다시 릴리즈 계획 단계로 돌아가는 식으로!
3) 짝 프로그래밍
짝!
아 이 짝이 아닌가.. 당연히 아니지
사실 여기서 짝은!
신발도 짝이 있고 양말도 짝이 있고 내 에어팟은 짝이 없고...😥 할 때 그 짝입니다
두 사람이 짝이 되어서 한 사람은 코딩을 하고, 한 사람은 코드 리뷰를 담당하는거죠!
올바른 짝 프로그래밍
두 명이 한 쌍이 되어(?) 사이좋게 코드 리뷰를 하는 모습이 훈훈하네요.
인터넷에는 30분마다 역할을 교체한다고 나와있는데, 보통 삘 받으면 한두시간 정도는 훅 지나가더라구요 경험상..
둘이서 같이 하는데 분명 장점이 있겠죠?
이렇게 한 사람은 코딩을, 한 사람은 코드 리뷰를 하면
1) 코드에 대한 책임을 공유함(우리 이제 공범이야)
2) 비형식적 검토 수행
3) 코드 개선을 위한 리팩토링 장려
4) 생산성 증가(한 컴퓨터에서 같이 개발하지만 따로 개발하는 것에 비해 생산성이 저하되지 않음)
이러한 장점이 있습니다. 
4) 테스트 주도 개발
테스트 주도 개발이란, 테스트 케이스를먼저 작성하고 이걸 통과하는 코드를 개발하는 것을 말합니다.
어? 보통 개발을 완료한 후에 테스트를 진행하지 않나요?
A: 그렇습니다. 하지만 테스크 주도 개발은 그 역순으로 진행한다는거!
그럼 어떤 순서로 진행되나요?
1) Task 별로 테스트 케이스 생성
2) 요구사항 - 스토리카드 - Task
3) 요구사항은 스토리 카드로 표현되고 스토리 카드는 Task들로 분해됨
4) 코드간의 관계가 명확해짐
이러한 순서로 진행됩니다! 어.. 생각보다 간단하네요
그럼 이 방법은 아무때나 써도 적용이 쉬운가요? 좋은가요? 어떤 효과가 있죠?
컴퓨터공학부 출신입니다. 수업 시간에 만든 학생 관리 프로그램 수가 제 이빨보다 많아요
그런데 제가 학생 관리 프로그램을 또 제작한다면.. 여기에 테스트 주도 개발을 적용하는게 효율적일까요?
아니죠. 눈감고도 할 수 있을 정도로 잘 아는 로직과 어떤 결과가 나올지 다 아는 상황에서 테스트 주도 개발 방법을 사용하는 것은 비효율적인 일입니다. 득보다 실이 많은 상황이 되는거죠.
즉, 불확실성이 높은 상황이라면 테스트 주도 개발을 적용하면 됩니다.
애자일 방법론의 장/단점
애자일 방법론의 공통적인 장/단점입니다.
1) 장점
- 프로젝트 계획에 들어가는 시간을 단축시킬 수 있음
- 계획/기능 등에 대한 유지보수가 유용함
- 요구사항에 빠르게 대응할 수 있음
- 우선적으로 출시한 후 개선해나갈 수 있음
2) 단점
- 계획에 들어가는 시간이 적은만큼 부실하여 그만큼 유지보수에 들어가는 시간이 증가함
- 반영할 수 없는 요구사항일 경우에 실현이 불가능하고
- 빠른 작업과 수정이 가능하지만 그만큼 굉장히 자주 반복적으로 해야함
- 숙련도가 낮은 팀원이라면 적응하기 힘들 수 있음
여러 장점이 많은만큼, 그에 따른 단점도 확실하게 따르는 것 같습니다.
하지만 현재 IT 시장의 변화는 빠르고, 예측이 어려우며 까다롭습니다. 그렇기에 애자일이라는 사상?철학?방법론?이 여러 기업들에게 매력적으로 느껴졌다고 생각하구요.
이번 포스팅을 진행하면서 한 편으로 느낀건, 애자일이 기업에는 결과적으로 이익을 가져다주지만
개발자들에게는 원수가 될 수도 있지 않을까..라는 그런?
미래에 취업하게 된다면 실무를 뛰며 느끼겠죠? 내심 얼른 그 날이 왔으면 좋겠다는 생각을 합니다.
그 때 되면 애자일은 아군인가 적군인가에 대한 포스팅을 할지도 모르겠네요.
오늘은 이렇게 애자일 방법론에 대해 알아봤는데요, 어떻게 이해가 잘 되셨는지 모르겠습니다..
요즘 포스팅하면서 느낀 점이라면 내 생각을 남에게 간단명료하게 전달하는 방법은 존재하지 않는다는 거
이거 단 하나입니다. 동영상을 아무리 잘 만들어도 인코딩하지 않으면 깨져버리는.. 그런 느낌이에요
오늘도 봐주셔서 감사하고, 앞으로 포스팅은 몇 일 간격으로 올라갈 것 같습니다.
프로젝트 진행예정인게 하나 있고, 토이 프로젝트도 만지고 여러가지 많이 하는중이라 시간 부족하네요.
그럼 다음에 만나yo 핐쓰~🤘
