https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md

'공부' 카테고리의 다른 글

마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08

칸반이란?

칸반은 연속적 흐름 처리 방식입니다. 이슈는 큐에 입력되고, 개발 프로세스의 단계에 따라 “당겨”집니다. 칸반은 칸반 보드로 시각화되고 각각 단계는 열로 표시됩니다. 이슈들은 “수영 레인(Swimlane)”으로 불리는 행으로 나눌 수 있습니다. 이슈들의 우선순위를 나타내기 위해 수영 레인을 이용하기로 결정하고  우선순위가 낮은 이슈들을 아래에 배치합니다. 칸반의 핵심은 Work-In-Process(WIP)가 동시에 개발이 진행 될 수 있는 아이템의 수를 제한하는 것입니다. 작업자는 WIP에 여유가 있을때만 작업을 왼쪽에서 오른쪽으로 당길 수 있습니다. 스크럼이 스프린트에 이용할 수 있는 작업 시간을 제한함으로써 생산성을 제어하는 반면, 칸반은 동시에 처리할 수 있는 이슈의 수를 제한함으로써 생산성과 벨로시티를 제어합니다. 추정은 더이상 프로세스의 일부가 아닙니다.

벨로시티는 여전히 중요 목표지만 지금 우리는 이슈 레벨에 따라 최적화 시켰고, 사이클 타임이라고 부르고 있습니다. 보드의 오른쪽에 있는 아이템은 그 뒤의 아이템들보다 더 높은 우선순위를 가집니다. 이것은 팀의 중요한 핵심 가치를 만들어 냅니다. 더 많은 작업을 하기 전에, 지금 하고 있는 작업부터 끝내야합니다. 또한 멀티 테스킹을 그만두고 이 일 저 일을 번갈아가면서 하는 것을 지양합니다.

칸반을 사용하면 사업적 요구에 따른 우선순위의 변동이 사라집니다. 사업팀은 “To Do” 열을 소유하고, 기술팀은 나머지 모든 열을 소유합니다. 사업팀은 작업들이 To Do에 있는 동안 야생 동물처럼 날뛰게 할 수 있지만, 다른 열로 이동된 이후에는 큰 노력 없이 그것들을 바꿀 수 없습니다. 결과적으로, 개발자들은 작업을 선택하는 순간 사업적인 영역과 단절됩니다.

칸반 간략 설명

칸반 장점

스크럼은 개발자에게 규범적이고 유연하지 못한 규칙을 부과하여 관리되는 것 처럼 느껴지게 만들었지만, 칸반은 탄력적이고 절차 지향적이고 기술 조직에 의해 관리됩니다. 게다가, 연속적인 흐름 모델은 “데드라인”이 없다는 것을 의미합니다. 그러나 “속도”에 대한 압박은 늘 존재합니다. 개발속도에 대한 압박은 존재하지만 데드라인이 없어 전체적인 생산성은 더 향상될 수 있습니다. 스크럼과 대비하여 전체 팀 플래닝 스프린트로 격주에 한번씩 반나절을 허비하지 않았을 수 있고 스프린트와 일치시키기 위해 개발 범위를 속이지 않을 수 있습니다. 칸반은 생산성과 코드 품질 모두를 향상시킬 수 있는 방법론이고, 한번에 여러 업무를 진행하는데서 오는 혼란을 감소 시킵니다. 거기다, 모두가 칸반 보드만 보면 무엇이 누구에 의해, 얼마정도 진행되고 있는지, 다음 작업을 위해서 무엇이 필요한지, 병목이 어디인지 알 수 있기 때문에, 프로젝트 관리 오버헤드를 감소시킬 수 있습니다.

품질에 대한 조직적 목표

계획적이지 않은 칸반의 주요 이점은 소프트웨어 품질에 초점을 맞출수 있게 해주는 것입니다. 스크럼에서는, 스프린트 내에 있는 것을 하기 위하여 코드리뷰를 건너뛰고, 코드 커버리지 표준인 95%에 못미치는 70%를 승인하는 등 기술적 부채를 늘려가는 경우가 많았습니다. 칸반에서는, 코드 품질 보증 단계는 프로세스에 포함됩니다. 거의 데드라인이 없기 때문에, 이런 단계를 건너 뛰어야 할 만한 압박이 없어집니다.

개선 VS 회고

스크럼 회고는 칸반에서 개선 회의로 대체됩니다. 개발자와 PO는 오버헤드를 감소시키면서, 속도와 품질을 향상시키기 위해 프로세스가 어떻게 수정되어야 하는지 논의합니다. 한 것을 뒤돌아보고 비판하는 대신, 진취적으로 프로세스를 개선하는데 모든 에너지를 쏟습니다. 방어적인 태도는 줄어들고, 협동력은 향상됩니다. 프로세스 안의 모든 것은 좋은 목표이고 새로운 아이디어들은 테스트 하기 위한 실험들로 간주됩니다. 대부분의 아이디어들은 시도해볼 수 있고, 매우 일부만 탈락합니다. 그 결과, 개선 회의에서는 긍정적이고, 창조적인 느낌을 받을 수 있고, 프로세스는 아주 부드럽게 수행됩니다.

칸반을 위한 소프트웨어 도구들의 미흡

Atlassian Jira와 Greenhopper가 칸반을 위한 좋은 기능들을 가지고 있지만, 이것들의 칸반 보드는 상대적으로 새롭고, 기대하는 것에 비해 유연스럽지 못합니다.(예를 들면, 수영 레인에서 WIP 한계를 가질 수 있도록).그 결과, 프로세스 일부를 Jira와 Greenhopper에서 가능하도록 맞춰야합니다. 칸반 보드를 팀의 특별한 요구에 따라 모델링 할 수 있다면, 칸반을 통해서 더 많은 이점을 얻을 수 있지만 이러한 도구가 미흡합니다.

신속함에 대한 조직의 동기부여 상실

스크럼에서는, 스프린트 시계가 큰소리로 똑딱거립니다. 모두가 스프린트 안에서 일을 완료하기 위해 압박을 느끼고 마음을 급박하게 만듭니다. 칸반에서는, 신속성은 더 추상적이고 그러한 감정적인 압박이 없기 때문에 문화부터 관리에 걸쳐 계속 열심히 해야 조직이 건강하게 유지될 수 있다는 긴장감을 부여해야만 합니다.


칸반이 완벽한 개발방법론은 아니지만 도입해보기엔 충분히 매력적입니다.

'공부' 카테고리의 다른 글

마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08

XP - 익스트림 프로그래밍이란?

비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법입니다. 이 방법은 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽히며, 약칭인 ‘XP’로 잘 알려져 있습니다. 이 방법은 10~12개 정도의 구체적인 실천 방법(Practice)을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋습니다. 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 큽니다. 켄트 백은 XP를 이끄는 가치와 원칙에 대해서도 강조했습니다. XP에서 실천 방법에만 집중하고 가치와 원칙을 무시하면 제대로 XP를 실천하고 있다 하기 힘들 것입니다. 원칙은 가치와 실천 방법을 잇는 다리 같은 것입니다. XP의 목적은 '고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것'입니다. 수시로 발생하는 고객의 요구사항에 대처하고, 고객이 원하는 SW를 고객이 원하는 시간에 인도하기 위해서는 고객과 팀원간의 대화를 통해 해결합니다. 다른 애자일 방법론과 구분되는 XP만의 특징에는 테스팅이 있습니다. XP는 프로그래머들이 코딩을 할 때에 테스트 코드를 작성하도록 함과 동시에 테스트를 기반으로 프로젝트를 완성시켜 나가도록 합니다. 또한 이러한 테스트에 기반을 둔 프로젝트 발전 과정은 애자일 방법론의 기본 개념인 "반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다"를 실천하는 데에 큰 도움을 줄 수 있습니다. 왜냐하면 매번 프로토 타입을 고객에 전달함에 있어서 프로토 타입 자체로써 버그가 상대적으로 적은 완벽에 가까운 데모를 경험하게 해줄 수 있기 때문입니다.

기본 원칙

기본 원칙은 다음과 같습니다.

  1. 조금씩, 하지만 자주 발표
  2. 사이클을 반복해서 돌리면서 개발
  3. 스펙에 없는 것은 절대 집어넣지 않음
  4. 테스트 코드를 먼저 만듬
  5. 야근금지. 항상 정규 일과 시간에만 작업
  6. 기회가 생기는 족족 언제 어디서든 코드를 개선
  7. 모든 테스트를 통과하기 전에는 어떤 것도 발표하지 않음
  8. 조금씩 발표하는 것을 기반으로 하여 현실적인 작업 계획을 만듬
  9. 모든 일을 단순하게 처리
  10. 두 명씩 팀을 편성하고 모든 사람이 대부분의 코드를 알 수 있도록 돌아가면서 작업

실천 방법

 Whole Team

애자일 방법론과 XP 방법론이 많이 사용되기 이전에는 팀을 기반으로 한 소프트웨어 개발이 흔치 않았습니다. 그렇기 때문에 개발자들과 프로젝트에 참여하는 관리자 모두 이러한 방법론에 대해서 진지하게 생각을 하지 않고 있었습니다. 그래서 고전적인 소프트웨어 개발 방법론인 폭포수 모델과 나선 모형에서는 수많은 소프트웨어 개발의 실패를 불러오기도 했습니다. 하지만 애자일 방법론 및 XP 방법론이 유명세를 타기 시작하면서 팀을 기반으로한 협동적인 개발 방법론이 강조되기 시작했습니다. 그러므로, 첫 번째 실천 방법인 Whole Team은 모든 프로젝트에 참여하는 팀원들을 가리키며 개개인이 각자의 역할이 있고 그들의 역할의 중요성을 이야기합니다. XP에서 말하는 Whole Team은 일반적으로 tester, interaction designers, architects, project managers, product managers, executives, technical writers, programmers and users로 구성이 됩니다. 이들 중에서 가장 중요한 팀원은 사용자(user)입니다. 왜냐하면 그들이 프로젝트의 키를 가지고 있는(stakeholder)일 뿐만 아니라 그들을 통해 요구사항(requirement)을 파악 할 수 있기 때문입니다.

Planning Game

XP에서 계획을 세우는데에는 중요한 2가지가 있습니다. 첫 번째로 '이번 반복(iteration)에는 어떤 개발 과정을 끝마칠 것인가' 와 두 번째로 '그 이후 개발 반복(iteration)에서는 무엇을 할것인가' 입니다. XP는 일반적으로 2주를 주기로 계획을 세우고 프로토 타입을 만들어서 최종 사용자 혹은 프로젝트를 의뢰한 의뢰인과 함께 무엇이 얼만큼 개발이 되었는지 혹은 알맞은 방향으로 개발이 진행이 되어가고 있는지 검사 혹은 회의를 합니다. 그렇기 때문에 그 기한 안에 프로젝트 혹은 프로토 타입은 반드시 개발이 완료가 되어야 하며, 그렇지 못해서 기한을 연장하게 되면, 그에 따른 추가 비용 및 시간적 손실이 발생하게 됩니다. 또한, 이를 통해서 소프트웨어 개발의 투명성을 확보 할 수가 있습니다. 기업의 입장에서 좋은 점은 그들의 실력 및 가능성을 보여줄 수 있는 기회로 사용될 수 있으며, 사용자 혹은 의뢰인 입장에서는 더욱 큰 금전적 손실이 발생하기 전에 프로젝트를 취소하고 다른 개발팀을 찾아 볼 수 있는 기회로 사용 될 수도 있습니다.

Customer Tests

가장 흔히 발생하는 소프트웨어 개발 실패 중 하나는 개발이 끝난 제품 혹은 소프트웨어가 처음 사용자 혹은 의뢰인이 원했던 것과 다르다는 것입니다. 그렇기 때문에 XP에서는 반복적으로 customer tests를 거칩니다. 그리고 이를 통해서 그들이 잘못 이해하고 있었던 부분에 대해서 수정을 거치기도 하며 더욱 더 의뢰인 혹은 최종 사용자의 요구에 부합하는 소프트웨어를 만들어 내게 됩니다.

Small Releases

이 실천 방안을 통해서 개발자는 주기적으로 프로토 타입을 의뢰인에게 보여줍니다. 그리고 이를 통해서 의뢰인은 제한된 기능을 가지고 있지만 실제로 작동이 되는 데모 모델을 볼 수가 있으며 추가 사항을 요구 할 수도 있습니다. 기존의 혹은 과거의 소프트웨어 개발 과정에서 개발이 끝나기 이전에 어떤 소프트웨어가 만들어질지 알 수 없었던 것과 비교해서 가장 차이점을 만들어내는 실천 방안입니다. 또한 개발자에게 있어서는 현재까지의 개발 상황이 올바른 길로 가고 있음을 알 수 있습니다.

Simple Design

보통의 프로젝트 개발 혹은 코딩의 경우 기능이 더해지면 더해질수록 복잡해 지기 마련입니다. 그렇게 되면, 새롭게 충원되는 개발자의 경우에 현재까지의 개발 상황을 이해하는데 오랜 시간이 걸리게 됩니다. 또한 버그가 발생할 경우에도 쉽게 처리를 하지 못하고 오랜 시간이 걸리게 됩니다. 그렇기 때문에 XP에서 모든 코딩을 가능한 간단하게 할 것을 강조합니다. 이러한 추세 혹은 트렌드는 KISS 원칙원리와도 함께 한다고 할 수 있습니다. (KISS 원칙이란 디자인에서 간단하고 알기 쉽게 만드는 편이 좋다는 원리를 말합니다.)

Test-Driven Development

테스트를 기반으로한 개발은 XP에서 가장 중요한 실천 방안중 하나입니다. 테스트를 거치고 코딩을 하며 프로젝트를 개발해 나갑니다.

Pair Programming

두명 혹은 그 이상의 프로그래머가 함께 코딩을 하는 것을 말합니다. 두명의 프로그래머가 함께 코딩을 하고 테스트를 통해서 개발을 할 수도 있고, 한명은 코딩을 하고 한명은 Quality Assurance 역할 통해서 테스트에만 집중을 할 수도 있습니다.

'공부' 카테고리의 다른 글

마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08

스크럼이란?

스크럼(Scrum)은 프로젝트관리를 위한 상호,점진적 개발방법론이며, 애자일 소프트웨어 공학 중의 하나입니다. 스크럼(Scrum)은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있습니다.

스크럼 특성

스크럼은 특정 언어나 방법론에 의존적이지 않으며, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법입니다. 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특성을 가지고 있습니다.

  • 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여.
  • 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공.
  • 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공.
  • 날마다 15분 정도 회의.
  • 항상 팀 단위로 생각.
  • 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지.

스크럼이 추구하는 가치

스크럼은 다음의 5가지 가치에 중점을 두어 진행됩니다.

확약

  • 약속한 것을 확실히 실현하는 것

전념

  • 확약한 것의 실현에 전념하는 것

정직

  • 어떤 것이 자신에게 불리해도 숨기지 않는 것

존중

  • 자신과 다른 사람에게 경의를 표하는 것

용기

  • 팀 구성원은 자신이 옳은 일을 할 수 있도록 팀원 간 갈등과 도전을 통해 작업 할 수 있는 용기

스크럼의 진행

스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킵니다. 아래는 스크럼 진행시 나타나는 중요 요소입니다.

  1. 일반적인 권장기간은 30일 이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주의 유연성을 가짐.

제품 백로그(Product Backlog)

  • 개발할 제품에 대한 요구 사항 목록

스프린트(Sprint)

  • 반복적인 개발 주기 (회사에서 정하는 이터레이션이 개발 주기가 됨. 계획 회의 부터 제품 리뷰가 진행 되는 날짜 까지의 기간이 1스프린트임)

스프린트 계획 회의(Sprint Planning Meeting)

  • 스프린트 목표와 스프린트 백로그를 계획하는 회의

스프린트 백로그(Sprint Backlog)

  • 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

일일 스크럼 회의(Daily Scrum Meeting)

  • 날마다 진행되는 미팅 (어제 한일, 오늘 할일, 장애 현상 등을 공유)

실행 가능한 제품(shippable product)

  • 개발 스프린트의 결과로써 나오는 실행 가능한 제품

상기 요소들을 아래와 같은 순서에 따라 사용하여 스크럼을 진행시킵니다.

  1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정함.
  2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 됨.
  3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당.
  4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가짐.
  5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해.
  6. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖음.
  7. 스프린트 기간 중 다음 스프린트를 준비 하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖음.


이러한 진행 방식과 더불어, 개발 팀원 이외에 아래와 같은 직책(역할)이 정의되어 있습니다.

제품 책임자(Product Owner)

  • 제품 백 로그를 정의하여 우선순위를 정해 줌.

스크럼 마스터(ScrumMaster)

  • 프로젝트 관리자(코치)

스크럼 마스터는, 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할을 하며, 제품 책임자는 스프린트 목표와 백로그등의 결정에 있어 중심이 되는 상위 관리자로, 제품 책임자가 독단적으로 목표를 결정하지 않고, 고객과 관리자 및 팀원들이 모여서 목표를 정합니다.

이런 과정을 거친 뒤, 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해 나가게 됩니다. 보통, 각 작업들은 4시간에서 16시간 정도 걸리도록 정합니다. 물론, 작업을 정하고 할당하는데는 고객이나 제품 책임자와는 상관 없이 팀원 자율로 진행됩니다. 이와 같은 자율적인 행위를 통해서 팀원들은 의사를 활발하게 주고 받게 되고, 끈끈한 협업체계를 가지게 됩니다.


애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여기고 있습니다. 하지만, 이러한 부분과 더불어 애자일 프로세스는 무질서해 보이기 때문에 전통적인 프로세스 개선과 마찰이 생기게 됩니다.

'공부' 카테고리의 다른 글

칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08
소프트웨어 개발 방법론  (0) 2017.03.08

read–eval–print loop의 약자로 파이썬 대화형 환경 같은 걸 말합니다. 컴파일 과정없이 즉석에서 코드를 입력하고 결과를 바로 알 수 있기 때문에 아주 편리합니다.


'공부' 카테고리의 다른 글

XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08
소프트웨어 개발 방법론  (0) 2017.03.08
문자열 인코딩 (unicode/UTF8, UTF16, ASCII)  (0) 2016.11.09

애자일 소프트웨어 개발이란?

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론입니다. 계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있으며, 계획에 너무 의존하는 경우는 그 형식적인 절차를 따르는데 필요한 시간과 비용을 무시할 수 없으며, 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있습니다.

그렇기 때문에 애자일 방법론에서 택한, 그리고 다른 고전적인 방법론, 예를 들면 폭포수 모델 또는 나선 모형과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code-oriented, 실질적인 코딩을 통한 방법론이라는 점입니다. 그러므로 애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style이라고 할 수 있습니다.

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말입니다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸습니다. 익스트림 프로그래밍(XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있습니다.

폭포수 모델이란?

폭포수 모델(waterfall model)은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌습니다. 이 폭포수 모델의 흐름은 소프트웨어 요구사항 분석 단계에서 시작하여, 소프트웨어 설계소프트웨어 구현소프트웨어 시험소프트웨어 통합 단계 등을 거쳐, 소프트웨어 유지보수 단계에까지 이릅니다.

한계점 

주로 실제 실행에 있어 불가능한 모델이라는 점이 그 주요 논지인데, 의미있는 규모의 프로젝트에서는 다음 단계에 대한 이해나 경험 없이, 각 단계를 완벽히 마무리한 후 다음 단계를 진행하는 것이 불가능하다는 것입니다. 예를 들어 고객들은 동작하는 프로토타입을 보지 않고는 정확히 자신들이 무엇을 원하는지를 요구사항으로 정하지 못할 수 있습니다. 또 고객들은 정해진 요구사항을 빈번하게 수정해달라고 요구하는 경우도 많으며, 그럴 경우 설계자나 구현자가 이를 통제할 수 있는 방법은 많지 않습니다. 만약 고객이 설계가 완료된 이후에 요구사항 변경을 요구했다면, 설계는 새로운 요구사항을 위해 변경되어야 하고 그때까지 투입된 많은 노력은 무위로 돌아가게 됩니다. 또한 설계자들은 설계 시에 향후 구현 작업의 난이도를 예측하기 어렵습니다. 즉, 구현 단계에 이르러서야 특정 부분의 설계를 구현하는 것이 불가능하거나 매우 어려움이 명백해지는 경우가 있을 수 있습니다. 그럴 경우, 기존 설계를 유지하여 어려운 구현을 진행하는 것보다 재설계를 택하는 것이 향후 발생할 수 있는 더 큰 문제 상황을 방지하는 데 나은 선택입니다.

기존 개발 프로세스와 차이점

전통적인 개발 프로세스들은 폭포수 모델과 계획 기반 개발을 따르는 반면, 애자일 개발 프로세스는 그에 반한다는 점에서 가장 큰 차이를 가집니다. 폭포수 모델과 계획 기반 개발 기법들은, 일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킵니다. 이것은, 이해하기도 쉽고 사용하기도 쉬운 바람직한 기법이기도 하지만, 이로 인해서 많은 부작용이 생길 수 있습니다. 가장 큰 부작용이 발생할 때는, 계획대로 진행되지 않을 경우입니다. 이럴 경우에는 다음과 같은 부작용이 발생하게 됩니다.

  • 납기일 전 철야
  • 철야에도 불구하고 납기일 지연
  • 지연에 따른 비난과 스트레스로 개발자 에너지 소진
  • 결국 납품된 솔루션은 고객의 요구를 충족하지 못함

이런 부작용은 근본적인 개발 프로세스 접근법의 차이에서 나타납니다. 전통적인 개발 프로세스들은 공업에서 사용하는 정형적 프로세스 제어 모델을 따르고 있습니다. 정형적 프로세스 제어모델은, 동일한 입력에 대해서 동일한 결과가 기대 될 경우에 적합합니다. 하지만, 소프트웨어를 포함한 IT의 개발은 경험적 프로세스 제어 모델로 접근할 필요가 있습니다. 경험적 프로세스 제어 모델은 항상 불확실성을 수반하고 포용하고 있습니다. 애자일 개발 프로세스는 경험적 프로세스 제어모델로 개발을 관리합니다.

종류

애자일 개발 프로세스로 불리는 개발 방법론에는 다음과 같은 것들이 있습니다.

  • 익스트림 프로그래밍(Extreme Programming, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 함. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있음.
  • 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있음. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론.
  • 크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론.
  • Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가짐.
  • Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론. 내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는 것이 조금 다름.
  • 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 함.

상기 소개된 애자일 개발 프로세스들은 각자 다른 특징과 적용 범위가 있으며, 서로 조합도 가능합니다. 애자일 개발 프로세스를 채용하고 있는 프로젝트에서는 특정 방법론만을 채택해서 매뉴얼대로 흉내만 내는 것이 아니라, 여러 방법 중에서 자신의 프로젝트에 맞는 부분을 취사 선택하여 조합하고, 또 독자적인 방법을 만들어 냄으로써 큰 효과를 올리고 있습니다. 이러한 애자일 개발 프로세스의 제창자들은 애자일 연합이라는 자유로운 조직을 만들고, 애자일 개발 프로세스의 보급에 힘쓰고 있습니다.

적용대상

애자일 개발 프로세스를 필요로 하는 조직은 크게 두 가지로 나뉩니다.

  1. 하나는 목표 달성을 위한 프로세스를 가지지 않고, 임기응변적인 소프트웨어 개발로 인해 혼란에 빠져있는 조직. 이러한 프로젝트 팀에게 있어 애자일 개발 프로세스는, 개선을 위한 좋은 힌트가 될 것입니다. 애자일 개발 프로세스는 작고 쉽게 도입할 수 있으며, 그것에 들어가는 비용과 위험도 낮습니다.
  2. 두 번째는 이미 전통적인 소프트웨어 프로세스를 도입하고 있지만, 제대로 동작하지 않는(또는 프로세스 실시를 위한 오버헤드가 너무 커서 오히려 업무에 부담을 주고 있는) 조직. 프로세스의 도입은 조직의 문화를 바꿉니다. 효과가 크면 클수록 조직문화에 대한 영향은 커지고, 도가 지나치게 되면 고유의 문화를 파괴해 버리기도 합니다. 그러나 조직에 있어서 애자일 개발 프로세스는 좋은 결과를 가져다 줄 것입니다. 또한 CMMI나 SPICE등의 인증을 얻으려고 하는 조직에서는 그들의 요구를 충족시킬 아이디어를 제공해 줄 수 있을 것입니다.


'공부' 카테고리의 다른 글

스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08
소프트웨어 개발 방법론  (0) 2017.03.08
문자열 인코딩 (unicode/UTF8, UTF16, ASCII)  (0) 2016.11.09
데이터 검증 유의사항  (0) 2016.10.17

소프트웨어 개발방법론의 정의

  • 소프트웨어 개발 방법론은 소프트웨어를 생산하는 데에 필요한 반복적인 과정들을 정리한 것
  • 소프트웨어 공학 원리를 소프트웨어 개발 생명주기에 적용

소프트웨어 개발 방법론의 필요성

  • 개발 경험 축적 및 재활용을 통한 개발 생산성 향상(작업의 표준화/모듈화)
  • 효과적인 프로젝트 관리(수행공정의 가시화)
  • 정형화된 절차와 표준 용어의 제공으로 의사 소통 수단 제공

연도별 흐름

1970198019902000
구조적 프로그래밍구조적 시스템 분석과 설계 방법론

객체지향 프로그래밍

고속개발 방법론

스크럼

익스트림 프로그래밍

래셔널 통합 프로세스

애자일 통합 프로세스


'공부' 카테고리의 다른 글

REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08
소프트웨어 개발 방법론  (0) 2017.03.08
문자열 인코딩 (unicode/UTF8, UTF16, ASCII)  (0) 2016.11.09
데이터 검증 유의사항  (0) 2016.10.17
유니코드 BOM(Byte Order Mark)  (0) 2016.10.12

게이트웨이는 ‘관문’이나 ‘출입구’라는 의미로 다양한 분야에서 일반적으로 사용되는 용어입니다. 컴퓨터 네트워크에서의 게이트웨이는 현재 사용자가 위치한 네트워크에서 다른 네트워크로 이동하기 위해 반드시 거쳐야 하는 거점을 의미합니다. 자동차 고속도로로 진입하기 위해 통과하는 톨게이트와 유사한 개념입니다.

두 컴퓨터가 네트워크 상에서 서로 연결되려면 동일한 통신 프로토콜을 사용해야 합니다. 따라서 프로토콜이 다른 네트워크 상의 컴퓨터와 통신하려면 두 프로토콜을 적절히 변환해 주는 변환기가 필요한데, 게이트웨이가 바로 이러한 변환기 역할을 합니다. 한국인과 미국인 사이에 원활한 의사소통을 위해 통역사를 두는 것과 동일합니다.

게이트웨이는 네트워크간 톨게이트

게이트웨이는 일반적으로 하드웨어 형태로 제공되며, 내부적으로 복잡한 원리로 작동하지만 외형은 생각보다 간단합니다. 흔히 보는 네트워크 허브나 스위치 등과 비슷하게 생겼습니다. 또한 기능이나 용도, 적용 범위 등에 따라 손바닥만한 제품부터 소형 냉장고만한 제품까지 크기도 다양합니다. 물론 설치와 설정 작업은 네트워크 전문가가 아니면 처리하기가 매우 어렵습니다.

게이트웨이는 또한 라우터와 동일한 개념으로 이해할 수 있습니다. 라우터는 네트워크 장비의 일종으로,패킷을 다른 네트워크 보내주는 역할을 합니다. 이와 함께 최적의 네트워크 경로를 찾아주는 역할도 함께 수행합니다. 이렇듯 라우터도 이기종 네트워크를 연결한다는 부분에서 게이트웨이와 동일합니다. 다만 게이트웨이는 라우터보다 포괄적인 개념입니다.

우리는 컴퓨터 사용 환경에서 게이트웨이를 늘 사용하고 있습니다. 가깝게는 인터넷 유무선 공유기가 우리가 만나는 첫 번째 게이트웨이입니다. 공유기는 사용자 컴퓨터의 네트워크와 인터넷을 연결하여 사용자가 웹 사이트에 접근할 수 있도록 관문을 열어 줍니다. 사용자가 속해 있는 로컬 네트워크의 통신 프로토콜과 인터넷의 통신 프로토콜이 다르기 때문입니다. 참고로 공유기는 게이트웨이의 역할과 라우터의 역할, 방화벽 역할 등을 동시에 제공하는 종합 네트워크 장비입니다.

한편 자신의 컴퓨터에서 목적지 네트워크까지 도달하기까지 여러 개의 게이트웨이를 거칠 수 있습니다. 고속도로를 갈아탈 때마다 톨게이트를 지나야 하는 것과 다름 없습니다. 또한 톨게이트를 지날 때마다 통행료가 부가되듯, 게이트웨이를 거칠 때마다 네트워크 부하도 증가하여 전송 속도가 느려질 수 있습니다. 

인터넷을 위한 필수 조건

해당 컴퓨터가 속해 있는 로컬 네트워크 구역 내에서는 IP 주소와 서브넷마스크만 있어도 주변 컴퓨터와 통신이 가능합니다. 다른 네트워크 구역으로 나갈 필요가 없기 때문입니다. 하지만 인터넷 등의 이기종 네트워크로 나가기 위해서는 게이트웨이(라우터 등)가 있어야 하고, IP 주소, 서브넷 마스크와 함께 게이트웨이 주소까지 정확하게 설정해야 합니다.

컴퓨터가 서로 통신하기 위해서는 모든 컴퓨터마다 유일한 IP 주소를 할당해야 하듯, 게이트웨이에도 중복되지 않는 IP 주소가 필요합니다. 이 IP 주소를 토대로 각 컴퓨터가 다른 네트워크와 연결됩니다. 일반적으로 게이트웨이의 IP 주소는 해당 네트워크 내 컴퓨터에 할당된 IP 주소 중 끝자리만 다른 형태입니다. 보통 1을 지정합니다. 이를 테면 컴퓨터 IP 주소가 123.123.123.123이라면, 게이트웨이 주소는 123.123.123.1이 됩니다. 물론 게이트웨이 IP 주소 설정이 잘못되면 외부 네트워크(인터넷) 연결이 불가능합니다.

'공부 > Network' 카테고리의 다른 글

Gateway란?  (0) 2016.11.28
방화벽이란?  (0) 2016.11.26
프록시란?  (0) 2016.11.26
스위치, 라우터, 허브 차이점  (0) 2016.11.26
OSI 7계층  (2) 2016.11.26

방화벽이란?

방화벽이란 외부 사용자(WAN)들이 내부 네트워크(LAN)에 접근하지 못하도록 하는 일종의 내부 네트워크 방어도구입니다. 다른 소프트웨어적인 프로그램 도구와는 달리 방화벽이라함은 독립된 시스템이나 전용 하드웨어등을 뜻합니다. 연결요청에 대해서 승인된 호스트에 한하여 처리하는 간단한 인증에서부터 패킷필터링 및 분석, 프로토콜 내 특정 공격서명(attack signature)을 막는기술, 사용자 연결의 인증과 암호화 단계까지 다양하게 존재합니다.

공격서명(attack signature)이란 해커들이 해킹을 전제로 사용되는 공통되고 비슷한 패턴을 의미합니다. 예를 들어서 80포트를 사용해 텔넷으로 명령을 내린다던지 ftp로 이상한 패킷을 보내는 것과 같은 행위를 말합니다.

방화벽의 종류

패킷 필터링

가장 기초적인 방화벽은 "라우터"에서 행하여지는 패킷 필터링이라 할 수 있습니다. 발신지 IP / protocol / port / 패킷 등을 선별적으로 인증해 접속요청에 대하여 판단 하는 것을 의미합니다. 향상된 라우터들은 스푸핑과 DoS공격에 방어하도록 발전했으며 아예 scanning조차 불가하도록 발전된 것도 있습니다

라우터를 방화벽으로 사용 시 장점

라우터는 방화벽을 목적으로 하는 장치는 아니고 내부 네트워크를 인터넷에 연결하기 위한 장치입니다.  라우터를 방화벽으로 사용한다면, 별도의 방화벽을 준비하지 않고도 라우터만으로 내부 네트워크를 연결하면서 방화벽 기능까지할 수 있다는 장점이 생깁니다. 방화벽 장비를 도입하지 않기 때문에 비용이 저렴해 질 수 있습니다.

라우터를 방화벽으로 사용 시 단점

라우터에 엄격한 필터링 및 지나친 방화기술을 쓴다면 라우터의 성능이 급격히 낮아질수 있습니다.

어플리케이션-프록시 방화벽

어플리케이션 게이트웨이를 통한 방법입니다. 프록시(proxy) 서버란 사설 통신망의 사용자가 공중 통신망을 간접적으로 엑세스할 수 있도록 마련된 네트워크 서버입니다. 사설 통신 사용자가 대리 서버를 통해 공적인 네트워크 정보를 액세스 하거나 저장하여 공중 통신망에 대한 액세스를 제한할 수 있습니다. 프록시 서버를 사용하는 경우는 두 가지가 있습니다. 하나는 사내의 네트워크와 인터넷 간의 액세스 제어를 행하는 경우인데 프록시 서버를 사용하면 인터넷에서 회사로의 액세스는 금지시키고, 사내에서 허용된 사용자만이 인터넷 특정의 서비스를 사용 하도록 설정할 수 있습니다. 액세스 제어에 사용하는 프록시 서버는 대개 방화벽으로 머신 상에서 동작시킵니다. 또 하나는 사내 네트워크와 인터넷간의 트래픽을 경감하고 싶을때 사용하는 캐쉬 기능입니다. 예를 들어 사용자가 있는 www 페이지를 액세스 하면 그 내용을 프록시 서버는 일정기간 기억해 둡니다. 이런 방법으로 인터넷 액세스의 빈도를 줄일 수 있습니다. 이러한 방법은 소프트웨어적으로 다양한 방화벽 기술을 펼칠수 있음이 확인됩니다.

웹방화벽이란?

웹방화벽(Web Application Firewall, WAF) 은, 일반적인 네트워크 방화벽 (Firewall)과는 달리 웹 애플리케이션 보안에 특화되어 개발된 솔루션입니다. 웹방화벽의 기본 역할은 그 이름에서도 알 수 있듯, SQL Injection, Cross-Site Scripting(XSS)등과 같은 웹 공격을 탐지하고 차단하는 것입니다. 웹방화벽은 직접적인 웹 공격 대응 이 외에도, 정보유출방지솔루션, 부정로그인방지솔루션, 웹사이트위변조방지솔루션 등으로 활용이 가능합니다.

'공부 > Network' 카테고리의 다른 글

Gateway란?  (0) 2016.11.28
방화벽이란?  (0) 2016.11.26
프록시란?  (0) 2016.11.26
스위치, 라우터, 허브 차이점  (0) 2016.11.26
OSI 7계층  (2) 2016.11.26

프록시란?

프록시(Proxy)란 '대리'라는 의미로,네트워크 기술에서는 프로토콜에 있어서 대리 응답 등에서 친숙한 개념입니다. 보안 분야에서는 주로 보안상의 이유로 직접 통신할 수 없는 두 점 사이에서 통신을 할 경우 그 상이에 있어서 중계기로서 대리로 통신을 수행하는 기능을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부릅니다.

프록시 서버의 특징

프록시 서버는 클라이언트 입장과 서버의 입장에서 볼 때 서로 상반되는 역할을 하는 것처럼 인식됩니다. 다시 말해서, 클라이언트 호스트에서의 입장에서 본다면 프록시 서버는 마치 원격 서버처럼 동작하는 것이고, 원격 서버에서의 입장에서 본다면 마치 클라이언트처럼 동작한다는 것입니다.

프록시 서버는 단순히 보안상의 이유만으로 설치하는 것은 아닙니다. 물론 보안상의 목적으로 설치하는 경우가 많겠지만, 그렇다고 그렇게 단순하게 볼 수만은 없을 것입니다. 우선 프록시 서버는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장해 둡니다. 이렇게 캐시를 해 두고 난 후에, 캐시 안에 있는 정보를 요구하는 요청에 대해서는 원격 서버에 접속하여 데이터를 가져올 필요가 없게 됨으로써 전송 시간을 절약할 수 있게 됨과 동시에 불필요하게 외부와의 연결을 하지 않아도 된다는 장점을 갖게 됩니다. 또한 외부와의 트래픽을 줄이게 됨으로써 네트워크 병목 현상을 방지하는 효과도 얻을 수 있게 됩니다.

프록시 서버의 종류

서버의 위치에 따라 분류하면 크게 두 가지로 나눌 수 있습니다.

Forward 프록시

이것은 프록시 서버를 '클라이언트 호스트들과 접근하고자 하는 원격 리소스의 사이'에 위치시키는 것입니다.이 프록시 서버는 원격 서버로부터 요청된 리소스를 가져와서 요청한 사용자에게 돌려주는 역할을 수행하며, 만일 캐시에 데이터가 남아 있다면 다음 요청시 캐시된 데이터로부터 제공해 주게 됩니다. 이 서버는 전형적으로 로컬 디스크에 데이터를 저장하며, 클라이언트 호스트들은 사용중인 웹 브라우저를 이용하여 프록시 서버 사용 설정을 해야 하므로 프록시 서버를 사용하고 있다는 것을 인식할 수 있을 것입니다. 이 방식은 대역폭 사용을 감소시킬 수 있다는 것과 접근 정책 구현에 있어 다루기 쉬우면서도 비용이 저렴하다는 장점을 갖습니다. 또한 사용자의 정해진 사이트만 연결할수 있는 등 웹 사용 환경을 제한할 수 있으므로 기업 환경등에서 많이 사용합니다. 

Reverse 프록시

이것은 프록시 서버를 '인터넷 리소스 또는 인트라넷 리소스 앞'에 위치시키는 방식입니다. 이 방식을 사용하면 클라이언트들이 프록시 서버에 연결되었다는 것을 알지 못하게 되며, 마치 최종 사용자가 요청 리소스에 직접 접근하는 것과 같이 느끼게 됩니다. 내부 서버가 직접 서비스를 제공해도 되지만 이렇게 구성하는 이유는 보안 때문입니다. 보통 기업의 네트워크 환경은 DMZ 라고 하는 내부 네트워크와 외부 네트워크 사이에 위치하는 구간이 존재하며 이 구간에는 메일 서버, 웹 서버, FTP 서버등 외부 서비스를 제공하는 서버가 위치하게 됩니다. example.com 사는 서비스를 자바로 구현해서 WAS 를 DMZ 에 놓고 서비스해도 되지만 WAS 는 보통 DB 서버와 연결되므로 WAS 가 최전방에 있으면 WAS 가 털릴 경우 DB 서버까지 같이 털리는 심각한 문제가 발생할 수 있습니다. 이 때문에 리버스 프록시 서버를 두고 실제 서비스 서버는 내부망에 위치시키고 프록시 서버만 내부에 있는 서비스 서버와 통신해서 결과를 클라이언트에게 제공하는 방식으로 서비스를 하게 됩니다. 특히 리눅스 환경에서 리버스 프록시로 아파치 웹 서버를 사용한다면 SELinux 를 켜 놓으면 SELinux 의 기본 정책이 웹 서버는 톰캣의 8080, 8009 포트만 접근 할 수 있으므로 아파치 웹 서버가 해킹당해도 웹 서버 권한으로는 내부망으로 연결이 불가합니다. 또한 리버스 프록시 방식은 각 요청에 대한 데이터가 캐시되기 때문에 프록시 서버는 실제 서버들을 위한 부하조절 기능을 가질 수 있습니다. 

'공부 > Network' 카테고리의 다른 글

Gateway란?  (0) 2016.11.28
방화벽이란?  (0) 2016.11.26
프록시란?  (0) 2016.11.26
스위치, 라우터, 허브 차이점  (0) 2016.11.26
OSI 7계층  (2) 2016.11.26

+ Recent posts