본문 바로가기
얼리어답터 리뷰/IT정보

[넉두리] 8년차 개발자의 이런 저런 이야기..

by 엔돌슨 2007. 11. 15.
반응형

링크 : http://www.okjsp.pe.kr/seq/107028

저는 전산실에 근무하는 8년차 개발자입니다.
요즘 아래 후배들을 보면서 느끼는게 있어 몇자 적어봅니다.
우리 개발자들이 각자의 위치에서 인정받고
오래도록 근무할 수 있기를 바라는 마음에서 써봅니다.
( 참고로 저는 SI 2년 , 회사내 전산실 6년차입니다. )

우선 일반적으로 개발자들은
회사내에서 그다지 높은 위치에 있지 못합니다.
다 그렇지는 않겠지만 일반적으로 그렇다는 이야기 입니다.
그것은 우리 개발자들의 어떤 잘못이 아니라
현업들의 마인드에 문제가 있는 부분이 크죠.
개발은 누구나 데려와서 시키면 된다는 못된 생각.

그런데 그것이 그렇다고 현업들만 탓하기에는 우리의 처지가 나아지는게 없죠.

현업들이 개발자들을 가볍게 여기는 이유중 하나가
업무에 대한 마인드가 개발자들에게는 없다는 것입니다.

사실 업무에 대한 마인드 없어도 높은 스킬로 작업하는데는 큰 무리가 없지만
그래도 업무에 대한 이해없이는 제대로 작업하기에는 힘든 부분이 있죠.

아래 글들을 보면 개발자가 쿼리를 알아야 하냐 마냐하는
조금은 소모적인 논쟁이 있는데..
사실 개발자가 쿼리를 알아야 하냐 마냐는 개인적인 실력이지 않을까 생각합니다.
개발자 치고 쿼리를 모르는 개발자가 거의 없겠죠..
하지만 개발자가 고도의 쿼리를 구사할 수 있다면 그것은 개인의 스펙이 커지는거니까
개인적인 실력차라고 봐야 하겠죠.

여기에 더해서 개발자가 여러 업무에 지식이 있다면
그것은 개인의 스펙이 더욱 높아지는걸 의미하는거니까
업무를 안다는것도 개발자에게는 무척 유리한 부분이 되는거라 생각합니다.

제가 왜 업무 이야기를 하냐면..
현업들이 개발자들에게 요구하는것이 이 업무에 대한 이해입니다.
사실 본래는 현업들이 기획해서 업무의 흐름을 그려주면
그걸 프로그램화 하는게 우리 개발자의 일이죠.
하지만, 많은 현업들은 대충 이야기하고
그걸 만들어주길 원하죠.
그 이면에는 그정도는 개발자들도 알고 있지 않냐는 생각이 있는듯 합니다.
알고 있으면 좋겠지만 모르는것도 당연한 일이죠.
우리가 현업이 아니니..
하지만, 알고 있는것이 역시 개인의 실력이 되는거겠죠.

이 알고 있는것과 모르고 있는것의 차이는 굉장히 크다는 생각을 합니다.

자바를 잘 하냐 .NET 을 잘 하냐, 또는 쿼리를 잘 하냐의 문제는
우리 개발자들 내부의 이야기들입니다.
현업하고의 이야기는 될 수 없죠.

우리는 현업들과 일을 하는거기 때문에
업무를 아는것과 모르는것의 차이는
우리를 대하는 현업들이 우리를 대하는 것의 차이와 비례한다는 생각을 합니다.
( 물론, 앞서 말했지만 꼭 알아야 한다는건 아닙니다.
다만, 못된 현업들이 대부분 그렇게 생각하는거죠. )

저는 후배들에게 조언을 많이 안하는 편이지만
술자리에서 몇마디 하게되면 하는 말이 몇년전부터 동일합니다.

개발의 능력을 키우기 위해서 언어도 공부하고
DB도 공부해야 한다.( 끊임없이 - 우리쪽은 짧은 시간에 많은것들이 변하지 계속 공부해야죠 )
여기에 더해서 좀더 좋은 개발자가 되려면
업무에 대한 공부도 해야한다.
회계에 대한 기본적인 공부도 하면 좋고
물류시스템에 대한 공부도 영업에 대한 공부도..
또 회사 재정에 관한 재무공부도..

물론, 다시 이야기 하지만 안해도 큰 문제는 없지만
한다면 개인적인 지식이 쌓이는거니 좋다는 이야기 입니다.

얼마전, 협력업체분과 1시간 정도 이야기를 나눌 기회가 있었습니다.
그분이 저랑 약간 말이 통해서 가끔 만날때면 길게 이야기를 합니다.
그분도 개발자인데 이런이야기를 하더라구요.
자기가 회사의 재무상태를 모르고 일을 할때와
거기에 관심을 갖은후 일을 하는것과는 많은 부분이 다르더라는 겁니다.
일단 다른 부서사람들과 이야기할때 공유되는 부분이 생기고
연봉에 대해서도 자기의 입장만 생각했는데
점점 회사의 입장도 이해하게 되고
그래서, 연봉협상할때 인상을 원할때는 그에 합당한 이유도 설득력있게 제시하고
( 회사의 이익에 따른 인상안 제시등.. )한다고 합니다.

에고.. 역시 제가 글 재주가 없다보니 정리를 잘 못하네요.

우리 개발자들이 좀더 인정받고 처우를 개선하기 위해서는
현업의 태도가 달라지는걸 바라기보다(어느 세월에)
우리가 그들의 인식을 바꿀수 있도록 노력하는것도 좋을듯 합니다.

모니터만 보고 일을 하기보다는
옆도 보고 위도 보고 시야를 조금 넓게 가져보는게 어떨까 생각합니다.

너무 길게 횡설수설 한것 같네요.

제 생각에 문제가 있다든지 하면 이야기 해주세요.
저도 제 생각을 다시한번 정리하고 싶네요.

모두들 행복한 인생 꾸리시기를 바랍니다. ^^

     
 
      
  • 아 좋은글 감사드립니다..업무흐름을 이해한다는건 참 난해하고 어렵다고 생각됩니다.
    저는 스킬도 중요하지만 업무파악이 제일 우선시 되어야 한다고 생각하는 분들하고 생각이 같습니다.
    사실 자바 잘 못합니다..쿼리는..남이 짜놓은거 보면 이해하는 정도입니다..저보고 똑같이 짜라고 하면 반드시 막힙니다..(ㅠㅠ)
    하지만 업무 흐름은 반드시 제대로 익히려 합니다..제가 구현하려다가 막히면 잘하는 분께 여쭈어 보더라도..업무를 알아야 제대로 알려달라고 요청을 드릴 수 있기 때문이고...도움을 요청하기에 앞서 준비과정도 그에 준하여 할 수 있기 때문입니다.
    그런데 요즘 막히는게 기술이네요...워낙 업무쪽 이해만 중요도 있게 생각하다보니..스킬이 딸려서..요즘 예전 문법 책 보면서 스킬 쌓고 있습니다...이제서야...공부 안한걸 후회합니다.
    하지만 지금 봐도 늦진 않더라구요...
    암튼 개발자 길이 참 힘들어요..어떻게 보면 상당한 매력이 있는 직업이라 생각해요(저만 그런가요??) 저는 이 직업이 참 맘에 듭니다.
    의사가 사람 몸 고치듯...저희도 무언가를 고쳐주고 희열을 느끼고..만들고 창조하고...제발 일에 몰두하고 일 자체가 즐거움의 요소가 되는 그런 세상이 빨리 왔음 좋겠어요...
    불합리한 구조부터..일보다는 돈이 지배하는 의식이 조금은 낮춰진다면 가능할까요???
  • 아놔
  • 2007-11-15 10:08:43
  • x
  • 좋은 말씀 감사합니다~~~ ^^
  • redhawk
  • 2007-11-15 10:11:47
  • x
  • 같이 일했던 일본개발자가 한마디 알려주시더군요.."좁은 시야를 넓히라!"
  • 아스키
  • 2007-11-15 10:29:09
  • x
  • 좋은 말씀 감사합니다..^^
  • k2ryu
  • 2007-11-15 10:33:53
  • x
  • 좋은 글입니다.
    소모적인 논쟁들보단 건설적인 이야기가 더 많아야 하는데 사실 현실이 그렇지 않아서 씁쓸합니다.
    열심히 살아야지 매번 다짐하지만 하루하루 똑같이 흘러가는 직장인들처럼 그렇게 살아가는게 지금의 내 모습이니...;;
  • Q u i c K
  • 2007-11-15 10:50:36
  • x
  • 글 잘 봤습니다.
    그 업무에 대한 지식이 현업보다 우위에 있다면 더 편해질(?) 수도 있습니다.
    다만... 현업들의 마인드도 좀 바뀌어야 하지 않을지...
    몇차례 프로젝트를 진행해본 분들은 그나마 좀 낫지만..
    의욕만 앞서 인공지능적(?)인 요구사항으로
    시스템의 기본을 흔드는 유저불량도 꽤나 있으니 말이죠.:)

    개발자도 하나의 바운더리에 속한 업무만 꾸준히 개발한다면 업무지식도 꽤나 쌓일텐데요.
    뭐 그러지 못하는 현실이 안타까울따름입니다. ^^
  • noodlecook
  • 2007-11-15 10:54:32
  • x
  • noodlecook// 동감..
  • 후니
  • 2007-11-15 10:56:03
  • x
  • 좋은 글입니다.
    몇년 전 세미나에서 어느 교수님이 하신 말씀이 기억납니다.
    앞으로 미래의 소프트웨어 개발은 Core를 담당하는 핵심 개발자만 더 높은 기술적 스팩이 요구되어지고
    대부분의 개발자는 업무적 스팩이 더 요구되어진다는 말씀...
    현재도 대부분의 core단은 몇몇의 리더들이 담당하고 대부분의 개발자들은 비지니스 로직 구현에만 집중해서 개발을 하고 있습니다.
    저도 요즘 고민중입니다. 전 새로운 기술을 배워나가는게 더 재미있고 좋지만..
    회사에서 요구하는 것은 그게 아니니....
  • 허허실실
  • 2007-11-15 10:57:31
  • x
  • 좋은글 잘 봤습니다
  • happynewmind
  • 2007-11-15 11:29:08
  • x
  • 업무를 잘 알게 되면
    현업과 동등한 레벨일까요? 상위레벨일까요?
    업무를 모르면 하위 레벨일까요?

    현 직장의 업무 프로세스를 파악하지 않아도 되는 개발이 있죠.
    솔루션 납품업체의 경우 솔루션에 대한 프로세스를 파악해야 하는...
    하지만 여기서도 개발자는 영업에 귀속되곤 합니다.
    왜죠? 왜일까요? 분명 영업보다는 솔루션의 장점, 단점, 한계를
    제대로 파악하고 프로세스도 정확히 아는데요.

    아마 업무를 제대로 알라고 하시는 말씀은 ERP 등의 사내 시스템을
    다루는 현장에 국한되지 않았나 싶네요.
    그런곳은 업무를 제대로 파악하는것이 거의 필수라고 여겨집니다.
    안그럼 일을 해도 제대로 했다고 할 수 없겠죠.
    말그대로 시키는것만 하는 로보트처럼 일하는게 아니라면요.
    하지만 그것 역시 한계가 존재합니다.
    매번 현장을 바꿔다니는 SI에서 새로운 현장의 시스템에 익숙해지는데는
    일정 기간이 필요한거니까요. 게다가 업무파악은...음
    결국 글을 쓰신 분의 말씀은 지긋이 한 회사 전산실에서 수년간을
    일을 하게 될 경우에나 노력에 대한 보상이 있어 보이네요.

    그렇다면 이외의 환경에서 프로젝트마다 업무를 파악하고 개발을 해나가는
    개발자들의 역량에 대한 기준은?
    분명 프로젝트를 수행할때 업무 프로세스를 파악하고 있는 능력은 현업보다는
    하위일 수밖에 없죠.
    하지만 개발자들이 업무 파악을 등한시해도 좋다는건 아니죠.
    자기기술개발, 업무파악 이런건 개발자의 기본 소양이라고 보여집니다.
    무엇을 더 중시하게 되는지는 현재 자신이 일을 하고 있는 근무처에 달라진다고 보고요.
    솔직히 SI를 하면 업무 이해 능력보단 개인 기술 능력이 더 중요하고 현업도 그런 점에서
    보는 관점을 달리 해야 한다고 여겨집니다만.

    까마득한 개발 3년차 후배의 좁은 소견이었습니다.
    많은 가르침 주십시요.
  • 손님
  • 2007-11-15 11:35:17
  • x
  • 예전에..
    개발자의 벽이 지금보다는 조금 높았던 시기에..
    제가 열심히 공부했던 그때..
    교수님께서 이런 말씀을 하셨었습니다.
    "개발은 지식을 담는 그릇이다"
    그 말씀대로 하나의 프로젝트를 완성하기 위해서 그 프로젝트에 대한 지식을 습득하는게 버릇이 되었죠..
    그 뒤부터 업무에 대한 이해를 하지 않으면 프로그램을 짜지 않습니다.
    그게 정상인데..지금은 뭐...
    벽도 좀 낮아지고..6개월 몇개월이면 몇백명씩 찍어내는듯한...
    그 쪽 교육이 참 마음에 안드는게..
    말그대로 현업을 프로그램화 하려면 업무의 흐름을 프로그램 로직으로 만들어야 하는데..
    그런 로직이나 로직을 그리는 플로우챠트 등은 전혀 안가르친다는거죠..
    그런거도 모르고 그냥 jsp문법이 어떻느니 하는거를 가르치면 뭐합니까..
    에궁..잠시 흥분을..;;
    이제...찍어내는 듯한 그런 취업만 목적으로하는 그런곳들..제대로된 교육을 하든가..망하든가 했으면 좋겠습니다.
  • 짱지
  • 2007-11-15 11:43:44
  • x

  • 8년차님// 글 잘봤습니다.
    제가 생각하는,,, 현업이 개발자에게 기획(설계)을 대충해서 주는 이유는 단한가지!!!
    귀찮아서 입니다.
    그리고,
    개발자가 A안, B안, C안, D안 ....을 가져와라..
    그러면 내가 그중에서 취사선택하겠다.
    이런 의도와 심리가 숨어있다는 말입니다.
    보통 일하러 여기저기 다녀보면 대부분 이런식이죠..
    개발요건, 요구사항을 제대로 내줘야 개발자가 편한데, 먼저 내가 알아서 해와라.
    그중에서 내가 고르던지, 잘못돼있으면 지적하겠다는
    편하게 가려는 심리.
  • 다가나지
  • 2007-11-15 11:56:22
  • x
  • 다가나지님 말에 동의 합니다.
  • 지나가다
  • 2007-11-15 12:50:41
  • x
  • 저도 글 잘봤습니다. 개발자 힘든 직업이죠. 끊임없이 공부해야하고 머리 열씨미 쓰면서하고
    가끔 개발자 단가 세다는글보면 참 끊임없이 노력해야하고 얼마안되는 연봉 시간으로 나눠보면
    진짜 다른 직종보다는 적게 받는건데 아직도 이런 얘기들으면 가끔 울컥해진다는...에휴
  • 산들바람
  • 2007-11-15 12:59:51
  • x
  • 데이타베이스나 WAS같은 시스템 소프트웨어를 개발하지 않는 이상, 업무 프로세스는 모든 시스템에서 가장 중요합니다. 개발자들이 참여하는 프로젝트에서 개발되는 시스템이 무슨 목적으로 존재하는지 생각해보세요. 업무흐름을 효율화하고, 비용을 절감하여, 경쟁력을 강화해서, 궁극적으로 회사의 수익에 기여하기 위해 존재하는 것입니다.
    이렇게 보면 돌아가는데 10초 걸리는 쿼리를 5초로 줄이는 기술보다는, 업무를 최적화할 수 있게, 해당 업무에 대해서 잘 파악하는 사람이 훨씬 더 좋은 개발자가 될 수 있습니다.
  • alva
  • 2007-11-15 13:47:55
  • x
  • 쿼리의 영역이 개발자였던가요?
    10초 걸리는 쿼리를 5초로 줄이는데에 총력을 기울이는 사람들은
    대용량 데이터베이스 분야의 사람들이라고 생각되는데요.
    개발자의 영역은 프로젝트의 전반적인 설계 능력이라고 생각됩니다.
    그런 바탕이 마련된 후 업무를 최적화할 수 있게, 해당 업무에 대해서 잘 파악하는 사람이 되면 훨씬 더 좋은 개발자가 되겠지요.
    아직 경험이 없는 저로써는 어느 특정 업무에 대한 공부보다는 설계 잘하는 프로그래머가 되기 위한 공부를 하고 싶네요.
  • 손님
  • 2007-11-15 14:09:00
  • x
  • 경계해야 하지 않을까요?
    의사도,변호사도 다들 전공이 있습니다. 물론, 그렇다고 의사가 다른 분야에 젬병이라고 할 수는 없지만요. 엔지니어도 마찬가지 아닌가요?

    자바 엔지니어가 SQL 을 짜는 것은 업무를 이해했다는 소립니다. 그런데, 속도가 안나온다는 것은, 쿼리가 덜 능숙하다는 것이죠.

    이것은 업무를 이해하는 것과 쿼리가 덜 능숙하다의 차이일 뿐 아닌가요?
    한국의 SI 현실이 만능을 원하지만, 그렇다고 그것이 정석이라는 생각은 아니라고 봅니다.
  • 제그리드
  • 2007-11-15 14:13:08
  • x
  • 12년차 입니다만..
    가끔 2-3년차 중에 "저는 내년부터 아키텍트 업무를 하고 싶습니다"라는 후배들을 보게 됩니다..

    뭐 아키텍트가 뭐라고 딱 꼬집어 말할 사람이 있을지 모르겠습니다만..
    그 뉘앙스는 "저도 설계를 잘 할 수 있습니다"로 들립니다.

    그럼 설계를 잘 하는 공부가 따로 있을까요?
    아닐겁니다..

    다양한 분야의 경험과 지식이 어우러져야 하겠죠.(물론 좋은 사수를 만나면 기간은 단축이 될 수 있겠습니다만)

    쿼리와 모델링, 그리고 DBMS 특성에 대한 것도 필요할테고
    네트웍과 WAS 구조에 대한 이해도 필요할테고
    해당 분야 업무에 대한 지식도 필수일테죠..

    특정 업무를 잘 아는 것은 유사한 업무로 넓혀 나가는데 매우 중요하다고 생각합니다..

    사족으로.. 저는 요새 테스팅 쪽에 이슈가 많아서 그쪽도 공부를 하고 있습니다..
  • 수빈빠
  • 2007-11-15 14:15:06
  • x
  • 현업은 딱 자기 하는 일만 아니까 업무 설명하려면 쩍팔려서 얼렁뚱땅 설명하려는 경향이 있지요.
    그리고 개발자가 질문하면 그때가서 아..그건요, 그러고.
  • japan
  • 2007-11-15 14:16:41
  • x
  • 저도 비록 3년차이지만 아키텍트의 명함이 그렇게 쉽게 따지는게 아니라는건 알고 있는데...
    아직도 디자인패턴과 리팩토링에서 해매는 햇병아리 개발자로써
    조심스럽게 결론을 내리면 특정업무에 8년정도 근무하면 업무가 보이고
    12년정도 근무하면 아키텍트가 보이는 그런거라고 생각하면 될까요? 흐흐흐
  • 손님
  • 2007-11-15 14:23:04
  • x
  • 저는 아직 경험이 부족해
    sql문법 핸드북 보면서 쿼리를 짜는데
    업무파악=테이블파악=쿼리작성
    이라고 생각합니다.
    업무파악이 안되면 테이블 파악도 안되고
    그러면 쿼리 작성도 산으로 가죠

    쿼리를 잘짜면야 좋겠지만
    업무파악되고 테이블 상관관계이해하고
    기본적인 쿼리는 작성할줄 알아야
    모델러든 dba에게든 도움을 요청할수있을거같습니다
  • 후니
  • 2007-11-15 14:52:52
  • x
  • 고수님들의 이야기 잘듣고 갑니다.. 다시한번 더 어떻게 하면 좋은 개발자가 될지 고민하게 되네요...
  • ...
  • 2007-11-15 14:53:25
  • x
  • 후니//뭐...논리모델이 없는곳이 대부분이라 테이블파악일 수도 있겠네요^^;
    논리모델만 보고도 대충 업무파악이 가능하면 더욱 좋겠죠? 어차피 데이터의 흐름이 업무니까요...
  • 2007-11-15 15:17:30
  • x
  • ㅎㅎㅎ 논리모델이 없는곳에서 근무중이라
  • 후니
  • 2007-11-15 15:22:00
  • x
  • 8년차님 등 다른 분들 글을 보고나서 울 나라 환경이 정말 이렇게 돌아가도 되는건지

    걱정이네요!!

    개발자도 여러 종류가 있는데 세분하게 분류되어 있지 않은 울 나라 환경에서는

    8년차 님 말도 맞는 애기입니다. 업무를 모르고 어떻게 설계를 하고 설계없이

    정확한(?) 프로그램을 개발 할 수 있겠습니까만은... 어디까지나 한쪽으로만

    집중 할 수 없는 개발자(특히 si쪽)은 빠른 시간안에 그업무를 최대한 이해하고

    분석해서 자기 나름의 스킬(?)로 적용할 수 있는 방법을 찾는 것이 현 우리 개발자들이

    풀어가야할 방향이라고 생각 합니다.

    스킬이 아주 뛰어나도 업무 능력이 부족하면 고객이 원하는 프로그램을 못만들고,

    고객이 원하는 솔루션에 대처 할 수 없는 거라고 생각 합니다.

    업무만 잘 이해해도 막코딩(?) 만으로도 문제를 풀어 고객이 만족 할 수 있는 프로그램을

    만들 수도 있는 것입니다. 이경우 유지보수는 어찌 할지 모르것지만서도 -_-;;

    저두 언 7년을 개발하고 학교 당길때 부터 지금까지 쭉~~ 소프트웨어공학에 깊은 뜻(?)을

    두고 있지만, 코딩 스클도 더 늘려야 것다는 생각이 많이 많이 드네요...
  • fatehun
  • 2007-11-15 15:37:05
  • x
  • 기업정보 SI에 종사하는 소프트웨어 엔지니어(PM,TA,DBA,SE,AP모두)는 정보기술이라는 도구를 가지고 기업가치에 득이되는 일을 하는 사람이지, 기업가치를 가지고 정보기술을 추구하는 사람이 아닙니다. IT에 처음 발을 들여놓거나 년차가 미력한 경우에 기술보다 업무만 따라가는 것도 바람직한 모습이 아니나, 자신이 종사하는 업종이 궁극적으로 뭘 제공해야 하는지, 고객이 뭘 원하는지 그 방향성에 대해서 고민하는 건 대단히 중요한 일이라고 생각합니다.

    업무를 안다는건, 이런 업무에 데이타베이스의 이런 저런 필드가 쓰인다 정도(기초적인 SQL을 짤 정도)를 의미하는게 아니라, 여러개의 필드가 쓰이는데, 이런것은 불필요하다, 저런것은 다른 것과 통합이 될 수 있다. 이런 필드가 필요하다. 이런것을 안다는 의미입니다.

    여러개의 비지니스 라인에 대해서 알고 있다면, 서로 다른 비지니스 라인을 위한 업무를 통합해서 비용을 절감하고, 관리상의 편의를 제공할 수 있는 공통된 모듈이나 구조를 만들 수 있습니다. 어플리케이션 아키텍쳐나 더 상위의 EA는 이런 업무에 대한 이해에서 나오는 겁니다.
    ( 물론 대단히 이상적인 예기이긴 합니다만 )
  • alva
  • 2007-11-15 15:40:34
  • x