► 하늘아래 비슷하더라도 정말 같은 프로젝트는 없.다.!
► 특정 목적성을 지니고 기간이 존재 + 점진적 구체화를 시키는 노력
► 유사용어:
프로그램 > 서로 관련성이 있는 여러 프로젝트들의 집합
포트폴리오 > 관련성이 있어도 되고 없어도 되는 프로그램의 집합
► 프로젝트의 목적: 예산안에 필요한 품질만큼을 가진 프로덕트를 납기하는 것
► 성공하기 위한 3가지 측면: PM, 환경, 조직적인 측면이 유기적으로 돌아가야한다.
► PM은 비즈니스인사이트가 있어야함.
► 주먹구구식으로 하는게 아니라 기존의 프로젝트들이 어떻게 성공했는지를 레퍼런스로 삼아 방법론을 도입해야 한다
► 환경적인 측면: 비즈니스의 정당성,목적성을 확보하여 지원을 받아낼 수 있어야함
► 착수단계에서 프로젝트에 대해 어느정도 이해하고 있는지도 프로젝트의 성공에 영향을 미침
► UI설계서가 나오게 한다음에 kickoff할때 고객에게 sign을 받을 수도 있음
► 바로 설계,개발기간확보 ► 프로젝트가 망가지더라도 버퍼가 생김
► 오프문화: 감정이 나빠지지 않도록 사람을 비난하는게 아니라 오픈 마인드로 소통해야함
프로젝트관리 방법론
► 고객이 원하는 아웃풋을 만들기 위해 체계적인 방법을 정리해놓은 방법론, 지식 중요
► 총 10가지 지식영역이 있음
► 관리하는 단계에는 5가지 단계가 있음.
✅ 킥오프 ► 계획 ► 고객의 요구사항을 명확하게 도출 ► 실행단계 ► 통제단계 ► 종료단계
► Scope: 프로젝트 기간동안 얼마만큼 할것인지 범위를 설정
► WBS(Work breakdown structure): 고객이 원하는산출물을 만들기 위해서 어떤 것들이 필요한지 나열시켜놓은 계층 구조
► 간트차트는 WBS와 혼용해서 사용되는 경우도 많음
► 범위관리시 가장 중요한 것: 요구사항 수집
- 일단 다 도출한다음 분석해서 어떤 기능을 넣어야 할지.할수있는지/하면안되는 건지 분석한다음 명세화(문서화가 아님)
- 고객과 협의를 거치면서 계속 검증해나감(도출-명세-합의-재작성)
- 나중에 개발하는데 활용
- 단 범위관리에 맞고 이 사업의 틀을 깨지 않는 상태에서 유지
- 이 요구사항이 어디에서 적용되서 개발되었는지를 추적하기 위해 매트릭스를 작성해서 추적하기도 함
연동기획(Rolling Wave Planning):
일정이 가까운 작업은 하위 수준까지 상세히 계획, 먼 미래의 작업은 상위수준만 기획하는 반복적계획 기법(도구)
원가/비용관리(cost management)
소요되는 자원으로 비용을 환산하고 프로젝트 일정에 따른 비용지출 계획인 원가기준선을 작성하여 이에 맞게 통제하는 활동
QA의 기준은 고객이 요구하는 품질! 개발자가 원하는 품질이 아님. 상대적으로 다르므로 무조건 기준은 고객의 요구사항
BigQ - 만드는 사람관점에서의 Quality
SmallQ - 고객관점에서의 Quality. 사용하는 사람의 관점에서 보는 퀼리티
►인적자원 :스킬이 좋은 시니어급 개발자가 필요, 엔지니어들이 확보가 필요.
► 물적자원 : 책상,의자,프린터,용지 모두 사거나 빌리는 것 들 물적자원 통제하는 것이 포함됨
► 실무담당자는 이걸 해야하는지 말아야하는지 결정하기가 어려움
► 보고해야하는 당사자, 결정해야 하는 당사자가 누구인지에 따라 차트를 만들어서 공유
►리스크 관리는 유기적으로 이루어져야한다. 리스크가 발생하기 전까지는 리스크, 발생하면 이슈로 관리한다.
► 조달관리:필요한 물건을 구매할때의 프로세스를 관리
► 공공프로젝트는 조달관리를 마음대로할 수가 없음, 금액의 크기에 따라 조달해야하는 방법이 다르므로 주의하여 진행해야함.
► 프로젝트에서 영향이 큰 사람들에 맞게 정보를 전달하는 과정,기법을 이해관계자 관리라고 함
► 프로젝트마다 영향도와 관심도에 따라서 어떤식으로 보고하고 어떻게 만족시킬 것인가를 결정하여 정보를 전달하고 관리해야함.
► 이해관계자 식별,수립,관리,통제하는 역할
► 왜하나 싶지만 제안서 뒷부분에 들어가는 부분이 모두 이 내용으로 채워져 있음.
► 이 프로젝트관리와 관련되어 있는 범위관리,일정관리,산출물은 적정한가? 보고를 주간보고,월간보고 언제 할건지, 중간보고, 종료보고가 언제 이루어져야 하는지가 중요함.
► 제안서 쓸 때 평가자들에게는 중요한 부분임.
► 블록체인플젝은 특히 산출물이 거기에 맞는 범위가 나와줘야함.
► 제안서는 법적인 효력을 가지고 있는 계약서나 마찬가지므로 kicoff계약시 제안서도 함께 들어감
► 기본적인 내용들을 쓰되 프로젝트와 관련있는 내용들을 체크하여 수정해야함
► 사고가 발생하면 몇시간안에 조치가 될 것인지 등, 유지보수 기간도 체크해야함.
📌 블록체인 기반 프로젝트 방법론
► 블록체인 자체는 속도가 매우매우 느리기 때문에 ! 기술적인 한계가 있음
► 저장공간의 크기가 매우 작음
► 기록이 삭제가 안됨 ► 블록체인에 개인정보,법적으로 일정시간이 지나면 삭제해야 하는 데이터는 블록체인에서 관리할 수 없음
► 정보의 저장을 구분해서 설계해야함
► 가스피,체계, 호출해주는 API도 블록체인간 상호운용이 안됨 ► 내것밖에 안됨..
► 실시간이 아니라는 가정하에 이 서비스를 구축해도 되는가? 를 프로젝트하는 동안 고민해봐야함!
► 이번에 내가 기획해야하는 서비스 모델에 맞게 블록체인 적용할 수 있는 부분, 내가 원하는 작업과 맞는 부분을 구현해야한다.
► 블록체인을 하겠다 = 믿지 않을 수 없는 신뢰시스템을 기반으로 다른 회사들과 정보를 공유하겠다는 뜻
► 구체적으로 어디에 사업을 어떻게 붙일 것인지 논의해야함
► IBM에서 나온 Design Thinking을 통한 아이디어 도출
► 블록체인 노드 구성, 합의알고리즘 선정이 필요
► 설계 검토를 해야하는 것 중 하나는 자체적인 보안규정, 법적규정이 있다면 확인해야함
► 인터페이스 설계 / 스마트컨트랙트 설계 필요
> 스마트컨트랙트는 블록체인 노드에 설치/ 앱에서 호출할 때 보통은 서버를 두고 용이하게 그 안에 있는 스마트 컨트랙트를 연결하므로 고려해서 설계한다.
► 테스트 및 운영 : 비즈니스 프로세스 검증, 성능테스트
(공공에서 가장 중요하게 보는 것! 동접 400tps를 맞춰서 운영해야하는 등 블록체인 신뢰성 평가 등 30% 이상이 성능테스트. 스마트 컨트랙트 호출로 블록체인 내부에서 동작하는 시간, dAPP에서 스마트컨트랙트- 기존의 레거시 - 데이터 저장 등 모든 시간을 통 틀어서 tps를 측정해서 성능으로 매김!), UI테스트(사용자가 편한가?) 등을 거쳐서 완성!
► 이걸 지켜가면서 하나? 100%는 아니지만 이런 순서로 일을 진행하게 되어 있음.
► 사용사례 선정: 레퍼런스, 없으면 유사한, 비슷한 분야에서 진행한 게 있는지 확인. 없으면 너무 힘들다...
( IBM에서 꽤 많은 레퍼런스를 만들어 공유해놓은 게 있음.참고!)
► 사용사례 목적에 따라 퍼블릭/ 프라이빗 블록체인 적용 여부를 판단하여 선택하면 됨!
► 별것 아닌 정보라고 하더라도 기업기밀이 될 수 있으므로 퍼블릭에 정보를 공유하는 것에 거부감이 있음.> 컨소시엄사용해야함
► 엔지니어들과도 컨센선스를 이뤄서 블록체인을 선택해야함.
► 블록체인을 활용할 때 고려해야할 5가지: 속도, 거래비용(gasfee),개방성, 확장성, Decentralized trust
► 프라이빗,컨소시엄은 속도나 확장성을 위해 개방성을 어느정도 포기하고 그럼에도 불구하고 블록체인이 해주는 chaining data에 대한 신뢰성이 어느정도 확보되면 되는 상황에 선정할 수 있다.
► 자율적인 융합 서비스를 제공하는 인프라 기술!
► 스마트워치, 스마트 티비, 각종 센서들 등
► 실제로 인터넷에 접속할 수 있는 IoT device는 그렇게 많지 않음... > 일단 인프라가 구축되어야하고 비용이 매우 비싸진다.
► 원론적으로 인터넷이 안되는 얘도 있음.
> middel ware라고하는 중개서버가 있어서 로컬에 정보를 저장하게 해서 이걸 읽어서 블록체인에 정보를 쏴야하는 경우도 있음
►블록체인에서 만들어진 가치가 타인에게 전달되면서 신뢰성이 보장되는 기술
► 블록체인 밖에서 정보를 수집해서 가지고 들어오게 만들어주는 middle ware가 필요하게 됨 > 블록체인 오라클이라고 함
► IoT device를 사용하게되면 blockchain oracle이 반드시 필요하게 됨!
► 밖에서 들여오는 데이터는 어떻게 신뢰할 수 있는가? !
► 웹에서 크롤링한 정보, 센서에서 가져오는 정보에 대한 신뢰성을 보장할 수 있는 방안을 만들어야함,
► IoT device에서 얻은 정보를 블록체인에 직접 전달하기 어려움... 커스터마이징된 device를 비용을 들여서 만들어야함.
► 하드웨어 오라클 문제: 센서에서 수집한 데이터를 '인가된' 디바이스에서 나오는 정보만 저장할 수 있도록 하는 등 요건 필요함.
► 소프트웨어 오라클 문제 > 똑같은게 많은 걸 믿고 블록체인에 저장 등
► 블록체인의 사이즈는 제한되어 있음
► 데이터를 IPFS에 저장하면 이 저장된 주소값을 반환(컨텐츠의 해시값) > 이걸 받아서
► 암호화가 필요한 경우 전처리 > IPFS에 저장 > 해시값을 반환받아서 이 정보를 기반으로 블록체인에 해시값을 저장
> 나중에 컨텐츠 조회시 해당 컨텐츠의 해시값을 조회 > 이 해시값을 주소로가지는 IPFS데이터를 받음> IPFS에 있으면 삭제도 가능
► IoT device 를 렌트해주고 비용을 받는 구조
► Airbnb모델 처럼 가상화폐로 결제하고 결제한 사람에게 그 기간 동안에만 사용가능한 스마트락의 패스워드를 제공하여 이용가능
► 생산에 특화되어 있는 IIoT
► 생산을위한 액팅까지 포함되어 있음
► IoT 기반의 노드를 만들어서 블록체인 네트워크에 참여하는 구조를 고안
► 인가된 단말만 정보를 등록할 수 있게 하고 싶다? > 정보등록시점에 단말의 등록여부를 확인해야함
► 지속적으로 살아 있는지 등을 확인해야함
► IoT 디바이스가 배터리가 없거나 고장나있으면 안됨! > 해당 기기에 대한 상태정보를 관리할 수 있는 표준 프로토콜
► 서버에 단말을 등록, 현재 IoT device 상태를 모니터링하고 특정 단말의 앱을 재설치/펌웨어 업그레이드 등의 명령을 내리게 해줌
► IoT와 단말을 연계하면 이런 내용부분을 고려해서 제안해야함.
블록체인에서 만든것을 다른 곳에서 확인해야 하는 경우가 많음.
► 데이터가 위변조 되지 않았다는 걸 검증하고자 하는 곳에 증명을 해줘야함. 내가 정보를 제공하고 검증자가 직접 확인할 수 있게해야 신뢰성이높음. > 이 때 QR코드를 가장 많이 사용함( e.g coov 백신예방접종 application에서 QR로 만들어서 신원확인,백신접종확인)
► QR코드안에 악성앱,코드가 실행되도록 만들어 공격하는 행위
► 어느정도는 서버에서 확인할 수 있도록 business process에 포함해서 QR코드에 많은 데이터를 넣지 않도록 신경써야함.
► 서버까지 가는건 아니지만 블록체인과 연계하기도 함
► 옷에 달린 태그 - 문앞에서 reader가 태그를 읽고 알람이 울리도록 함
► 공장에서 재고관리할때도 사용. 박스에 칩,QR코드를 활용해 재고관리에 사용
► 스마트 공장을 블록체인에 연계할 때 스캐너를 서버,블록체인에 연계하여 붙이는 것도 가능
► 만들 때 부터 보안을 고려해서 만들어야함
📌 디지털 트윈
►정보를 서버에서 전달하는 과정에서 블록체인에 정보를 저장해놓으면 신뢰도가 올라간다.
► 기존에서는 회사에서 서버,네트워크 망을 만들고 설치했는데 AWS,azure에서 사용시간,월단위,사용량 단위로 페이를 내고 사용하기
► IasS, PasS,SasS 로 나뉨.
► Infra: 서버,인프라를 빌림
► Platform: 개발하는 환경
► Software: 시스템을 빌려쓰는 시스템
► 어떻게 아키텍쳐를 구성할지 이정도는 설계할 줄 알아야함!
► 흐름도, IT 중심으로 그려주는게 좋다.. > 참여자, 누가 이용을 할 건지, 블록체인에 어떤 정보가 들어갈 건지 DID 기반으로 확인
► 나으.. 심복이되는 엔지니어를 만들어서 가능성을 타진해보고 미팅하기!
►BaaS(Blockchain as a Service)
: 사용한 만큼 사용하는 blockchain azureservice -> 쉽게 클라우드에 블록체인을 세팅하게 해주는 서비스
►다양한 기관들과도 연동되므로 통합테스트, 서비스 테스트를 잘 해야함
► 시계열로 저장되어있으므로 데이터 감사 추적으로 활용하기 좋다
► 성숙한 기술이 아니므로 시간이 많이 걸린다는 점 꼭 고려하기!
► 완벽한 솔루션이 아님. 사람이 만들어서 배포하는 것이므로 문제가 많다.
► 로드맵 만들고 발표했지만 개발 안된 것도 아직도 많으므로 주의!
► 안되는 것은 꼭 감내하기!
► 스마트 컨트랙트 완벽하지 않다. 내 주변의 개발자가 만든다.
► 거버넌스,규제,규정을 만드는 건 이해관계가 얽혀있는 다른 회사들과 만드는 것이 쉽지 않음.
► 평가하는 과정 중에 도입효과가 없어서 떨어지는 경우가 많으므로 사전에 파악해야함.
► e.g 얼마나 깨끗하게되어있고 공정이 얼마나 깨끗했는지를 보고로 남기는 기록이 필요하다면 >
정보를 투명하게 공유하고 하이퍼렛저를 활용해서 필요한 사람들에게만 정보를 노출, 시스템구축에 활용하면 좋음.
► 스마트컨트랙트에 개인정보를 저장? > 문제생겼을 때 누가 책임을 져야하는가?
► 블록체인 자체가 모든 IT기술을 총 망라하고 있기 때문에 도입하기가 어려우므로 프로세스를 통합해서 생산성을 향상시킬 수 있는지 중요
► 회사에서 보는 기밀정보는 우리와 다름.
► 테스트하는 정보도 기밀정보될 수 있으므로 이런 정보가 블록체인에 저장되도 괜찮은지를 체크받아야함
► 의료 > 윤리위원회를 열어서 확인받고 시작해야함.
► 프로세스가 시간이 단축되고 업무가 간편해지는지를 봐야함!
► 업무시간,마찰을 줄일 수 있다면 시도해볼 만 하다.
► 퍼블릭인 경우에는 키 관리하는 부분 조심. 개인키 잃어버리면 복구가 안됨.
► 허가받은 특정 노드만 참여할 수 있는 블록체인 네트워크.데이터공유되는 부분에 대해서 합의를 잘 해야 진행할 수 있다.
'Web3' 카테고리의 다른 글
블록체인 서비스기획 8주차 - 1일 수업 노트 (1) | 2023.08.22 |
---|---|
블록체인 서비스기획 7주차 - 4일 수업 노트 (0) | 2023.08.18 |
블록체인 서비스기획 7주차 - 2일 수업 노트 (0) | 2023.08.16 |
블록체인 서비스기획 7주차 - 1일 수업 노트 (2) | 2023.08.14 |
블록체인 서비스기획 6주차 - 4일 수업 노트 (0) | 2023.08.10 |