투잡 생활을 두 달째 하고 있다. 하루 4시간은 레일스 개발자로, 하루 6시간은 레일스 창업자로. 이건 정말 흥미로운 체험이다. 4시간과 6시간의 경험을 간단하게 적어볼까. 일단 오늘은 4시간.
10시에 출근해 기획팀 개개인과 개발팀 개개인이 돌아가면서 자신들이 어제 한 일과 오늘 할 일을 브리핑한다. 자신이 할 일은 자신이 정하고 우선순위도 자신이 정한다. 개개인의 역할이 커지고 책임도 커진다.
다 함께 수정할 문서는 위키를 활용하고 기획문서 교환과 피드백은 지메일을 포럼 쓰레드처럼 활용한다. 개발팀은 신중한 작업에는 언제든 페어 프로그래밍을 하고 작업량이 많을 땐 인덱스카드에 테스크를 시간 단위로 분할해서 분담해 작업하고 SVN으로 통합한다.
레일스의 MVC는 커뮤니케이션에 유리하다. 커뮤니케이션에 유리하다는 말은 사고하는 것에도 유리하고 결국 개발하는 데도 유리해지니 다 같은 말이긴 한데, 대화를 하다보면 MVC이기 때문에 소통에 이익을 얻는다는 느낌을 받는다.
'그 코드는 컨트롤러에서 자주 쓰이니 모델로 빼는 것이 좋겠다', '그건 뷰에서 일단 테스트한 다음에 컨트롤러로 옮기자' 등 모델에서 할 작업인지 컨트롤러에서 할 작업인지 뷰에서 할 작업인지를 언급하는 것만으로도 내가 말하는 의도가 전달이 된다.
커밋을 할 때면 내가 수정한 파일이 무엇이고 어떤 내용의 작업이었는지 다른 개발자에게 간단하게 브리핑하고, 업데이트할 때 머지된 부분이 있으면 설명을 요청한다. Trac 등을 사용하면 더 정확한 파악이 가능하겠지만 커밋과 업데이트가 워낙 빈번해서 상대방의 코드를 봐야 할 정도로 큰 수정은 없어서 안 쓰고 있다.
페어는 상황에 따라 이 PC에서 할 때도 있고 저 PC에서 할 때도 있는데 두 PC의 개발 도구가 완전히 달라서(압타나 vs. VI) 극과극의 체험을 빈번하게 할 수 있다. 냉탕과 온탕을 왔다갔다 하는 기분? 페어의 가장 큰 장점은 타인의 습관을 관찰하고 학습할 수 있다는 것이다.
상대방의 코딩을 눈으로 따라가면서 의도를 파악하고 잘 파악되지 않는 부분은 질문을 하거나 다른 방식을 제안하기도 한다. 내가 코드를 작성할 때는 '이렇게 하려고 한다'는 의도를 설명하면서 상대방의 제안을 귀담아 듣고 해결책을 잘 모를 때는 힌트를 요청하기도 한다.
문제를 해결할 수 있는 방법이야 수없이 많지만 가장 좋은 방법을 찾기 보다는 합리적이고 괜찮은 꽤 많은 방법 중에 먼저 떠오른 방법을 택한다. 약간의 타협인데 최고의 코드 보다는 합리적인 수준의 코드와 빠른 속도를 따르자는 암묵적인 합의.
미래의 재사용성을 고려해 메서드를 많이 만들어내기 보다는 가급적 쉽고 단순하게 구현한 뒤 그 코드를 2번 이상 똑같이 반복해야 할 상황이 왔을 때야 메서드로 뽑는다. 모듈화는 코드 재사용을 쉽게 하고, 잘 설계되었다는 인상과 프로그래머로서의 뿌듯함을 주지만, 타인이 코드를 이해하는 데 시간을 많이 걸리게 한다.
언젠가 또 사용하게 될 것 같다고 생각해서 미리부터 설계에 머리를 싸매기 보다는 가장 중요한 기능을 가장 빨리 구현할 수 있는 방법으로 코드를 작성하고, 같은 코드를 여러 번 반복하고 앉아있다는 자각이 일고 나서야 점차 코드를 리팩토링해 나가는 게 좋다고 생각한다.
4시간은 번개같이 지나가지만, 4시간이 지나놓고 보면 만들어 놓은 결과물이 결코 작지 않다. 6명 정도의 작은 팀이고 고개만 돌리면 기획팀과 개발팀이 소통을 할 수 있다. 꼭 필요한 커뮤니케이션을 30분 이내로 하고 간식을 자주 먹는다(중요). 기획팀이든 개발팀이든 하루 동안 많은 일을 한다.
하루동안 내가 작업할 수 있는 시간이 8시간이라면 일단 마음이 느긋해진다. 음악을 듣고 웹툰을 본다. 누군가 강제하지 않는다면 30분 단위로 테스크를 분할하게 되지는 않을 것이다. 아마도 오전에 할 것, 오후에 할 것, 퇴근 전까지 할 것 정도로 나누겠지.
오전 2시간 오후 2시간 사이에 식사 시간이 한 시간 있기 때문에 체감되는 시간은 더 빠듯하다. 화장실 가거나 물 마시는 시간 이외엔 따로 쉬는 시간도 안 챙긴다. 바빠서가 아니라 쉬고 싶다는 생각을 할 틈이 없을 정도로 높은 집중력을 유지할 수 있는 짧은 시간이다.
오늘은 처음으로 초과근무를 해서 총 8시간을 앉아있었는데 5시간 째 이후로는 확실히 집중력이나 작업속도가 절반 이하로 떨어졌다. 일한다는 느낌 보다는 버틴다는 느낌이 들었다. 알찼던 하루가 도로 풀려버리는 듯한. 보통의 개발자들이 이런 느낌으로 일하겠지 싶었다. 다음 글엔 '6시간' 이야기.
10시에 출근해 기획팀 개개인과 개발팀 개개인이 돌아가면서 자신들이 어제 한 일과 오늘 할 일을 브리핑한다. 자신이 할 일은 자신이 정하고 우선순위도 자신이 정한다. 개개인의 역할이 커지고 책임도 커진다.
다 함께 수정할 문서는 위키를 활용하고 기획문서 교환과 피드백은 지메일을 포럼 쓰레드처럼 활용한다. 개발팀은 신중한 작업에는 언제든 페어 프로그래밍을 하고 작업량이 많을 땐 인덱스카드에 테스크를 시간 단위로 분할해서 분담해 작업하고 SVN으로 통합한다.
레일스의 MVC는 커뮤니케이션에 유리하다. 커뮤니케이션에 유리하다는 말은 사고하는 것에도 유리하고 결국 개발하는 데도 유리해지니 다 같은 말이긴 한데, 대화를 하다보면 MVC이기 때문에 소통에 이익을 얻는다는 느낌을 받는다.
'그 코드는 컨트롤러에서 자주 쓰이니 모델로 빼는 것이 좋겠다', '그건 뷰에서 일단 테스트한 다음에 컨트롤러로 옮기자' 등 모델에서 할 작업인지 컨트롤러에서 할 작업인지 뷰에서 할 작업인지를 언급하는 것만으로도 내가 말하는 의도가 전달이 된다.
커밋을 할 때면 내가 수정한 파일이 무엇이고 어떤 내용의 작업이었는지 다른 개발자에게 간단하게 브리핑하고, 업데이트할 때 머지된 부분이 있으면 설명을 요청한다. Trac 등을 사용하면 더 정확한 파악이 가능하겠지만 커밋과 업데이트가 워낙 빈번해서 상대방의 코드를 봐야 할 정도로 큰 수정은 없어서 안 쓰고 있다.
페어는 상황에 따라 이 PC에서 할 때도 있고 저 PC에서 할 때도 있는데 두 PC의 개발 도구가 완전히 달라서(압타나 vs. VI) 극과극의 체험을 빈번하게 할 수 있다. 냉탕과 온탕을 왔다갔다 하는 기분? 페어의 가장 큰 장점은 타인의 습관을 관찰하고 학습할 수 있다는 것이다.
상대방의 코딩을 눈으로 따라가면서 의도를 파악하고 잘 파악되지 않는 부분은 질문을 하거나 다른 방식을 제안하기도 한다. 내가 코드를 작성할 때는 '이렇게 하려고 한다'는 의도를 설명하면서 상대방의 제안을 귀담아 듣고 해결책을 잘 모를 때는 힌트를 요청하기도 한다.
문제를 해결할 수 있는 방법이야 수없이 많지만 가장 좋은 방법을 찾기 보다는 합리적이고 괜찮은 꽤 많은 방법 중에 먼저 떠오른 방법을 택한다. 약간의 타협인데 최고의 코드 보다는 합리적인 수준의 코드와 빠른 속도를 따르자는 암묵적인 합의.
미래의 재사용성을 고려해 메서드를 많이 만들어내기 보다는 가급적 쉽고 단순하게 구현한 뒤 그 코드를 2번 이상 똑같이 반복해야 할 상황이 왔을 때야 메서드로 뽑는다. 모듈화는 코드 재사용을 쉽게 하고, 잘 설계되었다는 인상과 프로그래머로서의 뿌듯함을 주지만, 타인이 코드를 이해하는 데 시간을 많이 걸리게 한다.
언젠가 또 사용하게 될 것 같다고 생각해서 미리부터 설계에 머리를 싸매기 보다는 가장 중요한 기능을 가장 빨리 구현할 수 있는 방법으로 코드를 작성하고, 같은 코드를 여러 번 반복하고 앉아있다는 자각이 일고 나서야 점차 코드를 리팩토링해 나가는 게 좋다고 생각한다.
4시간은 번개같이 지나가지만, 4시간이 지나놓고 보면 만들어 놓은 결과물이 결코 작지 않다. 6명 정도의 작은 팀이고 고개만 돌리면 기획팀과 개발팀이 소통을 할 수 있다. 꼭 필요한 커뮤니케이션을 30분 이내로 하고 간식을 자주 먹는다(중요). 기획팀이든 개발팀이든 하루 동안 많은 일을 한다.
하루동안 내가 작업할 수 있는 시간이 8시간이라면 일단 마음이 느긋해진다. 음악을 듣고 웹툰을 본다. 누군가 강제하지 않는다면 30분 단위로 테스크를 분할하게 되지는 않을 것이다. 아마도 오전에 할 것, 오후에 할 것, 퇴근 전까지 할 것 정도로 나누겠지.
오전 2시간 오후 2시간 사이에 식사 시간이 한 시간 있기 때문에 체감되는 시간은 더 빠듯하다. 화장실 가거나 물 마시는 시간 이외엔 따로 쉬는 시간도 안 챙긴다. 바빠서가 아니라 쉬고 싶다는 생각을 할 틈이 없을 정도로 높은 집중력을 유지할 수 있는 짧은 시간이다.
오늘은 처음으로 초과근무를 해서 총 8시간을 앉아있었는데 5시간 째 이후로는 확실히 집중력이나 작업속도가 절반 이하로 떨어졌다. 일한다는 느낌 보다는 버틴다는 느낌이 들었다. 알찼던 하루가 도로 풀려버리는 듯한. 보통의 개발자들이 이런 느낌으로 일하겠지 싶었다. 다음 글엔 '6시간' 이야기.
댓글을 달아 주세요
오! 4시간 근무라,.
2008/09/04 23:3612시간씩 일하면 역시 업무 능률이 현저하게 떨어지는 게 맞네요..
힘듭니다.
힘내세요~
2008/09/08 18:19바쁘고 열심히 생활하시는군요.. .잘 지내시죠? ^^
2008/09/05 17:05정의의소님도 잘 지내시죠?^^
2008/09/08 18:19좋은 글을 맛있게 잘 쓰시는 군요. 부러워요.
2008/10/17 17:35또 저보다 젊으신데 저보다 더 바쁘고 알차게 지내시는 모습을 보면
저 자신에 대한 위기감을 느끼기도 하네요.
저의 팀도 오전에 한일과 할일을 회의하고 SVN으로 통합하고 , Trac도 활용해요.
근무시간은 오전 9시 부터 저녁 6시까지 점심시간 빼고 8시간...
4시 이후에는 정말 집중력이 떨어지는 건 사실이에요 ㅎ
맛있다는 표현 감사드립니다.
2008/10/19 15:22저 역시 제가 쓴 포장된 글들을 보고
위기감을 느끼곤 합니다 ㅎ
짧은 근무 시간은 분명 집중도를 유지해주지만
팀과 소통하고 함께 호흡할 시간은
분명 줄어들기 때문에 장단이 있는 것 같습니다.
개발자들 입장에서는 기획자들 얼굴 덜 보는게
마음이 더 편할 수 있지만
전체 프로젝트의 관점에서 보자면
소통할 타이밍이나 소통 채널(도구, 방식)에 대해
더 많은 고민이 필요한 것 같아요.