저작권 안내: 저작권자표시 Yes 상업적이용 No 컨텐츠변경 No

스프링5 입문

JSP 2.3

JPA 입문

DDD Start

인프런 객체 지향 입문 강의

'개발자'에 해당되는 글 3건

  1. 2016.08.03 문서
  2. 2013.04.05 도대체 실무가 뭐지? (4)
  3. 2012.07.09 난 개발자인가? 그리고 앞으로는? (10)

문서

개발자이야기 2016.08.03 21:47

난 개발과 관련해서 문서 작성을 선호하는 편이다. 그렇다고 검수 산출물과 같은 형식적인 문서 작성을 선호하는 것은 아니다. 주로 다음을 위한 문서 작성을 선호한다.

  • 대화 재료
  • 미래에 시스템을 운영할 사람

대화 재료로서의 문서는 회의에서 효과가 크다. 기능 스펙, 설계 초안, 구현 아이디어, 목차 등을 정리한 문서는 대화를 시작하기 위한 좋은 재료가 된다. 이때 문서는 소통이 가능한 수준의 내용만 담으면 된다. 간단한 클래스 다이어그램이나 상태 다이어그램이어도 되고, 자유 형식의 사용자 스토리여도 된다. 또는 종이에 끄적인 내용을 복사해서 함께 봐도 되고, 화이트보드에 그려 놓은 내용을 사진으로 찍어 출력한 문서여도 된다. 이 문서를 바탕으로 대화를 하면서 내용을 발전시켜 나갈 수만 있으면 된다.


대화 재료로 사용할 문서가 격식을 갖출 필요는 없지만, 그렇다고 내용을 대충 만들어도 된다는 건 아니다. 재료가 나쁘면 대화도 함께 나빠진다. 대화 과정에서 발전시켜야 할 내용이 문서에 없으면, 그 문서는 도움이 안 된다. 그래서, 대화 재료에 사용할 문서를 작성하는 사람은 논의할 내용의 핵심이 잘 담기도록 노력해야 한다.


잘 만든 문서 하나는 대화 참석자를 빠르게 핵심 주제로 안내하고 대화 결과물이 좋을 가능성을 높여준다. 몇 년 전에 스프링캠프 발표 주제를 정리하기 위해 운영진과 회의를 한 적이 있다. 그때 발표하고 싶은 주제와 개요 수준의 목차를 담은 마인드맵 문서를 대화 재료로 들고 나갔다. 그 문서를 기반으로 빠르게 컨텍스트를 맞춘 덕에 회의가 수월하게 끝난 기억이 난다.


미래에 시스템을 운영할 사람을 위한 문서는 중요하다. 퇴사 시점에 이런 문서를 작성해서 후임자에게 넘기는 경우가 많은데, 그 시점보다는 중요 마일스톤을 찍는 시점에 운영과 관련된 문서도 함께 정리하는 것이 좋은 것 같다. 한참 시간이 흘러 작성하려면 왜 배포 과정에서 우회 방법을 선택했는지, 특정 IP를 왜 열었는지와 같은 이유를 잊게 된다. 이는 중요한 정보를 사라지게 만든다.


운영을 위한 문서는 코드처럼 정리를 해야 한다. 더 이상 필요 없으면 삭제해서 혼란을 제거하고, 기존 문서의 설명과 다른 절차가 추가되었다면 반영해서 정보가 사라지지 않도록 해야 한다. 운영을 위한 문서가 현재를 반영하지 못하면 그 문서는 죽은 문서가 되고, 중요 정보를 구전으로 전수받아야할 상황이 발생한다.


이런 문서는 정확한 표현이 중요하다. 애매모호한 표현을 사용하면 문서를 읽는 사람을 혼란스럽게 할뿐이다. 이는 말로 하는 것과 차이가 없다. 말로 전달하는 것 이상의 효과를 얻으려면 공유할 내용을 적절한 방법으로 표현하는 연습을 해야 한다. 경우에 따라 문장을 쓰거나 코드를 보여주거나 다이어그램으로 표현할 수 있어야 한다. 


이런 표현력이 쌓이면 대화 중에도 즉석에서 도움이 되는 대화 재료를 만들 수 있다. 아래 그림은 몇 해 전에 회의 중간에 그린 다이어그램이다. 간단한 다이어그램이지만 이 그림이 나오기 전까지 회의에 참여한 사람들은 서로 다른 소리를 하고 있었다. 개발자, PM, 기획자, 또 다른 개발자가 같은 이야기를 듣고 서로 다르게 이해를 했다. 그런 상황이 계속될 기미가 보이기 시작해서, 자리에서 일어나 화이트보드에 대화를 정리하기 위한 다이어그램을 그렸다. 이 그림이 그려진 이후 같은 이해를 바탕으로 회의가 정리되기 시작했다.



개발자가 본능적으로 문서 작성을 싫어하는지는 모르겠지만, 좋은(?) 개발자가 되려면 의사소통 능력이 중요하며 그 능력을 향상시켜주는 것 중 하나가 문서 작성 역량이라고 생각한다. 문서는 말과 함께 의사소통을 위한 중요한 수단이기 때문이다. 코드의 표현력이 중요한 이유가 코드에 담긴 지식을 자신을 포함한 누군가에게 전달하기 위함인것처럼, 동일하게 문서 역시 누군가에게 뭔가를 전달할 때 사용할 수 있는 방법이다.


문서를 작성하는 것은 너무 너무 귀찮은 일이지만, 도움이 되는 문서를 제대로 작성하는 것은  매우 중요한 일이기도 하다. 이 중요한 일을 잘 하기 위한 연습을 게을리하는 개발자는 되지 말자.


Posted by 최범균 madvirus

댓글을 달아 주세요

흔히들 실무와 관련된 학습을 한다는 분들의 말을 듣다보면 그 실무라는 것이 사용 기술에 특화된 경우를 많이 본다. 스프링 프레임워크의 사용법이라든지, jQuery 사용법, 하둡 설치, Redis 연동, Node.js 이용한 메시지 처리 등 뭔가 기술 사용에 대한 것들이 많다. 그런데, 실무라는 게 진짜 이것 뿐인가? 그래서, 개발자에게 있어 실무가 뭔지 고민을 좀 해 보려고 한다. 


실무의 사전적 정의는 '실제적이고 구체적인 업무'이다. daum 사전을 검색해 보면 '실제'란 '있는 사실이나 현실 그대로의 상태나 형편'이고 '구체'란 '사물이나 현상이 일정한 모습을 갖추고 있는 것'이다. 이런 의미를 종합해보면 개발에 있어 실무란 '소프트웨어를 만들기 위해 수행하는 모든 업무'라고 볼 수 있을 것 같다.


소프트웨어를 만들기 위해 수행하는 모든 업무를 이곳에 다 나열할 수 없지만 (나 스스로 이걸 다 알지 못한다), 잠깐만 생각해봐도 다음과 같은 것들이 떠오른다.

  • 코딩
  • 요구사항 분석(요구사항 이해)
  • 설계 / 모델링
  • 테스트/QA (기능, 성능)
  • 소스 관리 / 버전 관리
  • 배포 / 인프라 관리
  • 운영
  • 일정 관리 / 비용 관리 (최소한 일정과 비용에 대한 개념)

하나의 소프트웨어가 만들어지려면, 위의 모든 작업들이 유기적으로 연결되어 실행되어야 한다. 요구사항이 제대로 분석되지 않은 상황에서 코드를 작성하면 의미없는 소프트웨어가 만들어질 것이다. 설계가 유연하지 않으면 요구사항의 변화를 제대로 수용할 수 없을 것이다. 소스 관리와 배포 관리가 되지 않으면, 이전 버전이 배포될 지도 모른다. 일정 관리가 되지 않으면 제때에 소프트웨어를 내놓지 못할 수도 있다.


이 모든 것들이 실무다. 단지, 스프링을 익히고, jQuery를 익히는 것만이 실무는 아닌 것이다. 스프링이나 jquery를 익히는 건 코드를 만드는 역할로서의 실무를 하기 위한 활동일 뿐이다. 개발자는 코더일 뿐만 아니라 코드를 만들기 위한 설계자로서 역할도 수행하며, 이를 잘 수행하기 위해서 요구사항을 분석하는 역할도 수행해야 한다. 또한, 본인이 만든 코드에 결함이 없도록 하기 위해 테스트도 어느 정도 수행해야 한다. 게다가 작은 조직이라면 직접 배포도 해야 하고, 일정도 어느 정도는 스스로 관리해야 한다. 소프트웨어에서 실무란 이런 작업들을 모두 포함하고 있는데, 단지 실무의 범위를 코드를 만드는데 사용되는 기술만으로 한정짓는 것은 건축 현장에서 벽돌을 쌓는 걸로 본인의 작업을 한정하는 것과 크게 다르지 않다.


개발자로서 실무를 잘 하려면 단지 특정 기술을 익혀 코딩하는 것만으로는 안 된다. 이건 소프트웨어를 만드는 데 있어서 가장 기본일 뿐이다. 코딩을 하지 않으면 소프트웨어는 만들어지지 않으므로 구현 기술을 익히는 것은 가장 기본이면서 가장 중요하지만, 이것만으로는 '좋은' 소프트웨어를 만들 수 없다.


사용자가 원하는 '좋은' 소프트웨어를 만들려면, 구현 기술뿐만 아니라 요구사항 분석 실무를 익혀야 한다. 또한, 요구사항의 변화를 적은 비용으로 대처할 수 있도록 유연한 설계를 만들 수 있는 방법을 익혀야 한다. 소프트웨어 결함을 낮추는 데 도움이 되는 테스트를 만드는 방법도 익혀야 한다. 이 뿐인가,, 서비스 중단을 최소화하면서 기존 소프트웨어를 업그레이드하는 방법도 익혀야 한다. 또한, 역할에 따라서 프로젝트 일정을 관리하고, 투입 예산을 관리하는 방법도 익혀야 한다.


이런게 다 실무다. 코딩만이 실무가 아닌 것이다. 이런 실무들을 잘 하려면 구현 기술을 익히기 위해 책/온라인자료/오프라인 강좌 등을 통해서 학습하는 것 처럼, 설계를 학습하고, 좋은 코드를 만드는 방법을 학습하고, 프로젝트 관리를 학습하고, 테스트를 학습해야 한다. 벽돌 쌓는 기술로 1층짜리 벽돌집은 간신히 만들 수 있을지는 모르겠으나, 고층빌딩은 고사하고 3-4층되는 집도 만들 수 없을 것이다. 비슷하게 소프트웨어 개발자도 간단한 코드는 만들 수 있을지 모르겠지만, 규모가 조금만 커져도 소프트웨어는 점점 엉망이 되서 더 이상 발전할 수 없는 그런 결과물이 만들어질 것이다.


이제 갓 이 바닥에 발을 들여 놓은 개발자들이 실무를 단지 벽돌쌓기 기술을 향상하는 것으로만 생각하지 않았으면 좋겠고, (나름 포함한) 많은 개발자들이 다양한 영역의 실무를 익혀서 좋은 소프트웨어를 만들 수 있는 개발자로 성장할 수 있기를 바란다.

Posted by 최범균 madvirus

댓글을 달아 주세요

  1. 이루리 2013.04.05 16:57 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다.
    비록 제 현실과는 맞지 않지만 저렇게 업무를 할 수 있는 회사로 이직하는 날을 꿈꾸며

  2. 큐라 2013.04.13 15:27 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글이군요..
    역시 실무에 핵심은 지루한 회의가 아닐까요?..

  3. bluepoet 2013.04.29 15:19 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 포스팅 잘 읽었습니다.

    아래부분이 핵심 요지가 아닌가 싶네요^^

    ==============================================================================

    사용자가 원하는 '좋은' 소프트웨어를 만들려면, 구현 기술뿐만 아니라 요구사항 분석 실무를 익혀야 한다. 또한, 요구사항의 변화를 적은 비용으로 대처할 수 있도록 유연한 설계를 만들 수 있는 방법을 익혀야 한다. 소프트웨어 결함을 낮추는 데 도움이 되는 테스트를 만드는 방법도 익혀야 한다. 이 뿐인가,, 서비스 중단을 최소화하면서 기존 소프트웨어를 업그레이드하는 방법도 익혀야 한다. 또한, 역할에 따라서 프로젝트 일정을 관리하고, 투입 예산을 관리하는 방법도 익혀야 한다.

얼마전에 트윗에 올라온 '개발자라고 착각하는 무늬만 개발자?'http://techit.co.kr/6551 글을 읽었다. 이 글이 한국의 많은 개발자들에게 생각할 거리를 던져주었다고 생각한다. 이 글에 대한 답글은 아니지만 필자가 개발자인가라는 질문을 하고 싶어져서 썰을 좀 풀어보조자 한다. 참고로 필자는 월급을 받고서 일하기 시작한지는 12년째로 접어들고 있다.


현재 내가 하는 역할


필자는 현재 개발 팀장을 하고 있다. 3년전부터 개발 팀장이라는 직책을 맡고 있고, 지금 하고 있는 일은 다음과 같다.

  • 아키텍처 설계하기, 기술 선택하기
  • 프로젝트 초반에 개발환경 구축하기
  • 주요 도메인 모델 설계 또는 팀원이 설계한 것 리뷰하기
  • 프로젝트 일정 계획 세우기/체크하기
  • 외부 인력 수급 관리하기
  • 난이도 높은 모듈/기능에 대한 구현하기
  • 여러 프로젝트에 동시에 참여하기
  • 회사 외적으로는 기술 관련 글 쓰는 사람

하고 있는 일을 주요 역할로 나눠보면 다음과 같다.

  • 아키텍트
  • 선임 개발자
  • 구현자
  • 프로젝트 관리자
  • 작가

필자는 (초보이긴 하지만) 아키텍트의 역할을 하고 있다. 만들어야 할 소프트웨어의 전체 구조를 설계하고 구현 기술을 선택하고 밀고 나간다. 이 외에 성능, 보안, 확장성 등 여러 가지 구현과 직결되는 내용을 챙긴다.


주요 도메인에 대한 모델을 설계하거나 팀원이 설계한 모델을 리뷰하는 선임 개발자의 역할도 수행한다. 경우에 따라 코드 중에 마음에 안 드는 부분을 변경하도록 지시도 한다. 팀이 규모가 크다면 이 역할을 다른 사람에게 주겠지만 아직 규모가 작기 때문에 필자가 하고 있다. 물론, 필자가 다 하는 것은 아니며 일부는 중간에 위치한 팀원이 초급 팀원을 가이드하고 있다.


때로는 직접 구현에 참여하기도 한다. 난이도가 다소 높거나 일정을 단축시켜야 할 때가 그런 경우다. 물론, 아직까지 제일 잘 하는 것 중의 하나가 코딩이기도 하다. 하지만, 코딩하는 비중은 높지 않다. 1주일에 2일 이상을 코딩에 투자하지는 않는다. 코딩에 많은 시간을 투자했다간 다음에 언급할 프로젝트 관리자로서의 역할을 제대로 수행할 수 없게 된다.


필자는 근무시간의 40~60% 정도를 프로젝트 관리에 사용한다. 큰 수준에서의 일정 계획을 수립하고, 진행 상황을 확인하고, 위험 요소를 해소하는 데 많은 시간을 소요한다. 예를 들어, 필요한 인력을 수급하기 위해 외부 업체와 미팅을 하며, 매일 오전마다 미팅을 통해 진척상황을 관리한다. 아직까지 프로젝트 관리는 잘 하는 분야가 아니기에 위기의 순간에는 윗사람의 힘을 많이 빌리곤 한다.


이 외에 회사의 소프트웨어 분야의 기술쪽 팀장으로서 몇 가지 업무에 프로젝트 코디네이터나 실행자로 참여하고 있다.


그리고, 남은 한 가지 역할은 기술 관련 글을 쓰는 작가이다. 작가는 필자가 오래도록 갖고 싶은 역할로서 블로그나 책을 통해서 기술 관련 내용을 글로 남기고 있다.


포기 또는 일부러 하지 않는 것


현재의 역할을 '잘' 해야 하기 때문에, 아래의 것들은 일부 포기하고 있다.

  • 모든 신기술들을 공부하기
  • 하루 종일 코딩하기
이제 모든 신기술을 익힐 수는 없다. 요점 정도만 알고 넘어가거나 호기심에 책을 읽어보는 정도이다. 예를 들어,  최근에 읽은 책 중의 하나는 node.js와 하둡에 대한 책이었는데, 이 책들을 읽은 이유는 node.js나 하둡 자체를 익히기 위해서가 아니라 node.js나 하둡이 무엇인지 알기 위함이었다.

하루 종일 코딩을 하는 것도 하지 않는다. 그랬다간 다른 역할에 구멍이 난다. 순간적으로 프로젝트의 진척도는 올라갈 지 몰라도 여러 곳에서 구멍이 나면서 프로젝트 들이 엉망이 될 수 있다.


역할을 잘 수행하기 위해 하는 것들


아키텍트나 구현자로서의 역할을 잘 수행해내기 위해 하는 일은 지속적으로 기술 흐름을 파악하는 것이다. 최근의 빅 데이터, node.js, HTML 5 등이 각광받는 이유 등에 대해 공부한다. 일단, 큰 그림 수준에서 이해하고 필요하면 한 놈씩 골라서 본격적으로 판다.


프로젝트 관리자는 필자가 잘 하고 싶은 분야는 아니다. 프로젝트 관리 자체가 아주 재미없는 건 아니지만 필자는 구현에 참여할 때가 더 즐겁다. 하지만, 구현이 재미있다고 구현만 하면 큰 그림을 볼 수 없고, 프로젝트 관리 능력이 없다면 사실상 괜찮은 아키텍트나 선임 개발자가 될 수 없음을 알고 있기에 어느 정도의 프로젝트 관리 능력을 보유하기 위해 노력하고 있다. 프로젝트 관리와 관련된 책이나 글을 읽고 따라해 보는 것이 주된 노력이다.


필자의 오랜 목표 중의 하나는 기본기와 관련된 책을 쓴 작가가 되는 것이다. 이를 위해 설계와 관련된 내용을 지속적으로 학습하고 있고, 틈틈히 글로 배운 지식을 정리해 보고 있고 언젠가 이를 바탕으로 좋은 책을 쓸 것이다. 더불어, 입문자를 위한 책을 쓰는 것도 중요하게 생각하고 있기 때문에 JSP나 Java 언어와 관련된 책도 꾸준히 개정해 나갈 것이다.

그래서 난 개발자인가? 앞으로도 개발자일 것인가?

그럼, 이제 본론으로 돌아가 '난 개발자인가?'라는 질문에 답을 해 보자. 프로젝트 관리도 넓은 의미에서 보면 개발의 범주에 속하지만, 아키텍트까지가 개발자가 아닌가 하는 생각이 든다. 그런 의미에서 필자는 현재 절반은 개발자로서 일을 하고 있고, 나머지 절반은 관리자로서 일을 하고 있다. 물론, 사생활에서는 작가로서 반, 개발자로서 반 정도의 시간을 보내고 있다. 이런 점에서 아직은 개발자라고 불려도 손색은 없을 것 같다.


요즘 내가 하는 고민은 이 비율을 앞으로 어떻게 조정할 것인가에 대한 것이다. 올해 이 고민을 시작했고, 올 해 안에 답을 내려고 한다. 참고로 필자는 올해 36세이며, 결정에 따라 앞으로 5년 동안 무슨 일을 할 지가 결정될 것이다. 이 결정에는 여러 가지 고려할 것들이 있는데, 이는 다음과 같다.

  • 아이의 나이
  • 또 다른 수입원
  • 즐거움

필자는 가장이고, 아이가 있기도 하다. 앞으로 가정에 돈이 많이 들어갈 예정이기에, 연봉은 중요한 고려 사항이다. 한국에서 평균적으로 팀원보다 프로젝트 관리자가 연봉이 높은 점을 감안하면 고민이 더 커진다. 프로젝트 관리자나 기술쪽의 더 높은 지위(본부장, CTO 등)로 경로를 잡아서 향후 5년간 연봉을 더 높여갈 것이냐 아니면 적당한 연봉에 만족하면서 구현자로서의 즐거움을 좀 더 만끽할 것이냐? 이것이 큰 고민거리다.


한국에서 구현자로서 15년 이상의 경력을 가진 고급 개발자는 (연봉으로서) 인정해주는 곳이 별로 없기에 구현자로서 즐거움을 계속해서 누리고 싶다면 프리랜서로 경력에 비해 더 낮은 돈을 받고 계속 일을 해야 할 지도 모른다. 아니면 단가를 그나마 잘 받기 위해 외주로 일을 받아 전문적으로 구현을 해 주는 업체를 차려야 할 지도 모른다. 하지만, 필자가 일을 계속 따 올 수 있는 영업력이 있는가에 대해서는 상당한 의구심이 든다. 


프로젝트 관리자 경로를 잡든 구현자의 기간을 연장하든 둘 다 국내에서는 쉽지 않아 보인다. 필자의 역량은 구현자로서 역할을 수행할 때 더 잘 발휘되지만 40살 넘은 구현자가 존재하는 경우가 흔치 않을 뿐더러, 개발 팀에서 40이 넘은 팀원을 구현자로 두고 있는 회사가 얼마나 있을까 하는 의구심도 든다. 물론, 관리자로서 본부장/CTO 등으로 승진하는 것은 더 어려운 일이다. 필자는 구현자로서의 역할을 잘 한다고 해서 관리자로서의 역할도 잘 할거라는 보장이 없음을 알고 있고, 그런 의미에서 피터의 법칙(승진할수록 일을 못 한다는)에 어느 정도 동의한다.


내 위에 직접적으로 연결된 40대 초/중반의 선배님들 중에 구현자로서 역할을 하는 분은 정말 소수에 불과하고 대부분은 관리자로서 일을 하고 계신다. 이런 모습을 보면 내가 앞으로 얼마나 구현자로서 한국에서 버틸 수 있을까 하는 고민에 빠져든다.


필자가 하고 싶은 것은 켄트 벡이나 밥 아저씨처럼 IT의 개발자로서 계속해서 일을 하면서 기본기를 닦아 줄 수 있는 지식을 전파하는 것이다. 언젠가 실력을 더 쌓아 객체 지향과 패턴에 대한 기초 서적을 쓰고 싶고, 그러면서 개발자로서 능력에 알맞은 대우를 받으면서 일을 하고 싶다. 이게 가능하지 않다면, 본업을 바꾸고 취미로 개발을 해야 할까?


한 동안은 하고 싶은 것과 먹고 살 거리를 함께 고민하는 시간이 될 것 같다. 고민해 보자.






Posted by 최범균 madvirus

댓글을 달아 주세요

  1. Konn 2012.07.09 23:05 신고  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다. 작년쯤에 이런쪽에도 알아두는게 좋을것같아서 자바 책을 사놓고있는데 아직도 절반도 못 읽고있네요. 너무 어렵기도 하고 제가 너무 게을러서도 이겠죠. 언제나 느끼는거지만 이런 능력자분들을 보면 정말 부럽습니다.

  2. ddalki 2012.07.09 23:21 신고  댓글주소  수정/삭제  댓글쓰기

    평생하게되는 고민같습니다.

  3. seungbeomi 2012.07.09 23:45 신고  댓글주소  수정/삭제  댓글쓰기

    개발자라는 좋은(?) 직업을 가지고서도 모두들 이와같이 진로에 대한 고민을하게 되는 현실이 참 안타깝습니다.

    • 최범균 madvirus 2012.07.10 11:41 신고  댓글주소  수정/삭제

      옛날처럼 평생 직장 개념이 없고, 기술자를 부리는 사람 정도로 취급하는 사회이다 보니, 더 많은 고민을 하게 되는 것 같습니다. 앞으로 살아가기 위한 현실적인 방법을 찾아야겠지요.

  4. msbaek 2012.07.10 14:26 신고  댓글주소  수정/삭제  댓글쓰기

    고민된다. 근데 꿈이 나랑 같다. 켄트벡이나 엉클밥. 근데 나는 관리를 하고 있는 듯. 요즘은 관리도 조금이고 프리젠테이션이 더 많은 듯. 에구.

  5. 그누 2012.07.10 15:16 신고  댓글주소  수정/삭제  댓글쓰기

    개발자라면 누구나 가지고 있는 로망 아닌가요? 막상, 현실은 뒷받침이 안되어 주고요^

    이게 우리 스스로 변해야 합니다. 누군가 바꿔주길 기대하지 말고 ~ 작은것에서 부터 실천해가는 모습~

    님께서 작성해주신 역할 즉, 아키텍트, 선임 개발자, 구현자, 프로젝트 관리자, 작가
    등에 대한 정의 및 상세 액티비티 등을 정의해서~ 공유하는 계몽운동을 벌여야 합니다.

    널리 퍼뜨려야 하지요. 요샌 개발자가 스토리 보도까지 작성 책임을 돌리는 상황까지도 전개 되었다라는 애기가 나돌고 있지요 기획자는 단순히 그리러 왔을뿐이다 라고 고객님께서 편드는 세상이 왔으니 말이죠

  6. innerman 2012.07.20 23:22 신고  댓글주소  수정/삭제  댓글쓰기

    제가 조금 나이가 더 많은데요... 전 아직도 개발하고 있습니다. 또 운좋게 개발만 해도 되는 환경에서요...(회사 전사가 애자일팀으로 변경되어서...)
    저는 개발자가 관리자가 되는 것은 반대입니다. 물론 아키텍트도 개발의 범주로 보구요... 코딩과 구별을 특별히 두고 싶지는 않네요... ㅋㅋ

  7. 체리파플 2013.10.13 01:42 신고  댓글주소  수정/삭제  댓글쓰기

    고급개발자 분이 필요합니다.
    신입들은 누가 키웁니까..