Part1.md

1부. 소프트웨어 엔지니어링이란 무엇인가

1장. 소프트웨어 공학의 정의와 역사

• 공학(Engineering) 이란 인간의 실용적 문제를 과학적 지식으로 해결하는 것을 의미한다. 즉, 과학의 원리를 현실 문제에 적용하여 효율적이고 효과적인 해결책을 만들어내는 실천적 학문이다.
• 소프트웨어 공학(Software Engineering) 은 소프트웨어 분야에 이러한 공학 개념을 적용한 것으로, 실증적이고 과학적인 접근법을 통해 경제적이고 실용적인 소프트웨어 문제 해결 방법을 찾는 활동을 말한다. 다시 말해, “최대한 적은 비용과 노력으로 높은 품질의 소프트웨어를 빠르게 개발하는 방법”을 추구하는 분야이다.
• 한때 소프트웨어 개발은 예술 또는 수공업처럼 여겨졌으나, 소프트웨어도 체계적 원리에 따라 개발해야 한다는 인식이 생기며 “소프트웨어 엔지니어링”이라는 용어가 등장했다. 이는 소프트웨어 개발을 반복 가능하고 예측 가능하게 만드는 방향으로 패러다임 전환이 일어났음을 의미한다.
• 소프트웨어 공학의 탄생: 1968년 독일 가르미슈에서 NATO 주관으로 열린 회의에서 처음으로 “소프트웨어 엔지니어링”이라는 용어가 공식적으로 사용되었다. 이 회의는 당시 만연하던 “소프트웨어 위기(Software Crisis)” – 즉, 소프트웨어를 제때에 예산 내에 품질 있게 완성하지 못하는 문제 – 를 해결하기 위해 학계와 업계 전문가들이 모인 역사적인 자리였다. 이 계기를 통해 소프트웨어 개발을 보다 체계적이고 학문적인 원칙에 따라 수행해야 한다는 공감대가 형성되었다.
• 이후 절차적 프로그래밍 → 구조적 방법론 → 객체지향 → Agile(애자일) 등으로 소프트웨어 개발 방법론에 여러 변화가 있었지만, 근본적인 목표는 복잡한 소프트웨어를 더 잘 만들기 위한 체계 확립이었다. 과거에는 완전히 새롭게 느껴지던 방법론들도 시간이 지나면서 공학적 지식으로 축적되었고, 소프트웨어 공학은 계속 진화하고 있다.
• 정리: 소프트웨어 공학은 “과학적으로 사고하고 실용적으로 행동하여 소프트웨어 문제를 푸는 것” 이다. 1960년대 말 소프트웨어 공학 개념이 탄생한 이후로, 소프트웨어 개발에는 개인의 재능뿐만 아니라 원칙과 프로세스가 중요하다는 인식이 자리잡았다. 이는 소프트웨어를 예술이나 수작업이 아닌, 체계적인 엔지니어링 활동으로 여겨야 더 나은 결과를 얻을 수 있다는 깨달음에서 출발한 것이다.

2장. 소프트웨어 ‘공학’의 참뜻

• “프로덕션(Production)은 우리의 문제가 아니다.” 소프트웨어는 한 번 만들어 놓으면 복제 비용이 거의 0에 가깝다. 제조업에서는 대량 생산(프로덕션)이 큰 도전이지만, 소프트웨어에서는 핵심 난제는 생산(복제)이 아니라 처음 그것을 ‘어떻게 설계하고 구현하느냐’ 에 있다. 따라서 소프트웨어 공학에서 말하는 공학은 대량 생산 기술이 아닌, 올바른 설계와 구축 방법론에 대한 것이다.
• 코딩 = 공학? 꼭 그렇지 않다. 현업에서 흔히 소프트웨어 엔지니어라고 하면 코드를 잘 짜는 사람을 떠올리지만, 공학의 핵심은 단순 코딩 이상이다. 공학은 문제를 분석하고, 최적의 해결책을 설계하며, 그 결과를 검증하고 개선하는 전체적인 문제해결 과정을 포함한다. 따라서 코드 작성은 공학 활동의 일부일 뿐이며, 소프트웨어 공학 = 코딩만 잘하면 되는 것이 아니라는 점을 인지해야 한다.
• 수공예 vs 공학: 소프트웨어 개발 초기에는 장인정신에 의존한 ‘수공예’적 개발이 주류였다. 개별 개발자의 뛰어난 능력에 따라 품질이 좌우되고, 표준화된 절차나 도구보다는 경험과 노력에 기대는 형태였다. 반면 공학은 재현성과 확장성을 중시한다. 누구나 일정 수준 이상의 품질을 낼 수 있는 프로세스와 도구, 원칙을 마련하고자 한다. 다시 말해, 수공예가 장인의 손끝 기술에 의존한다면, 공학은 누가 작업해도 일정 품질 이상이 나오도록 하는 시스템에 의존한다.
• 물론 장인정신과 창의성도 소프트웨어 개발에 중요하다. 하지만 수작업(장인 기술) 만으로는 현대 대규모 소프트웨어의 복잡성을 감당하기 어렵다. 수공예 방식은 개인의 역량에 크게 의존하기 때문에 팀 규모가 커지거나 시스템이 복잡해지면 한계에 봉착한다. 반면 공학적 접근은 정밀한 측정과 반복 개선을 통해 규모가 커져도 통제 가능한 개발을 가능케 한다. 예를 들어, 성능이나 안정성을 수치로 모니터링하고 개선하는 것은 공학적 사고이며, 이러한 측정과 피드백이 없이는 복잡한 시스템 품질을 유지하기 어렵다.
• 우리가 하는 일이 왜 진정한 의미의 소프트웨어 공학이 아닐까? 현실에서는 많은 프로젝트가 체계적 원칙보다는 데드라인 압박에 쫓겨 즉흥적으로 진행된다. 그 결과 “대충 돌아가는 대충 만든 코드”가 양산되곤 한다. 이는 진정한 공학이라기보다, 급한 불 끄기 식의 응급조치 개발에 가깝다. 공학은 단기적인 편의보다 장기적인 품질과 효율을 추구하지만, 현실의 많은 개발 현장은 장인정신도 부족하고 공학적 엄밀함도 부족한 난장판(sloppy mess) 상태에 머물러 있는 경우가 많다.
• 소프트웨어 제작의 트레이드오프: 결합도가 핵심이다. 소프트웨어 설계에서는 변경 용이성 vs 즉각적 효율 사이의 줄다리기처럼 여러 트레이드오프가 존재한다. 그 중심에 결합도(coupling) 문제가 있다. 결합도가 높으면 컴포넌트 간 변경 영향이 커져 유연성이 떨어지지만, 반대로 너무 결합도를 떨어뜨리면 (예를 들어 모듈을 극도로 세분화하면) 시스템 전반의 관리 포인트가 늘어나 복잡도가 증가한다. 공학적 설계란 이러한 결합도를 적절히 관리하여 요구사항 변화에 잘 대응하면서도 지나친 복잡성을 억제하는 절충을 해 나가는 일이다. 이렇듯 소프트웨어 공학은 곧 복잡성 및 변경 관리의 예술이라고도 볼 수 있다.
• 기술 발전의 진보라는 환상에 빠지지 말아야 한다. 종종 “새로운 언어나 툴을 쓰면 생산성이 10배 좋아진다”는 식의 주장이 있지만, 전설적 공학자 프레드 브룩스는 1986년에 이미 “소프트웨어 개발에는 은탄환(silver bullet)은 존재하지 않는다”고 설파했다. 그는 “향후 10년 내에 생산성, 신뢰성, 단순성을 10배 향상시킬 단일 기술이나 기법은 없다” 고 단언하며, 하드웨어 분야의 무어의 법칙처럼 소프트웨어 생산성이 자동으로 비약적으로 향상되는 일은 없을 것이라 했다. 결국 새 기술도 근본적인 복잡성은 남기 마련이므로, 기초 원리(모듈화, 좋은 설계, 테스트 등)를 무시한 채 신기술만 쫓는 것은 환상이라는 점을 명심해야 한다.
• 수공예에서 공학으로의 여정 은 아직 진행 중이다. 소프트웨어 분야는 비교적 역사도 짧고 변화도 빨라서, 전통 엔지니어링 만큼 표준화/체계화가 완성되어 있지 않다. 하지만 Agile 방법론이나 DevOps 같은 근대적 실천법들은 장인정신과 공학적 접근의 조화를 추구하며 한층 진화된 엔지니어링 문화를 만들어가고 있다. 더 이상 개인 영웅담에 기대지 않고, 팀과 조직의 지혜를 모아 소프트웨어 개발 프로세스를 지속 개선하는 방향으로 나아가는 것이 중요하다.
• 이제 우리가 고민해야 할 것은 “어떻게 하면 공학 원칙을 현실 프로젝트에 뿌리내리게 할까?” 이다. 현대의 소프트웨어 엔지니어들은 새로운 언어나 프레임워크뿐만 아니라, 테스트 자동화, 지속적 통합, 모니터링, 코드리뷰, 리팩토링 문화 등 공학적 기법들을 일상 업무에 적용하는 데 힘써야 한다. 대학의 비전공자 1학년 학생들도 앞으로 소프트웨어를 다룰 때 이러한 공학 마인드셋 – 체계적으로 계획하고, 측정하고, 개선하는 사고방식 – 을 갖추는 것이 큰 자산이 될 것이다.
• 정리: 소프트웨어 ‘공학’이란 코딩 이상의 무엇이다. 이는 장인정신과 창의성을 존중하면서도, 체계적 원칙과 데이터에 기반한 의사결정으로 소프트웨어 개발을 수행하는 것을 뜻한다. 수공예적 접근의 한계를 인식하고, 측정과 반복을 통해 지속적으로 개선하는 자세가 현대 소프트웨어 공학의 참뜻이다. 다시 말해, “대충 굴러가는 코드”를 넘어 과학적 엄밀함과 효율을 추구하는 것이 우리가 지향해야 할 모던 소프트웨어 엔지니어링의 길이다.

3장. 소프트웨어 공학을 이해하기 위한 기초 사항

• 새 기술만을 좇는 업계 풍토를 경계하자. 소프트웨어 분야는 유행 주기가 빨라 늘 새로운 언어, 프레임워크, 툴이 쏟아진다. 하지만 근본적인 원리는 비교적 변하지 않는다. 예컨대 1970년대의 모듈화 원칙이나 2000년대의 디자인 패턴 원리 등은 오늘날에도 여전히 유효하다. 최신 기술 자체보다 그 배경에 있는 공학적 문제 해결 원리를 배우는 것이 장기적으로 더 중요하다. 새로운 기술은 그때그때 활용하되, 핵심 개념(예: 높은 응집도, 낮은 결합도, 캡슐화 등)을 놓치지 말아야 한다.
• (비기능적 요소의) 측정의 중요성: “측정하지 않으면 개선할 수 없다”는 경영 격언이 있듯, 소프트웨어에서도 성능, 안정성, 보안, 사용성 등의 비기능적 품질을 숫자로 계량화해야 객관적으로 판단할 수 있다. 예를 들어 응답시간(ms), 장애복구시간(MTTR), 테스트 커버리지(%) 등의 지표를 살펴야 현재 상태를 정확히 파악하고 개선 목표를 설정할 수 있다. 이러한 품질 메트릭 없이는 문제를 감으로만 추정하게 되어 비효율적인 개발에 빠질 위험이 있다.
• 안정성과 처리량으로 생산성을 높이자: DevOps 연구 (DORA 등)에 따르면 소프트웨어 전달 속도(Throughput)와 안정성(Stability)은 트레이드오프가 아니라 동반상승하는 경향이 있다. 즉, 배포를 자주하고 빠르게 하는 팀일수록 서비스 안정성도 높다. 이는 빠른 피드백을 통해 결함을 조기에 잡고 지속적으로 개선한 결과이다. 반대로 “품질을 높이려면 개발을 느리게 한다”는 통념은 통계적으로 틀린 것으로 나타났다. 따라서 신속한 배포 파이프라인 구축과 자동화된 테스트로 안정성 확보를 동시에 추구하는 것이 현대 소프트웨어 공학의 생산성 비결이다.
• 우리는 어떤 분야의 전문가가 되어야 할까? 현대 소프트웨어 엔지니어는 특정 언어나 기술의 전문가라기보다, 학습과 적응의 전문가가 되어야 한다. 앞서 언급했듯 요구사항과 기술은 계속 변하기 때문에, 새로운 문제를 빠르게 이해하고 해결책을 찾아내는 능력이 중요하다. 마찬가지로 복잡성을 관리하는 전문가가 되는 것도 핵심 역량이다. 시스템이 커질수록 변경에 따른 영향 범위(코스트)가 기하급수적으로 늘어나는데, 이를 제어하지 못하면 개발 생산성은 급격히 떨어진다. 결국 좋은 엔지니어란 모르는 것을 금방 배우고, 복잡한 것을 단순하게 정리하는 사람이라고 할 수 있다.
• 학습의 전문가: 새로운 프레임워크든 도메인지식이든 학습 곡선을 빠르게 극복하고 자기 것으로 만드는 능력. 자신이 틀릴 수 있음을 인정하고 배우는 자세 가 중요하다 (엔지니어링적 사고에서는 처음부터 완벽할 수 없고, 빠른 실험과 피드백으로 개선해나감).
• 복잡성 관리의 전문가: 의도적으로 모듈화를 잘하고 결합도를 낮추며, 자동화 도구를 활용해 사람이 일일이 할 일을 줄이는 능력. 복잡성 관리의 궁극적 목표는 변화에 유연한 시스템을 만드는 것이며, 이것이 곧 소프트웨어 품질의 핵심 척도이다 (변경에 쉽게 적응하면 고품질 소프트웨어라고 할 수 있음).
• 정리: 1부에서는 소프트웨어 엔지니어링의 개념과 배경을 살펴보았다. 요약하면, 모던 소프트웨어 엔지니어링은 과학적 사고(실험, 측정)를 바탕으로 소프트웨어 개발을 체계화하는 것이다. 새로운 기술을 쫓는 것에만 급급하기보다 변하지 않는 원리(효율적 학습, 복잡성 관리 등)를 익히는 것이 중요하다. 비전공자라 하더라도 소프트웨어 분야의 기본 개념과 원칙을 이해하면, 기술 변화에 흔들리지 않고 문제 해결에 집중하는 역량을 키울 수 있을 것이다.