개발자가 원하는 훌륭한 SE



필자 메모 – 개발자가 원하는 훌륭한 SE
window31 (window31@empal.com / www.window31.com)

월간 마이크로소프트웨어 7월호


회사마다, 그리고 개발하고 있는 솔루션마다, 프로그래밍 종류마다, 개발자는 다 존재하지만 SE 파트가 존재하는 경우는 있는 곳도 있고 그렇지 않은 곳도 있다. SE는 무엇일까? System Engineer 의 약자로 “기술지원” 의미로 사용된다. 본래 SE는 서버를 관리하거나 장비를 다루는 등의 업무를 하는 사람을 일컬었지만, 소프트웨어 업계에서 SE는 매뉴얼을 작성하거나 모듈 테스트, 고객사와 컨택포인트가 되는 등의 일을 전담한다. 물론 이런 일들을 개발자가 직접 하고 있는 곳도 많이 있지만, 보통의 개발자들은 이러한 일들을 좋아하지 않으며(혹은 잘 처리하지 못하며 – 코드 작성 외에는 관심없는 개발자도 상당히 많은 편이다) 회사가 커지고 업무가 분담되면서 각 파트에 대한 업무 분리가 이루어질 수 있도록 SE의 필요성이 많이 부각되는 것이 요즈음의 추세인 것 같다. 이때 SE는 실제로 개발 업무는 하지 않지만 컴파일러나 라이브러리의 개념을 이해하고 있어야 하며 최소한의 코드를 파악할 수 있는 수준까지 요구되는 경우도 있다(실제로 개발자 출신도 있다). 그 외에도 솔루션이 해외로 수출되면서 해외 로컬라이징이 필요할 때가 되면, 중국어 일본어 영어 등 외국어가 가능한 SE들이 또 실력을 발휘하기도 한다. 개발, 테스트, 기획, 커뮤니케이션 등 IT업무의 전반적인 사항을 이해하면서 외국어 스펙까지 가능한 인재들이 SE포지션에 위치하면서 개발자들이 코딩에만 전념할 수 있도록 많은 부분에서 서포트 된다.

여기서 개발자들이 원하는 SE와 차라리 없느니만 못하다고 인식되는 SE가 구분된다. 개발자들이 원하는 SE들은 일단 제품에 대한 이해가 빠르고 포괄적인 지식을 담는 모습을 보여준다. 하지만 그렇지 못한 SE는 항상 개발자가 가르켜 주는 것만 알려 하고, 어쩔 때는 가르쳐 준 것도 잊어먹는 경우가 부지기수다. 훌륭한 SE는 제품을 개선시키려는 기획적인 아이디어 창출에도 기여한다. 하지만 그렇지 못한 SE는 현재 제품을 유지하는 것 외에는 관심이 없다. 그나마 유지조차 제대로 못하기도 한다. 뛰어난 SE는 개발자가 만든 코드와 기능에 대해 여러 사고로 접근하며 같은 질문을 반복하지 않는다. 한번 들은 것은 반드시 문서화 한다. 그렇지 못한 SE는 문서화를 싫어하며 시간만 지나면 가르쳐 준 것을 잊어먹는다. 똑 같은 질문을 여러 번 개발자에게 되풀이하여 묻는다. 똑똑한 SE는 개발자가 만든 기능과 코드를 훌륭한 매뉴얼과 소개서로 재탄생시킨다. 하지만 그렇지 못한 SE는 문서 작성시 개발자가 메신저로 한 얘기나 메일로 적어준 내용을 긁어붙히기만 한다. 똑똑한 SE는 한번 발생한 문제나 잇슈 사항은 같은 사건이 일어났을 때 자신의 선에서 해결하지만 그렇지 못한 SE는 같은 문제가 일어나도 매번 개발자에게 묻는다. 개발자는 소스 리빌드 없이 SE선에 좀더 손쉽고 많은 일을 처리할 수 있도록 툴을 새로이 만들어주는 경우가 많다. 이때 훌륭한 SE는 자기 선에서 직접 툴을 개발하거나 아니면 툴 개발 기획을 의뢰하기도 한다. 하지만 그렇지 못한 SE는 항상 개발자가 다 해주기만을 바라며 만들어준 툴도 제대로 사용할 줄 모른다.

이렇게 몇 가지 사항을 예로 들어가며 뛰어난 SE와 그렇지 못한 SE를 구별해 보았는데, 이런 훌륭한 SE라면 어떤 개발자라도 손을 들어 환영할 것이며, 그 SE와 함께 일한다는 것을 업무의 큰 잇점중 하나라고 생각할 것이다. 필자는 뛰어난 SE도 만나보았고, 함량 미달의 SE와도 일을 해 보았다. 뛰어난 SE와는 항상 그가 서포트 해 주었기에 든든했지만, 함량 미달의 SE와 일을 할 때에는 저 사람이 있어서 시간만 더 뺏기고 스트레스 받고 차라리 혼자 하는게 낫겠다는 생각만 되풀이 되었었다. 동료에게 환영을 받지는 못할망정 존재 자체에까지 부정적 인식을 심어주는 그런 취급을 받는다면 그 사람이나 그 관계는 분명히 문제가 있는 상황일 것이다. 메일을 주고받는 외에는 아무 것도 할 줄 모르고, 항상 개발자가 긁어주는 내용만을 답장으로 보내고 몇 년씩 맨날 보던 라이브러리 링크 에러 하나 날때마다 일일히 개발자에게 묻는다면 그 사람과 일을 하려는 개발자는 아무도 없을 것이다. 회를 먹을 때에 무우 채는 실제로 먹는 음식이 되지는 못하지만, 횟감을 돋보이는 역할을 함으로써 그 공헌을 충분히 하고 있다. 테크니컬 서포터도 마찬가지다. 개발자의 업무를 분리시키고 코딩 외적인 작업을 자신의 영역에서 훨씬 더 훌륭하게 처리한다면 그것은 회보다 훨씬 더 맛나고 우아해 보이는 무우 채가 될 것이다. 따라서 SE라는 포지션 자체가 서포터로서 공격보다는 수비의 역할이라 상대적으로 덜 부각되어 보일 수 있지만 어떤 수비를 하느냐에 따라 그 포지션은 가치의 경중이 크게 바뀔 수 있을 것이다. 누구나에게 인정받고 훌륭한 평가로 가치가 부각되는 SE는 어떤 개발자라도 어떤 회사라도 환영할 수밖에 없다.

Posted by BrokenCode


트랙백 보낼 주소 : http://window31.com/trackback/182

댓글을 달아주세요

  1. 2008/07/01 11:13
    댓글 주소 수정/삭제 댓글
    Second Edition ㅡㅡ;;
  2. 2008/07/01 21:33
    댓글 주소 수정/삭제 댓글
    Standard Edition =0=;;;
    • 2008/07/08 09:42
      댓글 주소 수정/삭제
      Super Enterprise :$?
  3. 2008/07/07 20:58
    댓글 주소 수정/삭제 댓글
    HS님이 읽어보라고 준 마소 7월호 보고 들어왔는데 역시나 여기에도 있네요
    머리속에만 있던글들인데 이렇게 정리를 해주셔서 좋네요 ㅎ
    제목에 "개발자가 원하는"을 다른걸로 바꿨으면 더 중립적인 글이 되었을 수도 있었지 않을까 생각해 봅니다. SE도 개발자에게 불만이 많을테니...
    • 2008/07/08 09:47
      댓글 주소 수정/삭제
      이 글은 전혀 중립적인 논조가 아닌데...
      SE의 문제점을 지적한 글이지
      난중에 SE입장에서 개발자의 문제를 지적한 글도 써볼께

DLL, MFC 실전 모듈 리버싱



[실전강의실|Reverse Engineering의 정석]
DLL, MFC 실전 모듈 리버싱

월간 마이크로소프트웨어 2008년 6월호


1, 2회를 거쳐오면서 C와 C++문법에 대한 디스어셈블링이 이제 어느 정도 감이 잡혔을 것 같다. 이번회는 DLL과 MFC등을 살펴보면서 실전 모듈에 대한 접근 방법을 살펴본다. 익스포트 함수와 MFC 클래스의 구조, 그리고 헤더 파일과 MSDN을 이용한 리버스 엔지니어링에 대해 알아보자.


------------------------------------------------------
강병탁
window31@empal.com, http://www.window31.com | 바이너리 취약점 분석 업무를 하고 있다. 안티 크래킹/안티 디버깅 엔진 개발을 다년간 해왔으며 시스템 프로그래밍과 리버스 엔지니어링에 관심이 많다. 악성 코드나 해킹툴이 내부에 담고 있는 천재적인 알고리즘에 감탄하며 오늘도 IDA를 돌린다.

------------------------------------------------------

연재 순서
1회 | 2008. 4 | C 문법과 디스어셈블링
2회 | 2008. 5 | C++ 클래스와 디스어셈블링
3회 | 2008. 6 | DLL, MFC 실전 모듈 리버싱
4회 | 2008. 7 | 4GL 고급 언어 역분석
5회 | 2008. 8 | 안티 디버깅과 리버스 엔지니어링
------------------------------------------------------

연재 가이드
운영체제| 윈도우 2K/XP/2003
사용도구| Visual Studio, IDA, OllyDBG
기초지식| C/C++, ASM, Win32 API, MFC
응용분야| 리버스 엔지니어링/시스템 프로그래밍/해킹/보안
------------------------------------------------------


다루는 내용

DLL도 C/C++로 코드가 이루어지기 때문에 기본적인 사항은 C/C++에 대한 디스어셈블링과 별반 차이가 없다. 다만 WinMain()대신에 DllMain()이 존재한다는 것, 그리고 각각의 ul_reason_for_call 에 대한 분류코드가 들어가며, 익스포트 함수가 있다는 것(물론 없는 경우도 있다). 그정도의 간단한 차이점을 생각할 수 있다. 따라서 이번회는 실제 어셈 코드나 스택의 계산법, 레지스터 이용 등에 대한 세부적인 설명보다는 DLL, MFC 와 관련된 굵직굵직한 내용을 다뤄보도록 하자.

 


Posted by BrokenCode


트랙백 보낼 주소 : http://window31.com/trackback/178

댓글을 달아주세요

  1. 2008/06/26 12:44
    댓글 주소 수정/삭제 댓글
    어떤 기회로 마소5월호를 봤었는데 그때 "C++ 클래스와 디스어셈블링" 재미있게 보았습니다^^
    • 2008/06/29 21:20
      댓글 주소 수정/삭제
      재밌게 봐 주셨다니 감사합니다 ^^;
      코드게이트 출전하셨었나 보네요 앞으로 블로그 자주 들리겠습니다 ^^

Nell - Separation Anxiety

 | Guitar
2008/06/16 14:37

Nell - Separation Anxiety




사용자 삽입 이미지


유난히 내 주변에만 산소가 모자란 듯
숨이 막히고 미칠 듯 답답해요
하늘이 무너져 내려 떨궈진 내 눈물이
발 밑에 구름 위로 흩어 지네요

나를 떠나지 마요
나를 떠나지 마요
나를 떠나지 마요

그래요
나란 사람 참 힘들죠
고장나버렸단 걸 알아요
그래도 날 포기해버리진 말아 줬으면 좋겠어요
고쳐질수만 있다면 사실 난 아주 아름다울테니
그러니 부디 놓아 버리지 말아요

유난히 내 주변에만 상실의 그림자가
유독 어둡고 짙게 깔린 듯해요
믿음이 무너져 내려 힘겹게 버텨오던
그 마지막 숨 조차 앗아가네요

나를 떠나지 마요
나를 떠나지 마요
나를 떠나지 마요......



사용자 삽입 이미지



Posted by BrokenCode


트랙백 보낼 주소 : http://window31.com/trackback/181

댓글을 달아주세요

  1. 2008/06/16 16:07
    댓글 주소 수정/삭제 댓글
    누굴 닮은거 같은데.. =0=a...
    아아.. 요새 여름타는지..; 싱숭생숭.. 이상하고..
    • 2008/06/20 01:11
      댓글 주소 수정/삭제
      여름도 타냐 ㅋㅋ
  2. 2008/06/16 17:57
    댓글 주소 수정/삭제 댓글
    HS / 태지옹이 아닐까?
  3. 2008/06/17 00:12
    댓글 주소 수정/삭제 댓글
    넬 노래치고 비트가 좀 강하군요. ;)
    묘한 분위기의 노래 잘 듣고 갑니다. ^^)/~
    • 2008/06/20 01:11
      댓글 주소 수정/삭제
      네 노래도 좋고 가사도 넘 좋죠 ^^
  4. 2008/06/21 12:58
    댓글 주소 수정/삭제 댓글
    4계절 다타는 족속임~~ 봄은 봄대로~ 여름은 여름대로~
    가을은 원래부터.. 겨울도 겨울 나름대로~~ㅋ =0=;;
    희안한 녀석이라고나 할까요~
    • 2008/06/26 11:54
      댓글 주소 수정/삭제
      방황좀 그만하3

팀장의 가치 - 3편




어쩌다보니 6월의 첫 글이 되어버렸네요 :)

개발자들은 밤에도 개인 프로젝트를 하거나 취미로 사교성 팀 프로젝트를 진행하면서
퇴근후 집에가서 몇줄씩 코딩하시는 분들이 많은데
하루종일 유지보수의 압뷁에 시달리다가 떡된 몸으로 집에 돌아가면 코딩이고 코풀이고 아무것도
하기 싫을 때가 있죠 ㅎㅎ

그런 것들과 관련해서 하루종일 장문의 이메일 작성 압뷁에 시달리고 집에 오면,
블로그에 문장 하나 끄적거리기 싫은 때가 바로 딱 요즘인 것 같습니다 :p

하지만 일단 벌려놓은 일은 마무리 지어야겠죠 :)
팀장의 가치 3편입니다.
몇편에서 끝날지도 모르는데 1/2, 2/2 따위의 제목으로 해놓은 것에 대해 기획성, 준비성,
분량 체크 등의 자질 부족을 탓하며 지난 제목을 다 1편, 2편 등으로 바꿨습니다.

그리고 참고로 몇마디 더 추가하자면, 지금까지 나열했던 항목들과 앞으로 등장할 내용들은
저 자신의 이야기도 많습니다.

아 그러니까 제가 팀원이었을 때 저런 팀장이 엿같았다 머 그런 얘기가 아니라, 제가 팀장
비스무리한 위치에 있었을 때 제가 실수했던 내용들을 다룬거라 이거지요.
저도 인간인지라 팀장이 하지 말아야 할 일들을 많이 자행해 왔던 것 같고, 주변 동생들한테도
"아 형 그러지 마여 애들 기분 나빠" 라는 말도 들었던 것 같네요. 그래서 주위를 둘러보게
되었고 저 자신도 여러 각도에서 반성을 했던 것 같습니다.

아! 그런데 저는 아이러니하게도 사회생활을 하면서 실제 팀장의 직책을 받아본 적은 한번도
없습니다. 팀장은 아니면서 팀장 비스무리한 포지션에 앉아서 책임은 팀장처럼 지고, 업무는
업무대로 하고, 근데 권한은 없고 ㅅㅂ뭔지 -_-  암튼 그런 자리에는 나름 오래 앉아있었던 것
같네요. 자리를 잡고 있었다기보다는 묶여 있었다는 표현이 맞을 것 같지만, 암튼 그랬습니다.
그러므로 그런 와중의 저를 씹은 내용이라 할 수도 있겠네요 ; 머 팀장은 아니니까 애들이 더
편하게 얘기를 할 수 있었던 것일수도 있던 것 같고요, 암튼 여러모로 좋은 지적을 해준 지난
동료들에게 감사하게 생각하고 있습니다.

그럼 각설하고, 6)번까지 했으니 7)번 항목으로 가보도록 하겠습니다.


7) 사사건건 지적을 하는게 관리능력이 훌륭한 것이 아니다.

누구든 팀장이 되면 업무 스킬은 물론이며 관리자로서의 역량까지도 고민하게 되죠. 어떻게
하는 것이 훌륭한 관리능력을 보여주는 것일까. 하는 고민을 참 많이들 하시는 것 같습니다.
여기서 초짜 팀장일수록 착각을 많이 하는데, 팀원들에게 이런저런 지적이나 잔소리를 많이
하는것이 관리능력이 뛰어나다고 생각하는 것입니다. "관리능력 = 잔소리" 대체 이 공식은
누가 만든것일까요? 두가지 개념은 결코 비례하지도 관계 지수가 높지도 않습니다.

또 이 케이스는 팀장이 더 윗사람들에게 자기가 뭔가 하는것처럼 보이고 싶어서 더 유난
떠는 경우도 많았던 것 같습니다. 보통 윗사람들에게 실력으로 별로 인정은 받지 못했는데
짬밥은 많고 밀려 올려가서 팀장이 되긴 했고, 당근 대가리들에게 잘 보이고 싶고, 근데
업무 스킬로 인정 받으려니 본인이 존나 모자라고,,, 머 그런 사람이 좀 높은 비율을 차지하지
않나 하는 생각이 듭니다. 한마디로 그자리에 앉으면 안 되는 넘이 앉게 되어서 발생하는
일 중 하나죠.

사사건건 간섭하면서 팀원들을 기죽이거나 ㅄ만들며 자기가 관리능력이 뛰어난 줄 착각하는
케이스죠. 실제로 그런 간섭은 업무에도 팀 운영에도 그다지 도움이 되지 않는 것들이
대부분입니다. 물론 진짜 지적과 충고가 필요한 상황도 많이 있습니다. 하지만 잔소리 많고
나무의 잔가지만 쳐대는 그런 팀장은 정작 굵은 가지가 상해갈때는 전혀 알아차리지도 못하며
아니면 아예 대체 뭐라고 말해줘야 하는지 판단하지도 못하는 (팀장의 한마디가 절실한 바로
이 상황에!! )어리석은 사람이 꽤 많습니다.



8) 회의좀 그만

위의 경우와 역시 일맥상통하는 팀장인 것 같은데요. 이번에도 역시 능력은 딸리고 어쩌다가
팀장은 됐는데 뭔가 관리한다는 모습은 윗선에 졸라 보이고 싶고 뭐 그런 팀장 얘기입니다.
이런 팀장들은 회의를 진짜 졸라 많이 합니다. 걸핏하면 회의실로 오라고 하거나 얘기좀 하자고
합니다. 아 물론 충분한 대화가 필요한 상황 얼마든지 있습니다. 당연히 상황이 그렇다면
회의 후에는 "아 이번 회의로 이런것을 깨달았다" 혹은 "아 이번 회의로 이 고민이 해결되었군"
등의 생각이 머리속에서 막 기지개를 켜고 있어야 합니다. 하지만 별볼일 없는(메일만 잘 보면
충분히 알 수 있는)업무 공유를 한답시고 장시간 회의를 한다거나, 귀한 업무시간에 회의실에
붙잡아 놓고 했던 얘기 또하고 또하고 하면 정말 뚜껑 열리죠.

아 업무 공유 하니까 혹시나 오해하실 분이 계실지 모르겠는데, 물론 업무 공유를 위해서 회의는
필요합니다. 하지만 그건 서로 다른 부서끼리나 협의점을 찾기 위한 선행작업 혹은 높은 분을
위하여 보고하는 자리 같은 형태가 되어야 맞는게 아닐까 하는 생각이 듭니다. 새파랗게 젊은
팀장에게 자기도 메일 다 보고 있으면서 보고서도 다 받았으면서 그걸 또 되새김질 시키는
업무 공유 회의는 정말 한심하죠(그것도 금방 끝나는 회의도 아니고 최소1시간이라면 -_-)

보통 이런 넘들은 회의시간이고 뭐시기고 했던 말을 또하고 또하고 하는 경우가 많습니다.
회의시간이 길어져야 뭔가 중대한 논의를 하고 온 것처럼 착각하는 것 같습니다. 별 영양가
없는 회의에 매번 시달리면 팀원들은 정말 지칩니다."아 또 이번엔 모야" 를 계속 연발하게 되죠.

애들 우르르 데리고 나가서 같은 소리만 반복하고, 막상 자기는 회의랍시고 불러냈으면서
그다지 도움 되는 얘기도 안해주고 하면... 참 한심하죠 :(
스트레스는 스트레스대로 받고 귀한 업무 시간 다 날라가고, 이런 팀장이 많으면 많을수록
회사 입장에서도 사실 손실입니다.



이번에는 서론이 길었으니 내용 자체가 많아져서 두개만 하고 넘어가도록 하겠습니다.
다음 글은 띄엄띄엄 나오지 않도록 바로 작성하도록 하겠습니다. 재미도 없는 글이 텀만 길어지니
참 모양새가 안 나네요 :)


2008년 6월. window31.



Posted by BrokenCode


트랙백 보낼 주소 : http://window31.com/trackback/177

댓글을 달아주세요

  1. 2008/06/10 09:24
    댓글 주소 수정/삭제 댓글
    비밀댓글 입니다
  2. 2008/06/11 14:04
    댓글 주소 수정/삭제 댓글
    비밀댓글 입니다
  3. s
    2008/06/12 07:24
    댓글 주소 수정/삭제 댓글
    8번...orz
    나도 제발 하루에 반을 차지하는 회의 안들어 가고싶삼.ㅜㅜ
    • 2008/06/16 14:38
      댓글 주소 수정/삭제
      ㅎㅎ 그런사람 많다지
  4. 2008/06/21 08:02
    댓글 주소 수정/삭제 댓글
    나의 블로그에
    CSI반장들을 모델로 쓴 팀장론을 퍼다놨는데
    관심있으면 보삼~
    • 2008/06/26 11:54
      댓글 주소 수정/삭제
      어 잘 보고 있다

BLOG main image
by BrokenCode

카테고리

분류 전체보기 (164)
Reverse Engineering (17)
C, C++ (12)
Kernel (8)
Guitar (15)
잡담 (57)
etc (4)
who am i (3)
보안 이야기 (31)
Tools (2)
월간 마이크로소프트웨어/.. (14)

글 보관함