>
근로소득의 미래에 대한 생각을 적으면서 생각보다 “SI 개발자”를 검색하여 들어오시는 분들이 많다.
이 부분에서 흥미로웠다.
현업에 들어온 이후로 “SI개발자” 라는 단어를 포털사이트, 검색 사이트에서 검색해본 적이 없었다.
”SM개발자” 도 물론 검색해본 적이 없다.
프리랜서 급여와 관련된 글은 이직고민에 검색을 해보았으나, 각양각색, 능력껏, 알아서 가 포인트이다.
학생, 취업 준비생분들이 검색했거나 현업 SM에서 SI로 가기 위해서, 아니면 SI 관련 구직활동을 찾기 위해서라고 생각된다.
그래서 좀 더 개발자와 관련된 주제로 도움이 될지는 모르겠지만 얘기를 해볼까 한다.
댓글이 없기에.. 무엇이 궁금해서 들어온 건지 모르겠다.
프로젝트에 투입되어 기계적으로 코딩하는 개발자이다.
팩트 아닌가?해당 프로젝트 요건에 맞게끔 확인하여 코딩한다.
”기계적”이라는 단어에 아무 의미 없는 코딩, 내 스펙에 도움 되지 않는 코딩, 누구나 할 수 있는 코딩을 의미하는 것이 아니다.
기계처럼 코드를 뽑아낸다고 봐야 한다.
개발 -> 테스트 -> 완료, 개발 -> 테스트 -> 완료,,,,,, 작은 프로젝트, 큰 프로젝트의 정의는 회사의 수익, 이익과도 관련이 있지만 순전히 개발자의 입장에서는 WBS 요건이 많은지 적은 지가 중요하다.
개발 목록이라고 생각하면 편하다.
정말 단순하게 일반적으로 필자의 경험으로 건수를 생각해 본다면 이렇다.
20 ~ 60 개, 편안한 퇴근60 ~ 90 개, 음… 퍼포먼스 좀 내야겠는걸?.. 야근도 좀 할 수도 있겠는데?.. 주말도 잘하면 출근해야겠는걸?90 ~ 120 개, 음.. 야 근.. 음.. 주말 출근… NO 여유… 120 ~ 150개, 하… 이번 프로젝트 끝나고 퇴사각이다.
.150개 이상, 퇴사정말 평균을 내기 위한 단순한 지표일 뿐, 짧으면 짧을수록 위의 내용은 더 위험해지고 압박이 심해진다.
길면 길수록 좀 더 완화된다.
왜? 기간이 짧으면, 테스트를 정밀하게 할 시간이 없다.
개발실적을 찍느라 정신이 없다.
내가 지금 뭘 하는지도 모른다.
건수와 상관없는 난이도의 개발이 있다면 이건 또 다른 문제이다.
경험이 없는 건이라면.. 공수가 불확실하기 때문이다.
나 자신도 해당 건이 언제 끝날지 모르는……. 그래도 공수는 정해야 한다.
하지만 사실 모든 개발 요건마다 D-Day 가 정해져 있어, 개발자 수준에 맞는 요건을 받고 거의 대부분 타이트하게 돌아간다.
버그 및 수정, 추가 요건은 해당 Work D-Day에서 제외되기 때문에, 항상 개발은 타이트하게 여유시간을 확보해야 한다.
쉽지 않겠지만 말이다.
SI개발자들이 프로젝트를 다 만든 다음, 서비스를 OPEN 한다.
OPEN 할 수 있을 정도의 퀄리티까지는 올라왔다.
하지만 안정화가 되어 있지 않다.
해당 프로그램의 안정화, 버그 수정, 고객의 개선 요청 등등 프로그램을 조금씩 전반적으로 수정한다.
팩트는 유지 보수.. 간혹 힘든 SM도 있다.
SI 성 SM이다.
그렇지만, 필자가 지금까지 본 SM 들은… 1일이면 될걸 가지고 일주일은 한다.
18시 되면 칼퇴. 중간중간 커피타임. 필자의 경력이 미천하기 때문에, 모든 SM 들이 이렇다는 것이 아니다.
이런 SM도 있다는 것이고, 그렇기에 필자가 SM 을 싫어하는 것이다.
요즘 들어 공부하고 있는 주식을 예로 들면 성장 가능성이 낮다고 볼 수 있다.
전문성 SM 은 좀 다르다.
SI 성 SM, SI에서 개발한 사람을 연장해서 SM으로 데려갈 수 있다.
좀 더 전문적이거나, 일반 SM개발자가 못한다든지, 업무의 전체적인 흐름을 알고 있어야만 할 수 있는 SM 들도 있다.
이분들은 SI 개발을 통한 SM 으로의 연장이기 때문에 위에서 말한 것과는 전혀 다르다.
. SI 와 마찬가지로 힘들다.
SI 때처럼 힘들지는 않지만, 힘들다.
사실, SM은 안 해봐서.. 필자가 오해하고 있을 수 있다.
경험에 의한 글이기 때문에, 미래 성장을 위해서 노력하는 SM 개발자분들이 분노하지는 않길 바란다.
노력하는 SM 개발자분들도 이런 사람들을 일하면서 최소 한 번 이상은 만나 보았을 것 아닌가?근데 필자는 SM을 안좋아한다.
아니 SM개발자들의 마인드를 안좋아한다.
솔루션을 가지고 있는 회사에서 경력을 쌓는다면, SI, SM, 엔지니어의 구분이 애매모호 해진다.
SI처럼 일을 하고 SM처럼 유지 보수하고 엔지니어처럼 고객도 대응한다.
큰 구분으로 연구소, 개발팀, 서비스팀 등등 회사마다 다를 순 있지만, 보통 일반 중소기업이라면 전부 다 할 줄 알아야 한다.
그만큼 일이 많고, 초반에 배울 수 있는 게 넘쳐난다.
그만큼 버티지 못할 확률도 높다.
뭔가 체계적으로 내가 할 일, 안 해도 되는 일, 등에 대한 구분이 없을 수 있다… 해당 솔루션의 전문가가 될 수도 있지만, 해당 솔루션이 더 이상 필요하지 않는 세상이 온다면……… 여기까지 하겠다.
다양한 경험을 하고 분야를 넓혀가는 것을 추천한다.
간혹 SI 개발자에 대해서 힘들다는 말을 많이 듣고, 솔루션 개발자를 생각하고 있다면, 오산이다.
엄밀히 말하자면 솔루션회사에서는 SI처럼 안 할 것 같은가? 솔루션마다 다르겠지만.. 전문 기술을 가지고 일을 하기 때문에 분야가 어떻든 힘든 건 다 똑같다.
프로그램언어 자체에 익숙해질 수밖에 없다.
SI 경험이 없는 SM 개발자분들이 프리랜서를 시작한다면, 조금 어려울 수도 있다는 게 필자의 생각이다.
분위기에 적응 못하고, 실적의 압박에 힘들어, 내보내질 수 있다.
SI 개발자이면서, 새로운 개발 환경에 빠르게 익숙해질 수 있다고 생각된다면, 프리랜서를 추천한다.
단, 정말 최소 경력 3년은 쌓고 해라. 아무리 뛰어나도 경력 자체가 중요한 지표이다.
프로젝트 이력서 또한 중요한 지표이다.
3개월짜리 프로젝트만 3년 동안 12번 한 거랑, 1년짜리 프로젝트만 3번 한 거랑은 다르다.
2년 정도 경력 쌓고, 프리랜서 개발자들과 같이 개발을 했었고 그들보다 본인이 더 잘한다고 생각이 된다면, 도전해보는 것은 괜찮다.
프로젝트 기간이 적어도 10개월 이상인 프로젝트에 참여하는 게 좋다.
가장 큰 이유는 10개월 동안 안정적인 보수를 받을 수 있으며, 보통 길면 길수록 큰 프로젝트일 확률이 높은데, 다음 프로젝트를 구할 때 경력란에 쓸게 많아지고 프로젝트 기간 동안 인정받는다면 콜이 들어올 수도 있다.
6개월 일하고 다음 프로젝트를 구하지 못할 경우 구할 때까지 강제 무급휴가이다.
이럴 바엔 회사 들어가는 게 훨씬 좋다.
회사라는 울타리가 없는 만큼, 본인 스스로가 정말.. 잘해야 한다.
다른 조언은 없는 것 같다.
실수했을 때 날 감싸줄 울타리가 없다.
프로젝트 오픈 후에 버그가 나왔다.
아무리 봐도 개발 문제는 아닌 거 같다.
어디에 문의해야 하는가?문제가 생겼을 때, 아는 만큼 보인다.
네트워크 문제인지, OS 문제인지, DB 문제인지, 소스 문제인지, 알아야 해당 업체에 문의할 것 아닌가? 개발 이외에도 전체적인 프로그램 흐름과 관련해서 경험을 많이 쌓는 것을 권장한다.
개발만 잘한다고 해서 문제가 해결되지 않을 때가 훨씬 많다… 당연한 말이겠지만… 인간관계가 중요하다.
필드에 나오면 개발을 잘하는 사람, 언어를 잘하는 사람은 정말 많고, 똑똑한 사람들도 정말 많다.
간혹 “개발 잘하는 사람 == 일 잘하는 사람”으로 생각하는, 또는 추구하는 사람이 있는데… 잘못된 생각이다.
개발만을 가지고 판단한다면 스타트업이나, 천재들이 모여있는 Google로 가라..
사용할 수 있는 언어나 종류를 밝히려고 했으나,, 흐음..!
? 안 밝히기로 한다.
개발자로써 다양한 언어, 다양한 DB를 사용해보았고, OS는 linux를 해보았다.
생각보다 Linux를 사용할 줄 아는 개발자가 많지 않다는 것에… 의외로 놀랐다.
직장이 있을 때 프리랜서들을 많이 보았는데, 프리랜서라는 껍데기만 있는 떨거지들도 수없이 많다.
정말 오래 못 갈 것이다.
경력 값도 못하는 떨거지들.. 같이 일하고 싶지 않다.
그냥 회사에 충성하세요…제발요…
QA는 엄밀히 따져본다면,, 개발자가 아닙니다.
QA 프로그램을 만든다면 개발자이지만,, QA는 전문 기술을 요하는 것이 아니기 때문에, IT업계에 이력서를 내기가 쉽지가 않을 것이에요.죄송합니다.
QA는 잘 모르겠어요. 개발자의 분류로 생각해본 적이 없습니다.