엣지 컴퓨팅은 아직 새로운 개념이고, PoC를 통해 도입을 고려하고 있는 사용자가 많을 것으로 생각됩니다.그건 그렇고, PoC라는 단어를 들어 본 적이 있습니까?인터넷으로 검색하면 나오는데 일반인들에게는 익숙하지 않은 단어일 수 있습니다.그러나 제품 개발 및 시스템 개발 분야에서는 향후 활용 기회가 늘어날 것으로 예상됩니다.이 섹션에서는 PoC의 정의, PoC와 프로토타입의 차이, PoC의 필요성과 장점, PoC 검증 작업의 흐름에 대해 설명합니다.
PoC란 무엇입니까?
PoC는 개념 증명의 약자이며 일본어로 “개념 증명”으로 번역됩니다.신제품 또는 시스템 프로젝트를 시작하기 전에 제품 또는 시스템의 효율성을 확인합니다.예를 들어 신제품을 개발할 때는 본격적인 판매 전에 판매를 테스트하고 고객을 모니터링하여 실제 판매 여부를 확인합니다.또는 시스템 개발에서는 최소 구현 및 테스트 작업을 의미합니다.
PoC와 지금까지의 검증 작업의 차이점
POC의 아이디어 중에는 실제로 만들어서 사용하자는 아이디어 자체가 오래전부터 있었던 제품 개발에서는 '시험 생산'을, 시스템 개발에서는 '시제품'을 들 수 있습니다.이 “프로토타입”을 통해 프로젝트의 진행 상황과 개발 중인 결함을 확인하고 있습니다.개발 프로젝트의 흐름은 “컨셉 → 기획 → 개발 → 테스트 → 운영 및 판매”의 흐름으로 진행되지만 “프로토 타이핑”과 “프로토 타입”은 개발 단계 또는 테스트 단계에서 언제든지 수행되었습니다.
반면 PoC는 구상 단계 바로 옆, 즉 구상 단계와 계획 단계 사이에 있는 경우가 많습니다.또한 프로토타입은 개발 솜씨를 확인하는 입장이지만 PoC의 결과에 따라 개발 정책이 크게 달라질 수 있으며 경우에 따라 개발을 포기할 수도 있습니다.즉, 본격적인 개발 프로젝트가 진행되기 전에 개념 설계가 적절한지 검증하는 것입니다.
PoC의 필요성과 이점
최근 몇 년간 고객의 요구가 다양해지고 제품 수명 주기가 짧아지면서 개발의 불확실성이 커졌습니다.또한 시스템 개발에서는 IoT, 인공지능 등 새로운 분야에 대한 과제가 많은데, 여기서도 불확실성이 커질 것이라고 할 수 있습니다.이해하기 쉽게 말하자면, 이러한 불확실성으로 인해 개발 목적을 잃을 위험이 높습니다.
지금까지의 개발 프로세스에서는 이러한 리스크를 개념 단계에서 예측하고 사전에 개발에 접목해 왔습니다.이 경우 개념 단계에서 위험을 예측하는 것이 매우 중요합니다.그러나 위에서 언급한 변경 사항으로 인해 점점 더 예측할 수 없는 위험이 발생하고 있습니다.개발이 진행된 후 이러한 위험이 구체화되면 해당 시점까지의 모든 개발 프로세스가 낭비될 수 있습니다.
위험을 조기에 이해하면 이러한 문제를 피할 수 있습니다.따라서 컨셉 시 소규모로 제품이나 시스템을 만들어 고객이 실제로 사용하게 할 수 있습니다.판매 및 결함을 통합하고 개념을 수정한 다음 본격적인 개발을 수행하면 모든 것이 잘못될 위험이 줄어듭니다.
또한 이러한 PoC는 개념을 개선하여 개발 정책이 더 명확해지고 프로젝트가 순조롭게 진행될 것입니다.즉, POC는 본격적인 개발 이전에 사용자의 요구를 더 잘 충족하도록 개념을 수정하고 소규모 테스트 판매 및 테스트 운영을 통해 사용자의 요구를 미리 파악하는 데 사용될 수 있습니다.
PoC의 예로는 인공 지능의 개발이 있습니다.여기서는 당분간 가장 중요한 인공 지능의 엔진 부분만 완성하고 사용자와 협력하여 학습을 다듬을 수 있습니다.이처럼 PoC 역시 본격적인 시스템 개발 이전에 사용자와 협력하면서 중요한 부분만 브러쉬업한다고 할 수 있습니다.
하지만 제품이나 시스템의 개념이 외부로 유출되고 최악의 경우 해당 정보를 입수하는 데 갈등이 생기는 단점이 있다는 점에 유의해야 합니다. 개념 단계에서 사용자로 하여금 사용하게 하기 위해서죠.
PoC 검증 플로우
PoC에는 여러 가지 장점이 있지만 무턱대고 가더라도 효과가 없습니다.효과적인 검증 흐름을 살펴보겠습니다.
- 효과/효용성 검증
먼저 대상 제품 또는 시스템이 달성하려는 목표가 사용자의 요구와 일치하는지 확인합니다.즉, 원하는 효과를 얻고 있는지 확인하십시오.예를 들어 신약의 임상시험에서는 안전한 신약 후보물질을 피험자에게 실제로 투여하여 의도한 효과가 있는지 확인합니다.판매되기 전에 판매되는 경우보다 훨씬 적은 수의 피험자를 대상으로 테스트되기 때문에 PoC에 해당합니다. - 기술적 타당성 검증
다음으로 이론적 이론이 아니라 개념이 실제로 실현 가능한지 여부를 검증할 것입니다.약간 놀라운 예로는 단편 영화가 있습니다.장편 영화를 만들기 전에 작은 작품을 만들어 필요한 기술적 과제를 해결할 수 있는지 확인하는 것이 목적입니다.PoC에서는 종종 기술적 타당성 검증이 효과/유용성 검증에 선행하는 경우가 많습니다.즉, 기술이 우선이지만 결과적으로 목표 요구 사항이 충족되는지 충분한 검증 없이 개발이 진행될 가능성이 있습니다.PoC는 원하는 효과와 이점을 얻을 수 있는 방법이라는 점을 알고 있어야 합니다. - 특이성에 대한 검증
그런 다음 컨셉에서 요구하는 사양 및 문제를 식별하고 구체적인지 확인하기 위한 검증을 수행합니다.이는 시장 조사 결과와 이를 실제로 사용해 본 사용자의 목소리를 모아 개발에 활용하겠다는 의미입니다.
위 검증 후 수정된 컨셉을 기반으로 컨셉, 프로토타입 제품, 시스템 등을 수정하여 사용자로 하여금 사용하게 하고 다시 검증할 예정입니다.이를 반복함으로써 “효과/효용”, “기술적 타당성”, “구체성”을 달성할 수 있는 개념을 다듬을 수 있습니다.다듬기가 완료되면 다음 계획 단계로 넘어갈 것입니다.
중요한 것은 사용자가 실제로 사용할 수 있도록 하는 것입니다.이렇게 하면 완제품이 사용자가 원하는 것과 거리가 멀어질 위험을 피할 수 있습니다.검증을 너무 많이 확장하지 않는 것도 중요합니다.이는 개념 수립에 필요한 작업 비용을 절감할 뿐만 아니라 개발 컨셉이 외부로 유출되는 것을 최대한 방지하는 위험 헤징으로 이어집니다.
PoC는 큰 장점이 있는 방법입니다.
컨셉 단계에서 사용자의 의견을 경청하는 PoC를 수행하면 컨셉 수정, 개발 위험 감소, 원활한 프로젝트 진행 등의 이점을 얻을 수 있습니다.하지만 검증의 규모와 횟수를 지나치게 늘리면 비용이 증가하고 개념이 외부로 유출될 위험이 있다는 점에 유의해야 합니다.
부차적인 이점으로는 PoC로 인해 개발을 포기하더라도 실제로 사용자 의견을 데이터로 수집할 수 있기 때문에 PoC 프로세스에서 얻은 지식이 낭비되지 않을 것입니다.다음 개발에 사용할 수 있습니다.그런 의미에서 PoC는 큰 장점이 있는 방법이라고 할 수 있습니다.
