티냅스
경력근거: 고객사의 AI 인프라 환경 분석 및 Runtime Trust Layer 연동 구조 설계
티냅스 FDE 공고는 고객사의 AI 인프라 환경을 분석해 Runtime Trust Layer 연동 구조를 설계하고 PoC 전 과정의 기술 설계와 결과 보고를 주도하며, 기술 제안서와 고객 기술 미팅을 직접 이끄는 사람을 뽑습니다. 고객사가 준 정책 요건서와 발화 로그를 대조해 확인 질문지를 만들어 미팅에 들고 들어가는 이 도구는 그 첫 구간을 그대로 재현하고, on-prem·private deployment 요구에 맞춰 로그를 밖으로 내보내지 않고 고객망 안에서 같은 명령으로 돌게 만듭니다. 이 포트폴리오가 보여주는 것은 지저분한 고객사 문서를 규칙으로 읽어 결함을 짚고 확인 질문으로 바꾸는 기술이며, 금융 규제 해석이나 0.2초 실시간 개입을 견디는 고객 인프라 운영 같은 도메인 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다.
운영 중인 AI 발화를 실시간으로 검사하고 위험을 감지하면 즉시 개입하는 Runtime Trust Layer 를 요구합니다. 그 층이 무엇을 걸러야 하는지는 고객 정책 요건에서 오므로, 요건과 실제 발화 로그를 대조해 규칙 공백을 먼저 메우는 도구가 바로 앞 단계에 붙습니다.
고객 AI 인프라를 분석해 연동 구조를 설계하고 PoC 를 실행한 뒤 그 경험을 재사용 가능한 제품 구조로 정리하는 FDE 를 요구합니다. 고객사 자료를 받아 확인 질문지로 정리하고 기술 미팅을 주도하는 흐름이 정면으로 정렬됩니다.
Cloud·Data·Security·AI 경험과 on-prem·API integration·private deployment, 금융권 엔터프라이즈 연동을 요구합니다. 로그를 밖으로 못 내보내는 고객망 안에서 같은 명령으로 도는 컨테이너 실행이 정렬됩니다.
고객사 정보보안팀이 건넨 AI 응답 정책 요건서 시트 추출본과 운영 AI 발화 로그 덤프 두 벌을 입력으로 받아, 조치 열이 비어 있는 요건·로그에 없는 채널을 가리키는 요건·같은 대상에 다른 조치를 지시하는 요건·자동 판정이 불가능한 문구·요건 어디에도 없는데 로그에는 실제로 나오는 위험 패턴을 규칙으로 찾아내, 담당자에게 물을 확인 질문지 md 파일과 요약 표를 명령 한 줄로 만드는 CLI입니다. 질문마다 요건 원문 인용과 발화 원문 인용, 영향 로그 건수, 연동 차단 여부를 붙이고, 담당자가 선택지를 고르면 그 답이 그대로 정책 규칙 초안이 되도록 빈칸을 설계합니다. 결함 유형 판정은 열 채움 여부·채널 대조·조치 충돌·패턴 매칭 같은 규칙이 결정하고, LLM 은 자연문 요건에서 규칙 후보 문구를 뽑고 질문 문장을 담당자가 읽기 쉽게 다듬는 보조만 맡습니다. 요건이 옳은지 그른지 판단하는 도구가 아니라, 그대로 규칙이 될 수 있는지만 가리는 도구입니다.
티냅스 FDE(고객사 파견, Runtime Trust Layer 연동 담당). 제1금융권 고객사에 들어가 정보보안팀에게서 응답 정책 요건서 엑셀과 운영 AI 발화 로그 덤프를 받아 놓고, 어느 요건이 그대로 규칙이 되고 어느 요건을 담당자에게 되물어야 하는지 두 파일을 번갈아 훑어 가려내다가 첫 기술 미팅 전날을 통째로 쓰는 사람입니다.
고객사 요건서와 발화 로그를 한 스키마로 읽고 결함 판정을 규칙에 맡기면, (a) 조치 누락·채널 미등록·요건 충돌·판정 불가 문구를 요건 원문 인용을 붙여 짚어 연동 착수를 막는 항목부터 물을 수 있고, (b) 요건 어디에도 없는데 로그에 실제로 나오는 위험 패턴을 발화 원문으로 제시해 요건서 자체의 공백을 드러내며, (c) 담당자가 선택지를 고른 질문지를 다시 넣으면 확정된 규칙 초안과 남은 질문만 남아 회차가 줄어듭니다.
정책 요건서 시트와 발화 로그 파일을 인자로 주고 명령을 한 줄 실행하면, 결함 유형별 확인 질문지 md 와 요약 표가 파일로 떨어지고 터미널에는 유형별 건수와 연동 차단 항목이 찍히는 도구입니다. 요건서와 로그는 일반 도메인 더미로 시작하고, 실시간 개입과 고객망 실행은 1주차 범위에서 빼고 로컬 파일 입력만 다룹니다. 화면은 만들지 않고 결과는 터미널 출력과 md 파일로 냅니다.
도구가 낸 결함 유형과 연동 차단 여부를 더미에 심은 정답 라벨과 대조해 일치율과 놓친 결함·과잉 질문을 리포트 파일로 내고, 로그를 밖으로 못 내보내는 고객을 가정해 같은 명령이 도는 컨테이너 이미지로 굽습니다.
담당자가 선택지를 고른 질문지를 다시 넣으면 확정된 정책 규칙 초안 파일과 남은 질문지가 나오고, 회차별로 반복되는 결함 유형을 누적 집계해 요건서 양식 자체의 약한 지점을 파일로 보여줍니다.
요건서 40행과 발화 로그 500행을 인자로 준 명령 한 줄이 확인 질문지 md 와 요약 표를 몇 초 안에 만들고, 터미널에 결함 유형별 건수와 연동 차단 항목이 찍히는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(빈 조치 열·섹션 병합 빈칸·채널 표기 흔들림·빈 발화·요건 충돌 쌍·머리글 반복 행)을 넣어도 질문지 구조와 요약 표가 한 번도 안 깨지고, 판정 못 한 행은 버리지 않고 '판정 불가'로 남습니다
더미에 심은 정답 결함 라벨 60건 중 유형과 연동 차단 여부가 함께 일치한 게 52건(약 87%)입니다. 단, 요건서·로그·정답을 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
답변이 채워진 질문지를 다시 넣었을 때 규칙 초안으로 자동 확정된 항목이 40건 중 31건(약 78%)이고 나머지는 잔여 질문으로 남습니다. 단, 담당자 답변도 작성자가 만든 합성 응답이라 실제 회신 품질과는 다릅니다
진짜 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 놓친 결함과 담당자가 실제로 답을 주는 비율은 티냅스의 실 고객사 요건서와 실 로그, 실 담당자가 있어야 측정됩니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
이건 고객사·실데이터 없이 혼자 만든 포트폴리오입니다. 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 도구 동작과 실검증 준비 상태로 솔직히 설명합니다
정답 결함 라벨을 작성자가 만들었으니 잘 맞는 게 당연합니다. 섹션 병합 빈칸·조치 열 공백·채널 표기 흔들림·요건 충돌 쌍·자동 판정 불가 문구·로그에만 나오는 위험 패턴 같은 경계 케이스를 요건서 더미에 일부러 섞어, 깨끗한 행만 통과시키는 게 아님을 보여줍니다
이 포트폴리오가 보여주는 것은 지저분한 고객사 문서와 로그를 규칙으로 읽어 결함을 짚고 근거를 붙인 확인 질문으로 바꾸는 기술입니다. 금융 규제 해석이나 실제 응답 정책 수립, 0.2초 실시간 개입을 견디는 고객 인프라 운영 같은 도메인 전문성은 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다
요건 문구를 기계가 잘못 읽으면 멀쩡한 요건을 결함으로 몰아 질문이 불어납니다. 결함 유형은 열 채움 여부·채널 대조·조치 충돌·패턴 매칭이라는 규칙만으로 정하고, 요건 원문을 인용하지 못하는 항목은 질문을 만들지 않고 '판정 불가'로 따로 모아 사람이 보게 합니다
요건서 양식은 고객사마다 다릅니다. 열 이름과 채널 표기를 어댑터로 흡수하고 못 묶은 건 추측하지 말고 '미등록 채널·미매핑'으로 알립니다. 실제 도입 시 요건서 분량과 담당자 회신 주기가 더미와 달라 회차 설계를 다시 맞춰야 하므로 도입 단계 과제로 분리합니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 정보보안팀이 건넨 AI 응답 정책 요건서 시트 추출본과 심은 정답 결함 라벨. 도구가 가른 결함 유형을 이 라벨과 대조해 자가채점합니다. 섹션 병합으로 빈 행, 조치 열 공백, 로그에 없는 채널 지정, 서로 어긋나는 요건 쌍, 자동 판정이 불가능한 문구를 일부러 섞어, 깨끗한 행만 통과시키는 함정을 만듭니다.
| req_id | section | requirement_text | channel_raw | action_text | exception_note | gold_gap_type | gold_blocking |
|---|---|---|---|---|---|---|---|
| REQ-01 | 개인정보 보호 | 고객의 주민등록번호와 계좌번호는 어떤 경우에도 응답 본문에 노출하지 … | 전체 | 즉시 차단 | — | none | false |
| REQ-02 | — | 휴대전화번호가 포함된 응답은 담당 부서 지침에 따라 처리한다. | 전체 | — | — | action_missing | true |
| REQ-03 | 표현 관리 | 욕설과 비하 표현은 가급적 사용하지 않는다. | 웹챗 | 가급적 제한 | — | unverifiable | false |
| REQ-04 | 표현 관리 | 투자 수익을 단정하는 표현은 응답에서 제외한다. | 카톡상담 | 즉시 차단 | — | channel_unmapped | true |
| REQ-05 | 표현 관리 | 투자 관련 문구는 준법감시 검토 대상이므로 사람이 확인한 뒤 내보낸다. | 전체 | 사람 검토 | — | conflict | true |
아래 JSON Schema 에 맞는 고객사 응답 정책 요건서 40행을 JSON 배열로 생성합니다. requirement_text 는 정보보안 담당자가 엑셀 시트에 직접 쓴 것 같은 자연문 한 문장으로 만들고, gold_gap_type 은 그 행이 그대로 규칙이 될 수 있는지에 대한 정답 라벨로, gold_blocking 은 그 항목이 정해지지 않으면 연동을 시작할 수 없는지로 심습니다.
{"type":"object","properties":{"req_id":{"type":"string"},"section":{"type":["string","null"]},"requirement_text":{"type":"string"},"channel_raw":{"type":["string","null"]},"action_text":{"type":["string","null"]},"exception_note":{"type":["string","null"]},"gold_gap_type":{"type":"string","enum":["none","action_missing","channel_unmapped","conflict","unverifiable"]},"gold_blocking":{"type":"boolean"}},"required":["req_id","section","requirement_text","channel_raw","action_text","exception_note","gold_gap_type","gold_blocking"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(깨끗한 행만 통과시키는 함정 회피): (1) 셀 병합 때문에 section 이 null 이라 위 행에서 상속해야 하는 행 4건 이상, (2) action_text 가 null 이거나 '지침에 따라'처럼 조치를 지목하지 못하는 행 5건(gold_gap_type=action_missing), (3) channel_raw 가 '카톡상담'·'모바일웹'처럼 발화 로그 채널 목록에 없는 표기인 행 4건(channel_unmapped), (4) 같은 대상에 서로 다른 조치를 지시해 짝으로 어긋나는 요건 쌍 3쌍(양쪽 모두 conflict), (5) '가급적'·'필요시'·'톤을 조정한다'처럼 자동 판정이 불가능하거나 로그로 식별할 수 없는 예외를 단 행 5건(unverifiable). 나머지는 gold_gap_type=none 으로 두고, none 인 행은 gold_blocking=false 로 둬라. 한 행이 여러 결함에 걸리면 action_missing, channel_unmapped, conflict, unverifiable 순으로 앞선 유형을 라벨로 둬라. JSON 배열만.{"type":"object","properties":{"req_id":{"type":"string"},"section":{"type":["string","null"]},"requirement_text":{"type":"string"},"channel_raw":{"type":["string","null"]},"action_text":{"type":["string","null"]},"exception_note":{"type":["string","null"]},"gold_gap_type":{"type":"string","enum":["none","action_missing","channel_unmapped","conflict","unverifiable"]},"gold_blocking":{"type":"boolean"}},"required":["req_id","section","requirement_text","channel_raw","action_text","exception_note","gold_gap_type","gold_blocking"]}고객사 운영 AI 가 실제로 내보낸 발화 로그 덤프 샘플. 요건서가 이 로그에 나오는 위험 패턴을 덮고 있는지 대조하고, 요건 어디에도 없는 패턴은 확인 질문으로 올립니다. 채널 표기 흔들림·빈 발화·우회 표기 개인정보·요건서에 없는 패턴을 섞어, 요건서만 읽어서는 안 보이는 공백을 만듭니다.
| log_id | ts | channel_raw | channel_id | utterance_text | gold_pattern |
|---|---|---|---|---|---|
| L0001 | 2026-07-14T09:12:03 | 웹챗 | ch_web | 확인해 보니 주민번호 901201-1234567 로 가입되어 있습니다. | rrn |
| L0002 | 2026-07-14T09:31:40 | 웹챗 | ch_web | 고객님 계좌는 110-234-567890 입니다. | account_no |
| L0003 | 2026-07-14T10:02:11 | 카카오톡 | ch_kakao | 담당자 연락처는 010-1234-5678 이니 참고하세요. | phone |
| L0004 | 2026-07-14T10:44:58 | 카카오 톡 | ch_kakao | 연락처는 영일영-일이삼사-오육칠팔 이니 참고하세요. | phone |
| L0005 | 2026-07-14T11:20:07 | 웹챗 | ch_web | 문의는 help.center@example-bank.co.kr 으로 … |
아래 JSON Schema 에 맞는 고객사 운영 AI 발화 로그 500행을 JSON 배열로 생성합니다. utterance_text 는 상담용 AI 가 고객에게 실제로 내보낸 것 같은 한국어 응답 문장으로 만들고, gold_pattern 은 그 문장에 실제로 들어 있는 위험 패턴 코드로, 위험 패턴이 없으면 null 로 심습니다.
{"type":"object","properties":{"log_id":{"type":"string"},"ts":{"type":"string"},"channel_raw":{"type":"string"},"channel_id":{"type":["string","null"]},"utterance_text":{"type":["string","null"]},"gold_pattern":{"type":["string","null"],"enum":["rrn","account_no","phone","email","card_no","passport_no","internal_url","prompt_leak","instruction_override","profanity","claim_certainty",null]}},"required":["log_id","ts","channel_raw","channel_id","utterance_text","gold_pattern"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(요건서만 읽어서는 안 보이는 공백 만들기): (1) 같은 채널의 표기 별칭('카카오톡'과 '카카오 톡'처럼 흔들려 channel_id 로 정규화돼야 하는 행) 20건 이상, (2) 채널 마스터에 없어 channel_id=null 인 미등록 채널 행 10건, (3) 한글 숫자나 구분자를 끼워 숫자 패턴을 피한 우회 표기 개인정보 15건, (4) 요건서가 언급하지 않는 위험 패턴(passport_no·internal_url) 20건 이상, 이 행들이 확인 질문의 근거가 됩니다, (5) utterance_text=null 인 빈 발화 8건. 전체의 절반가량은 gold_pattern=null 인 평범한 안내 문장으로 두어 위험 패턴이 과대 대표되지 않게 하고, ts 는 2026-07-14 하루 안에서 업무 시간과 야간에 흩어라. JSON 배열만.{"type":"object","properties":{"log_id":{"type":"string"},"ts":{"type":"string"},"channel_raw":{"type":"string"},"channel_id":{"type":["string","null"]},"utterance_text":{"type":["string","null"]},"gold_pattern":{"type":["string","null"],"enum":["rrn","account_no","phone","email","card_no","passport_no","internal_url","prompt_leak","instruction_override","profanity","claim_certainty",null]}},"required":["log_id","ts","channel_raw","channel_id","utterance_text","gold_pattern"]}| Runtime Trust Layer | 이 도구가 준비하는 대상 계층으로, 그 층에 넣을 정책 규칙을 확정하기 직전 단계를 맡습니다 |
| 실시간 발화 검사 | 운영 로그의 발화를 결정론 패턴으로 훑어 실시간 검사가 잡아야 할 위험 유형이 요건서에 적혀 있는지 대조하는 부분입니다 |
| 정책 규칙 엔진 | 요건서 문장을 규칙 후보로 파싱하고 조치·채널·예외가 채워졌는지, 요건끼리 어긋나지 않는지 검사하는 규칙 층입니다 |
| API integration | 고객 AI 서버를 붙이기 전에 그 서버가 내려준 발화 로그 덤프를 표준 입력 형식으로 읽어 들이는 어댑터입니다 |
| private deployment | 로그를 밖으로 못 내보내는 금융권 고객을 가정해 고객망 안에서 같은 명령으로 도는 컨테이너 이미지로 배포하는 방식입니다 |
| AWS | 2주차부터 컨테이너 이미지를 올려 고객 계정에서 배치로 실행하는 기본 클라우드입니다 |
| GCP | 고객이 AWS 대신 쓰는 경우를 가정한 대체 실행 환경입니다 |
| Azure | 금융권 고객이 요구하는 경우를 가정한 또 다른 대체 실행 환경입니다 |
| Snowflake | 여러 고객사와 여러 회차의 점검 결과를 쌓아 반복되는 결함 유형을 질의하는 저장소입니다 |
| Python | 요건서 파서·결함 판정 규칙·질문지 렌더러의 구현 언어입니다 |
| Claude | 자연문 요건에서 규칙 후보 문구를 뽑고 질문 문장을 담당자가 읽기 쉽게 다듬는 보조 모델입니다 |
| devops | CLI를 컨테이너로 굽고 고객망에서 같은 결과로 재현 실행하도록 자동화하는 축입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(심은 정답 대비 자가채점 + 폐쇄망 실행 패키징)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(답변이 채워진 질문지 2회차 실행 + 회차 누적 집계)로 진행합니다.
확인 질문 1건. 결함 유형·근거 인용·영향 로그 건수·연동 차단 여부·담당자가 고를 선택지를 한 스키마로 담아 질문지 md 파일과 요약 표를 렌더링합니다. 요건이 옳은지 판단하는 게 아니라 그대로 규칙이 될 수 있는지만 가리는 산출물입니다.
{"type":"object","properties":{"gap_id":{"type":"string"},"gap_type":{"type":"string","enum":["action_missing","channel_unmapped","conflict","unverifiable","uncovered_pattern"]},"requirement_refs":{"type":"array","items":{"type":"string"}},"question":{"type":"string","minLength":15},"options":{"type":"array","items":{"type":"string"}},"requirement_quote":{"type":["string","null"]},"log_evidence":{"type":["string","null"]},"affected_logs":{"type":"integer"},"blocking":{"type":"boolean"},"hedge":{"type":["string","null"]}},"required":["gap_id","gap_type","requirement_refs","question","options","requirement_quote","log_evidence","affected_logs","blocking","hedge"]}[
{
"input_ref": "REQ-02 (조치 열이 비어 있음)",
"output": {
"gap_id": "G-001",
"gap_type": "action_missing",
"requirement_refs": [
"REQ-02"
],
"question": "휴대전화번호가 들어간 응답에 어떤 조치를 적용할까요. 로그 500건 중 37건이 여기 걸립니다.",
"options": [
"전체 차단",
"뒷자리만 가리고 통과",
"사람 검토로 넘김"
],
"requirement_quote": "휴대전화번호가 포함된 응답은 담당 부서 지침에 따라 처리한다.",
"log_evidence": "담당자 연락처는 010-1234-5678 이니 참고하세요.",
"affected_logs": 37,
"blocking": true,
"hedge": null
}
},
{
"input_ref": "REQ-09 · REQ-10 (같은 대상에 다른 조치)",
"output": {
"gap_id": "G-004",
"gap_type": "conflict",
"requirement_refs": [
"REQ-09",
"REQ-10"
],
"question": "이메일 주소를 두 요건이 다르게 다룹니다. 어느 쪽을 규칙으로 삼을까요.",
"options": [
"REQ-09 대로 업무 안내 목적이면 허용",
"REQ-10 대로 항상 마스킹",
"업무 안내 목적만 예외로 두고 나머지는 마스킹"
],
"requirement_quote": "이메일 주소는 업무 안내 목적이면 응답에 그대로 넣어도 무방하다.",
"log_evidence": "문의는 help.center@example-bank.co.kr 으로 보내주세요.",
"affected_logs": 18,
"blocking": true,
"hedge": null
}
},
{
"input_ref": "REQ-04 (로그에 없는 채널 표기)",
"output": {
"gap_id": "G-006",
"gap_type": "channel_unmapped",
"requirement_refs": [
"REQ-04"
],
"question": "요건이 가리키는 '카톡상담' 채널이 발화 로그에 없습니다. 로그의 어느 채널을 뜻할까요.",
"options": [
"ch_kakao(카카오톡)와 같은 채널",
"로그에 아직 안 잡힌 별도 채널",
"지금은 쓰지 않는 채널이라 규칙에서 제외"
],
"requirement_quote": "투자 수익을 단정하는 표현은 응답에서 제외한다.",
"log_evidence": null,
"affected_logs": 0,
"blocking": true,
"hedge": "채널을 확정하기 전에는 영향 건수를 셀 수 없어 0으로 둡니다"
}
},
{
"input_ref": "로그 교차 대조 (요건서에 없는 위험 패턴)",
"output": {
"gap_id": "G-011",
"gap_type": "uncovered_pattern",
"requirement_refs": [],
"question": "여권번호가 응답에 그대로 나가는 로그가 있는데 요건서 어디에도 언급이 없습니다. 어떻게 다룰까요.",
"options": [
"주민등록번호와 같게 즉시 차단",
"앞자리만 남기고 마스킹",
"이번 범위에서 제외"
],
"requirement_quote": null,
"log_evidence": "여권번호 M12345678 로 등록된 정보가 확인됩니다.",
"affected_logs": 23,
"blocking": false,
"hedge": "요건서에 근거가 없어 위험도를 단정하지 않고 담당자 판단으로 넘깁니다"
}
}
][자동 검증] 1. JSON Schema 형식 검증으로 질문 1건의 필드·enum·minLength 가 스키마를 통과하는지 확인합니다(못 통과하면 질문지 md 에 못 실으므로 거릅니다). 2. requirement_quote 가 요건서 원문 행에 실제로 있는 문장인지, log_evidence 가 발화 로그 원문에 있는 조각인지 토큰 매칭으로 확인하고, 둘 다 없는 질문은 만들지 않고 '판정 불가' 목록으로 뺍니다. 3. gap_type 이 규칙 판정 결과와 같은지 확인합니다. 한 행이 여러 결함에 걸리면 action_missing, channel_unmapped, conflict, unverifiable 순으로 앞선 유형이 잡혔는지 봅니다. 4. affected_logs 를 발화 로그에서 다시 세어 질문지에 적힌 수와 일치하는지 확인하고, gap_type 과 blocking 을 심은 정답 라벨과 비교해 일치율과 놓친 결함·과잉 질문을 계산합니다. [수동 검증] 1. 담당자 역할 2명이 같은 질문지를 따로 읽고 답할 수 있는 질문인지 라벨링해 bootstrap Cohen's κ(두 사람 판단 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체 질문의 5% 를 사람이 직접 점검하고, 연동 차단으로 표시된 질문과 '판정 불가'로 빠진 행을 우선으로 봅니다.
근거: 고객사의 AI 인프라 환경 분석 및 Runtime Trust Layer 연동 구조 설계