Reactor 패턴

- 어떠한 이벤트가 발생하면, 이곳으로 알려달라는 방식.

- 윈도우 메시지 핸들러처럼, 특정 이벤트가 발생한다면 통지 받겠다는 방식.


Proactor 패턴

- 특정 작업을 시키고, 그 작업이 완료되면 알려달라는 방식.

- IOCP에서 Completion Port가 이 방식을 취하고 있다.



얼추 비슷한데, 구현에서 차이점이 명확해진다.


Proactor는 작업을 시키면서 콜백함수를 직접 넘김으로써 구현되고, Reactor는 디스패쳐를 구현하는 구조가 일반적.


Reactor 패턴 사용시에는 디스패쳐를 통함으로써 스팟 포인트가 발생하게 되는 단점이 있다고 보면된다.


이에 비해 Proactor는 명령을 내린 작업에 대해서만 통지를 받게 된다.


IOCP의 예를 들면, 내가 물려놓은 소켓에 Recv 이벤트가 발생했다고 해도, WSARecv를 걸지 않으면, 해당 이벤트가 발생했는지 여부에 대해 통지를 받지 않음을 의미한다.


이는 이벤트 폭발로 인한 부하 발생이나, 스팟 포인트를 감소 시킬 수 있는 테크니컬한 멀티 스레드 프로그래밍이 가능하게 하려면 Reactor 패턴보다는 Proactor 패턴이 유리하다는 것을 의미힌다.



Reactor 패턴은 디스패쳐를 거치기 때문에, 직렬화에 유리하긴 하나 이 디스패쳐가 스팟 포인트가 되는 것이 일반적이란 단점이 있다. (물론 그렇지 않게 구현 할 수 도 있으나, 그렇게 멀티스레드 로직을 수행하기엔 예외 상황이 지나치게 커질 위험이 있다.) 


stateless 하게 구현하기 위해선 proactor 기반의 처리 구조로 구현하는 것이 좀 더 유리하다고 볼 수 있다. (stateless하게 만들 수 있다면, reactor패턴을 쓴다고 해도 스팟 포인트를 줄일 수 있긴 하다.)

'Software Engineering > Design Pattern' 카테고리의 다른 글

Reactor 패턴과 Proactor 패턴  (0) 2014.08.05
Design Pattern Quick Reference  (0) 2011.02.10
데코레이터 패턴 (Decorator)  (2) 2008.02.09
커맨드 패턴 (Command)  (0) 2008.02.09
플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
Posted by 엘키 엘키

댓글을 달아 주세요

내 첫 IDE는 MS-DOS용 터보-C 2.0이다.


vi 정도는 아니었어도, 윈도우 기반 요즘 IDE와는 비교도 안될만큼 불편했다.


그런 환경에서 Visual Studio 5.0을 썼을때의 환경은 말그대로, 환호가 절로 나왔으며, MFC의 App Wizard는 신이 내린 하사품 같았다.


그렇다보니 GUI환경에 대한 동경은 갈수록 커져만갔을 뿐... 글씨만 줄창 보게되는 CUI (Console User Interface)에 대한 내 이미지는 "직관적이지 않고 어렵다" 였다.





알바 경험, 외주 경험을 다 제끼고 나면 나는 온라인 게임만으로 일해왔다.


내가 상업적인 프로젝트에 외주가 아닌, 직원으로 일한 것은 싸이미디어사의 믹스마스터였다.


당시 서버는 리눅스 서버였는데, 클라이언트 프로그래머였던 나로썬 점검시 심심하다고 나를 부르는 SE형 옆에서 서버 20대가량을 제어하는 터미널 창만 봐도 눈이 휘둥그레 졌었다.


여러개 떠 있는 세션에 같은 명령을 보내는 스크립트로 패치하시곤 했는데, 내 입장에서는 굉장히 신기한 작업이었다.


물론, 그저 신기했을 뿐 딱히 멋져보이진 않았다.




그러던 내가... 그 일로 얼마 지나지 않아 어쩌다보니 서버프로그래머가 됐다.


서버 프로그래머가 되고 서비스를 하다보니... 하... 먼놈의 관리해야 될 머신이 이렇게 많은겨....-_-


관리할 머신의 수는 팀마다 달랐고, 국가마다 달랐지만 최소 10대 가량은 관리해왔다고 볼 수 있다.



내 로컬에서 개발 머신까지의 적용은 그나마 괜찮다.


문제는 대부분 Local -> Develop -> QA -> Live 이런식으로 deploy 되는 과정에서, 실수가 유발됐다.


사실 점검은 국가마다 다르지만, 대게 새벽시간에 이루어지곤 한다.


유저가 가장 적은 시간대를 선택하다보니 그렇게 되기도 하고, 해당 국가의 시간에 맞추다보니 그렇게 되기도 하고.


그런 시간에 정신이 말짱해, 모든 프로세스를 실수 안하는 사람이 있나?


만약 있다해도 적어도 난 아니다.




작업은 가능한한 자동화 되어있어야했고, 그를 위한 서버 제어 시스템은 필수 였다.


내가 본 첫 서버 제어 시스템은 네X위즈사의 피X 서버 제어 시스템이었는데, 실질적으로 내가 사용한 것은 아니라 대략의 기능들과 어떠한 느낌인지만 알 수 있었다.



해당 서버 제어 시스템으로 관리되던 것은, 내가 클베때부터 합류했던 프로젝트인 네오액X의 포키포X인데, 


당시만해도 서버 프로그래머가 된지 얼마 되지 않았고, 업무량 자체가 절대적으로 많아 생각의 폭도 좁았지만, 그런 고민을 할 여유가 많지 않았다.


헌데 그렇게 바쁠 수록 실수는 나오기 마련.


패치할 서버를 FTP에 올려놓고, 패치 메일을 빼먹는 다거나, 업로드한 파일 경로를 잘못 메일에 기록한다거나...


특히 긴급 패치에 새로 나온 바이너리를 안올리고, 테스트하던 바이너리를 올린다거나 하는 등의 다급할때의 실수는 대부분 수작업으로 인한 파생 효과였다.




그래서 필요했던 것은 두가지였다.


1. 빌드 -> 배포까지의 자동화.


2. 배포 -> 실제 패치까지의 자동화




이렇게 되고나니 한결 편하게 패치를 진행할 수 있다.


서버가 몇대건 간에 말이다.



여기서 추가적으로 필요한 작업이 있다.


바로 서버 모니터링. 서버 제어 시스템의 핵심중 하나다.


서버가 죽었는지, 제대로 떴는지 등의 상태 체크를 모니터링 업체에만 맡길 순 없다. (실제로 모니터링 업체에 맡기는 경우도 드물고)



이런 기능을 개발하면서부터, 개발자의 시간을 아끼기 위해, 또 실수를 줄이기 위해 선 시간 투자에 대한 눈을 조금 떴다고 할까?


효율성이 떨어진 자동화나, 코드 생성기 작업도 없었던 것은 아니지만, 많은 작업들이 결과적으로 시간을 아꼈다.


애초에 덜렁대고 급한 성격인 나로썬, 급할 수록 돌아가지 못하다보니 잔실수를 자꾸 하게 됐었는데, 이를 자동화로써 해결하면서 큰 이득을 보게 됐다.


사실 과거에는 이런 솔루션 파는 회사 없나라는 고민을 좀 했었다. 범용 서버 제어 시스템...충분히 있을법하지 않은가?


요즘 보면 모바일 서버가 웹 기반으로 돌아섰고, AWS 등의 클라우드 기반 서버를 쓰다보니 자동화가 강제되는 면까지 있어, 이를 해낸 여러 사례가 들려오고 있다.


특히 cookbook같은 개념도 머릿속으로 그려봤던 개념이, 실제로 많이 실용화 된 것을 보자니 내가 해온 것보다 적은 공수로 실시간 서버 추가/제거를 해내는 모습을 보면 부럽기도 하면서, 뿌듯한 면도 있다. 당연히 앞으로 배울점도 많고.



다른 자동화에 대한 의지를 가진 분들의 생각은 다는 모르겠다만, 적어도 내 기본 전제는 "내가 편할려고", "똑같은 작업 여러번 하기 싫어서"다.


내가 당장 사무실에 없다해도, 혹은 누가 해도 되는 일로 만들기 위해서이기도 하고.


자동화도 하다보니 좀 늘더라. 특히 스크립트 언어를 적극 사용하니 좀 더 수월하기도 하고.



서비스 질이 갈수록 좋아지고 있다. 클라우드 서비스를 기반으로한 무인 원격 서버 증감도 이뤄지고 있더라.


요즘 트렌드를 보자면, 서버 제어 시스템을 앞으로 직접 구축하거나 보완하는 일은 많진 않을거라 예상은 되지만.... 서버 프로그래머로써 3번째 회사에서, 3번의 서버 제어 시스템을 담당 해본 입장에서, 이런 시스템을 구축하면 할 수록 업무 시간을 벌 수 있다.


node.js 등의 리눅스 기반 웹서버로써 구동하고자 하는 많은 회사들도 그렇게 하고 있다는 얘기도 들려오고 있고. 내가 한 많은 작업들이 AWS등에선 기본 지원하는 기능이기도하다.


조금 허탈하기도 하지만, 뭐 기술이란게 다 그런거 아닐까? 여하튼 좋은 모양새로 업계가 발전하고 있는것은 아주 맘에 든다. 



몇몇 분들을 보면 아쉬운 것이... 어째서 코드의 중복은 싫어하면서, 작업의 반복은 수긍하고 익숙해짐으로써 해소하려하는 걸까? 작업의 반복도 충분히 간소화하고 제거할 수 있다. 


개선할 수 있는 많은 것을 개선하고, 낭비되는 시간을 줄여야 진짜 즐거운 작업을 할 시간을 벌 수 있다. 우린 엔지니어다. 기술로 커버할 수 있는 것이 아주 많다. 조금씩만 더 효율적으로 일하도록 노력해보자.

Posted by 엘키 엘키

댓글을 달아 주세요

서버의 부하를 줄일 수 있는 부하 조절 정책으로, 블리자드의 디아블로2팀이 조치한 방법이 어떤 방법인지 알아보자.

1. 서버에 요청하는 액션이 일정 횟수 이상 반복되면 Trouble 유저로 판단.
* 방 입장/퇴장 반복
* 방 생성 후 일정 시간 이내에 빠른 퇴장
* 로그인/로그아웃 반복


2. Trouble 유저 (계정)로 판단시 해당 캐릭이 사용된 IP를 차단.
* Trouble 유저가 일정 시간내에 다른 IP에서 재사용된다면 그 IP도 차단.
* 한번 Trouble 유저로 인식되면 문제가 된 Trouble 사유가 아니더라도 (예: 방생성/퇴장 반복) 로그인만으로도 IP차단.


3. 빠른 방생성 입장/퇴장의 경우 ProcessID도 인식하는 것 같음. (정확하지 않음)
* 배틀넷 로그아웃후에 로그인을 통해 방 입장/퇴장 반복시에 간격이 짧으면 렐름 다운이 되는 경우가 발생.


4. 유저가 적은 새벽시간이나 낮시간에는 제약이 약한편
* 분명히 낮시간에는 잦은 반복과 더 빠른 반복도 유연하게 넘어갔었음.
* 유저가 훨씬 많은 시간 대에 같은 시간단위로 시도했음에도 Trouble 유저로 판정된다. (판단 규칙이 강화됨.)


5. 차단된 IP나 계정을 일정 시간 이내에 사용하면, 블럭 시간이 늘어남.
* 블럭되었다면 해당 계정을 묵혀두는 것이 좋다. 유동 IP의 경우는 IP를 재발급 받아서 시도 할 수 있었는데, 계정에 대한 제제가 들어가 있는 상태라, 바로 바뀐 IP도 블럭되었고, 블럭 시간은 계정단위로 지정이 되어있는 것 같다.
* 일반적으로 알려진 시간 (1시간)동안 사용하지 않았어야 했는데, 사용했더니 블럭 시간이 2배로 늘어났음. (정확치는 않음)
* 기본적으로 계정에 대한 블럭 개념 + IP에 대한 블럭 두가지 제약이 동시에 걸리는 구조로 예상됨.


6. 기타 사항
* 디아2의 경우 월간 사용료나 캐쉬템을 파는 게임이 아니기 때문에 강경한 정책을 사용할 수 있는편.
* 실제로 핵툴 유저 등 비정상 유저 계정 블럭은 CD-KEY단위로 이루어짐.
* 즉시 제제가 없다는 점은 좀 아쉽다.
* 서버 유지비를 줄일 수 있는 강경한 정책을 유지할 수 있는 장점이 있는 반면 사용자들이 불편한 점도 많이 갖고 있다. (디아2 배틀넷 초기에는 이렇지 않았음. 초기의 길고 잦았던 렐름다운을 겪고나서 취한 방법이 이 방식이라 생각됨.)

Posted by 엘키 엘키

댓글을 달아 주세요

1. 개체 단위 lock.

개체 수와 종류가 늘어날 수록 헬.

dead-lock 위험성도 매우 크다.

상위 개체 단위로 lock을 잠글 수도 있는데, 이마저도 상호 연관 이벤트가 늘어나면 헬이다.

사실 lock만으로 멀티스레드 로직을 구현한다는 것은 사실상 불가능에 가까운 복잡도를 만들어 낸다는 것을 이미 여러 프로젝트가 증명했다.


2. 데이터 사본 연산

그룹마다 (방 혹은 채널, 존) 스레드를 따로 생성하고 데이터 사본으로 연산 한 후 연산 결과를 이벤트로 다시 던져,  다음 턴 수행 전에 적용하는 방식이다.

기본적으로 턴(프레임이라 불리기도 하는) 단위를 잡고, 해당 단위마다 로직이 돈다는 것을 전제로 삼을 수 있어, 여러가지 계측의 기준점이 되기도 한다.


여러 그룹에서 동시 다발적인 변화가 발생해, 데이터 변경이 일어난다 해도 변경 사항들을 긁어와 턴 마다 적용하기에 문제가 생기지 않는다.

주로 응답을 message 개체로 변환해서 받기 때문에 message queue를 푸는 동작이 순서가 필요할 경우, 싱글 스레드로 풀어서 적용해도 된다.


주의 사항은 데이터가 클 경우 사본을 생성하는 과정이 무거울 수 있다는 점.

이런 과정도 delta를 잘 만들어 낼 수 있다면 가볍게 턴마다 수행 가능해, 정해진 영역 내에서는 비동기라는 생각 없이 프로그래밍이 가능하단 장점이 있다.


3. immediatly 연산

모든 오퍼레이션이 즉시 연산으로 이루어지게 설계 하는 방식이다. 현재 상황에서 즉시 알아낼 수 없는 정보는 취급하지 않거나, 티어를 옮기는 과정이 다른 요청에 영향이 없게 독립적으로 구성 되어 있어야 한다.

이 방식으로 구현하려면 middle-ware들도 non-blocking으로 응답 할 수 있는 구조로 지원되어야 한다. (혹은 그렇게 랩핑하거나)

즉시 연산을 위해선 connection (request) 대비 blocking 연산 비율이 1:1에 가까워야 한다.

가급적 cache 데이터 등에 접근해 blocking 도 줄이고, 계산 시간을 낮춰야 한다.

또한, 처리 티어를 옮겨 갔다 오게 되는 상황이 다른 요청에 영향을 끼치지 않으려면 stateless 해야 한다. (한번의 요청에 모든 필요데이터를 검증,취합,처리 해야 함을 의미)

대 다수의 web 서버가 이 구조라 할 수 있다.

Posted by 엘키 엘키

댓글을 달아 주세요

1. Through-put


초당 소화 가능 이벤트.

이는 DB나 연결된 기능들과의 교신/처리가 포함된 계측 이어야 한다.

분산 가능한 특정 이벤트들은 지정된 서버와의 교신 (P2P스러운 접근)만으로 처리함으로써, 비용을 분산 시킬 수 있다.

일반적으로 다음 두가지 측정이 이루어지면 된다.
- 프레임워크 (네트웍 엔진이라 불리우는) through-put.
- 로직 through-put.


2. Through Pipe-line

파이프라인이란 이벤트 처리를 위해 거치게 되는 과정을 표현한 것을 말한다.

구현 별로 다른 어떤 과정에서도 wait-free 방식으로 구현하는 것이 좋다.

어쩔 수 없는 상황이라면 해당 작업 전용 스레드를 할당 받는 것이 좋고.

Through Pipe-line은 스레드 디자인과 큰 연관이 있는데, blocking 동작이 있다면 퓨쳐 패턴으로 구현해 요청을 보낸 후, 다시 파이프라인으로 재 입력 받는 구조로 처리하는 것이 좋다.

핵심은 적절한 분산을 통해 병목 지점 제거, blocking 상황을 제거해 Through-put 향상을 노리는 것이다.


3. 순환 구조 체크

잘못된 순환이 이루어지면 이벤트 폭발이 일어날 수 있다.

상호 순환 구조가 안 생기도록 이벤트가 어떠한 순서로 파이프라인을 순회하는지 검사하고, 파이프라인을 오래 타거나 반복해서 타는 것이 불가능 하도록 제약을 걸 필요가 있다. (spin-count를 계산해 몇 번 이상이면 이벤트를 버리는 등의 처리가 필요하다)

4. base-line

base-line은 초당 로직이 몇회 동작할 것인지 (프레임), 그렇다면 한 프레임이 몇 ms까지 사용해도 되는지, 또 패킷은 몇초안에 수신된다는 것을 전제로 동작하는지 등이 명확히 규정지어져야 한다.

base-line을 넘어설 것이 의심되면 유저 수 제한, 특정 기능 제한 등을 통해 기존 접속한 유저/잘 동작하는 기능은 보호 받을 수 있도록 구현해야 한다.


5. run-time apply

run-time 접속제한, run-time 기능 제한, run-time 리소스 리로드 등이 그래서 필요하다.


6. 객체의 생성 소멸 관리

생성 시점과 소멸 시점은 같게 관리하는 것이 좋다.

만약 주체가 다른 tier나, 다른 프로세스 등이라 관리가 어렵다면, 이에 대한 보호 장치가 반드시 필요하다. 

어쩔 수 없는 상황이 아니라면 shared_ptr도 그다지 좋은 해결책이 아니다.

개체의 소유권은 가능한한 엄격히 관리되어야 한다.


7. 과한 보호 장치에 대한 억제

예외 상황을 검증하고 보호하기 위한 코드도 검사/검증 대상이다.

이런 코드가 문제를 일으킬 여지도 있으니 이러한 코드도 세워둔 전제를 위배하지 않는지 검사하고 검증하자.


8. 무거운 단일 이벤트 보다는 작은 이벤트로 처리하라.

가급적 모든 유저를 대상으로 하는 이벤트는 자제하고, 유저가 발생시키는 이벤트 단위로 동작 시켜라. (웹 서버 구조)

시간에 의존하는 이벤트 (heart-beat 체크, 아이템 유효 시간 체크, 날짜별 이벤트) 들도 비동기 처리 후, 적용 대상만 추려 작은 이벤트로 발생시켜라.

가능한 한 적용 대상 자체가 최대한 작게끔 유지 시키는 것이 좋다.

가능하다면 비동기 처리던 아니건 간에 목표 대상 자체를 줄이고, 기능이 정말 필요한 이벤트에 물려서 동작 시켜라. (코드 공유가 잘 되어 있다면, 클라이언트에 서버 연산 예상 결과를 적용 시키고, 서버는 해당 기능이 실제로 active 되는 시점에서 트리거를 동작시키는 방법도 있다.

가급적 polling보다는 event-driven을 선택하라


9. 확장성 (scalability)

결합도를 낮추면 자연스레 확장성을 높일 수 있다.

stateless를 의도하면서도 성능을 높일 수 있는지 검토하라.

서비스를 목적에 따라 작게 쪼개 관리할 수 있다면, (서비스 종류에 따라 관리 비용이 증가하지 않게 된다면)  확장성을 특히 runtime scale-in, scale-out을 좀 더 용이하게 이뤄낼 수 있다. 

'Software Engineering > Knowhow' 카테고리의 다른 글

디아블로2의 렐름 다운 정책에 대한 썰  (0) 2013.01.26
멀티스레드 로직 구현 방식  (0) 2013.01.26
서버 프로그래밍 핵심 정리  (0) 2013.01.26
문제 해결 노트  (0) 2009.02.03
나의 로그 기준  (0) 2008.02.23
서버 프로그래밍시 유의점  (0) 2008.01.14
Posted by 엘키 엘키

댓글을 달아 주세요

예전에 작성했던 글을 다시 보게 됐다.


좋은 프로그래머란 무엇일까?  (http://elky.tistory.com/174)


4년이 지난 지금 내가 생각하는 좋은 프로그래머란 무엇일까? (지금은 프로그래머란 표현보다 엔지니어란 표현을 좀 더 즐겨쓴다. 이것도 마인드의 변화겠지?)


우선 무엇보다 부드럽게 이야기하는 법, 대화 자세 이런건도 좋아졌고.


현실과 타협도 많이 한거 같다.



이전에는 책에서 보거나 느낀 최선을 실천하지 못하면 마음이 너무 불안했다.


그런데 그 실천이란 것을 주변 상황을 둘러보지 않고 하다보니, 이 상황에서 중요한 판단들을 놓쳐왔다.




예를 들면 원인 파악보다 중요한게 현재 상황에 대한 대처인 경우가 많다.


또한 패치가 얼마 남지 않은 상황에서 큰 설계상 오류에 대한 대처는 패치를 미루거나, 설계상 오류를 감안하고 최소한의 리스크로 서비스를 하는 것이 맞다.


완벽함을 추구한답시고 시간과 여건을 고려하지 않은 개발자 개인의 욕심이 안정성을 무너뜨려선 안되더라.




애초에 안정성이란 검증된만큼 이뤄지는 법이다.


우리는 스포츠 선수들 만큼은 아니지만, 평정심을 갖고 침착하게 상황을 바라볼 필요가 있다.




내가 생각하는 안정성을 위해 중요한 것은 무엇이냐?


바로 경험과 시스템이다.




좋은 경험을 많이 한다면 필요 수준의 기술은 갖추고 있는게 일반적이고.


경험을 바탕으로 퀄리티 높은 결과물을 만들기 위한 시스템을 갖추는 것이 너무나도 중요하다.


언제나 내가 생각하는 전제는 "사람은 언제나 실수한다"라는 것이다.


언제든 실수 할 수 있는 사람을 돕기 위해 시스템을 구축해야한다.



개발자 개개인의 역량은 그 시스템을 잘 구축하고 관리하기 위함이다.


많은 개발자의 실수는 섬세함과 부지런함의 부족이다.


섬세함의 부족이란 어떠한 목표만을 생각하다보니 운용상의 불편함을 만들거나, 운용이 편하지만 결합도가 높은 코드를 양산하는 등의 부족한 완성도를 말한다.


부지런함의 부족이란 갖춰 있는 시스템이 운용이 불편하던지 등의 이유로 적용을 미루는 것을 말한다.


시스템 운용이 불편하다면, 불편한 운용법을 효율적으로 고치는 것도 엔지니어의 자세다.


엔지니어는 철저히 결과로 말해야 하기 때문이다.




현재는 좋은 엔지니어는 상황에 맞는 최선의 판단을 해야 하며 이를 위해서는 일정 수준 이상의 기술과 시스템을 마련해야 된다는 것이 내 생각이다.


현 상황을 잘 개선할줄 아는 사람치고 빌드업을 못하는 사람은 없더라.


보통 난재는 빌드업과정보다, 잘못된 빌드업을 고치는 과정에서 더 많이 발생하기 때문이다.


잘못된 빌드업된 상황이 오래 유지되면 됐을수록 더 고치기 어려운 편이고.



자신이 만들어낸 것들에 대해서 좀 더 냉정히 바라보고, 그 완성도를 끌어올리는 일을 반복함으로써 조금 씩 더 좋은 엔지니어가 된다고 생각한다.


무언가를 그냥 만들어내는 것보다, 잘 만들어 내는 것을 요구 받아야 하고 (일정을 못지키더라도 잘 만들어내란 의미가 아닌 것은 알거라 믿는다.) 또한 그렇게 만들어 내야 한다.


그렇게 하는 사람이 바로 좋은 엔지니어가 아닌가 싶다.

Posted by 엘키 엘키

댓글을 달아 주세요

언젠가 관리자란 주제로 글을 쓰리라 마음 먹었것만, 나를 관리해주시는 관리자도 몇 되지 않으셨었고 (지금도 많진 않지만), 그 분들과 이야기를 나누거나 회고하기에는 재직중인 상황이라 미루다 미루다 이제서야 쓰게 됐다.


사실 좋은 관리자=좋은회사라는 공식이 어느정도 성립한다고 생각이 든다.


그렇게 생각하는 데에는 여러가지 이유가 있다.


1. 소통이 적은 회사 일 수록 직속 상사내지는 관리자와의 대화가 업무 진행에 8할 이상을 차지하기 때문.
- 안타깝게도 대부분의 회사가 이렇다는 게 현실

2. 결정권은 관리자에게 있으므로 해당 파트 내지는 팀의 방향성도 관리자에게서 나오기 때문
- 물론 그 보다 위에 계신 분들이 방향성을 잡는 경우도 있지만, 그 마저도 관리자의 역량과 영향이 있다고 볼 수 있음


기본적으로 좋은 관리자라는 의미는 상당히 애매하다.


대부분의 관리자 (내지는 대다수의 사람이) 들은 장점만 갖고 있지 않기 때문이다. (정말 정분이 날 만큼 친해서 자신에게 모든걸 맞춰주는 관리자를 만나신 분이 있다면 연락주시길...)


내가 경험해보거나 듣게 된 관리자들의 성향은 대부분 몇가지로 분류 할 수 있다.


1. 배려파
- 기본적으로 좋은게 좋은거라고 개개인의 성향을 존중하고, 판단을 존중한다.
- 장점 : 대부분의 이야기를 들어주고, 이해해주려 노력한다.
- 단점 : 의견 제시를 하는 사람이 여러명일 때 본인이 혼란에 빠지곤 한다. 또한 판단이 늦는 경우가 많다.

2. 현실파
- 회사의 입장이 최우선이다. 회사에 피해가 덜 가는 것을 우선적으로 생각한다.
- 장점 : 회사 입장에서 판단하기 때문에 결과적으로 회사와 갈등이 빚어지지 않는다.
- 단점 : 개개인의 판단이 무시되기도 하기에, 현실파 관리자와 개인간의 갈등이 빚어지곤 한다.

3. 독단파
- 자신의 판단이 최우선이다. 나를 따르라~~
- 장점 : 명확한 신념이 있기에 추진이 빠르다. 또한 설득을 위한 시간 소모가 없다.
- 단점 : 독단파 관리자의 판단이 잘못 됐을 때에도 여지가 없다. 다른 의견을 가진 사람들 사이에서 불만이 터져나오고 이를 수습하기도 어렵다.


개인적으로는 이 세가지 스타일의 관리자를 다 만나봤으니... 뭐 결과적으로 좋은 경험이었단 생각이 든다.


어느 한 스타일의 관리자를 꼽기에는 상황에 따라 필요한 관리자 타입이 너무나도 다르다.


물론 나도 레아님이 말씀하신 빠른 의사 결정이 최고의 관리자라는 얘기(http://rhea1st.tistory.com/489)에는 어느정도 공감한다.


결과적으로는 나는 생각이 조금은 다른데, 빠른 의사 결정이 다는 아닌 경우가 많다는 점이다.



나는 서버 개발자기에 긴급한 상황을 다른 파트보다 조금 더 많이 맞이한다고 생각이 든다. (이로 인해 줄어든 내 수명은... 누가 늘려줄려나...?)


당연히 나의 관리자도 이런 긴급한 상황을 자주 맞이하게 되는 것이고.


이런 상황에서 빠른 의사 결정이 물론 중요하다.


허나 결정이 이럴 때만 이루어 지는가??


그렇지 않다는게 중요하다.




워낙에 팀 분위기도 좋고, 게임 방향성도 모두가 공감해서 트러블 슈트만 제대로 해내면 하하호호 할 수 있는 팀이라면 얼마나 좋겠는가?


하지만 현실적으로 그런 팀은 많지 않고, 풀어내야 할 문제가 기술적인 이슈나 서비스적인 이슈만이 아니라는게 중요하다.




사실 사람간의 갈등이 제일 어렵다. 이 문제까지 관리자가 해결하는 건 쉬운일이 아니라 생각하고, 경험해본 적이 없기에 넘어가보자.



내가 가장 많이 겪었던, 그리고 들어온 고충은 바로 업무 스타일과 퀄리티 문제다.


업무 스타일에 따라 서비스 시에 발생할 문제를 매우 많이 해결 할 수 있고, 퀄리티란 단순히 테스트 해보니 잘 되요가 아닌 함축적인 의미를 내포하기 때문이다.


서로 다른 환경에서 일해오던 여러 사람이 팀으로 묶였을 때, 다른 업무 스타일과 퀄리티를 조율 할 수 있는 관리자가 좋은 관리자라 생각한다.




사실 이걸 해낸 관리자는 거의 없고, 앞으로도 많지 않을 것이다.


대부분의 경우는 혼란 상태에 빠져서 좌초되거나, 혼란 상태로 연명하며, 그런 상황은 대게 독단파 한명이 팀을 휘어 잡을 때가 되서야 나름의 평온함을 찾게 된다. (억눌러서 얻은 평화는 오래가지 않는법...예외가 있다면 독단파가 뛰어난 자라면 좋은 결과를 내기도 한다.)


아주 운이 좋을 경우 업무 스타일이 흡사한 사람들끼리 평온한 팀이 만들어지기도 하고.


하지만 대게는 나쁜 팀으로 남는다. (혹은 여러가지 상황으로 인하야 버티거나)




이렇듯 현실적으로 어려운 이야기를 왜 하느냐고?


그런 어려운 일을 해내야 좋은 팀이 된다는 이야기를 해야 하는 것이다.


좋은 관리자가 되는게 그만큼 어렵지만, 그만큼 좋은 팀이라는 보상이 온다.



그런 관리자를 앞으로의 개발자 인생에서 만날 수 있을까? (내가 그런 관리자가 될 수 있을까란 질문은 던지지 않는걸로. 나는 관리자가 아닌 개발자로써 계속 남고 싶으니까)


뭐 꼭 내가 만나지 못하더라도, 그런 관리자가 하나라도 더 있었으면 하는 바램에서 이 글을 남겨본다.

Posted by 엘키 엘키

댓글을 달아 주세요



출처  : http://www.mcdonaldland.info/2007/11/28/40/

'Software Engineering > Design Pattern' 카테고리의 다른 글

Reactor 패턴과 Proactor 패턴  (0) 2014.08.05
Design Pattern Quick Reference  (0) 2011.02.10
데코레이터 패턴 (Decorator)  (2) 2008.02.09
커맨드 패턴 (Command)  (0) 2008.02.09
플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
Posted by 엘키 엘키

댓글을 달아 주세요

이전버튼 1 2 3 4 5 6 이전버튼

블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today27
Total1,605,481

달력

 « |  » 2020.8
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

글 보관함