소프트웨어 공학을 전공하지는 않아 잘은 모르겠다.
하지만 자명한 것 한가지는 소프트웨어 공학의 철학적 기반에는 소프트웨어를 하나의 공업적 생산물로 바라보는 시각이 자리잡고 있다는 사실이다.
소프트웨어는 분명히 산업적 가치를 가지고 있다.
따라서 소프트웨어의 생산에 있어서 공학적 방법론을 마련하는 것은 어찌 보면 당연한 것인지 모르겠다. 소프트웨어에 대한 요구의 양과 복잡도가 늘어나고 그 질에 대한 민감성이 높아지는 마당에 소프트웨어 생산의 안정성 확보를 위한 공학적 방법론은 필수불가결한 일이라 할 것이다.

함께 일하던 한 개발자의 죽음에 관한 지난번 글에 많은 댓글이 달렸다.
그 댓글의 내용은 크게 두 가지인데 하나는 고인에 대한 추념이며 다른 하나는 '혹사당하는 개발자'에 대한 걱정과 연민이었다.
소프트웨어 개발에 종사하는 많은 개발자들이 홀대 혹은 혹사에 대한 탄식과 문제제기성 댓글을 남겼다.

과연 개발자들은 다른 직군에 비해 유독 '혹사' 당하고 있는 것일까?
과연 개발자들은 다른 직군에 비해 유독 노동강도에 미치지 못하는 보상을 받고 있는 것일까?

소프트웨어 공학 - 개발자의 적?

근대 산업사회 이래 시장 확대와 생산성 향상을 위해 과학적 발명이나 발견 이외에 다양한 '생산 기술'이 발전 해 왔다. 획기적 발명도 적절한 '생산 기술'이 수반되지 않으면 이는 시장성 결여로 간주되어 사장되고 만다. 많은 경우 충분한 생산 기술의 확보 여부는 최초 창작/창조보다 더 중요한 의미를 지니게 된다. 독보적 창의력이 없어도 '생산 기술'만 있으면 시장 지위를 획득 할 수 있는 것이 사실이다.
소프트웨어가 전 산업 분야에서 걸쳐 해당 산업의 생산성에 중요한 위치를 차지하게 됨에 따라 소프트웨어에 대한 '생산 기술'이 도입되기 시작하였다.
적어도 하나의 단위 생산조직에서 생산성의 극대화는 표준화, 즉 개별적인 차이를 제거하는데에서 시작한다. 소프트웨어 생산에 있어서도 이러한 경향은 마찬가지이다. 소프트웨어 '생산 기술'은 소프트웨어 개발자가 되기 위한 전제조건을 크게 낮출 수 있는 인프라를 요구하였다. 대량의 소프트웨어 개발자를 저가에 확보하기 위해 개발자에게 요구하는 기술적 요구사항은 크게 줄어들었다.
이는 소프트웨어 기술에서의 표준화와는 다른 관점이다.

그러나 이러한 소프트웨어 생산기술은 개발자가 무엇을 개발하고 있는지 파악 할 수 없게된다는 부작용을 수반한다. 개발자는 극단적으로 분절된 단위 로직을, 도저히 자동화 할 수 없는 종단의 로직을 개발하는데 흩뿌려진다.
그 뿐만 아니다. 오늘날 개발자들은 프로그래밍의 근간이 되는 기술로부터도 소외되어가고 있다.Pascal Language를 만든 Niklaus Wirth의 명저 "Algorithms + Data Structures = Programs"를 많은 분들이 기억 할 것이다. 그러나 과연 오늘날 개발 과정에서 자료구조를 혹은 알고리즘을 고민하는 개발자가 얼마나 될까?
이는 개발자에게 보상을 더 하는 것으로 해결될 수 있는 문제는 아니다.

물론 일부 개발자들은 프로젝트의 전 과정에 대한 명확한 목적의식을 가지고 개발에 임하고 있으며 또 다른 일부 개발자들은 본질적 프로그래밍 기술에 대한 연구에 매진하고 있을 것이다.
그러나 절대 다수 오늘날 '개발자'들은 이러한 행운을 누리지 못하고 있으며 무엇인지 알지 못한채 그 무엇을 개발하는데 내 몰리고 있다.

개발자는 무엇으로 사는가

오해일지 모른다.
하지만 그럼에도 불구하고 나는 개발자가 회사나 일을 떠나는 것은 단지 하는 일이 힘들어서가 아니라 일에서 성취감을 얻지 못하기 때문이라 믿는다.
개발자들과 프로젝트의 배경과 비젼을 공유하고 성공적인 결과에 대한 같은 이미지를 가질 수 있다면 어떨까?
자신이 만드는 것의 가치와 더 좋은 결과물을 위해 자신이 버려야 할 것과 따라배워야 할 것을 나눌 수 있다면 어떨까?
개발자 하나하나가 창의력을 발휘할 공간을 만들어 주면 어떨까?

작년 말 부터 설무렵까지 많은 우리 개발자들이 iPhone용 트레이딩 소프트웨어 개발에 참여했다.
참고할만한 사례가 어디에도 없는, 전혀 새로운 것을 만드는 프로젝트였다.
증권거래라고 하는 매우 엄격한 조건 아래에서 전혀 새로운 결과물을 만들어냈다.
그들은 무척 힘들었을것이다.
하지만 그 고통을 이겨낼 수 있었던 가장 큰 원동력은 그들이 창조행위를 했기 때문이다.
'요구사항 명세서'를 코드로 옮기는 것이 아니라 스스로 그 요구사항을 만들어내는 프로젝트였기 때문이라고 나는 믿는다.




그 결과, 그들이 만들어낸 소프트웨어는 가장 아이폰 다우며 가장 독창적인 iPhone용 트레이딩 소프트웨어인 iPlustar였다.




아직은 이런 저런 bug fixing을 해야 한다.
하지만, iPlustar는 '산출물'이 아니라 '창조물'이기에 우리 개발자들이 나는 오히려 부럽기만 하다.

다만, 그 개발의 행복함을 채 경험하기도 전에 먼저 저 세상으로 간 @sangho78 님이 안타까울 따름이다.