개발 방법론의 진화: 프로세스 측면
개발의 시조새: SAGE 계획, NASA 그리고 폭포수 모델(Waterfall Model)
우선, 개발의 시조새, SAGE 계획이나 NASA의 아폴로 계획을 보면 엄격한 폭포수 모델을 따랐다. 이 경우에는 상부의 계획에 맞게 위에서 아래로 차근차근 진행되어야 했기 때문에, 단계가 매우 뚜렷하고 엄격하다. 현재 인턴십을 하고 있는 회사인 메타빌드에서 추구하는 개발 방법론 역시 이와 유사하며, SI/SE 전반에 있어서 오래되었지만 무난한 이것이 널리 채택된다.
큰 틀에서 이 프로세스는 “분석->설계->구현->검증->배포->운영”을 따른다.
아래는 나사의 경우를 분석한다.
요구사항 정의 및 사양 확정
항공우주 분야의 미션은 실패를 염두에 두어서는 안 되는 작업이며, 단 하나의 비트 오류로도 우주선이 추락할 수 있다. 이 동작을 수행하기 위해 모든 동작은 FSW(Flight SoftWare; 비행 소프트웨어) 사양서에 기록되었다. 이 문서가 확정되기 전까지는 코딩을 시작할 수도, 시작해서도 안 된다.
알고리즘 설계 및 수학적 검증
모든 알고리즘을 설계 명세와 그림으로 일일이 손으로 그리며 호출 순위, 자원 사용 등을 수학적으로 무결할 때까지 검증한다. 단 하나의 사항이라도 수학적으로 정합성이 맞지 않으면 폭포수의 다음 단계로 넘어가지 못한다.
프로그래밍
모든 코드를 작성하고, 다중 검토를 통하여서 코드가 명세와 1:1로 일치하는지 검증한다. 모든 것이 검증되고 나면 코드는 천공 카드에 기록된다(현대에는 보통 메인 브랜치로의 머지일 것이다).
하드웨어 시뮬레이션 및 디버깅
작성된 코드는 고성능의 메인프레임 컴퓨터에서 단위 테스트, 그리고 우주 시뮬레이션에서의 소프트웨어 동작까지 시뮬레이션 후에 승인한다. 이 단계가 승인되고 나면 물리적 메모리에 기록하는 단계를 거쳤다.
메모리 제작
이 단계는 현대의 경우에는 C라면 ‘make -j12’, 자바라면 ‘mvn clean compile’로 끝날 일이다. 그러나 이 때는 전문가가 직접 코어 메모리에 정보를 직조해야 했으므로, 빌드에만 수 개월이 걸렸으며 물리적으로 직조된 바이너리는 수정이 불가했다.
엄격한 형상 관리와 최종 승인
한 번 제작된 메모리는 변경하지 못하기 때문에, 코드 변경을 CCB(Configuration Control Board) 위원회의 검토와 승인을 거친 후 최종 승인을 하여 우주선으로 배포되었다. 말 그대로 Deploy 아이콘 대신 우주선 한 대인 셈이다. 그런 만큼이나 모든 줄에 대해서 코드가 필요한 이유를 완벽하게 소명하는 것이 이 단계에서 요구되었다.
우선, 이 시기에는 PlantUML도 없고, 시스템은 우주에서도 돌아가야 한다는 제약을 따르는 임베디드 하드웨어 위에서 돌아가야 했음을 염두에 둬야 한다. 이 때는 FreeRTOS와 같은 예쁘고 쓰기 편한 시스템은 전혀 없었기 때문에, 오류 발생에 대한 감당을 OS 개발자만이 한다는 역할 분리가 모호했다.
이러한 상황을 위해서는 우선 순위에 따른 작업 비동기 처리, 시스템 콜이 CPU를 점유하는 시간(특히 싱글코어라면) 등이 극도로 중요했으며, 이 분야에서의 시조이자 세기의 천재 ‘마거릿 해밀턴’은 실시간 에러 탐지 및 프로세스 우선순위 재배열, 소프트웨어 엔지니어링이라는 학문의 창안 등의 기염을 토했다. 다시 돌아와, 마거릿 해밀턴의 소프트웨어 엔지니어링은 ‘소프트웨어는 단계적으로 명세를 설계하며 개발해야 한다’는 원칙을 충실하게 따르는 개념이다. 그러한 의미에서 ‘폭포수의 상류가 하류로 떨어지기 전에는’ 붕어를 살게 해서는 안 된다는 뜻이다.
마거릿 해밀턴이 소프트웨어 엔지니어링을 창안하게 된 동기를 엿볼 수 있는 어록이 하나 있다.
누군가 초심자로 조직에 들어왔을 때, 그들이 해왔던 일은 아무도 이해하지 못하거나 실행에 이를 수 없었던 프로그램을 그 사람에게 할당하는 것이었다. 내가 초심자였을 때도 그들은 나에게 프로그램을 주었다.
그것은 까다로운 프로그래밍을 해야 했고, 작성한 사람이 모든 의견을 그리스어와 라틴어로 적었다는 사실이 즐거움을 주었다. 그래서 나는 이 프로그램을 할당받고 실제로 작업을 하게 되었다. 심지어 라틴어와 그리스어로 된 답변을 출력하게 하였다. 나는 그것을 작동시킨 첫 번째 사람이었다.
마거릿 해밀턴과 같은 천재 역시 ‘아무도 이해하지 못하는 소프트웨어’에 대한 긴급 폭발물 처리반같이 쓰이던, 어떻게 보면 ‘박사님, 해 주세요’의 연속이었던 시대이다. 이 시대의 코드는 대개 어셈블리어고, 제대로 된 주석이 없는 경우도 많았던 것을 고려하면 마거릿 박사가 아니었다면 손을 못 댔을지도 모르는 노릇이다.
박사님, 저희는 어떻게 짜죠?
마거릿 해밀턴이 창시하거나 진일보시킨 분야 목록은 다음과 같다.
- 시스템 설계
- 소프트웨어 개발
- 엔터프라이즈 및 프로세스 모델링
- 개발 패러다임
- 공식 시스템 모델링 언어
- 시스템 모델링 및 개발을 위한 시스템 중심 객체
- 자동화 주기 환경
- 소프트웨어 신뢰성
- 소프트웨어 재사용 극대화 방법
- 도메인 분석
- 내장 언어 속성에 의한 정확성
- 강력한 시스템을 위한 개방형 아키텍처 기술
- 전체 주기 자동화
- 품질 보증
- 소프트웨어/하드웨어 통합
- 오류 감지 및 복구 기술
- HCI(Human-Computer Interaction)
- 운영 체제
- 종단 간 시험 기술
- 주기 관리 기술
괜히 박사가 아니라지만 너무 방대하고 어마어마해서, 우리가 모든 분야를 다 공부하기에는 어려울 것이다.
우선 개발 방법론이 왜 이렇게까지 엄격하였으며, 왜 지금까지 이어져 내려오는는지 역사적인 흐름과 미래에 대해서 아폴로 11호 착륙이라는 사건을 두고 알아 보도록 하자.
일촉즉발이지만 착륙! 엔지니어링 프로세스의 승리
우선 위키피디아 발췌 텍스트를 보자.
아폴로 11호 임무의 결정적 순간 중 하나는, 아폴로 가이던스 컴퓨터가 기내 비행 소프트웨어와 함께 달 착륙의 중단을 막은 것이다. 달착륙선이 달 표면에 도달하기 3분 전, 몇 대의 컴퓨터가 경보를 울렸다. 착륙선의 랑데부 레이다에 부정확한 위상 전원이 공급되자 컴퓨터가 과부하를 일으켜 일시 중단된 것이었다. 프로그램 경보는 “실행 오버플로”를 표시했는데, 이는 길잡이 컴퓨터가 모든 작업을 실시간으로 완료할 수 없고 그 중 일부를 연기해야 함을 의미했다. J. 할콤 레이닝이 설계한 비동기 실행은 작업 우선 순위를 매겨 컴퓨터가 늘어난 요구에 잘 대처할 수 있도록 해주었다. 해밀턴의 우선 순위 경보 표시는 우주비행사의 정상적인 화면 표시를 중단시키고 “우주비행사에게 실행/비실행 결정권(착륙 또는 착륙하지 않기)을 부여”하여 비상 사태를 경고하였다. 임무를 통제하는 NASA의 컴퓨터 공학자 잭 가먼은 우주비행사들에게 우선 순위 표시로 제시된 오류의 의미를 인지하여 “실행, 실행!”을 외쳤고, 그들은 계속해서 실행했다. 해밀턴을 NASA 스페이스 액트 어워드 후보로 지명한 선임 기술자 폴 커토 박사는 해밀턴의 작업을 “극단적으로 신뢰할 수 있는 소프트웨어 설계의 토대”로 칭했다.
문제 상황은 비교적 명확하다. 컴퓨터 다운->실행 슬롯 부족->실행 가능한 작업 공간 부족
이 상황에 대한 엔지니어링적인 지점은 ‘예외 처리 및 권한 부여’에 있다. 앞서서 나사의 연구자들은 수학적으로 모든 상황이 무결함을 예측했다고 하지만, J. 할콤 레이닝의 비동기 처리, 그리고 마거릿 해밀턴의 촘촘한 경보 시스템 역시 그 범위의 일부였다. 비행사들의 목숨이 달린 긴박한 상황임에도, 모든 코드 한 줄마다 꼭 필요한 이유를 일일이 검토함을 통해 ‘문제가 생길지도 모르는 부분’을 다 방어해 둔 덕분에 참사가 아닌 ‘착륙 성공’으로 역사를 기록하였다.
몇 명의 개발자들에게 모든 권한을 다 쥐어 주었다면 아무리 뛰어난 연구자인 마거릿 해밀턴이라도 모든 분기와 연산들에 대하여 전적으로 방어했을지는 알 수 없는 노릇이다. 이러한 까닭으로 마거릿 박사는 엄격한 소프트웨어 개발 프로세스를 정의하고 매 순간을 검토하려고 한 것이다.
현대의 소프트웨어는 어느 정도 실패가 용인이 된다. 그러한 까닭으로 많은 벤처 기업들은 폭포수 모델에서 서서히 탈피해 보다 개방적인 협업 모델을 따라간다. 결국 따지고 보면 시대의 요구에 따라서 변화하는 것이긴 한데, 폭포수 모델의 장점인 무결성에 대한 집착은 조직의 입장에선 ‘반짝이는 순간도 없지만 깨지는 순간도 없는’ 적당한 품질 관리로 유리하다. 그래서 많은 경우 조직에 속하게 되면 심하면 몇 년 이상을 커리어를 쌓을 기회를 주지 않고 유보하는 것이 아닌가 생각한다.
결론
결론적으로 폭포수 모델은 무결성을 지키기에 가장 안정적인, 그리고 V모델과 더불어 아주 보수적이고 안정형의 모델이다. 개인의 평가나 판단 여부와는 상관없이 상부의 권위에 맞게 해명하는 프로세스가 중시되는 설계는 급격한 변동이 적다는 것이 큰 장점이다.
그러나 이러한 모델은 상부에 ‘설득을 시도할 수 있을 때’ 정상적으로 기인하지, 상부의 압박에 수동적으로 따르면 사실상 인간을 잡아두고 하는 바이브 코딩이 될 수 있기 때문에, 이러한 점에서 프로세스의 부작용 역시 알아는 두는 점이 좋다고 생각한다. 김성모 만화에서 나오는 코미디 대사 중 하나가, ‘IQ 100인 너와 내가 머리를 맞대면 IQ 200’이라는 것이 있다. 코미디성 대사라고는 하지만 어느 정도 화백의 성찰이 담긴 대사라고 생각한다. 그러한 의미에서 소위 ‘위원회’, 현대에는 ‘임원진’ 몇 명의 지능에만 의존하는 것은 자칫 위험할 수 있다고 생각한다.
예를 들면, 이론적으로 감당하기 힘든 현장에서의 치명적인 문제점이 있다면 그것은 위원회, 혹은 임원들은 절대로 알 수가 없다. 이러한 것에 대한 적절한 보고가 이루어지기 위해서는 아래에서 위로 차근차근 ‘역전파’될 필요성이 있다. 마치 머신 러닝 시 기본적인 학습은 순전파이나, 보다 좋은 성능을 확보하기 위해서 역전파가 불가피한 것과 같은 맥락이다.
모델의 목적은 기본적으로 ‘요구에 맞는 더 똑똑한 엔지니어링’이다. 이러한 엔지니어링을 통해서 잘 합을 맞춘다면 IQ 수천의 조직도 꿈만은 아닐 것이다.
다음 목차
다음 목차는 또 다른 ‘박사님’ 모델에 해당하는, V모델에 대해서 다룰 것이다. 이 V모델을 여러모로 집착적일 정도로 발전시키고 선호한 조직은, 우리에게는 꽤 위협적이었던 국가로 익숙한 ‘소련’일 것이다.
정치적인 선악 여부를 떠나서, 엔지니어링 방법론에 있어서는 20세기 IT의 세 축, 미국, 일본, 소련을 참고하지 않을 수 없다. 우선은 보수적 모델을 세 나라에 대해서, 유사한 순서대로 학습할 것이기 때문에 ‘보수적 모델 시리즈’ 셋은 반드시 등장한다.