이번 주 일요일(2009년 1월 4일)에 TDD 스터디를 시작합니다.
첫 번째 스터디에서는 본 스터디의 목표나 개요를 간략하게 설명하고 코드 저장소라던가 TDD 규칙을 공유하는 시간을 갖겠습니다. 자세한 내용은 차후 봄싹 블로그를 통해 공지하겠습니다.
스터디 목표
- 완전한 TDD 매니아가 되는 것이 본 스터디의 목적은 아닙니다.
- 테스트를 어떻게 작성해야 하는지 감을 익히는 것.
- 테스트의 소중함을 실감해 보는 것.
- 테스트 작성에 익숙해 지는 것.
소스 코드 저장소
- 게시판 저장소와 비슷하게 SVN을 사용하며 이클립스에서 SVN 클라이언트(서브버전 or 서버시브)를 사용하여 접근합니다.
TDD 퀴즈
- 저 입사 초기에 토비님께서 TDD 교육을 해주신 적이 있는데 그 때 풀었던 문제 6개를 공개해서 사용해도 된다는 허락을 받았습니다.
TDD 규칙
- 제일 먼저 ToDo 작성.
- 그 다음은 테스트 작성.
- 테스트를 성공 시키는데 필요한 코드만 작성할 것.
- 리팩터링 할 것.
스터디 방법
- 2주 텀으로 TDD 퀴즈를 각자 하나씩 풀어서 소스 코드 저장소에 올려둡니다.
- 다른 사람 및 자신이 작성한 코드에 대한 리뷰를 PPT로 발표 준비를 해 옵니다.
- 테스트 없이 만든 코드가 있진 않은지 리뷰.
- 리팩터링이 필요한 코드 리뷰.
- 멋지다고 생각한 코드 리뷰.
- 덩덩덩...
- 스터디 당일 돌아가면서 자신이 리뷰한 내용을 발표합니다.
다 른 사람의 코드 리뷰를 할 떄는 좀 까칠하게 해도 괜찮습니다. 어렸을 떄 장기를 조금 배운적이 있는데 신기하게 자기가 둘 때 보다 훈수를 둘 때 더 잘 보이더라구요. 잘 하면 뭐하러 학습을 하겠습니까? 다들 똑같이 배우는 입장에서 다른 사람의 의견을 겸허하게 받아 들이는 스터디가 되면 좋겠습니다. 대신. 그렇다고 해서 자신이 이성적으로 맞다고 생각하는 걸 굽힐 필요는 없으니까. 자신 보다 경력이 많거나 말빨이 좋은 사람이 이러 저러한게 좋아 보인다고 해서 꼭 그게 맞을 꺼라는 생각을 하진 마시구요. 자신의 주장도 소신껏 이어가시고.. 그걸로 인해서 토론도 하고.. 그렇게 되면 재밌겠습니다.
새해 첫 스터디이니 만큼 재밌게 달려보자구요. 파이팅!!
첫 번째 스터디에서는 본 스터디의 목표나 개요를 간략하게 설명하고 코드 저장소라던가 TDD 규칙을 공유하는 시간을 갖겠습니다. 자세한 내용은 차후 봄싹 블로그를 통해 공지하겠습니다.
스터디 목표
- 완전한 TDD 매니아가 되는 것이 본 스터디의 목적은 아닙니다.
- 테스트를 어떻게 작성해야 하는지 감을 익히는 것.
- 테스트의 소중함을 실감해 보는 것.
- 테스트 작성에 익숙해 지는 것.
소스 코드 저장소
- 게시판 저장소와 비슷하게 SVN을 사용하며 이클립스에서 SVN 클라이언트(서브버전 or 서버시브)를 사용하여 접근합니다.
TDD 퀴즈
- 저 입사 초기에 토비님께서 TDD 교육을 해주신 적이 있는데 그 때 풀었던 문제 6개를 공개해서 사용해도 된다는 허락을 받았습니다.
TDD 규칙
- 제일 먼저 ToDo 작성.
- 그 다음은 테스트 작성.
- 테스트를 성공 시키는데 필요한 코드만 작성할 것.
- 리팩터링 할 것.
스터디 방법
- 2주 텀으로 TDD 퀴즈를 각자 하나씩 풀어서 소스 코드 저장소에 올려둡니다.
- 다른 사람 및 자신이 작성한 코드에 대한 리뷰를 PPT로 발표 준비를 해 옵니다.
- 테스트 없이 만든 코드가 있진 않은지 리뷰.
- 리팩터링이 필요한 코드 리뷰.
- 멋지다고 생각한 코드 리뷰.
- 덩덩덩...
- 스터디 당일 돌아가면서 자신이 리뷰한 내용을 발표합니다.
다 른 사람의 코드 리뷰를 할 떄는 좀 까칠하게 해도 괜찮습니다. 어렸을 떄 장기를 조금 배운적이 있는데 신기하게 자기가 둘 때 보다 훈수를 둘 때 더 잘 보이더라구요. 잘 하면 뭐하러 학습을 하겠습니까? 다들 똑같이 배우는 입장에서 다른 사람의 의견을 겸허하게 받아 들이는 스터디가 되면 좋겠습니다. 대신. 그렇다고 해서 자신이 이성적으로 맞다고 생각하는 걸 굽힐 필요는 없으니까. 자신 보다 경력이 많거나 말빨이 좋은 사람이 이러 저러한게 좋아 보인다고 해서 꼭 그게 맞을 꺼라는 생각을 하진 마시구요. 자신의 주장도 소신껏 이어가시고.. 그걸로 인해서 토론도 하고.. 그렇게 되면 재밌겠습니다.
새해 첫 스터디이니 만큼 재밌게 달려보자구요. 파이팅!!
올 한해가 끝나가는 이 즈음에 봄싹 2기도 끝이 났습니다. 참가해주신 모든 분들께 감사 인사를 드리고 싶습니다.
저는 요즘 스노우보드에 빠져있습니다. 그쪽 관련 동호회에 참석하여 새로운 사람들을 만나며 그들의 문화에 적응하고 스노우보드 타는 법을 배우는 재미가 쏠쏠 합니다. 그 동호회에 참석하면서 느낀점이 있는데 동호회가 제공해주는 서비스가 굉장히 편리하며 유용하다는 것입니다. 시즌방을 잡아서 보드를 타다가 쉴 수도 있고 잠을 자고 가도 되며 차를 가지고 있는 분들이 리조트까지 태워다 주기도 하고 먹을 것도 같이 나눠 먹고 보드 타는 법도 갈쳐줍니다. 그런 걸 보면서 자연스래 봄싹과 비교하게 되더군요. 우리 스터디는 참가자에게 어떤 서비스를 제공하고 있을까... 하고 말이죠. 아무것도 주는 것 없이 스터디에 시간을 투자하기만을 바라고 있는 거 아닐까.. 이래서 사람들이 점점 줄어들고 스터디 운영이 힘들어 지는거 아닐까 하고 말이죠.
그래서 이 스터디를 지속하려면 무언가 새로운 서비스가 있어야 한다는 생각이 들었습니다. 그게 무엇이 될지는 모르겠습니다. 무엇이 되던 봄싹 스터디에 참여하시는 분들이 보다 즐겁고 편하게 스터디를 하면서 자기개발을 할 수 있는 환경을 마련하고 싶습니다. 그래서 더 많고 다양한 사람들이 함께 할 수 있으면 좋겠습니다.
그동안 별 서비스도 없는 스터디 임에도 불구하고 자신의 피와 살같은 시간을 들여가며 열심히 코딩과 발표 준비를 해오신 분들께 진심으로 감사 인사를 드립니다. 내년에도 잘 부탁드리겠습니다. 더 즐겁고 더 유익한 스터디가 될 수 있도록 고민해 보겠습니다.
ps: 여성 개발자 모임과 조인트 스터디 어떤가요? ㅋㅋㅋ
저는 요즘 스노우보드에 빠져있습니다. 그쪽 관련 동호회에 참석하여 새로운 사람들을 만나며 그들의 문화에 적응하고 스노우보드 타는 법을 배우는 재미가 쏠쏠 합니다. 그 동호회에 참석하면서 느낀점이 있는데 동호회가 제공해주는 서비스가 굉장히 편리하며 유용하다는 것입니다. 시즌방을 잡아서 보드를 타다가 쉴 수도 있고 잠을 자고 가도 되며 차를 가지고 있는 분들이 리조트까지 태워다 주기도 하고 먹을 것도 같이 나눠 먹고 보드 타는 법도 갈쳐줍니다. 그런 걸 보면서 자연스래 봄싹과 비교하게 되더군요. 우리 스터디는 참가자에게 어떤 서비스를 제공하고 있을까... 하고 말이죠. 아무것도 주는 것 없이 스터디에 시간을 투자하기만을 바라고 있는 거 아닐까.. 이래서 사람들이 점점 줄어들고 스터디 운영이 힘들어 지는거 아닐까 하고 말이죠.
그래서 이 스터디를 지속하려면 무언가 새로운 서비스가 있어야 한다는 생각이 들었습니다. 그게 무엇이 될지는 모르겠습니다. 무엇이 되던 봄싹 스터디에 참여하시는 분들이 보다 즐겁고 편하게 스터디를 하면서 자기개발을 할 수 있는 환경을 마련하고 싶습니다. 그래서 더 많고 다양한 사람들이 함께 할 수 있으면 좋겠습니다.
그동안 별 서비스도 없는 스터디 임에도 불구하고 자신의 피와 살같은 시간을 들여가며 열심히 코딩과 발표 준비를 해오신 분들께 진심으로 감사 인사를 드립니다. 내년에도 잘 부탁드리겠습니다. 더 즐겁고 더 유익한 스터디가 될 수 있도록 고민해 보겠습니다.
ps: 여성 개발자 모임과 조인트 스터디 어떤가요? ㅋㅋㅋ
올해 마지막 모임이 아래와 같은 걸로 알고 있습니다.
저번주에 기선님 만나서 책을 전해줄려고 했는데, 어떤 사정이 있었나 봅니다.
그래서 현재 제가 가지고 있는데 28일날 책을 가지고 가겠습니다.
개인 사정으로 저희 딸과 같이 갈것 같으니, 가서 책만 간단히 전해드리고 올께요.
책을 받을실분 두분이 정해진걸로 알고 있으니 받는 분은 꼭 참석하시면 감사 하겠습니다.
( 아...딸과 함께 험난한 기차여행을 하겠구나... )
================= 추가입니다. ===================================
참석여부 확인 댓글도 좀 알려주세요~ [성윤추가]
일자 : 2008년 12월 28일(일요일)
시간 : 15:00 ~ 18:00
장소 : 종로토즈
시간 : 15:00 ~ 18:00
장소 : 종로토즈
저번주에 기선님 만나서 책을 전해줄려고 했는데, 어떤 사정이 있었나 봅니다.
그래서 현재 제가 가지고 있는데 28일날 책을 가지고 가겠습니다.
개인 사정으로 저희 딸과 같이 갈것 같으니, 가서 책만 간단히 전해드리고 올께요.
책을 받을실분 두분이 정해진걸로 알고 있으니 받는 분은 꼭 참석하시면 감사 하겠습니다.
( 아...딸과 함께 험난한 기차여행을 하겠구나... )
================= 추가입니다. ===================================
참석여부 확인 댓글도 좀 알려주세요~ [성윤추가]
쏠로에겐 악몽같은... 크리스마스가 다가오고 있어요. 큰일이에요.
다들 크리스마스에 어떻게 대처할지 계획은 세우셨나요?
머리좀 식히세요~
다들 크리스마스에 어떻게 대처할지 계획은 세우셨나요?
머리좀 식히세요~
강남에 삼성그룹이 신사옥을 지었다고 해서 놀러갔다 왔습니다.
정말 잘 지어 놨더군요. 가운데 덩그라니 알박기 한듯한 건물도 볼만했고~ ^^;
각설하고 어제 했던 이야기에 덧글도 많이 달리고 답글로 올라왔으니,
좀 딴 길로 새는 듯 하지만 의문을 적으셨길래 재답변 들어갑니다.
태클 걸려는 글은 아닙니다. 나름 IT에서 굴러먹은 이야기를 좀 해보려구요.
IT 분야 중에서 소프트웨어 개발 분야는 짧은 시간에 많은 발전이 이루어져 왔습니다.
하드웨어 분야 못지 않게 말이죠. 그런데 문제는 좀처럼 체계가 잡히고 있지 않고 있다는 것이죠.
자바나 C 같은 언어적인 기본 도구들은 거의 틀이 잡혀서 혼란이 덜하지만, 그외의 개발 도구들은
너무 많은 선택의 여지가 있습니다. 프레임워크, 소스 버전 관리, 컴파일러, 통합 개발환경, 미들웨어 서버,
통신 프로토콜, 보안 관련 표준도 다양하고...
SI 분야에 계신 분도 있고, 혹은 솔루션 분야에서 일하시는 분도 있고, 스스로 도구를 선택할 수 있는
자리에 있는 사람도 있고, 선임자가 정한 것들을 무조건 사용해야 하는 사람도 있습니다.
제가 하고 싶은 얘기는 닥치고 열심히 노력하는 걸 미덕으로 생각하지 말자는 것입니다.
무엇이 좋은가? 어떤 트렌드가 있는가? 과연 지금 사용하고 있는 도구가 최선의 선택인가에 대해서
비판적으로 바라보는 자세가 필요하다고 봅니다.
30대, 40대, 그리고 50대까지 IT에서 살아남으려면 그저 열심히 하는 것만으로는 부족하다고 생각합니다.
10년 전에 사용하던 유용한 툴, 혹은 유명한 툴 중에서 여전히 쓸만한 것들은 많지 않습니다.
자칫 유행만 쫒다가, 어느새 과거에 유명하던 개발자라는 말을 듣게 되지는 않을까?
그런 사람들을 많이 보아 왔고, 또 보게 될 것이기 때문에
개발자 자신의 포지션(position), 그리고 각자가 사용하는 도구에 대한 차분한 고민도 필요하지 않을까요?
또, 독학을 하더라도 올바른 길을 가고 있는지 계속 살펴볼 필요가 있습니다.
UML이 뜬다고 해서 다들 열심히 UML을 공부해야 한다고 난리가 난적이 있습니다.
EJB를 하면 최고로 인정 받을 수 있다고 해서 다들 EJB에 심취한 적도 있습니다.
닷넷이 나왔을 때, 마이크로소프트 소속 에반젤리스트들의 설레발은 지금도 눈 앞에 선합니다.
ERP가 한참 유행한 적도 있고, 작년과 올해에는 Flex라는 툴이 나와서 아도브에서 열심히
홍보하기도 했죠. 뭐만 열심히 하면 남들보다 2배 벌 수 있다. 참 지겹게 듣는 이야기 입니다.
그런데, 자바는 또 얼마나 살아남을 수 있을까요? Spring 이것 또한 한 때의 유행이 되는 건 아닐까요?
저는 자바를 좋아합니다. 스프링도 꽤 괜찮은 프레임워크라고 생각합니다.
스트럿츠도 사용하고, EJB도 사용해 봤고, 데이터베이스도 여러가지 써봤습니다.
독학과 삽질 분야에 대해서는 자격증을 국가에서 내준다면
삽질만 아는 대통령께 표창 받을 수 있다고 생각합니다. ^^;
그런데 말이죠. 제가 해본 여러가지 일 중에서 솔직히 말하자면 자바, 스프링, 데이터베이스 이런 기술
들이 차지하는 비중은 그리 크지 않습니다. 도구는 도구일 뿐이라는 것이죠.
스프링 스터디 블로그에서 왜 이런 말을 하냐구요?
스프링 프레임워크 자체를 목적으로 보지는 말자는 것입니다.
왜 스프링 프레임워크를 사용하고, 이것을 사용함으로써 어떤 부가가치를 창출할 수 있는가?
컨설턴트들만이 그런 얘기를 해야 하고, 할 수 있는 건 아니라고 봅니다.
우리가 프로 개발자라면 말이죠. 왜 나를 써야 하는가? 왜 내가 많은 연봉을 받을 가치가 있는가?
스프링 프레임워크를 아는 개발자를 고용함으로써 어떤 이익을 기대할 수 있는가...
이런 이야기를 면접에서 얘기할 수 있는 개발자가 되어야 한다고 생각합니다.
개발자는 자신의 능력을 파는 사람이니까요~
줄타기에 대한 이야기를 말씀 드리겠습니다.
취향의 문제라고 말씀하시는 건 솔직히 말해서 좀 아마추어적이라고 생각합니다.
기분 나쁘시다면 먼저 사과의 말씀을 드려야 할 것 같네요. 비난하려는 건 아닙니다.
소프트웨어 개발을 한다는 것이 자기 좋아서 하는 일이라는 측면에서 보면
당연히 취향도 중요한 것이지만, 제가 하려던 얘기는 엄연히 프로라는 위치에서
보았을 때, 프로라면 어찌해야할 것인가 라는 이야기 입니다.
즉, 관점이 틀린 이야기가 되었다는 것이죠. 제 본래 의도에 대한 부연 설명을 드립니다.
개발자도 언젠가는 매니저가 됩니다. 적어도 우리나라에서는 말이죠.
그냥 개발자로 남는 상황에서도 선임 개발자라면 팀 내에서 어떤 프레임워크를 사용해야할 지
자기 주장을 내놓아야 합니다. 소프트웨어 개발을 개인의 취향에 맡겨 두던 시대는 지나갔으니까요.
그런데, 프레임워크를 사용하는 것, EJB를 사용할지 결정하는 것, 다양한 도구 중에 어떤 것을 표준으로
선택하는가 하는 문제는 그리 단순한 일이 아닙니다. 수십명 혹은 수백명이 일사분란하게 움직여야 하는데
표준화된 기술을 채택하지 않으면 엄청난 혼란을 초래하고, 그에 따른 기회비용 상실, 프로젝트 지연,
심지어 회사의 존폐 위험까지도 발생할 수 있습니다.
지금 시대에 프레임워크를 사용하지 않는 기업은 거의 없는 것 같습니다.
이건 선택의 문제가 아니라고 여겨집니다.
시간이 바로 비용인데, 프레임워크 따위는 없어도 된다는 사고로 작은 시스템을 개발했다가,
나중에 유지보수 비용이 겉잡을 수 없이 상승해서 결국 다시 개발하는 경우도 비일비재합니다.
작은 기업에서는 별 일이 아닌데, 나름 규모가 있는 기업에서는 큰 비용 상실이 발생합니다.
프레임워크를 사용하지 않고 자기 혼자 멋대로 시스템을 개발한다는 것도 위험한 생각이라고 생각합니다.
1인 기업을 꾸린다면 모를지만 말입니다.
람보 같은 개발자 많습니다. 이들도 위험합니다. 왜냐하면 혼자 장렬히 전사하면 다행인데,
람보 개발자가 열심히 개발하고 장렬히 전사하거나, 시스템을 다른 사람들에게 넘겨주고 퇴사해버리면
결국 남은 개발자들이 뒷감당을 못하고 몇 배의 비용을 들여서 재개발하는 경우를 봐 왔습니다.
참호 속의 개발자... 많이 있습니다. 수백명이 참여하는 대형 프로젝트에서 일하다 보면
매일 야근을 하고 있음에도 도무지 주어진 과제를 해결하지 못하고,
우물쭈물 하다고 결국 몸이 아프다는 핑계라거나, 집안 사정이라는 이유 등등의 핑계를 대고
회사를 그만두는 경우가 있습니다. 이들의 뒷감당 해야 하는 개발자들도 부지기수인데,
과연 프레임워크를 모르는 것이 취향 차이일 뿐이라고 치부할 수 있을런지 의문입니다.
이런 이야기들이 제 개인적인 경험에 기초한 것이고, 공감하지 않으실 분도 있겠지만...
또 많은 분들이 겪어본 일들입니다. 앞서 얘기했듯이 태클 걸려는 글이 아니라,
IT 분야의 어느 막장 달리 말해서 SI 현장이라는 곳의 이야기 였습니다.
참고하시라는 거죠~ 물론, SI에서 일하지 않으시겠다면... 프레임워크를 모르는 건 그저 취향일 뿐입니다.
너무 진지해지면 지는 겁니다... 후후~
정말 잘 지어 놨더군요. 가운데 덩그라니 알박기 한듯한 건물도 볼만했고~ ^^;
각설하고 어제 했던 이야기에 덧글도 많이 달리고 답글로 올라왔으니,
좀 딴 길로 새는 듯 하지만 의문을 적으셨길래 재답변 들어갑니다.
태클 걸려는 글은 아닙니다. 나름 IT에서 굴러먹은 이야기를 좀 해보려구요.
IT 분야 중에서 소프트웨어 개발 분야는 짧은 시간에 많은 발전이 이루어져 왔습니다.
하드웨어 분야 못지 않게 말이죠. 그런데 문제는 좀처럼 체계가 잡히고 있지 않고 있다는 것이죠.
자바나 C 같은 언어적인 기본 도구들은 거의 틀이 잡혀서 혼란이 덜하지만, 그외의 개발 도구들은
너무 많은 선택의 여지가 있습니다. 프레임워크, 소스 버전 관리, 컴파일러, 통합 개발환경, 미들웨어 서버,
통신 프로토콜, 보안 관련 표준도 다양하고...
SI 분야에 계신 분도 있고, 혹은 솔루션 분야에서 일하시는 분도 있고, 스스로 도구를 선택할 수 있는
자리에 있는 사람도 있고, 선임자가 정한 것들을 무조건 사용해야 하는 사람도 있습니다.
제가 하고 싶은 얘기는 닥치고 열심히 노력하는 걸 미덕으로 생각하지 말자는 것입니다.
무엇이 좋은가? 어떤 트렌드가 있는가? 과연 지금 사용하고 있는 도구가 최선의 선택인가에 대해서
비판적으로 바라보는 자세가 필요하다고 봅니다.
30대, 40대, 그리고 50대까지 IT에서 살아남으려면 그저 열심히 하는 것만으로는 부족하다고 생각합니다.
10년 전에 사용하던 유용한 툴, 혹은 유명한 툴 중에서 여전히 쓸만한 것들은 많지 않습니다.
자칫 유행만 쫒다가, 어느새 과거에 유명하던 개발자라는 말을 듣게 되지는 않을까?
그런 사람들을 많이 보아 왔고, 또 보게 될 것이기 때문에
개발자 자신의 포지션(position), 그리고 각자가 사용하는 도구에 대한 차분한 고민도 필요하지 않을까요?
또, 독학을 하더라도 올바른 길을 가고 있는지 계속 살펴볼 필요가 있습니다.
UML이 뜬다고 해서 다들 열심히 UML을 공부해야 한다고 난리가 난적이 있습니다.
EJB를 하면 최고로 인정 받을 수 있다고 해서 다들 EJB에 심취한 적도 있습니다.
닷넷이 나왔을 때, 마이크로소프트 소속 에반젤리스트들의 설레발은 지금도 눈 앞에 선합니다.
ERP가 한참 유행한 적도 있고, 작년과 올해에는 Flex라는 툴이 나와서 아도브에서 열심히
홍보하기도 했죠. 뭐만 열심히 하면 남들보다 2배 벌 수 있다. 참 지겹게 듣는 이야기 입니다.
그런데, 자바는 또 얼마나 살아남을 수 있을까요? Spring 이것 또한 한 때의 유행이 되는 건 아닐까요?
저는 자바를 좋아합니다. 스프링도 꽤 괜찮은 프레임워크라고 생각합니다.
스트럿츠도 사용하고, EJB도 사용해 봤고, 데이터베이스도 여러가지 써봤습니다.
독학과 삽질 분야에 대해서는 자격증을 국가에서 내준다면
삽질만 아는 대통령께 표창 받을 수 있다고 생각합니다. ^^;
그런데 말이죠. 제가 해본 여러가지 일 중에서 솔직히 말하자면 자바, 스프링, 데이터베이스 이런 기술
들이 차지하는 비중은 그리 크지 않습니다. 도구는 도구일 뿐이라는 것이죠.
스프링 스터디 블로그에서 왜 이런 말을 하냐구요?
스프링 프레임워크 자체를 목적으로 보지는 말자는 것입니다.
왜 스프링 프레임워크를 사용하고, 이것을 사용함으로써 어떤 부가가치를 창출할 수 있는가?
컨설턴트들만이 그런 얘기를 해야 하고, 할 수 있는 건 아니라고 봅니다.
우리가 프로 개발자라면 말이죠. 왜 나를 써야 하는가? 왜 내가 많은 연봉을 받을 가치가 있는가?
스프링 프레임워크를 아는 개발자를 고용함으로써 어떤 이익을 기대할 수 있는가...
이런 이야기를 면접에서 얘기할 수 있는 개발자가 되어야 한다고 생각합니다.
개발자는 자신의 능력을 파는 사람이니까요~
줄타기에 대한 이야기를 말씀 드리겠습니다.
취향의 문제라고 말씀하시는 건 솔직히 말해서 좀 아마추어적이라고 생각합니다.
기분 나쁘시다면 먼저 사과의 말씀을 드려야 할 것 같네요. 비난하려는 건 아닙니다.
소프트웨어 개발을 한다는 것이 자기 좋아서 하는 일이라는 측면에서 보면
당연히 취향도 중요한 것이지만, 제가 하려던 얘기는 엄연히 프로라는 위치에서
보았을 때, 프로라면 어찌해야할 것인가 라는 이야기 입니다.
즉, 관점이 틀린 이야기가 되었다는 것이죠. 제 본래 의도에 대한 부연 설명을 드립니다.
개발자도 언젠가는 매니저가 됩니다. 적어도 우리나라에서는 말이죠.
그냥 개발자로 남는 상황에서도 선임 개발자라면 팀 내에서 어떤 프레임워크를 사용해야할 지
자기 주장을 내놓아야 합니다. 소프트웨어 개발을 개인의 취향에 맡겨 두던 시대는 지나갔으니까요.
그런데, 프레임워크를 사용하는 것, EJB를 사용할지 결정하는 것, 다양한 도구 중에 어떤 것을 표준으로
선택하는가 하는 문제는 그리 단순한 일이 아닙니다. 수십명 혹은 수백명이 일사분란하게 움직여야 하는데
표준화된 기술을 채택하지 않으면 엄청난 혼란을 초래하고, 그에 따른 기회비용 상실, 프로젝트 지연,
심지어 회사의 존폐 위험까지도 발생할 수 있습니다.
지금 시대에 프레임워크를 사용하지 않는 기업은 거의 없는 것 같습니다.
이건 선택의 문제가 아니라고 여겨집니다.
시간이 바로 비용인데, 프레임워크 따위는 없어도 된다는 사고로 작은 시스템을 개발했다가,
나중에 유지보수 비용이 겉잡을 수 없이 상승해서 결국 다시 개발하는 경우도 비일비재합니다.
작은 기업에서는 별 일이 아닌데, 나름 규모가 있는 기업에서는 큰 비용 상실이 발생합니다.
프레임워크를 사용하지 않고 자기 혼자 멋대로 시스템을 개발한다는 것도 위험한 생각이라고 생각합니다.
1인 기업을 꾸린다면 모를지만 말입니다.
람보 같은 개발자 많습니다. 이들도 위험합니다. 왜냐하면 혼자 장렬히 전사하면 다행인데,
람보 개발자가 열심히 개발하고 장렬히 전사하거나, 시스템을 다른 사람들에게 넘겨주고 퇴사해버리면
결국 남은 개발자들이 뒷감당을 못하고 몇 배의 비용을 들여서 재개발하는 경우를 봐 왔습니다.
참호 속의 개발자... 많이 있습니다. 수백명이 참여하는 대형 프로젝트에서 일하다 보면
매일 야근을 하고 있음에도 도무지 주어진 과제를 해결하지 못하고,
우물쭈물 하다고 결국 몸이 아프다는 핑계라거나, 집안 사정이라는 이유 등등의 핑계를 대고
회사를 그만두는 경우가 있습니다. 이들의 뒷감당 해야 하는 개발자들도 부지기수인데,
과연 프레임워크를 모르는 것이 취향 차이일 뿐이라고 치부할 수 있을런지 의문입니다.
이런 이야기들이 제 개인적인 경험에 기초한 것이고, 공감하지 않으실 분도 있겠지만...
또 많은 분들이 겪어본 일들입니다. 앞서 얘기했듯이 태클 걸려는 글이 아니라,
IT 분야의 어느 막장 달리 말해서 SI 현장이라는 곳의 이야기 였습니다.
참고하시라는 거죠~ 물론, SI에서 일하지 않으시겠다면... 프레임워크를 모르는 건 그저 취향일 뿐입니다.
너무 진지해지면 지는 겁니다... 후후~
Prev
Rss Feed