철수네 소프트웨어 세상 [본점]

소프트웨어와 관련이 있다면 뭐든지 – I no longer work for Microsoft.

Archive for 2월 2007

몰린 올블 후드티 수령 포스트들

leave a comment »

하루에 몰려서 포스팅 되었는데,

매일 5명씩 혹은 10명씩 발송해서 그 효과가 한달가량 가게 했다면 더 효과가 좋지 않았을까 하는 잡생각…

Written by charlz

2007년 2월 26일 at pm 4:38

Uncategorized에 게시됨

Me2day는 20% 프로젝트

leave a comment »

글 목록 – [2007년 2월 26일, 월요일] – Me2day

me2day1.png

15%도 25%도 아닙니다. 20%입니다. 거짓말이 아닙니다.^^

Written by charlz

2007년 2월 26일 at pm 2:27

Uncategorized에 게시됨

즐건 주말 매쉬업캠프

with 11 comments

오랜만에 토요일에 이어 일요일도 반납했다. 오전 9시 50분까지 연세대 상남경영원에 가서 매쉬업캠프에 참가하기로 했다. 그 이른시각부터 시작해서 저녁 6시까지 하는 행사이니 그리고 뒷풀이까지 생각하면 하루는 꼬박이다. 아무튼 때맞춰 도착하여 15번이라는 번호표를 받았다. 나중에 1등경품 엑박 2등경품 ipod이 14번이셨죠?

오전에는 다음과 네이버의 웹 API들을 모두 각기 설명하는 세션이었다. 딱 한가지 지적하자면 (질문도 했지만), API의 결과물을 RSS로 낼 경우에 RSS의 표준 Element가 아닌 것들은 namespace를 만들어서 XML 표준을 지켜야 할 것이고, 기왕이면 그 namespace를 다른 업체들과 표준화 내지는 암묵적 합의를 했으면 좋겠다. 여기는 전화번호를 telephone, 저기는 telno, 요기는 phoneno…이런 식 말고. Naver에서는 RSS를 여기의 spec을 참조했다고 했지만, 다음의 문구는 살짝 잊으신 듯:

RSS originated in 1999, and has strived to be a simple, easy to understand format, with relatively modest goals. After it became a popular format, developers wanted to extend it using modules defined in namespaces, as specified by the W3C. 

RSS 2.0 adds that capability, following a simple rule. A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace.

오후 세션에서는 실습 시간이었다. 어디로 들어갈까 하다가 회사 생각해서 VC 실습팀에 들어갔다. 한시간 좀 넘는 시간동안 Hands-on으로 Daum과 Naver의 사전 서비스의 OpenAPI를 사용해서 결과를 비교하는 응용프로그램을 살짝 만들고, 노트북이 없던 나는 열심히 듣…다가 졸았다;;; (너무 일찍 일어난 관계로!) 그리고 남은 한시간 멘토님의 여러가지 이야기를 듣고 모두 각자 소개를 했다. 언제나 사람들 각자의 이야기를 듣는 것은 즐거운 일.

실습이 완료된 5시, 각 팀이 만든 결과를 짧게 보여주었고, 마지막 두 팀이 멘토 실습이 아닌 직접 아이디어를 내서 만든 매쉬업을 시연하였다. 하나는 핸폰으로 사진을 올리고 LBS로 지도에 위치를 찍어주는 매쉬업과 다른 하나는 다음 인증 API를 OpenID와 연동하여 인증하는 매쉬업이었다. 모두 끝나고 두둥, 약 4:1밖에 안되는 경쟁률의 경품 추첨에서 역시나 구경만 하고(;;;)…뒷풀이로 이동. 뒷풀이 끝까지 못간 것 죄송해요~

득템한 아이템 중 차니님이 이번 행사(& 어제 자바 컨퍼런스)때 처음 뿌린 핸폰줄이라고 강조하시던…:

 img_3594.png

그리곤, 집에 가서 어머니 생신해드리는데 사용한 네이버 날개모자. 정가표가 붙어있어서 보니까 26000이더라.

img_3578.png

우리나라에는 해외의 매쉬업 붐(?)과는 괴리가 있는 환경이었다가 근래 포털들이 해탈을 하고 OpenAPI들을 공개하면서 이제 막 분위기가 형성되고 있다. 해외의 컨텐트는 그다지 어필할 만한 것들이 없었지만, 이제는 국내 컨텐트가 스물스물 오픈되고 있으니 그 분위기가 해외의 그 분위기를 넘어서는 그것이 되었으면 좋겠다. 단순한 매쉬업으로 엄청난 수익을 올리고 있는 그런 사례도 나오고 하기를. 그런 의미에서 이런 매쉬업 행사는 대환영! 그냥 단발성으로 수익과 연결되지 않는 점을 들어서 사그라들지 않기를 바라며, Yahoo! Pipes과 같은 형태로 쉬운 매쉬업을 만들 수 있는 방법들도 생기기를.

아울러 이렇게 행사도 회사들이 매쉬업되어 하는 경우가 늘었으면 하는 바램도 지속적이기를.

Written by charlz

2007년 2월 26일 at am 12:57

Uncategorized에 게시됨

나에게 지금 아쉬운 회사/직책은…

with 4 comments

현재 다니는 훌륭한(?) 회사의 훌륭한(?) 직책에도 불구하고 나에게 지금 찡하니 아쉬운 회사/직책은…

  • 훌륭한 인재를 직접 찾고 발굴해서 직접 원하는 팀을 만들 수 있는 회사. – 미국으로 transfer하지 않는 한에는 지금 회사에서는 거의 불가.
  • 회사 내부에서 (예를 들면) 오픈! 오픈!등의 구호를 모두에게 외칠 수 있고, 외쳐도 통할 수 있는 직책.
  • 업무와의 상관성을 따지지 않고 원하는 유료 컨퍼런스 마음껏 지원해주는 회사. – 비싼 컨퍼런스 비싼 교통비 업무시간 준수 ㅜ,.ㅜ;
  • 일 이외에 있어서는 직장인 마인드 직원보다 학생 마인드 직원들과 더 많이 일하는 회사. – 정적인게…확실히 늙는 느낌이 난다.

또 뭐 많았던 것 같은데…클클클

Written by charlz

2007년 2월 25일 at am 2:39

Uncategorized에 게시됨

자바개발자컨퍼런스갔다가 ImagineCup 2007갔다가

with 4 comments

피곤하니 짤막하게…

아침에 오전심사하러 ImagineCup 2007 소프트웨어 디자인 부문갔다가, 오후에 자바개발자컨퍼런스갔다가, 다시 ImagineCup 2007 오후 시상식보러 갔다온 날.

아침 7시 30분까지 가서 브리핑 듣고 8시부터 심사를 해야돼서 수년만에(는 아니고…) 6시 30분에 일어나서 회사로 출동. 어제 소개할때 회사 일 땜시 늦게 가서 좀 덜 적응된 상황에서 어리버리 심사. 이번에는 10팀을 둘로 나눠서 5팀씩 심사하여 2팀씩, 총 4팀을 선발했고 오후에 그 중 1,2,3등을 가리게 되었다.

일단 자바컨퍼런스를 등록했기 때문에 코엑스로 출동. But…

자바컨퍼런스는 두세션듣다 사람들이 특정 세션에 왕창 몰리는 바람에 들어가지도 못하고 그냥 나와서 시상식으로 향했다. 이런 식으로 사람이 몰리는 것을 탓할 수는 없지만, 배치를 좀 잘하고 제목도 적당히 잘 정해서 적절히 분배해줬으면 좋았을 것을.

섬유센터로 졸린눈에 어슬렁 다시 4팀의 발표를 들으러 갔지만, 첫 팀은 놓치고 3팀만 구경했다. 윤종수 판사님은 자바컨퍼런스에서 발표하시고, 여기 또 와서 심사하고 계시더라는. 결국 1,2,3등 가려졌고 1등만 8월 세계대회에 나가게 되었지만, 모두가 다 수고했고 멋졌다는 +_+)b

참 좋았음. ImagineCup 2007은 젊은 친구들 풋풋한 열정에 좋았고, 그냥 즐거워하고 열심인 학생들 구경하느라 파장되기 전까지 기웃기웃. 한 팀은 고3 올라간 친구들이었는데 집에 가는 길에 회사에 데려다 주는 동안 잠깐 담소를 나누었다. 입상은 못했어도 아직 ImagineCup에 5번 이상은 더 참여할 기회가 있으니 힘내.

내가 젋다고 생각해도, 주변 사람들이 나이가 더 어렸을때처럼 하지 않는 환경때문에도 이제는 그들처럼 하기 쉽지 않은 나의 모습이 좀 대비되기에 서글플 수도 있지만, 그냥 구경하는 것만도 즐거운 것이 오히려 난 더 좋은 하루였다.

Written by charlz

2007년 2월 24일 at pm 8:34

Uncategorized에 게시됨

Google Apps, 99.9% SLA 흠흠

with 3 comments

Gmail Service Level Agreement

구글의 Google Apps 패키지 공개로 웹이 떠들석하다. 뭐 다른 분들이 장단점 소개나 예측/비교/평가등을 써주시겠지만, 그것 말고 이 SLA(Service Level Agreement)를 살짝 본다. 99.9%나!가 아니다. 99.9%밖에다. 세계적으로 돈받고 이메일을 호스팅하는데 99.9%라니, 그 규모때문일까나.

이전에도 포스팅한 적 있지만 99.9%는 1년중 업무시간으로 하루(8시간)는 이메일을 못써도 된다는 뜻이다. 업무를 하는데 이메일이 마비되면 곤란한 회사들이 한두군데겠냐마는, 역시나 일반 유저들의 입장에서는 수용할 수 있는 숫자일 수도 있겠다.

참고로 SLA를 하면서 99.뒤의 9 갯수로 위용들 과시하기도 한다. 그냥 Fact만 전달한다: 계산하기 귀찮아서 구글검색으로 다음의 표를 구해왔다.

Uptime – Downtime Per Year

90% – 876 hours

95% – 438 hours

99% – 87 hours, 36 minutes

99.5% – 43 hours, 48 minutes

99.9% – 8 hours, 45 minutes, 36 seconds

99.99% – 52 minutes, 33 seconds

99.999% – 5 minutes, 15 seconds

99.9999% – 32 seconds

100% – 0

다음은 구글의 SLA 중 보상에 관한 내용이다:

“Service Credit” means: (a) three days of Service added to the end of Your term for the Service, at no charge to You, if the Monthly Uptime Percentage for any calendar month is between 99.0% and 99.9%; or (b) seven days of Service added to the end of Your term for the Service, at no charge to You, if the Monthly Uptime Percentage for any calendar month is between 99.0% and 95.0 %; or (c) fifteen days of Service added to the end of Your term for the Service, at no charge to You, if the Monthly Uptime Percentage for any calendar month is less than 95.0%.

87시간(주야3일) 이하 마비되면 3일 공짜, 438시간(주야18일) 이하 마비되면 7일 공짜, 그 이상 마비되면 15일 공짜. 서비스 아예 1년내내 안돼도(그럴 리는 절대 없겠지만) 고맙게 15일 공짜로 추가해준다.^^

Update: gofree님이 지적해주신대로, 제가 실수를 했군요. 한달을 기준으로 다시 작성했습니다(이번에는 Fact…겠죠?^^). 한달 30일 기준으로 0.3일 이하 마비되면 3일 공짜, 1.5일 마비되면 7일 공짜, 그 이상 마비되면 15일 공짜. 서비스가 아예 1달 내내 안돼도(그럴리는 절대 없겠지만) 고맙게 15일 공짜로 추가해준다.^^ 1년이 12달이니 1년내내 서비스가 안되면 180일을 공짜로 준다는 이야기다.

Customer Must Request Service Credit. In order to receive any of the Service Credits described above, Customer must notify Google within thirty (30) days from the time Customer becomes eligible to receive a Service Credit. Failure to comply with this requirement will forfeit Customer’s right to receive a Service Credit.

이것도 사용자가 따로 요청을 해야된다는 조항이다. 30일 지나면 무효.

재밌지요?

Written by charlz

2007년 2월 23일 at am 1:33

Uncategorized에 게시됨

나이를 먹는다는 것

with 2 comments

나이를 먹으면서…아니, 경험이 쌓이면서 어른이 된다는 것이 무엇인가를 조금씩 맛보게 된다. 실제로 경험하기 전에는 세상을 이해하는 것이 쉬운 것이 아니라는 사실이 실제로 피부에 와닿으면서 드는 생각이, “아! 이런 것들을 말로 전해줄 수 있는 방법이 있다면 얼마나 좋을까”이다. 어른이 되면 무뎌지고 젊었을때의 패기가 없어지고 좋지 않은 세상사 무시하게 된다는 이야기들을 하지만, 점점 나이를 한살한살 먹으면서 드는 생각은 그것이 아니다. 되려, 민감해져서 이해하고 포용하게 되고, 무대뽀인 패기가 좋지 않은 결과를 낳는지를 깨닫게 되고, 좋지 않은 세상사가 왜 좋지 않게 되었는가를 피부로 겪고 바꿀 수 없는 것은 바꿀 수 없다는 것을 알게 된다. 내 속의 화를 다스리는 것 역시도 아마도 그 화를 꼭꼭 담아 눌러두는 것이 아니라, 세상의 순리를 깨닫고 그 화의 크기를 조절하는 것이리라.

“이해한다”는 말의 의미를 이제야 조금 알게되면서 서른 두해만에 이 정도면 짧은 것일게야, 하는 위안을 가지고 떡국 한 사발 먹고 나이 한살도 더 먹었다.

벌써 2007년이다? 아니 이제 2007년이다.

Written by charlz

2007년 2월 20일 at pm 6:32

Uncategorized에 게시됨

철수야 놀자의 철수님…

with one comment

철수야 놀자 ::

이올린 보는데…철수야 놀자의 철수님의 포스트;; 저와는 완전 다른 내용의 블로그 내용을 쓰십니다. 동닉이인(同Nick異人).

성함이 철수실까요. 구글애드의 남자ㄴㄷ같은 저 단어들에서 느껴지는 포스…저는 웬지 간판 내려야할 것 같은 ㅜ,.ㅜ;;

Written by charlz

2007년 2월 15일 at pm 11:46

Uncategorized에 게시됨

추천 블로그 릴레이…라는 어려운 작업이

with 2 comments

추천 블로그 릴레이…라는 어려운 작업이…제게 할당되었습니다; 링블로그에서 시작했나보군요. 이런거 할때마다 고민이 많이 됩니다. 좋은 곳이 한두군데라야죠. 그렇다고 추천해서 예전 likejazz효과나 스마트플레이스효과 그런게 있는 블로그는 아닌지라 책임감은 덜하지만서도요^^

영문 블로그로 릴레이하면 거기서 끊길테니 난감할 것 같고, 그렇다고 이미 진솔함(?)으로 유명하신 분들(만박님이 좋아하시는 주린대하는 이나 erehwon님 좋아하시는 레진사마 아니면 leegy, goara, 동사서독 등등 매니아형)을 링크하는 것도 어디선가 할테고, 지인 블로그도 속보이니까(;;) 좀 그렇고…저는 그냥 제가 재밌다고 생각하는 이기적인 분류로;;

http://www.thinkbrush.com/think/index.php – 대빵 좋아하는 그림 스타일의 일러스트레이터분 블로그.

http://mentalese.net/blog/, http://janice.kaist.ac.kr/~gomeisa/blog/ – 나와는 사고패턴이 완전히 다른듯해서 구독하는 블로거분들.

http://gyuhang.net/ – 고래가 그랬어요. 나중에 애낳아 키울때 참고하리라 다짐한 블로그 중 하나. 우리 아이(들)은 절대 나처럼 안만들거니까.

http://emusic.egloos.com/ – 전자음악 알아보기! 저도 음악에 관심 많다고요.

http://www.infocommune.net/CLS/ – 내가 법에 대해 아는바가 쥐뿔도 없기에…

http://paper.cyworld.nate.com/halflife62/ – 가수 박지윤의 페이퍼블로그. 그냥 다른 연예인 블로그 같지 않아서. 혹시나 릴레이 받아줄까봐…는 아니고. =3=3=3

몇개까지 하는게 좋을까요;;; 여기까지..ㅎㅎㅎ

Written by charlz

2007년 2월 15일 at am 12:11

Uncategorized에 게시됨

SDET는 테스터와는 다른 직책이다.

with 4 comments

이전에도 여러번 언급했었습니다만, 마이크로소프트에는 SDET라는 직책과 STE라는 직책이 있습니다. SDET는 Software Design Engineer in Test이고 STE는 Software Test Engineer입니다. 직책의 역할(Job Role)이 둘간에 확실히 구분되어있는데, SDET는 우리나라에서 이야기하는 프로그래머와 같은 선상에 있는 직책을 이야기합니다.

오늘은 외부에 나가서 거기서 뭘하냐는 질문에 테스터다라고 대답한다는 사실에 대해 꾸중을 들었습니다. 그건 니 자신을 깎아내리는 짓이라고. 회사에서 그냥 일반적인 테스터는 STE를 이야기합니다. SDET가 아닌 테스터라는 역할이 작다거나 하는 뜻이 아니고, 또한 일반적인 테스터 이야기가 아니라 Sofware Test이기 때문에 더더욱 그렇습니다. 제가 하는 변명은 그것을 이해해줄 사람이 얼마나 있겠느냐는 것이었지만, 아무튼 저는 제 자신을 위해서 SDET라는 것을 널리 홍보해야하는 상황이기도 한 것은 맞는 것 같습니다. 이전에도 적은 적이 있지만 또 한번 이야기해봅니다.

Software를 테스트하는데 있어서 Software의 모든 전반에 대해 이해 정도가 있는데, 그 이해의 깊이에 따라서 STE냐 SDET냐로 옮겨가게 됩니다. 요는 Software의 Design에 대해서 얼마나 이해를 하고 있느냐는 것이고, Software의 Design을 이해하기 위한 요소 중 큰 부분 한가지가 프로그래밍이라는 사실입니다. 참고로 이해를 위해 이야기를 하면, 마이크로소프트에서는 개발자를 SDE(Software Design Engineer)라고 합니다. 말그대로 Software의 디자인에 관여하는 엔지니어라는 뜻이겠죠.

테스터의 역할은 테스팅이라고 하겠지만, SDET인 저의 정확한 역할은 잘못 혹은 엉터리 혹은 미비하게 짠 코드/기획으로 인한 버그를 찾고 그 원인을 밝혀서 어떻게 고쳐야할 것인지를 판단하고 이를 제시하는 것입니다. 이 말은 단순해보이지만 사실은 여간 복잡한 것이 아닙니다. 여러가지 요소에 대해서 쭉 나열을 해보죠. 첫째로, 그 이면에는 “문제”라는 것이 문제인 딜레마가 있습니다. 항상 그런 것은 아니지만, “문제”를 들이대면 좋아할 사람은 별로 없다는 것이죠. “문제”임에도 불구하고 “문제”가 아닌 것으로 해결하려는 경우도 굉장히 많습니다. 그래서 직접 남의 코드를 노가다로 들여다보고 디버깅하고 증거(?)로 들이대야하는 작업도 계속 생깁니다. 디버깅이라면 재미있겠지만, 증거찾을라고 남의 코드 분석/디버깅하는 일은 좀 그렇죠.

둘째로, 문제를 찾는 방법적인 것이 하나의 학문화되고 있는 부분입니다. 학문이라고 할 정도로 큰 영역이 되었다는 것이 새삼스러운 것은 아니지만, 그만큼 방대한 영역이고 어려운 영역이며 부각이 되는 영역이라는 것이기도 합니다. 테스트에 관한 논문들도 계속해서 나오고 있고, 책들도 계속해서 나오고 있죠. 그리고 테스트의 방법론은 분야만 바꿔도 적용이 안되는 경우가 허다하기도 한 영역이기도 합니다.

셋째로, 또하나는 가장 중요한 스케줄/리소스/예산등과의 밸런스입니다. 이것들이 무한대라면 모든 것을 테스트하고 완벽한 제품을 낼 가능성이 높아질 수 있다고 하겠지만, 그렇지가 못합니다. 우선순위를 매겨서 낮은 것들은 눈물을 흘리면서(?) 포기해야하는 것이 개발자들과 마찬가지로 SDET의 고충이기도 합니다. 더더욱이 작은 업체 작은 팀이라면 오히려 이런 리소스들이 영역에 비해 더 작기 때문에 더 무시하면 안되는 이유가 됩니다. 이런 문제들을 해결하는 것도 테스팅의 역할에는 들어가 있다고 하겠습니다.

넷째로, 문제(쉽게 버그라고 생각하면 좋을 것 같습니다)라는 것은 그 영역이 방대합니다. 어제 댓글에서도 언급한 내용이기도 한데, 한때는 마이크로소프트 내부에서도 SDE들이 TDD를 하는 것이 SDET의 영역과 겹치지 않느냐는 이야기가 있던 적이 있습니다. 하지만, 실제 테스팅을 하면 Unit Test나 BVT 정도로 잡는 버그로는 택도 없다는 수치적인 결과가 나옵니다. TDD는 개발자가 자신의 코드를 자신이 생각할 수 있는 만큼만 ensure하는 것이지, 실제 제품의 영역에 있어서는 큰 커버리지를 감당할 수 없습니다. 마이크로소프트에서도 SDE들이 TDD로 제품을 개발하기 시작한지 꽤 되었습니다. 표준 준수를 검사하는 Test Kit도 한 예일 것입니다. 수천개의 TestCase를 두지만, 그것을 통과한 다른 제품이라고 해도 무조건 서로 연동이 가능하지 않고, 연동/준수를 해결하기 위해서 또 무던히 테스트를 해야합니다. 다운되는 것만을 문제라고 하지 않고, 사용자가 불편해하는 사용성 부분도 문제 영역에 포함됩니다. 기획자가 잘못 기획했다면, 그것을 raise하는 것도 역할이라고 하겠습니다.

다섯째로, 노력에 비해서 성과가 작아 보일 수 있습니다. 버그 하나 고치는 것이 쉬울때는 행복하지만, 몇달/몇년이 걸릴 정도로 어려운 것들도 있습니다. 그렇게 본다면, 버그 하나 고치기 위해서 엄청난 비용을 들이는 것입니다. 버그의 경중을 떠나서 갯수로만 보면 그 역할이 필요하기나 한지 의심될 수도 있겠죠. 하지만, 그 버그의 수정으로 창출되는 부가가치를 보는 것이기 때문에 SDET라는 직업이 있는 것이기도 하겠습니다.

여섯째로, 반복되는 작업들은 자동화한다는 것입니다. 자동화라함은 테스팅을 위해서 테스트를 하는 프로그램을 짠다는 뜻인데, 이 말을 잘 살펴보면 재미있는 결과가 나옵니다. 테스팅을 하는 프로그램도 Software이기 때문에 문제가 발생한다는 것입니다. 결국 테스트를 하는 프로그램 자체도 일의 연장선이 되는 것이죠. 테스트를 위한 프로그램은 다양한 상황에서 동작해야되기 때문에 다양한 상황을 위한 수정을 하는 Robustness를 보장하는 기간이 따로 존재하기도 합니다. 저는 한국에서 한국 제품을 테스트하기 때문에, 원격 테스트의 편의를 제공하고, 다양한 한글OS에서 동작하도록, 한글 제품에 맞는 프로그램으로 만들어 주거나 직접 수정해서 사용 해야합니다. 반대로 자동화가 불가능한 것들은 시간을 들여서 직접 테스팅(Manual Testing)을 해야합니다. 아주 쉬운 예가 “게임” 테스팅이겠죠. 그냥 게임을 하면 되는 것이 아니냐는 이야기는 절대 틀립니다.^^ 게임을 즐기는 것이 아니라, 모든 상황을 구석구석 본화면 보고 또보고 해가면서 시간을 많이 사용해야하는 작업을 짧은 시간내에 하는 일입겠습니다.

일곱째로, 이런 테스트와는 별도로 제품에 익숙해지기 위해서 공부를 따로 해야한다는 것입니다. 제품을 사용하여 높은 생산성을 발휘하는 것은 다른 역할이기에 잘 써야되는 것은 아니지만, 어떤 기능이 있는가, 어떤 것이 되는가 안되는가를 알아야합니다. 어떤 문제가 있을때 이에 효과적으로 대처하기 위한 필수 사항이라고 하겠죠. 자기도 모르는 제품을 테스트한다는 것은 어불성설이겠죠.

여덟째로, 일반 Software의 플랫폼이 굉장히 다양 다분화되었습니다. OS 뿐만 아니라 Browser도 플랫폼이 되었고 하드웨어 아키텍쳐도 여러가지입니다. 저는 솔직히 98 지원이 중단된다고 했을때 좋아한 직업 중 한 직업입니다. 98은 이제 테스트 안해도 되는구나! x64 아키텍쳐가 보편화되고 있는 상황이 미운 직업이기도 합니다. 하나를 테스트해도 XP/2003/Vista와 x86/x64(or ia64)의 조합으로 해야합니다. 조만간 나올 롱혼 서버도 또하나의 플랫폼이겠죠.

아홉째로, 저(저희 팀)한테 국한된 이야기지만(현재 SDET 2명 총 6명), 제품이 한두개가 아니라는 것입니다(여러서비스를 하는 온라인 회사들도 그런 예가 되겠죠^^). 제가 테스트하는 비주얼 스튜디오 제품군을 위한 PU(Product Unit)는 30개가 넘습니다. 근자에는 Team Foundation Server라는 서버 제품도 만들었죠. 요즘 자주 회자되는 Expression 제품군도 4개의 제품으로 나뉩니다. 각 PU는 나름대로의 제품을 또 만듭니다. 최신 기술들인 비스타에 있는 .NET Framework 3.0도 저희 제품이고, WPF/E도 저희 제품이고, ASP.NET AJAX도 저희 제품입니다. 각 제품들은 또다시 서비스팩, 패치등을 비정기적으로 냅니다. OS가 업그레이드하면, 거기서 문제가 없는지도 테스트해야합니다.

되도록이면 어려운 용어는 빼고 이야기했지만, 위의 한문장처럼 간단하지는 않죠? 이외에도 하고 싶은 이야기는 산적해있습니다. 하지만, 기사가 아니고 그냥 머리에서 떠오르는 생각으로 적은 글이니, 이정도면 감은 올 듯 합니다. 다음주에 새로 SDET(스뎃;;;)이 늘어나는데, 이렇게 재미난 일인지 알고 입사를 하는 것인지 모르겠네요.^^

Written by charlz

2007년 2월 8일 at pm 8:24

Uncategorized에 게시됨

%d 블로거가 이것을 좋아합니다: