대한민국의 개발자들은 거의 대부분 전쟁 중입니다. 디자이너와의 전쟁, 기획자와의 전쟁, 그리고 의뢰인과의 목숨을 건 전쟁을 하고 있습니다. 이 세 가지 부류의 사람이 개발자의 업무량에 치명적인 영향을 주기 때문입니다. 추가되는 기능이 중요한 기획이라면 처음부터 빠지면 안될 것인데, 왜 이제야 언급하는지. 프로그램은 경우의 수와의 싸움인데, 왜 그리 허술하게 기획해서 와서는 군대에서 삽질 시키는 것처럼 "저기 파 봐. 아니다 여기 파. 저기는 메우고" 같은 정제되지 않은 요구로 개발자를 지치게 합니다.
제가 철썩 같이 믿고 있는 기준이 있습니다. "프로젝트의 성공은 프로젝트가 오픈되고 나서 참여자들의 이직율이 얼마나 제로에 가까운가로 알 수 있다"
프로그래밍을 하면서 문제를 풀어나가는 것은 프로그래머들에게 모험과도 같습니다. 이것은 재밌는 일이죠. 하지만, 이 산이 아닌게벼 스타일의 일 진행은 문제 풀이가 아닌 정글 속을 헤매는 것 같습니다. 아, 정글이 아니고, 마땅한 비유가 생각나지 않는군요. 하여간 무진장 답답합니다. 그것 때문에 회사 생활이 야간자율학습과 같아지게 되고, 학창생활을 가장 재미없게 만든 것처럼 회사를 재미없게 만듭니다. 관리자가 돌아다니죠. 자리에 앉아 있나 땡땡이 치나. 걸렸을 때 회사가 학교보다 치명적인 고과가 나빠지고, 월급과 승진 심지어는 짤릴 근거가 되어 버립니다. 치사해라.
구글 디벨로퍼 나이트 2007의 초미인 Sophia Brueckner님의 발표를 들으면서 재밌는 생각을 해보았습니다. --; 이상한 생각 아닙니다. (H끼는 아주 쬐금 있지만)
일단 소개가 소프트웨어 엔지니어 라고 되어 있습니다. 기획자도 프로그래머도 아니고 엔지니어입니다. 발표 중에 자신은 2년 전 igoogle 서비스에 참여해서 지금까지 일해왔다고 했고, 자신은 자바스크립트를 모르지만 igoogle의 서비스는 쉽게 만들 수 있을 정도로 igoogle의 가젯만들기는 쉽다라고 했습니다.
헉, 뜨~.
웹 서비스의 소프트웨어 엔지니어가 자바스크립트를 모른다!
그 때부터 제 옆자리의 누군가가 묻더군요. "기획자 아녜요? 왜 자바스크립트를 모른다고 하지? 소프트웨어 엔지니어라면서"
오늘까지도 계속 생각하고 있는 명제였습니다.
소프트웨어 엔지니어란 무엇일까. 엔지니어 단어는 기술의 경제적인 요소를 잘 이용하는 사람이라는 뜻을 포함하는 것으로 압니다. 개발자냐 기획자냐가 중요한 것이 아니라 생각하게 되었습니다.
현재하고 있는 일이 최종 사용자들에게 얼마나 경제적인 효과를 가져다 줄 것인지, Vi삐리리 카드 선전처럼 돈으로 살 수 없는 경험을 주는 서비스를 만들고 있는지가 더 중요한 포인트라는 것이죠.
개발자도 기획자도 디자이너도 사람입니다. 의뢰인도 사람이고요. 이 사람들이 모인 이유는 새롭고 재밌는 서비스, 프로그램을 만들기 위해서입니다. 마음이 통해야 의사전달이 수월해집니다.
서로 이용해 먹으려고 하면, 이용당하는 사람은 기분 나쁩니다. 기분 더럽죠. 요구할 것은 요구하고, 그만큼 보상하고, 도와줄 것은 도와주고, 그에 상응하는 댓가도 떳떳하게 받을 수 있어야죠. 쿨한 관계, 부담 없는 관계, 치우치지 않고 평등한 관계, 합리적인 관계가 필요합니다.
만들어 놓은 서비스야 베타 딱지 붙이고 최종 사용자들이 만족할 때까지 점진적으로 양육시켜 나가면 됩니다. 그랜드 오픈일이다 뭐다 해서 납기일로 개발자들 초치지 말아주시면 좋겠습니다. 이미 윗선에 보고가 된 일이기 때문에 납.기.일.은 꼭 지켜야한다와 같은 피말리는 요구는 사양합니다.
세상에 가치를 만들어내는 재밌는 팀들이 많이 생기길 빌어봅니다. 하늘이시여~
제가 철썩 같이 믿고 있는 기준이 있습니다. "프로젝트의 성공은 프로젝트가 오픈되고 나서 참여자들의 이직율이 얼마나 제로에 가까운가로 알 수 있다"
프로그래밍을 하면서 문제를 풀어나가는 것은 프로그래머들에게 모험과도 같습니다. 이것은 재밌는 일이죠. 하지만, 이 산이 아닌게벼 스타일의 일 진행은 문제 풀이가 아닌 정글 속을 헤매는 것 같습니다. 아, 정글이 아니고, 마땅한 비유가 생각나지 않는군요. 하여간 무진장 답답합니다. 그것 때문에 회사 생활이 야간자율학습과 같아지게 되고, 학창생활을 가장 재미없게 만든 것처럼 회사를 재미없게 만듭니다. 관리자가 돌아다니죠. 자리에 앉아 있나 땡땡이 치나. 걸렸을 때 회사가 학교보다 치명적인 고과가 나빠지고, 월급과 승진 심지어는 짤릴 근거가 되어 버립니다. 치사해라.
구글 디벨로퍼 나이트 2007의 초미인 Sophia Brueckner님의 발표를 들으면서 재밌는 생각을 해보았습니다. --; 이상한 생각 아닙니다. (H끼는 아주 쬐금 있지만)
일단 소개가 소프트웨어 엔지니어 라고 되어 있습니다. 기획자도 프로그래머도 아니고 엔지니어입니다. 발표 중에 자신은 2년 전 igoogle 서비스에 참여해서 지금까지 일해왔다고 했고, 자신은 자바스크립트를 모르지만 igoogle의 서비스는 쉽게 만들 수 있을 정도로 igoogle의 가젯만들기는 쉽다라고 했습니다.
헉, 뜨~.
웹 서비스의 소프트웨어 엔지니어가 자바스크립트를 모른다!
그 때부터 제 옆자리의 누군가가 묻더군요. "기획자 아녜요? 왜 자바스크립트를 모른다고 하지? 소프트웨어 엔지니어라면서"
오늘까지도 계속 생각하고 있는 명제였습니다.
소프트웨어 엔지니어란 무엇일까. 엔지니어 단어는 기술의 경제적인 요소를 잘 이용하는 사람이라는 뜻을 포함하는 것으로 압니다. 개발자냐 기획자냐가 중요한 것이 아니라 생각하게 되었습니다.
현재하고 있는 일이 최종 사용자들에게 얼마나 경제적인 효과를 가져다 줄 것인지, Vi삐리리 카드 선전처럼 돈으로 살 수 없는 경험을 주는 서비스를 만들고 있는지가 더 중요한 포인트라는 것이죠.
개발자도 기획자도 디자이너도 사람입니다. 의뢰인도 사람이고요. 이 사람들이 모인 이유는 새롭고 재밌는 서비스, 프로그램을 만들기 위해서입니다. 마음이 통해야 의사전달이 수월해집니다.
서로 이용해 먹으려고 하면, 이용당하는 사람은 기분 나쁩니다. 기분 더럽죠. 요구할 것은 요구하고, 그만큼 보상하고, 도와줄 것은 도와주고, 그에 상응하는 댓가도 떳떳하게 받을 수 있어야죠. 쿨한 관계, 부담 없는 관계, 치우치지 않고 평등한 관계, 합리적인 관계가 필요합니다.
만들어 놓은 서비스야 베타 딱지 붙이고 최종 사용자들이 만족할 때까지 점진적으로 양육시켜 나가면 됩니다. 그랜드 오픈일이다 뭐다 해서 납기일로 개발자들 초치지 말아주시면 좋겠습니다. 이미 윗선에 보고가 된 일이기 때문에 납.기.일.은 꼭 지켜야한다와 같은 피말리는 요구는 사양합니다.
세상에 가치를 만들어내는 재밌는 팀들이 많이 생기길 빌어봅니다. 하늘이시여~
![초급자를 위해 준비한 인프런 [데브옵스 · 인프라] 강의](https://okdevtv.com/images/inflearn-react-api.webp)
