Broken Code (window31)

破解nProtect教學

BrokenCode — Wed, 20 Aug 2008 00:54:57 +0900

破解nProtect教學
제목이 쵸큼 불순해서 한글로는 바로 적지 못하겠고
원문 그대로 놔뒀습니다.
해석하면 nProtect Rosmsqkdqjq 정도 되려나요 :p

중국어 잘하시는 분들 한번 보세요
엥간한거 다 나와있네요 :$

http://www.fantasy-eden.com/redirect.php?tid=901&goto=lastpost

중국 사이트에는 정말 별의별게 다 있어요
요즘 중국어 공부하는 중입니다. 어디까지 할수있을런지 모르겠지만
수많은 좋은 자료를 그냥 암호 보듯이 썩혀두기 아까워서요.

해킹 올림픽서도 "대~한민국!"

BrokenCode — Tue, 12 Aug 2008 12:35:52 +0900

해킹 올림픽서도 "대~한민국!"

이홍석 기자 redstone@dt.co.kr | 입력: 2008-08-11 20:52

태권브이팀 4위 등 '데프콘 CTF'역대 최고성적

베이징 올림픽에서 연일 승전보가 울리고 있는 가운데 지구 반대편에서 열린 해커들의 올림픽에서도 국내 팀이 역대 최고 성적을 기록했다.

10일(현지시간) 미국 라스베이거스에서 폐막한 세계 최대 해킹축제이자 해커들의 올림픽 `데프콘 CTF(Capture the Flag)'에서 태권브이(Taekwon-V) 팀이 4위, 와우해커(WOWHACKER)팀은 8위를 차지했다. 우승은 스쿨오브루트(School of root)팀에게 돌아갔으며 지난 2년간 연속 우승을 차지했던 1@stPlace팀은 3위에 랭크됐다.

올해로 16회 째를 맞은 데프콘은 세계 최대 해킹 및 보안 콘퍼런스로 지난 8일부터 10일까지 3일간 열렸다. 데프콘 CTF는 전 세계 해커그룹간 경쟁을 통해 최고 해커 고수를 선발하는 데프콘의 대미를 장식하는 행사로 지난해 우승팀과 온라인 예선전을 통과한 7개 팀이 자웅을 겨룬다.

태권브이는 국내 대표 언더그라운드 해커그룹 널앳루트(Null@Root)와 보안회사 패닉시큐리티(Panic Security)가 주축이 된 팀이며 와우해커는 동명의 해커 동호회 맴버들로 구성됐다. 지난 5월 해킹방어대회에서 메이킹(MayKing) 팀의 일원으로 대상을 수상한 해커스타 구 사무엘(19ㆍ건국대)군은 태권브이 팀원으로 활약하며 역대 최고 성적에 기여했다.

이번 태권브이 팀의 4위의 성적은 지난 2006년 동해(TheEastSea)팀과 2007년 자유의 노래(Song of Freedom)팀이 2년 연속 달성한 6위를 뛰어넘는 역대 최고의 성적이다. 특히 전 세계 450여 팀이 겨룬 온라인 예선을 통해 본선에 진출한 상위 7팀 중 3팀이 국내 팀이었다는 점은 국내 해킹 및 보안 실력이 세계적인 수준임을 보여줬다는 평가다. 포항공대 동호회로 이뤄진 플러스 팀은 예선을 통과했으나 개인 사정을 이유로 본선 참가를 포기했다.

한국정보보호진흥원 최중섭 해킹대응팀장은 "매년 국내 팀의 성적이 향상되는 것은 국내 보안 및 해킹 기술이 성장하고 있음을 보여준다"고 말했다.

이홍석기자 redstone@

원문 : http://www.dt.co.kr/contents.html?article_no=2008081202010660713003

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

태권브이 팀원으로 활약하며 역대 최고 성적에 기여한 해커스타 구 사무엘(19ㆍ건국대)군이
귀국후 맥주를 사기로 했습니다. 어서 사333!! - 말종간지폭풍

넥슨밴드 여름 공연

BrokenCode — Sat, 9 Aug 2008 18:05:15 +0900

넥슨밴드가 여름 공연을 합니다.
넥슨밴드(이하 넥밴)은 총 4개의 팀으로 구성되어 있으며
(1팀:아비규환, 2팀:오리무중, 3팀:준비태세, 4팀:막무가내)
숫자가 큰 순서대로 공연을 합니다.

저는 1팀 아비규환에서 기타를 치고 있으며 이번 공연에서는 기타가 부재중인 2팀에서도
저를 임대하여 갔기 때문에 땜빵을 할 계획입니다 (즉 실력도 안되는게 두탕 뜁니다 ㅅㅂ)

암튼 재미있으실테니 많이들 놀러오세요.
사운드홀릭은 홍대 클럽중 시설도 좇고, 교통도 좃습니다. :)

날짜 : 2008/08/23/SAT pm 7:23 (7시까지 오셔야 자리확보 가능)
장소 : 홍대 사운드홀릭 (www.soundholic.co.kr)
찾아오는길 : 홍대역 5번출구 KFC골목진입하자마자
오른쪽으로 꺾으신후 100m 가시면 왼쪽에 보임
입장료 : 5처넌 (맥주 1병 포함)

팀장의 가치 - 4편

BrokenCode — Thu, 7 Aug 2008 00:45:28 +0900

아으 정말 오랫만이죠.
팀장의 가치 4편입니다. 삼류 일일 드라마도 아닌데 어쩌다보니 질질 끌게 되네요.

9) 팀장이 좋아하는 것을 팀원들이 다 좋아하지는 않는다

팀장들의 크나큰 착각이 하나 있는데, 그건 바로 "자기가 애들을 데리고 다닌다" 라고 생각하는
것입니다. 그런 경우는 보통 회식이나 워크샵 등에서 문제가 불거집니다. 자기가 농구를 좋아해서
농구 경기 시합 관점 겸 해서 회식을 한다. 자기가 퍽탄주를 좋아해서 퍽탄주만 먹는다 뭐
이런것들이 예가 될 수 있겠네요.

회식은 다같이 즐기기 위한 자리고 업무의 재충전을 하는 목적으로 마련된 것입니다. 하지만
분명히 농구장이든 야구장이 가기 싫은 사람도 있을거고 퍽탄주를 싫어하는 사람도 있을겁니다.
물론 사회에선 싫어하는 일도 분명히 해야 하죠. 하지만 그건 적당한 수위와 상황에 부합하는
분위기 등이 동반되어야 하는 것 같습니다. 실력 있고 리더쉽 넘치는 카리스마 팀장이 그렇게
하자면 아랫것이 알아서 기면서 따르겠지만, 별것도 아닌게 지가 지금 팀장이라고 위세 부릴 때가
아닌데 무조건 지 하고싶은대로만 한다면 그 밑에는 아무도 남아 있으려 하지 않겠죠. 이건 초짜
팀장일 경우 혹은 JOT같은 ㅄ팀장들의 경우에 많이 보았던 것 같습니다.

10) 자신의 실수를 지적하는 팀원을 만들어라

정말 업무가 개같이 굴러가는 시기가, 팀장의 실수를 아무도 지적하지 않는게 반복될때 입니다.
윗사람에게 실수 지적하는건 물론 쉽지 않죠. 그리고 방법에 따라 예의에 어긋날 수도 있죠. 하지만
아랫사람의 의견을 묵살하는 독단에 빠진 팀장은 정말 오래 못갑니다. 포용하는 자세가 정말
필요한데, 대부분의 팀장은 죤심 상한다는 이유로, 또 그런걸 받아들이다면 팀원들이 전부 자신을
족같이 볼거라는 소인배같은 생각에 그러지 못하고 있죠. 팀원들이 팀장의 실수를 지적하지
못하는 이유는 여러가지가 있습니다.

1) 자기가 실수하면 두배로 당할까봐
2) 그런 행위 자체를 건방지다고 생각할까봐
3) 연봉 평가에 반영될까봐
4) 어차피 저사람은 지적해봤자 안 고쳐지기 때문에
5) 전혀 받아들이지 않을까봐 (그게 잘못됏다고 생각하냐? 등의 반응)

어떤 연유에서건 저런걸 무기로 역공하는 팀장들은 정말 쪼잔한 놈입니다. 거기다가 또 엿같은
사실은 팀장이라는 사람에게 무언가 당신이 잘못했소 라는 말을 하기가 쉽지 않다는거죠. 정말
쉽지 않죠. 그래서 필요한 것이 신뢰관계 입니다. 신뢰 관계로 뭉친 팀장과 팀원은 서로의 발전을
위해 그런 내용이 지적이나 간섭 혹은 반항이라고 받아들이지 않고, 나를 도와준다고 생각해
줍니다. 물론 팀원들이 이를 악용해서 사사건건 팀장에게 말꼬리를 잡는 일은 없어야겠죠. 머
개인적으로 그런거에 이용당하는 팀장은 또 ㅄ이라고 생각합니다. 어쨌든 이러한 신뢰관계는
11)에서 계속 얘기해보겠습니다.

11) 신뢰관계

팀장에게 묻고 싶습니다. "당신은 완전한 내 사람이라는 팀원을 가지고 있습니까?" 입니다.
만약 팀이 작을 때부터 원년 멤버로 업무의 최전선에서 뛰면서 동료들과 온갖 고초를 겪어오며
위까지 올라온 사람들이라면 그럴 수 있습니다. 함께 어려운 시절을 겪었으니 입지상으로는 자신이
팀장이지만 같이 고생한 사람들은 계속 자신의 동료라고 받아들이고 또 그 동료도 그렇게 생각해
주기 때문이죠. 이 경우는 실질적으로는 평행관계입니다. 인간적인 마찰만 없다면 계속 발전할 수
있는 업무 환경이죠. 심복? 이라고 하기엔 뭣하지만 오른팔이라 할 수 있는 사람이 옆에 있고,
팀장도 인간인데 힘들고 어려운 점을 의논할 사람이 필요하죠.

하지만 밀려 올라가서 팀장이 됐다거나 짬밥이 많아서 걍 어쩔 수 없이 됐다거나(잘하는 사람들이
다 퇴사해버려서 ㅄ팀원이 걍 남아있다보니 팀장이 된 경우가 대부분 이거랍니다), 아니면
대가리들에게 좇나 비벼대서 그자리에 올라섰거나 (이건 진짜 제일 개같은 상황) 하는 사람들은
자신이 믿을만한 사람이 없는 경우가 많습니다. 그런 사람들에게 "그래 이넘이라면 내 고민을
털어놓을 수 있고, 나의 자리를 대신해서 맡길 수 있지" 하는 사람이 있기나 할까요?

자신이 팀장이라면 생각해 보세요. 서로 신뢰관계가 굳건한 동료가 있는지.
그리고 자신이 팀원이라면 생각해 보세요. 우리 팀장님에겐 신뢰관계가 돈독한 팀원이 있을런지.
삼국시대에 각 나라의 킹왕짱들에겐 모사가 있었고, 조폭들에게는 오른팔이라 할 수 있는 넘버투가
있는 등, 리더들에겐 신뢰로 구축된 관계의 존재가 필수적입니다. 그게 없이 리더가 된 사람들은
외롭고 불쌍할 뿐이죠.

3개 넘게 쓰는건 참 힘들군요. 5편에 계속합니다 lol

2008년 8월. window31.

일상 생활에서의 역공학

BrokenCode — Tue, 5 Aug 2008 10:07:53 +0900

마소플러스
일상 생활에서의 역공학 - 월간 마소 8월호 中
강병탁 / window31@empal.com / www.window31.com

예전에 유럽의 어느 호텔에서는 한국인이나 중국인을 받지 않는 곳이 있었다. 이유는 유럽의 호텔에서는 샤워기 등의 각종 편의도구를 최신 시설로 구비하여 서비스 하고 있는데, 한국인이나 중국인만 왔다 가면 그것을 모조리 분해해 놓고 도망간다는 것 때문이었다. 그들은 왜 샤워기 등을 분해해놓고 도망쳐야 했을까. 그 이유는 일단 최신 시설이 너무나 탐이 났기 때문이다. 그래서 본인들도 그런 기술을 파악하여 제작해 보려는 의도로 자행한 일이라고 한다. 그렇게 기술을 파악하기 위해서는 설계도가 필요하겠지만, 그것이 없는 상태에서 완성화된 제품만 있으니 분해를 해서 구조를 파악해볼 수밖에 없다. 이것은 역공학(Reverse Engineering)이라 비유할 수 있는 작업이다. 설계도는 소스에 해당하며, 완성화된 제품은 릴리즈 버전의 바이너리라 생각할 수 있다.

이처럼 역공학 기술은 단지 코드 리버싱에만 국한되는 작업이 아니다. 또 하나의 예가 있다. 음악 부분에서도 비슷한 역공학 기술이 존재한다. 우리가 즐겨 듣는 음악, 록 음악이든 대중음악이든 유명하고 좋은 음악들은 반드시 그 악보가 어디선가 등장하기 마련이다. 이 악보는 어떻게 제작되는 것일까, 물론 작곡가가 직접 악보를 공개하는 경우도 있으나 상당히 많은 경우는 음악의 역공학에 능한 기술자들이 귀로 듣고 따낸 것이다. “여기서는 D – F - C# 등의 프레이즈가 들어가는군”, “드럼은 8비트에서 스네어 몇번” 하는 식으로 피아노나 기타 하나만을 달랑 들고 그 음악을 귀로 들으며 악보로 고스란히 옮겨 내는 작업 역시 리버스 엔지니어링에 비유할 수 있다. 이들에겐 멜로디를 콩나물로 포팅할 수 있는 훌륭한 귀와, 작업에 필요한 한두개의 악기가 일종의 디버거나 디스어셈블러인 셈이다. 바이너리에 녹아들어있는 독특한 아이디어를 참고하기 위해 해당 프로그램의 리버스 엔지니어링 작업을 하듯이, 음악 분야에도 타 아티스트가 만들어낸 아름다운 선율을 활용하기 위해 역공학 기술이 사용된다.

역공학 기술은 음식 문화에서도 살펴볼 수 있다. 어떤 미식가들은 마음에 쏙 드는 맛집을 발견하였을 때, 음식을 코와 혀로 느끼고 재료의 구성 상태를 캐취해내며 집으로 돌아와 본인의 부엌에서 그 음식과 비슷한 수준으로 요리해내기도(구현해 내기도) 한다. 이 역시 요리 과정이 기록된 문서 없이 단지 완성된 제품만을 가지고 거꾸로 역추적해 들어가 음식의 제작 과정을 파악하는 것이다. 이들의 경우도 훌륭한 역공학 기술이라고 말할 수 있다.

이처럼 리버스 엔지니어링은 단지 코드 역공학 뿐만이 아닌 많은 분야에 존재한다. 접근 소재나 방법론은 다를지 몰라도 거꾸로 추적해 나간다는 점에서 그 공통점은 분명하다. 그리고 원본 소재에 가깝게 다다른다는 그 목표도 일치한다. 공통분모가 단지 그것 뿐일까? 역공학에 있어서 가장 중요한 것이며 모든 역공학 분야의 공통되는 사항이 있다. 그것은 바로 “정공학에 대한 능통함” 이다. 역공학에 능한 사람들은 그 분야에 대해 모두 “장인”의 경지에 오른 사람들이다. 따라서 본인이 정공학에 능하기 때문에 그 지식을 바탕으로 역공학을 구사할 수 있는 것이다. 만약 정공학에 능하지 않은 사람이 역공학을 한다면 어떨까? 그 결과는 매우 보잘 것 없을 것이다. 게임 프로그래밍을 해본 적이 없는 사람이 렌더링 루틴이나 소켓 처리부를 리버스 엔지니어링 해 보았자 얻을 수 있는 것은 거의 없다. 또 화음이나 스케일에 대해 아무것도 모르는 사람이 음악을 듣고 귀로 따려 해봤자 음표 몇 개 그릴 수 없을 것이며, 요리도 제대로 하지 못하는 사람이 음식을 먹으며 재료를 분석하는 작업 역시 불가능에 가깝다.

다시 말해서, 역공학에 능하기 위해서는 반드시 “정공학”부터 능숙해야 할 필요가 있다. 이것은 어떤 분야의 역공학이든 마찬가지이며 가장 중요한 공통점이다. 그러나 실제로는 그렇지 않은 경우가 많다. 메인 분야도 잘 모르면서 역공학부터 파려 하는 사람들이 상당히 많은 편이다. 특히 이것은 코드 분야에서의 역공학 쪽이 더욱 심하다. 코딩은 거의 하지 못하는 사람들이 시리얼 크래킹이나 P2P 다운로드 프로그램의 속도 패치에만 열을 올리는 모습을 보면 이러한 아쉬움이 더욱 더 크게 느껴진다. 진정한 역공학의 의미와 기본 태도가 무엇인지 아는 자세가 필요한 것이 아닐까. 밥이 먼저인지 반찬이 먼저인지 파악하지 못하고 있는 모습을 보면 안타까울 뿐이다.

필자와 같이 일하는 한 팀원은 메인 업무가 개발이 아닌 리버스 엔지니어링이지만 항상 코딩 연구를 게을리하지 않고 있다. 역공학에 능하기 위해서는 정공학부터 빠지지 않아야 한다는 자세 때문이다. 이런 자세가 진정한 본모습이라고 생각한다. 그것이 아닌 경우는 자기 자신을 한번 뒤돌아볼 필요가 있다. 단지 역공학으로 무언가를 적출해내는 모습이 멋져 보이는가? 폼생폼사를 따지기보다는 본인의 기본 자질부터 갖춰야 할 필요가 있다고 본다. 역공학에 능하기 위해서는 정공학에 대한 이해부터 선행되어야 한다. 역공학과 정공학은 닭이 먼저냐 달걀이 먼저냐 하는 의미 모호한 토론과는 전혀 다르다. 역공학에 관심 가지는 것에는 좋다. 하지만 역공학에 막연한 환상을 갖고 접근하기 보다는 역공학이 무엇인지 그 기본부터 아는 자세가 필요하다고 본다.

nop 차번호

BrokenCode — Mon, 4 Aug 2008 12:00:59 +0900

평상시엔 보기 힘든 차입니다.
디씨 같은데서 퍼온것도 아니고 제가 주차장에서 직접 찍었슴다.
해커들에겐 최고의 차번호가 될듯 싶네요 ㅋ

개발자와 악기

BrokenCode — Wed, 30 Jul 2008 23:47:57 +0900

필자 메모 – 개발자와 악기
강병탁 / window31 (window31@empal.com / www.window31.com)

월간 마이크로소프트웨어 8월호 ("안티 디버깅과 리버스 엔지니어링 中)

대부분의 개발자들은 하루종일 코드와 씨름한다. 출근하자마자 코드를 보면서 하루를 시작하고, 밥 먹을 때에도 수저를 들면서 버그의 원인을 찾으려 머리를 굴린다. 퇴근 후에도 집에서 개인 프로젝트 혹은 취미 팀 프로젝트를 진행하며 코드와 시간을 함께 한다. 그 외 여분의 시간이 주어질 때나 주말 등의 시간에도 기술 서적이나 타인이 개발한 새로운 코드를 보며 내공을 연마한다. 개발자들은 잠잘 때 외에는 거의 대부분의 시간을 코드와 함께 하는 것 같다.

여기서 아쉬운 부분은 이처럼 상당수의 개발자들이 위와 같은 모습을 그리며 코드 외적인 부분에 있어서의 문화생활은 매우 폭이 좁다는 점이다. 개발자도 사람이며 코드를 보는 것 외에도 취미생활이 존재하며 가정이 필요하고 그 외적인 일상이 있어야 하는 법이다. 그러나 많은 개발자들은 코드 외에 딱히 즐기는 문화생활이 없고 별달리 할 줄 아는 것도 없는 채 뚜렷한 제2의 자신을 발견하지 못하고 있다. 그것은 무척이나 딱한 현실이다.

그런 사람들에게 가장 추천할 만한 것은 바로 개발자들에게 가장 어울리는 문화라고 생각되는 “음악과 악기”이다. 개발자들이 코드 외에 취미를 갖지 못하는 중요한 이유 중 하나는 바로 코드 외적인 부분에는 관심이 없거나 그런 문화는 아예 자신과는 맞지 않다고 선을 그어버리기 때문이다. 그렇다면 이들이 찾아야 할 문화는 무엇일까. 이들은 코드에 강하다. 그렇다면 문화생활도 코드를 사용하는 쪽으로 접근하는 것이 정답이 아닐까 한다. 이같은 상황에서 악기라는 객체는 개발자에게 가장 어울리는 것이라고 생각된다. 몇 가지 비교를 해 보도록 하자. 개발할 때에 코드를 사용하듯이, 악기 연주에도 코드 숙지는 필수 사항이다. 코딩하는 데에 문법이 있다. 그리고 문법에는 유형화된 패턴이 존재한다. 악보에도 역시 주로 사용되는 프레이즈가 있으며 코드 패턴을 많이 익히면 개발이 가능하듯이 주요 스케일 몇 개만 외우면 작곡까지도 가능하다. 서서히 공통점이 보이지 않는가? 필자는 C/C++의 코드나 음악 악보에서 등장하는 화음 코드나 별 차이가 없다고 생각한다. 코드에만 매달려 사는 개발자들도 조금만 관점을 달리하여 접근하면 훌륭한 악기 연주자가 될 수 있다. 그런 얘기가 있다. “유명 해커들은 반드시 한두개의 악기에도 프로급의 실력을 갖추고 있다.”. 코딩에 강한 독자, 별다른 취미가 없는 개발자인 독자들에게 말해주고 싶다. 악기를 손에 잡기를 권한다. 그러면 당신은 텍스트로만 이루어진 코드의 세상에 청각 예술을 결합시켜 제2의 헬로월드를 맛볼 수 있으며 코딩밖에 모르는 개발자라는 그림자에서 탈피할 수 있다.

:$

BrokenCode — Wed, 16 Jul 2008 22:10:29 +0900

죄송합니다.
저번달이면 대충 그만 바쁠줄알았는데 이번달도 여전히 속상하게 사는군요 :$
방문자수를 몰래 한번 봤을때 몇주째 볼거없는 블로그지만 아직도 와주시는 분들에게
무한한 죄송함을 느낍니다.

팀장의 거시기도 빨리 마무리해야 하는데 그것도 끝맺음을 못하고 있군요 lol
그간 헛소리 끌적이느라 리버싱 포스팅도 뜸했고 블로그가 점점 영양가를 잃어가는데
사이트가 썩어가는동안 그래도 나름 몸뚱아리로는 재미있는 소재거리와 많이 뜀박질을 했으므로
곧 싱싱하며 상큼한 코드의 뒤따마로 블로깅을 해보겠습니다.

이미지는 제가 짤방이나 모의해킹툴 제작에 쓰이는 이미지를 구할때 자주 방문하는
치트엔진 포럼에서 불펌했습니다.

Happy Birthday for Dark Byte !

BrokenCode — Tue, 1 Jul 2008 17:23:58 +0900

친구가 오늘 다크바이트 생일이라고 알려주길래, 아 그래? 하고 말았는데
아무생각없이 CE를 사용하다가 메시지박스가 뜬다는 것을 보았습니다 ㅋㅋ

다크바이트 생일축하합니다 !

개발자가 원하는 훌륭한 SE

BrokenCode — Sun, 29 Jun 2008 21:17:40 +0900

필자 메모 – 개발자가 원하는 훌륭한 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는 어떤 개발자라도 어떤 회사라도 환영할 수밖에 없다.