조대협의 블로그

좋은 개발자가 되고 싶어요. 서버 개발자는 어떻게 되나요? 조대협 (http://bcho.tistory.com) 블로그를 운영하면서 자주 받는 질문들이 "좋은 개발자가 되고 싶어요." "아키텍트는 어떻게 되나요?" "서버 개발자가 되려면 어떻게 해야 하나요?" 라는 질문들인데, 일일이 답변을 드리기가 어려워서 생각을 정리해봅니다. 사실 답은 저도 잘 모르겠습니다. 아직 좋은 개발자가 아닌거 같아서요. 그래도 그간 IT를 경험하면서 나름의 생각을 정리해 보면 다음과 같습니다. 좋은 개발자가 되는 방법은 학교에서 다 배웠다. 사실 좋은 개발자가 되는 방법은 학교에서 다 배웠습니다. 대학교 과정에는 IT 개발에 필요한 필수 이론들을 다 배웁니다. 자료구조, OS, 소프트웨어 공학론 등등. 다들 중요한 내용이지..

https://www.scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-howFive essentials of self-organizing teams Competency: Individuals need to be competent for the job at hand. This will result in confidence in their work and will eliminate the need for direction from above. Collaboration: They should work as a team rather than as a group of individuals. Teamwork is enc..

소프트웨어를 잘하고 싶으시면 개발자를 그만 뽑으세요. 간만의 포스팅입니다. 요즘 일도 너무 바쁘고 여유가 안생겨서, 그동안 포스팅을 거의 못했네요. 평소에 생각하던 내용인데, 요즘 들어 소프트웨어니, 서비스니 하면서 여기저기서 사람 뽑는 글들이 많아서 올려봅니다. "소프트웨어를 잘하고 싶은데, 개발자를 뽑지 말라니??" 의아하게 생각하실지도 모르지만, 낚시 타이틀이 아니라 진정으로 드리고 싶은 이야기 입니다.제가 해외 개발자들이나 엔지니어들과 일해봤을때, 한국 개발자가 실력적으로 그렇게 밀린다고 생각하지는 않습니다. 문제는 관리입니다.!!아무리 똑똑한 개발자를 뽑아 놓는다 하더라도, 개발자들이 만들어야 할 소프트웨어의 구조를 잡을 아키텍트가 없고, 프로젝트를 위한 계획과 엔지니어에 대한 배치를 제대로 하..

오늘은 개발자의 잉여력에 대한 이야기를 해보려고 합니다.잉여력이란... 남는 시간입니다. 근무시간도 좋고 집에서 쉬는 시간도 좋습니다.개발자라는 특성상, 모두는 아니지만 대부분은 적어도 기술에 대한 흥미를 가지고 새로운 것을 접하는 것을 좋아 하는 특성상, 남는 시간에는 새로운 기술을 접하고 공부하고, 때로는 새로운 것을 만들어내기도 합니다. 이런 잉여력의 산실이 오픈소스와 블로그등입니다.오픈소스는 누가 시켜서 하는 것도 아니고, 돈을 벌기 위해서도 아니고, 그냥 남는 시간에 재미있으니까는 하는일입니다.개발자는 꼭 몬가를 시키지 않아도 스스로 공부를 합니다. 왜 갑자기 이런 이야기를 하는가 하면, 국내 기업의 경우, 개발자의 잉여력을 발휘할 시간이 없습니다. 항상 바쁘기 때문이지요. 사실 문화적인 차이도..

요즘 예전의 해왔던 일의 경험을 최대한 쏟아 부어서 열정적으로 일을 하고 있습니다. 서비스도 기획해보고, 분석도 해보고, 딜 네고도 해보고, 사람도 뽑고, 예산 관리도 하고, 일정 조정도 하고 사람 관리도 하고, 테스트도 하고,튜닝도 하고, 설계도 하고, 설득도하고... 코딩 빼놓고는 대부분 다하는 군요.. 시점이 바뀌다 보니까는 사람을 보는 눈도 조금 바뀌지 않았나 싶습니다. 요즘 IT 인력, 특히 개발자가 없다 보니까는 개발자 단가는 올라가고, 일의 강도도 쉽게 높일 수 없어지는 것 같습니다. 이제야 제대로 IT 인력들이 대접받기 시작하지 않나 싶은데, 아마 많은 시니어 개발자들이 IT의 길을 떠나거나 앱쪽으로 전향을 하고, 새로운 주니어 인력의 충원이 적기 때문에 한참 노련한 30대 중반 개발자들이..

근래에 느끼는 것인데, 근래에 한국 IT 가 조금씩 바뀌어가는 것 같다. 첫번째는 대우? 또는 인력의 변화인데. 삼별전자가 기술 내재화를 목적으로 벤더의 협력사 엔지니어나, 벤더 엔지니어, 포탈 개발자들을 닥치는 데로 연봉 올려주면서 데리고 가고 있다. K티는 클라우드 한다고 하더니, 열심히 하는 클라우드 벤처와 망해가던 벤쳐(T?)에 있던 선수들을 데리고 가서 기술을 내재화하는 노력들을 하고 있다. (좋은 현상들입니다.!! 연봉 많이들 올려서 데리고 가세요..) 그리고 요즘 프로젝트를 해보면 SI사 인력들도 다르다... 지금 일하는 SI社 사무실에만 봐도.. 다들 영어 다 잘한다.. 외국 컨설턴트도 종종 보인다.. 영어만 잘하는 것이 아니라 논리적인 사람들이 많아졌다. 한마디로 꼰대님들은 안보이신다는...

트위터에 개발자당 오픈했습니다. 검색하셔서 "#개발자당_" 찾으시면 되구요.아니면 간편하게 http://bit.ly/a7xxk7 링크 클릭하셔도 됩니다. IT 관련 소식들 같이 공유했으면 합니다. 많이 Follow 부탁드립니다. :) IT관련 뉴스들 제가 매일 올리고 있으니.. 무한 RT부탁합니다.

J2EE 시절까지는 자바 개발의 주류가 JEE Spec에 기술된 기술 위주였다. JDBC,JTS,JTA,JMS,EJB,Servlet/JSP etc 그런데, 오픈소스의 활성화와 Spring의 판도 변화로 이것이 완전히 바뀌어 버렸다. 어제 자바스터디 현재 운영자가 번역했다고 보내준 Spring 2.5 책을 쭈욱 읽어봤는데, 이러한 확신은 더 드는 듯 하다. JEE5.0에서 들고 나온 JSF,EJB3.0,JDO 등은 국내에서는 거의 사용되지 않고 JSF/Spring MVC/Struts,Sping DI & AOP , IBatis,Hibernate와 같은 오픈 소스 조합의 개발이 가장 널리 쓰이는 조합이다. 이런상태에서 JEE6,7등의 스펙이 나오는 것이 더 이상 의미가 있을까? 벤더드링 Spring등을 흡수해..

지금까지 delivery한 프로젝트를 생각해보니, 문제가 없이 잘 되었던 프로젝트는 어떤 이유에건간에 (자의든 타의든) 1~2개월정도의 프로토타입핑 시간을 가졌던 것으로 기억된다. 물론 지금 하고 있는 프로젝트 역시 Prototyping을 진행하고 있다. 이 과정에서는 1.고객의 요건을 분석한후 2.요건을 패턴화 하여 분리한후 3.패턴별로 프로토 타입을 구현한다. 4.그리고 기능/비기능 테스트를 통해서 프로토 타입을 검증한다. 이 과정이 끝나면 아키텍쳐나 시스템에 대한 디자인은 어느정도 이상의 완성도를 가지게 되고, 그 다음부터는 패턴에 따라서 찍어내기만 하고, Task 에 대한 스케쥴 관리만 원할하게 하면 된다. 결국 프로젝트의 성공 여부는 얼마나 검증되고 안정된 아키텍쳐를 초기에 잘 뽑아내는가인거 같..

요즘 프로젝트가 바쁘다 보니, 블로그에 포스팅할 시간이 없다. REST, ROA (Resource Oriented Architecture), Collaboration, Code Review등 포스팅 하고 싶은 것들이 많은데.. 그나마 시간내서 쓰던 포스팅들도 이번달에는 거의 힘든 상태가 되었다. 아마도 다음달이나 되야, 포스팅들이 올라가지 않을까? 이번 글은 어제 저녁에 써놨던 아키텍트,PM,개발자의 차이 중 2번째로 아키텍트에 대해서 이야기 해보고자 한다. 아키텍트 아키텍트는 전체 시스템을 디자인하고 설계하는 역할을 가지는 사람이다. 아키텍처링은 크게 두가지로 나뉘어 지는데 첫번째는 비지니스 아키텍쳐, 다음은 테크니컬 아키텍쳐이다. 비 지니스 아키텍쳐랑, 해당 시스템이 비지니스적으로 어떤 의미를 갖는지..