엔디안이란?

엔디안(Endian)은 컴퓨터의 메모리와 같은 1차원의 공간에 여러 개의 연속된 대상을 배열하는 방법을 뜻하며, 바이트를 배열하는 방법을 특히 바이트 순서(Byte order)라 합니다. 엔디안은 보통 큰 단위가 앞에 나오는 빅 엔디안(Big-endian)과 작은 단위가 앞에 나오는 리틀 엔디안(Little-endian)으로 나눌 수 있으며, 두 경우에 속하지 않거나 둘을 모두 지원하는 것을 미들 엔디안(Middle-endian)이라 부르기도 합니다.


사람이 숫자를 쓰는 방법과 같이 큰 단위의 바이트가 앞에 오는 방식이 빅 엔디안입니다.


빅 엔디안리틀 엔디안
0x123412 3434 12
0x1a3ecd1a 3e cdcd 3e 1a

16진수는 2개가 1바이트이므로 묶어서 계산합니다.

장단점

빅 엔디안은 소프트웨어의 디버그를 편하게 해 주는 경향이 있습니다. 사람이 숫자를 읽고 쓰는 방법과 같기 때문입니다.

반대로 리틀 엔디언은 메모리에 저장된 값의 하위 바이트들만 사용할 때 별도의 계산이 필요 없다는 장점이 있습니다. 예를 들어, 32비트 숫자인 0x2A는 리틀 엔디언으로 표현하면 2A 00 00 00이 되는데, 이 표현에서 앞의 두 바이트 또는 한 바이트만 떼어 내면 하위 16비트 또는 8비트를 바로 얻을 수 있습니다.

반면 32비트 빅 엔디언 환경에서는 하위 16비트나 8비트 값을 얻기 위해서는 변수 주소에 2바이트 또는 3바이트를 더해야 합니다. 


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

엔디안(Endian)이란?  (0) 2018.07.15
이진법, 16진법, 비트와바이트, 인코딩  (0) 2018.07.12
마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13

정말정말 간단한건데 사용안할 줄 알고 대충알고 넘어갔다가 이번에 큰코를 다쳤.............

16진법만 다시 정리할까 했는데 전체적인 내용을 다시 까먹지 않기 위해 비트와 관련된 알고 있는 내용까지 전부 정리합니다.

이진법 (binary)

컴퓨터는 이진법으로 이해를 합니다. 우리가 사용하는 수의 표현방법은 십진법입니다. 이진법에는 0 또는 1 만 존재합니다. 알다시피 십진법은 0~9까지 존재합니다.

십진법 ↔ 이진법

십진법에서 1은 이진법에서도 1입니다. 십진법에서 3은 이진법으로 표현하자면 11이 됩니다. 이를 다시 십진법으로 변경하자면 2^1 + 2^0 = 3 으로 성립이 됩니다.  자리 수가 n개인 이진법를 십진법로 계산하는 공식은 2^n-1 + 2^n-2 + ... + 2^1 + 2^0 이 됩니다. 마지막으로 5를 이진법로 변경하면 101이고 이를 다시 공식에 대입하면 5가되는 것을 알 수 있습니다. 아래 예시 표를보고 공식에 대입해보면 쉽게 이해가 됩니다.

십진법이진법
00
11
311
5101
101010


시간이 없을 땐 https://ko.calcuworld.com/%EC%88%98%ED%95%99/2%EC%A7%84%EB%B2%95-%EA%B3%84%EC%82%B0%EA%B8%B0/ 를 사용하면 깔끔하게 변환이 됩니다.

비트와 바이트

위에서 이진법을 설명한 이유는 비트 때문입니다. 

비트는 0, 1로 이루어져 있습니다. 십진법 5를 표현하려면 자리수가 3개이므로 3비트가 필요합니다. 마찬가지로 10을 표현하려면 4비트가 필요하단 뜻입니다. 


위 이진법을 알고 있다면 다음의 비트가 몇개의 수를 표현하고 있는지 읽을 수 있습니다.

0100000101110000


끊어 읽는 규칙이 없으면 위 비트는 많은 방식으로 해석될 수 있습니다. 컴퓨터는 8비트를 데이터의 크기 기본단위로 사용하여 8비트씩 끊어 읽습니다. 8비트인 이유는 초창기 알파벳과 여러 특수문자를 표현하는 데 필요한 최소한의 크기로 채택이 되었기 때문입니다.

이진법0100000101110000
십진법65122


8비트는 1바이트와 같은 개념입니다. 

1바이트는 8비트이며 표현할 수 있는 수는 2^8 = 256가지 입니다.

2바이트는 16비트와 같은개념이고 표현할 수 있는 2^16 입니다.

16진법

십진법이진법16진법
00000 000000
10000 000101
30000 001103
50000 010105
100000 10100A
150000 11110F
170001 000111


위 표처럼 a,b,c,d,e,f 를 합쳐 16가지의 문자를 표현할 수 있습니다. 16진법은 이진법을 보다 쉽게 축약하여 보여줄 수 있습니다.

아래 문자열을 계산하는 예를 확인하면 이진법보단 16진법이 좀 더 보기 간편한 것을 알 수 있습니다.

APPLE
이진법01000001
01110000
01110000
01101100
01000101
16진법41
70
70
6C
65
십진법65
112
112
108
101


코딩을 하다보면 종종 16진법으로 결과가 내려오는 경우가 있는데 (SHA256 결과) 만약 64자의 길이를 가지고 있다면 이는 32bytes 입니다. 위 표에서 보는 것과 같이 16진법은 2개당 1바이트를 사용합니다. 

기타

십진법에서 0.01234 라는 값에서 소수점을 우측으로 옮기고 싶다면 10^n을 곱하면 됩니다. 예) 0.01234 * 10 = 0.1234,  0.01234 * 10^2 = 1.234, 

16진법에서 0.001f24 라는 값에서 소수점을 우측으로 옮기고 싶다면 16^n을 곱하면 됩니다. 예) 0.001f24 * 16^ = 0.01f24,  0.001f24 * 16^2 = 0.1f24

위 16진법에서 주의할 점은 0.001f24에서 지수자리인 0은 00이 생략되었다고 보는 것이 나중에 편합니다.

[00].[00][1f][24] 이와같이 2자리씩 끊어 존재한다고 인식하는게 편합니다.

인코딩

인코딩은 간단하게 설명합니다.

ANSI

미국에서 표준을 지정. 코드표를 이야기 할 경우엔 ANSI에서 제정한 ASCII와 동일

ASCII

아스키코드라 읽으며 1바이트로 문자를 표현.

한글은 표현할 수 없음.

EUC-KR

ANSI의 한국확장판. 영문을 포함한 ANSI 코드 부분은 1바이트, 한글 등의 문자는 2바이트. 일부 한글이나 아랍어 등을 표현 못함

유니코드

unicode. 세계에 존재하는 모든 문자를 표현하기 위해 제정된 표준 코드 표. 하나의 문자는 유일하게 하나의 수와 짝지어짐.

유니코드로 저장된 문서는 맨 앞에 (BOM)값이 존재할 수 있음. 이는 문서가 어떠한 엔디안을 사용해서 인코딩 되었는지 알려주기 위함. 혼란이 없는 경우엔 생략되기도 함.

UTF-16

16비트 즉 2바이트씩 끊어서 표현. 희귀한 일부 문자들을 제외한 대부분의 문자는 하나 글자당 2바이트로 표현될 수 있음. 2바이트로 표현되지 않는 문자는 2바이트가 더해져 4바이트로 표현.

UTF-8

8비트 즉 1바이트씩 끊어서 표현. ASCII는 1바이트, 유럽문자는 2바이트, 아시아문자는 3바이트로 표현. 파일의 용량절약과 ASCII와의 호환성 향상 이점이 존재.

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

엔디안(Endian)이란?  (0) 2018.07.15
이진법, 16진법, 비트와바이트, 인코딩  (0) 2018.07.12
마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13

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

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

엔디안(Endian)이란?  (0) 2018.07.15
이진법, 16진법, 비트와바이트, 인코딩  (0) 2018.07.12
마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13

칸반이란?

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

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

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

칸반 간략 설명

칸반 장점

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

품질에 대한 조직적 목표

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

개선 VS 회고

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

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

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

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

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


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

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

이진법, 16진법, 비트와바이트, 인코딩  (0) 2018.07.12
마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (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

+ Recent posts