구축 실적

• 

  KT - 통합 망관리 시스템 구축

  재난안전망 NMS 무선품질측정 시스템 ( WiNG ), KT BIT OSS DBT 구축, 차세대 OSS시스템 플랫폼 개발 및 구축 컨설팅을 수행하였으며 현재는 유무선 통합 NMS 구축및 관리를 하고 있습니다
  (2010 ~ 2016)

  (2010 ~ 2016) KT - 통합 망관리 시스템 구축

  

  재난안전망 NMS 무선품질측정 시스템 ( WiNG ), KT BIT OSS DBT 구축, 차세대 OSS시스템 플랫폼 개발 및 구축 컨설팅을 수행하였으며 현재는 유무선 통합 NMS 구축및 관리를 하고 있습니다
  

  닫기

• 

  SKT - 통합 망관리 시스템 구축

  SKT WiBRO NMS 구축 및 개량개선 / SKT EPS 구축 및 개량개선 과 SKT WiBRO NMS 유지보수를 수행하였습니다
  (2010 ~ 2016)

  (2010 ~ 2016) SKT - 통합 망관리 시스템 구축

  

  SKT WiBRO NMS 구축 및 개량개선 / SKT EPS 구축 및 개량개선 과 SKT WiBRO NMS 유지보수를 수행하였습니다
  

  닫기

• 

  삼성 - 통합 망관리 시스템 구축

  삼성전자 A STORE 플랫폼관리시스템 구축, 삼성전자 아마존 클라우딩 웹서비스
  OSS시스템 개발 및 개량개선 등을 수행하였으며 현재는 삼성전자 통합 OSP 유지보수를 수행하고 있습니다.
  (2010 ~ 2016)

  (2010 ~ 2016) 삼성 - 통합 망관리 시스템 구축

  

  삼성전자 A STORE 플랫폼관리시스템 구축, 삼성전자 아마존 클라우딩 웹서비스
  OSS시스템 개발 및 개량개선 등을 수행하였으며 현재는 삼성전자 통합 OSP 유지보수를 수행하고 있습니다.
  

  닫기

• 

  KT – 영업관리 시스템 구축

  ICIS(고객관리&빌링시스탬) 개량개선, 기업 영업기회 관리시스템 개량 개선, kt BIT BSS 구축 LE프로젝트 , CRM 시스템 기능 개선 , kt 홈페이지 계열 PPAS 전환 등을 수행하였으며 현재는 KT차세대 및 Loyalty 운영, 확산 , KT HOME PAGE 운영 사업에 참여하고 있습니다
  (2010 ~ 2016)

  (2010 ~ 2016) KT – 영업관리 시스템 구축

  

  ICIS(고객관리&빌링시스탬) 개량개선, 기업 영업기회 관리시스템 개량 개선, kt BIT BSS 구축 LE프로젝트 , CRM 시스템 기능 개선 , kt 홈페이지 계열 PPAS 전환 등을 수행하였으며 현재는 KT차세대 및 Loyalty 운영, 확산 , KT HOME PAGE 운영 사업에 참여하고 있습니다
  

  닫기

• 

  삼성 – 영업관리 시스템 구축

  삼성닷컴 홈페이지 기능개선, 삼성전자 아마존 클라우딩 웹서비스, 삼성물산 건설 통합 견적 시스템 개발, 삼성물산 견적시스템 VOC개선 및 M&E 개산 견적 시스템 개발 사업에 참여하였습니다
  (2010 ~ 2016)

  (2010 ~ 2016) 삼성 – 영업관리 시스템 구축

  

  삼성닷컴 홈페이지 기능개선, 삼성전자 아마존 클라우딩 웹서비스, 삼성물산 건설 통합 견적 시스템 개발, 삼성물산 견적시스템 VOC개선 및 M&E 개산 견적 시스템 개발 사업에 참여하였습니다
  

  닫기

• 

  시스템 개발 원칙 1조 : 고객 너머 고객의 사용자를 생각해야 한다.

  “어떠한 경우에도 사용자의 잘못은 없다(있을 수 없다).”
  “사용상에 문제가 발생했다면 그것은 무조건 100% 개발자 잘못이다. 왜냐하면 개발자는 시스템을 개발할 때, 발생 가능한 모든 경우를 고려 해야 하니까(해야 하는 책임이 있으니까).”
  
  
  H공사는 신분증 없이 비행기에 탑승할 수 있는 생체정보 인증 기술을 도입하여 신원 확인을 간소화하고 있었습니다. 이 시스템은 지문과 손바닥 정맥을 사전 등록한 후, 생체인식 전용 게이트를 통해 신분증 검사 없이 신속하게 통과할 수 있도록 설계되었습니다.
  
  특히, H공사는 전 세계 최초로 '손바닥 정맥' 인식 기술을 도입하여 주목을 받았으며, 이 기술은 A사로부터 제공받았다고 했습니다. 하지만 A사가 '전 세계 최초 도입'이라는 타이틀을 H공사에 안겨주었다고 자랑함에도 불구하고 그 시스템은 실제 사용자를 짜증나게 하는 불편 유발 시스템이었습니다. 아래는 그 시스템 사용 경험 이야기입니다
  
  2021년 9월 30일, 김포공항에서 울산행 비행기 탑승 수속 중이었습니다. 앞으로도 비행기로 울산 갈 일이 많을 것 같아 간편 수속을 위해 생체정보를 사전 등록하기로 했습니다.
  
  생체정보 사전등록대의 키오스크에서 사전 등록 작업을 시도 했는데, 신분증 스캔 작업 시 복사기와 같은 스캔 판넬에 신분증을 어느 위치에 두어야 할지 정확한 위치에 대한 안내가 없었고 제대로 된 위치에 두지 못해 인증 실패 메시지만 받았습니다. 여러 번 시도 끝에 이 단계를 겨우 통과했습니다.
  
  그 다음 손바닥 정맥 인식 시도를 할 때 언제(몇 초간 있다가) 손을 떼어야 하는지 안내가 없어, 결국 등록 실패할 수 밖에 없었습니다. 또 다시 등록자 인적 사항 입력, 신분증 스캔, 손바닥 정맥인식, 등록 실패 이러한 과정을 10번 넘게 반복했습니다..
  
  이러한 등록실패가 반복되면서 키오스크 뒤로 대기 줄은 점점 길어졌고, 기다리는 사람들의 눈초리는 따가워졌기에. “시스템을 어떤 xx가 이따위로 개떡같이 개발 했어! 정말 형편없는 xx네”라고 욕설하면서 사전 등록을 포기하고 나왔습니다.
  
  위의 사례와 같이 어떤 시스템일지라도 입력 작업을 두 번 이상 하게 하거나, 사용자의 실수를 예방하지 않는 시스템은 고객의 인수 절차를 통과 했을지라도 불량 시스템입니다. 그 시스템 개발자도 뛰어난 개발자라고 할 수 없지요.
  
  이처럼 사용자에게 쉽고 편리하게 기능해야 할 시스템을 개발자 자신이 편(?) 하려고 대충 대충 개발한 까닭에 오히려 짜증 나게 만드는 상황은 부지기수로 많습니다. 사용자는 그 시스템을 사용할 때마다 쓰레기 개발자라고 욕하게 되겠죠.
  
  해서, 우리는 시스템을 발주한 고객이 아니라 고객 너머 고객의 고객(사용자)을 만족 시킬 수 있도록 시스템을 개발해야 합니다.

  시스템 개발 원칙 1조 : 고객 너머 고객의 사용자를 생각해야 한다.

  

  “어떠한 경우에도 사용자의 잘못은 없다(있을 수 없다).”
  “사용상에 문제가 발생했다면 그것은 무조건 100% 개발자 잘못이다. 왜냐하면 개발자는 시스템을 개발할 때, 발생 가능한 모든 경우를 고려 해야 하니까(해야 하는 책임이 있으니까).”
  
  
  H공사는 신분증 없이 비행기에 탑승할 수 있는 생체정보 인증 기술을 도입하여 신원 확인을 간소화하고 있었습니다. 이 시스템은 지문과 손바닥 정맥을 사전 등록한 후, 생체인식 전용 게이트를 통해 신분증 검사 없이 신속하게 통과할 수 있도록 설계되었습니다.
  
  특히, H공사는 전 세계 최초로 '손바닥 정맥' 인식 기술을 도입하여 주목을 받았으며, 이 기술은 A사로부터 제공받았다고 했습니다. 하지만 A사가 '전 세계 최초 도입'이라는 타이틀을 H공사에 안겨주었다고 자랑함에도 불구하고 그 시스템은 실제 사용자를 짜증나게 하는 불편 유발 시스템이었습니다. 아래는 그 시스템 사용 경험 이야기입니다
  
  2021년 9월 30일, 김포공항에서 울산행 비행기 탑승 수속 중이었습니다. 앞으로도 비행기로 울산 갈 일이 많을 것 같아 간편 수속을 위해 생체정보를 사전 등록하기로 했습니다.
  
  생체정보 사전등록대의 키오스크에서 사전 등록 작업을 시도 했는데, 신분증 스캔 작업 시 복사기와 같은 스캔 판넬에 신분증을 어느 위치에 두어야 할지 정확한 위치에 대한 안내가 없었고 제대로 된 위치에 두지 못해 인증 실패 메시지만 받았습니다. 여러 번 시도 끝에 이 단계를 겨우 통과했습니다.
  
  그 다음 손바닥 정맥 인식 시도를 할 때 언제(몇 초간 있다가) 손을 떼어야 하는지 안내가 없어, 결국 등록 실패할 수 밖에 없었습니다. 또 다시 등록자 인적 사항 입력, 신분증 스캔, 손바닥 정맥인식, 등록 실패 이러한 과정을 10번 넘게 반복했습니다..
  
  이러한 등록실패가 반복되면서 키오스크 뒤로 대기 줄은 점점 길어졌고, 기다리는 사람들의 눈초리는 따가워졌기에. “시스템을 어떤 xx가 이따위로 개떡같이 개발 했어! 정말 형편없는 xx네”라고 욕설하면서 사전 등록을 포기하고 나왔습니다.
  
  위의 사례와 같이 어떤 시스템일지라도 입력 작업을 두 번 이상 하게 하거나, 사용자의 실수를 예방하지 않는 시스템은 고객의 인수 절차를 통과 했을지라도 불량 시스템입니다. 그 시스템 개발자도 뛰어난 개발자라고 할 수 없지요.
  
  이처럼 사용자에게 쉽고 편리하게 기능해야 할 시스템을 개발자 자신이 편(?) 하려고 대충 대충 개발한 까닭에 오히려 짜증 나게 만드는 상황은 부지기수로 많습니다. 사용자는 그 시스템을 사용할 때마다 쓰레기 개발자라고 욕하게 되겠죠.
  
  해서, 우리는 시스템을 발주한 고객이 아니라 고객 너머 고객의 고객(사용자)을 만족 시킬 수 있도록 시스템을 개발해야 합니다.

  닫기

• 

  시스템 개발 원칙 2조 : 지속적인 개발 생산성 개선으로 고객에게 가치 제공

  * B 개발팀과 Creta 솔루션 개발 이야기
  
  1. 문제 상황
  
  초기 B 개발팀은 웹 개발자 1명, C++ 개발자 1명, 모바일 개발자 2명으로 구성되어 있었으나, 기술적 고립과 인력의 비효율적인 배치로 인해 생산성이 높지 않았습니다. 웹 개발자는 개발할 업무량이 1명 정도만 필요했고, 모바일 개발자들은 역량 부족으로 C++ 개발자를 지원할 수 없었습니다. 결과적으로 C++ 개발자는 과중한 업무로 야근과 주말 근무를 반복해야 했습니다. 이러한 상황은 결국 인력의 불균형과 낭비를 초래했습니다.
  B 개발팀은 새로운 제품을 신속하게 프로토타이핑하고 실험해야 하는 팀이었으나, C++ 기반의 UBC 프레임워크는 빠른 실험을 지원하지 못했습니다.
  
  초기 Creta 팀에는 단 한 명의 신참 백엔드(BackEnd) 엔지니어만 있었고, 이는 프레임워크 개발의 병목 현상을 초래했습니다. 클라우드와 스탠드얼론 백엔드가 모두 요구되는 시장의 필요를 충족하기에는 역부족인 상황이었습니다.
  
  
  2. 개선책
  
  B 개발팀에서는 이러한 문제를 다음과 같이 개선하여 개발 생산성을 높이고 유지보수 비용을 절감할 수 있도록 해주는 프레임워크를 개발하였습니다.
  
  2.1. Cross-Platform 언어 통일
  FrontEnd 개발 언어를 Flutter로 통일하여 웹, Windows Client, Android, 모바일 클라이언트를 모두 지원하도록 하였습니다. 이로 인해 웹 엔지니어, 모바일 엔지니어, C++ 엔지니어가 서로 협력할 수 있는 환경이 조성되었습니다. 특정 기술 분야에 대한 인력 필요가 줄어들었고, 신규 업무 발생 시 여유 시간이 있는 엔지니어가 이를 맡을 수 있게 되어 팀 인력 구성의 유연성이 향상되었습니다. 이는 향후 유지보수 단계에서 인원 축소 등의 상황이 발생해도 충격을 완화할 수 있을 것입니다.
  
  2.2. BaaS(Backend as a Service) 도입
  Firebase와 Appwrite 두 가지 BaaS 시스템을 도입하여 BackEnd 문제를 해결하였습니다. BaaS는 BackEnd 기술에 대한 지식이 없어도 개발이 가능하게 하여 모든 엔지니어가 Full-Stack 엔지니어로 성장할 수 있는 기회를 제공합니다. Appwrite는 스탠드얼론 서버에 설치할 수 있어 유지보수의 편리함을 제공하며, 사업적으로도 시장 영역을 확장할 수 있는 가능성을 열어줍니다.
  
  이렇게 지속적으로 개발 생산성을 개선함으로써, 이제 환경 변화에 대응하고 시장의 요구에 신속하고 유연하게 대응할 수 있게 되어, 고객들에게 더 큰 가치를 제공할 수 있는 기반을 마련하게 되었습니다.

  시스템 개발 원칙 2조 : 지속적인 개발 생산성 개선으로 고객에게 가치 제공

  

  * B 개발팀과 Creta 솔루션 개발 이야기
  
  1. 문제 상황
  
  초기 B 개발팀은 웹 개발자 1명, C++ 개발자 1명, 모바일 개발자 2명으로 구성되어 있었으나, 기술적 고립과 인력의 비효율적인 배치로 인해 생산성이 높지 않았습니다. 웹 개발자는 개발할 업무량이 1명 정도만 필요했고, 모바일 개발자들은 역량 부족으로 C++ 개발자를 지원할 수 없었습니다. 결과적으로 C++ 개발자는 과중한 업무로 야근과 주말 근무를 반복해야 했습니다. 이러한 상황은 결국 인력의 불균형과 낭비를 초래했습니다.
  B 개발팀은 새로운 제품을 신속하게 프로토타이핑하고 실험해야 하는 팀이었으나, C++ 기반의 UBC 프레임워크는 빠른 실험을 지원하지 못했습니다.
  
  초기 Creta 팀에는 단 한 명의 신참 백엔드(BackEnd) 엔지니어만 있었고, 이는 프레임워크 개발의 병목 현상을 초래했습니다. 클라우드와 스탠드얼론 백엔드가 모두 요구되는 시장의 필요를 충족하기에는 역부족인 상황이었습니다.
  
  
  2. 개선책
  
  B 개발팀에서는 이러한 문제를 다음과 같이 개선하여 개발 생산성을 높이고 유지보수 비용을 절감할 수 있도록 해주는 프레임워크를 개발하였습니다.
  
  2.1. Cross-Platform 언어 통일
  FrontEnd 개발 언어를 Flutter로 통일하여 웹, Windows Client, Android, 모바일 클라이언트를 모두 지원하도록 하였습니다. 이로 인해 웹 엔지니어, 모바일 엔지니어, C++ 엔지니어가 서로 협력할 수 있는 환경이 조성되었습니다. 특정 기술 분야에 대한 인력 필요가 줄어들었고, 신규 업무 발생 시 여유 시간이 있는 엔지니어가 이를 맡을 수 있게 되어 팀 인력 구성의 유연성이 향상되었습니다. 이는 향후 유지보수 단계에서 인원 축소 등의 상황이 발생해도 충격을 완화할 수 있을 것입니다.
  
  2.2. BaaS(Backend as a Service) 도입
  Firebase와 Appwrite 두 가지 BaaS 시스템을 도입하여 BackEnd 문제를 해결하였습니다. BaaS는 BackEnd 기술에 대한 지식이 없어도 개발이 가능하게 하여 모든 엔지니어가 Full-Stack 엔지니어로 성장할 수 있는 기회를 제공합니다. Appwrite는 스탠드얼론 서버에 설치할 수 있어 유지보수의 편리함을 제공하며, 사업적으로도 시장 영역을 확장할 수 있는 가능성을 열어줍니다.
  
  이렇게 지속적으로 개발 생산성을 개선함으로써, 이제 환경 변화에 대응하고 시장의 요구에 신속하고 유연하게 대응할 수 있게 되어, 고객들에게 더 큰 가치를 제공할 수 있는 기반을 마련하게 되었습니다.

  닫기

• 

  시스템 개발 원칙 3조 : 성의를 다하여 작업 수행, 겸손한 자세 견지

  1. 맡은 바 책임을 다하고, 항상 최선을 다하여 업무를 수행한다.
  
  애자일 스크럼 방법의 회고 회의에서 Norman Kerth는 다음과 같은 기본 지침을 제시했습니다.
  
  문제가 발견되었을 때, "개발팀의 모든 구성원들은 그 당시 그들이 알고 있는 것, 기술과 능력, 사용할 수 있는 자원과 상황을 활용하여 최선의 노력을 했다"는 점을 인정하고 믿어야 합니다. 이는 문제가 발생하더라도 ‘개발팀은 최선을 다했다’는 인식을 바탕으로 합니다.
  
  이러한 태도는 프로로서의 자세이며, 비즈니스 관계에서 상대방을 존중하는 기본 예의입니다. 이런 마음가짐 없이는 비즈니스 거래가 성립할 수 없습니다.
  
  우리는 자신 있게 이렇게 말할 수 있어야 합니다. “물론 프로젝트와 관련하여 더 나은 멤버나 도구, 방법, 시기, 대안 등이 있었겠지만, 결코 의도적으로 그러한 것들을 배제하지 않았습니다. 우리 개발팀은 주어진 여건에서 항상 최선을 다해 지금의 결과를 만들어냈습니다.”
  
  
  
  2. 자신의 역량과 한계를 인정하고, 지속적으로 학습하고 성장한다. 그리고 타인의 의견에 대해 겸손하게 존중의 자세를 견지하며 경청한다.
  
  자신의 역량과 한계를 인정하고 지속적으로 학습하고 성장하는 자세가 필요합니다. 또한 다른 사람의 의견을 겸손하게 존중하고 귀 기울여 들어야 합니다. 인간은 완벽할 수 없고 언제나 실수할 수 있습니다. 소프트웨어는 단순 반복 작업을 자동화해 큰 이점을 줄 수 있지만, 완벽하지 않은 소프트웨어는 예상치 못한 피해를 낳을 수 있습니다. 아폴로 1호, 챌린저호, 컬럼비아호의 비극은 사소한 실수나 오류에서 비롯되었습니다. 소프트웨어 개발 역시 본질적으로 큰 위험을 안고 있습니다.
  
  따라서 개발자는 겸손하고 열린 태도를 유지해야 합니다. “다 했어! 완벽해!”라는 말은 결코 해서는 안 되는 말입니다. Apollo 13 승무원을 집으로 데려온 유명한 NASA 비행 책임자 Gene Kranz는 아폴로 1호 사고 후에 다음과 같이 말했습니다.
  
  “오늘부터 우주비행 관제센터는 ‘강인함 Tough ‘ 과 ‘적합함 Competent ‘ 을 신조로 삼을 것입니다.
  ‘강인함’은 우리가 하는 일이나 하지 않은 일에 대해 영원히 책임을 진다(치열함)는 뜻입니다.
  우리는 다시는 우리의 책임을 타협하지 않을 것입니다. ‘적합함’은 이는 우리가 어떤 것도 당연하게 여기지 않을 것임 (엄격함)을 의미합니다. 우리는 결코 우리의 지식과 기술에서 부족함이 발견되도록 하지 않을 것입니다. 임무통제센터는 완벽해야 할 것입니다.”
  
  이런 치열하고 엄격한 마음가짐은 ‘다 했다. 문제 없다’라는 교만함을 허용하지 않고, '최선을 다했지만 뭔가 놓친 게 있을 수 있다’는 겸손한 태도를 유지하게 합니다.
  
  이러한 자세는 개발팀이 더 큰 신뢰를 쌓고 지속적으로 성장할 수 있는 기반이 됩니다.
  
  
  
  3. 아폴로 1호 사고와 교훈
  
  아폴로 1호(Apollo 1)는 AS-204로도 알려져 있으며, 1967년 2월 21일 발사 예정이었습니다.
  그러나 1967년 1월 27일 지상 시험 중 화재가 발생해 승무원 3명 모두가 목숨을 잃는 비극적인 사건이 일어났습니다. 이 사고로 인해 NASA의 안전 기준과 조직 문화에 큰 변화가 일어났습니다.
  
  사고 당시 승무원들은 좌석에 앉아 훈련 중이었고, 사령선 내부는 100% 순수 산소로 가득 차 있었습니다. 이러한 상황에서는 알루미늄이 자연 발화할 수 있었고, 결국 화재가 발생했습니다. 승무원들은 탈출할 수 없었고, 안타깝게도 15초 만에 사망한 것으로 추정됩니다.
  
  사고의 원인은 전기 배선 문제로 밝혀졌습니다. 환경 제어 장치에 연결된 구리 전선이 마모되어 불꽃이 튀었고, 이는 가압된 산소와 만나 순식간에 화재로 번졌습니다. 사고 조사 후, NASA는 여러 가지 개선 조치를 취했습니다. 선내 기압을 조정하고, 해치 구조를 바꾸며, 가연성 재료를 불연성으로 교체하는 등의 조치가 이루어졌습니다.
  
  사고의 경과를 설명하면서 진 크랜츠 NASA 제2대 수석비행책임자는 이 사건의 원인이 "우리" 자신에게 있다는 점을 강조했습니다. 그는 준비 부족과 장비의 불완전함을 지적하며, 모든 팀원이 문제를 터놓고 논의하고 경계할 필요성을 깨달아야 한다고 주장했습니다.
  
  그는 먼저 아폴로 계획에 중대한 문제가 발생했다는 사실을 인정하며 얘기를 시작했습니다. 그는 다들 마감 시한을 멈추는 데만 열중하느라 눈에 보이는 결함을 무시했다고 생각했습니다. 또한 앞으로 우주비행 관제센터는 '강인한'과 '적합한'이라는 두 단어로 유명해질 것이라고 선언했습니다. 그가 말한 '강인함'은 사람들이 자신의 행동에 큰 책임감을 느끼면서 자신이 한 일이나 하지 못한 일을 전적으로 책임진다는 뜻입니다. '적합함'은 지식과 기술이 절대 부족하지 않도록 애쓰면서 배움을 멈추지 않겠다는 뜻입니다. 크랜츠는 다들 자기 칠판에 '강인함'과 '적합함'이라는 단어를 적으라고 촉구했습니다. 그러고는 이 두 단어가 세 우주 비행사의 희생을 끊임없이 상기시키고 다시는 같은 비극이 발생하지 않도록 하는 데 도움이 될 것이라는 말로 얘기를 끝맺었습니다.
  
  아폴로 1호 화재 사고는 걱정과 관심사를 팀원에게 털어놓고 공유해야 한다는 교훈을 주었습니다. 실패를 감추고 잠재적인 문제를 무시하려는 생각은 이제 사라졌습니다. 실수를 인정하고 이를 학습과 성장의 기회로 여기자는 발상이 힘을 얻었습니다. 한 비행관제사는 나중에 이 상황이 ‘카드 앞면이 보이게 펼쳐놓고 포커 게임을 하는 것과 비슷했다’고 설명했습니다. 따라서 허세를 부릴 수도 없고 결함과 실수도 모두 인정해야 했습니다.
  
  이 연설은 그의 가치관에 대한 표현과 미래 우주 비행에 대한 훈계이며 NASA에 대한 그의 유산입니다.
  
  곧 이어 놀라운 변화가 일어났습니다. 훗날 많은 논객들은 아폴로 1호의 비극적인 화재 사건을 통해 따끔한 교훈을 얻지 못했다면 닐 암스트롱이 달에 발을 딛지 못했을 것이라고 주장했습니다.
  
  아폴로 1호 화재 사고는 성실한 업무 수행과 겸손한 자세의 중요성을 잘 보여줍니다. 문제를 숨기지 않고 공유하는 문화가 형성되면서, NASA는 과거의 비극을 되풀이하지 않기 위해 끊임없이 노력하고 있습니다. 이러한 교훈은 오늘날에도 여전히 유효하며, 안전한 우주 비행을 위한 핵심 가치로 자리 잡았습니다.

  시스템 개발 원칙 3조 : 성의를 다하여 작업 수행, 겸손한 자세 견지

  

  1. 맡은 바 책임을 다하고, 항상 최선을 다하여 업무를 수행한다.
  
  애자일 스크럼 방법의 회고 회의에서 Norman Kerth는 다음과 같은 기본 지침을 제시했습니다.
  
  문제가 발견되었을 때, "개발팀의 모든 구성원들은 그 당시 그들이 알고 있는 것, 기술과 능력, 사용할 수 있는 자원과 상황을 활용하여 최선의 노력을 했다"는 점을 인정하고 믿어야 합니다. 이는 문제가 발생하더라도 ‘개발팀은 최선을 다했다’는 인식을 바탕으로 합니다.
  
  이러한 태도는 프로로서의 자세이며, 비즈니스 관계에서 상대방을 존중하는 기본 예의입니다. 이런 마음가짐 없이는 비즈니스 거래가 성립할 수 없습니다.
  
  우리는 자신 있게 이렇게 말할 수 있어야 합니다. “물론 프로젝트와 관련하여 더 나은 멤버나 도구, 방법, 시기, 대안 등이 있었겠지만, 결코 의도적으로 그러한 것들을 배제하지 않았습니다. 우리 개발팀은 주어진 여건에서 항상 최선을 다해 지금의 결과를 만들어냈습니다.”
  
  
  
  2. 자신의 역량과 한계를 인정하고, 지속적으로 학습하고 성장한다. 그리고 타인의 의견에 대해 겸손하게 존중의 자세를 견지하며 경청한다.
  
  자신의 역량과 한계를 인정하고 지속적으로 학습하고 성장하는 자세가 필요합니다. 또한 다른 사람의 의견을 겸손하게 존중하고 귀 기울여 들어야 합니다. 인간은 완벽할 수 없고 언제나 실수할 수 있습니다. 소프트웨어는 단순 반복 작업을 자동화해 큰 이점을 줄 수 있지만, 완벽하지 않은 소프트웨어는 예상치 못한 피해를 낳을 수 있습니다. 아폴로 1호, 챌린저호, 컬럼비아호의 비극은 사소한 실수나 오류에서 비롯되었습니다. 소프트웨어 개발 역시 본질적으로 큰 위험을 안고 있습니다.
  
  따라서 개발자는 겸손하고 열린 태도를 유지해야 합니다. “다 했어! 완벽해!”라는 말은 결코 해서는 안 되는 말입니다. Apollo 13 승무원을 집으로 데려온 유명한 NASA 비행 책임자 Gene Kranz는 아폴로 1호 사고 후에 다음과 같이 말했습니다.
  
  “오늘부터 우주비행 관제센터는 ‘강인함 Tough ‘ 과 ‘적합함 Competent ‘ 을 신조로 삼을 것입니다.
  ‘강인함’은 우리가 하는 일이나 하지 않은 일에 대해 영원히 책임을 진다(치열함)는 뜻입니다.
  우리는 다시는 우리의 책임을 타협하지 않을 것입니다. ‘적합함’은 이는 우리가 어떤 것도 당연하게 여기지 않을 것임 (엄격함)을 의미합니다. 우리는 결코 우리의 지식과 기술에서 부족함이 발견되도록 하지 않을 것입니다. 임무통제센터는 완벽해야 할 것입니다.”
  
  이런 치열하고 엄격한 마음가짐은 ‘다 했다. 문제 없다’라는 교만함을 허용하지 않고, '최선을 다했지만 뭔가 놓친 게 있을 수 있다’는 겸손한 태도를 유지하게 합니다.
  
  이러한 자세는 개발팀이 더 큰 신뢰를 쌓고 지속적으로 성장할 수 있는 기반이 됩니다.
  
  
  
  3. 아폴로 1호 사고와 교훈
  
  아폴로 1호(Apollo 1)는 AS-204로도 알려져 있으며, 1967년 2월 21일 발사 예정이었습니다.
  그러나 1967년 1월 27일 지상 시험 중 화재가 발생해 승무원 3명 모두가 목숨을 잃는 비극적인 사건이 일어났습니다. 이 사고로 인해 NASA의 안전 기준과 조직 문화에 큰 변화가 일어났습니다.
  
  사고 당시 승무원들은 좌석에 앉아 훈련 중이었고, 사령선 내부는 100% 순수 산소로 가득 차 있었습니다. 이러한 상황에서는 알루미늄이 자연 발화할 수 있었고, 결국 화재가 발생했습니다. 승무원들은 탈출할 수 없었고, 안타깝게도 15초 만에 사망한 것으로 추정됩니다.
  
  사고의 원인은 전기 배선 문제로 밝혀졌습니다. 환경 제어 장치에 연결된 구리 전선이 마모되어 불꽃이 튀었고, 이는 가압된 산소와 만나 순식간에 화재로 번졌습니다. 사고 조사 후, NASA는 여러 가지 개선 조치를 취했습니다. 선내 기압을 조정하고, 해치 구조를 바꾸며, 가연성 재료를 불연성으로 교체하는 등의 조치가 이루어졌습니다.
  
  사고의 경과를 설명하면서 진 크랜츠 NASA 제2대 수석비행책임자는 이 사건의 원인이 "우리" 자신에게 있다는 점을 강조했습니다. 그는 준비 부족과 장비의 불완전함을 지적하며, 모든 팀원이 문제를 터놓고 논의하고 경계할 필요성을 깨달아야 한다고 주장했습니다.
  
  그는 먼저 아폴로 계획에 중대한 문제가 발생했다는 사실을 인정하며 얘기를 시작했습니다. 그는 다들 마감 시한을 멈추는 데만 열중하느라 눈에 보이는 결함을 무시했다고 생각했습니다. 또한 앞으로 우주비행 관제센터는 '강인한'과 '적합한'이라는 두 단어로 유명해질 것이라고 선언했습니다. 그가 말한 '강인함'은 사람들이 자신의 행동에 큰 책임감을 느끼면서 자신이 한 일이나 하지 못한 일을 전적으로 책임진다는 뜻입니다. '적합함'은 지식과 기술이 절대 부족하지 않도록 애쓰면서 배움을 멈추지 않겠다는 뜻입니다. 크랜츠는 다들 자기 칠판에 '강인함'과 '적합함'이라는 단어를 적으라고 촉구했습니다. 그러고는 이 두 단어가 세 우주 비행사의 희생을 끊임없이 상기시키고 다시는 같은 비극이 발생하지 않도록 하는 데 도움이 될 것이라는 말로 얘기를 끝맺었습니다.
  
  아폴로 1호 화재 사고는 걱정과 관심사를 팀원에게 털어놓고 공유해야 한다는 교훈을 주었습니다. 실패를 감추고 잠재적인 문제를 무시하려는 생각은 이제 사라졌습니다. 실수를 인정하고 이를 학습과 성장의 기회로 여기자는 발상이 힘을 얻었습니다. 한 비행관제사는 나중에 이 상황이 ‘카드 앞면이 보이게 펼쳐놓고 포커 게임을 하는 것과 비슷했다’고 설명했습니다. 따라서 허세를 부릴 수도 없고 결함과 실수도 모두 인정해야 했습니다.
  
  이 연설은 그의 가치관에 대한 표현과 미래 우주 비행에 대한 훈계이며 NASA에 대한 그의 유산입니다.
  
  곧 이어 놀라운 변화가 일어났습니다. 훗날 많은 논객들은 아폴로 1호의 비극적인 화재 사건을 통해 따끔한 교훈을 얻지 못했다면 닐 암스트롱이 달에 발을 딛지 못했을 것이라고 주장했습니다.
  
  아폴로 1호 화재 사고는 성실한 업무 수행과 겸손한 자세의 중요성을 잘 보여줍니다. 문제를 숨기지 않고 공유하는 문화가 형성되면서, NASA는 과거의 비극을 되풀이하지 않기 위해 끊임없이 노력하고 있습니다. 이러한 교훈은 오늘날에도 여전히 유효하며, 안전한 우주 비행을 위한 핵심 가치로 자리 잡았습니다.

  닫기

• 

  시스템 개발원칙 4조 : 민첩한 시스템 개발

  민첩한 시스템 개발(Agile Development)은 소프트웨어 개발 과정에서 반복적이고 점진적인 접근 방식을 통해 제품을 개선하고, 고객의 피드백을 신속하게 반영하는 것을 목표로 합니다. 이를 통해 개발 팀은 빠르고 유연하게 프로젝트를 진행할 수 있습니다.
  
  1. 반복적 개발
  소프트웨어는 한 번에 완성되지 않습니다. 여러 차례에 걸쳐 점진적으로 개선해 나가며, 개발 과정 중에도 결과물을 확인하고 필요한 수정사항을 즉시 반영할 수 있습니다.
  
  2. 고객 중심
  개발 과정에서는 고객의 요구사항과 피드백을 지속적으로 반영하여, 고객이 원하는 방향으로 제품을 개발합니다. 이를 통해 최종 제품의 품질을 높일 수 있습니다.
  
  3. 적응력
  변화하는 요구사항에 빠르게 대응하여, 유연하게 개발 방향을 조정할 수 있는 능력을 갖추고 있습니다. 이는 시장의 변화에 민첩하게 반응할 수 있도록 합니다.
  
  
  
  * Agile 개발 방법론 적용 예시
  
  온라인 쇼핑몰 개발 시, 모든 기능을 한 번에 완벽히 구현하기보다는 핵심 기능인 제품 검색과 장바구니 기능을 우선 개발하여 배포합니다. 이후 고객의 피드백을 반영하여 결제 기능, 리뷰 기능 등을 점진적으로 추가해 나가는 방식입니다.
  
  
  
  * 민첩한 시스템 개발 성공 사례 : Spotify
  
  Spotify는 음악 스트리밍 서비스로, 민첩한 개발 방법론을 통해 빠르게 성장할 수 있었습니다. Spotify는 작은 팀 단위로 구성되어 각 팀이 특정 기능이나 모듈에 집중할 수 있도록 하여, 새로운 기능을 신속하게 개발하고 사용자의 피드백을 지속적으로 반영했습니다.
  
  주요 성공 요소
  - 작은 팀으로의 분할과 자율성 부여
  - 지속적인 사용자 피드백 반영
  - 점진적이고 반복적인 개발
  
  
  
  * 민첩한 시스템 개발 실패 사례 : Healthcare.gov
  
  2013년 출시된 미국의 Healthcare.gov 웹사이트는 오바마케어(ACA)를 위한 온라인 건강 보험 사이트입니다. 초기 출시에서 대규모 실패를 겪었으며, 그 주된 이유는 민첩한 개발 방법론을 적용하지 않았기 때문입니다. 전통적인 폭포수 모델을 사용하여 모든 기능을 한 번에 구현하려 했습니다.
  
  주요 실패 요인
  - 한 번에 모든 기능 구현 시도
  - 사용자 피드백 반영 부족
  - 유연하지 못한 개발 과정
  
  민첩한 시스템 개발은 성공적인 소프트웨어 개발을 위한 중요한 접근 방식이며, 이를 통해 변화하는 시장 환경에 효과적으로 대응할 수 있습니다.
  
  
  
  * 美 FBI ‘애자일 기법 유효’ 입증 사례
  
  FBI는 2013년 6월 20일 애자일(Agile) 소프트웨어 개발 방법의 유효성을 입증하는 사례를 발표하였습니다. 그러나 이 발표는 큰 반향을 일으키지 못했습니다. 10여 년간 10억 달러에 달하는 세금을 쏟아 부은 프로젝트가 실패로 돌아간 점을 감안하면 아이러니한 일이었습니다. 소통 부족과 경쟁력 결여, 감독 부실 등이 원인이 되어 세금이 낭비되었지만, 애자일 개발을 도입한 CIO의 노력 덕분에 프로젝트는 다시 제 궤도에 올랐습니다.
  
  FBI의 사례는 애자일 개발이 실제로 효과적이라는 중요한 교훈을 시사합니다. 완벽하진 않지만, 많은 정부 공무원들과 계약업체들이 여전히 어려움을 겪고 있음에도 불구하고 성과가 나타나고 있습니다. 애자일 개발은 정부가 대형 IT 프로젝트를 제때, 주어진 예산 내에 구현하도록 돕고 있으며, 원하는 목표를 달성하는 데 기여하고 있습니다.
  
  문제의 FBI 프로젝트는 '센티넬(Sentinel)'로, 에드가 후버 시대부터 이어져 온 종이 파일 시스템을 대체하기 위한 것이었습니다. 9/11 사건을 계기로 사건 관리 시스템의 필요성이 부각되었고, FBI는 가상 사건 파일(Virtual Case File) 프로젝트에 1억 7,000만 달러의 예산을 배정했습니다. 그러나 이 프로젝트는 2004년 중단되었고, 요건 분석과 설계, 개발, 프로젝트 관리에서 문제가 발생하였습니다. 결국, 2006년까지 6억 달러를 지출했으나 성과를 얻지 못했습니다.
  
  이후 FBI는 록히드 마틴과 계약을 체결하고 센티넬 프로젝트를 재개하였으나, 2010년 8월까지 완료율은 50%에 불과하고 예산이 초과되었습니다. 이에 따라 FBI는 MITRE에 비용 산정을 의뢰하였고, 추가 비용은 3억 5,100만 달러로 추정되었습니다. 계속된 예산 투입에도 불구하고 결과가 나오지 않자, 2008년 12월 로버트 뮬러 국장은 채드 풀험에게 센티넬 프로젝트를 맡겼습니다.
  
  풀험은 2010년 9월부터 애자일 개발 방법론을 도입하여 프로젝트를 추진하였으며, 2주 간격의 반복 스크럼 방식을 통해 개발을 진행하였습니다. 비록 최초의 데드라인인 2011년 9월은 지키지 못했지만, 애자일 개발을 통해 예산을 효율적으로 운용하며 프로젝트를 완료하였습니다.
  
  미국 정부 회계 감사원(GAO)의 보고서는 FBI와 다른 연방 정부 기관들이 애자일 개발의 효과를 입증했다고 강조하고 있습니다. 애자일 개발은 긍정적인 결과를 도출하는 소프트웨어 개발 방식으로, 경영진의 관점에서 평가는 엇갈릴 수 있습니다. GAO는 국방부, NASA, 특허청 등 여러 기관의 애자일 개발 사례를 분석하며 32가지 효과적인 애자일 개발 실천 사례와 방법을 제시하였습니다.
  
  미국 정부가 애자일 개발을 통해 성공을 이룰 수 있었던 이유는 애자일의 본질을 이해하고 이를 실천했기 때문입니다. 즉, 애자일 개발 방법론을 단순히 적용하기보다는 그 철학을 받아들여야 한다는 것입니다. 애자일 개발에서 가장 중요한 것은 변화에 적응하는 것입니다.
  
  GAO는 성공적인 애자일 개발을 위해 필요한 경우 소프트웨어 개발 계획을 조정해야 한다고 지적하였습니다. 제때, 주어진 예산 내에서 소프트웨어를 개발하고 전달하는 것이며, 목표 달성을 위해서는 기존 방법을 변경할 수도 있어야 합니다.
  
  물론, 여전히 애자일 개발과 관련된 여러 과제가 존재합니다. 협업 및 요구 사항 관리의 어려움, 직원 참여 부족, 불분명한 가이드라인 등 여러 난제가 도사리고 있습니다. 그러나 많은 정부 기관들은 애자일 개발에 있어 유연한 태도를 보여주고 있으며, 이러한 변화가 앞으로의 성과로 이어질 수 있기를 기대합니다.

  시스템 개발원칙 4조 : 민첩한 시스템 개발

  

  민첩한 시스템 개발(Agile Development)은 소프트웨어 개발 과정에서 반복적이고 점진적인 접근 방식을 통해 제품을 개선하고, 고객의 피드백을 신속하게 반영하는 것을 목표로 합니다. 이를 통해 개발 팀은 빠르고 유연하게 프로젝트를 진행할 수 있습니다.
  
  1. 반복적 개발
  소프트웨어는 한 번에 완성되지 않습니다. 여러 차례에 걸쳐 점진적으로 개선해 나가며, 개발 과정 중에도 결과물을 확인하고 필요한 수정사항을 즉시 반영할 수 있습니다.
  
  2. 고객 중심
  개발 과정에서는 고객의 요구사항과 피드백을 지속적으로 반영하여, 고객이 원하는 방향으로 제품을 개발합니다. 이를 통해 최종 제품의 품질을 높일 수 있습니다.
  
  3. 적응력
  변화하는 요구사항에 빠르게 대응하여, 유연하게 개발 방향을 조정할 수 있는 능력을 갖추고 있습니다. 이는 시장의 변화에 민첩하게 반응할 수 있도록 합니다.
  
  
  
  * Agile 개발 방법론 적용 예시
  
  온라인 쇼핑몰 개발 시, 모든 기능을 한 번에 완벽히 구현하기보다는 핵심 기능인 제품 검색과 장바구니 기능을 우선 개발하여 배포합니다. 이후 고객의 피드백을 반영하여 결제 기능, 리뷰 기능 등을 점진적으로 추가해 나가는 방식입니다.
  
  
  
  * 민첩한 시스템 개발 성공 사례 : Spotify
  
  Spotify는 음악 스트리밍 서비스로, 민첩한 개발 방법론을 통해 빠르게 성장할 수 있었습니다. Spotify는 작은 팀 단위로 구성되어 각 팀이 특정 기능이나 모듈에 집중할 수 있도록 하여, 새로운 기능을 신속하게 개발하고 사용자의 피드백을 지속적으로 반영했습니다.
  
  주요 성공 요소
  - 작은 팀으로의 분할과 자율성 부여
  - 지속적인 사용자 피드백 반영
  - 점진적이고 반복적인 개발
  
  
  
  * 민첩한 시스템 개발 실패 사례 : Healthcare.gov
  
  2013년 출시된 미국의 Healthcare.gov 웹사이트는 오바마케어(ACA)를 위한 온라인 건강 보험 사이트입니다. 초기 출시에서 대규모 실패를 겪었으며, 그 주된 이유는 민첩한 개발 방법론을 적용하지 않았기 때문입니다. 전통적인 폭포수 모델을 사용하여 모든 기능을 한 번에 구현하려 했습니다.
  
  주요 실패 요인
  - 한 번에 모든 기능 구현 시도
  - 사용자 피드백 반영 부족
  - 유연하지 못한 개발 과정
  
  민첩한 시스템 개발은 성공적인 소프트웨어 개발을 위한 중요한 접근 방식이며, 이를 통해 변화하는 시장 환경에 효과적으로 대응할 수 있습니다.
  
  
  
  * 美 FBI ‘애자일 기법 유효’ 입증 사례
  
  FBI는 2013년 6월 20일 애자일(Agile) 소프트웨어 개발 방법의 유효성을 입증하는 사례를 발표하였습니다. 그러나 이 발표는 큰 반향을 일으키지 못했습니다. 10여 년간 10억 달러에 달하는 세금을 쏟아 부은 프로젝트가 실패로 돌아간 점을 감안하면 아이러니한 일이었습니다. 소통 부족과 경쟁력 결여, 감독 부실 등이 원인이 되어 세금이 낭비되었지만, 애자일 개발을 도입한 CIO의 노력 덕분에 프로젝트는 다시 제 궤도에 올랐습니다.
  
  FBI의 사례는 애자일 개발이 실제로 효과적이라는 중요한 교훈을 시사합니다. 완벽하진 않지만, 많은 정부 공무원들과 계약업체들이 여전히 어려움을 겪고 있음에도 불구하고 성과가 나타나고 있습니다. 애자일 개발은 정부가 대형 IT 프로젝트를 제때, 주어진 예산 내에 구현하도록 돕고 있으며, 원하는 목표를 달성하는 데 기여하고 있습니다.
  
  문제의 FBI 프로젝트는 '센티넬(Sentinel)'로, 에드가 후버 시대부터 이어져 온 종이 파일 시스템을 대체하기 위한 것이었습니다. 9/11 사건을 계기로 사건 관리 시스템의 필요성이 부각되었고, FBI는 가상 사건 파일(Virtual Case File) 프로젝트에 1억 7,000만 달러의 예산을 배정했습니다. 그러나 이 프로젝트는 2004년 중단되었고, 요건 분석과 설계, 개발, 프로젝트 관리에서 문제가 발생하였습니다. 결국, 2006년까지 6억 달러를 지출했으나 성과를 얻지 못했습니다.
  
  이후 FBI는 록히드 마틴과 계약을 체결하고 센티넬 프로젝트를 재개하였으나, 2010년 8월까지 완료율은 50%에 불과하고 예산이 초과되었습니다. 이에 따라 FBI는 MITRE에 비용 산정을 의뢰하였고, 추가 비용은 3억 5,100만 달러로 추정되었습니다. 계속된 예산 투입에도 불구하고 결과가 나오지 않자, 2008년 12월 로버트 뮬러 국장은 채드 풀험에게 센티넬 프로젝트를 맡겼습니다.
  
  풀험은 2010년 9월부터 애자일 개발 방법론을 도입하여 프로젝트를 추진하였으며, 2주 간격의 반복 스크럼 방식을 통해 개발을 진행하였습니다. 비록 최초의 데드라인인 2011년 9월은 지키지 못했지만, 애자일 개발을 통해 예산을 효율적으로 운용하며 프로젝트를 완료하였습니다.
  
  미국 정부 회계 감사원(GAO)의 보고서는 FBI와 다른 연방 정부 기관들이 애자일 개발의 효과를 입증했다고 강조하고 있습니다. 애자일 개발은 긍정적인 결과를 도출하는 소프트웨어 개발 방식으로, 경영진의 관점에서 평가는 엇갈릴 수 있습니다. GAO는 국방부, NASA, 특허청 등 여러 기관의 애자일 개발 사례를 분석하며 32가지 효과적인 애자일 개발 실천 사례와 방법을 제시하였습니다.
  
  미국 정부가 애자일 개발을 통해 성공을 이룰 수 있었던 이유는 애자일의 본질을 이해하고 이를 실천했기 때문입니다. 즉, 애자일 개발 방법론을 단순히 적용하기보다는 그 철학을 받아들여야 한다는 것입니다. 애자일 개발에서 가장 중요한 것은 변화에 적응하는 것입니다.
  
  GAO는 성공적인 애자일 개발을 위해 필요한 경우 소프트웨어 개발 계획을 조정해야 한다고 지적하였습니다. 제때, 주어진 예산 내에서 소프트웨어를 개발하고 전달하는 것이며, 목표 달성을 위해서는 기존 방법을 변경할 수도 있어야 합니다.
  
  물론, 여전히 애자일 개발과 관련된 여러 과제가 존재합니다. 협업 및 요구 사항 관리의 어려움, 직원 참여 부족, 불분명한 가이드라인 등 여러 난제가 도사리고 있습니다. 그러나 많은 정부 기관들은 애자일 개발에 있어 유연한 태도를 보여주고 있으며, 이러한 변화가 앞으로의 성과로 이어질 수 있기를 기대합니다.

  닫기

• 

  시스템 개발 원칙 5조 : 자기조직화된 팀의 고객 협업

  자기 조직화된 팀은 팀원들이 팀의 목표를 인식 공유하고 이를 달성하기 위해 자발적으로 상호 협력하여 업무를 수행하는 구조를 갖추고 있으며, 고객과의 협업을 통해 효율성을 극대화할 수 있습니다. 아래는 각 상황에서 고객의 요구를 반영하여 팀이 어떻게 협업을 이루는지를 설명합니다.
  
  
  1. 제안서 작성 팀 (제안 TF)
  
  고객의 요구에 따라 갑자기 제안서를 작성하게 될 때, 팀은 다음과 같은 절차를 통해 협업합니다.
  
  - 팀원 구성 및 필요성 설명
  본부장이 고객의 요구와 목적 목표를 명확히 전달하고, 팀원들은 각자의 역할을 이해합니다.
  
  - 도메인별 그룹핑
  고객의 요구에 따라 PM, 디자인, 어드민 등으로 나누어 각자의 전문성을 활용합니다.
  
  - 자료 수집 및 정리
  고객의 기대에 부합하는 자료를 공유폴더에 정리하여, 모든 팀원이 쉽게 접근할 수 있도록 합니다.
  
  - 목차 및 작업 분배
  고객의 피드백을 반영하여 제안서의 목차를 정하고, 각 팀원이 맡을 분량을 명확히 합니다.
  
  - 발표자료 준비
  고객의 이해관계를 고려하여 발표자료를 작성하고, 피드백을 통해 내용을 보완합니다.
  
  이 과정에서 설정된 목표를 달성하기 위해 고객의 의견을 적극 반영하여 팀의 협업을 강화합니다.
  
  
  
  2. 시스템 개발 팀 (PoSE 개발)
  
  고객의 필요가 제기되면 즉시 개발을 시작하는 구조를 갖추고 있습니다:
  
  - 팀원 구성 및 필요성 설명
  조직장은 고객의 현재 및 미래의 요구를 분석하고, 팀원들은 그에 맞춰 협력합니다.
  
  - 기능 및 업무 프로세스 정의
  고객의 요구를 바탕으로 영업부터 준공까지의 절차를 정의하여 명확한 개발 방향을 설정합니다.
  
  - 시스템 구현
  고객의 사용 편의를 고려하여 시스템을 구현하고, 지속적인 피드백을 통해 개선합니다.
  
  이러한 협업을 통해 고객의 기대에 부응하는 솔루션을 제공합니다.
  
  
  
  3. AI 사업 준비 팀 (AI TF)
  
  고객의 요구가 변하는 상황에서 빠르게 대응하기 위해 팀원들이 자발적으로 협력합니다.
  
  - 팀원 구성 및 필요성 설명
  본부장은 고객의 사업 확대 필요성을 전달하고, 팀원들은 각자의 전문성을 적극 활용합니다.
  
  - 업무 도메인 이해
  팀원들은 고객의 데이터 속성을 깊이 이해하고, 이를 바탕으로 AI 시스템을 구축합니다.
  
  - 비즈니스 모델 준비
  고객의 요구에 적합한 비즈니스 모델을 개발하기 위해 협력하여 아이디어를 공유합니다.
  
  각 팀원들은 고객의 필요를 중심으로 유기적으로 협력하며, 자발적인 조직화를 통해 효과적인 솔루션을 제공합니다.
  
  
  이와 같이 자기 조직화된 팀은 고객의 요구를 중심으로 협력하며, 각자의 역할을 명확히 하여 효율적인 결과를 도출합니다. 고객과의 긴밀한 협업은 팀의 성과를 높이는 중요한 요소입니다.
  
  
  
  ※ '자기조직화'의 뜻
  
  '자기조직화는 복잡성 과학의 이론을 토대로 하여 출현한 이론이다.
  자기조직화를 행정시스템적 관점에서 바라보면, 자기조직화(self-organization)란 시스템의 구조가 외부로부터의 압력이나 관련이 없이 스스로 혁신적인 방법으로 조직을 꾸려나가는 것을 말한다. 즉, 한 시스템 안에 있는 수많은 요소들이 공유하는 시스템의 목적 달성을 위하여 얼기설기 얽혀 상호관계나 복잡한 관계를 끊임없이 재구성하고 환경에 적응해 나간다.
  
  자기조직화의 대표적인 사례로 일리야 프리고진의 사례를 들 수 있다. 그는 점균류 곰팡이를 관찰하여 자기조직화 이론을 도출해내었는데, 점균류 곰팡이는 영양분이 모자라게 되면 서로 신호를 보내어 수만 마리가 일제히 요동을 시작하여 한 곳에 모여 어떤 수준에 도달하게 되면 그들은 응집 덩어리를 형성하고 하나의 유기체가 되어 기어다니며 영양을 섭취한다. 이 후에, 환경이 다시 나아지면 다시 흩어져서 단세포 생물의 자리로 돌아가는 것이다. 이처럼 자기조직화 이론은 과학적인 측면에서뿐만 아니라 혁신을 주도하는 세계의 흐름 속에서 주목 받는 이론이라고 정의할 수 있다.

  시스템 개발 원칙 5조 : 자기조직화된 팀의 고객 협업

  

  자기 조직화된 팀은 팀원들이 팀의 목표를 인식 공유하고 이를 달성하기 위해 자발적으로 상호 협력하여 업무를 수행하는 구조를 갖추고 있으며, 고객과의 협업을 통해 효율성을 극대화할 수 있습니다. 아래는 각 상황에서 고객의 요구를 반영하여 팀이 어떻게 협업을 이루는지를 설명합니다.
  
  
  1. 제안서 작성 팀 (제안 TF)
  
  고객의 요구에 따라 갑자기 제안서를 작성하게 될 때, 팀은 다음과 같은 절차를 통해 협업합니다.
  
  - 팀원 구성 및 필요성 설명
  본부장이 고객의 요구와 목적 목표를 명확히 전달하고, 팀원들은 각자의 역할을 이해합니다.
  
  - 도메인별 그룹핑
  고객의 요구에 따라 PM, 디자인, 어드민 등으로 나누어 각자의 전문성을 활용합니다.
  
  - 자료 수집 및 정리
  고객의 기대에 부합하는 자료를 공유폴더에 정리하여, 모든 팀원이 쉽게 접근할 수 있도록 합니다.
  
  - 목차 및 작업 분배
  고객의 피드백을 반영하여 제안서의 목차를 정하고, 각 팀원이 맡을 분량을 명확히 합니다.
  
  - 발표자료 준비
  고객의 이해관계를 고려하여 발표자료를 작성하고, 피드백을 통해 내용을 보완합니다.
  
  이 과정에서 설정된 목표를 달성하기 위해 고객의 의견을 적극 반영하여 팀의 협업을 강화합니다.
  
  
  
  2. 시스템 개발 팀 (PoSE 개발)
  
  고객의 필요가 제기되면 즉시 개발을 시작하는 구조를 갖추고 있습니다:
  
  - 팀원 구성 및 필요성 설명
  조직장은 고객의 현재 및 미래의 요구를 분석하고, 팀원들은 그에 맞춰 협력합니다.
  
  - 기능 및 업무 프로세스 정의
  고객의 요구를 바탕으로 영업부터 준공까지의 절차를 정의하여 명확한 개발 방향을 설정합니다.
  
  - 시스템 구현
  고객의 사용 편의를 고려하여 시스템을 구현하고, 지속적인 피드백을 통해 개선합니다.
  
  이러한 협업을 통해 고객의 기대에 부응하는 솔루션을 제공합니다.
  
  
  
  3. AI 사업 준비 팀 (AI TF)
  
  고객의 요구가 변하는 상황에서 빠르게 대응하기 위해 팀원들이 자발적으로 협력합니다.
  
  - 팀원 구성 및 필요성 설명
  본부장은 고객의 사업 확대 필요성을 전달하고, 팀원들은 각자의 전문성을 적극 활용합니다.
  
  - 업무 도메인 이해
  팀원들은 고객의 데이터 속성을 깊이 이해하고, 이를 바탕으로 AI 시스템을 구축합니다.
  
  - 비즈니스 모델 준비
  고객의 요구에 적합한 비즈니스 모델을 개발하기 위해 협력하여 아이디어를 공유합니다.
  
  각 팀원들은 고객의 필요를 중심으로 유기적으로 협력하며, 자발적인 조직화를 통해 효과적인 솔루션을 제공합니다.
  
  
  이와 같이 자기 조직화된 팀은 고객의 요구를 중심으로 협력하며, 각자의 역할을 명확히 하여 효율적인 결과를 도출합니다. 고객과의 긴밀한 협업은 팀의 성과를 높이는 중요한 요소입니다.
  
  
  
  ※ '자기조직화'의 뜻
  
  '자기조직화는 복잡성 과학의 이론을 토대로 하여 출현한 이론이다.
  자기조직화를 행정시스템적 관점에서 바라보면, 자기조직화(self-organization)란 시스템의 구조가 외부로부터의 압력이나 관련이 없이 스스로 혁신적인 방법으로 조직을 꾸려나가는 것을 말한다. 즉, 한 시스템 안에 있는 수많은 요소들이 공유하는 시스템의 목적 달성을 위하여 얼기설기 얽혀 상호관계나 복잡한 관계를 끊임없이 재구성하고 환경에 적응해 나간다.
  
  자기조직화의 대표적인 사례로 일리야 프리고진의 사례를 들 수 있다. 그는 점균류 곰팡이를 관찰하여 자기조직화 이론을 도출해내었는데, 점균류 곰팡이는 영양분이 모자라게 되면 서로 신호를 보내어 수만 마리가 일제히 요동을 시작하여 한 곳에 모여 어떤 수준에 도달하게 되면 그들은 응집 덩어리를 형성하고 하나의 유기체가 되어 기어다니며 영양을 섭취한다. 이 후에, 환경이 다시 나아지면 다시 흩어져서 단세포 생물의 자리로 돌아가는 것이다. 이처럼 자기조직화 이론은 과학적인 측면에서뿐만 아니라 혁신을 주도하는 세계의 흐름 속에서 주목 받는 이론이라고 정의할 수 있다.

  닫기

• 

  시스템 개발 원칙 6조 : 프로젝트 성공을 위한 권한과 책임 부여

  "권한과 책임은 해당 분야의 전문가에게 부여해야 한다.
  회사의 새로운 유니폼 디자인을 사장이 결정하게 한다면 어떤 결과가 나올까?
  각 분야의 전문가에게 권한을 부여하고 그들의 의견을 존중하는 것이 중요하다.
  이는 조직이 보다 창의적이고 효과적으로 발전할 수 있는 길이다."
  
  1. 리비안 손잡은 폭스바겐…독일의 약점이 드러났다
  
  폭스바겐 그룹은 연간 900만 대의 자동차를 생산하는 세계 2위 자동차 기업이지만, 현재 위기 상황에 처해 있습니다. 특히, 폭스바겐의 전기차 소프트웨어는 여러 차례 실패를 겪으며 심각한 문제를 드러냈습니다. 최근 몇 년간 출시된 ID.3와 ID.4 모델은 소프트웨어 오류로 인해 소비자들로부터 큰 불만을 샀고, 이는 폭스바겐의 전기차 판매에 부정적인 영향을 미쳤습니다. 이러한 문제를 해결하기 위해 폭스바겐은 카리아드라는 자회사를 설립했지만, 높은 관료주의와 경직된 조직 구조로 인해 목표 달성에 실패했습니다. 카리아드에서는 소프트웨어 엔지니어들이 아닌 비전문가들이 주요 결정을 내리는 경우가 많았고, 이는 혁신을 저해하는 요인이 되었습니다.
  
  카리아드의 내부 문화는 폭스바겐과 아우디의 기존 경영진에 의해 정의되었으며, 오래된 공급업체와 낡은 사고방식을 버리지 못한 채로 혁신을 시도했습니다. 한 직원은 “소프트웨어 엔지니어가 아닌 사람들이 소프트웨어에 대해 결정을 내립니다”라고 언급하며, 관료적 문화가 자리 잡으면서 소프트웨어 개발이 지연되고 있다고 지적했습니다. 또한, “환상적인 워라밸입니다. 회사가 공룡의 속도로 돌아가기 때문에 저는 일주일에 10시간 정도만 일하고 나머지 시간은 회의에 참석했습니다”라며 젊은 엔지니어들에게는 흥미로운 업무가 거의 없고 관료주의가 만연하다는 점을 강조했습니다.
  
  이러한 어려움 속에서 폭스바겐은 최근 독일 공장을 폐쇄하겠다는 발표로 충격을 주었고, 이는 전기차 시장에서의 경쟁력 부족이 문제로 지적됩니다. 이에 폭스바겐은 미국 전기차 스타트업 리비안과의 합작을 통해 전기차 소프트웨어 개발에 총 8조원을 투자하기로 결정했습니다. 이 결정은 폭스바겐이 전기차 시장에서의 경쟁력을 회복하기 위해 자체 소프트웨어 개발을 포기하고 카리아드를 사실상 종결하는 의미를 지니고 있습니다.
  
  폭스바겐의 리비안과의 제휴는 전기차 시장에서의 경쟁력을 높이고, 디지털 전환을 위한 새로운 출발이 될 수 있지만, 그 성공 여부는 향후 진행 상황에 달려 있습니다. 과거의 성공에 안주하는 사고방식이 여전히 문제로 작용하고 있으며, 독일 경제 전반의 패러다임 전환이 필요하다는 주장이 제기되고 있습니다. 이러한 변화가 성공하기 위해서는 권한과 책임을 명확히 하고, 자율성을 부여하는 문화가 필요합니다.
  
  
  * 폭탄이 된 소프트웨어
  폭스바겐의 전기차 소프트웨어는 여러 차례 실패를 겪었습니다. ID.3와 ID.4 모델은 심각한 소프트웨어 오류로 소비자 불만을 초래했으며, 이는 전기차 판매에 부정적인 영향을 미쳤습니다. 폭스바겐은 소프트웨어의 중요성을 인식하고 카리아드라는 자회사를 설립했지만, 관료주의와 경직된 구조로 인해 목표 달성에 실패했습니다.
  
  
  * 비상 경영 중 나온 8조원 베팅
  폭스바겐은 자동차 판매 감소와 영업이익 급감으로 비상 경영을 선언했습니다. 특히 중국 시장에서의 판매 감소가 큰 타격을 주었고, 경쟁력 있는 전기차 모델이 부족한 상황입니다. 이러한 배경 속에서 리비안과의 합작 발표는 서로의 약점을 보완할 수 있는 기회로 평가받았습니다.
  
  
  * 관료주의라는 함정
  폭스바겐의 카리아드는 뛰어난 엔지니어들이 있음에도 불구하고, 결정권이 비전문가들에게 있어 혁신이 저해되었습니다. 관료적 문화가 자리 잡으면서 소프트웨어 개발이 지연되었고, 이는 회사의 성장에 악영향을 미쳤습니다. 아래 내용은 독일권 직장인 커뮤니티에 올라온 카리아드 직원의 리뷰입니다.
  
  “소프트웨어 엔지니어가 아닌 사람들이 소프트웨어에 대해 결정을 내립니다. 문화의 대부분이 폭스바겐과 아우디의 기존 경영진에 의해 정의됩니다. 그들은 오래된 공급업체와 낡은 사고방식을 버리지 않으면서, 끊임없이 테슬라를 이긴다고 얘기하죠.”
  
  “환상적인 워라밸입니다. 회사가 공룡의 속도로 돌아가기 때문에 저는 일주일에 10시간 정도만 일하고 나머지 시간은 회의에 참석했습니다. 젊은 엔지니어 경력엔 사형선고일 수 있습니다. 흥미로운 업무가 거의 없고 관료주의가 너무 많습니다.”
  
  “최고경영진은 소프트웨어가 아닌 기계 제조 전공입니다. 많은 경직성과 레거시 프로세스가 존재합니다. ‘우리가 가장 잘 알고 여러분은 그냥 하세요’라는 태도입니다. 작은 위험조차 감수하길 싫어합니다.”
  
  
  * 이것은 독일 경제의 위기인가
  폭스바겐의 사례는 독일 경제 전반에 걸친 문제를 드러냅니다. 과거의 성공에 안주하며 새로운 산업 패러다임에 적응하지 못하는 상황이 지속되고 있습니다. 이는 독일이 산업화 과정에서 축적한 장점이 현재는 장애물로 작용하고 있음을 보여줍니다.
  
  
  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  
  
  2. B사 AS400 디커미션 프로젝트의 '프로젝트 성공을 위한 권한과 책임 부여' 스토리
  
  
  우리는 현재 B사 AS400 디커미션 프로젝트를 수행하고 있으며, 이 프로젝트는 B사 글로벌 IT부서, 인도 개발팀, 한국 B사 현업 등 다양한 이해관계자와 부서 간의 협력이 필요한 복잡한 작업입니다. 여러 차례의 문제와 도전이 있었지만, ‘권한과 책임부여’ 원칙이 프로젝트 성공에 얼마나 중요한 역할을 하는지 경험을 통해 깨닫게 되었습니다.
  
  
  * 문제 해결과 의사결정의 주도성
  프로젝트 초기 단계에서 우리는 기존 시스템 분석 과정에서 어려움을 겪었습니다. 7개의 목표 시스템을 이해하고, 연관된 추가 시스템을 파악하는 과정에서 분석 대상의 분량이 방대했으며, 계약직 팀원들은 고객사의 늦은 대응을 탓하고 기다리는 바람에 분석 작업이 지체되고 있었습니다.
  
  PM은 팀원들에게 “계약할 때 능력을 어필했으니, 지금이 그 능력을 보여줄 때”라고 강조하며, 문제 해결과 의사결정의 주체가 되어야 한다고 독려 했습니다. 이후 팀원들은 각자의 영역에서 문제를 해결하고 필요한 결정을 내리기 시작했고, 고객의 대응과 피드백이 늦더라도 미리 작업 가능한 부분을 준비하여 시간 손실을 최소화했습니다.
  
  
  * 적절한 권한과 책임 부여
  이 프로젝트에서 가장 중요한 변화는 각 팀원에게 적절한 권한과 책임이 부여된 것입니다. 초기에는 의사결정 권한이 제대로 부여되지 않아(의사결정 할 수 있다고 생각하지 않아) 팀원들이 문제를 주도적으로 해결하기보다는 외부의 조치와 도움을 기다리는 경우가 많았습니다.
  
  그러나 이후 팀원들은 자신이 결정하고 결과에 책임진다는 생각으로 주도적으로 문제를 해결하고, 고객의 반응을 적극적으로 이끌어내기 위해 노력하고 있습니다. 예를 들어, 인도 SRE팀과 협력하여 MSA 시스템에 우리 개발 애플리케이션을 통합하는 과정에서, 팀원들이 MSA 시스템을 분석하고 필요한 조치를 할 수 있도록, 적극적으로 SRE팀에 대응 요청을 하며 일정 지연을 최소화하고 있습니다.
  
  
  * 성과에 대한 공동 책임
  프로젝트의 모든 팀원은 각자의 파악한 내용과 개발한 산출물을 적극적으로 공유하고 있습니다. SRE팀에서 만든 MSA 시스템에 대응하는 로컬 개발 환경 구축 과정에서, 팀원들은 자신이 작업한 내용과 문제점을 서로 공유하며 협력하여 해결해 나갔습니다. 이 경험을 통해 프로젝트 성과는 팀 전체의 책임이라는 인식이 공유되었고, 누군가의 실수가 있더라도 이를 해결하는 것은 개인의 책임이 아닌 팀 전체의 책임이라는 인식이 확립되었습니다.
  
  B사 AS400 디커미션 프로젝트는 ‘권한과 책임’ 원칙이 팀의 성과에 미치는 영향을 명확히 보여주는 사례입니다.
  
  문제 해결과 의사결정의 주체성을 가지는 것, 필요한 권한과 책임을 명확히 부여 받는 것, 성과에 대해 팀 전체가 책임을 공유하는 것이 프로젝트 진행에 결정적인 역할을 하며, 성공적인 결과를 도출할 수 있도록 합니다. 앞으로도 이러한 원칙을 적용한다면, 우리는 더 많은 도전과제를 극복하고 성공적인 결과를 만들어낼 수 있을 것이라 확신합니다.
  

  시스템 개발 원칙 6조 : 프로젝트 성공을 위한 권한과 책임 부여

  

  "권한과 책임은 해당 분야의 전문가에게 부여해야 한다.
  회사의 새로운 유니폼 디자인을 사장이 결정하게 한다면 어떤 결과가 나올까?
  각 분야의 전문가에게 권한을 부여하고 그들의 의견을 존중하는 것이 중요하다.
  이는 조직이 보다 창의적이고 효과적으로 발전할 수 있는 길이다."
  
  1. 리비안 손잡은 폭스바겐…독일의 약점이 드러났다
  
  폭스바겐 그룹은 연간 900만 대의 자동차를 생산하는 세계 2위 자동차 기업이지만, 현재 위기 상황에 처해 있습니다. 특히, 폭스바겐의 전기차 소프트웨어는 여러 차례 실패를 겪으며 심각한 문제를 드러냈습니다. 최근 몇 년간 출시된 ID.3와 ID.4 모델은 소프트웨어 오류로 인해 소비자들로부터 큰 불만을 샀고, 이는 폭스바겐의 전기차 판매에 부정적인 영향을 미쳤습니다. 이러한 문제를 해결하기 위해 폭스바겐은 카리아드라는 자회사를 설립했지만, 높은 관료주의와 경직된 조직 구조로 인해 목표 달성에 실패했습니다. 카리아드에서는 소프트웨어 엔지니어들이 아닌 비전문가들이 주요 결정을 내리는 경우가 많았고, 이는 혁신을 저해하는 요인이 되었습니다.
  
  카리아드의 내부 문화는 폭스바겐과 아우디의 기존 경영진에 의해 정의되었으며, 오래된 공급업체와 낡은 사고방식을 버리지 못한 채로 혁신을 시도했습니다. 한 직원은 “소프트웨어 엔지니어가 아닌 사람들이 소프트웨어에 대해 결정을 내립니다”라고 언급하며, 관료적 문화가 자리 잡으면서 소프트웨어 개발이 지연되고 있다고 지적했습니다. 또한, “환상적인 워라밸입니다. 회사가 공룡의 속도로 돌아가기 때문에 저는 일주일에 10시간 정도만 일하고 나머지 시간은 회의에 참석했습니다”라며 젊은 엔지니어들에게는 흥미로운 업무가 거의 없고 관료주의가 만연하다는 점을 강조했습니다.
  
  이러한 어려움 속에서 폭스바겐은 최근 독일 공장을 폐쇄하겠다는 발표로 충격을 주었고, 이는 전기차 시장에서의 경쟁력 부족이 문제로 지적됩니다. 이에 폭스바겐은 미국 전기차 스타트업 리비안과의 합작을 통해 전기차 소프트웨어 개발에 총 8조원을 투자하기로 결정했습니다. 이 결정은 폭스바겐이 전기차 시장에서의 경쟁력을 회복하기 위해 자체 소프트웨어 개발을 포기하고 카리아드를 사실상 종결하는 의미를 지니고 있습니다.
  
  폭스바겐의 리비안과의 제휴는 전기차 시장에서의 경쟁력을 높이고, 디지털 전환을 위한 새로운 출발이 될 수 있지만, 그 성공 여부는 향후 진행 상황에 달려 있습니다. 과거의 성공에 안주하는 사고방식이 여전히 문제로 작용하고 있으며, 독일 경제 전반의 패러다임 전환이 필요하다는 주장이 제기되고 있습니다. 이러한 변화가 성공하기 위해서는 권한과 책임을 명확히 하고, 자율성을 부여하는 문화가 필요합니다.
  
  
  * 폭탄이 된 소프트웨어
  폭스바겐의 전기차 소프트웨어는 여러 차례 실패를 겪었습니다. ID.3와 ID.4 모델은 심각한 소프트웨어 오류로 소비자 불만을 초래했으며, 이는 전기차 판매에 부정적인 영향을 미쳤습니다. 폭스바겐은 소프트웨어의 중요성을 인식하고 카리아드라는 자회사를 설립했지만, 관료주의와 경직된 구조로 인해 목표 달성에 실패했습니다.
  
  
  * 비상 경영 중 나온 8조원 베팅
  폭스바겐은 자동차 판매 감소와 영업이익 급감으로 비상 경영을 선언했습니다. 특히 중국 시장에서의 판매 감소가 큰 타격을 주었고, 경쟁력 있는 전기차 모델이 부족한 상황입니다. 이러한 배경 속에서 리비안과의 합작 발표는 서로의 약점을 보완할 수 있는 기회로 평가받았습니다.
  
  
  * 관료주의라는 함정
  폭스바겐의 카리아드는 뛰어난 엔지니어들이 있음에도 불구하고, 결정권이 비전문가들에게 있어 혁신이 저해되었습니다. 관료적 문화가 자리 잡으면서 소프트웨어 개발이 지연되었고, 이는 회사의 성장에 악영향을 미쳤습니다. 아래 내용은 독일권 직장인 커뮤니티에 올라온 카리아드 직원의 리뷰입니다.
  
  “소프트웨어 엔지니어가 아닌 사람들이 소프트웨어에 대해 결정을 내립니다. 문화의 대부분이 폭스바겐과 아우디의 기존 경영진에 의해 정의됩니다. 그들은 오래된 공급업체와 낡은 사고방식을 버리지 않으면서, 끊임없이 테슬라를 이긴다고 얘기하죠.”
  
  “환상적인 워라밸입니다. 회사가 공룡의 속도로 돌아가기 때문에 저는 일주일에 10시간 정도만 일하고 나머지 시간은 회의에 참석했습니다. 젊은 엔지니어 경력엔 사형선고일 수 있습니다. 흥미로운 업무가 거의 없고 관료주의가 너무 많습니다.”
  
  “최고경영진은 소프트웨어가 아닌 기계 제조 전공입니다. 많은 경직성과 레거시 프로세스가 존재합니다. ‘우리가 가장 잘 알고 여러분은 그냥 하세요’라는 태도입니다. 작은 위험조차 감수하길 싫어합니다.”
  
  
  * 이것은 독일 경제의 위기인가
  폭스바겐의 사례는 독일 경제 전반에 걸친 문제를 드러냅니다. 과거의 성공에 안주하며 새로운 산업 패러다임에 적응하지 못하는 상황이 지속되고 있습니다. 이는 독일이 산업화 과정에서 축적한 장점이 현재는 장애물로 작용하고 있음을 보여줍니다.
  
  
  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  
  
  2. B사 AS400 디커미션 프로젝트의 '프로젝트 성공을 위한 권한과 책임 부여' 스토리
  
  
  우리는 현재 B사 AS400 디커미션 프로젝트를 수행하고 있으며, 이 프로젝트는 B사 글로벌 IT부서, 인도 개발팀, 한국 B사 현업 등 다양한 이해관계자와 부서 간의 협력이 필요한 복잡한 작업입니다. 여러 차례의 문제와 도전이 있었지만, ‘권한과 책임부여’ 원칙이 프로젝트 성공에 얼마나 중요한 역할을 하는지 경험을 통해 깨닫게 되었습니다.
  
  
  * 문제 해결과 의사결정의 주도성
  프로젝트 초기 단계에서 우리는 기존 시스템 분석 과정에서 어려움을 겪었습니다. 7개의 목표 시스템을 이해하고, 연관된 추가 시스템을 파악하는 과정에서 분석 대상의 분량이 방대했으며, 계약직 팀원들은 고객사의 늦은 대응을 탓하고 기다리는 바람에 분석 작업이 지체되고 있었습니다.
  
  PM은 팀원들에게 “계약할 때 능력을 어필했으니, 지금이 그 능력을 보여줄 때”라고 강조하며, 문제 해결과 의사결정의 주체가 되어야 한다고 독려 했습니다. 이후 팀원들은 각자의 영역에서 문제를 해결하고 필요한 결정을 내리기 시작했고, 고객의 대응과 피드백이 늦더라도 미리 작업 가능한 부분을 준비하여 시간 손실을 최소화했습니다.
  
  
  * 적절한 권한과 책임 부여
  이 프로젝트에서 가장 중요한 변화는 각 팀원에게 적절한 권한과 책임이 부여된 것입니다. 초기에는 의사결정 권한이 제대로 부여되지 않아(의사결정 할 수 있다고 생각하지 않아) 팀원들이 문제를 주도적으로 해결하기보다는 외부의 조치와 도움을 기다리는 경우가 많았습니다.
  
  그러나 이후 팀원들은 자신이 결정하고 결과에 책임진다는 생각으로 주도적으로 문제를 해결하고, 고객의 반응을 적극적으로 이끌어내기 위해 노력하고 있습니다. 예를 들어, 인도 SRE팀과 협력하여 MSA 시스템에 우리 개발 애플리케이션을 통합하는 과정에서, 팀원들이 MSA 시스템을 분석하고 필요한 조치를 할 수 있도록, 적극적으로 SRE팀에 대응 요청을 하며 일정 지연을 최소화하고 있습니다.
  
  
  * 성과에 대한 공동 책임
  프로젝트의 모든 팀원은 각자의 파악한 내용과 개발한 산출물을 적극적으로 공유하고 있습니다. SRE팀에서 만든 MSA 시스템에 대응하는 로컬 개발 환경 구축 과정에서, 팀원들은 자신이 작업한 내용과 문제점을 서로 공유하며 협력하여 해결해 나갔습니다. 이 경험을 통해 프로젝트 성과는 팀 전체의 책임이라는 인식이 공유되었고, 누군가의 실수가 있더라도 이를 해결하는 것은 개인의 책임이 아닌 팀 전체의 책임이라는 인식이 확립되었습니다.
  
  B사 AS400 디커미션 프로젝트는 ‘권한과 책임’ 원칙이 팀의 성과에 미치는 영향을 명확히 보여주는 사례입니다.
  
  문제 해결과 의사결정의 주체성을 가지는 것, 필요한 권한과 책임을 명확히 부여 받는 것, 성과에 대해 팀 전체가 책임을 공유하는 것이 프로젝트 진행에 결정적인 역할을 하며, 성공적인 결과를 도출할 수 있도록 합니다. 앞으로도 이러한 원칙을 적용한다면, 우리는 더 많은 도전과제를 극복하고 성공적인 결과를 만들어낼 수 있을 것이라 확신합니다.
  

  닫기

• 

  시스템 개발 원칙 7조 : 개발 범위의 유연화, 우선순위에 따라 개발

  고객의 요구사항 변경을 유연하게 수용하고 개발 범위를 조정하는 것은 프로젝트의 성공에 필수적이자 애자일 개발원칙이기도 입니다. 요구사항은 사용자가 문제를 해결하거나 목표를 달성하기 위해 필요로 하는 조건이나 기능을 의미합니다. 이는 시스템이 갖추어야 할 조건과 능력의 총체로, 명확한 요구사항 파악은 불필요한 오해를 줄이고 프로젝트의 성공을 담보합니다.
  
  
  1. 요구사항 분석의 목표
  
  요구사항 분석은 프로젝트 전체의 방향에 대한 중대한 실수를 방지하는 데 중점을 둡니다. 이는 "어떻게 (how to)"가 아닌 "무엇(what)"에 초점을 맞추어 고객과 개발자가 공동의 목표를 설정할 수 있도록 돕습니다. 이 과정을 통해 요구사항에 대한 이해를 제대로 할 수 있게 되고 개발 범위에 대한 피드백이 가능해집니다.
  
  
  2. 요구사항 명세서의 역할
  
  분석 단계의 산출물인 요구사항 명세서는 고객과 개발자가 모두 이해할 수 있도록 작성되어야 하며, 명시된 조건은 양측이 동의한 내용이어야 합니다. 제안된 시스템의 모든 기능과 영향을 미치는 제약 조건을 명확히 기술하고, 시스템 사용을 위한 검증 기준을 제시해야 합니다. 또한, 시스템의 품질, 상대적 중요성, 그리고 품질의 측정 및 검증 방법을 명세서에 포함시켜야 합니다. 시스템의 포용성과 오류 조건도 명시하여 개발 과정에서의 유연성을 확보해야 합니다.
  
  이러한 요구사항 명세서는 개발 과정에서 우선순위를 설정하고, 필요에 따라 개발 범위를 조정하는 데 중요한 기준이 됩니다. 이를 통해 프로젝트는 변화하는 요구에 적응하며, 성공적인 결과를 도출할 수 있습니다.
  고객의 요구사항 변경과 개발 범위 조정 방법에 대한 몇 가지 접근법을 소개합니다.
  
  
  
  3. 애자일(Agile) 방법론 활용
  
  - 우선순위 조정
  애자일에서는 고객의 요구사항을 우선순위에 따라 정렬하고, 가장 중요한 기능부터 개발합니다.
  
  - 개발 범위 유연화
  초기에 정해진(고정된) 개발범위(요구사항 명세서)대로 개발하는 것이 아니라 정해진 기간 내에 정해진 자원과 비용으로 개발주기마다 (명세서대로 개발 하는 것 보다) 더 중요하고 필요한 요구사항을 개발함으로써, 고객에게 제공되는 가치(효과)를 극대화 하게 됩니다.
  
  - 짧은 반복 주기
  개발을 짧은 반복 주기(스프린트)로 나누어 진행하고, 매 반복 주기마다 고객의 피드백을 반영합니다. 이를 통해 변경 사항을 신속하게 수용하고 개발 범위를 조정할 수 있습니다.
  
  
  
  4. 프로토타입 및 MVP 개발
  
  - 프로토타입 활용
  초기 단계에서 프로토타입을 제작하여 고객의 피드백을 받아 반영함으로써 요구사항을 명확히 하고 이후 변경 가능성을 줄입니다.
  
  - 최소 기능 제품(MVP) 개발
  완성된 제품 대신 최소한의 핵심 필수 기능만 포함한 제품을 먼저 개발 출시하고, 고객의 검증을 거쳐 기능을 점진적으로 추가하거나 변경하는 방식입니다.
  
  - 투자효과(ROI) 제고
  가장 중요한 MVP기능들을 조기에 개발 운영 되게 함으로써 개발투자효과를 미리 확보하고, 요구사항 명세서에 포함되어 있지만 그러나 상대적으로 중요도 낮은 것 보다 더 중요하고 가치가 큰 것을 개발하게 함으로써 ROI를 높이게 됩니다.
  
  - 프로젝트 실패 위험 제거
  MVP를 개발하여 조기에 운영 하게 함으로써, 일괄 개발(Big Bang개발)후 업무 전환할 때 발생하는 실패 위험과 그 파장을 최소화하여 프로젝트를 성공으로 이끕니다.
  
  
  
  5. 지속적인 고객 커뮤니케이션
  
  - 정기적인 미팅
  고객과 정기적으로 미팅을 통해 진행 상황을 공유하고, 피드백을 받아 변경 필요 사항을 조기에 파악하여 신속하게 대응합니다.
  
  - 고객 참여 및 협업
  모든 실패한 프로젝트의 가장 큰 요인은 ‘고객과의 협업 부재’ 입니다. 개발 현장에 고객이 상시 참여하고 빠르게 피드백 하는 것은 실패 요인을 (사전에) 제거하는 활동입니다.
  
  이러한 접근법을 통해 고객의 요구사항 변경 요구는 억제되거나 거부될 것이 아니라 권장되고 환영해야 할 것입니다. 프로젝트의 성공을 위한 발상 전환의 태도입니다.
  
  
  
  6. 프로젝트 성공 실패 사례
  
  → 실패한 모든 프로젝트는 개발범위를 고정하고 우선 순위를 부여하지 않았다.

  시스템 개발 원칙 7조 : 개발 범위의 유연화, 우선순위에 따라 개발

  

  고객의 요구사항 변경을 유연하게 수용하고 개발 범위를 조정하는 것은 프로젝트의 성공에 필수적이자 애자일 개발원칙이기도 입니다. 요구사항은 사용자가 문제를 해결하거나 목표를 달성하기 위해 필요로 하는 조건이나 기능을 의미합니다. 이는 시스템이 갖추어야 할 조건과 능력의 총체로, 명확한 요구사항 파악은 불필요한 오해를 줄이고 프로젝트의 성공을 담보합니다.
  
  
  1. 요구사항 분석의 목표
  
  요구사항 분석은 프로젝트 전체의 방향에 대한 중대한 실수를 방지하는 데 중점을 둡니다. 이는 "어떻게 (how to)"가 아닌 "무엇(what)"에 초점을 맞추어 고객과 개발자가 공동의 목표를 설정할 수 있도록 돕습니다. 이 과정을 통해 요구사항에 대한 이해를 제대로 할 수 있게 되고 개발 범위에 대한 피드백이 가능해집니다.
  
  
  2. 요구사항 명세서의 역할
  
  분석 단계의 산출물인 요구사항 명세서는 고객과 개발자가 모두 이해할 수 있도록 작성되어야 하며, 명시된 조건은 양측이 동의한 내용이어야 합니다. 제안된 시스템의 모든 기능과 영향을 미치는 제약 조건을 명확히 기술하고, 시스템 사용을 위한 검증 기준을 제시해야 합니다. 또한, 시스템의 품질, 상대적 중요성, 그리고 품질의 측정 및 검증 방법을 명세서에 포함시켜야 합니다. 시스템의 포용성과 오류 조건도 명시하여 개발 과정에서의 유연성을 확보해야 합니다.
  
  이러한 요구사항 명세서는 개발 과정에서 우선순위를 설정하고, 필요에 따라 개발 범위를 조정하는 데 중요한 기준이 됩니다. 이를 통해 프로젝트는 변화하는 요구에 적응하며, 성공적인 결과를 도출할 수 있습니다.
  고객의 요구사항 변경과 개발 범위 조정 방법에 대한 몇 가지 접근법을 소개합니다.
  
  
  
  3. 애자일(Agile) 방법론 활용
  
  - 우선순위 조정
  애자일에서는 고객의 요구사항을 우선순위에 따라 정렬하고, 가장 중요한 기능부터 개발합니다.
  
  - 개발 범위 유연화
  초기에 정해진(고정된) 개발범위(요구사항 명세서)대로 개발하는 것이 아니라 정해진 기간 내에 정해진 자원과 비용으로 개발주기마다 (명세서대로 개발 하는 것 보다) 더 중요하고 필요한 요구사항을 개발함으로써, 고객에게 제공되는 가치(효과)를 극대화 하게 됩니다.
  
  - 짧은 반복 주기
  개발을 짧은 반복 주기(스프린트)로 나누어 진행하고, 매 반복 주기마다 고객의 피드백을 반영합니다. 이를 통해 변경 사항을 신속하게 수용하고 개발 범위를 조정할 수 있습니다.
  
  
  
  4. 프로토타입 및 MVP 개발
  
  - 프로토타입 활용
  초기 단계에서 프로토타입을 제작하여 고객의 피드백을 받아 반영함으로써 요구사항을 명확히 하고 이후 변경 가능성을 줄입니다.
  
  - 최소 기능 제품(MVP) 개발
  완성된 제품 대신 최소한의 핵심 필수 기능만 포함한 제품을 먼저 개발 출시하고, 고객의 검증을 거쳐 기능을 점진적으로 추가하거나 변경하는 방식입니다.
  
  - 투자효과(ROI) 제고
  가장 중요한 MVP기능들을 조기에 개발 운영 되게 함으로써 개발투자효과를 미리 확보하고, 요구사항 명세서에 포함되어 있지만 그러나 상대적으로 중요도 낮은 것 보다 더 중요하고 가치가 큰 것을 개발하게 함으로써 ROI를 높이게 됩니다.
  
  - 프로젝트 실패 위험 제거
  MVP를 개발하여 조기에 운영 하게 함으로써, 일괄 개발(Big Bang개발)후 업무 전환할 때 발생하는 실패 위험과 그 파장을 최소화하여 프로젝트를 성공으로 이끕니다.
  
  
  
  5. 지속적인 고객 커뮤니케이션
  
  - 정기적인 미팅
  고객과 정기적으로 미팅을 통해 진행 상황을 공유하고, 피드백을 받아 변경 필요 사항을 조기에 파악하여 신속하게 대응합니다.
  
  - 고객 참여 및 협업
  모든 실패한 프로젝트의 가장 큰 요인은 ‘고객과의 협업 부재’ 입니다. 개발 현장에 고객이 상시 참여하고 빠르게 피드백 하는 것은 실패 요인을 (사전에) 제거하는 활동입니다.
  
  이러한 접근법을 통해 고객의 요구사항 변경 요구는 억제되거나 거부될 것이 아니라 권장되고 환영해야 할 것입니다. 프로젝트의 성공을 위한 발상 전환의 태도입니다.
  
  
  
  6. 프로젝트 성공 실패 사례
  
  → 실패한 모든 프로젝트는 개발범위를 고정하고 우선 순위를 부여하지 않았다.

  닫기

• 

  시스템 개발 원칙 8조 : SW개발 작업 가시화

  sw개발 작업은 보이지 않습니다. 건물 공사 등과는 다르게 ‘작업이 잘 진행되는지, 문제는 없는지’ 다른 사람들은 알기 어렵습니다. 환자의 병을 조기에 발견하면 대개 치료가 가능하지만 늦게 발견하면 고치기 어렵습니다. SW개발 프로젝트도 성공하기 위해서 ‘개발작업의 가시화’가 필수불가결 합니다.
  
  
  * Spotify의 스쿼드 모델을 활용한 프로젝트 관리 사례
  
  Spotify는 음악 스트리밍 서비스 개발 및 유지보수를 위해 독특한 '스쿼드 모델'을 도입하여 소프트웨어 개발 프로세스를 관리하고 있습니다. 이 모델은 애자일 방법론을 기반으로 하며, 작은 크로스-펑셔널 팀(스쿼드)을 중심으로 운영됩니다. 아래는 Spotify의 스쿼드 모델을 통한 프로젝트 관리 사례입니다.
  
  
  1) 개발 프로세스와 진척 상황을 가시화하여 투명성을 높입니다.
  Spotify의 각 스쿼드는 특정 기능이나 서비스 영역에 집중합니다. 예를 들어, 검색 기능, 플레이리스트 관리, 추천 시스템 등에 대한 스쿼드가 있습니다.
  각 스쿼드는 자체적으로 애자일 보드를 운영하며, 이를 통해 현재 진행 중인 작업, 백로그 아이템, 완료된 작업 등을 실시간으로 공유합니다.
  스쿼드 멤버들은 JIRA나 Trello와 같은 도구를 사용하여 작업 현황을 시각화하고, 모든 팀원이 프로젝트의 진행 상황을 쉽게 파악할 수 있도록 합니다.
  
  2) 개발 현황을 모니터링하고 게시하여 상황을 공유합니다.
  Spotify는 '챕터'라는 개념을 통해 유사한 기술을 가진 멤버들의 그룹을 형성합니다. 예를 들어, 웹 개발자 챕터, QA 챕터 등이 있습니다.
  챕터 리드는 정기적으로 개발 현황을 모니터링하고, 이를 조직 전체와 공유합니다.
  스쿼드의 진행 상황은 스프린트 리뷰와 데모 세션을 통해 공유됩니다. 이 세션들은 보통 2-3주마다 열리며, 완성된 기능을 시연하고 피드백을 받는 기회가 됩니다.
  이러한 과정은 Spotify의 내부 도구를 통해 기록되고 공유되어, 다른 스쿼드나 관련 부서에서도 진행 상황을 파악할 수 있게 합니다.
  
  3) 가시화를 통해 이해관계자 및 팀원 간의 협업, 소통, 작업 개선을 증진합니다.
  Spotify는 '길드'라는 개념을 도입하여 서로 다른 스쿼드와 챕터 간의 지식 공유와 협업을 촉진합니다. 예를 들어, 웹 성능 최적화 길드, 보안 길드 등이 있습니다. 이 길드들은 정기적으로 미팅을 갖고, 각자의 경험과 지식을 공유합니다.
  
  
  3-1. 이해관계자 맞춤 보고서 작성
  Spotify는 'Health Check' 시스템을 통해 각 스쿼드의 건강 상태를 평가합니다. 이는 팀 만족도, 제품 품질, 방향성 등 다양한 지표를 포함하며, 결과는 시각화되어 경영진과 공유됩니다.
  
  3-2. 이해관계자와 문서화된 위험 및 이슈 공유
  스쿼드 간 의존성이나 잠재적 문제는 'Dependency Board'를 통해 관리됩니다. 이 보드는 모든 이해관계자가 접근할 수 있어, 문제가 발생하기 전에 선제적으로 대응할 수 있게 합니다.
  
  3-3. 다양한 개발현황 가시화 방법 활용
  Spotify는 자체 개발한 'Squad Health Check' 모델을 사용하여 각 스쿼드의 건강 상태를 시각화합니다. 이는 신호등 체계(녹색, 노란색, 빨간색)를 사용하여 각 영역의 상태를 직관적으로 보여줍니다.
  
  이러한 Spotify의 접근 방식은 대규모 조직에서도 애자일 방법론을 효과적으로 적용할 수 있음을 보여주는 좋은 사례입니다. 그들의 스쿼드 모델은 자율성, 소통, 투명성을 증진시키며, 이는 빠르게 변화하는 시장에 대응하는 데 큰 도움이 되고 있습니다.
  
  
  
  * C사 스마트&비대면 통합운영관리시스템 개발 진행 현황
  
  M 본부는 2021년부터 'C사 스마트&비대면 통합운영관리시스템 개발 구축 사업'을 진행했습니다. 본 프로젝트는 WBS(Work Breakdown Structure) 관리방법을 적용하여 S/W 개발작업을 가시화하였고, 이는 프로젝트의 방향성을 유지하고 팀원 각자의 역할 및 일정을 세분화하여 관리하고 추적하는 데 도움을 주었습니다.
  
  
  1) 개발 프로세스와 진척 상황을 가시화하여 투명성을 높입니다.
  C사 프로젝트에서는 각 담당자의 개발 목표, 일정 등 주요 사항을 관리WBS와 개발WBS로 구분하여 식별하고, 구글시트를 활용하여 실시간으로 공유했습니다. 관리/개발 WBS를 통해 모든 참여자는 프로젝트의 명확한 목표와 진행 상황을 이해하고, 자신의 역할과 진척도를 쉽게 파악할 수 있습니다. 구글 시트는 모든 팀원이 접근할 수 있도록 설정되어 있어, 변경 사항이 즉시 반영되며, 각 팀원은 필요할 때마다 최신 프로젝트 개발 상황을 확인할 수 있습니다.
  
  2) 개발 현황을 모니터링하고 게시하여 상황을 공유합니다.
  프로젝트의 개발 현황을 정기적으로 확인하기 위해 각 담당자 별 구분된 세부 업무 단위로 진행 상태를 색상으로 표시하여 진행 중, 완료, 착수 지연, 완료 지연 등을 한눈에 파악할 수 있습니다. 개발 WBS는 프로젝트 리더(PL)가 파트 팀원의 세부 업무와 일정을 별도 관리할 수 있도록 시트로 구분하여 종합 개발 현황과 파트별 개발 현황을 확인할 수 있도록 하였습니다.
  
  매주 진행되는 회의에서는 WBS를 이용하여 진척 상황을 공유하고, 식별된 이슈는 별도의 시트로 관리됩니다. 이슈 관리를 통해 프로젝트의 위험 발생을 최소화하고 발생한 이슈는 담당자를 지정하여 완료시 까지 추적함으로써 파트나 팀원 간의 소통을 증진시키고, 해결책을 모색하는 중요한 방법이 됩니다. 회의에서 논의된 내용은 다시 이슈 시트에 반영되어 모든 팀원이 진행 내용을 공유하고, 향후 진행 방향을 설정하는 데 도움이 되도록 합니다.
  
  3) 가시화를 통해 고객 및 팀원 간의 협업, 소통, 작업 개선을 증진합니다.
  C사 프로젝트에서는 고객사와의 원활한 소통 및 협업을 강화하기 위해 매월 정기적인 업무 보고를 실시하고 있습니다. 내부적으로 개발 일정을 공유하는 방식과는 달리, 고객사에게는 주요 일정 중심으로 보고하고 있습니다. 이러한 소통 및 협업 증진 노력은 고객사와의 신뢰 관계를 강화하고, 프로젝트의 성공적인 진행을 지원하는 데 기여하고 있습니다.
  
  
  3-1. 고객사 맞춤 보고서 작성
  고객에게는 매월 진행 현황을 종합 일정표에 계획된 업무와 지연된 업무를 쉽게 파악할 수 있도록 시각화하여 보여줍니다. 또한 계획 대비 실제 진행률은 별도 Burn Up Chart를 이용하여 시각화하고, 진척률이 떨어지는 이유를 차트에 명시하여 현 단계의 주요 이슈를 시각화하여 보여 줍니다. 이 보고서로 고객사는 프로젝트의 진행 상황을 한눈에 파악할 수 있습니다.
  
  3-2. 고객과 문서화된 위험 및 이슈 공유
  프로젝트를 진행하며 발생한 위험과 이슈는 별도 리스트로 관리하여 고객의 의사결정을 요구하거나 문제 해결을 위한 구체적인 방안을 제시합니다. 고객과의 미팅에서 주요 위험과 이슈에 대한 해결 방안을 논의하기도 합니다. 이러한 소통 과정을 통해 프로젝트의 위험이 최소화되고 고객사와의 관계가 더욱 강화되며, 고객의 피드백을 통해 서비스 품질을 지속적으로 개선할 수 있습니다.
  
  3-3. 다양한 개발현황 가시화 방법 검토
  개발현황을 가시화하기 위해 엑셀, Redmine, JIRA 등의 솔루션을 사용해 보았으나 상용 솔루션은 고객 요구에 맞는 보고서를 만들거나 현재 상태의 명확한 진척률을 파악하는 데 한계가 있어 엑셀을 사용하여 개발현황을 관리하고 있습니다. 프로젝트별 특성에 따라 전용 솔루션을 사용하거나 엑셀로 고객 맞춤형 보고서를 만들어 사용할 수 있습니다.

  시스템 개발 원칙 8조 : SW개발 작업 가시화

  

  sw개발 작업은 보이지 않습니다. 건물 공사 등과는 다르게 ‘작업이 잘 진행되는지, 문제는 없는지’ 다른 사람들은 알기 어렵습니다. 환자의 병을 조기에 발견하면 대개 치료가 가능하지만 늦게 발견하면 고치기 어렵습니다. SW개발 프로젝트도 성공하기 위해서 ‘개발작업의 가시화’가 필수불가결 합니다.
  
  
  * Spotify의 스쿼드 모델을 활용한 프로젝트 관리 사례
  
  Spotify는 음악 스트리밍 서비스 개발 및 유지보수를 위해 독특한 '스쿼드 모델'을 도입하여 소프트웨어 개발 프로세스를 관리하고 있습니다. 이 모델은 애자일 방법론을 기반으로 하며, 작은 크로스-펑셔널 팀(스쿼드)을 중심으로 운영됩니다. 아래는 Spotify의 스쿼드 모델을 통한 프로젝트 관리 사례입니다.
  
  
  1) 개발 프로세스와 진척 상황을 가시화하여 투명성을 높입니다.
  Spotify의 각 스쿼드는 특정 기능이나 서비스 영역에 집중합니다. 예를 들어, 검색 기능, 플레이리스트 관리, 추천 시스템 등에 대한 스쿼드가 있습니다.
  각 스쿼드는 자체적으로 애자일 보드를 운영하며, 이를 통해 현재 진행 중인 작업, 백로그 아이템, 완료된 작업 등을 실시간으로 공유합니다.
  스쿼드 멤버들은 JIRA나 Trello와 같은 도구를 사용하여 작업 현황을 시각화하고, 모든 팀원이 프로젝트의 진행 상황을 쉽게 파악할 수 있도록 합니다.
  
  2) 개발 현황을 모니터링하고 게시하여 상황을 공유합니다.
  Spotify는 '챕터'라는 개념을 통해 유사한 기술을 가진 멤버들의 그룹을 형성합니다. 예를 들어, 웹 개발자 챕터, QA 챕터 등이 있습니다.
  챕터 리드는 정기적으로 개발 현황을 모니터링하고, 이를 조직 전체와 공유합니다.
  스쿼드의 진행 상황은 스프린트 리뷰와 데모 세션을 통해 공유됩니다. 이 세션들은 보통 2-3주마다 열리며, 완성된 기능을 시연하고 피드백을 받는 기회가 됩니다.
  이러한 과정은 Spotify의 내부 도구를 통해 기록되고 공유되어, 다른 스쿼드나 관련 부서에서도 진행 상황을 파악할 수 있게 합니다.
  
  3) 가시화를 통해 이해관계자 및 팀원 간의 협업, 소통, 작업 개선을 증진합니다.
  Spotify는 '길드'라는 개념을 도입하여 서로 다른 스쿼드와 챕터 간의 지식 공유와 협업을 촉진합니다. 예를 들어, 웹 성능 최적화 길드, 보안 길드 등이 있습니다. 이 길드들은 정기적으로 미팅을 갖고, 각자의 경험과 지식을 공유합니다.
  
  
  3-1. 이해관계자 맞춤 보고서 작성
  Spotify는 'Health Check' 시스템을 통해 각 스쿼드의 건강 상태를 평가합니다. 이는 팀 만족도, 제품 품질, 방향성 등 다양한 지표를 포함하며, 결과는 시각화되어 경영진과 공유됩니다.
  
  3-2. 이해관계자와 문서화된 위험 및 이슈 공유
  스쿼드 간 의존성이나 잠재적 문제는 'Dependency Board'를 통해 관리됩니다. 이 보드는 모든 이해관계자가 접근할 수 있어, 문제가 발생하기 전에 선제적으로 대응할 수 있게 합니다.
  
  3-3. 다양한 개발현황 가시화 방법 활용
  Spotify는 자체 개발한 'Squad Health Check' 모델을 사용하여 각 스쿼드의 건강 상태를 시각화합니다. 이는 신호등 체계(녹색, 노란색, 빨간색)를 사용하여 각 영역의 상태를 직관적으로 보여줍니다.
  
  이러한 Spotify의 접근 방식은 대규모 조직에서도 애자일 방법론을 효과적으로 적용할 수 있음을 보여주는 좋은 사례입니다. 그들의 스쿼드 모델은 자율성, 소통, 투명성을 증진시키며, 이는 빠르게 변화하는 시장에 대응하는 데 큰 도움이 되고 있습니다.
  
  
  
  * C사 스마트&비대면 통합운영관리시스템 개발 진행 현황
  
  M 본부는 2021년부터 'C사 스마트&비대면 통합운영관리시스템 개발 구축 사업'을 진행했습니다. 본 프로젝트는 WBS(Work Breakdown Structure) 관리방법을 적용하여 S/W 개발작업을 가시화하였고, 이는 프로젝트의 방향성을 유지하고 팀원 각자의 역할 및 일정을 세분화하여 관리하고 추적하는 데 도움을 주었습니다.
  
  
  1) 개발 프로세스와 진척 상황을 가시화하여 투명성을 높입니다.
  C사 프로젝트에서는 각 담당자의 개발 목표, 일정 등 주요 사항을 관리WBS와 개발WBS로 구분하여 식별하고, 구글시트를 활용하여 실시간으로 공유했습니다. 관리/개발 WBS를 통해 모든 참여자는 프로젝트의 명확한 목표와 진행 상황을 이해하고, 자신의 역할과 진척도를 쉽게 파악할 수 있습니다. 구글 시트는 모든 팀원이 접근할 수 있도록 설정되어 있어, 변경 사항이 즉시 반영되며, 각 팀원은 필요할 때마다 최신 프로젝트 개발 상황을 확인할 수 있습니다.
  
  2) 개발 현황을 모니터링하고 게시하여 상황을 공유합니다.
  프로젝트의 개발 현황을 정기적으로 확인하기 위해 각 담당자 별 구분된 세부 업무 단위로 진행 상태를 색상으로 표시하여 진행 중, 완료, 착수 지연, 완료 지연 등을 한눈에 파악할 수 있습니다. 개발 WBS는 프로젝트 리더(PL)가 파트 팀원의 세부 업무와 일정을 별도 관리할 수 있도록 시트로 구분하여 종합 개발 현황과 파트별 개발 현황을 확인할 수 있도록 하였습니다.
  
  매주 진행되는 회의에서는 WBS를 이용하여 진척 상황을 공유하고, 식별된 이슈는 별도의 시트로 관리됩니다. 이슈 관리를 통해 프로젝트의 위험 발생을 최소화하고 발생한 이슈는 담당자를 지정하여 완료시 까지 추적함으로써 파트나 팀원 간의 소통을 증진시키고, 해결책을 모색하는 중요한 방법이 됩니다. 회의에서 논의된 내용은 다시 이슈 시트에 반영되어 모든 팀원이 진행 내용을 공유하고, 향후 진행 방향을 설정하는 데 도움이 되도록 합니다.
  
  3) 가시화를 통해 고객 및 팀원 간의 협업, 소통, 작업 개선을 증진합니다.
  C사 프로젝트에서는 고객사와의 원활한 소통 및 협업을 강화하기 위해 매월 정기적인 업무 보고를 실시하고 있습니다. 내부적으로 개발 일정을 공유하는 방식과는 달리, 고객사에게는 주요 일정 중심으로 보고하고 있습니다. 이러한 소통 및 협업 증진 노력은 고객사와의 신뢰 관계를 강화하고, 프로젝트의 성공적인 진행을 지원하는 데 기여하고 있습니다.
  
  
  3-1. 고객사 맞춤 보고서 작성
  고객에게는 매월 진행 현황을 종합 일정표에 계획된 업무와 지연된 업무를 쉽게 파악할 수 있도록 시각화하여 보여줍니다. 또한 계획 대비 실제 진행률은 별도 Burn Up Chart를 이용하여 시각화하고, 진척률이 떨어지는 이유를 차트에 명시하여 현 단계의 주요 이슈를 시각화하여 보여 줍니다. 이 보고서로 고객사는 프로젝트의 진행 상황을 한눈에 파악할 수 있습니다.
  
  3-2. 고객과 문서화된 위험 및 이슈 공유
  프로젝트를 진행하며 발생한 위험과 이슈는 별도 리스트로 관리하여 고객의 의사결정을 요구하거나 문제 해결을 위한 구체적인 방안을 제시합니다. 고객과의 미팅에서 주요 위험과 이슈에 대한 해결 방안을 논의하기도 합니다. 이러한 소통 과정을 통해 프로젝트의 위험이 최소화되고 고객사와의 관계가 더욱 강화되며, 고객의 피드백을 통해 서비스 품질을 지속적으로 개선할 수 있습니다.
  
  3-3. 다양한 개발현황 가시화 방법 검토
  개발현황을 가시화하기 위해 엑셀, Redmine, JIRA 등의 솔루션을 사용해 보았으나 상용 솔루션은 고객 요구에 맞는 보고서를 만들거나 현재 상태의 명확한 진척률을 파악하는 데 한계가 있어 엑셀을 사용하여 개발현황을 관리하고 있습니다. 프로젝트별 특성에 따라 전용 솔루션을 사용하거나 엑셀로 고객 맞춤형 보고서를 만들어 사용할 수 있습니다.

  닫기

• 

  시스템 개발 원칙 9조 : 상시 학습과 기술·품질 부채 쌓지 않기

  1. 지속적인 리팩토링
  
  기술부채(Technical debt)는 소프트웨어 개발 과정에서 급하게 구현한 코드나 임시방편으로 처리한 부분이 나중에 문제를 일으키게 되는 것들입니다. 이를 없애거나 최소화하기 위해서는 지속적인 학습과 품질 관리를 통해 기술부채가 쌓이지 않도록 해야 하며, ‘기술부채 줄이기’를 ‘요구사항 관리’처럼 하는 것이 필요합니다.
  
  1.1. 지속적인 학습과 적용
  효율적인 기술과 방법론을 꾸준히 학습하고 이를 실제 프로젝트에 적용해야 합니다. 최신 기술 동향을 따라가고 더 나은 방법으로 작업할 수 있도록 팀원들이 상시 학습하는 문화가 필요합니다.
  
  1.2. 기술부채 제거
  임시방편으로 처리한 코드나 설계의 문제점을 주기적으로 점검하고 개선하는 리팩토링 과정이 필수적입니다. 이를 통해 기술부채를 줄이고 시스템의 유지보수성을 높일 수 있습니다. 새로운 기능의 개발작업과 리팩토링 작업을 그 중요도와 필요성을 함께 평가하여 우선순위를 결정해야 합니다.
  
  1.3. 자동화된 테스트
  품질 보장을 위해 테스트 자동화를 우선적으로 실행해야 합니다. 자동화된 테스트는 반복적인 수작업을 줄이고 신속하게 문제를 발견하고 해결할 수 있도록 도와줍니다.
  
  
  
  2. 리팩토링 실천 방안
  
  2.1. 지속적인 코드 리뷰와 리팩토링
  팀원들이 정기적으로 코드 리뷰를 실시하고 코드의 품질을 개선하는 활동을 합니다. 주기적인 리팩토링을 통해 복잡한 코드를 간결하게 만들고, 가독성을 높여 기술부채를 줄입니다.
  
  2.2. 새로운 자동화 도구/기술 도입
  프로젝트에 필요한 새로운 기술이나 도구를 적극적으로 학습하고 도입합니다. 기존의 수동 테스트 방식을 자동화 테스트 도구로 전환하여 테스트의 효율성을 높이고 오류 발생 가능성을 줄입니다.
  
  2.3. DevOps 문화 도입
  DevOps 문화를 도입하여 개발과 운영 팀 간의 협력을 강화하고, 지속적인 통합과 배포(CI/CD)를 통해 기술부채를 줄입니다. 이를 통해 새로운 기능을 빠르게 배포하고 문제가 발생하면 신속히 대응할 수 있습니다.
  
  
  
  3. 원칙 적용 사례
  
  3.1. Google의 코드 리뷰 문화 사례
  Google은 상시 학습과 품질 관리를 위해 철저한 코드 리뷰 문화를 갖추고 있습니다. 모든 코드 변경 사항은 다른 개발자의 리뷰를 받아야 하며, 이를 통해 코드의 품질을 높이고 잠재적인 문제를 조기에 발견합니다. 정기적인 리팩토링과 최신 기술 도입을 장려하여 기술부채를 최소화합니다.
  
  주요 성공 요소
  - 철저한 코드 리뷰: 모든 코드 변경이 리뷰를 거쳐 품질을 보장합니다.
  - 정기적 리팩토링: 코드의 복잡성을 줄이고 유지보수성을 높입니다.
  - 최신 기술 도입: 지속적인 학습과 새로운 기술 도입을 통해 효율성을 향상시킵니다.
  
  3.2. Knight Capital의 소프트웨어 버그
  2012년 Knight Capital은 기술부채를 관리하지 못해 큰 재정적 손실을 입었습니다. 새로운 소프트웨어 배포 시 기존 코드와의 호환성을 충분히 테스트하지 않아 시스템 오류가 발생했습니다. 이로 인해 단 45분 만에 약 4억 4천만 달러의 손실을 입었고, 결국 회사는 파산에 이르게 되었습니다.
  
  주요 실패 요인
  - 충분한 테스트 부족: 새로운 소프트웨어 배포 시 기존 시스템과의 호환성 문제를 간과했습니다.
  - 기술부채 관리 실패: 기술부채를 적절히 관리하지 못해 시스템의 복잡도가 증가했습니다.
  - 리팩토링 부족: 기존 코드의 문제를 해결하지 않아 잠재적 오류가 누적되었습니다.
  
  이와 같은 사례를 통해 상시 학습과 품질 관리를 통해 기술부채를 쌓지 않는 것이 얼마나 중요한지를 알 수 있습니다.

  시스템 개발 원칙 9조 : 상시 학습과 기술·품질 부채 쌓지 않기

  

  1. 지속적인 리팩토링
  
  기술부채(Technical debt)는 소프트웨어 개발 과정에서 급하게 구현한 코드나 임시방편으로 처리한 부분이 나중에 문제를 일으키게 되는 것들입니다. 이를 없애거나 최소화하기 위해서는 지속적인 학습과 품질 관리를 통해 기술부채가 쌓이지 않도록 해야 하며, ‘기술부채 줄이기’를 ‘요구사항 관리’처럼 하는 것이 필요합니다.
  
  1.1. 지속적인 학습과 적용
  효율적인 기술과 방법론을 꾸준히 학습하고 이를 실제 프로젝트에 적용해야 합니다. 최신 기술 동향을 따라가고 더 나은 방법으로 작업할 수 있도록 팀원들이 상시 학습하는 문화가 필요합니다.
  
  1.2. 기술부채 제거
  임시방편으로 처리한 코드나 설계의 문제점을 주기적으로 점검하고 개선하는 리팩토링 과정이 필수적입니다. 이를 통해 기술부채를 줄이고 시스템의 유지보수성을 높일 수 있습니다. 새로운 기능의 개발작업과 리팩토링 작업을 그 중요도와 필요성을 함께 평가하여 우선순위를 결정해야 합니다.
  
  1.3. 자동화된 테스트
  품질 보장을 위해 테스트 자동화를 우선적으로 실행해야 합니다. 자동화된 테스트는 반복적인 수작업을 줄이고 신속하게 문제를 발견하고 해결할 수 있도록 도와줍니다.
  
  
  
  2. 리팩토링 실천 방안
  
  2.1. 지속적인 코드 리뷰와 리팩토링
  팀원들이 정기적으로 코드 리뷰를 실시하고 코드의 품질을 개선하는 활동을 합니다. 주기적인 리팩토링을 통해 복잡한 코드를 간결하게 만들고, 가독성을 높여 기술부채를 줄입니다.
  
  2.2. 새로운 자동화 도구/기술 도입
  프로젝트에 필요한 새로운 기술이나 도구를 적극적으로 학습하고 도입합니다. 기존의 수동 테스트 방식을 자동화 테스트 도구로 전환하여 테스트의 효율성을 높이고 오류 발생 가능성을 줄입니다.
  
  2.3. DevOps 문화 도입
  DevOps 문화를 도입하여 개발과 운영 팀 간의 협력을 강화하고, 지속적인 통합과 배포(CI/CD)를 통해 기술부채를 줄입니다. 이를 통해 새로운 기능을 빠르게 배포하고 문제가 발생하면 신속히 대응할 수 있습니다.
  
  
  
  3. 원칙 적용 사례
  
  3.1. Google의 코드 리뷰 문화 사례
  Google은 상시 학습과 품질 관리를 위해 철저한 코드 리뷰 문화를 갖추고 있습니다. 모든 코드 변경 사항은 다른 개발자의 리뷰를 받아야 하며, 이를 통해 코드의 품질을 높이고 잠재적인 문제를 조기에 발견합니다. 정기적인 리팩토링과 최신 기술 도입을 장려하여 기술부채를 최소화합니다.
  
  주요 성공 요소
  - 철저한 코드 리뷰: 모든 코드 변경이 리뷰를 거쳐 품질을 보장합니다.
  - 정기적 리팩토링: 코드의 복잡성을 줄이고 유지보수성을 높입니다.
  - 최신 기술 도입: 지속적인 학습과 새로운 기술 도입을 통해 효율성을 향상시킵니다.
  
  3.2. Knight Capital의 소프트웨어 버그
  2012년 Knight Capital은 기술부채를 관리하지 못해 큰 재정적 손실을 입었습니다. 새로운 소프트웨어 배포 시 기존 코드와의 호환성을 충분히 테스트하지 않아 시스템 오류가 발생했습니다. 이로 인해 단 45분 만에 약 4억 4천만 달러의 손실을 입었고, 결국 회사는 파산에 이르게 되었습니다.
  
  주요 실패 요인
  - 충분한 테스트 부족: 새로운 소프트웨어 배포 시 기존 시스템과의 호환성 문제를 간과했습니다.
  - 기술부채 관리 실패: 기술부채를 적절히 관리하지 못해 시스템의 복잡도가 증가했습니다.
  - 리팩토링 부족: 기존 코드의 문제를 해결하지 않아 잠재적 오류가 누적되었습니다.
  
  이와 같은 사례를 통해 상시 학습과 품질 관리를 통해 기술부채를 쌓지 않는 것이 얼마나 중요한지를 알 수 있습니다.

  닫기

• 

  시스템 개발 원칙 10조 : 초기부터 데브옵스 파이프라인 구축하여 테스트 주도 개발

  1. 문제 상황
  
  Creta 팀은 DevOps 파이프라인을 최대한 단순화한 채로 개발을 시작했습니다. 초기에는 개발-빌드-테스트라는 간단한 단계만 존재했기 때문에 문제 없이 진행되었습니다. 빌드에서 테스트 서버까지의 배포 과정도 매우 간단했으며, 운영 서버가 존재하지 않던 시기라 굳이 빌드와 배포를 자동화할 필요가 없었습니다.
  
  하지만 시간이 흐르면서 사업이 시작되었고, 다양한 잠재 고객이 나타났습니다. 이에 따라 고객별로 운영 서버를 분리하고, 각각의 운영 서버를 위한 별도의 테스트서버가 필요해졌습니다. 또한 고객별로 빌드 형태가 달라져야 했습니다. 이로 인해 개발-빌드-테스트-운영서버의 경로가 여러 갈래로 나뉘게 되었고, 기존의 수동 방식으로는 이러한 변화를 감당하기 어려워졌습니다.
  
  
  
  2. 해결 과정
  
  연구소는 각 연구팀이 모두 사용할 수 있는 CI/CD 도입 계획을 수립하고, DevOps파이프라인을 구축하게 되었습니다.
  
  
  2.1. 상황 분석
  
  - 시간 부족
  초기 CI/CD 도입을 위한 준비 시간을 감안하지 않는 것이 문제의 주요 원인이었습니다.
  이는 당장은 필요하지 않다고 생각하여 다른 우선순위 업무에 집중하게 된 때문입니다.
  
  - 경험 부족
  CI/CD 프로세스를 경험한 사람이 부족하였고, 이를 주도하고 관리할 리더 또한 필요하였습니다.
  
  
  2. CI/CD 계획 수립 및 추진
  
  - 과거에 CI/CD 구축 경험이 있는 엔지니어를 관리 총책임자로 선임하였습니다.
  - Creta팀, IQS팀, 스마트브릿지 팀 각각을 조사하여 필요한 파이프라인 형태를 파악하였습니다.
  - 이후, 각 팀에 대한 권장 안을 도출하였습니다.
  - 각 팀 별로 새로운 담당자를 선임하였고 역할을 분담하였습니다.
  
  이러한 과정을 통해 Creta팀은 그 이후부터 DevOps 파이프라인을 구축하고, 테스트 주도 개발을 효과적으로 실현할 수 있는 기반을 마련하게 되었습니다.

  시스템 개발 원칙 10조 : 초기부터 데브옵스 파이프라인 구축하여 테스트 주도 개발

  

  1. 문제 상황
  
  Creta 팀은 DevOps 파이프라인을 최대한 단순화한 채로 개발을 시작했습니다. 초기에는 개발-빌드-테스트라는 간단한 단계만 존재했기 때문에 문제 없이 진행되었습니다. 빌드에서 테스트 서버까지의 배포 과정도 매우 간단했으며, 운영 서버가 존재하지 않던 시기라 굳이 빌드와 배포를 자동화할 필요가 없었습니다.
  
  하지만 시간이 흐르면서 사업이 시작되었고, 다양한 잠재 고객이 나타났습니다. 이에 따라 고객별로 운영 서버를 분리하고, 각각의 운영 서버를 위한 별도의 테스트서버가 필요해졌습니다. 또한 고객별로 빌드 형태가 달라져야 했습니다. 이로 인해 개발-빌드-테스트-운영서버의 경로가 여러 갈래로 나뉘게 되었고, 기존의 수동 방식으로는 이러한 변화를 감당하기 어려워졌습니다.
  
  
  
  2. 해결 과정
  
  연구소는 각 연구팀이 모두 사용할 수 있는 CI/CD 도입 계획을 수립하고, DevOps파이프라인을 구축하게 되었습니다.
  
  
  2.1. 상황 분석
  
  - 시간 부족
  초기 CI/CD 도입을 위한 준비 시간을 감안하지 않는 것이 문제의 주요 원인이었습니다.
  이는 당장은 필요하지 않다고 생각하여 다른 우선순위 업무에 집중하게 된 때문입니다.
  
  - 경험 부족
  CI/CD 프로세스를 경험한 사람이 부족하였고, 이를 주도하고 관리할 리더 또한 필요하였습니다.
  
  
  2. CI/CD 계획 수립 및 추진
  
  - 과거에 CI/CD 구축 경험이 있는 엔지니어를 관리 총책임자로 선임하였습니다.
  - Creta팀, IQS팀, 스마트브릿지 팀 각각을 조사하여 필요한 파이프라인 형태를 파악하였습니다.
  - 이후, 각 팀에 대한 권장 안을 도출하였습니다.
  - 각 팀 별로 새로운 담당자를 선임하였고 역할을 분담하였습니다.
  
  이러한 과정을 통해 Creta팀은 그 이후부터 DevOps 파이프라인을 구축하고, 테스트 주도 개발을 효과적으로 실현할 수 있는 기반을 마련하게 되었습니다.

  닫기