추적성(Traceability)과 그 쓰임새
베터코드 인사이트의 시작
추적성(Traceability)이라는 개념이 있다. 위키피디아 정의를 보자.
Traceability is the capability to trace something. In some cases, it is interpreted as the ability to verify the history, location, or application of an item by means of documented recorded identification.
이력(역사), 위치, 항목의 사용 여부 등을 검증하는데 쓴다고 한다. 위키피디아 정의에서는 그 수단을 'documented recorded identification'으로 명시하고 있는데, 내가 추적성(Traceability)에 관심을 갖는 이유는 앱(응용 프로그램)이 남기는 흔적이 바로 그 'documented recorded identification'의 실체가 될 수 있다고 생각하기 때문이다.
추적성의 보편적인 쓰임새
내가 쓰려고 하는 곳은 잠시 제쳐두고, 위키피디아를 보면 범용적으로 어디서 쓰이나 확인할 수 있다.
Traceability is applicable to measurement, supply chain, software development, healthcare and security.
측정(measurement), 공급망 관리(supply chain), 소프트웨어 개발(software development), 헬스케어(healthcare), 보안(security) 등이다.
나는 기업 업무의 추적성에 초점을 두고 있는데, 앞서 언급한 대로 앱(응용 프로그램)이 남기는 디지털 흔적을 원료로 삼고 있는 탓에 소프트웨어 개발(software development)을 별도 분야로 두고 있는 위키피디아 정의는 다소 낡은 듯이 느껴진다.
여하튼 분야별 쓰임새를 더 훑어보기로 한다. 측정(measurement)은 응용 층의 관심사가 아니라 제외한다.
공급망 관리에서 추적성
공급망 관리에 대한 위키피디아 설명은 전체의 50%가 넘는다. 그만큼 널리 쓰인다고 추측해볼 수 있다. 재료(Materials), 물류(Logistics), 음식 가공(Food processing), Forest products(이건 우리말로 뭐라 하나?) 등으로 나눠져 있는데, 원재료를 이용해서 생산을 하거나 운반과 배송을 해야 하는 업태를 고려하면 태그나 바코드를 붙여 추적할 수 있어야 한다는 기본적인 필요성 정도는 어렵지 않게 공감할 수 있다. 음식 가공(Food processing)의 경우는 때를 놓치면 폐기를 해야 한다는 점이 다른 물류와 다르다는 사실을 예전에 마켓 컬리 개발자와 이야기하면서 배운 바 있는데, 그 내용도 떠올랐다.
특이하게 느낀 내용은 추적성 관점에서도 ESG 이슈가 언급된다는 점이다.
Traceability is increasingly becoming a core criterion for sustainability efforts related to supply chains wherein knowing the producer, workers and other links stands as a necessary factor that underlies credible claims of social, economic, or environmental impacts.
부품조달 과정에서도 윤리적으로나 환경 보전 관점에서 고려가 투명하게 추적될 수 있어야 한다는 맥락으로 이해했다.
기타 분야의 추적성
소프트웨어 개발(software development)은 외주 계약 개념의 개발 업태에 초점이 맞춰진 기록이다. 요구사항이 제대로 반영되어 있느냐를 추적하려는 용도다. 일회성 소프트웨어 개발이나 구매가 아니라 업무 현장에서 소프트웨어가 중요한 상황이 나의 관심사다.
이런 경우는 기업의 일상 업무가 소프트웨어를 많이 이용하고, 디지털 수단으로 고객을 응대하거나 앱이 매출을 일으키는데 기여하는 상황을 말한다. 이런 경우는 소프트웨어 Ongoing 설계가 필요한 상황이라고도 말할 수 있다. 이럴 때는 일회적으로 요구사항과 소프트웨어 구현을 대조하는 추적이 필요한 것이 아니라 소프트웨어가 매출 등의 활동에 어떤 공헌을 하느냐를 가시화할 필요가 있다. <공헌이익과는 다른 디지털화 이야기> 편에서 소개한 <프로젝트에서 제품으로>라는 책이 이를 다루고 있다.
헬스케어(healthcare), 보안(security)은 내 관심 밖이라 제외한다.
우리가 시도하는 추적성
나에게 있어서 추적성은 오래된 숙제다. 2019년에도 북경의 동료들과 해당 기능을 만들어 잘 활용한 바 있고, 그 이전에도 판매 공간과 물류 현장이 분산되어 있는 곳의 문제를 풀 때 핵심 개념이 추적성이라 할 수 있다.
그러나, 이번에는 추적성 개념에서 출발한 일이 아니었다. UX 개선을 하는 동료가 자신의 기획 의도가 제대로 반영이 되었는지 알고자 하는 바람직한 욕망에서 비롯되었다. 그리고 그 일을 도우려는 개발자가 있어 일이 성사되었는데, 그들이 하는 일을 들여다보니 역으로 추적성(Traceability)이 보였다.
나는 이들의 노력이 한 번으로 그치지 않고 해당 기능을 재사용할 수 있다는 가정을 가지고 파일럿을 시도 중이다. 파일럿이 성공하면 해당 기능을 Better Admin이라는 공개 소프트웨어의 기능으로 추가할 예정이다. 아래 그림은 그러한 아이디어를 동료들에게 설명한 스케치이다.
다른 이야기이지만 이 또한 맥락도의 하나라고 할 수 있다. <도메인 모델링에서 맥락은 왜 필요한가?> 편에서 설명한 대로 맥락은 결국 소통(구두 대화뿐 아니라 그림 자체로 메시지를 전달하는 일 포함)을 위한 이해의 배경을 설정하는 일이기 때문이다.
