적정 기술 3 . 개발자 역할 의 변화 | IT 의 중심 에서 
 적정 기술 3 . 개발자 역할 의 변화 
 새로운 영역 에서 개발자 들 의 역할 은 점점 더 넓 어 지 고 있 다 . 그래서 개발자 들 이 과거 역할 에 만 갇혀 있 어서 는 안 된다 . 사업 이 안 된다 . 
 실리콘밸리 라고 해서 선진 문명 이 고 우리 는 후진 문명 이 고 그런 것 이 아니 다 . SW 산업 은 격차 가 없 다 . 그래서 해결책 의 도입 에 기대 기 보다 자체 적 인 문제 해결 능력 의 확보 가 더 중요 하 다 . 
 전통 산업 군 에서 의 IT 
 제조업 , 유통 업 등 전통 적 산업 의 고민 은 뭐니뭐니 해도 [ 원가 절감 ] 이 다 . 이것 은 회사 의 영업 이익 과 직결 되 기 때문 이 다 . 그래서 IT 의 핵심 가치 가 [ 원가 절감 ] , [ 생산 성 강화 ] , [ 효율 향상 ] 에 있 었 다 . 이것 은 IT 의 역할 을 [ 반복 업무 의 자동 화 ] 에 한정 지 었 다 . 
 그래서 과거 에 는 검증 된 SW 패키지 를 공급 받 아 이 문제 를 해결 하 려 했 다 . 하지만 , 사업 환경 변화 가 빠른 곳 에서 는 대 규모 의 개발자 를 이용 해서 [ 보다 빠르 게 ] 업무 를 전산 화 하 는 것 이 중요 했 다 . ( 특히 통신 ) 
 그래서 과거 의 SW 공학 은 어떻게 하 면 10 년 이상 안정 되게 돌아가 게 할 것 인가 ( Tolerant ) , 어떻게 하 면 한 번 만들 어서 여기 도 쓰 고 저기 도 쓰 게 할 것 인가 ( Flexibility ) 에 집중 해 왔 다 . 그래서 크 고 복잡 한 Enterprise Architecture 를 처음 부터 염두 해 두 는 것 이 매우 중요 했 다 . IT 시스템 의 구축 비용 조 차 도 절감 해야 했 기 때문 이 다 . 
 하지만 , IT 인프라 가 발달 하 면서 사업 환경 의 변화 도 점점 더 빨라졌 다 . 그래서 이 를 따라 잡 기 위한 대 규모 프로젝트 가 끊임없이 만들 어 졌 다 . 하지만 , [ 보다 빠르 게 ] 업무 를 전산 화 하 는 것 은 [ 원가 절감 ] 이 아니 라 오히려 [ 높 은 IT 시스템 유지 비용 과 변경 비용 ] 으로 이어지 고 말 았 다 . 
 물론 , 지금 도 전통 산업 에서 [ 업무 의 전산 화 ] 는 중요 하 다 . 그런 산업 들 은 대부분 [ 기반 산업 ] 이 기 때문 에 IT 가 본연 의 상품 이 아니 기 때문 이 다 . 그래서 Enterprise System 을 만들 고 유지 보수 하 는 SW 개발 방법론 과 프로젝트 관리 방법 은 사라지 지 않 을 것 이 다 . 
 문제 는 이 분야 의 중점 사항 이 “ 안정 된 Process Function ” 들 을 만들 어 내 는데 있 다는 것 이 다 . “ Data ” 는 거래 Transaction 의 근거 로서 존재 할 뿐 이 다 . 즉 Data 를 보존 할 뿐 이용 하 지 는 않 는다 . 
 하지만 , IT 시스템 이 [ 상품 ] 이 되 는 영역 에서 는 논리 가 좀 다르 다 . 예 를 들 면 앱 서비스 는 스마트폰 을 통해서 돈 을 번다 . 즉 IT 시스템 의 핵심 이 [ 원가 절감 ] 이 아니 다 . 고객 들 에게 돈 을 받 을 수 있 는가 하 는 [ 상품성 ] 이 핵심 이 다 . 그래서 IT 의 역할 이 ‘ 돈 으로 치환 될 수 있 는 부 가 가치 를 제공 하 고 있 는가 ? ’ 하 는 [ 효과 성 ] 을 충족 시키 는데 있 다 . 
 따라서 고객 의 니즈 를 읽 고 돈 을 받 을 수 있 는 무형 의 상품 을 만들 어 내 기 위한 [ 방법 ] 이 중요 해졌 다 . 즉 , 사업 을 시작 할 때 만들 어야 하 는 [ 업무 발굴 ] 이 SW 개발 의 영역 으로 들어온 것 이 다 . 기존 의 SW 개발 방법 론 이 [ 개발 명세서 ] 를 만들 기 위해 [ 분석 ] , [ 설계 ] 부터 시작 한다면 , 이 분야 에서 는 효과 성 을 [ 시험 ] , [ 확인 ] 하 기 위한 작업 부터 시작 된다 . 
 그래서 이 분야 의 SW 공학 은 어떻게 하 면 [ 효과 적 인 상품 을 만들 수 있 는가 ] 에 집중 한다 . 그리고 , 효과 성 을 빠르 게 확인 하 기 위해 짐 을 최대한 가볍 게 한다 . 이미 공개 된 플랫 폼 과 소스 , 서비스 를 활용 한다 . 그리고 작 고 가벼운 Architecture 를 선택 한다 . 
 이 분야 는 기존 산업 과 비교 하 면 [ 비즈니스 룰 을 새로 만들 어 가 는 과정 ] 과 정확히 일치 한다 . 그런데 온라인 사업 은 이 과정 의 상당 부분 에 개발자 가 참여 해야 만 한다 . SW 개발자 의 역할 이 확대 된 것 이 다 . 그리고 , 이 역할 은 토론 , 갈등 , 분쟁 등 을 만들 어 낸다 . 그래서 협업 과 조정 , 리더 쉽 과 팔 로 워십 이 더욱 중요 하 게 되 었 다 . 참고 로 애자일 은 이 문제 를 해결 하 기 위한 선택지 중 의 하나 이 다 . 
 이 분야 의 중점 사항 은 “ 안정 된 Function Process ” 보다 “ 가치 있 는 데이터 의 축척 과 활용 ” 이 다 . 인터넷 은 주로 사용 자 의 정보 욕구 를 채워 주 거나 정보 불 균형 을 해소 시켜 주 는데 강점 이 있 기 때문 이 다 . 
 문제 는 이 분야 에 개발 방법론 * 이 라 할 만 한 것 이 없 다는 것 이 다 . 그래서 기술 부채 가 상대 적 으로 빠르 게 증가 하 다가 어느 순간 사업 의 확장 성 을 저해 하 기 시작 하 는데 이 를 해결 할 방법 이 요원 하 다 . 따라서 적절 한 시점 에 기술 부채 를 털 어 낼 수 있 도록 , 누적 속도 를 낮추 도록 설계 되 거나 개발 되 어야 하 는데 아직 정리 된 연구 가 많 지 않 다 . 사업 성공 율 도 높 지 않 고 성공 적 기술 사례 도 적 어서 그런 것 이 아닐까 싶 다 . 
 IT 시스템 이 [ 원가 절감 설비 ] 가 되 느냐 , [ 상품 ] 이 되 느냐 하 는 것 은 매우 큰 차이 다 . 전자 는 1 회 성 투자 로 끝나 고 전문가 에게 맡길 수록 유리 하 다 . 그러나 후자 는 아마추어 라도 반드시 회사 와 운명 을 같이 해야 한다 . 즉 주인 정신 이 없 으면 상품 이 만들 어 질 수 없 기 때문 이 다 . 
 개인 적 으로 전통 적 인 산업 영역 은 크 게 관심 이 없 다 . 구축 경험 이 시장 에 축적 되 었 기 때문 에 딱히 연구 할 만 한 주제 가 없 기 때문 이 다 . 많 은 분 들 이 잘 알 아서 하 고 있 고 , 앞 으로 도 잘 할 것 이 다 . 
 문제 는 국가 관점 이 다 . IT 기술 의 가장 큰 장점 은 [ 다양 한 부 가 가치 창출 능력 ] 인데 우리 나라 는 [ 인프라 형 비용 절감 산업 ] 에 머물러 있 다 . 즉 산업 자생력 이 엄청 낮 다는 것 이 다 . 자생력 을 높이 려면 시장 에 다양 한 자금 이 흘러 다니 고 , 독립 고객 층 이 형성 되 어야 하 는데 이 문제 는 꽤 어려운 숙제 다 . 
 그래서 아직 까지 는 실리콘밸리 의 성공 사례 를 연구 , 도입 하 고 있 다 . 최근 의 대표 사례 가 [ 애자일 ] 이 다 . 기존 의 폭포수 개발 방식 으로 는 인터넷 사업 에서 대응 하 기 힘들 게 되 자 도입 한 것 이 다 . 그러나 애자일 은 일 하 는 방식 에 대한 변화 ( 가치 생산 방식 ) 일 뿐 사람 의 문제 나 기술 의 문제 를 해결 해 주 지 는 않 는다 . 그래서 기술 문제 를 해결 하 기 위해 최근 주목 받 는 것 이 [ 마이크 로 서비스 아키 텍 쳐 ] 다 . 
 그런데 , [ 애자일 ] 이나 [ 마이크 로 서비스 아키 텍 쳐 ] 가 생각 해 보 면 하늘 에서 떨어진 특별 한 것 이 아니 다 . 단지 직면 한 문제 에 대해 개발자 들 이 해결책 과 진화 방향 을 스스로 고민 한 것 뿐 이 다 . 따라서 직면 한 문제 가 다르 면 해결책 도 달라지 게 된다 . 이 두 가지 사례 에 대해 우리 가 알 아야 할 것 은 이런 것 들 이 다 . 
 실리콘밸리 가 겪 고 있 는 조직 적 기술 적 문제 가 우리 보다 앞서 있 지 않 다 . 즉 , 우리 도 당장 현장 에서 겪 고 있 는 문제 이 다 . 적어도 SW 산업 분야 는 ‘ 선진국 의 기술 수준 이 10 년 이상 뒤쳐져 있 어요 . ’ 라는 멘 트 는 해당 하 지 않 는다 . 앞서 있 다 아니 다 의 개념 이 아니 라 , 다르 다고 말 하 는 것 이 맞 다 . 그래서 베끼 는 것 이 아니 라 이해 하 고 배워서 응용 을 해야 한다 . 
 이 엔트리 는 2017 년 2 월 1 일 에 subokim 님 이 IT 산업 이야기 , 적정 기술 에 게시 하 였으며 실용 기술 , 재 개발 방법 론 , 적정 기술 , MSA 태그 가 지정 되 었 습니다 . 	 짧 은 링크 
 http : / / wp . me / pV 8 GE - 1 Jp 
 많이 본 글 	 플랫 폼 이 란 	 은행 의 IT 시스템 에 대한 이해 	 다른 개발자 들 은 어떻게 살 고 있 을까 ? 	 스타트업 , 서비스 개발자 가 되 자 . 	 SI 개발 자 란 	 API 의 정의 	 풀 스택 개발자 에 대한 환상 	 Domain Knowledge - 기술 지식 	 기획 자 이야기 	 멍 부 , 멍게 , 똑 부 , 똑 게 	 누적 조 회수 	 989 , 879 Visits 
 인기 글 	 플랫 폼 이 란 	 은행 의 IT 시스템 에 대한 이해 	 다른 개발자 들 은 어떻게 살 고 있 을까 ? 	 스타트업 , 서비스 개발자 가 되 자 . 	 SI 개발 자 란 	 API 의 정의 	 풀 스택 개발자 에 대한 환상 	 Domain Knowledge - 기술 지식 	 기획 자 이야기 	 멍 부 , 멍게 , 똑 부 , 똑 게 	 누적 조 회수 	 989 , 879 Visits