소프트웨어 개발을 엔지니어링으로 만드는 것은 무엇인가
What makes software development engineering
소프트웨어 엔지니어라는 직함은 왜 특별하게 느껴질까? 1968년 NATO 소프트웨어 엔지니어링 컨퍼런스에서 '소프트웨어 위기'를 해결하기 위해 이 용어가 등장한 이래, IEEE는 엔지니어링을 '체계적이고 규율 있으며 정량화 가능한 접근법의 적용'으로 정의한다. 글은 이커머스 상품 상세 페이지 성능 개선 사례를 통해 추정, 구현, 피드백 루프로 이어지는 반복적 엔지니어링 접근법을 설명한다. 동작하는 소프트웨어는 비체계적으로도 만들 수 있기에 엔지니어링 접근법이 간과되기 쉽다고 지적한다.
소프트웨어 공급자는 '소프트'웨어는 고치기 쉽다고 생각하며 이것이 낮은 품질을 정당화한다고 여길 수 있다. 그러나 소비자에게 신뢰할 수 없는 소프트웨어를 사용하는 것은 매우 불쾌한 일이며 때로는 위험할 수도 있다.
HN 토론
58- mikewarot
> 실제로 캐나다 일부 주에서는 '소프트웨어 엔지니어', '컴퓨터 엔지니어' 등 '엔지니어'가 들어가는 컴퓨팅 직함은 (원칙적으로) 주 엔지니어링 규제 기관의 면허를 받은 사람에게만 허용됩니다.
가장 합리적인 입장이다. 미국에서도 이걸 시행해야 한다.
수정: 그래, 나는 소프트웨어 엔지니어는 면허가 필요한 직업이어야 하지만 프로그래머는 아니어야 한다고 주장하는 거다. 엄격함이 필요 없는 경우에는 프로그래머라는 대체 명칭으로 충분할 거다.
--
내가 엔지니어라면, 정수 처리 시설의 제어 시스템에 연결된 인터페이스 중에서 인터넷에 연결되어 제어 권한을 외부에 내주는 걸 절대 신뢰하지 않을 거다. 그냥 예를 하나 들자면.
2015년 OPM 해킹[1]은 국가 안보 측면에서 최악의 사례로, 그들의 컴퓨터 시스템 설계에 엔지니어가 전혀 관여하지 않았다는 걸 명백히 증명한다. 제어 권한의 외부 유입은 절대 금지되어야 하는데, 그렇지 않았다. 나는 왜 그 데이터베이스가 금고 속 파일 캐비닛 대신 컴퓨터에 들어갔는지, 왜 다른 시스템과 연결되어 있었는지, 그리고 왜 요청 시 수동으로 통제된 데이터 반출만 가능한 완전한 에어갭 상태로 금고에 보관되지 않았는지 이해할 수 없다.
[1] https://en.wikipedia.org/wiki/2015_Office_of_Personnel_Manag...
- randysalami
나는 소프트웨어 작업 중 일부만이 엔지니어링이라고 생각한다. 내가 (직업과 관련해) 스스로를 소프트웨어 엔지니어라고 부른다면, 그것은 실제로 '소프트웨어의 개발, 운영, 유지보수에 대한 체계적이고 규율 있으며 정량화 가능한 접근법'이기 때문이다. 말로만 그런 게 아니다. 그렇지 않다면, 나는 직함에 소프트웨어라는 단어가 있든 없든 (심지어 소프트웨어를 다루는 일을 하더라도) 다른 무엇이다. 직장 밖에서는 나는 본질적으로 스스로를 소프트웨어 엔진이라고 생각하지만, 직장에서 요구한다면 그것을 그보다 못한 것으로 취급하는 데 아무 문제가 없다.
- woah
유럽 어느 지역에서든 강력한 발리스타를 만들 수 있는 적절한 탄성의 묘목과 가지를 고르지 못하거나, 요새 벽 아래로 광산을 계획하고 지휘할 수 없다면, 너는 스스로를 엔지니어라고 부를 수 없다. 끝.
- tfrancisl
엔지니어링 설계 프로세스를 사용하면 그것이 엔지니어링이다.
- kerblang
글쓴이는 1968년 NATO SEC에서 사람들이 해결하려 했던 복잡성 위기를 설명하는 것으로 시작하지만, 그 후 엔지니어링을 계산과 캐시를 포함하는 문제 해결 노력으로 이야기한다.
복잡성 위기가 계속되는 게 놀라운가? 현대 시스템에서 의존성이 통제 불능으로 치솟아 온갖 혼란을 일으키고, 보안 문제까지 만든다. 학계는 이에 거의 관심이 없는 것 같다.