totoro's world

오늘자 아시아경제에 (이런 신문이 있는지 오늘 처음 알았다)
KT의 남중수 사장님이
직원들이 메신저를 없애달라는 건의를 듣고 이렇게 얘기하셨다 하는데

관리자들이 메신저를 관리, 감시의 수단으로 사용해서 직원들을 압박하기 때문이란다.
이런 문화를 바꾸기 위해서 메신저 사용금지를 얘기하셨나 보다.

뭐랄까. KT답다.
인터넷 메신저를 그릇된 공기업의 폐습으로 바라보는 사장이나
메신저를 통해서 감시하고 몰래 무리한 지시를 내린다는 관리자들이나
없애달라는 직원들이나

처음에 기사 제목을 봤을때 보안, 업무 집중 어쩌고 그런 얘기가 나올줄 알았두만
웬 이런 엉뚱한 내용이 있을까

하도 어이가 없어서 뭐라고 쓰기도 그렇네.

우리 회사에서도 관리자들이 메신저를 통해서 자리 있나 없나를 보기도 하고
나도 가끔 회의 소집이나 출근했나 볼때 메신저를 보기도 한다.

좀 새서...
99년, 2000년에 사내 메신저 통합 얘기가 나오면서
(그때는 ICQ, AOL의 대전이었는데 네이트온이 대세라니 ... 네이트온만세
light 버전 만들어 주심 안될까요?)
메신저 사용을 해야 하나 가 이슈가 되면서
찬성은 업무 효율이 젤 큰 이유였고 반대자들은 업무의 연속성과 공유를 문제를 들었었다.

반대자들은 공식적인 업무는 시스템을 통한 공유를 해야 하고 안되면 이메일의 re, re, re를 통한 연속성을 가져야 하는데
메신저를 통해서 하면 이게 안되고 또 관리가 안된다는 이유를 들어서 없애자라고 얘길했었다.
(사실 안 써본 사람들이 이 얘길 했었던거 같은데 ... 한달 정도 지나고 이런 얘기는 싹 죽었었다.
직원들은 생각보다 똑똑해서 메신저로 진행할거 메일로 할거 다 구분해서 하더라.
똑똑한 사람들의 문제는 사람들을 정말 바보로 인식하는 경우가 있다.
다만 자기한테 말 안 거는 사람들은 우울해 하긴 하더라)

언론을 믿기가 힘들어서 .. 정말로 남사장님 되시는 분이 저렇게 얘길 하셨을까?

개발자(개발자란 말을 싫어하면서 계속 쓰게 되네)로서 일한지 10년차인데
중간에 사업한다고 외도한 시간들을 제외하면 9년 조금 넘는데
여러 회사를 다니다 보니 개발자가 다니기 좋은 회사가 있고 아닌 회사들이 있는데
지금 다니고 있는 이곳은 (2년 반정도 되고 되나 보다) 회사원으로서 다니기 좋은 회사임은 분명한데
개발자로선 그다지 좋은 회사가 아닌 듯 하다.

대기업 소속(회사를 다니는 목적이 명함을 들고 다니는 데 두는 애들도 보이고...분명 중요한 가치니 뭐라고 할 건 아니고
다만 그 브랜드를 유지하기 위해 본인이 뭘 해야 할지는 고민을 왜 안할까?)의 이점, 복리후생,
대기업 소속임에도 자유스러운 문화, 적정 수준의 연봉...

그럼에도 불구하고 개발자로서 잘하는 동료, 혹은 후배를 부르기가 조금 껄끄러운게
회사의 문화가 개발 보다는 전략, 기획, 마케팅이 우선시 되면서 개발은 뒷전이라는 점,
많은 분야의 개발이 외주 의존적이라는 점(이건 리소스의 문제기도 하지만 갔다쓰면 되지라는 소모품으로 바라보거나 별 중요하지 않아 누가해도 똑같아라고 바라보는 인식이 있기 때문이기도 하고 가장 중요한 가치를 당장의 성과에 포커스를 맞추기 때문이다. 인간이 하는건 공장의 기계가 하는 것과 달라서 일정 품질을 유지하는건 시간이 필요한데 기획은 지력의 산물이고 개발은 노가다의 산물이라고 생각을 하니...)
가장 중요한 건 구성원의 교육에 대해서 중요하다고 하긴 하지만 캐리어패스에 대한 명확한 길이 없고
특히 개발은 자기 계발에 대한 직접적인 동기 부여가 없다.
(1년에 한번이라도 몇명씩 유명 해외 컨퍼런스만 참가시켜도 이런건 좀 덜해질수도 있을텐데...
가서 책 혹은 블로그등으로 접하던 자신이 바라던 개발자, 컨설턴트를 직대 하는 것만으로도 의욕 고취가 될 수 있을텐데^^)

그러다보니 개발자들을 보면 한명한명 개인은 우수한데 시너지가 나지 않고 있고
주어진 일만 하고 그 이상의 노력같은 걸 하지 않으려고 하는 걸 볼 수 있다.

왜 이럴까?

개발직군에서 회사에 영향력을 발휘할 사람이 없기 때문이다. 라고 생각이 드니 더 안타깝고
얼마전 사장님 간담회에서 신임 사장님께서
"개발 리소스의 부족" 이라고 말씀 하셨는데 본부장들이 이구동성으로 얘기했다고
한편 동감하기도 하지만 정확하게는 이끌어갈 사람이 없는 데서 오는 부분이 더 맞을것이다.
(이 글 쓰면서 보니 이걸 말씀 하신 걸 수도...우수 리소스 얘기하시고 그러셨으니...
우수한 리소스가 오려면 문화부터 바껴야지. 아 저긴 저런데구나. 뭐 해 볼 수 있겠는데 라는 생각이
들어야 오지. 돈 몇푼에 개발자로서 우수한 리소스가 움직일까?
사람은 나름 자존심과 자기 가치로 움직이는 건데...)

왜 개발자들이 이거 하면 뭐합니까? 새로운걸 해보고 싶어도 얘기할 수 있는 사람이 없어요.
이거하면 제가 뭐 칭찬이라도 받을 수 있을까요? 얘기해봐야 소용없어요. 납기만 맞춰야죠.

이렇게 얘기하는 걸 먼저 타파하는게 중요하다.
본인들이 잘 하는 걸 보여줄 수 있는 걸 만들어줘야 하는데 ...
상호 교류가 활발하고 기술에 대한 검토가 이루어지고 숙제가 많다.
(플랫폼부터 통일해야 그나마 시너지가 날텐데...)

개발자가 관리자가 되면서 본인들에게 주어지는 미션이
당장의 미션, 일정 준수가 되다 보니 우수한 인력들이 관리를 함에도 불구하고
이러한 것들이 멀어지나 보다.

회사 핑계를 대고 있는 난 팀원들에게 뭘 줄 수 있을까?
생각해보니 회사에 한 번이라도 OOPSLA, Javaone 보내겠습니다. 이런 얘기를 한적이 없군.
받고 싶은 교육을 잘 찾아봐라라는 얘긴 했지만 넌 이런 분야로 이걸 쭉 해주고 우리한테 이런 가치를 줬으면 해
라는 얘기도 ...

반성하자.

연초인가 ? 기억이 안나는데
사장님께서 경영관 관련해서 구성원간의 자율적 합의에 의한 의사결정 이런 걸 얘기하셨던 것 같은데
그때 "정말 저렇게 해서 잘 될거라고 진심으로 생각하시는 걸까?" 라고 생각했었다.

역사의 발전이 탁월한 독재자에 의해서 이뤄졌다고 생각했었던 고등학교 시절과
토론에 익숙하지 않은 교육을 받고 자란 대한민국의 회사원이
서로다른 상황, 직급, 욕구가 다른 상황에서 합리적인 결론을 도출하는 것은 불가능 하다라고 생각을 했었다.
그래서 뛰어난 리더가 이끄는 것이 조직 구성원에게도 오히려 편한 방법이고
구성원들이 바라는 것일거다. 라고 생각을 했었는데...

정말 그럴까? 라는 생각이 들었다.

전체 사회를 보면 자유주의/민주주의라는 것이 지금 나은 체계라는 것이고
이게 회사라는 사회도 다르지 않을 텐데 결국 회사도 그렇지 않을까라는 생각이 들었다.
뛰어난 독재자가 나올 확률은 높지 않고
우리나라에서 제대로된 기업 활동이 이루어진 시간이 짧고
또 인터넷 기업의 업력이 정말 짧은 것을 보면
아직 시간이 필요한 과정이 아닌가 한다.

팀원들에게 물어보니 Top-Down 식의 전달이 아직 편하다는 의견이 많네.
기술쪽은 Bottom-Up이 되야 하는데 ... 시간을 가지고 기대를 해봐야지

난 개발자다. 정확하게 이제는 서비스개발자면서 매니저의 길을 밟고 있는 개발자라고 하면 될 것이다.
개인적으로 사람들의 캐리어에 대해서 신경을 쓰는 편이라
열심히 해야지 그래야 뭘 하고 뭘하고 하지 않겠냐? 공부하자. 뭘하고 싶은지 찾아라...라는 얘기를 많이 하는데
돌아오는 답이
'몇년이나 하겠어요', '뭐 한다고 돈 버나요?', '몇 년 하다가 장사해야죠', '공부해서 뭐가 되는데요?' 라는 대답을 들을 때가 많다.
물론 성격이 뭐 같아서 약간의 버럭을 섞어서 뭐라 하는데...

우리 회사가 개발자도 많고 볼때 우수한 인력들도 많은 편인데
외부에선 절대 인정받지 못 하고 개발자들이 보람도 못 느끼는 상태인데 ...
매니저의 길을 걷고 있는 상황에서 안타깝다.

잘 하는 친구인데 개발에 대해서 애정을 못 가지고 IT는 여튼 싫어요 하고 떠나던가
아님 다른 회사를 찾아서 가는데...

IT가 싫어요 하는 이유는
IT가 노동강도도 세고 근무환경도 열악한 편이라고 인식되고 있고
보통 구글이나 SI회사처럼 개발을 가지고 먹고 사는 회사들이 아닌 점도 있고(우리 회사는 반정도 차지 한다고 보는데 위상은 30%정도라...)
비젼이 없는 점 이러한 이유들이 가장 클텐데
우리 회사에서 떠나는 이유는 ... 마지막 개발자로서의 비젼을 볼 수 없다는 점이 아닐까 싶다.

개발자는 캐리어를
아키텍터
설계전문가
서비스 전문 개발자
에반젤리스트
고급개발자
컨설턴트
매니저
이런 역할들에 대해서 연차가 차갈 수록 자기가 해야 할 롤모델을 정하고 가야 할텐데

현재 우리회사에서는
개발자 --> 파트장 --> 팀장 이러한 management의 path만 존재하는 관계로
개발자가 비젼을 가질 수가 없는 것이 개발자들이 회사를 떠날 수 밖에 없게 하는 가장 큰 이유로 생각된다.

이런것들을 제대로 해주게 하기 위해선
리소스의 여유가 가장 중요하고 리소스가 여유가 있다면 잘 할 수있으려면
플랫폼도 어느정도 대세 플랫폼으로 통일화 되는 것이 좋을 듯 한데...
(개인적으로 랭귀지 하나, 플랫폼를 잘하는데는 최소 몇년의 시간이 필요하다고 본다.
Copy&Paste야 ... 몇개월이겠지)

그리고 무엇보다 중요한게 의사결정권자들이 이러한 캐리어패스 관리에 신경을 쓰는 것이다.

분류가
DB개발
웹개발
App개발
SE
이게 뭐야 이게...회사내에 몇백명의 개발자가 있는데...

하다못해 기술 등급을 매기던가 (이 얘기했다가 팀원들에게 맞을뻔했다. 무슨 우유냐구)
1등급 웹개발자...이상한가?

http 스펙을 보다가 찾게된 블로그인데 웹페이지 로딩에 대한 내용을 잘 정리해 놓았다

아래인데 함 들려볼 필요가 있다.

http://www.die.net/musings/page_load_time/

우선 아래 내용을 써 놓았고

• IE, Firefox, Safari 는 HTTP Pipelining 을 기본적으로 제공해 주지 않는다. Firefox에선 세팅을 바꿀 수 있다.
• HTTP/1.1 권고안에서 한 도메인 당 커넥션은 2개로 제한한다. --> registry 수정을 통해서 변경 가능하다
• Upload와 download 속도가 다르다. --> ADSL같은 경우 특히 upload가 작죠.

에 대한 내용이 나와 있고,
아래 내용이 있는데

1. 외부 Object 에 대한 keep-alive 사용, 정확하게 이 말이 이해가 안되는데 (Turn on HTTP keepalives for external objects.) 3-way handshake를 줄일 수 있다는 내용인데...내용 자체는 keepalive를 당연히 5~10sec정도를 줘야 connection 트래픽을 감소 시킬 수 있다는 뜻. 적용하는게 퍼포먼스 측면에서는 좋으나 사용자가 정말 많은 사이트라면 고민을 해봐야 한다.
   
2. external object수를 줄여라. 당연한 얘기인데 ... 이번에 뼈저리게 느낀건데global reference가 되는 관계로 js, css include의 수를 줄이고 (하나 아님 2개로) request overhead 로 인해, 하나의 큰 파일이 두개의 작은 파일보다 더 빠르게 로딩된다. --> 이 말을 잘 봐야 하는데 대체가 가능할때 얘기다. 개체수가 200개 이상이고 여러 이미지를 묶어서 하나로 하는게 가능하다면 차라리 큰 게 낫다는 얘기다. CSS-base Design, CSS sprites등을 이용해 이미지 개체수를 줄인다.
3. 위 HTTP/1.1 권고안에서 한 도메인 당 커넥션은 2개로 제한한다. 의 내용을 보완하기 위해 버추얼 호스트 혹은 도메인 추가를 이용해서 여러개의 도메인을 사용하면 파이프라인 효과를 볼 수 있다.
   * 이 방법은 여러 이슈가 있을 수 있을텐데...임계치를 잘 봐야겠다.
   웹서버 CPU증가, DNS lookup 의 수 증가(이에 따른 트래픽)--> 개체수가 정말 많은 페이지에서 유용할 것이다. 또 유념할 것이 참 당기는 내용이긴 한데 yahoo의 테스트에선 파일 사이즈가 크다면 두개 정도가 적당하다고 테스트가 되어 있다. http://yuiblog.com/blog/2007/04/11/performance-research-part-4/ --> 공동구매 페이지 정도가 적당할 것으로 보인다.
4. stylesheets, javascript, images를 사용자 브라우저에 캐쉬 시켜라.
   변경될 경우를 고려해 디렉토리를 날자나 버젼별로 구분해서 관리하라. --> http://example.com/build/1235/logo.gif 관리가 만만치 않다. --> 정말 중요한 내용이다. js, css, image의 변경에 대한 지침을 가져가는 건 정말 중요하다. 다음에 웹을 만든다면 반드시 고려할 것이고 css, js는 gzip도 적용해야 한다. 도메인도 나누는 것이 좋겠다.
   이미지 url 에 쿼리 파라메터를 사용하지 마라. --> squid cache 서버가 인식하지 못 한단다.
5. 초기 메인 화면이나 많이 쓰이는 페이지에 대해서는 GET방식을 사용하고 정적페이지에  Last-Modified, ETag 를 이용하여 cache될 수 있도록 한다. --> 은근히 고민이 되는 부분이 있다.
6. HTTP request사이즈를 줄여라. cookie 밖에 없겠지. 쿠키 줄여야지. 별거 아닐 수 있다고 생각하겠지만 이미지가 캐싱이 안되어 있다고 하면 혹은 304라도 개체수만큼 날라간다.
7. http response도 줄여라. gzip의 활용. (html, css, js)
8. CDN의 고려. 당연히 좋을 수 있지.
9. 아파치 성능 고려.
   

좋은 내용이다.

기업용 App.이나 대형 사이트개발을 개발을 하게되면
필수적으로 배치 개발이 필요한데 ...

다양한 방법들로 수행한다.

- DB 배치 (job 등)
- 시스템 스케줄러 : 리눅스라면 cron, at / 윈도우 스케줄러
- thread
- daemontool

각자 용도에 맞게 DB안에서만 도는 것이라면 DBMS에 종속되는것이 제일 편한 것 같고
App에서 도는것인데 특정 시간에만 돌 필요가 있는 것이라면
cron, at
계속 떠 있어야 하면서 지속적으로 돌아야 하는 것은 supervise가 있는 daemontool
....
이러다 보니 배치 관리가 어렵게 된다.
한눈에 보기도 어렵고 로깅 관리도 어렵고

quartz라는 넘이 cron을 대체하는 역할을 하기도 하는데 ... 적당히 WAS랑 섞으면 CRON, DAEMONTOOL 정도 합친 역할은
해줄 것 같다.

SPRING에서 배치를 준비한다고 하는데
기능이 다음과 같단다.

XML을 비롯한 다양한 파일 포맷 지원

실패후 자동 retry

모니터링과 동작을 위한 job control 언어 지원

실행 상태, 통계정보를 실시간 또는 완료후 확인

배치 작업을 실행하는 다양한 방법 지원 - http, script, incoming message 등

OLTP시스템과 concurrently하게 실행

여러개의 tx 리소스를 사용

로깅, 리소스관리, 재시작, 스킵 등의 핵심 배치 서비스 지원

스펙자체가 많이 이런 작업을 해본듯한데(그 회사에 들어간 개발자들이 기업 App. 경험이 충분한건지...)
반갑기도 하지만 요즈음 Spring이 java전체에 끼치는 영향이 너무 크다는 생각이 든다.

스프링배치 : http://blog.interface21.com/main/2007/05/07/spring-batch/ 

REST(Representational State Transfer)란 용어를 요즈음 많이 들을텐데 ...

이걸 통해서 웹에 대해서 다시 한 번 생각을 하고 우리 App개발에서 되집어볼 요소를 생각해볼 수 있었음한다.

REST란 요즘에는 XML과 HTTP를 사용하는 웹기반인터페이스를 지칭(REST의 원칙을 따르는 웹서비스 혹은 URL구조)하는 것으로 굳어졌지만 원래는

웹과 같은 네트워크 시스템을 위한 원칙을 의미한다.

REST란 말을 그대로 해석한다면 구체적인 상태 전이로 할 수 있을텐데 이것은 웹시스템을 떠올리게 되면 네트워크가 있고

특정 웹에 사용자가 링크를 선택하게 되면 다른 페이지로 전이되는 모습을 설명한것이다.  (요청 --> 네트워크 --> 웹페이지 --> 전이 --> 다른 페이지)

REST에서 정의하는 주요 원칙은

- 클라이언트 서버(웹으로 보면 브라우저 / 웹서버) : Stateless

- 보편적인 인터페이스 (HTTP Method로 정의 된다. GET/POST/DELETE/PUT... )

- 자원은 URI를 통해 유일하게 지정된다.

- 각 자원들은 URI를 통해 서로 연결될 수 있다

 이 원칙들이 뭐 새로운 건 아니고 웹 자체가 만들어 질 때 설계가 된 것이고 이걸 잘 재정의한게 REST라고 할 수 있는데 몇가지 되집을게 있는데

REST에서 stateless 라면 즉 session, cookie는 사용하지 않는 것이 원칙이다. 이건 REST를 이용한 OPEN API에서 인증키라는 넘으로 표현한다. (매번 인증)

또 하나를 더 보면 웹에서는

GET : URI에 있는 자원 획득, select

POST : URI에 자원을 수용하도록 요구, insert

DELETE : URI의 자원 제거 , delete

PUT : URI에 자원을 위치 , update(어째 파일 업로드가 확 오긴 하지만...)

로 처음 디자인을 했는데 뭐 CRUD에 대한 내용에 대한 정의니까 당연한 디자인이겠지만 브라우저에서 GET/POST만 지원하는 것은

이것만으로도 충분하다고 생각도 된거기도 하고 GET은 조회, POST는 CUD의 역할을 한다고 디자인을 한 것이다.

* 조회하는 성격의 URL을 POST방식으로 하는 것은 웹의 디자인에도 유배될뿐만 아니라 stateless와 원래 용도를 이해한다면 브라우저에서 '만료된 페이지입니다'를 뿌리는 이유를 이해가 될 것이다.

GET의 제한이 있다고 ...조회용 URL을 POST로 한다는 것은 웹디자인상 편의상 규약상 하지말아야 할 일이고 가급적 나머지 등록 등은 POST로 해주는게 좋은 것이다.
전에 내가 이 얘기를 했을 때 누가 나한테 'insert후 결과값을 얻어서 POST 던져서 뿌려줘야 결과 처리 페이지는 어떻게 해요?' 라고 물은 적이 있었는데
당연히 key만 받아서 다시 얻어오는 것이 원칙이다. 주문 완료페이지는 주문 번호만 넘겨서 받아오던가...

(싸이마켓 초창기에 이렇게 되어 있는 것들이 많았지. 실패사례 중 하나)

이제 REST를 stateless와 Uniform interface라는 측면에서 구체적으로 보면서 RESTful App를 보면 다음과 같이 과장해서 정의를 할 수 있는데

HTTP method인 GET/POST/DELETE/PUT 와 리소스에 대한 URI의 결합으로 App의 동작을 정의하는 스킴으로 얘기할 수 있다.

예를 들면 만약 우리가 상품번호가 100번인 상품 정보를 상품정보를

조회 /item/item.do?method=doItemDetailView&goods_no=100 --> REST로 한다고 하면 /item/100 을 GET으로 요청
삭제 /item/item.do?method=doUpdateItem&goods_no=100 --> /item/100 DELETE으로 요청

이런식인데

언뜻 보면 URL의 의미가 명확해지는 듯 하기도 하고 모델만 잘 정의하면
(만약 신규 업무가 나온다고 하면 그 리소스에 대한 정의만 하면 되니까
e.g. 상품 일시 중지는 freeze라는 걸 정의하고 이런식으로 /item/100/freeze를 POST로 날리는 식으로, 삭제는 /item/100/delete 이렇게)
설계도 편하고 너무나 외부에 hackable한 제공을 해 줄 수 있게 보여쥴수 있죠.
(요즈음 블로그 URL을 보면 잘 따르고 있죠.
이 잘정리된 URL이 참 의미가 있는데 ... 웹이 링크로 움직이는 시스템이니까 더더욱 그런데
홈2의 게시물의 주소복사를 하면 이런식으로 되어있긴 한데...눈에 바로 보이는 링크는 이게 아니라서 -한번이라도 덜 타게 하려고 의도적으로 한건지는 모르겠지만
...요즈음 웹을 이렇게 만들면 욕먹는다는 거...우린 더 심하니까 할 말은 없고)

많이 샜는데 REST를 따르는게 많은 장점이 있을 듯 한데 적용하기를 가로막는 단점들이 있는데
일단 브라우저가 GET/POST외에 put/delete는 지원하지 않는다는거와 App의 복잡한 업무가 GET/POST/PUT/DELETE로 정의가 다 될수가 없기 때문에
당연히 custom method에 대한 리소스를 지원해야 하는데 보면...
아까 상품삭제를 /item/100 delete로 요청하는걸 /item/100?method=delete 로 한다고 하면...후자가 오히려 명확하게 보이기도 하고
웹 App의 복잡한 다 일일히 모델을 만들어줘야 하는데 이 작업이 비용이 많이 드는 작업이 되기 때문에 REST의 장점이 오히려
손실이 되기도 한다.

REST스런 App를 전면적으로 만드는건 참 힘들 수 있는 일이긴 하지만 분명
REST스런 App를 만들려고 하는 것은 장점이 많을 수 있고 설계를 하는데 유용한 컨셉이 될 것이다.

설계시
* unique URI
 - 리소스에 대한 정의(item, cart, coupon) + action(get/post/delete/put을 염두에 두고)
 - 설계한 모델의 리소스의 제대로 된 액션 정의. 만약 method가 getitem 인데 이걸 파라미터로 분기해서 다른 액션을 취하게 하는 건 틀린것이다.
* hackable URI
를 염두에 두고 하면 좋을 것이다

다음은 아마존의 REST방식 OPEN API중 장바구니 추가 예제인데 이걸 보면 좀 더 명확해질텐데
http://webservices.amazon.com/onca/xml?Service=AWSECommerceService&SubscriptionId=[Your
Subscription ID
Here]&Operation=CartAdd&CartId=[A Cart
ID]&HMAC=[An HMAC Shopping Cart
Token]&Item.1.ASIN=[An
ASIN]&Item.1.Quantity=1

여기서 subscriptionID는 --> 로그인을 위한 key(stateless)
Operation=CartAdd --> 리소스에 대한 action 정의

결과는 xml형식으로 return 된다.

아마존의 매출의 40%이상이 OPEN API에서 나오고 SOAP, REST방식으로 제공되는 OPEN API중에서
85%이상이 REST로 제공되고 있다.

국내에서는 옥션, GSeshop등이 SOAP으로 제공하고 있으나 별 의미 없는 상태이고
우리도 판매자 연동쪽에서는 OPEN API 제공 요구가 꾸준히 있다. 얼른 해야 할텐데...

참고 URL
http://www.awszone.com/
http://openapi.naver.com/index.nhn
http://www.restlet.org/ : Lightweight REST framework for Java

이 회사로 옮기고 나서 젤 많이 느낀게
'참 착한 사람이 많은 회사구나'였다.

참으로 착한 대화들과 격려...열심히 착하게 일하는 사람들.

참 좋다 생각했었는데 (내가 안 그런관계로...사실 좋다 생각은 안했다. 이러고 잘되나? 희한하네 했지)

내가 생각할 때 회사에 착한사람은
조직의 내/외부에 기여하는 사람인데 ... 이 회사의 착한 사람은 

- 실망스러운 output을 보고도 수고했다고 하는 사람.
- 착하게 살면 회사에서 보상을 해줄거야라고 믿는 사람.
- 실력없고 일 못하는 사람이 회사에 계속 다니는걸 보면서도 쯧쯧되면서도 자신은 부러워 함.
- 별 의견없이 아무런 얘기도 안 하는 것이 착하다고 믿는 사람.
- 성과를 내거나 잘하는 사람을 보면 여기서 저런거면 온갖 나쁜 짓을 다 한게지...라고 생각하는 사람.
- 위의 생각들을 다들 하고 있겠지 라고 생각하는 사람.

...정리하자니 잘 안되네...한마디로 일은 못하면서 이것저것 일 외에는 관심 많고 착한척하는 사람을 얘기한다.
그리고 판에 박힌...멘트들

진짜 ... 겉으론 착한 사람, 착한 조직인척하는 게 여긴 너무 심하다.

개인적으로 이런 현상을 매우 싫어하는데
결국 멍청한 직원들만 대량으로 양산할 뿐만 아니라 이런 직원들이 안정적으로 오래 근무하게 되는 현상을 보게 될때
착하고 안착하고 무능하고 유능하고의 구분도 없어지게 되고 세상이 불공평한건지.... 어떤건지...
결국 착한 직원만 남게 되고 나쁜 직원은 다 나가겠지.

딱 보면 공무원 조직이 착한직원의 대표적인 예인데 ... 여긴 거기랑 정말 다른 문화고 열심히 하는 문화이긴 한데...
어찌 저찌 칭찬 문화가 이상하게 변질되면서... 이렇게 되버렸다.

아니라고 하고 이렇게 우기는 사람. 버럭 대는 사람한테 동료들이 칭찬하기는 어렵기 때문일텐데...

조직내 직무분리를 고민을 많이 하게 되는데 ...
직무분리를 고민하게 되는 첫번째 이유는 아무래도 생산성 향상, 개인의 캐리어패스, 전문가 양성 차원일텐데
이게 참 어렵다는 생각을 많이하게 된다.

돈을 벌 수 있는(여러의미다...) 일이 되려면 남들이 못 하는 일을 해야하기도 하지만
그 전에 일자리가 나와야 하는데 어느정도 능력을 가지기전에 직무를 분리하는게 부담이 된다.

만약 신입사원이 들어왔는데 웹개발을 UI개발과 Logic 개발로 2개의 직군으로 나눠서 업무가 주어진다면
그 중의 하나를 시켜야 하는데 하나만 가지고 이 친구가 가치를 가질 수 있을까?
물론 직무순환이 필요한 순간이 올테고 이게 잘 이뤄져야 할텐데 ...
어느정도 잉여 인력을 갖춘 조직이 아닌 이상 직무순환에 대한 비용 지출이 항상 걸림돌이 된다.

소팀을 이루어서 (한 4~5명?) 프로젝트 혹은 운영을 진행한다고 하면
만약 그 구성원이 UI개발, 로직개발, DB개발 이렇게 나눠져서 하는거랑 전 구성원이 이걸 다 할 수 있는 구성원인거랑
어떻게 퍼포먼스가 날런지... 전자일까? 후자일까? 아무래도 후자가 낫겠지. but
후자가 낫겠지만 이렇게 되면 자신의 업무만 바라보게 되는 업무 분리(지금 우리 조직이다.)가 되기 때문에
총괄적으로 바라보는 view가 줄게 되고 기술적으로도 전문성이 떨어지게 되는데 ... (기획자 의존적이 될 수 밖에 없고.)

이리저리 생각해보면

직무 분리의 장점
- 전문성
- 생산성 향상
- 품질의 향상을 가져올 수 있음.

직무 분리의 단덤
- 커뮤니케이션 단절/비용 지출
- 병목 발생의 Risk (상당히 위험할 수 있다)
- 관리 비용

결론적으로 ...
현상황에서 보면 완성적 조직으로 가려면 직무분리로 가야 한다.
다만 개발자 같은 경우 각 직무에 대한 경험 혹은 지식을 어느정도 가져갈 수 있도록
직무 순환이 이뤄져야 한다. (적정한 인력구조가 필요하다는 얘긴데...)

* 가장 큰 문제는 .... 순환이든 커뮤니케이션 문제를 줄이던 둘다 대화가 쉽게 이뤄질 수 있는
분위기와 수단인데...

UI개발 - HTML, CSS, Javascript         
Flash 개발
SE
DBA
DB개발
배치 - Core 개발
로직개발
....
더 있을라나....