자칭 geek 들의 모습

scjd2010의 이미지

자존심하나로 산다고 한다.

그렇게 대놓고 말하지 않지만, 그 태도나 행동, 툭툭 내 뱉는 냉소적인 말한마디가 그것을 그대로 보여준다.
그러다가, 항상 말이 없고, 바보같아 보이고, 말도 잘 안 통하는 동양에서 온 거지발싸개같은 녀석에게 한방 제대로 먹는다.
"여봐요 팀 (그의 이름이다), 그거 SOAP 에 SSL 거는건데 제대로 테스트 해 보고 된다고 한거 맞나요?"
"당연하지. 내 테스트 environment 에서는 잘 돌아가던데 뭐. 왜?"
최근에 운영체제 (Operating System) 을 upgrade 했기때문에 시스템 자체의 컴파일러가 아닌 g++ 로 컴파일한 코드가 잘 도는지 테스트를 해야 하고, 그 확인을 가장 똑똑하다는, 성질은 개같은 자타칭 geek 인 팀이 맡아했고, SOAP 과 SSL 을 사용하는 인터페이스 프로그램이 잘 도는지도 그가 확인하는것으로 되어있다.

자리로 돌아와 하나 하나 따져보았다.
워째 저 도사님이 테스트한 프로그램이 prod environment 에서 뒈졌냐 이거지...
그럼 이 프로그램 짠 내게 책임도 돌아오고, 원인도 금방 모르겠고...
로그를 자세히 살펴본다.
올타꾸나! HTTPS 여는 데서 떨어졌네! 그런데 왜 팀 environment 에서는 잘 도냐?
그럴지도 몰라. 팀의 control file (일종의 프로그램 기동 프라퍼티랄까 configuration 이랄까, 뭘까.. 하여간에) 을 열었다.

그럼 그렇지... HTTP 로 여는데 SSL 이 불러지냐고요~!
여러분도 알겠지만, C 던 Java 던 일반 애플리케이션에서 상대방의 HTTPS 를 열어 통신하려면 SSL 이 불려지고, HTTP 를 열면 SSL 이 불려지지 않는다. 즉 팀의 경우 에러가 안나는 이유는 HTTPS 가 아닌 HTTP 로 열었기때문이다.
"어~이! 팀! 너 HTTP로 불러서 괜찮은거야! HTTPS 로 해 봐라! 되는지!"
"..... 어 그러네!"

찾아낸것은 대견하나, 그렇다고 문제가 해결된것은 아니다. 아직은 왜 떨어졌는지 (prod 에서 HTTPS 열어 통신하는게) 원인 불명이니 좋아할때가 아니잖은가. 그걸 아는 팀이 가만 있겠냐고.
"그래, 그럼 왜 문제가 생겼을까?"

다른일도 바빠죽겠는데, 메니저는 결국 내게 원인파악하라는 숙제를 주고만다.
잘 할 수 있으리라는 기대도 있겠지만, 해당 프로그램을 짠 사람이 책임을 지게 하는게 당사자를 존중해주는것이고 시니어 엔지니어를 대접해 주는 방식이다. 만약 이걸 팀이나 다른 사람에게 던져주면, 난 더 열받겠지!

다행히 원인은 금방 알 수 있었다.
빌드를 하는 그룹에서 g++ 빌드시, 일반 유닉스나 라이넉스에 통하는 O3 옵션을 넣은게 화근이었다.
일반 유닉스나 라이넉스에서는 O3 옵션이 SOAP 을 사용하는 코드의 최적화를 잘 해 준다. 하지만, 회사시스템은 OLTP 기종이고 O3 옵션을 곧이 곧대로 사용하여 이런 재난이 일어난것이다. 바로 전 버젼 OS에서는 잘 돌았다. 하지만, 이번 새 버젼 OS 에서 이부분까지 꼼꼼하게 신경써서 운영체제를 만들지 않았던것 같다.

O3 옵션때문이라는것을 회의시간에 꺼냈다. 팀이 반격한다. 그럴리가 없다는것이고, 반드시 O3 옵션이 필요하다는것이다.
과연 그럴까? 한번 그럼 네 프로그램으로 직접 빌드해보고 SOAP 의 SSL 콜 부분이 어떻게 바뀌는지 보고 와서 말해라. 하고 댓구하자 맞은편에 있던 메니저가 내게 고개를 꺼떡꺼떡 한다. 아무도 함부로 팀에게 대적을 못했었다. 메니저나 부장도.

..

결국은 내 판단이 옳았다. 지금 잘 돌아가고 있다. (거래량이 적어서 그렇지...)

geek 이라고 스스로 자아도취되지 마라.
나같은 거지 발싸게, 점심시간 마다 찹찹 거리고 스팀드라이스에 계란말이 쏘세지 일본장아찌 먹는 하잘것 없는놈한테도 자존심 구기는 일 생긴다. 열심히 하는 놈한테는 아무도 못당한다.
자기가 얼마나 뭘 모르고 있는지 아는게 중요하다.
내가 아는것은 남들도 이미 다 알고 있다는 생각을 해야 한다.

동양이든 서양이든 통하는것은 하나다.
열심히 해야 하고, 진실되어야 하고, 편견을 버려야 한다.

머지않은 시간에 그룹차원에서의 대 이동이 있을거라는데, 솔직히 두렵다.
덜 무서우려면, 준비가 잘 되어 있어야 한다.

서울지사의 시스템부서 쪽에 대가리(head)로 전출나가는 꿈을 꾸어보면서 잠자리에 든다. 역시 꿈이겠지만...

innobeing의 이미지


scjd2010 님에 경의(敬意)의 박수를 보냅니다!     성공하시길...!

권순선의 이미지

재미있게 잘 읽었습니다~

웃는 남자의 이미지

서울지사로 전출에 성공하시길 바랍니다 ^^

----------------------------------------
Nothing left after Nirvana.

----------------------------------------
Nothing left after Nirvana.

sloth_의 이미지

내용무

jick의 이미지

세상 어딜 가나 성질 더러운 놈은 있죠.

(앗 말해놓고 나니 찔리는군요...)

baboda4u의 이미지

정말 배움의 연속인것 같습니다. ㅠ_ㅠ

============================
Stay Hungry, Stay Foolish

============================
Stay Hungry, Stay Foolish

johan의 이미지

사실 그런 문제는 프로덕션 시스템에 가기전에 걸러졌어야 겠죠. 즉 회사 개발/테스트/디플로이먼트 프로세스에 문제가 있다고 봐야겠죠. 제 일터였다면 개발 후 최종 커밋 직전에 프로덕션 시스템으로 갈 바이너리로 해당 테스트 및 기존의 모든 테스트를 통과해야 작업에 마침표가 찍힙니다. 그 후에 QA 팀에서 주어진 시나리오에 따라 프로덕션 시스템으로 갈 바이너리로 다시 점검합니다. 프로덕션 시스템에서 문제가 생기는 일은 그외의 일들이어야 한다고 봅니다.

작은 승리에 연연하지 말고 계속 전진하시길...

scjd2010의 이미지

미국도 직장마다 특유의 관행이랄까 시스템이 있더라고요.
전에 있던 직장에도 여기에도 QA 부서가 따로 있습니다. 그리고 말씀하신대로, 최종 릴리즈전에 빌드한 엑시큐더블은 프로덕션시스템과 동일한 환경을 가진 테스트시스템에서 며칠간 돌아가게 되어있습니다. 그래서 그렇게 했을터이고요. 별문제없이 돌아가는것으로 보인것은 해당 라인드라이버 프로그램의 콘피그를 HTTP 로 해서 상대방 테스트 사이트를 열었기 때문이지요. 상대방 시스템이 HTTPS 로만 열리게 한것이라면 그 단계에서 확인이 되었겠지만, HTTP 로도 열리고, SOAP 기능이 모두 가능하거든요.

대부분의 작은 결함이랄까 실수가 그렇듯, 결국은 또 컨피그 문제였지요.
거기에, 개발부서에서 킹왕짱으로 불리는 "팀"이라는 사람이 검수를 한것이니 메니저도 믿겠거니 하고 그냥 프로덕션으로 넘긴겁니다. 사소한 부주의였지만, 프로덕션에서 바로 와장창 떨어지는 굴욕적인 사건이죠.

사람이 하는 일이다보니 이러저러한 실수는 항상 벌어지더군요, 제아무리 철저하게 해도 말입니다.
특히, 문제가 잘 발생하는데가 운영부서에서 컨피그 가지고 작은 실수를 한것이 나중에 시스템 전체에 파급되는 경우가 많던데, 특히, 옛날의 기종(메인프레임이나 온라인 트렌잭션 프로세서)을 사용하는 일터에서 이런일이 잦은것 같습니다. 전에 있던 회사에서 자바로 J2EE 환경구성을 해서 시스템을 만들고 돌리는 경우, 여러사람에게 코드와 컨피그가 잘 보여진다는 특성때문인지 문제가 덜 발생하고, 발생하더라도 조치가 훨씬 더 빨랐던것이 생각납니다.

어여 저도 큰 승리를 좀 챙겨야 할텐데... 열심히 하고 있습니다. 감사합니다.

Sr. Software Engineer
JP Morgan Chase Co., Card Services