brunch

빨래를 개다가 떠오른 식별성과 태그, 라벨

감히 시도하는 설계의 정석

by 안영회 습작

<생각을 나눠 요소를 만드는 일의 어려움>과 <객체 식별의 어려움에서 기인한 패턴들>을 쓰고 나서는 적어도 식별(識別)에 대해서는 더 이상 할 말이 없을 줄 알았습니다.


두 아들 속옷을 개다가 떠오른 식별성

그런데 무려 작년 9월 두 아들의 속옷 사진과 함께 메모 한 내용을 발견했습니다.

두 아들의 속옷,
경험적으로 익숙해지기 전에는 구분이 쉽지 않음
매번 크기를 재어 봐야 할 수도 있고


마치 Java의 Object 클래스에 있는 equals 메소드 구현에 상응하는 내용인데, 어떻게 구현해야 할지 상상해 보면 잘 떠오르지 않았습니다. 아내는 구분을 할 수 있는데 제가 못하는 것이죠. 이미 살 때 어떤 기준이 있었던 것일까요? 머신러닝으로 상당한 데이터를 넣는다면 지식화가 가능할까요? 이 메모를 두고 식별이라고 다시 분류해 두었습니다.


그런데 다시 생각해 보니 특정 객체가 내가 인지하는 바로 그것인지를 알아보는 식별은 아니고 둘을 구분하는 능력에 대한 것이니 식별력(識別力) 혹은 변별력(辨別力)의 문제였습니다.


속옷의 소유자를 바코드로 구분하지는 않지!?

비슷한 문제를 다뤄 본 제 경험으로 나아가 보면, 빠른 식별 혹은 식별성 향상을 위해 바코드나 QR 코드를 활용하는 일을 떠올립니다. 요즘은 일반인들도 익숙합니다. 편의점이나 마트에 가서 줄을 서지 않기 위해 셀프 계산대에 가면 이들을 쓰니까요.

그런데, 제가 빨래를 갤 시점에는 바코드 같은 것이 필요했던 것은 아닙니다. 각 잡고 정확히 따지면 '누구 것이냐?'를 알려 주는 일종의 이름표 같은 것이 필요했던 것이죠. 제가 군대에 있을 때는 이를 위해 '주기'라는 것을 강제로 해야 했습니다. 속옷 모두에 이름이 쓰여 있었죠. 아이들 속옷에도 사이즈가 표기된 태그가 있기는 합니다. 하지만, 옷 안에 있어 보이지 않거나 간지럽다고 자르기도 하여 빠른 식별을 돕지는 못합니다.


태그tag와 라벨label 차이는 무엇인가?

생각이 이렇게 흐르자 다른 맥락에서도 살펴보게 됩니다. 생산업체들은 복잡한 태그는 숨기면서 상표나 브랜드 각인을 위한 라벨은 강조하거나 간판처럼 눈에 잘 띄게 합니다. 드러낸 라벨과 숨긴 태그 사이에 어떤 문화적 바탕이 있을까요? 혹시나 해서 사전을 찾아봅니다. 먼저 콜린스의 tag 풀이입니다.

A tag is a small piece of card or cloth which is attached to an object or person and has information about that object or person on it.

다음은 label입니다.

A label is a piece of paper or plastic that is attached to an object in order to give information about it.

재질만 다르고 둘 다 용도가 같은 물건이네요.


한편, 위키피디아 페이지 비교를 했더니 더 헷갈립니다. 용처가 다를 뿐 같은 말이고, 종종 섞어 쓰기도 한다는 의심이 들 정도네요.[1]

그래서, 어원적 차이까지 포함한 비교표를 퍼플렉시티로 만들었습니다.


새로운 연재: 감히 시도하는 설계의 정석

글을 채우고 나니 연재 제목과 안 어울리는 글로 시작을 하네요. 이 글은 <왜 도메인 이벤트와 이벤트 스토밍이 필요한가?> 이후 3개월 정도 쉬었던 '모델링'에 대한 새로운 연재입니다.


주석

[1] 더불어 소프트웨어 개발 분야에서 자주 듣거나 보는 두 단어의 전혀 다른 쓰임새가 눈에 띄기는 했습니다.

Tag (Facebook), a link in Facebook

Tag (metadata), a more flexible form of categories

Tag, an element in several markup languages

Revision tag, for a specific revision

Label, in machine learning, a desired output for a given input in a dataset


지난 어떻게 하면 모델링을 잘할 수 있을까? 연재

(36회 이후 링크만 표시합니다.)

36. 사건이라는 개념을 프로그래밍 이벤트로 응용하기

37. 프로그래밍에서 이벤트는 모듈화를 위해 도입한 개념

38. 사용자 경험과 연결되는 도메인 이벤트 설계 품질

39. 커피숍에서 우연히 만난 도메인 이벤트 대응 사례

40. 입차와 출차를 바탕으로 객체 설계의 꽃인 상태도 활용

41. 주요 비즈니스 상태에서 도메인 이벤트를 식별하기

42. 모델링에서 행위자를 뽑는 일은 시스템 맥락을 만드는 일

43. 비동기 호출과 이벤트 기반 프로그래밍의 연결

44. 객체의 작명과 속성 부여 과정이 경계를 만드는 일입니다

45. 실환경 검증의 중요성 그리고 액터와 사용자

46. if문을 실행할 수 있는 수준이라면 모두 액터다!

47. 종이를 웹 화면에 대입했더니 재미있게 머리가 굴러간다

48. 주차 정산 사례로 설명하는 느슨한 결합과 OCP 원칙

49. DDD 출현이 현대적인 도메인 모델링의 기준인가?

50. 모델링 요소는 프로그램의 쓸모를 뽑는 일종의 가설

51. 왜 도메인 이벤트와 이벤트 스토밍이 필요한가?

keyword
작가의 이전글멀티모달 토큰화에 대해 가볍게 듣기