programming way of system engineer

이번 기술부 지원 프로젝트에서 경험했던, 'SE의 프로그래밍을 서포트한 2009년 여름 프로젝트'는 굉장히 색다른 느낌이었습니다. 이 이야기를 적어볼까 합니다.

서포트를 나가게 된 배경은 다음과 같습니다.
2008년 리만브러더스 파산과 더불어 시작된 불경기, 그리고 사내 파견사원의 감축과 정사원위주만으로의 운영, 신규프로젝트 발생과 기술부 리소스부족(perl과 python코딩에 대한), 개발부에 지원요청과 해당 경험이 있고 덜 중요한(?!) 리소스(바로 접니다)의 지원제공.

1. 굉장히 간결한 방식을 선호(shell script를 확장한 것과 같은 느낌의 프로그래밍.)

'심플한 것이 아름답다'라는 프로그래밍에서의 정석이 있습니다만, 정말 그것을 실천하려고 애를 씁니다. 특히, 한 줄 코드로 가능할 수 있다면, 그렇게 하려고 애를 씁니다. 여기서 몇가지 지금까지와는 다른 상식으로 진행되었는데, 예를 들면,

1) 가능하면 클래스는 사용하거나 작성하지 않습니다.
어차피 pointer를 tie하는 것에 지나지 않는 클래스를 생성하려고, new하는 한 줄의 코드를 작성하는 것은, 불필요한 리소스 낭비로 여기어 지는 것 같았습니다.

2) parameter는 주로 array of hash reference
hash reference인 것은 이해가 가지만, 그것의 array였다는 것은 좀 색달랐습니다.

3) 리턴값, int형 보다는 (rc, rm)의 배열.
rc는 return code, rm은 return message입니다.(간혹 엔지니어에 따라 rv 즉 return value로 사용하는 경우도 있었습니다.)
리턴이 perl의 subroutine이든, python의 method이든, 실패했을 경우 그 이유를 알기 위한 메시지를 함께 전달합니다. 실패라면 exception을 함께 전달하는 느낌입니다.
문제없이 진행되어 rc가 성공이라면, rm은 해당 리턴값을 가지게 하는 설계가 많았습니다.

4) 리턴값, 0 = 성공, 1 = 실패
이는 시스템 커맨드의 리턴(batch라면 errorlevel)이 대게 에러번호를 리턴하는데 기인합니다.
개발자로서의 인식으로는 non-zero = true, 0 = false 이기 때문에 checkData와 같은 함수의 리턴이 1(true)라면, OK라는 인식이지만, SE에게는 NG라는 인식입니다.
이는 정의하고 진행하면 되는 것이기 때문에 특별히 문제는 없었습니다만, "음? 성공하면 0입니까? (성공하면 false입니까?)"하고 물었을 때, '음? 당연한 것을 왜묻지?'하는 느낌의 반응은 약간의 이질감을 느끼게 되더군요.


2. 놀라운 시스템 관련 지식.

이것은 말할 것도 없습니다. (모든 SE가 다 그렇지는 아니겠지만) 굉장히 정확한 지식을 가지고 있었습니다.
이런 예가 있었습니다. 한번은 '어떤 명령어 | sed xxxxx'와 같은 외부 프로세스를 실행한 결과를 치환해 값을 받도록 실행하는 코드를 작성한 적이 있었습니다. 이때 다른 명령어는 모두 문제가 없었는데 어느 특정 한 명령어는 프로세스가 종료하지 않고 메모리에 남아 있게 되는 일이 있었습니다.
이를 SE에게 문의했는데, 추적하는 것을 보여주더군요. 값진 경험이었습니다.

우선, ps상 이 프로세스가 defunc가 아니었기 때문에(좀비가 아니었기 때문에) 폭주인지, 아니면 무엇을 하고 있는지 strace를 통해 pid에 걸어서 무엇을 하고 있는지 알아보더군요. 지금까지 나 이외에 strace를 사용하는 것을 '직접' 본 두번째 경험이었습니다.)

우선은 표준입력을 기다리고 있는 것을 알아내어 폭주는 아닌 것을 확인했습니다. 그다음 왜 표준입력을 기다리고 있는지 알아보았는데, 그 '특정 명렁어'가 표준 출력으로 출력하는 것을 모두 /dev/null로 돌려놓고 있었더군요. 결국 sed는 뭔가 파이프로 전해져 오는 것이 없었기 때문에 sed가 입력을 기다리고 있었고, child의 pid를 수확하지 못하고 있기 때문에 parent의 '특정 명령어' 및 shell이 살아남아 있는 것이었습니다.

이때 잠깐 질문을 제가 했는데, sed를 echo로 바꾸면 정상종료하는데, 그 차이를 잘 이해하지 못하다라고 얘기했을 때, 설명을 받았습니다.
이때 그는 파이프 처리에 관련된 설명을 하면서 File Descriptor라는 용어를 사용해 설명하였는데, 나는 시스템 프로그래밍 기사나 책을 읽으면서 몇번 본 적은 있지만, file descriptor라는 단어를 내 입으로 조차 발음해 그 소리를 내 귀로 들은 적이 한 번도 없었는데, 이때 설명받으면서 들은 것이 난생 처음이었습니다.(그만큼 그 개념을 직접 말해 설명하는 것을 듣는 것이 굉장히 드믄 일입니다.)

3. 기타

<작성중>

1) 자기가 작성한 코드는 장해 발생때 대응하는 사람이 살펴보고 긴급히 수정해 대응할 수 있어야 하는 코드

2) '로직을 아직 다 못썼습니다.'

3) '단순한 버그이기 때문에 위치를 알면 곧 수정해 대응이 가능합니다.'
대신 환경(장비상의, 또는 시스템상의) 이나 데이타의 대응이 훨씬 더 큰 일.