우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›토스›데이터 엔지니어›질문 상세
    問
    토토스데이터 엔지니어직무 역량2026년 출제

    온톨로지 및 지식 그래프 구축에 대한 경험이 있다면, 어떤 구조로 데이터를 모델링했는지 설명해줄 수 있나요?

    답변 미리보기

    대학원 연구실에서 생명과학 용어 온톨로지를 구축하는 소규모 프로젝트에 참여했습니다. 처음에는 개념들을 그냥 트리 구조로 나열하면 된다고 생각했는데, 실제로…

    예상 답변 시간
    90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    구조를 어떻게 설계했는가?
    데이터 모델링의 구조적 접근 방식에 대한 흔적이 답에 있어야 합니다. 없으면 면접관이 '어떤 기준으로 설계했나요?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    온톨로지 경험을 설명할 수 있는가?
    온톨로지 및 지식 그래프와 관련된 경험의 구체적인 사례가 답에 있어야 합니다. 없으면 면접관이 '구체적인 예시를 들어주세요'라고 질문하는 자리가 자주 보입니다.
    語
    03
    데이터의 관계를 어떻게 정의했는가?
    구조 내 데이터 간의 관계 설정에 대한 흔적이 답에 있어야 합니다. 없으면 면접관이 '관계 정의는 어떻게 했나요?'를 추가로 묻는 경우가 빈번하게 보입니다.
    本
    04
    모델링 도구를 아는가?
    데이터 모델링에 사용한 도구나 기술에 대한 언급이 답에 있어야 합니다. 없으면 면접관이 '어떤 도구를 사용했나요?'를 묻는 자리가 자주 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    토스 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    온톨로지 노드·엣지 설계를 실무 프로젝트에서 직접 정의한 경험 중심으로 푸는 결약 86초지식 그래프 스키마를 점진적으로 확장하며 생긴 설계 충돌을 해결한 경험 중심으로 푸는 결약 88초캡스톤 프로젝트에서 RDF 트리플 구조를 처음 적용한 시행착오 중심으로 푸는 결약 84초
    예시 답변 1
    약 86초

    온톨로지 노드·엣지 설계를 실무 프로젝트에서 직접 정의한 경험 중심으로 푸는 결

    대학원 연구실에서 생명과학 용어 온톨로지를 구축하는 소규모 프로젝트에 참여했습니다. 처음에는 개념들을 그냥 트리 구조로 나열하면 된다고 생각했는데, 실제로 해보니 상위 개념과 하위 개념 사이의 관계를 어떻게 정의할지가 훨씬 어려웠습니다. 예를 들어 '치료법'이라는 노드 아래에 '약물치료'와 '수술'을 두는 게 맞는지, 아니면 각각 독립 노드로 둬야 하는지를 놓고 교수님, 팀원 2명과 두 시간 넘게 논의했습니다. 저는 결국 관계 레이블을 먼저 목록화하는 방식을 제안했습니다.

    is-a, part-of, causes 같은 관계 유형을 먼저 정해두고, 그 유형에 맞는 노드 쌍만 엣지로 연결하도록 규칙을 만들었습니다. 초반에 규칙 없이 연결하다가 순환 참조가 생겨 추론이 깨지는 오류를 경험한 적이 있어서였습니다. 완성 후엔 Protégé로 구조를 시각화해 논리 오류를 잡았고, 검증 쿼리로 고아 노드 12개를 찾아 수정했습니다. 지금도 개념 모델을 짤 때 관계 유형 목록을 먼저 쓰는 습관이 남아 있습니다.

    이 결의 특징
    온톨로지 구축에서 관계 유형을 먼저 목록화해 순환 참조 문제를 방지한 흔적이 있습니다.
    이 결이 통하는 자리
    규칙 없이 연결하다 순환 참조로 추론이 깨졌던 경험에서 관계 유형 목록의 필요성을 얻은 관점이 답에 담겨 있을 때 면접관의 신뢰가 쌓이는 자리를 자주 봅니다.
    예시 답변 2
    약 88초

    지식 그래프 스키마를 점진적으로 확장하며 생긴 설계 충돌을 해결한 경험 중심으로 푸는 결

    인턴 기간에 사내 제품 지식 그래프를 유지보수하는 일을 맡았습니다. 이미 노드 수천 개짜리 그래프가 있는 상태였는데, 새 제품 카테고리를 추가할 때마다 기존 스키마와 충돌이 났습니다. 처음엔 그냥 새 노드를 이어붙였는데, 나중에 보니 같은 의미인데 레이블이 다른 노드가 7쌍이나 생겨 있었습니다. 그 경험이 좀 창피했습니다. 이후 저는 새 개념을 추가하기 전에 기존 노드와의 유사도를 먼저 체크하는 단계를 추가했습니다. 단순히 이름 문자열 비교였지만, 중복 노드 생성을 절반 가까이 줄였습니다. 또 엔티티 타입을 세 계층(Domain / Concept / Instance)으로 고정해두고, 신규 노드를 추가할 때 타입을 먼저 결정하게 했습니다. 퇴근 직전에 급하게 노드를 넣다가 타입을 잘못 달아 추론 결과가 이상하게 나온 적이 있었는데, 그 사고가 이 규칙을 만든 계기였습니다. 완벽한 해결은 아니었지만, 그 이후 신규 충돌은 눈에 띄게 줄었습니다.

    이 결의 특징
    같은 의미의 노드가 중복 생성된 문제를 유사도 체크와 타입 계층 고정으로 개선한 흔적이 있습니다.
    이 결이 통하는 자리
    타입을 잘못 달아 추론 결과가 이상해진 사고가 규칙을 만든 계기라는 관점이 구체적으로 담긴 답에서 통합니다.
    예시 답변 3
    약 84초

    캡스톤 프로젝트에서 RDF 트리플 구조를 처음 적용한 시행착오 중심으로 푸는 결

    캡스톤 프로젝트에서 영화 정보 지식 그래프를 만드는 팀에서 데이터 모델링을 맡았습니다. 처음에는 RDF 트리플(주어-서술어-목적어) 구조가 간단해 보여서 금방 할 수 있을 것 같았습니다. 그런데 막상 '감독이 영화를 만들었다'와 '배우가 영화에 출연했다'를 어떻게 다르게 표현할지부터 막혔습니다. 둘 다 '연관됨'으로 뭉뚱그렸다가 나중에 쿼리할 때 원하는 결과가 안 나와 이틀을 날렸습니다. 그 실수 덕분에 서술어(predicate) 어휘를 먼저 확정하는 게 핵심이라는 걸 배웠습니다.

    directed_by, acted_in, released_in 같이 의미가 좁은 서술어를 미리 목록으로 정하고, 그 목록 밖의 서술어는 팀원 승인 없이 못 쓰게 했습니다. 데이터는 영화 약 800편, 노드 2,400여 개 규모였고, 이 방식으로 이후 쿼리 정확도가 확연히 개선됐습니다. 발표 때 교수님이 서술어 설계가 탄탄하다고 해주셨는데, 그 칭찬보다 실수를 통해 배운 이유가 더 오래 기억에 남습니다.

    이 결의 특징
    서술어를 뭉뚱그렸다가 쿼리 결과가 이상해져 이틀을 날린 실패를 감추지 않은 흔적이 있습니다.
    이 결이 통하는 자리
    서술어 어휘를 먼저 확정하는 것이 핵심이라는 관점이 답에 담겨 있을 때 면접관의 신뢰가 쌓이는 결이 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹해당 모델링 과정에서 어려움은 없었나요?
    貳모델링을 위한 도구나 기술은 어떤 것을 사용했나요?
    參다른 팀원들과의 협업 과정은 어땠나요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 토스 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    CJ올리브영 · 데이터 엔지니어
    데이터 모델링 경험에 대해 구체적으로 설명해 주세요. 어떤 프로젝트에서 어떤 방식으로 데이터 모델을 설계하셨나요?
    이 질문 보기
    쿠팡 · 데이터 사이언티스트
    대량의 데이터셋을 다룰 때, 어떤 방식으로 특징을 추출하고 모델을 구축하나요?
    이 질문 보기
    토스 · 데이터 분석가
    데이터 모델링에서 주요 개념을 어떻게 정의하고 데이터 구조를 디자인할 때 고려하는 요소는 무엇인가요?
    이 질문 보기
    토스 · 데이터·AI 일반
    데이터 모델링 과정에서 경험한 복잡한 데이터 구조를 단순화한 사례를 공유해 주실 수 있나요?
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 토스 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기