뒷마당 채석장: 바위를 데이터로 변환하기

Source: Dev.to

최근 또 한 차례의 기술 업계 정리해고가 산업 전반에 퍼졌고, 나는 그 속에 잡힌 사람 중 하나였다.
기술 분야에서 어느 정도 기간 동안 일해 본 사람이라면 그 뒤따르는 일과를 잘 알 것이다: 이력서를 업데이트하고, 인맥에 연락을 취하고, 구인 게시판을 스크롤하며, 현재 시장이 열광하고 있는 기술과 조용히 사라져 가고 있는 기술을 파악하려고 애쓴다.

그러한 사이클을 며칠 반복한 뒤, 나는 노트북 앞보다 밖에서 보내는 시간이 더 많아졌다. 어느 오후, 마당을 거닐다가 흥미로운 점을 발견했다: 우리 뒷마당에는 놀라울 정도로 방대한 데이터셋이 존재한다.

예상치 못한 데이터셋

내 뒷마당은 온갖 모양과 크기의 바위들로 가득합니다:

• 몇몇은 완두콩 크기입니다.
• 다른 것들은 대략 자동차 엔진 정도의 크기입니다.
• 몇 개는 “손수레 사용 권장”과 “아마도 중장비가 필요할 정도” 사이의 불편한 범위에 해당합니다.

당연히, 나는 큰 바위 무더기를 바라볼 때 많은 사람들이 결국 떠올리는 생각과 같은 생각을 했습니다: 아마도 이걸 팔 수 있겠군. 도로 근처에 작은 가판대를 놓고, 크기별로 몇 개의 더미를 정리하고, “조경용 바위”라고 적힌 표지판을 걸어두는 식이죠. 이것이 벤처‑지원 스타트업은 아니지만, 더 기이한 부업도 존재해 왔습니다.

불행히도, 엔지니어들에게는 잘 알려진 약점이 있습니다: 우리는 거의 간단하게 일을 하지 않거든요. 내가 바위를 팔 생각이라면, 단순히 테이블 위에 쌓아두는 것이 아니라 시스템을 구축하려고 했습니다.

From Rocks to Records

The moment you start thinking about the rocks as inventory, a familiar set of questions appears:

• How many rocks are there?
• What kinds?
• Which ones are small decorative stones and which ones fall firmly into what I’ve started calling Engine Block Class?

Like many real‑world datasets, this one has significant variability. Some objects are a few grams; others weigh enough to require careful lifting technique and a brief internal conversation about life choices. At a glance, the dataset looks chaotic, but underneath the chaos are patterns: different sizes, shapes, colors, and geological types. Some rocks are smooth river stones; others are jagged fragments that look like they escaped from a small landslide.

If you squint a little, you start to see the outlines of something familiar to anyone who works with data systems—a collection of physical objects that could be represented as structured records.

디지털 트윈 설계

이론적으로 바위 판매는 간단합니다:

1. 바위를 수집합니다.
2. 그것들을 한 무더기로 쌓습니다.
3. 누군가 차를 멈추고 조경 자재가 필요하다고 결정하기를 기다립니다.

하지만 이를 엔지니어링 관점에서 생각하기 시작하면 질문이 늘어납니다:

• 각 바위마다 식별자를 부여해야 할까요?
• 사진을 포함해야 할까요?
• 시스템이 무게나 치수를 추적해야 할까요?
• 분류는 어떻게 할까요? (Pebble Class, Wheelbarrow Class, Engine Block Class 등)

개념적으로 각 바위에 대한 레코드는 다음과 같이 보일 수 있습니다:

rock_id:        # unique identifier
weight:        # in grams or kilograms
dimensions:   # length × width × height
color:         # descriptive or hex code
rock_type:     # e.g., river stone, basalt, limestone
location_found:# GPS coordinates or yard zone
status:        # e.g., in stock, sold, reserved

마당에 있는 각 바위는 디지털 객체—물리적 세계에 존재하는 무언가를 나타내는 구조화된 레코드—가 됩니다. 즉, 각 바위는 이제 디지털 트윈을 갖게 되는 것입니다. 조경용 돌이라는 맥락에서는 다소 터무니없게 들릴 수 있지만, 이 아이디어는 놀라울 정도로 강력합니다.

많은 산업 분야에서 조직들은 동일한 문제에 직면합니다: 복잡한 물리적 현실을 구조화된 디지털 시스템과 연결하는 일. 제조업체는 기계 부품을 추적하고, 박물관은 유물을 카탈로그화하며, 농부는 작물을 관리하고, 물류 회사는 창고를 오가는 재고를 추적합니다. 각각의 경우 물리적 객체가 세계 어딘가에 존재하고, 우리는 이를 소프트웨어 시스템이 이해할 수 있는 방식으로 표현하고자 합니다.

뒷마당 채석장 프로젝트

부분적으로는 농담으로, 그리고 부분적으로는 프로젝트의 정신을 포착했기 때문에 이 작업을 뒷마당 채석장이라고 이름 붙였습니다. 일상적인 관찰에서 시작된 것이 데이터 모델링, 객체 카탈로그화, 시스템 설계에 대한 작은 실험으로 발전했습니다.

데이터셋은 작을 수 있고, 객체는 바위일 수 있지만, 그 근본적인 질문들은 놀라울 정도로 풍부합니다:

• 물리적 객체를 소프트웨어에서 어떻게 표현할까요?
• 그들에 대한 정보를 어떻게 포착할까요?
• 결과 데이터를 어떻게 검색하고 조직할까요?
• 객체 수가 몇 십 개에서 수천 개, 혹은 수백만 개로 늘어날 때 이러한 시스템은 어떻게 확장될까요?

다음 단계

이번 시리즈의 다음 몇 게시물에서는 Backyard Quarry를 중심으로 작은 시스템을 구축하면서 위 질문들을 탐구할 것입니다. 다룰 주제는 다음과 같습니다:

• 물리적 객체를 위한 스키마 설계
• 이미지와 측정값 캡처
• 포토그래메트리를 이용한 3D 모델 생성
• 데이터 수집 파이프라인 구축
• 데이터셋 인덱싱 및 검색

모두 간단한 암석 컬렉션에서 시작합니다.

결론

세상에는 복잡한 엔지니어링 문제들이 부족하지 않다.
때로는 그것들을 탐구하기에 가장 좋은 장소가 더 단순한 곳일 수 있다—예를 들어 뒷마당에 있는 바위 더미와 같은.
그리고 만약 뒷마당 채석장에 대한 정밀히 문서화된 표본이 필요하다면, 현재 재고가 있다(하지만 배송비가 그 바위 자체의 가치보다 더 클 수도 있다).