#softwareengineering > [!abstract] Introduction > 소프트웨어 제품의 품질은 그것을 개발하고 유지보수하는 프로세스의 품질에 의해 결정된다. 이번 글에서는 소프트웨어 프로세스가 무엇이고 왜 중요한지 알아본다. # Software Process 카네기 멜론 대학의 소프트웨어 엔지니어링 연구소*Software Engineering Institute, SEI*에서 소프트웨어 엔지니어링 프로그램을 창안한 왓츠 험프리*Watts Humphrey*는 다음과 같은 말을 남겼다. > [!quote] > “The quality of a software product is largely determined by the quality of the process used to develop and maintain it” 소프트웨어 제품의 품질은 그것을 개발하고 유지보수하는 과정이 크게 좌우한다는 것인데, 여기서 등장하는 것이 바로 소프트웨어 프로세스다. > [!info] Process > a sequence of steps performed for a given purpose \[IEEE\] 프로세스는 ==특정한 목적을 달성하기 위한 일련의 작업==으로 정의된다. 소프트웨어 프로세스는 하드웨어의 제조공정 관리에서 그 개념을 가져온 것으로, ==소프트웨어와 관련 산출물(설계서, 테스트케이스 등)을 개발하고 유지보수하는 활동 및 방법==으로 정의된다. > [!info] Software Process > a set of activities, methods, practices, and transformation that people employ to develop and maintain software and the associated products (e.g., design documents, test cases etc.) \[SEI\] 이제 소프트웨어 프로세스가 무엇을 의미하는지 얼추 이해했을 것이다. 그런데 왜 소프트웨어 프로세스를 강조한 것일까? # 왜 프로세스인가? ## Quality, Delivery, Cost IT의 발전과 함께 소프트웨어가 대부분의 기업에서 수익구조의 중추에 자리 잡기 시작했다. 그러면서 소프트웨어 역량이 기업의 주요 관심사로 떠오르게 되었는데, 그 핵심이 바로 품질*Quality*, 전달*Delivery*, 비용*Cost*이다. 시시각각 변하는 고객의 요구사항과 시장의 변화에 맞추기 위해 기업들은 설계를 시작하는 순간부터 출시까지 걸리는 시간을 줄이고, 출시 이후에도 짧은 주기로 이루어지는 지속적인 배포를 추구하게 되었다. 그래서 기업들의 관심사는 이처럼 빠른 개발 속도와 좋은 품질을 유지하면서 비용을 최대한 절감하는 방향으로 기울게 되었고, 이를 위해 무엇을 바꿔야 할지 고민하게 되었다. ## 바꿀 수 있는 것은 프로세스 뿐이다 지속적인 배포를 추구하면서, 소프트웨어 제품을 짧은 주기로 자주 배포하는 것이 중요해졌다. 배포의 빈도와 속도를 높이려면 그에 맞는 기술과 업무 절차가 필요하고, 무엇보다 사람들이 그에 맞게 일해야 한다. 그래서 제품의 품질, 전달, 비용을 결정하는 3대 요소는 사람*People*, 프로세스*Process*, 기술*Technology*이다. 그런데 이 중에서 사람과 기술은 주어지는 것이다. 아무리 LLM을 써도 결국 그렇게 만들어진 코드는 사람이 검토해야 하고, 좋은 사람만 구할 수도 없으며, 필요한 기술이 하늘에서 뚝 떨어지는 것도 아니다. 하지만 프로세스는 만들 수 있다. 사람도 기술도 통제할 수 없지만, 사람들이 기술을 사용해 일하는 방식은 통제할 수 있다. 좋은 프로세스는 일을 수행하는 사람들의 역량을 강화시키고, 적절한 기술을 선택할 수 있게 하고, 사람, 도구, 절차를 하나로 통합한다. 소프트웨어는 날이 갈수록 복잡해지면서 혼자서는 통제할 수 없는 복잡도를 가지게 되었고, 지속적인 개발과 배포가 이루어져야 하는 상황 속에서 프로세스를 필요로 하게 되었다. 그래서 제품 뿐만이 아니라 소프트웨어 프로세스에 대한 평가가 중시되기 시작했고, 제품의 품질은 소프트웨어 프로세스의 품질로부터 나온다는 생각이 점차 정설로 자리잡기 시작했다. # 프로세스 표준 모델 이러한 생각은 프로세스 표준 모델의 탄생으로 이어졌다. 업무 프로세스의 표준 모델은 아래와 같은 역사를 지니고 있다. 기존에는 모든 산업에서 통용 가능한 범용적인 모델이 있었지만, 점차 각 분야에 특화된 모델들이 탄생하기 시작해 지금까지 이어지고 있다. ![[ProcessModelHistory.png]] 이렇게 각 업무에 맞게 표준화된 프로세스 모델을 사용한다는 것은 기성복을 입는 것과 같다. 프로세스 모델이 없던 시절에는 다른 회사의 성공적인 사례를 벤치마킹했는데, 그 사례는 맞춤정장 같은 것이라서 그대로 적용하기에는 여러가지 곤란한 구석이 있기 마련이다. 프로세스는 실제로 제품을 만들기 위한 기술적 기반과 프로세스를 현장에 적용시키기 위해 필요한 관리적 기반을 통해 엔지니어링에 적용된다. # 마치며 프로세스 모델은 프로젝트 및 조작차원 프로세스 개선의 가이드가 된다. 조직에서 프로세스 개선이 가지는 의미에 대한 비전을 공유할 수 있고, 소프트웨어 프로세스에 대한 공통의 언어가 된다. 또한, 프로세스를 개선할 때 그 목표와 우선순위를 결정하는 데 도움을 주는 가이드가 된다. 그러나 프로세스 모델은 만병통치약이 아니다. 모델은 그저 실제 세계를 단순화한 것일 뿐이며, 프로세스 모델은 단지 도구이므로 프로세스 모델을 적용하고자 한다면 그 목표에 부합하는 테일러링*Tailoring*, 즉 구체적 현실에 맞게 프로세스 모델을 다듬는 과정이 있어야 하며, 그에 따라 사업 목표에 부합하는 해석이 있어야 한다.