본문 바로가기

Sorry Architecture

Continuous Integration

지속적 통합(Continuous Integration)은 짧은 주기로 소프트웨어(Software)를 개발하고, 사용자에게 빠르게 전달한 다음, 개선사항을 제안받아 다음 번 개발에 반영함으로써 지속적이고 주기적으로 소프트웨어를 개선해 나가는 개발 방법을 말한다. 이렇게 하면 사용자의 요구사항이 변경되더라도 쉽고 유연하게 맞춰나갈 수 있다. 보통 소프트웨어 개발은 설계, 개발, 검증, 배포의 과정으로 진행하는데, 전통적으로 전 과정에서 각 단계는 분리되어 있었고 뒤로 되돌아 가기 어려웠다. 그래서 보다 꼼꼼하게 설계하고 많은 시간을 설계 문서 작성에 공을 들였다. 일부의 경우 이러한 방법이 잘 맞았다. 요구사항의 변화 폭이 크지 않은 경우엔 충분히 설계를 검토하고 문서를 꼼꼼하게 잘 만들수 있었고, 검증도 가능했다.

 

그러나 인터넷이 발달하고 다양한 어플리케이션(Application)들이 쏟아져 나올 때, 이 어플리케이션들은 소비자의 성향이나 주변 상황이 예측하기 어려웠고, 유행은 쉽게 바뀌었다. 그래서 기존의 엔터프라이즈(Enterprise) 소프트웨어 개발에 사용했던 방식으로는 개발 상황을 투명하고 정확하게 파악하기 어려웠다. 설계도면과 실제구현에 불일치가 나타나는 경우가 많았고, 복잡한 구성으로인해 한 쪽에서 고치면 전혀 생각치 못한 곳에서 부작용이 발생하는 경우가 자주 생겼다. 그래서, 시간이 한 참 지나고 나서 오류를 발견했다면 복잡하게 꼬인 소스 코드를 들여다 보아야했고 고치는 것도 쉬운 일이 아니었다. 사소한 것을 한 가지 고쳐도 모든 기능을 점검해야 하는 문제가 있었다. 이건 너무 어려운 일이었는데, 잔병은 미리미리 병원을 찾아서 조금씩 치료할 수 있지만, 큰 병으로 발전한 뒤에는 손쓰기 어렵게 되는 것과 같았다.
 
그래서 전통적인 개발방법론을 개선하려는 움직임이 생겼다. 요구사항을 가능한 짧은 기간 내에 확실하게 검증할 수 있는 (명확한) 형태로 서술하고, 요구사항에 정의한 것만 구현하는 방식을 제안하였다. 그리고 그 과정을 반복하면서 필요한 기능을 덧붙이는 개발방법론이 나타났다. 이러한 방법론 (철학)이 고객을 가치의 최우선권에 둔 애자일 소프트웨어개발(Agile Software Development) 철학[각주:1]이다. 애자일 방법의 현상은 여러 가지로 나타났지만, 공통적으로 나타난 것은 다음과 같다. 앞서 말한 것과 같이 요구사항을 작은 단위로 나누고 예측가능한 일정동안 진행한 후 다른 단위기능을 추가하거나 기존 기능을 개선해 나가는 모습이었다. 전통적인 소프트웨어 개발 모형을 충분히 작은 형상으로 축소하고 이를 반복적으로 수행해 가는 것이었다. 많은 사람들의 오해 중 한 가지는 폭포수 모형과 애자일이 상극이라는 것이다. 폭포수 모델은 나쁘고 애자일 착하다?는 것은 맞지 않다. 폭포수 모형, 나선형(Spiral) 모형, 그리고 애자일은 다른 도구이며 적합한 사용처가 다른 것이다. 사실 애자일의 모습을 잘 들여다보면 폭포수 모형이나 나선형 모형에서 강조하는 충분한 요구사항 분석과 체계회된 문서작성을 거부하지 않는다. 오히려 기존 모델들을 현 시대에 맞게 실용적으로 고쳐서 사용한다는 것이 적합 한 표현인 것 같다.

1/ 피드백(Feedback): 지속적 통합에서 가장 중요한 개념을 꼽으라고 한다면 피드백을 선택하고 싶다. 많은 사람들이 자동화(Automation), 매일 빌드(Nightly Build), 소스 코드 버전 관리(Source Control), 협업(Collaboration) 등 많은 단어들을 선택하겠지만, 가장 중요한 개념은 피드백이라고 생각한다. 이유는 현재 진행 중인 결과에 대해 즉각 적으로 반응을 살피고 그에 따라 점진적으로 변화되어 가는 것이 지속적 전달의 목표이기 때문이다. 다시말해서, 애자일을 이야기할 때 빠지지 않는 것이 고객(사용자)을 중심에 놓는 소프트웨어 개발방법이고 이를 실현하기 위한 구체적인 실천방안 중 꽤 설득력 있게 완성된 형태 (순환고리, Eco-system)가 지속적 전달이기 때문이다. 지속적 전달의 핵심은 간단하다. 개발하고 보여주고 듣고 다시 개발하고 보여주고 듣고를 계속 반복하는 것이다.
 
2/ 자동화(Automation): 피드백 다음으로 중요한 개념을 꼽으라면 자동화를 선택하고 싶다. 피드백을 들을 수 있는 창구와 이를 반영할 수 있는 절차가 있다면, 일단 지속적 전달을 해볼 수 있다고 생각한다. 하지만 모든 절차를 사람들이 개입해서 관리하게 된다면, 속도가 나지 않는다. 그래서 개발하고 보여주고 듣는 과정의 절차들을 최대한 자동화해서, 순환고리(Eco-system)의 효율성을 높여야 한다. 다시말해서, 지속적 통합은 피드백을 받는 것이 가장 핵심이고 이러한 과정의 생산성과 효율성을 높이기 위해서 자동화가 다음으로 중요하다. 특히, 고객의 목소리를 빠르게 듣고 바로 적응해서 점진적으로 대응해 나가겠다는 애자일에서 효율성은 꽤 중요한 요소이다.


 

'Sorry Architecture' 카테고리의 다른 글

Jikji Code  (0) 2019.06.08
Git  (0) 2019.06.08
Continuous Delivery  (0) 2019.06.06
About Pull Requests  (0) 2019.06.01
Chaos Engineering  (0) 2019.05.21