 태그 : 개발 |
2013/01/28 [잡생각] 이미 죽어있는 시스템에서 개발하기
2011/11/30 [잡생각] 팀장들의 대화 .. with 평가, 개발 [8]
2011/10/06 [잡생각] 어떻게 하는게 개발을 잘하는 것일까?
2010/03/05 [잡생각] 소프트웨어는 계속 회전시켜 봐야만 안다!
2009/12/10 [잡생각] 열혈 아이폰 스터디중!! [4]
2009/12/08 [잡생각] 개발과 팀장의 딜레마 [6]
2009/11/30 [잡생각] 완전체가 되어보자?!?
2009/05/25 [잡생각] 운영적 마인드의 설계, 개발
2009/05/18 [잡생각] ORM(Object-relational mapping)의 복병을 만나다. [2]
2009/04/14 [잡생각] 오늘 프로젝트가 오픈인데.. 궁시렁 궁시렁 [3]
2011/11/30 [잡생각] 팀장들의 대화 .. with 평가, 개발 [8]
2011/10/06 [잡생각] 어떻게 하는게 개발을 잘하는 것일까?
2010/03/05 [잡생각] 소프트웨어는 계속 회전시켜 봐야만 안다!
2009/12/10 [잡생각] 열혈 아이폰 스터디중!! [4]
2009/12/08 [잡생각] 개발과 팀장의 딜레마 [6]
2009/11/30 [잡생각] 완전체가 되어보자?!?
2009/05/25 [잡생각] 운영적 마인드의 설계, 개발
2009/05/18 [잡생각] ORM(Object-relational mapping)의 복병을 만나다. [2]
2009/04/14 [잡생각] 오늘 프로젝트가 오픈인데.. 궁시렁 궁시렁 [3]
아.. 오픈일정이 촉박해서 미친듯이 달려야 할 타이밍에 블로그에 글을 쓰고 있네.. ^^
절반이상은 짜증이 난 상태이고 나머지는 내 무능력함에 실망이고
약간은 나도 사람이자나 라는 자기만족(?)이다..
우리 회사의 아주 핵심적인 legacy 시스템에서 개발중이다.
내가 보았을때는 아주 아주 훌륭한 시스템 + 프레임웍이다.
PHP의 framework이 거의 없던 시절에 PHP 자체 소스도 고쳐가면서 성능개선을 하였고
꼭 필요한 핵심 기능을 잘 추려서 library화를 하였고 성능도 뛰어나다.
문제는
이 legacy시스템이 몇명의 천재 개발자들에 의해서 만들어졌고
이미 처음 만들어지고 이 위에 비지니스 로직을 올리기 시작한지 7~8년이 지났고
이 천재 개발자들이 회사에 남아있지 않다는 것이다.
이 기반 시스템에서 오래동안 개발을 한 사람들은
대략적인 흐름과 역할에 대해서는 이해를 하지만 각 사업부별로 파생되어버린 특화기능에 대해서는 서로 모르고
이 부분을 고치게 되면 어디서 어떤 문제가 발생할지 장담을 못하는 상태이다.
나도 지금 비슷한 상황이다.
처음에는 간단히 페이지를 수정할 예정이었는데 오픈해서 보니 7~8년의 회사 히스토리가 고스란히 담겨있는 소스이다.
이미 종료된 서비스, 분사되어서 나가버린 서비스들을 위한 코드가 덕지덕지 남아있고 결정적으로 html 의 구조도 깨져있다.
처음부터 만들어보겠다라는 결심을 하였고 이 페이지 소스에 있는 20개의 기능중 몇개를 살려야할지 모르겠지만
QA 및 테스트를 거쳐서 돌파하겠다라는 결심도 섰지만 정작 프레임웍에 관련한 코드는 어떻게 해야 할지 모르겠다.
가장 간단한 방법은 기존에 잘 돌아가는 페이지의 기본 구성을 가져와서 깔아놓고 시작하는 것이다.
이 함수의 기능이 무엇인지 잘 모르겠지만 다른 기반코드에서 모두 쓰고 있으니 쓰는거지.
이 자바스크립트가 어디서 쓰는지 잘 모르겠지만 일단 include 하고 보는거야.. 에러나면 어떻게해...
젠장.. 역시 죽어있는 시스템에서 개발하는건 별로이다..
하지만 오늘까지 하라라고 하는데 전체를 다 오픈하면서 연관성 체크하기는 시간이 부족하다고.. ㅠㅜ
ps.
죽어있는 시스템이란 이렇게 전체적인 틀을 잡고 가이드하고 계속 리팩토링 + 개선을 하지 않는
시스템을 이야기한다. 아무리 잘 만들어지고 기능이 뛰어난 것이라도 라이프사이클을 돌려주지 않는다면
곧 버려야 하는 시스템이 될수 밖에 없을것이다.
어제는 오랜만에 편한 사람들과 술한잔을 했다.
친한 회사동료가 한잔하자고 해서 할것 다 놔두고 갔는데 아이러니컬하게도 모두 다 팀장이네 ^^
울고 싶은데 누가 뺨때려준다라는 것처럼 술한잔도 생각이 나고 하고 싶은 이야기도 많은데
나뿐만이 아니라 모두 다 그런것 같다. 이제 막 평가기간도 지났고 팀원에게 하지 못하는 말들이 있으니 ^^
나는 팀장이 되고 나서 첫번째의 평가기간이었다. 팀원 막판에 약간의 깨달음을 얻은것 같았는데
팀장이 되고 나서 정말로 커다란 깨달음을 얻었다. 평가에 대해서 말이다.
그전에는 늘 평가기간에는 스트레스였다. 잘 받지도 못하면서 잠도 설치고 스트레스도 많고
팀원 막판에 얻은 결론은 어짜피 평가는 주관적이라는 것이다.
팀장이 주는 것이 그 한사람이 보는 것이지 회사, 사회, 내가 주는 나에 대한 평가가 아니라는것..
객관적인 수치, 정량적인 잣대, 다 개뻥이다. 절대 만들수 없다. 라는것에 대해서 알았다.
그냥 주는데로 받자.. 그게 답이다..
팀장이 되고 나서는 평가기간동안 작성하는 자료들, 평가서, 업적리스트, 역량평가서 ... 등등
어짜피 모두 필요가 없는 자료이다. 그냥 형식을 맞추기 위한 것이다.
어짜피 팀원에 대한 평가는 이미 팀장의 마음속에 있다.
없다라면 그건 팀장 역할을 잘 못하고 있는 것이다.
그것은 평가기간동안 만들어지는 것이 아니라 그동안 계속 누적이 되면서 쌓이는 것이다.
평가기간동안 아무리 난리를 쳐도 바뀌지 않는다. 특히나 상대평가의 기준에서는 말이다.
어제는 5명의 팀장이 있었다. A,B,C,D,E(나)
part 1. 평가 --------------------------------------------------------------------
A팀장.
팀원이랑 평가때문에 한창 스트레스를 받고 힘들어 한다.
팀원도 워낙 강력하게 들이대고 이야기도 잘 안된단다.
내 관점으로 봤을때는 그 팀원 올해 농사(평가)를 망쳤지만 내년의 농사도 망쳤다.
이렇게 팀장과 감정대립을 하고 나서 어쩌겠다는 것인지..
올해 농사를 망쳤으면 깔끔하게 올해는 아쉽지만 내년에 더 잘해보겠다. 지켜봐달라 와 같은
팀장과의 감정대립이 생기기전까지만 어필하고 터닝 포인트를 만들고 손을 때야 한다.
팀장의 입장에서는 엇.. 생각이 괜찮네.. 내년에는 좀 더 잘 지켜봐야지.. 라는 생각이 드는 것이다.
내가 팀원이었을때 했던 것처럼 팀장과의 합의를 못내고 실장, 본부장, 인사위원회까지 올라가면
내년 농사도 필히 망한다.
B팀장.
평가는 잘한것 같은데 팀원들의 말때문에 많은 상처를 받았다.
D팀장은 팀원들을 자유롭게 풀어주는데 팀장님은 왜 그래요?
E팀장은 책도 많이 보면서 공부하는데 팀장님은 왜 그래요? 와 같은 팀장들의 비교로 말이다.
이쪽 팀원들 참 재밌네.. -_-;;;;
나한테 한번 걸렸으면 한다.. 내가 팀원들간에 비교, 퍼포먼스가 쩌는 타팀원에 대해서 제대로 비교해주게 ...
팀장이건, 팀원이건 , 실장이건, 회사건 어디랑 비교하지 말자.. 정말 스트레스다..
C팀장
아.. 이분이 이렇게 무서운 사람인지 몰랐다.
팀원들과의 평가는 무난히 잘한 것 같은데 뒷이야기가 무섭다.. ㅠㅜ
팀원들이 올리는 자신의 평가는 신경쓰지 않는다.어짜피 실장이 알아서 정리해줄테니
그냥 ok, ok 하면서 패스해버린다. 그래도 A, B는 팀원들과 커뮤니케이션을 하려고 하는데
이분은 그냥 패스네.. 허걱.. 흠..
원하는 만큼 기회와 환경을 다 준다. 팀장은 안챙겨준다. 못하면 니가 각오해야 할것이다. 라는 자세다.. 흠
D팀장.
원래 무서운 사람이다. ^^
잘 모르는 사람들, 특히나 타팀원들은 서글서글하고 깔끔한 스타일로 좋아하지만
팀장의 커다란 깨달음은 이 팀장을 통해서 배운 것이다.
평소에도 늘 팀원들에 대한 정리가 되어 있다. 누구는 어떻고, 누구는 어떻고,
잘하면 + 가 되지만 - 도 정확하다. 에누리 없다. 못하면 얄짤없다..
E팀장
나다.. ^^ 첫번째였지만 잘 건너간것 같다.
내 스타일을 머라고 단정하기 어렵지만 C팀장과 D팀장의 중간쯤인것 같다.
이게 맞는 방향인것 같기도 하고
part 2. 개발 --------------------------------------------------------------------
팀장 모두 개발을 하다가 팀장이 되었다.
지금 모두~~~~ 다시 개발을 하길 원한다. 그때가 가장 행복했다고
누가 개발을 해서 행복했다라고 하기보단 무엇인가에 집중할수 있어서 좋았던 것이란다. 수긍이 간다.
하루 종일 잡힌 회의에 치여서 코딩을 못해본지 좀 된것 같다.
하려면 퇴근 시간 이후에 해야 하는데 체력이 이미 바닥이다..
점차 이렇게 시간이 흐르면 돌아올수 없단다.. 슬프다..
그래도 팀원들이 성장을 하는 것을 보면 기분이 좋다라는 것은 공통적이다.
그러기 위해서 무엇인가를 해야 하는데 팀장이 예외가 될수는 없다.
모범이 되어야 하기에 더 어렵다.
스터디 준비를 하거나 발표 자료를 준비하거나 기술조사를 하거나.. 더 잘해야 한다.
출근시간도 팀원일때보다 더 지켜야 한다. 딴짓을 해도 실장보다는 팀원 눈치가 보인다. ㅠㅜ
(어제 2시까지 술을 마시고 칼같이 9시15분에 출근했다. 내 스터디 발표차례이기에 준비해야 한다ㅠ)
휴... 팀장을 하는게 잘하는 짓인가.. 다들 고민이다.
개발자로 생각하는 내 자신에게 늘 던지는 질문이었고 최근 2~3년동안 무엇이라 답을 잘 하지 못하였다.
올해초 리플래쉬를 다녀오면서 개인적으로 결론을 내려보기도 하였는지만 정답인지는 모르겠다.
경력자의 면접관으로 들어가게 되면 단골질문이기도 한 "어떻게 하는것이 개발을 잘하는 것일까?"
아래의 내용은 내가 년차별로 그 당시에 느꼈던 "잘 하는 개발"에 대한 정의였는데
년차가 올라갈수록 나도 성장을 하면서 관점도 바뀌고 경험도 늘어나면서 조금씩 달라져가고 있다.
1~2년차
벤처회사에 있을당시 미친듯이 몰려오는 일에 대해서
"정해진 일정에 맞춰서 빠르게 개발을 하면서" 나름 난 뛰어난 개발자야..라는 말도 안되는 생각을 할때였다.
리소스 재사용이나 db connection 관리 같은것은 잘 모르겠고 ctrl+c, ctrl+v 가 최고였다.
3년~5년차
대학교때 자바를 배우긴하였지만 OOP의 개념을 다시 접하면서
소프트웨어 설계라는 것을 어느 정도 알게 되었고
"설계된 방식으로 정확히 개발하는 것"을 하기 위해서 많이 노력하였다.
약간의 소프트웨어 설계도 접해보긴 하였지만 지금 돌이켜보면 제대로 한것 같지 않다.
SI를 할때이니 내가 만든 소프트웨어의 운영 및 수정을 해본적이 없을때였다.
5년~8년차
설계에 어느정도 관심이 있으면서 더블어 소프트웨어 공학에도 많은 관심을 가지게 되었다.
설계를 하는 것도 중요하지만 같이 개발을 하는 모든 사람들이 그 설계를 벗어나지 않고
같은 맥락, 같은 수준(깊이)로 만드는 것이 정말로 정말로 쉽지 않다는 것을 알게 되었고
"누구나 쉽게 코드를 이해할수 있도록 만드는 것"이 중요하다라는 생각을 하게 되었다.
함수명과 변수명도 바로 알수 있도록 사전에서 좋은 단어를 선택하기 위해서
로직설계보다 여기에 더 많은 시간을 투자하게 되었고 조건체크를 2번하더라도 한눈에 보기가 쉽다면
프로그램 라인이 늘어나는 것에 주저하지 않았다.
8년차~ 12년차(지금)
지금도 누구나 쉽게 코드를 이해할수 있도록 만들어야 한다는 생각은 변함이 없다.
하지만!!!! 누구나 쉽게 이해한다는 것이 사람마다 방식이 모두 다르다는 것에 대해서 많이 느끼게 되었고
다른 사람의 코드를 쉽게 보기위해서는 그 사람의 스타일을 아는 것이 중요하다라고 생각하게 되었고
팀원들간의 코드리뷰를 될수 있으면 많이 할수 있도록 분위기 조성하는 것에 초점을 맞췄다.
이슈관리시스템과 SVN을 잘 연동하고 프로세스를 어느정도 정리하여서 소스코드의 변경은
반드시 이슈관리시스템의 이슈와 연동이 될수 있도록 중요성을 강조하고 다른 사람들에게도 쓰도록 하였다.
(전규현님의 블로그를 참조하였다 ^^)
새로운 프로젝트를 만들때 사업적인, 기획적인 이슈이외에 개발적인 테마를 정하고 도전하였다.
스크럼 방식으로 개발방법을 정해보기도 하고 TDD는 약간 무엇인가가 부족해서 기능별 자동테스트의 프로세스 생성에
도전해보기도 하고 사용자관점의 완벽분석 로그시스템도 만들기도 해보고... 등 실패도 많지만.. 성공도 있었다.
이런 일련의 과정들이 "개발문화, 개발철학을 만들고 유지하는 것"으로 어느 정도 정리가 되는듯하였다.
강압적인 분위기가 아니라 경력이 많은 개발자가 솔선수범하고 자연스럽게 미들과 주니어 개발자의 동참도 이끌어내고
담당하고 개발하는 시스템도 우리들이 정한 개발문화, 개발철학에서 벗어나지 않고 잘 유지되도록 말이다.
이것이 팀장의 역할이 아닐까 하는 생각도 있지만
이런 개발문화를 만들고 이끌어주는 시니어 개발자가 있으면 너무나 좋겠다라는 생각이 든다.
나보다 경험이 많은 개발자가 있다면 물어보고 심도있는 토론을 해보고 싶은데
다들 통닭집으로 가기도 하고 매니저로 전환한 사람들이 많아서 누구랑 이야기해보지?
꼬리말1.
위에 있는 잘하는 개발자의 내용에는 어떤 기술을 사용하였는지, 어떤 언어를 선택하였는지는 하등 관계가 없다.
기술이라는 것은 그때 필요한 요구사항에 맞도록, 운영에 가장 적정한 것을 선택하면 되는것이다.
뛰어난 성능, 안정성도 비슷한 맥락이다. 꼭 필요한 경우가 있지만 꽤 많은 경우는 하드웨어의 성능으로 커버가 되고
24시간 365일 무정지 시스템과 같은 케이스는 그렇게 많지 않으니 잘 맞는 기술을 선택하면 되는 것이지...
(나름 개발 expert라는 사람이 시스템은 3년정도 쓰고 버리고
새로 전체를 개발하는게 편하다라는 이야기를 듣고 이 글을 써본다)
프로그램을 돈을 벌기 시작할 초반에 나는 나름대로 설계와 개발을 잘한다고 생각하고 있었다.
석사라는 타이틀도 있고 학교에서 최신의 방법론(이때는 CBD, RUP 가 대세였다)으로 무장하고 있었고
동료, 선배들은 컨설턴트로 최신의 기술, 트랜드를 나에게 주입해주고 있었다.
웹개발도 하였었고 소프트웨어 패키지(eCRM)를 만드는 회사에서 설계, 개발도 하였었다.
아키텍트라는 사람이 거의 없던 시절이었기에 (사실 ^^ DBA도) 이것 저것 다 하면서 우쭐해하고 있었다.
하지만 지금의 회사에 오면서 생각이 많이 바뀌기 시작하였다.
내가 만든 시스템으로 서비스를 하면서 추가 변경사항도 받고, 리뉴얼 프로젝트도 진행하면서 말이다.
그전까지 내가 만들었던 시스템, 소프트웨어는
그 expert가 이야기하는 것처럼 쓰고 버리고 새로 만드는 형태의 것들이었다.
그러니 그때 제대로 설계를 하고 만들었다고 하여도.. 사실 회전시켜보지 않았기에
잘 만들었는지 잘 못 만들었는지 알수 없는 상황이었고 알지도 못하였다. 만들고 빠지는 SI가 무슨 회전을 경험해보겠냐..
OOP의 가장 기본적인 개념인 재사용을 하지 않는 소프트웨어들이 무슨 OOP란 말인가..
추가적인 요구사항으로 현재 프로그램을 고쳐보지 않는 만들고 손을 놔버리면서 무슨 설계를 이야기 하는가..
엉터리로 설계하고 시스템을 만들어도.. 초반에 운영까지는 어떻게 할수가 있다.
그냥 문제 생기면 수정하고, 에러 생기면 잡고.. 프로그램으로 밥을 먹은지 5년정도가 되면 이 정도는 다 덮어버릴수 있다.
하지만!!!!
핵심 기능의 변경이나 로직의 전체를 건드려야 할때는 잘 만들어진 것과 그렇지 않은것에 대한 차이는 엄청나다!
이 시스템은 3년정도 있다가 버려야 하는 것이라면.. 그것은 처음부터 설계가 잘못 된 것이다. 아님 설계라는 개념 자체가 없다던가
오픈소스 10개를 이용해서 시스템을 만들었다고 하자!
그렇게 힘들이지도 않고 빠른 시간에 만들었을 것이다. 생산성도 좋고, 성능도 검증된 것을 사용하여서 좋다.
그럼 좋은 설계로 봐야 하는 것일까?
좋다라고 생각하는 사람은 제대로 회전을 시켜보지 않아서 일것이다.
10개의 오픈소스에 대한 update는 어떻게 할것인가? 아마 update만 하다가 시간 다 보낼것이다.
그럼 update를 하지 않는다? 사용자의 요구사항이 오픈 소스 최신 버전에 있는데.. 어떻게 하지?
오픈소스들을 어떻게 결합시켜서 사용하는지가 관건이다.. 결합도를 높여놨으면.. 정말 미친다..
하지만 당장 오픈하였을때는 좋은 평가를 받을수 있겠지.. 최신에, 오픈소스에, 공짜에 ... 등등
소프트웨어를 계속 회전시키는 것은 정말로 쉽지 않고 어려운 일이다.
아마 개발자중에서도 1개의 소프트웨어를 계속 개발하고, 리펙토리하고, 변경하고, 리펙토링하고 ,
이렇게 계속적인 업그레이드를 경험해본 사람은 많지 않을 것이다.
거의 대부분 귀찮아서 리펙토링 조차도 잘 안한다.. 그러면서 최신의 기술에 대해서는 귀가 번뜩한다.
왜 컴팩트하게 만들어야만 하는지..
책에 있는 디자인 패턴들은 그냥 형태일뿐 나에게 맞도록 수정을 해야만 하는지..
제대로 설계가 된 시스템이라면 회전까지를 모두 고려해서 만들어야만 하는 것이다!
올해 새롭게 배울 언어로 선택한 Object-C
맥개발보다는 아이폰 개발이 목적이었다.
그 첫번째 예제로 hello world를 짜본 것이 3월달이었다.
그 다음부터는 사실 흐지부지 되어가고 있었다.
같이 스터디를 하던 친구가 회사 생활에 치여서 손을 든것이 첫번째 이유였지만
내 스스로도 의지가 부족해서 혼자 스터디를 유지 하지 못하였다.
공부는 하지 않으면서 서점에 가면 새로운 아이폰개발 책에는 또 왜 이렇게 손이 가는지
이렇게 방황하던중
사내에서 나와 비슷하게 방황하는 몇명을 발견하였다. 크흐흐
그래서 2번째 스터디팀을 구성하였다. (왜 혼자는 잘 안될까.. 흠흠)
맥북을 가진 사람도 있고 넷북에 해킨토시를 설치해서 추가모니터를 통해서 듀얼로 쓰는 사람도 있고
아직 아무것도 없이 책만 가진 사람도 있다.
일주일에 2번, 한번에 1~2시간정도 라이브코딩!!!!을 한다.
한명이 배울 챕터를 선행학습하고 가이드를 해준다.
책에 있는 예제를 짜보고 돌려보고 안되는 사람의 원인을 다 같이 찾아본다.
아직 대부분 오타로 인한 버그이지만 그래도 혼자 큰 벽을 헤쳐나가는것보다 훨씬 잘 되고 있다.
맥개발 환경이 아직 준비 안된 사람을 위해서 내가 선행학습을 해와서 진행할 차례이면
내 맥북을 그 친구에게 양보한다. 오늘은 니가 짜봐라.. 하면서..
한명을 빼고는 다른 사람은 큰 준비가 필요없다. 와서 열심히 코딩하면 된다.
타이핑이 많은 챕터를 만나면 책 예제를 카피해서 돌려보고 싶은 충동에 빠지기도 하지만
그래도 다들 부담감 없이 재밌게 하고있다.
얼능 공부를 하고 내가 정말 짜보고 싶은 나를 위한 맞춤 가계부!!!!를 만들어봐야지
한참전부터 하고 있던 고민이다.
이번에 팀장과 면담을 하면서 나뿐만이 아니라 팀장도 비슷한 고민을 하고 있구나.. 라는 생각이 들었다.
난 매니징에는 관심이 별로 없다.
개발이 좋고 계속 개발만을 하고 싶다.
그런데 어느 순간!!
정말로 내가 하고 싶은 개발을 하기 위해서는 팀장이 되어야 하나? 라는 생각을 해보았다.
이렇게 하는 것은 정말 아닌데!!
이것을 써야 하는데!! 라는 생각이 들지만 팀장과의 합의 실패로 하지 못한 것들이 꽤 있다.
(팀장을 논리적으로 잘 설득해야지!! 라는 말은 하지 말자.. 이것은 논리와 설득이 아니다!!)
팀장은 그 반대의 걱정을 하고 있었다.
매니징을 주로 하기는 하지만 테크니컬 리더를 하는 역할을 재미있어 한다.
그래서 자주 하는 편인데 그것에 대한 부작용이 좀 있는 편이다.
팀장은 순수한 테크니컬 리더로써의 조언이지만
받는 사람의 경우는 팀장이라는 위치때문에 명령으로 들릴수 밖에 없다. 아무리 편하게 이야기 한다고 해도..
그리고 종종 개발보다는 매니징만 하라는 소리를 많이 듣는다.다른 팀장한테서도..
하지만 우리팀에서 운영하는 툴들을 rails로 framework을 변경하는 이 작업은
팀장의 위치가 아니었다면 해볼수 없는 일이다.
하고 싶은 개발을 위해서는 힘을 얻어야 한다.
힘을 얻기 위해서는 책임을 지는 팀장 이상의 위치에 올라서야 한다
올라서는 순간 개발을 버려야 한다.
참 아이러니컬하다.
(완전체라는 단어가 아주 마음에 드는 편은 아니지만 저 단어를 대체할 만한것이
잘 생각이 나지 않아서 그대로 사용하기로 해본다.)
사례 1:
진중권씨가 3개정도의 대학에서 재임용에 실패하였다고 한다.
MB정권이 끝나기전까지는 힘들것이라고 생각하고 세부으로 가서 평소에 하고 싶었던 경비행기에 탄다고 한다
그리고 3년정도 후에 돌아와서 교수를 한다고 한다.
(관련기사)
사례 2:
어떤 기획자가 있다.
기획을 주로 하긴 하지만 사업기획을 시작으로, 서비스기획, 개발관리, 마지막 보고용 지표까지 ..
윗사람들이 보기에는 어떤 일에 대해서 이 기획자에게 시키면 다 된다고 생각한다.
자기가 일을 다 하는것이 아니겠지만 개발은 어떤 개발자가 하는것이 좋은지 리스트업을 해주고
윗사람은 자금을 지원해주고 간간히 올라오는 갈림길에서 선택만 하면 된다.
사례1의 진중권씨와 같이
지금 내가 다니는 직장을 그만두고 3년정도를 지금 하는 일과 전혀 다른 일을 하고 왔는데
과거와 거의 동일한 대우를 받으면서 똑같은 일을 할수가 있을까?
만일 이 질문에 Yes라는 대답을 할수 있다면 그대는 내가 생각하는 완전체라고 봐야 한다.
사례2에서의 기획자는
기획이라는 파트때문에 아니라 스스로 거의 완전한 상품에 가깝다.
따라서 같은 회사내에서 일을 담당할 기회가 많을 뿐만 아니라 새로운 곳(새로운 회사, 새로운 부서...)에서
이 사람을 데려가면 우선 절반이상은 일을 한거다.. 나머진 이 사람이 알아서 해줄테니깐..
내가 생각하는 완전체에 가까워질수록
회사에 대한 의존도가 낮아지고 독립성이 강해지면서 조금 더 자유롭고 편한 삶을 살것이 라는 생각을 해본다.
내가 하고 있는 개발업무는 조~금 수동적이다.
사업적인 이슈가 발생하고 기획서가 만들어지고.. 그러면 개발일을 시작한다.
물론 기획서 없이 개발을 하기도 하지만 특별한 경우이거나 개인적인 프로젝트일때가 많다.
따라서 난 아직 완전체에서 한참 멀었다.
개발에 비지니스부분을 합쳐야지만 완전체에 가까워질까?
우선 이 대답에는 당연히 Yes라고 할수 있을것이다.
전 C개발자입니다, 자바개발자입니다.. 라고 이야기 하는것보다는
전 검색개발자입니다, 빌링개발자입니다, 게임그래픽 엔진 개발자입니다.. 라고 할수 있는 사람들이
살아남기가 더 쉬울것이고 일을 할때 선택받기 더 편하다.
하지만 이것으로는 부족하다.
제일 잘나가는 검색개발자라고 해봤자 어떤 검색서비스를 만들어야 돈을 잘 벌수 있을까가 제일 먼저이고
그안에서 사용되는 기술은 그 다음이라고 볼수 있다. 나 같은 웹서비스 개발자야.. 할말 없다.
웹에 대해서는 무엇이든 만들어드립니다!!! 라고 해봤자 기획자가 어떤 기획을 해오는것인가가 더 중요하다.
개발기술을 늘 최고수준으로 유지하면서 쩌는 비지니스 마인드를 보유한다? 에효.. 잘 모르겠다..
개발을 버리고 싶지 않은데.. 개발로만 하는 방향이 있을까?
이 글을 쓰고 싶었던 이유는 한참 전에 내가 올린 포스팅에서 시작이다.
SP를 쓰는것을 반대하던 내 글에서의 댓글은 아니었지만 다른 사람의 블로그의 댓글에서
내가 SP를 반대하는것이 내가 SP를 잘 모르기때문이라는 말이 있어서였다.
내가 쿼리를 얼마나 잘 쓰는지(?), 내 DB 스킬능력을 이야기 하려다가 ^^
운영적 마인드에 대한 내 이야기를 해보려고 이번 포스팅을 하게 되었다.
서론은 여기까지하고..
내 개발인생에서 절반은 오로지 제품개발과 SI만을 하였었고
나머지 절반은 지금과 같은 운영과 개발을 같이 진행하고 있다.
개발인생 초반에는 운영을 참 무시하였다.
개발능력이 부족한 사람들이 가는 곳이라는 생각도 했었고
패배주의적으로 창의력도, 의욕도 없는 운영을 하는 사람들을 보면서 말이다.
매니징을 원하지 않고 오래 개발을 하려고 하다가 보면 설계라는 것에 관심이 생기는 때가 있고
그때 마침 운영도 알고 있어서인지 지금은 운영이라는 것에 대한 마인드가 전혀 다르다.
소프트웨어의 꽃은 운영이다.!!!!
자바와 같은 OOP의 소개에 보면 늘 이런 말이 있다. 재사용성이 높은 언어다!! 라는 말..
왜 이렇게 만들었어요.. 라고 물어보면 대답중에 꽤 많은 것들이 이렇게 만들게 되면 추후 변경에 용이합니다..
다 운영적인 편리성, 운영적인 마인드를 이야기하는 것이다.
그런데 참 아이너리컬하게도
운영을 해보거나 운영적인 마인드가 전혀 없는 사람들이 소프트웨어 설계나 컨설팅을 하는 모습을 보고
그들의 결과물을 보게 되면 오로지 이론적일뿐.. 현실감이 없는 운영적인 마인드에 많이 실망을 한다.
또 재밌게도 디자인 패턴이 나오면서 이런 현실감이 없는 설계나 개발이 더욱더 늘어나고 있다.
운영의 핵심은 심플함이다.
디자인 패턴을 그대로 사용하는 것이 아니라 지금 상황에 맞도록 불필요한 것들을 모두 제거한
컴팩트한 형태로의 변경을 할수 있어야만 디자인패턴을 사용하는 것이다.
일관된 형태의 유지를 위해서 한번 사용하기로 하였으면 계속 사용을 해야 하기에
초반에 어설프게 사용된 인터페이스 클래스의 사용이 지금은 걷잡을수 없을정도로 커져서
프로젝트에 있는 클래스의 1/3가 빈껍데기 형식 맞추기용 인터페이스인 것을 볼때마다
운영적인 마인드의 부족함을 절실히 느끼게 된다.
나는 다를수 있는 프로그램 언어가 몇가지 있다.
우리팀 개개인의 능력을 합치면 더욱더 많다.
많으면 많을수록 언제 어떤 것을 써야 할지, 지금 환경에서는 어떻게 해야 할지에 대한 고민은 더욱더 많다.
한개의 프로젝트, 서비스 안에서 여러개의 언어, 프레임웍을 사용하는 것은 피곤하다.
이유는 아주 간단하다..
관리포인트가 늘어나기때문이다!!!
내가 할수 있다고 마구잡이로 기술을 쓰는것은 운영적인 마인드가 부족한 것이다.
가장 간단한 기술로 사용자의 요구사항을 만족시키는 것이 소프트웨어의 설계인것이다!
저녁먹고 wow가 아닌 FPS의 게임을 한창 하고 있었다.
이번 달에 있는 회사 창립기념행사에 내정된 사내게임대회에 출전하기 위해서
오랜만에 열심히 총을 쏴주고 있었는데..
DBA에게서 전화가 왔다.
제우스님. 이번 달 정기점검때 DB가 오라클 9i에서 오라클 10g로 업그레이드 됩니다.plan과 optimize 테스트를 위해서 사용하고 있는 모든 쿼리를 뽑아주세요아.. 그리고 실행 가능하도록 변수에 값을 모두 넣어주세요
허거걱.. 이게 왠 날벼락이냐.. 게임도중에 멍하니 서있었다. (그래서 커피내기 졌다.. ㅠㅜ)
쿼리가 많기도 하였지만 결정적인 문제가 있었다.
1. perl 배치에서의 쿼리
약간 귀찮긴 하지만 간단하였다.
소스상에서 다이렉트 쿼리를 쓰고 있기에 소스를 찾아가면서 쿼리를 뽑아내면 된다.
어짜피 perl 배치가 몇개 없기에 OK!!
2. spring에서 사용하는 iBatis의 SQL Maps
절반만 ORM이라고 내가 맨날 투덜거리던 요놈이 이번에는 너무나도 이뻐보였다.
왜냐고? 당연하지.. 사용하는 쿼리가 모두 하나의 폴더, 여러개의 xml에 모두 저장이 되어 있으니깐!!
그냥 파일 한개씩 열면서 바인딩 변수만 챙겨주면 된다.
3. ruby on rails의 ActiveRecord
RoR에서는 최대한 ORM을 모두 사용하기 위해서 노력을 하였다.
다이렉트 쿼리는 거의 없고 관계를 최대한 사용하면서 만들어놓았다.
ruby 배치도 있는데 rails에서 만들어놓은 model을 불러서 사용하도록 만들어 놓았다.
이놈이... 발목을 잡을줄이야.... ㅠㅜ
@logs = ActionLog.find( :all,
:include=> [:user, :admin], :conditions => conditions,
:order => "action_logs.created_at desc",
:limit=> per_page,
:offset => @logs_pages.current.offset)
@user_list = User.find(:all,
:select => "lastname , firstname, login, dept, phone, email, domains",
:conditions=> ['permission_id in ('+query_conditions+ ')'],
:joins => "INNER JOIN admissions ON admissions.user_id = users.id",
:group => "lastname, firstname, login, dept, phone, email, domains")
주로 이렇게 사용하는데.. 이놈의 쿼리를 어떻게 뽑아내지?
결론은 log에서 하나씩 실행시키면서 쿼리를 뽑아낼수밖에 없다..
정말 이것뿐이란 말인가.. ㅠㅜ 어쩌지? 어쩌지?
ps. 팀장님이 DB팀장님과 협상하러 가셨다... 크흐흐
시스템에서 trace로 일주일정도 query 모아서 그것으로 합시다!!!! 를 주장하러..
제발 이게 통하길...
오늘 프로젝트가 점심때 오픈을 하였다.
프로젝트라고 부르기엔 규모가 약간 작은 편이지만 그래도 ^^ QA와 임시점검을 거쳐서
오픈을 한것이니 프로젝트라고 봐야겠지.
사실 이번 프로젝트는 시작부터 마음에 들지 않았다.
3월말에 오픈한 이전 프로젝트 설계 당시 구조가 전혀 다른 상품을 추가하는게 목표이었는데
기존 상품과 2개가 병행하게 되면 시스템의 복잡도가 3배이상 증가하니 기존 상품은 일괄 전환하자고
개발팀에서는 의사표현을 하였다.
하지만 사업팀에서는 일괄전환을 하게 되면 이탈하는 사용자가 생기게 되고 그것이 그대로 손실로
연결이 된다고 해서 자연소멸될때까지 끝까지 기다려야 한다고 절대적인!!!! 주장으로 할수 없이
시스템이 복잡해지더라도 사업팀의 요구사항을 받아드렸다.
그리고 3월말 잘 오픈을 하였다.
정말 많이 챙겨서 오픈하고 다음날 거의 문제가 없이 잘 서비스되고 있었다.
그때 긴급회의가 소집이 되었다.
사업팀 왈 부사장님이 '왜 상품을 2개나 출시해서 운영 리소스를 낭비하고 사용자에게 혼선을 주냐 , 한쪽 상품으로 전환시켜라!!'
했다고 한쪽 상품으로 전환 시켜야 한다고 한다.. 최대한 빨리..
대규모 전환 작업은 정기점검 시점이 아니면 불가능하고
사용자에게 최소 2주이상 Noti를 해야 하니 개발기간이 2주뿐이 없었다..
말이 개발 기간이 2주이지 자기네들 정책잡고 기획서 만들고 디자인 요청해서 디자인 작업하고 ...
더 큰 문제는 정책에서 혼선이 있는것이다.
전환동의를 받고 일괄 전환을 하는것이 미션이다.
그럼 전환동의를 받지 않는 사람들은 버린다? 꼬셔서 안넘어오면 포기다? --> 이건 금전적인 손해가 너무 커서..
기존상품을 그대로 쓰도록 해준다? --> 이게 무슨 전환이냐.. 그냥 상품 2개가 공존하는 형태이지..
한쪽을 선택하자니 피해가 너무 크다.. 하고 싶지는 않는데 윗사람은 시킨다..
아유.. 답답해..
시킨 부사장한테 가서
월매출 10억 손실이 생긴다. 그래도 가겠냐?
최대한 전환을 시켜서 10억 손실을 줄여보겠지만 회사 이미지나 손실금액은 발생한다. 그래도 가겠냐? 물어봐서
그래도 가겠다라고 하면 가는거지.. 시킨 사람은 따로 있는데 그 반대편을 생각하면서 결정을 못내리면
우린 언제 기획하고 디자인하고 개발하냐고.. 쩝.
어째튼 핵심 이슈결정 리스트를 만들어서 사업팀에 주고 이것들을 결정해주세요.. 라고 협박해서 결정을 받긴 하였다.
기획서를 받아서 보고 개발을 시작하면 좋겠지만 시간이 부족하니 머리속에 있는 것으로 개발시작이다.
개발을 하는 동안은 마침 팀장님도 3일간 휴가이시고 옛날로 돌아간 느낌이었다.
다른 사람들과의 개발속도가 잘 안맞고 귀찮으니깐 그냥 내가 모두 다 하겠다. 다른 사람들은 Don't Touch!!!
옛날에는 이게 참 좋은지 알았는데.. 내가 참 능력이 좋다라고 착각하고 있었고 ^^
과거와 다른 것은 내가 Service, DAO, 쿼리를 먼저 만들어서 공유하고 다른 사람들은 이것을 가져다가 사용하는
형태로 개발을 시작하였다. 이러다가 기획서를 받아 보았는데.. 휴..
기획서란 말이지 PPT로만 만들었다고 되는것이 아니라 정책과 Flow가 있어야 하는데..
그냥 네모칸에 버튼만 그려놓으면 어쩌라고.. 하나 하나 물어가면서 빠진 정책들은 챙겨가면서 어째튼 달렸다.
빨리 달렸다고 했는데도.. 시간이 부족하다. ㅠㅜ 결국 일요일 반나절 정도는 내 시간을 투자해야만 했다.
그래도 QA일정에 맞도록 준비를 하였다.
QA 시작일날..
QA 리스트가 없다.. ㅠㅜ 그렇겠지.. 기획서에 정책을 담을지 모르는데.. QA 리스트가 나올리가 없지..
정책 A 가 있다. A의 정책이 제대로 되는지 케이스 5개에 대해서 테스트 해본다.. 이게 QA 리스트이거든
결국 QA 리스트를 만드는것부터 도와주고 있다. x,y,z 의 경우에 대해서 체크해보시고요..
난 일정을 맞추겠다고 주말근무(팀장님이 알면 난 마이너스가 되니.. 이야기도 못하고.. 그냥 몰래 나와서 ㅠㅜ)까지 했는데
제대로 준비도 안된것을 보니.. 허탈하다.. 휴..
프로젝트 오픈날..
마지막 실환경에서의 테스트인데.. 테스트 데이터가 부족하다.. ㅠㅜ
개발환경이야 개발자들이 만들어놓은 데이터가 많으니 이런 저런 케이스에 대해서 체크가 가능했지만
실환경은 사용자정보 와 상품정보가 정확히 매칭이 되어야 하니, 그리고 이게 회계와 정산에 걸려있으니
함부로 데이터를 만들수 없다.
테스트 전용 사용자들이 있어야 하는데.. 그게 부족하니 테스트가 진행이 안된다.. 휴..
있는 데이터로 짜집기 하고 변경하고 확인하고.. 어째튼 오픈이다.. 그래도!
이번 프로젝트에서는 내가
사업담당자도 되었다가, 기획자도 되었다가, 개발자도 되었다가, QA 까지...
흠.. 지금은 잘못된 데이터 복구작업까지 한다.. 이러다가 슈퍼맨이 되어서 곧 하늘도 날겠다 -_-;;;;
