[26상] 케이뱅크 정보보호 자기소개서 항목별 풀이

[산업/기업/직무 분석]

# 케이뱅크, 어떤 회사일까?

케이뱅크는 2017년 출범한 국내 첫 인터넷전문은행으로, KT 그룹(BC카드)과 우리은행, NH투자증권을 주요 주주로 둔 디지털 은행입니다. 2025년 말 기준 고객 1,553만 명, 총자산 31.86조 원 규모이고, 2026년 3월 5일 코스피에 상장하며 IPO 3수 끝에 자본시장 진입을 마쳤습니다. 주담대와 아담대 중심의 여신 경쟁력, 업비트 제휴 기반의 가상자산 생태계 연결, SOHO 특화 전략이 3대 차별화 축입니다.

최우형 행장은 2026년 창립 10주년 메시지에서 "2030년 고객 2,600만 명, 자산 85조 원" 비전을 선포했고, 이를 달성할 3대 성장엔진으로 플랫폼(BaaS와 제휴), SME(2027년 100% 비대면 법인대출), AI와 디지털자산(K-Stable 해외송금, 프라이빗 LLM)을 명시했습니다. 세 엔진 모두 API 보안, KYB 고도화, LLM 거버넌스라는 정보보호 과제를 동반합니다.

# 케이뱅크 정보보호 직무의 특수성

인터넷전문은행 정보보호는 전통 시중은행과 다릅니다. 시중은행이 감사와 통제 중심의 CISA형 인재를 요구한다면, 케이뱅크는 코드를 읽고 쓸 수 있는 Security Engineer를 선호합니다. 이유는 세 가지입니다. 첫째, 조직 규모가 소수정예라서 1인 담당 범위가 시중은행 대비 넓습니다. 둘째, 클라우드 네이티브와 MSA 아키텍처가 기본 환경이라 SAST, SCA, 컨테이너 이미지 스캔(Trivy, Snyk)을 CI/CD에 내재화해야 합니다. 셋째, 무신사, 네이버페이, 업비트 같은 외부 파트너 연동이 많아 API 게이트웨이 보안과 제3자 위탁 관리의 난이도가 높습니다.

여기에 2024년 7월 시행된 책무구조도, 2026년 1월 전자금융감독규정 시행세칙 개정(별표7 망분리 대체 통제), 2025년 롯데카드 해킹 이후 금감원 블라인드 모의해킹 훈련 상시화라는 규제 변화가 겹치며, 정보보호 직무 지원자에게 요구되는 역량이 빠르게 고도화되는 중입니다.

[자기소개서 항목별 풀이]

항목 1. 케이뱅크에 입사를 희망하게 된 이유와 입사 후 이루고 싶은 목표에 대해 구체적으로 작성해주세요. (700자)

Q. 케이뱅크 지원동기는 회사 비전과 본인 비전 중 어디에 무게를 실어야 하나요? 

A. 공고 단서("케이뱅크의 비전도 좋지만, 본인의 비전을 중심으로")를 곧이곧대로 따르세요. 회사 자랑은 한 문단 안에 압축하고, 본인이 3년 뒤, 5년 뒤 어떤 프로젝트의 책임자가 되고 싶은지를 시계열로 쓰는 편이 평가자에게 훨씬 잘 읽힙니다.

① 출제 의도 해석 (WHY)

이 문항은 지원자가 인터넷전문은행 세 곳 중 왜 "케이뱅크"를 골랐는지를 검증합니다. 카카오뱅크는 플랫폼 뱅크, 토스뱅크는 슈퍼앱 임베디드 뱅크라는 정체성을 가진 반면 케이뱅크는 스페셜티 볼륨 뱅크로 포지셔닝되어 있고, 2026년 3월 상장 이후 공시 의무를 지는 기업으로 탈바꿈했습니다. 평가자는 지원자가 이 전환기 맥락을 읽었는지, 그리고 본인의 5년 커리어 로드맵을 케이뱅크의 3대 성장엔진(플랫폼, SME, AI/디지털자산)과 어떻게 맞물리게 설계했는지를 봅니다. 즉 문항의 본질은 "회사의 서사와 개인의 서사가 얼마나 겹치는가"를 증명하라는 요구입니다.

② 평가 체크포인트 (WHAT)

• 카카오뱅크, 토스뱅크가 아닌 케이뱅크를 선택한 이유가 차별화 축(업비트 제휴, 주담대 경쟁력, SME 전환, 스테이블코인 해외송금) 중 최소 하나와 연결되는가

• 입사 후 목표가 추상적 포부가 아니라, 2027년 비대면 법인대출과 같은 실제 케이뱅크 로드맵 상의 프로젝트와 시점을 특정하는가

• 정보보호 직무가 2030 비전 달성에서 왜 필수적인 조력 기능인지를 본인의 언어로 설명하는가

③ 상위 1% 예시 (HOW)

[IPO 이후의 보안, 기업가치의 방패]

2026년 3월 코스피 상장은 케이뱅크 정보보호 조직에 근본적인 질문을 던졌다고 봅니다. 공시 의무를 지는 상장기업은 사이버 사고 한 건이 수천억 원 시가총액을 흔들 수 있는 구조에 들어섰기 때문입니다. 롯데카드가 ISMS-P 인증을 받은 지 2주 만에 Oracle WebLogic 취약점으로 200GB 데이터를 유출당한 사건은 인증과 운영의 괴리를 드러냈고, 2026년 1월 전자금융감독규정 시행세칙에 신설된 망분리 대체 통제 조항과 맞물려 금융권 보안 기준선이 다시 그어지는 중입니다.

이 전환기에 케이뱅크와 함께 성장하고 싶은 이유는 세 가지입니다. 첫째, AI Powered Bank 비전 아래 프라이빗 LLM과 금융특화 모델 23종을 운영하는 환경은 프롬프트 인젝션과 RAG 파이프라인 보안이라는 실전 과제를 담고 있습니다. 둘째, 2027년 3분기 100% 비대면 법인대출 목표는 KYB 고도화와 API Gateway 인증 설계 기회를 만듭니다. 셋째, 스페셜티 볼륨 뱅크의 소수정예 조직 구조 덕분에 한 사람이 SOC, 클라우드 보안, DevSecOps를 풀스택으로 다룰 수 있습니다.

입사 3년 차에는 비대면 법인대출 서비스의 보안성 검토 리드로 STRIDE 기반 위협 모델링과 OAuth 2.0 인증 설계를 수행하고, 5년 차에는 K-Stable 해외송금의 온체인, 오프체인 경계 보안 아키텍트로 기여하고 싶습니다. 기업가치를 지키는 방패가 되어 2030 비전의 한 축에 서겠습니다.

왜 통과되는가 :

• IPO, 망분리 시행세칙 개정, 롯데카드 사고라는 3대 최신 이슈를 지원동기의 전제 문단으로 깔아 산업 이해도를 첫 단락에서 증명함

• 회사 비전이 아닌 본인 비전을 3년 차와 5년 차 프로젝트로 시점화해 공고 단서("본인의 비전 중심")를 충실히 따름

• 정보보호 직무가 왜 케이뱅크 성장엔진의 enabler인지를 한 문장이 아니라 구조(플랫폼, SME, AI)로 매핑해 평가자의 납득 구간을 넓힘

항목 2. 지원한 분야에 관심을 갖게 된 계기와 본인만의 특성/강점을 근거로 지원분야에 적합한 이유에 대해 작성해주세요. (700자)

Q. 정보보호 직무 관심 계기를 쓸 때 자격증 나열부터 시작해도 되나요? 

A. 자격증은 체크박스일 뿐 스토리가 아닙니다. 반드시 "사건-깨달음-후속 행동"의 트리거 순서로 써야 합니다. 자격증은 후속 행동 구간에 증거로 들어가야 설득력이 생깁니다.

① 출제 의도 해석 (WHY)

이 문항은 지원자의 진정성과 케이뱅크 조직 적합도를 동시에 점검합니다. 케이뱅크 정보보호 자소서에서 가장 많이 탈락하는 유형은 "보안이 중요한 시대라 지원했다"는 일반론입니다. 평가자는 특정 사건이나 경험이 관심의 방아쇠가 되었는지, 그 이후 지원자가 어떤 증거를 쌓아 왔는지, 그리고 그 증거들이 케이뱅크의 DevSecOps 환경과 소수정예 조직 구조에 맞는 강점으로 수렴되는지를 봅니다. 강점은 두 가지 언어를 동시에 구사할 수 있는 Bilingual 역량, 즉 개발과 규제를 양방향으로 번역하는 능력이 가장 높이 평가됩니다.

② 평가 체크포인트 (WHAT)

• 관심의 시작이 특정 사건이나 프로젝트에 결부되어 있고, 그 사건이 일반 취준생 서사와 겹치지 않는가

• 본인의 강점이 "책임감, 꼼꼼함" 같은 추상어가 아니라 Bilingual 역량(코드와 규제), 자동화 지향, 시나리오 사고 중 하나 이상으로 구체화되는가

• 그 강점이 케이뱅크의 소수정예 풀스택 환경에서 왜 쓰일 수 있는지를 지원자의 언어로 설명하는가

③ 상위 1% 예시 (HOW)

[코드를 읽는 보안 엔지니어]

첫 관심은 3학년 팀 프로젝트에서 시작됐습니다. Docker 컨테이너로 배포한 로그인 서버의 베이스 이미지가 Log4Shell 취약점을 품고 있었는데, 팀원 누구도 그 사실을 모른 채 배포 직전까지 프로젝트가 흘러갔습니다. 취약점을 찾아낸 사람이 개발자가 아니라 Trivy 스캔 결과를 읽을 줄 아는 한 명이었다는 장면이 오래 남았습니다. 그날 이후 개발과 보안을 함께 이해하는 엔지니어가 되겠다고 결심했고, 정보보안기사와 AWS Security Specialty를 1년 안에 순차 취득했습니다.

두 번째 관심은 2025년 롯데카드 해킹을 복기하며 찾아왔습니다. 8년간 패치되지 않은 WebLogic 취약점이 일으킨 사고는 기술의 문제라기보다 조직의 문제였고, 기술과 프로세스, 규제를 한 문장으로 묶어 설명할 수 있는 사람이 되어야 한다고 느꼈습니다.

케이뱅크 정보보호 직무에 적합하다고 보는 강점은 두 가지입니다. 하나는 코드를 읽는 보안 관점입니다. GitHub Actions 기반 CI/CD에 SAST, SCA, 컨테이너 이미지 스캔을 파이프라인으로 내재화한 경험 덕분에 개발팀에게 보안을 No가 아닌 조건부 Yes로 설계해 줄 수 있습니다. 다른 하나는 규제 문서를 번역하는 힘입니다. 전자금융감독규정 제15조와 ISMS-P 101개 통제 항목을 정리한 블로그를 2년간 운영하며, 법 조문을 개발자가 받아들일 수 있는 체크리스트로 바꾸는 훈련을 쌓았습니다. 두 언어를 오가는 역량이 소수정예 케이뱅크 조직에서 쓰일 자리라고 판단했습니다.

왜 통과되는가 :

• 관심의 계기를 특정 사건(Log4Shell 배포 직전 탐지)과 산업 사고(롯데카드 해킹) 두 개의 레이어로 쌓아, 취준생 공통 서사에서 벗어남

• 강점 두 가지를 Bilingual이라는 틀로 묶고 각각의 증거(CI/CD 파이프라인 구축, 규제 해설 블로그)를 배치해 추상어를 전부 제거함

• "No가 아닌 조건부 Yes", "법 조문을 체크리스트로" 같은 실무 언어를 사용해 현업 감수성을 증명

항목 3. 현재 이용하고 있는 앱 중 가장 좋아하는 앱은 무엇이고, 그 이유에 대해 자유롭게 설명해주세요. (700자)

Q. 정보보호 지원자가 이 문항에서 유리한 앱 선정 기준이 있을까요? 

A. 금융앱이 아니어도 된다는 조건이지만, 정보보호 직무 지원자라면 "신뢰 설계"가 눈에 보이는 앱을 고르는 편이 유리합니다. 관찰 대상이 보안 UX, 개인정보 최소수집, 신고와 제재 피드백 루프 중 하나여야 직무 연결이 자연스럽습니다.

① 출제 의도 해석 (WHY)

이 문항은 사용자 경험 감수성과 관찰력을 봅니다. 케이뱅크는 앱 중심 은행이고, 정보보호 조직조차 "보안은 사용자 경험의 일부"라는 관점을 공유합니다. 평가자는 지원자가 앱의 표면(UI)이 아니라 이면(설계 원칙)을 읽어낼 수 있는지, 그리고 그 관찰이 본인 직무와 연결되는 시선을 가졌는지를 확인합니다. 특히 정보보호 직군 지원자가 신뢰 설계 관점의 관찰을 남기면 직무 fit이 추가 점수로 작동합니다.

② 평가 체크포인트 (WHAT)

• 앱의 장점을 기능 나열이 아니라 설계 원칙 수준에서 해석했는가

• 관찰이 구체적 장면(특정 화면, 특정 문구, 특정 플로우)에 닿아 있는가

• 앱에서 배운 설계 원칙이 지원 직무(정보보호)와 어떤 지점에서 겹치는지를 마지막에 엮어내는가

③ 상위 1% 예시 (HOW)

[당근, 신뢰를 설계하는 동네]

가장 오래 쓰는 앱은 당근입니다. 중고거래로 시작했지만 지금은 동네생활 탭과 모임 기능까지 하루 두세 번씩 열고 있습니다. 이 앱을 좋아하는 이유는 편의성이 아니라 신뢰 설계 방식에 있습니다.

첫째, 노출되는 개인정보 범위가 거래 단계별로 다릅니다. 글 목록에서는 닉네임, 동네, 매너온도만 보이고, 채팅을 시작해야 위치 공유 기능이 열립니다. 개인정보 최소수집 원칙을 UX 레이어에서 구현한 사례라고 봅니다. 둘째, 사기 의심 거래에 대한 경고 배너가 문맥에 맞게 뜹니다. 대화 중 계좌 요청 키워드가 등장하면 팝업이 아닌 채팅 상단 인라인 경고로 나타나, 사용자 흐름을 끊지 않으면서도 시그널을 남깁니다. 셋째, 신고 후 결과를 가시화합니다. 신고한 사용자의 이후 제재 상태를 신고자에게 부분 공유해 주는데, 이 피드백 루프가 신고 참여율을 끌어올리는 구조로 작동합니다.

정보보호 직무를 준비하며 가장 자주 되새기는 명제가 "보안과 사용자 경험은 제로섬이 아니다"라는 것입니다. 당근은 그 명제를 서비스 레이어에서 증명하고 있습니다. 위험 신호를 확인과 동의 과정에 자연스럽게 섞고, 제재 결과를 투명하게 보여줌으로써 사용자가 스스로 커뮤니티의 보안에 참여하게 만드는 설계가 그렇습니다. 케이뱅크 고객이 하루에 마주할 FDS 경고와 추가 인증 화면도 이 문법을 따라야 한다고 봅니다. 보안을 장벽이 아닌 습관으로 만드는 앱에서 배우고 싶은 지점이 여전히 많습니다.

왜 통과되는가 :

• 장점 세 가지를 "기능"이 아니라 "설계 원칙(최소수집, 인라인 경고, 피드백 루프)"으로 해석해 앱을 보는 눈을 증명

• 관찰의 끝을 본인 직무(FDS 경고와 추가 인증 화면)로 연결해, 문항이 요구한 자유 서술 안에서도 직무 fit을 확보

• "보안은 제로섬이 아니다"라는 단 한 줄 명제가 마지막 단락 전체를 묶어 가독성을 높임

항목 4. 은행의 상품이나 앱을 사용하면서 느꼈던 장점과 아쉬운 점을 구체적으로 설명해 주세요. 그렇게 느낀 이유를 작성하고, 내가 개발자라면 어떻게 개선·보완할지 제안해 주세요. (1000자)

Q. 개선 아이디어는 어느 정도로 구체적이어야 하나요? 

A. "이런 기능이 있었으면 좋겠다" 수준에서 멈추면 감점입니다. 입력값, 엔진, 출력 인터페이스까지 3단 구조로 내려가야 합니다. 케이뱅크는 Tech 직군 평가에서 "네가 개발자라면"을 문자 그대로 해석합니다.

① 출제 의도 해석 (WHY)

이 문항은 사용자 관찰, 문제 정의, 기술적 구현 제안의 3단 사고를 모두 요구합니다. 정보보호 직무 지원자는 특히 보안 UX 관점의 제안을 내놓는 편이 차별화됩니다. 일반 UX 개선은 기획자 지원자들이 쉽게 쓰지만, 경보 둔감화, 리스크 기반 인증, 컨텍스추얼 MFA 같은 관점은 보안 직무 지원자에게서만 나오기 때문입니다. 평가자는 지원자가 기능의 표면이 아니라 설계 결함을 구조적으로 읽고, 현재 기술 스택(FDS, SIEM, 인증 게이트웨이) 안에서 실현 가능한 개선안을 그려낼 수 있는지를 봅니다.

② 평가 체크포인트 (WHAT)

• 장점과 아쉬운 점이 현장에서 실제로 겪을 법한 구체 장면에 닿아 있는가

• 아쉬운 점의 원인 분석이 증상 나열이 아니라 구조적 해석(경보 둔감화, 획일적 통제 등)으로 들어가는가

• 개선 제안이 입력-엔진-출력(또는 데이터-모델-인터페이스) 3단 구조로 내려가며 실현 가능한 기술을 명시하는가

③ 상위 1% 예시 (HOW)

[보안 팝업 피로도, 스텝업 인증으로]

가장 자주 쓰는 은행 앱은 카카오뱅크입니다. 장점은 세 가지입니다. 첫째, 송금과 조회까지의 동선이 3탭 이내로 끝납니다. 둘째, 공동인증서 없이 생체인증만으로 거래가 가능해 첫 화면 진입에서 로그인까지의 시간이 1초 안팎입니다. 셋째, 알림센터에 거래 내역, 캘린더, 소비 분석이 하나의 스트림으로 통합되어 가계부 앱을 따로 열 일이 없습니다.

아쉬운 점은 저위험 거래에서도 보안 인증이 획일적으로 반복된다는 부분입니다. 10만 원 송금과 1,000만 원 송금의 인증 단계가 같고, 평소 쓰던 디바이스에서 평소 보내던 계좌로 보낼 때도 추가 인증이 발생합니다. 금감원과 금융보안원이 권고하는 이상거래 탐지의 기본 취지는 위험에 비례한 통제인데, 사용자 입장에서는 거래 금액과 상관없이 같은 마찰을 겪게 되는 셈입니다. 이 반복이 쌓이면 사용자는 보안 화면을 관성적으로 넘기게 되고, 진짜 위험한 순간의 경고까지 같이 흘려보내는 경보 둔감화가 일어납니다.

개발자라면 Risk-Based Authentication 기반의 스텝업 인증을 도입하겠습니다. 설계는 세 층으로 구성합니다. 1층은 디바이스 지문, IP 신뢰도, 계좌 관계, 시간대, 평균 거래금액을 입력값으로 받는 실시간 위험 점수 계산 엔진입니다. 2층은 점수 구간별 통제 매트릭스입니다. 저위험 구간에서는 생체인증 한 번으로 통과, 중위험 구간에서는 간편비밀번호 재입력, 고위험 구간에서는 ARS 또는 영상 인증을 요구하는 식입니다. 3층은 사용자가 본인의 위험 프로필과 통제 강도를 볼 수 있는 투명성 대시보드입니다. 왜 지금 추가 인증이 요구되는지를 한 줄로 설명해 주는 영역이 있어야 사용자가 통제를 납득합니다.

구현 관점에서는 기존 FDS 룰 엔진 위에 Flink 기반 스트리밍 스코어링 계층을 얹고, 추론 결과를 인증 게이트웨이 API로 노출해 통제 매트릭스가 실시간 동작하도록 하겠습니다. 모델 성능 지표는 차단된 사기 금액 대비 고객 불편 지수 비율로 측정해, 보안과 사용자 경험을 같은 보드에서 관리하는 문화를 제안하고 싶습니다.

왜 통과되는가 :

• 장점을 세 가지로 불렛화하되 각각이 시간(1초), 동선(3탭) 같은 숫자에 닿아 있어 관찰자 시선을 증명

• 아쉬운 점의 원인을 "경보 둔감화"라는 보안 직군 고유의 개념으로 정의해, 기획자 지원자 답변과 차별화

• 개선안을 입력값(디바이스 지문, IP 신뢰도), 엔진(Flink 스트리밍), 인터페이스(통제 매트릭스, 투명성 대시보드)의 3층 구조로 내려 보내고 성능 지표까지 제시

항목 5. 보안 또는 IT 프로젝트에서 문제를 발견하고 해결한 경험을 구체적으로 작성해주세요. 그 과정에서 새로운 기술(AI, 클라우드 등)을 학습하고 적용해본 경험이 있다면 함께 설명해주세요. (1000자)

Q. 문제 해결 경험에서 AI나 클라우드를 억지로 넣어야 할까요? 

A. 억지로 넣으면 티가 납니다. 문제 정의가 먼저고, 그 문제의 한계를 뚫기 위해 AI나 클라우드가 수단으로 선택된 흐름이 자연스러워야 합니다. 공고에서 AI/클라우드를 묶어 언급한 이유는 케이뱅크의 AI Powered Bank 전략 때문이고, 평가자는 기술 자랑이 아니라 "왜 그 기술이어야 했는가"를 봅니다.

① 출제 의도 해석 (WHY)

이 문항은 기술 역량의 실제 적용과 학습 민첩성을 동시에 검증합니다. 케이뱅크 정보보호 조직은 클라우드 네이티브 환경에서 DevSecOps와 AI 거버넌스를 병행하기에, 지원자가 한 번이라도 "문제를 정의하고 → 도구의 한계를 식별하고 → 새 기술을 학습해 적용하고 → 결과를 측정한" 사이클을 돌려봤는지가 관건입니다. 평가자가 싫어하는 답변은 두 가지입니다. 하나는 AI나 클라우드를 장식처럼 붙인 서술, 다른 하나는 결과를 정성적으로만 적고 수치가 없는 서술입니다.

② 평가 체크포인트 (WHAT)

• 문제 정의가 증상(에러) 나열이 아니라 구조적 한계(룰 기반의 한계, 의미 이해 부재 등)로 내려가는가

• 새 기술(AI, 클라우드) 선택이 "멋져서"가 아니라 문제의 한계를 뚫기 위한 수단으로 제시되는가

• 결과가 최소 하나 이상의 정량 지표(탐지 건수, 시간 단축, 정확도 변화)로 측정되는가

③ 상위 1% 예시 (HOW)

[자동화되지 않던 취약점, LLM으로 깨다]

4학년 캡스톤에서 웹 API 취약점 자동 스캐너를 제작했습니다. 팀은 4명이었고, 저는 스캔 엔진과 리포팅 파이프라인을 맡았습니다. 초기에는 OWASP ZAP을 래핑해 SQL Injection, XSS, CSRF 같은 전통 취약점을 탐지하는 구조로 만들었지만, 실제 테스트 대상 서비스에 돌려 보자 한계가 드러났습니다. IDOR이나 권한 상승 같은 비즈니스 로직 취약점은 URL 패턴만으로는 잡히지 않았고, OpenAPI 명세를 사람이 읽고 의심 구간을 지정해야만 룰이 작동했습니다.

문제를 두 갈래로 분리했습니다. 하나는 스캐너가 API의 의미를 모른다는 것, 다른 하나는 전통 퍼징이 무작위 입력에 의존해 의미 있는 시나리오를 만들지 못한다는 것이었습니다. 해결 방향은 시맨틱 퍼징이었고, 그 수단으로 LLM과 RAG를 택했습니다.

먼저 OpenAPI 문서와 해당 서비스의 인증, 권한 정책 문서를 청크 단위로 잘라 벡터 DB에 인덱싱했습니다. 스캐너는 엔드포인트를 돌기 전에 RAG 검색으로 해당 API의 리소스 소유자, 권한 레벨, 상태 전이 규칙을 받아오고, LLM이 그 정보를 바탕으로 권한 경계 우회 시나리오를 생성하도록 파이프라인을 구성했습니다. 인프라는 AWS Lambda와 SQS로 서버리스 분산 구조를 만들고, 스캔 결과는 DynamoDB와 S3에 분리 적재했습니다. 프롬프트 인젝션 방어를 위해 LLM 입력은 OpenAPI 스키마 기반 화이트리스트로 제한했고, 출력은 JSON 스키마로 강제 파싱해 악성 지시가 실행 코드로 흘러가지 않도록 차단했습니다.

결과는 두 지표로 확인했습니다. 기존 룰 기반 스캐너가 놓치던 IDOR 유형 취약점 중 11건을 새로 발견했고, 동일한 취약점 집합을 스캔하는 데 걸린 시간은 7시간에서 1시간 40분으로 줄었습니다. 담당 교수님이 지도 학생 10개 팀 중 유일하게 "프로젝트 이후에도 실제 서비스에 쓸 수 있는 결과물"이라고 평가해 주셨습니다.

이 경험은 신기술이 목적이 아니라 기존 한계를 정의한 뒤 선택해야 할 도구라는 사실을 남겼습니다. 케이뱅크 클라우드 네이티브 환경에서도 문제 정의에 먼저 집중하는 방식으로 기여하고 싶습니다.

왜 통과되는가 :

• 문제를 "증상"이 아니라 "구조적 한계(의미 이해 부재, 무작위 퍼징의 한계)"로 분리해, 기술 선택의 논리적 근거를 먼저 깔아 둠

• LLM 도입 과정에 프롬프트 인젝션 방어와 JSON 스키마 강제 파싱이라는 보안 내장 설계를 함께 배치해 직무 적합성을 자연스럽게 녹임

• 결과를 정성 평가 한 줄과 정량 지표 두 개(신규 발견 11건, 시간 7시간 → 1시간 40분)로 병기해 평가자의 의심을 최소화