Egloos | Log-in
결론에 가보기
결론에 가보기
태그 : 개발자
2013/08/01   [잡생각] 웹개발자의 시대가 다시 온것인가? [8]
2013/07/04   [잡생각] 개발자라는 직업... [8]
2011/10/06   [잡생각] 어떻게 하는게 개발을 잘하는 것일까?
2009/03/17   [책] 코끼리는 생각하지 마 [4]
2008/07/15   [잡생각] 코더가 되지 말아야 하는데..
2008/07/02   [잡생각] 개발자를 무엇으로 평가할 것인가? [2]
2007/12/24   [잡생각] 당신은 깨어있는 개발자인가.. [4]
[잡생각] 웹개발자의 시대가 다시 온것인가?
어제 나랑 동갑인 개발자 친구랑 한잔하면서 이런 저런 이야기를 나눴다.
그친구도 꽤 괜찮은 회사에서 좋은 대접을 받고 있지만 그만두고 스타트업의 회사로 이직하기로 하였다. 

나랑 그친구가 본격적인 웹개발을 시작한 것은 1999년, 2000년 IT 버블이 막 시작할때였던 것 같다. 
지금 모바일 스타트업 회사가 많이 생기던 것처럼 인터넷 회사(? 머하는지도 모르는)가 우후죽순으로 생기고
홈페이지 만들고 포털만들고 카페 만들고 ... 등등 회사만 만들면 쉽게 투자를 받는 시대이었다. 

이와 더블어 웹페이지를 만들수 있는 개발자가 진짜 많이 필요하였다. 
대기업 연구소에 있던 나도 아는 선배형을 따라서 벤처에 발을 들일때가 이때였다. 

물론 IT 버블이 빠지면서 내가 다니던 회사도 문을 닫았지만 난 좋았다. 
진짜 미친듯이 웹페이지를 찍어내고 있었다. 
2년차의 쥐뿔도 모르는 개발자가 할주 아는 것이라고는 같은 코드 카피해가면서 빠르게만 만들고 있었다.
그래도 무엇인가 만들어진 결과물을 보는 재미에 푹빠졌었다. 

회사가 망하고 나도 솔류션을 만드는 회사, SI 프로젝트를 거쳐가면서 한동안의 암흑기를 걸었다.
그때도 물론 웹개발자의 니즈가 없는 것은 아니었지만 윈도우 클라이언트 개발자, 솔류션 개발자가 좀 더 대우를 받았다.

대형 포털 업체가 구체화가 되면서 웹개발자는 이런 대기업에서 일을 하던지 SI 또는 프리랜서를 하던지
양쪽으로만 나눠진 상태로 한동안 흘러온것 같다.

그리고 지금과 같은 모바일 디바이스의 시대가 왔다. 

처음 앱이 나왔을때는 앱을 만드는 클라이언트 개발자의 니즈가 폭팔하였다. 
2010년쯤에 코코아로 앱을 만들 수 있었으면 굉장한 대우를 받으면서 갈 수 있었을 것이다. 
초창기 앱의 스타일은 모바일 디바이스 자체에서만 돌아가는 형태이었다. 

점차 클라이언트 개발자들도 앱개발자로 전향을 하면서 니즈를 충족시켜가고 있고 
앱의 형태도 단순한 형태에서 점차 서버 클라이언트 통신형태로 복잡해져가고 있었다. 

이에 따라서 어느정도 니즈를 충족시킨 앱개발자에 비해서 서버개발자의 수가 부족해져가고 있다. 
어플리케이션 서버개발자는 워낙 사람이 적고 풀이 적은 상태이었고 

서버의 니즈도 
컨넥션을 계속 연결하고 있는 어플리케이션 형태의 서버보다는
필요할때 요청해서 결과를 받고 한동안은 클라이언트에서 처리하다가 결과를 서버로 보내는 형태가 
3G와 같은 망에서 더 유용한 형태가 되면서 모바일의 서버를 웹서버로 만드는 방식이 유행하고 있다.
덕분에 웹개발자가 서버를 만들게 되었고 나도 모바일게임의 서버개발이라는 부분을 담당하게 되었다.

그전에 만들던 웹페이지와 크게 다르지 않다.. 
그냥 결과물을 xml이나 json으로 건네주면 되는것이니...

그리고 경력이 좀 있는 웹개발자의 경우 DB쿼리는 왠만큼 쓸줄 알고 
웹서버의 성능을 높이고 부하를 줄이는 지식을 습득하다가 보니 자연스럽게 서버 아키텍쳐를 그리고 있다. 

모바일의 스타트업 업체가 늘면서 
기본적으로 서버개발자가 필요하고 간단한 운영툴도 필요하게 웹개발자를 많이 찾고 있다. 
특히나 시니어급(서버 아키텍쳐나 프로세스 구성해줄수 있는)은 완소 캐릭이 되어버렸다. 
그전 회사에 팀마다 2~3명씩 있던 10년차 이상의 웹개발자가 나와서 찾으려니 정말 없다..

스타트업중에서도 자금여력이 되는 곳은 대형포털의 시니어급의 몸값을 맞춰서라도 데려오려고 한다.
스타트업의 리스트때문에 선택에 조심스러워하고 있기는 하지만 도전을 선택하는 사람들도 늘고 있다.

이제 다시 한번 웹개발자의 시대가 온 것인가?  이게 얼마나 갈까? ^^

모바일게임쪽에서 점차 MMORPG의 게임을 준비하고 있다. 
이때는 반드시 어플리케이션 서버가 필요하다. 그렇다면..앞으로 2~3년의 모습은 하이브리드서버의 형태가 될것같다.

그냥 자기가 좋아하는 분야를 끝까지 잡고 있으면 흐름은 오는 것이다. 아님 말고 ^^
by 제우스 | 2013/08/01 10:53 | 말말말 | 트랙백 | 덧글(8)
[잡생각] 개발자라는 직업...
한달이라는 시간을 잘 쉬고 새로운 회사에 자리를 잡았다. 
팀장이라는 타이틀을 달고 싶지 않았지만 상황이 여의치가 않네.. 
그래도 운영이라는 미션은 없이 아키텍쳐의 역할에 치중할 수 있을것 같아서 하겠다라고 했다.

회사에 와보니 팀의 막내가 나랑 15살 차이가 나는 .. 90년생...
전문화 고등학교를 졸업하고 대학교는 패스하고 회사 생활을 하면서 현재 병특인 남자아이다.
완전 어린애이지만 롤이라는 게임이 우리 사이에 있기에 대화는 어렵지 않다고 ^^

이런 저런 이야기를 하다가 보니깐 개발자라는 직업의 이야기가 나왔다. 
그는 개발도 좋고, 돈도 많이 벌고 싶고, 지금 가는 길이 맞는가 하는 고민이 좀 있는것 같았다. 

내가 생각했을땐 말이지...
어떤 직업이든지 열심히 10년이상을 꾸준히 하면 분명 빛을 보게 되어 있고 돈도 꽤 벌수 있을것이라 생각한다.
특히나 직업과 같은 롱텀으로 생각을 해봐야 하는 부분에 대해서는 현재 가장 좋은 직업을 선택하는 것은 
큰 실수를 할 수 있는 부분이다. 

10년전만해도 의사, 판사, 검사, 변호사, 선생, 공무원의 직업이 최고였겠지만, 아직도 꽤 높은 상위에 있지만
10년뒤에는 난 장담할수 없을것이라 본다. 법조계의 이야기를 들어보면 그 어렵다라는 사법고시를 통과해도 
연수원의 성적으로 상위 30%만 판검사가 되고 그 다음 상위 30%가 대형 로펌에 변호사로 가고 
나머진 개인 변호사 사무실이던 일반 회사로 가야 한다.. 하위 40%는 정말 밥줄 걱정을 해야 한다. 

철밥통이라는 공무원도, 그 좋다라는 공무원 퇴직연금도..  
정년이 짧아지고 수명이 길어지면서 정년퇴직이후에 할수 있는것이 별로 없고(전문직이 아니니)
점차 공무원의 퇴직연금도 조정이라는 칼을 피할수 없을것이다. 

직업이라는 것은 전망을 보고 선택하기 보다는 그냥 자기가 재밌어하고 좋아하는 것을 선택하는 것이 좋을것이다.

그런 측면에서 개발자라는 직업이 나는 정말로 좋다. 
컴퓨터를 만지는 것이 좋고 만들고 바로 돌아가는 결과물이 나오는것도 좋고 
숨겨진 버그를 찾아냈을때의 그 기쁨은 정말 이루 말할수 없다. 

이슈트래킹 시스템에 해야 할 일을 왕창 등록해두고 하루에 2~3개씩 일일퀘스트를 하는 느낌으로
점차 목표점에 도달하는 진행방식도 꽤 괜찮다. 

돈? 
흠.. 내가 상위 몇%인지 (하위에서 카운팅하는것보다는 상위에서 하는게 빠르겠지 ^^ ) 모르겠지만 
내 스스로 부족하다라는 생각은 하지 않는다. 정년이라는 것이 있을지 모르겠지만 그 다음부터는
프리랜서로 전향해서도, 연봉을 다운해서 한참을 더 유지할수 있을것이라 생각이 든다. 

또 희망적(?)인 소식이 요즘 대학생들이 IT를 3D업종으로 보고 들어오지 않기에  
나의 자리가 위태롭지 않아서 한참을 더 할 수 있을것같다. 

물론 개발자로서 엄청나게 성공한 사람들도 많다. 

NC의 김택진 사장이나 드림위즈의 이찬진 사장들은 20대에 아래아한글을 만들었고
안철수 의원(?)은 20대에 V3의 백신을 만들었고 
네오위즈를 만든 나성균회장, NHN의 1세대라고 불리는, 지금은 흩어져서 여러회사에서 사장을 하고 있는 사람들 모두
20대에 큰 거 한방씩을 터트렸었다. 
그래서 뛰어난 개발자는 20대에 무엇인가 한방을 터트린다라고 한다. 

이미 20대가 훌쩍 지난, 허접하고 평범한 개발자인 나는 그 반대를 보고 있다.
25년이상 개발을 한 대한민국 개발자는 거의 없다. 20년을 현장에서 계속 개발한 개발자도 유니크다. 
15년 이상의 개발자를 찾는것도 정말 어렵다. 

앞으로 10년정도만 현장에서 더 버티면 나도 유니크한 개발자가 될수 있을것이다. -0-
이정도면 충분한 거 아닌가?
by 제우스 | 2013/07/04 14:38 | 말말말 | 트랙백 | 덧글(8)
[잡생각] 어떻게 하는게 개발을 잘하는 것일까?
개발자로 생각하는 내 자신에게 늘 던지는 질문이었고 최근 2~3년동안 무엇이라 답을 잘 하지 못하였다. 
올해초 리플래쉬를 다녀오면서 개인적으로 결론을 내려보기도 하였는지만 정답인지는 모르겠다.
경력자의 면접관으로 들어가게 되면 단골질문이기도 한 "어떻게 하는것이 개발을 잘하는 것일까?"

아래의 내용은 내가 년차별로 그 당시에 느꼈던 "잘 하는 개발"에 대한 정의였는데
년차가 올라갈수록 나도 성장을 하면서  관점도 바뀌고 경험도 늘어나면서 조금씩 달라져가고 있다.

1~2년차
벤처회사에 있을당시 미친듯이 몰려오는 일에 대해서 
"정해진 일정에 맞춰서 빠르게 개발을 하면서" 나름 난 뛰어난 개발자야..라는 말도 안되는 생각을 할때였다.
리소스 재사용이나 db connection 관리 같은것은 잘 모르겠고 ctrl+c, ctrl+v 가 최고였다. 

3년~5년차
대학교때 자바를 배우긴하였지만 OOP의 개념을 다시 접하면서 
소프트웨어 설계라는 것을 어느 정도 알게 되었고 
"설계된 방식으로 정확히 개발하는 것"을 하기 위해서 많이 노력하였다. 
약간의 소프트웨어 설계도 접해보긴 하였지만 지금 돌이켜보면 제대로 한것 같지 않다.
SI를 할때이니 내가 만든 소프트웨어의 운영 및 수정을 해본적이 없을때였다.

5년~8년차
설계에 어느정도 관심이 있으면서 더블어 소프트웨어 공학에도 많은 관심을 가지게 되었다.
설계를 하는 것도 중요하지만 같이 개발을 하는 모든 사람들이 그 설계를 벗어나지 않고 
같은 맥락, 같은 수준(깊이)로 만드는 것이 정말로 정말로 쉽지 않다는 것을 알게 되었고
"누구나 쉽게 코드를 이해할수 있도록 만드는 것"이 중요하다라는 생각을 하게 되었다.
 
함수명과 변수명도 바로 알수 있도록 사전에서 좋은 단어를 선택하기 위해서 
로직설계보다 여기에 더 많은 시간을 투자하게 되었고 조건체크를 2번하더라도 한눈에 보기가 쉽다면
프로그램 라인이 늘어나는 것에 주저하지 않았다. 

8년차~ 12년차(지금)
지금도 누구나 쉽게 코드를 이해할수 있도록 만들어야 한다는 생각은 변함이 없다. 
하지만!!!! 누구나 쉽게 이해한다는 것이 사람마다 방식이 모두 다르다는 것에 대해서 많이 느끼게 되었고
다른 사람의 코드를 쉽게 보기위해서는 그 사람의 스타일을 아는 것이 중요하다라고 생각하게 되었고
팀원들간의 코드리뷰를 될수 있으면 많이 할수 있도록 분위기 조성하는 것에 초점을 맞췄다.

이슈관리시스템과 SVN을 잘 연동하고 프로세스를 어느정도 정리하여서 소스코드의 변경은
반드시 이슈관리시스템의 이슈와 연동이 될수 있도록 중요성을 강조하고 다른 사람들에게도 쓰도록 하였다.
(전규현님의 블로그를 참조하였다 ^^)

새로운 프로젝트를 만들때 사업적인, 기획적인 이슈이외에 개발적인 테마를 정하고 도전하였다.
스크럼 방식으로 개발방법을 정해보기도 하고 TDD는 약간 무엇인가가 부족해서 기능별 자동테스트의 프로세스 생성에
도전해보기도 하고 사용자관점의 완벽분석 로그시스템도 만들기도 해보고... 등  실패도 많지만.. 성공도 있었다. 

이런 일련의 과정들이 "개발문화, 개발철학을 만들고 유지하는 것"으로 어느 정도 정리가 되는듯하였다.

강압적인 분위기가 아니라 경력이 많은 개발자가 솔선수범하고 자연스럽게 미들과 주니어 개발자의 동참도 이끌어내고 
담당하고 개발하는 시스템도 우리들이 정한 개발문화, 개발철학에서 벗어나지 않고 잘 유지되도록 말이다. 

이것이 팀장의 역할이 아닐까 하는 생각도 있지만 
이런 개발문화를 만들고 이끌어주는 시니어 개발자가 있으면 너무나 좋겠다라는 생각이 든다. 

나보다 경험이 많은 개발자가 있다면 물어보고 심도있는 토론을 해보고 싶은데
다들 통닭집으로 가기도 하고 매니저로 전환한 사람들이 많아서 누구랑 이야기해보지?

꼬리말1.
위에 있는 잘하는 개발자의 내용에는 어떤 기술을 사용하였는지, 어떤 언어를 선택하였는지는 하등 관계가 없다.
기술이라는 것은 그때 필요한 요구사항에 맞도록, 운영에 가장 적정한 것을 선택하면 되는것이다. 
뛰어난 성능, 안정성도 비슷한 맥락이다. 꼭 필요한 경우가 있지만 꽤 많은 경우는 하드웨어의 성능으로 커버가 되고
24시간 365일 무정지 시스템과 같은 케이스는 그렇게 많지 않으니 잘 맞는 기술을 선택하면 되는 것이지...
by 제우스 | 2011/10/06 10:18 | 컴퓨터 | 트랙백 | 덧글(0)
[책] 코끼리는 생각하지 마
코끼리는 생각하지 마
조지 레이코프 지음, 유나영 옮김 / 삼인
나의 점수 : ★★★★★

1월달 사내 독서토론회에서 선택된 책이다. 
2월달의 책인 '배려'를 저번에 올렸으면서 
이제서야 1월달 책을 지금에서야 올리는것이 ... 책을 다 못읽어서이다

토론회전까지 책을 다 못읽어서 끝나고 나머지를 읽을려고 하는데
그전까지의 집중력은 모두 사라지고 너무나도 잘 안읽혀지더라. 
질질끌다가 그냥 책을 덮는것으로 결정을 내리고 이제서야 리뷰를 올린다. 
(토론을 열심히 했으니 다 본걸로 할수 있지 않을까요? ^^)

코끼리는 생각하지마 
참 제목이 엉뚱하다.하지만 책을 좀 보다가 보면 어느정도 이해를 할수 있다.
코끼리는 미국 공화당을 상징하는 것으로 민주당에서 분명히 우리가 선거에서 이겨야 하는데
왜 지고 있는 것일까.. 하는 것을 분석하고 결론을 내리는 책이다.

난 정치에 그렇게 관심이 높은 편이 아니라 이런 책에 별점 5개를 주는 약간은 언밸런스한 모습이지만
민주당이 선거에서 진 원인을 분석하고 내린 결론이 참으로 멋진 방안이고 너무나 큰 느낌을 받아서이다.

이 책의 핵심은 '프레임' 이라는 것이다.

공화당에서는 수년간 이런 프레임을 만들고 퍼트리고 사용하는 것에 많은 학자와 연구원들을 
고용하고 투자하고 전파해서 만들고 있다. 아무리 논리적으로, 체계적으로 설명하는 민주당이지만
프레임을 이용하는 공화당에게 결국 지고 만다. 

이런 프레임을 이용하는것은 미국의 공화당뿐만이 아니다. 
우리나라의 한나라당, 조선일보.. 등등 언론뿐만 아니라 학원선전, 광고등의 마케팅에서도 폭넓게 쓰고있다.

그럼 이 프레임이라고 하는 것은 무엇을까? 예를 가지고 한번 살펴보자

한창 우리나라에서 촛불시위를 많이 할때, 
유모차를 가지고 시위에 참석한 유부녀들이 있었다.

유모차가 상징하는 것은 가족적인 분위기, 귀여운 아기, 행복한 순간 등등을 사람들은 쉽게 느낀다.
그래서 촛불시위 + 유모차라는 프레임은 시위를 문화제로 바꿔주는 역할을 하고 있었다. 
이때 조중동에서 선택한 프레임은 '유모차부대' 라는 것이다.

부대라는 프레임은 조직적, 계획적, 전투, 희생.. 등을 가지고 있다. 
이 프레임을 역이용해서 촛불문화제를 전투적이고 조직적인 시위로 다시 탈바꿈 시켰다.

내가 출퇴근하는 버스에 붙어 있는 학원광고들이 많다.

거기서 주로 쓰는 단어(프레임)이 비법, 공식, 법칙, 마법.. 등등이다. 
이 프레임은 마치 이 학원을 안다니는 너희들은 이런 공식도 모르고 무식하게!!! 혼자 우매하게 삽질하고 있다. 
이리와서 간단히(?) 해결할수 있는 길이 있다. 배워라~ 를 의미한다.

IT의 개발자라는 프레임은 어떨까?
이미 3D 업종이고, 맨날 밤새고, 피곤함과 지친 모습이 연상이 되고, 고집불통에 말도 잘 안통하는..
이것은 누가 만들었을까? 바로 우리 개발자들이 만들었다. 그래서 스스로 무덤을 파고 있다.
개발자들을 파리목숨에 기피대상으로 만들고..

우리 스스로 이런 프레임을 바꿔야 한다. 물론 당장은 되지 않는다. 
공화당에서도 프레임을 만드는데 5~6년이 걸렸다. 개발자들은 더 걸리지도 모른다. 

개발자? 너네가 상상만 한 것들을 우리가 실제로 만들어준다. 상상만 해라~ 
라는 프레임을 만들어야 하지 않을까? 이게 우리가 살길 일수 있다.
by 제우스 | 2009/03/17 15:01 | 영화나 책 | 트랙백 | 덧글(4)
[잡생각] 코더가 되지 말아야 하는데..
요즘 들어
늘 바쁘고 정신없고 열심히 일을 하는것 같은데 무엇을 한지 잘 모르겠고
책을 통한 공부도 소홀해지고 내일 무엇을 해야할지 머리에 잘 정리가 안되는
것을 보니.. 코더가 된듯하다.

코더라는 정확한 역할이 있는 것도 같지만
(디자이너가 그린 포토샵 파일에서 개발자가 코드를 넣을수 있는 html코드까지 만들어주는
사람들을 html 코더라고 하기도 하던데..)
내가 언급하는 코더는 개발자, 엔지니어 vs 코더 의 개념이다.

개발자와 코더가 무엇이 다를까

내 기준은
요즘처럼 기획자가 비지니스 플로우 와 화면을 모두 구성해주고
선행되는 개발자가 시스템, 소프트웨어의 구성을 모두 잡아주고 나면
시키는데로, 정해진 방식 그대로 타이핑 하는 사람이 코더라 생각을 한다.

뛰어난 기획자를 만나면 모든 에러의 경우, 메시지까지 모두 추려서 준다.
선행되는 개발자가 테이블 구성, 관계설정, 로그 포맷, 형태, 클래스 구성, .. 등을
만들어주면 코더들은 너무나도 행복하다. 그냥 짜기만 하면 된다.
그껏해봐야 테이블 필드명 조금 보고 나면 신나게 짤수가 있다.

열심히, 빠르게, 누구보다 많이 짠다고 기뻐하고 역시 나는 우리나라의 IT업계의 주역인
개발자라고 자부심이 느끼겠지만 그대는 3년정도만 되면 누구와도 별반차이가 없는
10만 양병설의 주인공인 코더일뿐일 것이다.
왜 이렇게 해야 하는가, 이렇게 하는것이 정말 사용자를 위한 것인가 하는 고민이 없다면..

하지만 ^^
지금의 나처럼 상황이 나를 코더로 만들고 있다.
소프트웨어의 구성이나 사용자의 편의성을 을 조금 바꾸고 높여볼려고 하면
당장 급한 오류부터 처리해야만 하는 상황때문에 힘들다.. (핑계일라나? 흠)

그런데 참 아무 고민 없이 마음이 편하기는 하다.
이클립스로 클릭, 클릭, 수정하고 화면 확인하면 끝.. 오늘도 한건 완성 ^^
내일은 머 내일 기획자가 안되는고 하는거 하면 되겠지..라면서 퇴근..
이런 타성에 점점 젖어든다..

휴.. 깨어나야 하는데. 깨어있어야 하는데.. 쉽지 않다.
제발 안정화가 될때까지만.. 코더로써.. 개발자를 잊지 말자..
by 제우스 | 2008/07/15 15:56 | 말말말 | 트랙백 | 덧글(0)
[잡생각] 개발자를 무엇으로 평가할 것인가?
벌써 7월달이 되면서 하반기로 접어들었다.

이 얘기는 상반기 평가가 이루어지고 있다라는 얘기이기도 하다
늘 평가기간이 되면 기분이 썩 좋은 편이 아니다. 내 평가가 만족스럽지 않다라기보다는
평가자들이 개발자들의 평가를 위해서 사용하는 잣대에 늘 짜증이 난다

회사의 기본틀은
정해진 목표에 달성을 하게 되면 B, 120%이상 초과달성이면 A, 140% 초과달성이면 S이다.

이 틀을 개발자에게 적용해보면
프로젝트A에 대해서 사용자의 요구사항을 모두 받아서 정해진 기간내에 만들면 B이다. -_-;;;
그럼 A와 S를 받기 위해서는 어떻게 해야 하는가?

개발쪽에 초과달성이라는 말을 적용해볼만 것은
개발기간 단축, 성능 향상, 매출의 증대 .. 정도이다.

성능 향상이라는 측면은 이것이 필요하거나 중요한 프로젝트는 내 경험상 10개중 1~2개뿐이다
특히나 웹쪽 관련한 시스템에 성능이라는 단어를 쓰는것이 좀 오버인듯하다. 사용자가 느리다는 것을
느끼지 못하는정도인데.. 그 이상의 성능을 내어야 하는가?
하드웨어의 성능 향상에 따른 시스템의 성능도 정말 특별한 경우가 아니고는 신경쓸 필요가 없을정도이다.

매출증대.. 매출과 연관이 되어 있는 프로젝트이라면 그래도 괜찮은 편이고
그리고!!!! 경험상 매출이 증대가 되면 개발자는 늘 맨 마지막에 혜택을 받는다..
결국 다 같이 평가가 좋다는 얘기다.

결국 나오는 얘기는 개발기간 단축이다.
이 얘기가 나오면 정말 짜증이 난다. 잘 만드는것보단 빠르게 만들면 장땡이란 얘기인듯하여서 ..
정말 사악하게  개발기간 2배 뻥튀기 한다음에 절반으로 줄여볼까? 라는 잔머리까지 등장하고
머.. 개발기간을 충분히 주는 프로젝트는 거의 본적이 없으니.. 개발자보고 죽으라는 얘기이다.

평가자와의 평가면담을 하면

평가자A : 니가 그 잣대를 만들고 전파해라. 아직 나를 납득할만한 잣대가 없으니 안된다.
평가자B : 니가 아이디어를 내고 프로젝트를 붐업시켜서 결과까지 만들어내라.
평가자C : 나도 정확히 무엇을 해야할지 모르겠다. 하지만 지금 상태는 아니다.

회사의 기본틀에서 개발관련 평가자들의 평가가 그들마다 늘 다르기에
이번에 평가자A를 기준으로 맞추어도 평가자가 바뀌게 되면 말짱 도루묵이 되기 일쑤이다.

물론 그들을 이해하지 못하는 것은 아니다.
개발자의 경력이 올라가다가 보면 매니저로 건너가야 하는 것이 일반적인 상황이기에
매니저의 관리능력을 빼고 개발만으로 경력이 높은 개발자를 평가하는 것은 롤모델도 없고
많이 해보지도 않아서 애매할것이다. 특히나 운영과 개발을 같이 하는 팀에서는 단순 운영만은
5년차나 10년차나 별반 다르지 않다라고 생각할 것이다.


생각을 바꾸어서..


현재 지금 운영을 목표로 하고 있고 추후 개발을 해야 하는 이번 프로젝트에서 
3년차의 개발자와 다르게 내가 어떻게 해야 내 역할을 하고 있다라고 할수 있을까를 생각해본다.

꽤 고민을 해서 선택한것이
3년차의 개발자가 당장의 에러나 수정사항을 고친다면
나는 이 소프트웨어가 전체적인 틀이 제대로 짜여져있는지, 이 설정의 의미가 무엇이고 어떤 영향을
주는지 등등 소프트웨어 아키텍트나 테크니컬 코치의 일을 하는게 맞다라고 생각한다.

하지만 이것을 어떻게 평가와 연결을 시킬지에 대해서는 자신이 없다.
이런 것에 대해 평가자들이 개념이라도 있을까? 쩝쩝.

내가 현재 평가에 대해 할수 있는 일이란
이런 의문을 평가자에게 계속 제기하는 것뿐이다. 그래서 평가자도 생각을 한번 더 하게 하고
그 다음 평가를 받는 사람에게 '나도 생각을 해보았는데..'라는  평가자의 말을 듣게 하는
정도이겠지만.. 점차 좋아질것이라는 기대를 해본다.


ps. 글을 쓸려고 생각을 정리하다 보니깐 재밌는 것을 찾아냈다.
기존에는 B평가를 받는 프로젝트가 5개이거나 10개이거나 전체는 B이다.
하지만 동일한 규모라고 한다면 상반기에 10개를 하였다면 5개를 한것보다는 더 좋은 평가를 받는게
맞을듯하다. 즉 평균이 아니라  누적으로 계산을 하는 부분이 있어야하네..
평가자님하~ ^^ 껀수 하나 더 찾았어요.. 준비하세욥~
by 제우스 | 2008/07/02 11:28 | 말말말 | 트랙백 | 덧글(2)
[잡생각] 당신은 깨어있는 개발자인가..
(늘 드는 생각이지만 제목을 만드는것이 참 쉽지가 않다 ^^ )

이 포스팅에선 내가 생각하는 개발자의 필수사항 중 한개를
내가 접한 사건과 더블어 이야기 해보고자 한다.

우리팀의 주업무중에 한개가 과거 포스트에서 설명한 적도 있지만
전체서버에 대한 소스관리가 있다. 오픈소스를 수정하여서 만든 tool인데
이 tool의 로그를 잘펴보다가 보면 요즘 어떤 팀이 바쁜지 ^^ 대충 눈에
보이기도 한다.

요즘은 연말이라서 나를 비롯하여 전체적으로 정리분위기라서
그렇게 심하게 바쁜편은 아니다. 하지만 유독 한팀에서 요즘 한창 바쁜것으로
보이는 팀이 있다. 크리스마스때 고생하는 것이 아닌지 연민이 느껴진다.

우리회사에서의 개발환경은 개인개발환경, 실QA환경, 실서비스환경이 있다.

기획자의 기획내용으로 담당개발자가 자신의 개인개발환경에서 개발을 하고
완성이 되면 기획자, QA들이 그 개발자의 개발환경으로 접속해서 테스트를 한다.
개발용 DB환경에 테스트용 Data이지만 가끔 실Data를 가져와서 setting을 하기에
완전 테스트용 datat는 아니다.  여기까지는 우리팀이 관여하지 않는다.

실QA환경으로의 요청이 들어오면 이때부터 우리팀이 소스관리에 관여를 한다.
실서비스와 거의 동일한 환경으로의 setting이고 데이터는 real DB와 연결이 되어있고
일반 사용자만 접할수 없고 실제 환경과 동일하다.
여기서 마지막 QA 및 테스트를 한다.

그리고 실서비스환경으로 소스가 뿌려지면 사용자들의 변경된 내용을 접하게 된다.

요즘들어 바쁜 그팀에서는 개발자가 4~5명 되는데
한창 실QA환경으로 소스를 보내달라고 요청이 들어온다.

그런데!!!!

내가 좀 어이없어 하는 것은 실QA환경으로의 요청과 재요청이 너무 빈번하다는 것이다.

요청이야 한번은 와야 하는 것이지만 재요청이라는 것은 내가 느끼기에
개발환경에서의 Test에서 발견하지 못한 내용이 실환경에서 나타났다는 얘기이다.

이런 경우가 없는 것은 아니지만 이렇게 똑같은 파일을 5~6번씩 재요청이 들어올정도는
아니다. 어떤 경우는 실서비스까지 뿌려졌는데.. 재요청으로 다시 수정하고 뿌리는 경우도
발생을 하였다.

내가 추측하건데 이럴때는 딱 2 가지 경우이다.

개인개발환경에서 테스트를 하지 않았거나 기획자의 기획내용이 자주 변경이 될때이다.
그팀의 개발자들의 초보자가 아니기에 테스트를 하지 않았다기 보다는 기획내용의
빈번한 수정이 있었을 것이다.

메신저로 그팀의 사람과 잠시 얘기를 하였었는데..
아시자나요~ 여기 기획자 어떤지.. 라는 말로 자신의 상황을 대변하였지만.. 난 그 개발자도
잘못하고 있다라고 생각을 한다.

개발자와 기획자의 관계는 어떤것인가..

지금 회사와 같은 웹환경에서는 컨텐츠의 핵심은 기획자가 가지고 있다.
그래서 그 팀의 개발자들은 기획자가 시키는데로만 열심히 하고 있는 것이다.
산중턱에서 이산이 아닌가보다.. 라고 하면 다시 내려가서 다른 산을 열심히 오르고 ..

나는 이런 사람들은 깨어있지 않다라고 생각을 한다.

특히나 개발자는 늘 깨어있어야 한다고 생각을 한다.
그래서 주위의 사람들에게 긍정적인 액션을 취해야 한다. 다른 개발자이건 기획자이건

기획내용을 보고 피드백을 줄것이 없는지..
이렇게 자주 변경이 되면 기획의 핵심을 잘 잡고 있는 것인지 기획자에게 피드백을 주고

실용주의 프로그래머라는 책에서도 이런 얘기가 있다.

사용자들의 어떤 작업을 현재 어떻게 하느냐는 것을 알아내는 것보다 왜 그럴 하는지
그 내재적 이유를 알아내는 것이 더 중요하다

깨어있으려는 노력을 해보자.. 그렇다면 해당 프로젝트후에 평가가 분명히!! 다를 것이다.
어이 없는 얘기를 할지어라도 열정적이다라는 평을 받을테고 그 중에 1~2개 괜찮은
아이디어로 기획자에게 감동을 준다면 기획을 아는 개발자라는 평을 받을 것이다.
by 제우스 | 2007/12/24 11:36 | 컴퓨터 | 트랙백 | 덧글(4)
◀ 이전 페이지 다음 페이지 ▶

카테고리
영화나 책
말말말
컴퓨터
게임이야기
태그
똑바로일하라 ngrinder 2nd밴드 메이저코드 원리 디아블로3 스테가노그래피 라이프사이클 재태크 파워코드 보험 공연 슬럼프 직업 개발자 화성학 나꼽살 vanish 오픈세미나 하이코드 제이슨프라이드 기타코드 웹개발자 ror helloworld 게임 서버개발 개발 마이너코드
전체보기
최근 등록된 덧글
엄지척 바짝 올립니다. 궁금했던..
by 초보 at 10/11
다자가이든 소작이든 닭이 천 마리..
by yada at 09/20
나는 팔라독 헬 깸.
by 남영찬 at 06/17
^안녕.하세요^;; 골드팟 생기개..
by 전설의레전드소설책 at 03/25
이왕이면---- A7 등등 '7' 이 붙는..
by papagoat at 04/12
매우 감사합니다 ! 아주 쉽게 키..
by papagoat at 04/12
자꾸 F를 라로 표기하시네요 ㅎㅎ
by 안녕하세요 at 12/21
시 클라식 기타 코드표 도 보여..
by 강초보 at 06/08
sp를 싫어하는 개발자들은 유지..
by 나도개발자 at 04/23
여자친구와의 금연약속을 어겨서..
by 구사일생 at 11/13
라이프로그
똑바로 일하라
똑바로 일하라

펜트하우스 코끼리
펜트하우스 코끼리

화폐전쟁
화폐전쟁

10억
10억

거북이 달린다
거북이 달린다

용의자 X의 헌신
용의자 X의 헌신

마더
마더

터미네이터 : 미래전쟁의 시작
터미네이터 : 미래전쟁의 시작

스타트렉 더 비기닝
스타트렉 더 비기닝

천사와 악마
천사와 악마

노잉
노잉

7급 공무원
7급 공무원

박쥐
박쥐

인사동 스캔들
인사동 스캔들

와이키키 브라더스
와이키키 브라더스

매란방
매란방

건투를 빈다
건투를 빈다

코끼리는 생각하지 마
코끼리는 생각하지 마

배려
배려

벤자민 버튼의 시간은 거꾸로 간다
벤자민 버튼의 시간은 거꾸로 간다

작전
작전

워낭소리
워낭소리

작전명 발키리
작전명 발키리

적벽대전 2 : 최후의 결전
적벽대전 2 : 최후의 결전

트랜스포터 - 라스트미션
트랜스포터 - 라스트미션

디파이언스
디파이언스

사랑하지 않으면 떠나라!
사랑하지 않으면 떠나라!

촐라체
촐라체

쌍화점
쌍화점

황후화
황후화

크리스마스 별장
크리스마스 별장

눈먼 자들의 도시
눈먼 자들의 도시

예스맨
예스맨

순정만화
순정만화

펀치 레이디
펀치 레이디

눈에는 눈 이에는 이
눈에는 눈 이에는 이

전략적 책읽기
전략적 책읽기

돈, 뜨겁게 사랑하고 차갑게 다루어라
돈, 뜨겁게 사랑하고 차갑게 다루어라

좋은 놈, 나쁜 놈, 이상한 놈
좋은 놈, 나쁜 놈, 이상한 놈

다크 나이트
다크 나이트

H2 1
H2 1

그림으로 읽는 생생 심리학
그림으로 읽는 생생 심리학

호모 코레아니쿠스
호모 코레아니쿠스

강철중: 공공의 적 1-1
강철중: 공공의 적 1-1

이채원의 가치투자
이채원의 가치투자

쿵푸 팬더
쿵푸 팬더

카불의 사진사
카불의 사진사

인디아나 존스 4 - 크리스탈 해골의 왕국
인디아나 존스 4 - 크리스탈 해골의 왕국

시골의사의 부자경제학
시골의사의 부자경제학

종자돈 700만 원으로 부동산 투자 200억 만들기
종자돈 700만 원으로 부동산 투자 200억 만들기

우리동네
우리동네

디지로그 digilog
디지로그 digilog

대하소설 주역 4
대하소설 주역 4

읽지 않은 책에 대해 말하는 법
읽지 않은 책에 대해 말하는 법

Stick 스틱!
Stick 스틱!

색즉시공 시즌 2
색즉시공 시즌 2

바르게 살자
바르게 살자

20대는 통장을, 40대는 인생을 채워라
20대는 통장을, 40대는 인생을 채워라

점퍼
점퍼

생로병사의 비밀
생로병사의 비밀

추격자
추격자

오늘의 거짓말
오늘의 거짓말

주식시장을 이기는 작은책
주식시장을 이기는 작은책

대한민국 진화론
대한민국 진화론

무방비 도시
무방비 도시

피라니아 이야기
피라니아 이야기

우아한 세계
우아한 세계

경제를 읽는 기술
경제를 읽는 기술

실용주의 프로그래머
실용주의 프로그래머

블로그 비즈니스
블로그 비즈니스

어거스트 러쉬
어거스트 러쉬

세븐데이즈
세븐데이즈

뷰티풀 선데이
뷰티풀 선데이

괴물 1
괴물 1

킹덤
킹덤

당신과 일하기 힘들어 죽겠어
당신과 일하기 힘들어 죽겠어

뉴욕의 프로그래머
뉴욕의 프로그래머

나를 바꾸는 데는 단 하루도 걸리지 않는다
나를 바꾸는 데는 단 하루도 걸리지 않는다

벽오 금학도
벽오 금학도

해바라기
해바라기

펀드투자가 미래의 부를 결정한다
펀드투자가 미래의 부를 결정한다

상식이 통하는 웹사이트가 성공한다
상식이 통하는 웹사이트가 성공한다

아버지의 가계부
아버지의 가계부

본 얼티메이텀
본 얼티메이텀

최강 로맨스
최강 로맨스

여자도 여자를 모른다
여자도 여자를 모른다

부동산 10년 대폭락 시나리오
부동산 10년 대폭락 시나리오

아키텍트 이야기
아키텍트 이야기

보물지도
보물지도

오션스 13
오션스 13

게임회사 이야기
게임회사 이야기

바람피기 좋은 날
바람피기 좋은 날

조폭 마누라 3
조폭 마누라 3

삼미 슈퍼스타즈의 마지막 팬클럽
삼미 슈퍼스타즈의 마지막 팬클럽

광기와 우연의 역사
광기와 우연의 역사

런어웨이
런어웨이

회사가 당신에게 알려주지 않는 50가지 비밀
회사가 당신에게 알려주지 않는 50가지 비밀

롱테일 법칙
롱테일 법칙

해리 포터와 불사조 기사단
해리 포터와 불사조 기사단

사소한 것에 목숨 걸지 마라 - 습관 바꾸기 편
사소한 것에 목숨 걸지 마라 - 습관 바꾸기 편

우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해
우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해

트랜스포머
트랜스포머

20대부터 시작하는 스트레스 제로기술
20대부터 시작하는 스트레스 제로기술

미운오리새끼의 출근
미운오리새끼의 출근

캐리비안의 해적 : 세상의 끝에서
캐리비안의 해적 : 세상의 끝에서

미녀는 괴로워
미녀는 괴로워

유태우 교수의 내몸개혁 6개월 프로젝트
유태우 교수의 내몸개혁 6개월 프로젝트

브레이크 업 : 이별후애(愛)
브레이크 업 : 이별후애(愛)

인사이드 맨
인사이드 맨

마키아벨리, 회사에 가다
마키아벨리, 회사에 가다

웹 2.0 경제학
웹 2.0 경제학

한반도
한반도

연애, 그 참을 수 없는...
연애, 그 참을 수 없는...

구미호 가족
구미호 가족

럭키 넘버 슬레븐
럭키 넘버 슬레븐

찰리와 초콜릿 공장
찰리와 초콜릿 공장

아파트
아파트

레전드 오브 조로
레전드 오브 조로

rss

skin by jiinny
X