sosa0sa.com

예전에도 한번 “잔업없는 회사”라는 내용으로 접한 적이 있었는데 우연히 어떤 글을 보고 다시금 찬찬히 그 회사의 글들을 보게 되었다.

(주)사이냅소프트

많은 IT업체가 그렇듯이 회사의 생활등을 블로그를 통해 접할 수 있다(우리도 IT업체인듯 한데 그러기엔 우린 엄살이 너무 심하지. 뭐 그리 숨길 게 많다고)

그 중에는 사이냅소프트의 전경헌 사장님과의 인터뷰 글도 볼 수 있는데 사장님의 생각을 통해 회사의 생활이 어떨 지 짐작할 수 있다(반론의 여지가 있는 말이긴 하다. 윗사람의 생각대로 회사가 움직인다고 단정지을 수 없기 때문이다. 구름 위에 있는 사람이 갖는 생각과 현실은 다를 수 있으니. 그래도 일단 들어보자)

그 중 일부다.

유용빈: 정치적 스트레스는 어떻게 해결하시나요. 회 사 내에 그런 스트레스가 얼마나 있는지 제가 잘 알지는 못합니다만 다른 회사에 비해서는 상대적으로 적으리라 생각합니다. 개발자들이 지원하는 역할에 머무르는 회사가 많은데 사이냅소프트는 저부터 시작해 영업 직원들도 개발자 출신이라 서로 이해하는 부분이 많아 갈등이 크지는 않습니다. 또 지난해 애자일 컨설팅의 컨설팅을 받으면서 회고하는 문화가 자리잡고 있습니다. 회고란 체계적으로 즐겁게 반성하고 개선점을 찾는 활동인데 그 이후로는 회사에 있던 문제들에 대해 서로 동등한 수준에서 의사 소통을 하면서 그와 같은 스트레스가 더 줄고 있다고 봅니다.

이국진: ‘가정을 지키기 위해 일찍 퇴근한다’는 글을 쓰셨는데 정시 퇴근은 잘 지켜지나요. 그 글은 2005년에 쓴 글입니다. 전에는 일을 굉장히 많이 했습니다. 결혼하고 나서도 아침에 일찍 출근하고 막차 시간이 거의 다 됐을 때나 새벽에 집에 들어갔습니다. 집에서는 잠만 자고 휴일에도 회사에 나와 일하기도 했습니다. 거의 일만 하는 사람이었죠. 일로서 성공하고 싶은 생각도 많았고요. 2005년은 큰 아들이 유치원에 다니던 해였는데 밥 먹으면서 유치원 생활에 대해 아들에게 물었는데 아이가 대답을 하지 않았습니다. 아내가 대신 이야기를 해줬지만 아들에게 직접 듣고 싶다고 말을 거니 아이가 “아빠는 알지도 못하면서 아는 체 해”라고 말했습니다. 그러고 보니 아이가 보기에는 자기가 일어나기 전에 회사에 나가고 자고 있을 때 집에 들어오니 자신에 대해 아무것도 모른다고 생각하는 게 당연하겠더군요. 물론 아내를 통해 아이가 어떻게 지내는지 늘 듣고 있었지만요. 굉장히 충격을 받았고 이게 제가 원하던 삶은 아니라는 걸 깨달았습니다. 아이가 태어날 때만 해도 크는 동안 많이 안아주고 좋은 이야기를 들려주고 싶었는데 열심히 일하다 보니 어느새 아이는 자라 학교 갈 나이가 되어 있더군요. 세상은 장기전이고 그러려면 가정도 지켜야 하고 저뿐만 아니라 직원들도 마찬가지라는 생각이 들었습니다. 그 때부터 열심히(?) 저녁에 일찍 퇴근하고 있습니다. 아이들이 굉장히 좋아하고요. 요즘은 간혹 집에서 저녁 먹고 들어오라는 전화가 옵니다.(웃음)

오랜 기간 몸에 밴 야근이란 습관을 되돌리는 데 반발은 없었나요. 야 근을 하느냐 하지 않느냐가 좋은 개발자를 판단하는 기준은 아닐 겁니다. 책임감이 굉장히 강한 개발자들은 맡은 일이 진전되는 것을 확인하려고 야근을 하기도 합니다. 야근 금지를 반대하는 개발자들도 있었습니다. 회사에서 뭐라 하든 ‘내 일이기 때문에’ 야근을 해도 상관 없다는 이유 때문이었죠. 소프트웨어 개발은 장기전이고 몇 달 바짝 해서 성공하는 게 아니기 때문에 자신의 건강과 가정을 지키며 일하자고 계속 설득해 지금은 야근 금지가 많이 정착되어 특별한 일이 있지 않는 한 다들 일찍 퇴근합니다.

지금도 개발을 하시나요. 예. 수시로 하고 있습니다. 직원들이 개발을 하다 문제에 부딪히면 같이 살펴보기도 하구요. 프로그래밍 공부도 꾸준히 하고 있습니다. 제품 코딩보다는 직원 교육을 위한 코딩 위주로 하고 있습니다. 최근에는 파이썬을 많이 쓰는데 아이디어가 떠오르면 파이썬으로 빠른 시간 안에 구현할 수 있어 직원들이 어떤 문제에 막혔을 때 그것을 푸는 데 도움이 될 만한 코드를 파이썬으로 짜서 보여주기도 합니다. 개발이 여전히 좋아 은퇴 후에도 코드를 짜는 걸 즐기지 않을까 합니다.

앞으로 구상이 있으시다면 소개해 주세요. 지 금까지 한국 소프트웨어 개발사들을 보면 유명 개발자 한두 명에게 크게 의존하는 경우가 많았는데 그런 방식에는 한계가 있다고 봅니다. 문화를 잘 가꾸며 체계적으로 개발을 하는 회사가 성공하는 사례가 나와야 할 것 같습니다. 좋은 소프트웨어를 만드는 데 필요한 것이 있다면 기꺼이 받아들여 배우고 적용할 계획입니다.

또 다른 글,

다양한 기능은 어떻습니까? 마이크로소프트 오피스에는 수없이 많은 기능이 있습니다. 그러나 우리가 사용하는 기능은 매우 단순한 몇가지에 지나지 않습니다. 그 많은 다양한 기능은 어디다 쓰는 것이죠? 그 기능들을 개발하느라고 수없이 많은 개발자들이 시간을 쏟아 부었을텐데… 우리한테 어떤 의미가 있습니까? 사실상 거의 의미가 없죠. 일반인들이 워드에서 XML로 저장하는 기능을 사용할 일이 있겠습니까? 엑셀에서 포아송분포를 계산할 필요가 얼마나 있겠습니까? 그러한 다양한 기능들은 영업을 위한 자료에 사용될 문장 몇개 만드는 것 이상의 용도가 없습니다. 핵심기능이 잘되는 것이 훨씬 중요합니다. 일정과 기능도 무시 못할 요소이기는 하지만, 결코 품질보다 중요하지는 않습니다.

…

먼저, 정치적 환경입니다. 이건 언제나 발생하고 가장 골치아프고, 해결하기 어려운 것 중에 하나 입니다. 팀장이상 급에서는 어느 정도 신경을 쓸 수 밖에 없죠. 정치적 환경에서 발생하는 문제는 임원들에게 알려주세요. 임원들이 해결하도록 하겠습니다. 정치적 환경 때문에 골치아파 하지 마십시오. 임원들이 해야하는 역할 중에 하나가 정치적 문제를 없애는 것입니다.

두번째로는 기술적 환경이 있습니다. AIX에서 돌아가는 프로그램을 짜야하는데 AIX가 없으면 안되겠죠. PC가 2대 있으면 금방 해결할 수 있는 문제라면 한대 더 사야겠구요. 지금 쓰고 있는 컴퓨터가 느려서 컴파일시간이 오래걸리면 바꿔야죠. 메모리가 부족하면 늘려야겠구요. 기술적인 환경은 약간의 비용을 들이면 쉽게 해결이 가능합니다.

…

우리 인트라원 자유게시판에 보면 “빌게이츠 찾아가는 법”이라는 제목으로 지도 3장이 올려져 있을 것입니다. 아마 관심있게 본 사람들은 알 수 있었겠지만 마이크로소프트 메인 캠퍼스의 대부분 건물들은 십자(+)형이나 에이취자(H)형으로 되어있습니다. 우리나라 건물들이 대부분 박스(ㅁ)형인 걸 생각하면 매우 특이한 것입니다. 마이크로소프트 메인 캠퍼스에도 박스형 건물들이 몇개 있지만 강당 등 공통 공간인 경우입니다. 직원들이 일하는 공간은 대부분 십자형과 에이취자형 건물입니다. 박스형건물이 건축비가 싸게 먹힌다는데… 왜? 십자형과 에이취자형으로 건물을 지었을까요? 십자형과 에이취자형 건물의 특징은 좁은 복도와 복도 양쪽으로 창이 딸린 방을 배치할 수 있다는 것입니다. 즉, 마이크로소프트는 메인 캠퍼스에 근무하는 모든 사람에게 창이 딸린 작은 방(1인실 또는 2인실)을 주고 있습니다. 너무 돈이 많아서, 돈질을 하는 걸로 보이나요? 빌게이츠씨가 헛 돈 쓰는 거 봤습니까? 차라리 기부를 하면 했지, 과시를 위해서 돈쓰는 건 아닐 겁니다. 또, 빌아저씨쯤되면 과시하지 않아도 누구나 인정하는 세계에서 제일 돈이 많은 사람이잖아요. 빌아저씨가 소프트웨어 회사에서 생산성과 품질을 높이는 가장 좋은 업무 환경을 연구해서(연구비줘서 시켰겠죠) 실현한 것이라 생각합니다.

자, 어떤가?

흔한 말로 생각이 바로 박혀있는 것처럼 보이지 않는가? 어떤 회사의 사장이란 사람이 저런 위험한(?) 말을 할 수 있을까? MS의 건물 배치에 대해서는 피플웨어에서도 언급했던 내용인데 우리 회사 매니저중에 얼마나 많은 사람들이 그 책을 봤을까? 내 근처 사람중에 단 한 사람이라도 본 적이 있을까?(이런 S/W 생산성에 관한 책을 정리해서 공유 해볼까?)

구글 리더에 등록했는데 최근 10개만 보여서 열심히 블로그 페이지에서 직접 글들을 읽고 있다. 볼만한 내용이 너무 많다.

• 사이냅은 이렇게 개발합니다
• XP적용하면서 사무실분위기가 달라졌어요
• SW개발에서 ‘Peer Review’의 중요성
• 운전배우기
• 가정을 지키러 갑니다
• 새 사무실 인테리어에 관한 이야기
• 좋은 프로그래머가 되기 위한 방법
• 우리가 만들어야하는 좋은 소프트웨어란 무엇인가?
• [김익환의 '대한민국에 SW는 있다'] 진정한 SW 전문가란…’과거형’과 ‘미래형’의 차이
• 정말 좋은 소프트웨어 개발하려는 사이냅 개발체계
• 이런 개발자면 더할 나위 없이 좋겠습니다!
• 사이냅소프트가 괜찮은 회사인 이유 10가지

다만 블로그에 댓글이 그리 많은 편이 아닌 것이 아쉽다.

과연 우리 회사는? 우리 회사 역시 세상이 좋다고 하는 것 중 몇 개는 따라 하려고 한다. 다만 항상

• Top-down
• 수치를 통관 관리
• 안하면 갈금

의 형식을 갖는다. 왜 해야 하는 지에 대해 충분히 설명하고(당연한 것도 있겠지만) 자발적으로 하는 문화를 만들기 보다는 늘 명령하달식으로 진행한다. 위키를 설치해서 사용하는 것을 몇 번 보여줬는데 맘에 들었나 보다. 위키를 많이 사용하라고 권고하기 시작했다. 조만간 주간별 포스팅 수등을 관리하면서 1인당 포스팅 갯수를 할당하지 않을까 걱정이다 -_-

갑자기 전화를 받고 뒷 자리에 앉아 있는 원일이형이랑 회의에 들어갔다.(원일이형은 입사는 늦지만 나보다 연배가 높아 형이라고 편하게 부른다)

회의에서는 두 부장님과 몇 명이 있었는데 우리가 들어서니 다들 씨익~ 웃는다.

들어보니 먼저 회의를 나가신 랩장이 어떤 성능 측정 관련 업무를 지시했는데 그걸 하루만에 결과를 달라고 한 것이다. 원래는 옆 부서에서 해야 하는데 그 부서가 너무 바빠서 결국 그 업무가 우리쪽으로 넘어온 것이다. 실은 원일이형이 그쪽 일을 잘 알기도 하고.

암튼 얼떨결에 아침 10시가 넘은 시간에 업무를 할당받았아. 하루만에 결과를 내야 하는.

잘 모르긴 하지만 작성해야 할 코드의 내용이 대략적으로 어떻게 돌아야 하는 지는 알고 있는 터라 크게 걱정은 되지 않았아. 오히려 그동안 하던 일과 다른 일이라 재밌을 거라는 생각도 들었다.

암튼 등을 대고 앉아있는 덕에 XP에서 말하는 Pair programming을 한 번 실습해 보기로 했다. 우선 원일이형이랑 위책임과 해야 할 일을 이야기해가서 작성할 프로그램의 대략적인 구조나 동작을 이해했다.(나에게만 새로운 내용이라^^)

그 다음 원일이형이 Header file에 structure를 정리하고, 나는 동작 흐름에 따른 함수 prototype을 작성했다.

대개 하나의 모듈을 여러 사람이 작성하는 경우에는 서로 업무를 나누어 하지만 이번에는 XP를 도입해봐야겠다는 생각이 들어 내 해피해킹 키보드를 뽑아서 원일이형 책상으로 갔다. 원일이형 역시 해패해킹을 사용하고 있어 졸지에 책상위에 해피해킹 키보드가 2개나 놓여졌다(라이트 하나 프로 하나). 워낙 작은 키보드라 두 개를 놔도 전혀 문제가 없다. 그리고 모니터는 원래 듀얼 모니터.

암튼 XP에서 정의하고 있는 5분 단위로 키보드와 마우스를 넘기는 것은 아니고 20분 정도를 주기로 했다. 정확히 20분이 되면 넘기는 것도 아니고 결론적으로 그렇게 된 듯하다. 대신 한 명이 코딩하는 동안 옆에서 다른 사람은 계속해서 코드를 보고 같이 토론을 하면서 타이핑 실수나 알고리즘의 오류를 지적해 주었다.

결과적으로 저녁 7시 경에는 원하는 결과를 보여주는 코드가 완성되었다. 다만 아쉽게도 결과가 보여주는 내용을 객관적으로 설명하기가 쉽지 않을 듯해서(논리적으로는 설명이 가능하지만 다른 사람이 보았을 때 쉽게 수궁하는 전개가 아니라) 일단 그 날 하루만에 보고하는 것은 접기로 했다. 나중에 알았지만 출장 나가있는 상무님이 원하는 것이 아니라 랩장이 필요한 정보라는 것이었고, 당장 당일 필요한 내용도 아니었다고 한다. 그리고 또 다른 이유도 있고.

그 다음 날은 일단 결과를 리포트로 정리하여 보내고, 다시 여러 관련자와 함께 결과물에 대해 리뷰를 진행하여 부족한 점을 보완하였다. 이 과정에서 또 다른 3명이 코드 리뷰를 진행했고, 코드에는 큰 문제가 없음을 확인받았다.

결국 이틀에 걸쳐 2명이 설계/코딩하고, 3명이 코드 리뷰를 추가로 하고, 그 외 여러 명이 결과물에 대해서 리뷰를 진행한 이틀짜리 프로젝트가 성공적으로(?) 완성되었다. 개인적으로는 나름 형식을 갖춘 Pair Programming을 처음 해 본 재밌는 경험이었다. 덕분에 이번 주도 “보람찬” 한 주라는 느낌이 들었다 :-)

특별한 것은 아니고 회사에서 일하는 인도친구들이 expect를 사용해서 개발 서버에서 여러 호스트를 거쳐 타켓 보드에 이미지를 보내는 것을 보고 부러워하다 Python의 pexpect를 알게되어 비슷한 동작을 하는 프로그램을 만들었다.

파일을 보내는 것은 아니고(요건 따로 만들어 놓고) 로그인만 하도록 만들어 놨었는데 어떤 기능을 추가하다가 기존 동작도 안하도록 수정을 해버렸다.

고쳐야지 하면서 생각만 하다가 피일차일 미루고만 있었는데 알라딘 아저씨가 비슷한 이야기를 하면서 프로그램이 있냐고 하길로 제약 사항을 알려주고 소스 코드를 넘겨줬다.

그러더니 뚝딱 뚝닥 하더니 버그를 고쳐왔다.(코드가 워낙 간단해서 특별히 이해하는데 어려움은 없었고, 다만 실행 환경에 따라 다를 수 있는 부분에 대한 처리가 필요했다)

잘 동작한다. 와서 고친 부분을 설명해 줘서 듣고 나니 아이디어가 생각났다. 같이 이야기하면서 바로 고쳤다. 다시 소스 동기화.

알라딘 아저씨 자리에 가더니 아이디어가 생각이 났는 지 뭔가를 또 고쳤단다. 쓸만한 기능이 추가되었다. 그러면서 이런 이런 기능이 있으면 좋겠다고 한다.

마침 해당 기능을 쉽게 구현하는 코드를 본적이 있어 바로 방법을 이야기 하고 뚝딱 뚝딱 해서 코드를 고쳤다.

XP(Extreme Programming)에서 말하는 Pair Programming은 아니지만 같은 블럭을(기능을) 함께 고민하고, 함께 코딩하는 경험은 색달랐다. 서로가 가지고 있는 아이디어를 내놓고, 최적의 구현 방법을 논의하다 보니 코딩도 재밌지만 빠른 시간내에 쓸만한 프로그램을 만들 수 있었다.

이것이 진정한 Pair Programming의 장점이 아닐까?