Daybreakin Things

Posted
Filed under 살아가기, 생각하기

요 근래 글이 다시 뜸해지는 것은 다른 이유가 아니라 회사 생활 때문이다. 주5일제로 오전 9시부터 오후 6시까지가 기본 근무 시간인데 이 시간 동안 집중해서 일하면 저녁 때 다른 일을 하기가 쉽지 않다. 대신 덕분에 아침·점심·저녁은 꼬박꼬박 챙겨먹게 되어서 오히려 살이 찌고 있다;;;

인턴이긴 하지만 실제로 하는 일은 정직원이나 다름없을 정도이다. 3개월의 인턴 기간 동안 웹어플리케이션을 하나 만들어 서비스화해야 하는데, 그동안 오픈소스 활동(특히 텍스트큐브)을 하면서 쌓은 노하우들이 큰 도움이 되고 있다. 또한 함께 인턴을 하는 스팍스 선후배들도 동아리 활동으로 많은 도움을 받고 있는 것 같다. 각종 서버 관리 노하우는 물론이고, 나같은 경우는 오픈소스 특성상 원격지에서 비동기적으로 일하기 때문에 내가 무엇을 했는지, 상대방이 무엇을 했는지 정확히 추적하기 위한 커밋로그/이슈/문서 작성 습관이 자연스럽게 몸에 배어 있어있는 편이다. 회사에서는 내가 상상했던 만큼 철저하게 하고 있지는 않은데, 그렇기 때문에 이런 노하우를 회사에 적용해보는 좋은 시도이자 경험이 될 것 같다.

또한 회사 규모가 크지 않기 때문에 내가 컨트롤할 수 있는 영역이 크다는 것도 흥미롭게 해주는 점이다. 내가 맡은 프로젝트의 경우도 기존 시스템과 연동하는 부분이나 전체 프로세스 진행 방식은 동료선배님1의 도움을 받지만 기본적으로 전체 설계는 내가 한다는 느낌이 강하다. 인턴치고 회사의 프로덕트 하나를 이렇게 전체적으로 맡아 처음부터 끝까지 만들 수 있는 경우는 아마 거의 없을 것이다. 한재선 대표님의 모토 자체가 인턴들에게 커피나 타게 하고 복사 시키고 이런 건 자기 체질에 안 맞다며 우릴 뽑은 이유는 말 그대로 실무에 투입해서 회사도 도움이 되고 우리도 경험을 쌓게 하고자 하는 것이라고 했는데 정말 그 말대로 하고 있다.

도와주시는 그 선배님의 의견을 따라 애자일 방법론을 적용해보고 있는데--인사이트 출판사에서 나온 플래닝 포커 카드도 써봤다 ㅋㅋ--이것 또한 내게 큰 도움이 되고 있다. 실제로 매일매일 개발작업별로 투입한 시간을 스스로 정리하고 이것을 바탕으로 사용자 스토리별 비용 추정 및 이터레이션·릴리즈 계획을 적용하고 있는데(물론 이제 막 시범용 1번 이터레이션이 끝났으므로 본격적인 건 이제부터다), 그동안 별다른 시간 계획 없이 되는대로 개발해왔던 것을 떠나 스스로의 개발 스타일을 좀더 정량화해볼 수 있는 계기가 될 것 같다.

특히 소프트웨어공학개론 수업을 들을 때 폭포수 모델로 하면서 IEEE830 스타일2의 요구사항 명세서를 작성했던 것에서 벗어나, 사용자 관점에서 기능들을 정리하고 usable한 기능을 적절한 크기까지 쪼개어 하나씩 쌓아올리는 방식으로 나선형 주기를 탄다는 것이 인상적이었다. 이 방법이 꼭 개발방법론의 정답이라고 말할 수는 없겠지만, 웹어플리케이션을 개발할 때는 단순 UI prototype이 아니라 직접 써봐가면서 많은 아이디어들이 떠오르고 적용된다는 점에서 상당히 적합한 방식인 것 같다. 기존의 폭포수 모델에선 모든 걸 설계를 완벽하게 한 다음 문서를 그대로 코드로 옮기는 방식이었는데, 여기서는 사용자 입장에서 보이는 기능 단위로 나누어 각 기능 하나하나를 완전하게(DB 모델부터 UI까지) 구현하기 때문에 중간에 아이디어가 추가되거나 변경되더라도 그 자체에 집중하기 좋다. (물론 그에 따른 개발기간 연장은 당연한 것이지만.) 다행히(?) 내 스스로 문서화를 잘 하려고 노력하는 편이기 때문에 학교 수업에서 만들었던 것과 같은 정형화된 문서는 아니더라도 어느 정도 인수인계할 수 있을 만큼은 만들 수 있을 것 같다.

특히 이번 프로젝트는 텍스트큐브를 제외하고 내가 하는 모든 웹개발 프로젝트처럼 Python+Django 플랫폼을 이용할 것이기 때문에 그 기술로 상용제품을 만들어 검증해본다는 점에서도 의미가 있다. 사실 textcube.org 홈페이지도 django로 거의 완성해놓은 것이 있는데 python 개발자가 많지 않다보니 유지보수를 이유로 역사의 뒤안길로 사라진 가슴아픈 경험이 있다. 그래서 회사에서도 내가 인턴을 마치더라도 누군가 이어서 할 수 있도록 최대한 많은 문서화와 python/django 기술 세미나도 할 생각이다.

험난한 산이 몇 개 남아있지만 그래도 이 프로젝트가 잘 되었으면 좋겠다. 다행히 한재선 대표님의 철학이나 회사 분위기가 잘 맞는 것 같아 비교적 순탄하게 할 수 있지 않을까 싶다. 돈은 둘째치고 뭔가 내 이름을 걸고 제대로 된 프로덕트를 하나 만들어낸다는 성취감을 느껴보고 싶다.


  1. 군대 용어를 빌려서 '사수'라고도 표현하는 것 같다. 하지만 실제 우리회사 분위기는 매우 가족적이라서 그냥 형이라고 부르는 경우가 대부분이다. 

  2. 전통적으로 사용되던 표준화된 소프트웨어 요구사항 시방서 형식이다. 처음부터 완전무결하게 설계하고 요구사항을 채워넣도록 강조하였기 때문에 최근에는 많은 비판의 대상이 되고 있다.