개발자로 일하다 보면 프로그래밍과 소프트웨어 엔지니어링에 대해 의미적 구분 없이 혼용되어 단어가 사용되는 것을 많이 경험할 수 있다.
두 단어의 차이를 알고, 자신이 둘 중 어떤 업무에 몰입 하고 싶은지 고민이 되는 분들이 이 글을 읽고 명확한 길을 찾으셨으면 좋겠다.
목차
- 소프트웨어 엔지니어링과 프로그래밍의 차이
- 그래서 나는 어떤 쪽이 더 맞는가?
- 이 글을 읽고 해결된 의문
소프트웨어 엔지니어링과 프로그래밍의 차이
구글 엔지니어는 이렇게 일한다라는 책에서 나온 것처럼 아래 문장이 두 단어의 차이점을 관통하는 문장이라고 생각한다.
Software engineering is programming integrated over time
소프트웨어 엔지니어링은 흐르는 시간 속에서의 프로그래밍을 모두 합산한 것이다.
개발자로서 우리가 코드를 짜는 것 그 자체는 프로그래밍이고, 계속 생겨나는 제품의 요구사항에 맞게 코드를 수정하는 행위를 포함해 소프트웨어 전반을 가지고 생애주기를 이어 나가는 것 그것이 소프트웨어 엔지니어링이라고 생각한다.
회사에 입사하게 되면, 새로운 코드를 작성하기보다는, 기존의 서비스를 이해하며 다른 사람이 작성한 코드를 읽고 이해하는데, 대부분 시간을 사용하게 된다. 이 자체가 소프트웨어 엔지니어링 위에 있다는 것이다. 코드로만 작성되고 짧은 생애주기를 가진 서비스였다면, 내가 그 코드를 이해할 필요조차도 없다. 하지만, 내가 작성되어 있던 기존 코드를 이해해야 하는 이유는 서비스를 지속 가능하게 새로운 기능들을 붙여나가야 하기 때문이다. 즉 지속 가능성이 핵심이라고 생각한다.
회사의 소프트웨어가 대부분 기대 생애 동안 요구되는 가치 있는 변경에 대응할 수 있어야 하기때문에 우리는 프로그래밍이 아닌, 소프트웨어 엔지니어링을 한다.
구체적인 업무 환경에서의 차이
일반적으로, 프로그래밍은 특정 문제를 해결하거나, 필요한 기능을 구현하는 코드를 작성하는 과정을 의미한다. 반면, 소프트웨어 엔지니어링은 소프트웨어 개발의 전체적인 프로세스를 포함하는 개념으로, 요구사항 분석, 시스템 디자인, 코딩, 테스팅, 유지 보수 등을 포괄한다.
이는 마치 건축과 미술을 비교하는 것과 유사하다. 프로그래밍은 소프트웨어를 ‘건축’하는 데 필요한 기술적인 능력이고, 소프트웨어 엔지니어링은 아이디어로부터 완성된 소프트웨어 제품까지 이르는 전체 과정을 관리하고 최적화하는 능력이다.
건축과 미술
건축은 계획, 디자인, 구조, 자재, 건설 기술 및 법규 준수 등 많은 것을 고려해야하는 복합적인 프로세스를 거친다. 건축가는 단순히 건물을 “만드는” 것 이상의 역할을 한다. 그들은 공간을 효율적으로 활용하고, 안전한 구조를 만들며, 미적으로 매력적인 동시에 기능적인 건물을 만드는 데 관여한다. 또한 거주하면서도 지속적으로 그 건물을 유지보수한다.
반면, 미술에서는 아티스트가 자신의 감정, 생각, 아이디어를 자유롭게 표현한다. 이는 기술적인 측면도 중요하지만, 아티스트의 창의력과 개인적인 표현이 무엇보다 중요하다고 볼 수 있다.
이런 관점에서, 프로그래밍은 코딩의 기술적인 측면, 즉 언어의 문법과 알고리즘, 로직 구현 등에 무게를 둘 수 있다(미술). 반면, 소프트웨어 엔지니어링은 프로그래밍을 포함하여 프로젝트의 시작부터 끝까지의 전 과정, 즉 요구 분석, 설계, 개발, 테스트, 배포, 유지보수에 걸쳐 진행되는 활동들을 총괄한다(건축).
Disclaimer) 제가 미술에 대해 잘 알지 못하여서 미술은 시간에 따라 작품을 계속 변경해나가야한다는 측면이 없다고 생각했습니다.
그래서 나는 어떤 쪽이 더 맞는가?
프로그래밍
자신이 제품의 성장에는 크게 관심이 없고, 새로운 기술을 개인의 취향에 따라 사용해 보고 그것에 희열을 느끼는 분이시라면 소프트웨어 엔지니어링보다는 프로그래밍을 하는 것이 더 좋을 수 있다. 프로그래밍한다는것은 글 초반에 말했듯이 시간이 흘러갔을 때 소프트웨어의 그림을 상상하지 않고, 현재 상황에 입각하여 현재 요구사항에만 맞게 서비스를 설계한다고도 이야기할 수 있을 것 같다.(견고하지 않다는 것이 아니다)
기술적 성장을 목표로 하는 주니어 개발자분들 같은 경우, 프로그래밍적 측면에서 더 몰입하면 보다 원하는 목표를 빠르게 실현할 수 있다고 생각한다.
사실 취업을 하기 위한 목표라면 지속 가능한 설계를 해야 하는 개발자를 뽑아야 하는 회사가 보기에는 좋은 선택은 아닐지도 모른다.
소프트웨어 엔지니어링
제품을 지속 가능성 측면에서 많이 고민하는 분들이 적합하다고 생각한다. 서비스 자체를 짧은 생애 주기로 여기지 않고, 이런 요구사항이 들어오면 어떡하지? 이런 방향으로 피봇하면 어떡하지? 등 시간이 흘러 미래에, 제품에 대한 청사진을 그리며 개발하는 개발자들은 소프트웨어 엔지니어링 측면에서 몰입하면 좋다.
개발자의 성장 패스와 역할
초기 개발자로서의 여정에서는 코드를 작성하는 기술과 개발 툴을 사용하는 능력에 무게가 실리곤 한다. 그러나 경력이 쌓이면서 다른 스킬들이 중요해진다. 예를 들어, 다른 팀과의 커뮤니케이션, 프로젝트 관리, 시스템 설계 등 다양한 역량이 요구된다. 여기서 소프트웨어 엔지니어링 역량이 더욱 중요해지며, 더 큰 그림을 볼 수 있는 능력이 필요해진다. 이는 시스템의 확장성, 유지 보수성, 팀의 생산성 등을 고려하게 만든다.
이 글을 읽고 해결된 의문
- 나는 프로그래밍의 길을 걸을지, 소프트웨어 엔지니어링의 길을 걸을지에 대한 이정표
- 소프트웨어 엔지니어링이 프로그래밍보다 좋다는 오해
마무리
이 글에 나온 부분에 대해 더 깊게 인사이트를 얻고 싶으신 분들은 구글 엔지니어는 이렇게 일한다 책을 읽어보시길 추천해 드립니다.