푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 915편 · 23 / 92 페이지)
-
재무제표 없이 20년 경영전략을 읽는 법 — ㈜에이티맥스
무슨 문제를 풀려고 했나
-
전술을 가르치지 않아도 전투를 배운다: 마린 컨트롤 실험에서 본 강화학습의 구조
영상에서 던지는 질문
-
React 의 상태와 'AI 준비 완료' 상태 — 어디까지 같은 문제이고, 어디서 부호가 뒤집히는가
프론트엔드에서 “상태 관리”라고 부르는 것과, 데이터·에이전트 쪽에서 “목적성과 품질성을 통과한 상태”라고 부르는 것은 같은 단어를 쓴다. 우연이 아니다. 둘 다 값이 아니라 술어를 다루고, 그 술어가 인자를 하나 더 받는다는 것도 같다.
-
백엔드 BigDecimal 을 프론트에 내릴 때 — 정규식 포맷터는 무엇을 지키고 무엇을 못 지키는가
정산 코드베이스의 규칙 하나는 이렇게 적혀 있다. “JSON 직렬화 시 금액은 십진 문자열로 다루고, JS 쪽에서
Number()변환을 제안하지 마라.” 이 한 줄을 지키려고 프론트에 정규식 기반 포맷터를 두게 된다. 이 글은 그 정규식이 정확히 무엇을 벌어주는지를 실측으로 가른다. -
공공데이터와 DART로 온톨로지를 설계하면 — 표준화된 것은 이름과 분류이지, 개체가 아니다
오늘 이 블로그에 온톨로지 글이 다섯 편 올라갔다. 어휘와 규칙을 나눈 글, 표현수준 스펙트럼을 다룬 글, 도메인 온톨로지와 구조 온톨로지를 여섯 렌즈로 쪼갠 글, 그래프와 벡터DB가 각각 무엇을 포기하는지 비교한 글, 그리고 가용성·탐색성·신뢰성·기계판독성 네 축이 사실은 사슬이라고 주장한 글.
-
도메인 온톨로지는 언제 '쓸만해지는가' — 정의·문제·가치·이력, 그리고 한 줄의 판정
앞 글에서 데이터의 준비도를
ready(D, P, t)라는 술어로 적었다. 데이터셋 \(D\) 가 목적 \(P\) 에 대해 시점 \(t\) 에 승인된 상태인가. 온톨로지도 정확히 같은 꼴을 갖는다. -
IT 개발 노동자의 위촉직·계약직·정규직: 전문성·비즈니스모델·성과·정책의 하브루타
질문: 고용형태가 전문성과 성과를 결정하는가?
-
온톨로지의 표현수준 — 목적이 스펙트럼의 어디에 세울지를 정한다
“우리 온톨로지는 아직 부족하다”는 말을 자주 듣는다. 그런데 부족하다는 게 무슨 뜻이냐고 되물으면 대답이 갈린다. 어휘가 적다는 뜻인가, 계층이 얕다는 뜻인가, 아니면 기계가 모순을 스스로 못 잡아낸다는 뜻인가. 이 셋은 전혀 다른 결핍이고, 채우는 방법도 다르다. “제대로 된 온톨로지”라는 단일한 목표는 없다. 목적마다 필요한 표현수준이 다르고, 표현수준을 올릴수록 모델링 비용과 추론 비용이 같이 오른다. 이 글은 그 스펙트럼이 어디서 왔고, 층위마다 무엇을 얻고 무엇을 지불하는지, 그래서 목적이 어떻게 층위를 결정하는지를 정리한다.
-
도메인 온톨로지와 구조 온톨로지 — 이름을 고정하는 일과 경계를 고정하는 일
온톨로지를 한 덩어리로 다루면 논의가 엉킨다. 실제로는 서로 다른 것을 고정하는 두 층이고, 무너지는 방식도 다르다.
-
온톨로지 구축, 어휘와 그 어휘가 지켜야 할 규칙으로 나눠보면
온톨로지를 “지식을 표현하는 체계”라고 정의하면 구축 방법이 안 보인다. 뭘 먼저 만들어야 하는지, 뭐가 끝났다는 신호인지 이 정의에서는 아무것도 안 나온다.