면접 질문 · 답변 노트
작성자 이정원. 인성 질문과 기술 질문을 한 자리에서 점검하기 위해 자소서와 같은 원칙(마지막 문장이 의지, 미경험은 배움으로)을 답변 끝까지 적용했습니다. 질문마다 예상 꼬리질문을 붙였고, "내 답변 써보기"로 먼저 내 말로 연습한 뒤 "예시 답변 보기"로 비교할 수 있다 — 입력한 연습 답변은 이 브라우저에만 저장된다.
자기소개 · 기본 성향
1분 자기소개, 성격, 대학 수업, 출퇴근, 야근 등 가장 먼저 받는 인성 질문.
-
자기소개 부탁드립니다
예상 꼬리질문- 1분을 30초로 줄이면 뭘 가장 먼저 빼시겠어요?
- 사회복무요원 경험이 지원 동기에 어떻게 연결되나요?
예시 답변안녕하세요. 이정원이라고 합니다. 광운대학교 4학년에 재학 중이고, 지난 7월에 사회복무요원 소집해제를 마쳐 복학을 준비하던 중 시선아이티 현장실습 공고를 보고 지원하게 되었습니다.
· 포인트1분 이내로 끊고, 지원 동기 한 줄을 자연스럽게 연결.
-
본인 성격은 어떤 편인가요?
예상 꼬리질문- 내성적인 성격이 협업에서 불리하게 작용한 적은 없나요?
- '한 발 더 움직인다'는 구체적으로 어떤 행동이었나요?
예시 답변사회적으로는 내성적인 편이지만, 할 일이 쌓여 있는 걸 보는 게 싫어서 안정적으로 끝내는 쪽을 선호합니다. 사회복무요원 시절에도 남들보다 한 발 더 움직이는 편이었고, 그게 싫지 않았습니다. 조직에 애정을 두는 편이라 같이 일하는 사람이 더 나아지는 쪽을 먼저 생각합니다.
· 포인트내성적 + 성실 → 단점이 아니라 톤. 끝에 조직에 대한 애정으로 착지.
-
가장 기억에 남는 학교 수업은요?
예상 꼬리질문- 캐시를 도입해서 실제로 성능이 얼마나 좋아졌나요?
- 톨키니즘과 산업혁명 비교는 왜 흥미로웠나요?
예시 답변전공 중에서는 운영체제였습니다. CPU 레지스터부터 캐시 히트율 알고리즘, 가상 메모리와 페이지네이션까지 — 같은 아키텍처가 반복되는 게 흥미로웠고, 실제로 캐시를 도입해 성능을 높여 보려는 시도로 연결됐습니다. 컴퓨터 구조는 논리 게이트에서 CPU가 완성되는 과정이 재미있었고, 기계학습에서는 퍼셉트론을 적층해 신경망이 된다는 한 가지가 그 수업 전체의 가치가 된 경험이었습니다. 교양에서는 톨키니즘과 산업혁명 비교가 기억에 남습니다.
· 포인트수업 → 실습 연결을 짧게 한 줄씩. 끝에 흥미 → 행동.
-
혼자 밥 먹는 건 괜찮은가요?
예상 꼬리질문- 회식 문화는 어떻게 생각하세요?
예시 답변괜찮습니다. 대학 때는 혼자 먹는 걸 선호했는데, 사회복무요원 시절에는 다같이 먹는 것도 즐겁게 잘 했습니다. 그래서 그때그때 달라요.
· 포인트솔직함 + 유연성. 짧게 끝내도 됨.
-
팀원과의 갈등이 생기면 어떻게 대처하나요?
예상 꼬리질문- 구체적으로 의견이 갈렸던 사례를 하나만 들어주실 수 있나요?
- 그래도 안 풀리면 어떻게 하나요?
예시 답변감정이 상하는 쪽으로 번지지 않도록 의견을 명확히 나누는 편입니다. 경기혈액원에는 10년 20년을 함께한 분들도 계셨는데, 그분들은 다툴 때도 일에 대한 이야기였고 사적으로는 다시 가까워지셨습니다. 결과가 더 나아지는 다툼이라면 피하고 싶지 않습니다.
· 포인트다툼 자체를 회피하지 않는 성격임을 보여줌. 끝에 '더 나은 결과'로 닫기.
-
혼자 일하는 거랑 같이 일하는 거 중에 어떤 게 더 좋아요?
예상 꼬리질문- '내가 무엇을 모르는지도 모르게 된다'는 걸 실제로 느낀 순간이 있었나요?
예시 답변작업에 따라 다릅니다. 처음 보는 코드를 읽거나 디버깅할 때는 혼자가 좋고, 명세가 모호하거나 실수했을 때 잡아줘야 할 때는 같이 하는 게 좋습니다. 사회복무요원 전까지는 거의 혼자 일했는데, 거기서 한 가지 배운 게 있습니다 — 혼자 하면 할수록 내가 무엇을 모르는지조차 모르게 된다는 점입니다. 그래서 SI처럼 명세와 절차가 짜여 있는 환경에서는 같이 일하는 쪽이 더 빠르게 성장할 거라 봅니다.
· 포인트작업별 분기 + 한계 인정 + SI 의지. 자소서 2번의 '다인 개발' 결핍과 직접 연결.
-
출퇴근은 불편하지 않나요?
예상 꼬리질문- 출퇴근 시간에 보통 뭘 하시나요?
예시 답변수원 영통에 사는데 지하철로 한 시간 정도입니다. 대학 2년 동안 광운대까지 2시간 통학을 했고, 사회복무요원 때도 40분씩 걸렸기 때문에 한 시간은 크게 어렵지 않습니다.
· 포인트구체 숫자(2년, 40분)로 진정성. 짧게.
-
퇴근 후에 업무 요청이 오면 어떻게 하나요?
예상 꼬리질문- 그게 반복되면 어떨 것 같아요?
예시 답변제 업무라면 처리합니다. 회사에 다니는 동안은 그 업무가 제 것이고, 시간과 장소는 부수적인 문제라고 생각합니다.
· 포인트짧고 단단하게. 한 줄 답변.
-
회사 업무가 과도하다고 느끼면 어떻게 하나요?
예상 꼬리질문- 여쭤봤는데도 상황이 안 바뀌면 어떻게 하시겠어요?
예시 답변먼저 리더나 선임분께 의견을 여쭙습니다. 제가 과도하다고 느끼는 감정이 워크플로우에 대한 무지에서 오는 것일 수 있고, 그분들은 그 자리를 이미 보셨으니 더 나은 방법을 제시해 주실 수 있기 때문입니다.
· 포인트자기 판단을 의심하는 톤 + 위임. 끝이 '배움'으로 닫힘.
-
야근이 있을 수도 있는데 괜찮겠어요?
예상 꼬리질문- 야근이 일주일 내내 반복되면 그때도 같은 생각이실까요?
예시 답변괜찮습니다. 시험공부는 미루다 몰아서 하면 비효율이 큰데, 회사 일은 해야 할 일이니까요. 그 차이입니다.
· 포인트시험공부 vs 회사 일 대비 — 깔끔한 한 줄.
지원 동기 · 회사 이해
왜 시선아이티인지, 회사가 하는 일을 얼마나 아는지 검증하는 질문.
-
왜 우리 회사에 지원했어요?
예상 꼬리질문- '행정적으로 영향이 가는 데이터'를 다뤄본 구체적 사례가 있나요?
- 챗봇 직무와 SI 직무 중 더 끌리는 쪽이 있나요?
예시 답변두 가지가 결정적이었습니다. 첫째, 현장실습 계획서에 적힌 챗봇 직무가 단순 키워드 매칭을 넘어 의도·문맥 파악과 SI 내부 시스템 연동까지로 적혀 있었는데, 그건 도구 호출(tool calling)을 LLM으로 안정적으로 감싸는 문제와 정확히 일치합니다. oxi 생태계에서 그 연결을 직접 만들어 본 경험이 있는 곳이 여기라고 생각했습니다. 둘째, 공공데이터를 다루는 시스템이라는 점입니다. 혈액관리본부의 헌혈 데이터를 다뤄 봤을 때, API 명세가 바뀌거나 공시가 늦어지면 단순히 못 그리는 것이 아니라 행정적으로 영향이 가는 데이터라는 걸 몸으로 느꼈습니다. 그 감각을 가진 채로 들어가는 것이 의미가 있다고 생각했습니다.
· 포인트챗봇 + 공공데이터의 교집합으로 회사 특정성. 자소서 1번과 같은 결.
-
왜 다른 회사 대신 여기?
예상 꼬리질문- 같은 조건의 다른 회사가 있었다면 어떻게 결정하셨을까요?
예시 답변솔직히 같은 조건의 다른 회사 — 챗봇 + 공공데이터 — 가 많지 않아서, 여기 한 곳을 깊게 준비했습니다. 결정 이유는 두 가지입니다. 첫째, 챗봇의 '의도·문맥 파악' 명시가 다른 곳의 단순 Q&A 봇 수준과 달랐고, 둘째, 현장실습 계획서에서 교육 커리큘럼이 구체적으로 적혀 있어서 여기서 무엇을 배우게 될지 미리 그려볼 수 있었습니다. SI에서 처음 시작하는 자리라서 무엇을 배울 수 있는지 명시적인 곳을 고른 것이 가장 컸습니다.
· 포인트회사 특정성 + 신입이 처음 가는 자리라 커리큘럼 명시성을 본다는 이유.
-
우리 회사에서 하는 일들 알고 있나요?
예상 꼬리질문- 그중에서 가장 관심 가는 사업은 어느 거예요?
- 지사(김해)와 본사(부산) 업무가 왜 나뉘어 있다고 보세요?
예시 답변홈페이지 기준으로 봤습니다. AI 기반 지중매설물 정보 관리 시스템, 국토 현황 정보 플랫폼, 산불과선 자동추출 프로그램 — 이미지 비전을 그렇게도 활용할 수 있구나 싶었습니다. 재난/재해 서비스는 정부 부처에서 실제 사용 중이고, 공간정보 시스템은 김해 지사, 안전관리 서비스는 부산 본사의 업무로 보고 있습니다. GeoAI는 구축 중이고, 시선 AI 챗봇은 요청 시 지도 시각화로 연결된다는 점이 흥미로웠습니다. SLM 플랫폼은 SaaS로 모델을 통합 관리하는 형태라, 머지않아 소프트웨어에 SLM 계층이 기본으로 들어가는 시점이 올 거라 봅니다.
· 포인트지사별/본사별 업무 구분까지 말할 수 있어야 함.
-
GIS에 대해 아나요?
예상 꼬리질문- 3D 게임 프로젝트에서 그 문제를 실제로 어떻게 해결했나요?
예시 답변바이브코딩으로 3D 게임을 진행해 본 적이 있는데, 그때 자주 발생하던 문제가 오브젝트가 월드 바닥에서 떠 있거나 파묻히는 경우였습니다. 월드 형태를 이미지 비전으로만 확인하니 정확히 인지하지 못해서 그런 것이고, 이처럼 국토라는 배경에서 에이전트가 작업하려면 위성 이미지가 아니라 구조화된 GIS 데이터가 필요하다고 이해했습니다.
· 포인트바이브코딩 실패 경험으로 GIS 필요성 연결.
-
SaaS 알고 있나요?
예상 꼬리질문- SaaS와 온프레미스의 차이를 설명해주실 수 있나요?
예시 답변네, 알고 있습니다.
· 포인트한 줄 답.
-
이 직무에서 살아남으려면 뭐가 중요할까요?
예상 꼬리질문- '절차와 권한'에서 좌절했던 구체 사례를 하나 들어주실 수 있나요?
예시 답변신입이 6개월 안에 안정적으로 일하려면, 코드 잘 짜는 것보다 이 회사의 산출물 양식과 절차에 빨리 익숙해지는 것이라고 생각합니다. 그 이유는 자소서에도 썼듯이, 개인 프로젝트에서 좌절했던 세 번의 이유가 전부 기술 바깥 — 절차와 권한 — 에 있었기 때문입니다. 기술은 이미 어느 정도 다루지만 절차는 처음이므로, 1단계에서는 그 양식과 단계별 산출물을 빠르게 흡수하는 데 집중할 생각입니다. 그리고 SI는 혼자 일하는 일이 아니기 때문에, 다른 사람이 만든 정의를 읽는 속도와 그에 맞춰 구현하는 정확도가 결국 생산성의 전부라고 보고, 그 두 가지를 가장 먼저 키우겠습니다.
· 포인트좌절의 원인이 절차 밖이라는 자소서 핵심. 1단계 의지 + 협업 정확도.
-
6개월 후 본인이 어떤 모습일 것 같아요?
예상 꼬리질문- 평가셋은 구체적으로 어떻게 만들 계획인가요?
- 인수인계 문서는 어떤 형식으로 남기실 건가요?
예시 답변1단계(교육)에서는 방법론과 산출물 양식을 익히면서, 제가 개인적으로 만들었던 것들 중 어느 부분이 어떤 산출물 양식에 대응하는지 매핑해 두겠습니다. 마르미-III의 단계별 산출물이 실제로 어떤 모양인지 직접 만져보겠습니다. 2단계(챗봇)에 들어가면 그때는 이미 부딪혀 본 영역이므로, 검색 품질이 나아졌는지 판단하는 기준을 세우는 일부터 손을 보태겠습니다. 평가셋을 만들어두고 정량으로 비교하는 흐름을 시도해 보겠습니다. 실습이 끝날 때 제가 만든 부분은 다른 사람이 그대로 이어받을 수 있는 상태로 넘기겠습니다. 이게 SI에서 결과물을 진짜 끝낸 모양이라고 생각하기 때문입니다.
· 포인트1단계/2단계 분리 + 평가셋 + 인수인계. 자소서 3번 결론과 동일.
-
우리 회사가 5년 후 어떻게 되었으면 좋겠어요?
예상 꼬리질문- 그 방향에 본인이 직접 기여할 수 있는 건 뭐라고 보세요?
예시 답변두 가지가 떠오릅니다. 첫째, 공공데이터와 LLM의 접점이 되는 회사가 되었으면 좋겠습니다. 시군구 단위 GIS 데이터, 토지이용·도로·건물 같은 행정 데이터는 그 자체로 가치가 있고, LLM이 그 데이터를 사용자의 의도에 맞게 검색·요약·시각화하는 것은 SI 업계에서 가장 의미 있는 응용 중 하나라고 봅니다. 둘째, 사내 도구와 절차가 잘 정리된 회사가 되었으면 좋겠습니다. 신입이 들어와서 빠르게 기여할 수 있는 회사는 결국 산출물 양식, 형상관리, 테스트 자동화가 잘 돌아가는 회사라고 보기 때문입니다. 실습 기간에 작은 도구 하나라도 자동화해 두는 것이 직접 기여할 수 있는 영역이라고 생각합니다.
· 포인트공공+LLM + 사내 자동화. 마지막이 '내가 기여할 부분'으로 닫힘.
-
우리 회사 업무 외에 본인이 하고 싶은 게 있나요?
예상 꼬리질문- 디자인 시스템 이식이 실제 업무와 충돌하지는 않을까요?
예시 답변솔직히 답하기 어렵습니다. 첫 직장이 될 자리이고, 들어갔을 때 회사가 원하는 일의 형태가 지금과 다를 수 있다고 보기 때문에, 미리 무엇을 하고 싶은지 단정하는 것보다 들어간 다음에 회사가 필요로 하는 일과 제가 잘하는 일이 어디서 겹치는지 찾는 것이 맞다고 생각합니다. 다만 두 가지 방향은 열어 두고 있습니다. 하나는 디자인 시스템을 사내 저장소 안으로 이식하는 일 — oxi 생태계에서 디자인 토큰을 통일해 본 경험이 있어서, 사내 여러 프로젝트의 UI가 들쭉날쭉한 문제를 정리하는 데 기여할 수 있습니다. 다른 하나는 자동화 스킬·툴을 만들어 팀에 나누는 일 — 매일 새벽에 코드리뷰 자동화, 디자인 감사 자동화를 돌리는 흐름을 사내에서도 적용할 수 있다고 봅니다.
· 포인트첫 자리라 겸손하게 + 두 가지 구체 방향 제시.
-
우리 회사에서 가장 부딪힐 것 같은 게 뭐에요?
예상 꼬리질문- 폐쇄망 문제는 실제로 어떻게 풀어보고 싶으세요?
예시 답변두 가지가 예상됩니다. 첫째, 폐쇄망에서 외부 OSS 도구를 어떻게 들여올 것인가 — 시선아이티는 공공 발주처와 일하므로 외부 저장소 직접 접근이 막힐 가능성이 높고, 그 안에서 어떻게 LangChain 같은 표준 도구나 GitHub Actions 같은 외부 CI를 들여오는지가 관건일 것입니다. 둘째, 행정 도메인의 데이터 모델링 — GIS 데이터, 토지이용, 도로망, 건물 같은 개체들이 단순한 스키마가 아니라 행정 구역·기준일·시행일자에 따라 버전이 갈라집니다. 그 '버전 있는 현실'을 코드로 어떻게 표현할지가 기술적으로 가장 큰 도전일 거라 봅니다.
· 포인트폐쇄망 + 행정 도메인 버전 모델링. 회사 구조를 이해하고 있다는 증거.
-
우리 회사 외에 다른 데도 지원했어요?
예상 꼬리질문- 다른 곳과 비교했을 때 여기를 고른 결정적 차이는 뭐였나요?
예시 답변현장실습이 한 학기 일정이라, 같은 기간에 현장실습을 받는 다른 GIS·공공데이터 SI 1~2곳에도 지원은 했습니다. 다만 면접까지 가서 비교한 것은 시선아이티가 유일합니다.
· 포인트솔직하게 1~2곳 지원 사실 + 면접까지 간 곳은 여기뿐.
개발자 정체성 · 기술관
개발자가 무엇이라고 보는지, 어떤 개발자가 되고 싶은지 등 직무 가치관.
-
개발자가 뭐라고 생각하나요?
예상 꼬리질문- 창작자로서 가장 만족스러웠던 순간은 언제였나요?
예시 답변창작자라고 생각합니다. 하늘 아래 같은 소프트웨어는 없으니까. 클린룸 구현을 해도 그것은 또 다른 소프트웨어가 되고, 개발은 곧 어떤 문제를 해결하기 위한 창작물을 만드는 일이라고 봅니다. 무엇을 만들지 고민하고 설계하는 과정이 이 직업을 매력적으로 만든다고 생각합니다.
· 포인트창작자 + 설계의 가치. 짧고 단단한 한 단락.
-
개발의 어떤 부분에서 흥미를 느꼈나요?
예상 꼬리질문- 상상한 걸 결과물로 만들다가 크게 실패했던 경험도 있나요?
예시 답변상상한 것을 결과물로 만드는 기쁨입니다. 음악을 잘했으면 가수를, 글을 잘 썼으면 소설가를 하고 싶었을지도 모르지만, 제가 남들보다 잘한다고 생각한 건 코딩을 할 줄 안다는 것이었고, 그래서 상상한 것을 실현할 수단은 코딩이었습니다. 개발자는 컴퓨터라는 샌드박스 안에서 어떤 것이든 만들어낼 수 있고, 그게 너무 좋습니다.
· 포인트개인 정서 + 본질적 매력.
-
어떤 개발자가 되고 싶어요? (5년 후)
예상 꼬리질문- '도메인 언어를 코드로 옮기는' 걸 실제로 해본 사례가 있나요?
- 번역가 역할이 구체적으로 어떤 상황에서 필요하다고 보세요?
예시 답변세 가지를 말하고 싶습니다. 첫째, 도메인의 언어를 코드로 옮길 수 있는 개발자입니다. 헌혈 데이터를 만졌을 때 가장 어려웠던 건 코드가 아니라 '분당혈액원'과 '헌혈의 집'의 차이, '전혈'과 '성분헌혈'의 분류가 행정적으로 어떻게 갈라지는지였습니다. 둘째, 도구가 바뀌어도 모델을 유지할 수 있는 개발자. 오늘 LangChain이 표준이듯 내일 또 다른 프레임워크가 표준이 될 수 있고, 그때 도구가 바뀌어도 도메인 모델은 살아남도록 만드는 사람이 되고 싶습니다. 셋째, 절차와 도구를 함께 설명할 수 있는 사람. SI의 특성상 기술만 잘하는 사람은 많고 절차를 아는 사람도 많지만, 그 둘을 같은 자리에서 설명할 수 있는 사람은 드뭅니다. 그 사이라의 번역가가 되고 싶습니다.
· 포인트도메인 모델 + 도구 독립성 + 번역가. 자소서 4번의 가치관과 일치.
-
본인이 생각하는 좋은 코드란?
예상 꼬리질문- 세 가지 기준이 서로 충돌하면 뭘 우선하시겠어요?
예시 답변세 가지로 봅니다. 첫째, 다음 사람이 읽었을 때 질문 없이 따라갈 수 있는 코드 — 똑똑한 한 줄보다 설명이 조금 더해진 세 줄이 그 자리를 차지하는 경우가 많습니다. 둘째, '이 코드가 왜 이렇게 생겼는가'의 흔적이 코멘트나 커밋 메시지에 남아 있는 코드. SI처럼 누가 무엇을 바꿨는지 추적해야 하는 환경에서는 그 흔적이 곧 문서가 됩니다. 셋째, 테스트가 붙어 있어 변경이 안전한 코드. 기능을 만들 때 같이 붙이는 테스트가 다음 리팩토링의 안전망이 됩니다.
· 포인트가독성 + 추적성 + 안전성. 자소서와 같은 결.
-
기술 부채라는 말 들어봤어요?
예상 꼬리질문- 그 크레이트 말고 다른 기술 부채 관리 경험도 있나요?
예시 답변들어봤고, 제 프로젝트에서도 직접 마주쳤습니다. 빨리 만들기 위해 예외 처리를 일부러 비워 두고 넘어간 자리가 결국 다음 단계의 작업 속도를 떨어뜨리는 누적된 비용입니다. oxi 생태계에서는 그 비용을 일부러 한 곳에 모았는데, oxicode-api-stability라는 크레이트가 SDK의 공개 API 표면을 고정해서 그 안쪽은 자유롭게 리팩토링할 수 있게 만듭니다. 부채를 허용하되 부채가 새는 경계를 명시적으로 정의해 두는 패턴입니다. SI에서 기술 부채는 '다음 외주 인력'이 짊어지는 비용이 되기 쉽기 때문에, 처음부터 부채가 어디에 쌓이는지 표시해 두는 습관이 중요하다고 봅니다.
· 포인트경계 명시화 패턴. SI에서 '다음 사람' 비용으로 연결.
-
다른 사람한테 물어보는 거 어떤가요?
예상 꼬리질문- 물어봤는데 상대방도 모르면 어떻게 하시나요?
예시 답변어렵지 않고 오히려 좋아합니다. 혼자 헤매는 것보다 5분이라도 옆 사람에게 물어보면 30분이 절약되는 경우가 훨씬 많습니다. 사회복무요원 시절에 신입이 들어오면 가장 먼저 한 말이 '모르는 게 있으면 그 자리에서 물어봐라, 잘못된 채로 두면 나중에 더 큰 비용이 든다'였습니다. 다만 물어보기 전에 내가 무엇을 알고 무엇을 모르는지부터 정리해서 가는 편입니다. 그래야 상대방이 답하기 쉽고 제가 답을 들은 다음에 검증할 수 있기 때문입니다.
· 포인트물어보기 전에 정리 — 절차 의식. 신입 때 들은 말을 본인이 따르고 있다는 인격적 인용.
기술 스택 · 직무 지식
Rust/Java/JS/Python/SVN/Git/프레임워크 등 실제로 사용해 본 도구와 깊이.
-
Rust로 개발했는데 왜?
예상 꼬리질문- Rust의 느린 컴파일 시간이 실제로 불편하지 않았나요?
- SI 현장에서 Rust를 못 쓰면 어떻게 하시겠어요?
예시 답변메모리 안전성을 컴파일 타임에 강제하는 게 가장 컸습니다. C/C++에서 댕글링 포인터나 데이터 레이스를 직접 짜본 적은 없지만, 매니지드 언어들에서도 가비지 컬렉션의 예측 불가능한 일시정지가 답답하게 느껴졌었고, Rust는 그 둘의 사이라고 들었는데 실제로 써 보니 그 말이 맞았습니다. 그리고 무엇보다 oxi 생태계 전체가 Rust로 짜여 있어서 Rust로 작성된 도구끼리는 도메인 모델을 그대로 공유할 수 있다는 실용적인 이유도 컸습니다. 한국 SI 현업에서 Rust 채용은 드물다는 건 알고 있어서, SI 절차와 Rust 도구를 동시에 들고 있는 사람으로 자라는 것이 여기서는 차별점이 될 수 있다고 생각하고 지원했습니다.
· 포인트메모리 안전 + oxi 통합성 + SI 차별점. 자소서 4번의 Rust 언급과 연결.
-
Java나 JS에 대한 경험은?
예상 꼬리질문- 스프링의 의존성 주입을 실제로 코드로 짜본 적은 있나요?
예시 답변Java는 안드로이드 앱을 만들 때 써봤고, 그 이후에 C#으로 유니티 게임을 몇 년 개발했는데 C#이 자바와 문법적으로 닮은 면이 많아서 자바 코드도 읽는 데 큰 무리는 없습니다. JavaScript/TypeScript는 oxi 생태계의 TUI와 컴패니언 앱들이 거의 다 TypeScript + React로 되어 있어서 일상적으로 다루고 있고, what-is-oxi라는 사이트를 Astro로 직접 빌드해서 유지하고 있습니다. SI 현업에서 쓰는 자바/스프링 패턴은 직접 짜본 적은 없지만 읽을 수는 있고, 스프링의 의존성 주입이나 트랜잭션 추상화 같은 개념은 한 번씩 짚고 넘어간 적이 있습니다.
· 포인트C# → Java, TS → SI 패턴. 솔직한 미경험 + 읽을 수 있다는 표현.
-
JAVA 경험은?
예상 꼬리질문- C#과 Java의 실제 차이를 하나만 들어주실 수 있나요?
예시 답변안드로이드 앱 만들 때 써봤습니다. 그 이후에 C#으로 유니티 게임 개발을 몇 년 했고, C#이 자바와 유사하다고 느꼈습니다. 최근에 직접 코드를 짠 적은 짧지만 문법이 비슷하기 때문에 금방 적응할 수 있다고 생각합니다.
· 포인트위 답변의 단축형.
-
Python 경험은?
예상 꼬리질문- 강화학습 모델을 학습시키면서 가장 어려웠던 부분은요?
예시 답변졸업 프로젝트에서 강화학습용 모델을 학습시키려 써봤습니다.
· 포인트짧게 한 줄.
-
SVN과 Git의 차이점은?
예상 꼬리질문- SVN을 안 써보셨는데 trunk/branch 개념은 알고 계신가요?
예시 답변둘 다 버전 관리이지만 저장 모델이 다릅니다. Git은 분산(DVCS) — 로컬에 전체 이력이 있고 커밋이 해시로 연결됩니다. SVN은 중앙집중(CVCS) — 중앙 서버가 진실의 원천이고 작업은 그 서버에서 checkout한 사본 위에서 일어납니다. SI에서 SVN이 아직 쓰이는 이유는 명확합니다 — 중앙 서버 기반이라 누가 무엇을 언제 커밋했는지 통제가 쉽고, 사내망·폐쇄망에서 외부로 이력을 빼가기 어렵습니다. 보안·감사 요건이 있는 발주처일수록 그쪽을 강제합니다. 기능적으로는 Git이 압도적으로 풍부하지만, SVN은 더 단순한 워크플로우를 강제하기 때문에 팀에 신입이 들어왔을 때 정해진 절차대로만 따라가면 되도록 통제하기는 더 쉬울 수 있습니다. Git은 개인 저장소 위주로 써 왔고 SVN은 다뤄 본 적이 없습니다. 마르미-III에서 SVN을 표준으로 두는 절차를 본 적이 있어 금방 적응할 수 있다고는 생각하지만 직접 trunk에 커밋해 본 적은 아직 없습니다.
· 포인트DVCS vs CVCS + SI의 SVN 잔존 이유. 끝이 미경험 → 의지로 닫힘.
-
프레임워크 선택 기준은?
예상 꼬리질문- 회사 디자인 시스템이 마음에 안 들면 어떻게 하시겠어요?
예시 답변디자인 프레임워크는 MUI → Mantine → Shadcn/ui 순으로 써 왔고, 지금은 oxi 생태계 앱들을 만들 때 고정으로 쓰고 있습니다. 디자인 토큰은 DESIGN.md라는 컨벤션 문서로 정의해 두고, 모든 앱이 그 토큰을 따라 패밀리룩을 유지하도록 하고 있습니다. 회사가 정한 디자인 시스템이 있다면 거기에 우선 맞춰서 들어갈 생각입니다.
· 포인트디자인 시스템 일관성. '회사가 정한 것이 있으면 따른다'로 끝.
-
LangChain은 안 써봤나요?
예상 꼬리질문- 직접 만든 RRF 결합 방식이 LangChain 기본 구현보다 나은 점이 있나요?
예시 답변써 본 적은 없습니다. 다만 그 프레임워크가 감싸고 있는 게 무엇인지는 알고 있습니다 — 툴 콜링 루프, 프롬프트 템플릿, 메모리 추상화, 벡터 스토어 어댑터 정도가 핵심이라고 보고 있습니다. 그래서 oxi 생태계를 만들 때 의도적으로 그 추상화 레이어를 직접 만들었습니다. 청킹(512/64), 임베딩(Dense + Sparse TF-IDF), HNSW+BM25의 RRF 결합까지 — 라이브러리 호출 한 줄로 끝낼 수 있는 것들을 직접 짜놓은 이유는, 그 안에서 무엇이 일어나는지 정확히 알아야 챗봇의 검색 품질이 나빠졌을 때 어디를 손봐야 하는지 판단할 수 있기 때문입니다. SI에서 LangChain 같은 도구를 쓴다는 것은 도구 벤더에 기능을 종속시키는 일이라고 보는데, 발주처 요구사항이 까다로울수록 그 안쪽을 알지 못하면 한계에 부딪힐 거라 생각합니다.
· 포인트안 써봄을 솔직히 + 무엇인지는 앎 + SI에서 안쪽을 아는 게 중요.
-
버그 만나서 가장 오래 막혔던 건요?
예상 꼬리질문- 그 버그를 더 빨리 찾을 수 있었던 방법은 없었을까요?
예시 답변oxi 생태계의 oxios-memory 쪽이었습니다. 메모리 백엔드를 SQLite WAL에서 redb로 옮기던 중에, 동시성 락이 자꾸 걸리는데 재현이 안 되는 종류의 버그였습니다. 결국 1주일 넘게 매일 새벽에 코드를 다시 읽다가, async drop 순서와 Arc clone이 drop되는 타이밍이 어긋난 부분이라는 걸 찾았습니다. 그 안의 MemoryStore 포트가 multi-writer를 가정하는데 백엔드 구현이 single-writer 락만 잡고 있었던 게 원인이었습니다. 이 경험에서 배운 건, 버그가 재현이 안 되는 건 내 환경이 아니라 모델이 잘못됐다는 신호일 수 있다는 점입니다. 그래서 같은 버그가 다시 나면 환경부터 의심하기보다 도메인 모델을 먼저 의심하게 됩니다.
· 포인트1주일 + redb + 도메인 모델. 깊이 있는 디버깅 사례.
-
코드 리뷰 드려본 적 있어요? 받거나 드리거나 어느 쪽이 더 어려웠어요?
예상 꼬리질문- 자동 코드리뷰 스킬이 놓친 부분을 사람이 잡은 적이 있나요?
예시 답변드려본 적은 없고, 받은 적은 oxi 생태계 작업을 하면서 몇 번 있습니다. 매일 새벽에 자동 코드리뷰 스킬을 돌리는데 거기서 나오는 리뷰는 사람이 짚는 것과 결이 비슷합니다. 더 어려웠던 쪽은 받는 쪽이었습니다. 제 코드는 늘 제 머릿속 모델이 그 안에 들어 있는데, 리뷰를 받는 순간 그 모델을 풀어서 설명해야 하거든요. 그 과정에서 제가 당연하다고 넘긴 가정이 상대방에겐 가정이 아니었던 적이 많았습니다. SI에서 짝 코드리뷰나 PR 리뷰가 절차로 강제되는 이유가 이것이라고 보고, 드리는 쪽이 아직 약하다고 생각해서 실습 들어가서부터는 그 자리를 특히 의식해서 들을 생각입니다.
· 포인트리뷰 = 모델 풀기. 드리는 쪽이 약하다는 솔직한 인정 + 의지.
-
오픈소스 기여해 본 적 있나요?
예상 꼬리질문- 외부 OSS에 기여하지 않은 특별한 이유가 있나요?
예시 답변별도의 외부 OSS에 PR을 올린 적은 아직 없습니다. 다만 oxi 생태계 전체 — oxicode, oxios, oxibrain, oxibrowser — 가 GitHub에 오픈소스로 공개되어 있고, 그 안에서 디자인 시스템을 통일하거나 CI를 고치는 작업은 일상적으로 하고 있습니다. 매주 새벽 자동화로 코드리뷰 보고서를 받아 그 발견 사항을 즉시 반영해 두는 흐름 자체가, 작은 규모지만 외부에서 컨트리뷰션이 들어왔을 때의 워크플로우와 비슷하다고 보고 있습니다. 발주처의 폐쇄망 정책 때문에 외부 OSS 도입이 까다로운 SI 환경에서는, 사내 저장소에서 어떻게 외부 컨벤션을 들여오는지가 결국 핵심이라서 그 연결 고리를 만드는 데 관심이 있습니다.
· 포인트외부 PR은 없음 + 사내 기여 + 폐쇄망 SI로 연결.
-
기술적으로 가장 자신 있는 분야는?
예상 꼬리질문- 그중 시선아이티 직무에 가장 먼저 쓰일 건 뭐라고 보세요?
예시 답변에이전트/도구 호출 흐름과 그 위의 데이터 파이프라인입니다. oxi 생태계의 oxicode-sdk, oxios-memory, oxibrain-ports를 직접 다루면서 LLM이 도구를 호출하고 그 결과가 다시 컨텍스트로 들어오는 루프가 어떻게 안정적으로 굴러가는지를 몸으로 알고 있습니다. 그다음은 정적 사이트 + 문서화 — Astro로 what-is-oxi라는 23개 페이지짜리 사이트를 빌드하고 있고, 그 안에서 MDX·Shiki·Tailwind v4를 조합해 한국어/영어 듀얼 다크모드를 구현했습니다. 시선아이티의 챗봇이 다루게 될 도메인 문서/매뉴얼을 다룰 때 이 경험이 직접 연결될 거라 봅니다. 그다음이 데스크톱/모바일 UI — Tauri + React. oxinot, oxiline 같은 Tauri v2 앱을 만들면서 Rust 백엔드와 React 프론트를 한 자리에서 연결한 경험이 있습니다.
· 포인트1) 에이전트 루프 2) 문서화 3) Tauri. 직무(챗봇)와 직접 매핑되는 순서로.
BIMS · 현장 경험
경기혈액원 사회복무요원 시절 적십자사 정보시스템 BIMS에서 본 것들.
-
직원들이 BIMS에서 보통 어떤 불편함을 호소했나요?
예상 꼬리질문- 그 문제를 본인이 직접 고쳐볼 권한이나 기회가 있었나요?
예시 답변실제 사용자가 사용하는 워크플로우와 앱이 제공하는 워크플로우가 일치하지 않는 경우가 자주 있었습니다. 예시로, 차트에서 소팅이 안 되거나, 수량 입력 시 숫자 인풋이 아니라 일반 인풋이 뜨거나, 모달창으로 즉시 수정할 수 있을 것 같은 부분이 별도 페이지로 라우팅되거나, 실시간 내역이 업데이트 안 돼 새로고침을 눌러야 하는데 새로고침하면 차트가 아니라 페이지 전체가 새로고침되는 경우가 있었습니다. 한 가지 구체적인 흐름을 말하자면, 사이드바에서 단체 정보 관리 → 섭외 장소 조회 → 담당자 전화 확인 → 다시 섭외 내역 관리 화면으로 이동해 내역 입력. 한 사용자의 연속된 작업이 사이드바 점프로 갈라져 있었습니다.
· 포인트구체 화면 4개 + 한 시나리오. 면접관이 '한 가지 화면 더' 물으면 BIMS 그 외 것들 1~2개.
-
그 경험을 통해 무엇을 배웠나요?
예상 꼬리질문- 그 배움을 실제 프로젝트에 적용해본 적이 있나요?
예시 답변실제 사용자의 워크플로우를 개발자 입장에서 상상하고 파악하는 것이 중요하다는 점이었습니다. 모든 가능한 경로에 진입점을 만들어 두는 것도 좋지만 시간과 자원은 한정되어 있고, 최대 효율로 최대 효용의 소프트웨어를 만들기 위해서는 사용자의 이용 방식과 경험을 미리 조사하고 상상하는 것이 필수라고 배웠습니다.
· 포인트워크플로우 파악의 가치. SI 입장에서 '요구사항을 먼저 묻는 습관'으로 연결.
-
자랑하고 싶은 만들어 본 것이 있나요? (5분 설명)
예상 꼬리질문- 결측치를 (min+max)/2로 폴백한 게 실제로 정확도에 영향을 줬나요?
- 이 모델을 실제 서비스로 배포까지 해봤나요?
예시 답변한 가지만 얘기하자면 헌혈량 예측 시스템입니다. 혈액관리본부 공개 API와 ASOS 기상 관측을 날짜로 join해서, 특정 일자에 헌혈량이 평균 대비 얼마나 줄거나 늘어날지 점수화한 모델을 만들었습니다. 5분 데모 흐름은: ① 데이터 입력 → ② 모델이 스냅샷 생성 → ③ 차트가 일자별로 예측 구간을 그림. 사용자는 차트 위에서 특정 일자만 콕 집어 그날의 헌혈량 추이를 볼 수 있고, ASOS 결측치(tempAvg 누락) 같은 케이스는 (min+max)/2로 폴백해 빈 자리가 안 생기게 했습니다. 자랑하고 싶은 이유는 모델 수학이 단순한 회귀라 정교하지는 않지만, 데이터 결합 → 스냅샷 → 시각화까지 파이프라인을 혼자 굴려 봤다는 점입니다. 어디서 무엇이 잘못되면 어디가 깨지는지 몸으로 익혔습니다.
· 포인트5분 안에 ①데이터 ②스냅샷 ③차트 → 폴백까지. 데이터 파이프라인 경험 강조.
-
다른 사람이 쓴 정의를 보고 그대로 구현해 본 적 있나요?
예상 꼬리질문- 엑셀 형식에 맞추면서 가장 까다로웠던 부분은요?
예시 답변솔직히 말해 그렇게 해 본 적은 없습니다. 개인 프로젝트에서는 늘 무엇을 만들지 제가 정해 왔고, 요구사항을 정하는 것도, 화면을 그리는 것도, 그에 맞춰 구현하는 것도 전부 제가 한 자리에서 일했습니다. 사회복무요원 시절에 가장 가까웠던 경험은, 혈액원 내 부서 간 데이터를 맞춰야 할 때 상대 부서가 정리해 준 엑셀 형식에 제 코드를 맞춰 넣었던 일입니다. 그때 느꼈던 건 — 제가 만드는 입장에서는 융통성 있게 만들어 두면 됐는데, 받아 쓰는 입장에서는 그 융통성이 오히려 매번 확인해야 할 예외가 된다는 점이었습니다. 그래서 SI에서는 '다른 사람이 만든 정의를 그대로 읽는 연습'이 절차의 일부라는 걸 알고 있고, 들어갔을 때 가장 먼저 손에 익혀야 할 것 중 하나라고 생각합니다.
· 포인트솔직한 미경험 + 사회복무 사례 + '들어간 다음에 익힐 것'. 자소서 2번과 같은 결.
AI 활용 · 정보 습관
해커뉴스, AI 도구 활용, 자동화 스킬 — 메타 인지/습관 질문.
-
해커뉴스 읽는다구요? 최근 흥미로운 게 있었어요?
예상 꼬리질문- 그 아티클을 읽고 실제로 설계를 바꾼 적이 있나요?
예시 답변여러 가지가 있었습니다. 한때 클로드 코드 코드베이스가 유출됐을 때 아키텍처 글이 막 올라와서 흥미롭게 읽었고, 오픈클로 열풍 이후에 제로클로, 나노클로 시리즈가 나왔을 때 각자 다른 구현 방식으로 클로 서비스가 나오는 걸 보는 것도 흥미로웠습니다. 그래서 그때부터 클로-라이크 서비스를 하나 만들려고 하다가 점점 발전해서 oxios라는 에이전트 개발 환경까지 오게 됐습니다. RAG나 세컨브레인, 마크다운 노트패드 같은 제품들도 한 번씩 읽고 있고, UX 구성을 보면서 챗봇 설계에 참고합니다. 주말에 읽은 아티클 하나가 — 'AI는 수학자보다 더 똑똑한 게 아니라 더 기억을 잘 하는 것이다'라는 글이었는데, AI의 컨텍스트 윈도우가 작업 기억의 확장이라는 관점이 챗봇 설계에 직접 연결된다고 봅니다. 그래서 SLM이 컨텍스트 윈도우가 작다는 제약을 고려해, 한정된 작업 기억 안에서 작업을 잘 수행하도록 설계해야 한다고 생각합니다.
· 포인트유출 → 아키텍처 학습 → oxios로 연결. 컨텍스트 윈도우 → 챗봇 설계로 착지.
-
AI를 어떻게 활용하고 있나요?
예상 꼬리질문- 자동화가 잘못된 방향으로 돌아간 적은 없었나요?
- AI가 짠 코드를 얼마나 그대로 믿고 쓰시나요?
예시 답변oh-my-pi라는 오픈소스 터미널 코딩 에이전트를 쓰고 있고, oxicode의 TUI는 아직 불편해서 안 씁니다. oxios로는 일상적인 질문이나 설계서 작성할 때 사용하고, 매일 새벽에 제 프로젝트들에 대한 코드리뷰와 간단한 버그 수정을 해서 감사 보고서 HTML로 작성해 이메일로 보내도록 자동화해 두었습니다. 해커뉴스에서 top 5 기사를 가져와 번역해 이메일로 보내는 것도 매일 돌고 있습니다. 코딩할 때에는 superpowers 플러그인을 기본으로 쓰고, 배포는 GitHub workflow로 crates.io 게시와 Tauri 앱 빌드를 등록해 두어서 린트·테스트 통과 후 태그 푸시만 하면 배포되도록 만들어두었습니다. 그리고 DESIGN.md를 글로벌 위치에 두고 모든 oxi 앱이 패밀리룩으로 디자인되도록 스킬로 이식하고 차이가 있는 부분은 감사·수정하도록 했고, 커밋이나 내부 문서 작성도 스킬로 만들어두었습니다.
· 포인트에이전트 + 자동화 + 디자인 시스템 일관성. 회사가 보면 '자동화 능력 있음'으로 읽힘.
-
마감 압박이 있을 때 어떻게 하나요?
예상 꼬리질문- 앞쪽에 시간을 들였는데도 마감을 못 맞춘 적은 없었나요?
예시 답변앞쪽에 시간을 더 들이는 편입니다. 마감 직전에 몰아서 하면 실수가 나고 그걸 고치는 데 더 오래 걸립니다. 작업을 받자마자 범위와 의존성부터 정리하고 위험한 부분을 먼저 처리해 둡니다. oxi 생태계에서도 모든 배포가 깃허브 워크플로우의 린트·테스트를 통과한 뒤에만 태그가 푸시되도록 자동화되어 있어서, 사람의 마감 압박이 시스템의 품질 게이트와 분리되어 있습니다. 이 구조가 실수를 줄이는 핵심이라고 보고, SI에서도 그 패턴을 들이고 싶습니다. 다만 SI의 마감은 외주·발주처 일정과 묶여 있어 개인이 통제하지 못하는 부분이 있고, 그때는 줄일 수 있는 범위와 양보할 수 없는 범위를 먼저 분리해 두는 것이 가장 중요하다고 배웠습니다.
· 포인트자동화 + 통제 가능/불가능 분리. 시험공부 비결과 같은 결.
약점 · 부족함
솔직한 약점 인정과 채울 방향 — 자소서 원칙(미경험→배움) 적용.
-
본인이 가장 부족하다고 느끼는 부분은?
예상 꼬리질문- 그 부족함 때문에 실제로 문제가 생긴 적이 있나요?
예시 답변두 가지입니다. 첫째, 다른 사람이 만든 정의를 읽고 그대로 구현해 본 경험이 가장 부재합니다. 늘 무엇을 만들지 제가 정해 왔기 때문에, 명세서를 받아 그에 맞춰 구현하는 흐름이 익숙하지 않습니다. 둘째, 형상관리와 테스트 자동화입니다. 개인 저장소 위주로만 Git을 써 왔고 SVN은 다뤄 본 적이 없습니다. 단위 테스트는 뽑아 본 적이 없고, 통합 테스트와 SP 인증 기준에 맞춘 최종 산출물은 처음입니다. 다만 이 부족함은 들어가고 나서 채울 수 있는 부족함이라고 봅니다. 1단계의 산출물 양식을 빠르게 흡수해서 2단계에서 검색 품질 평가 같은 정량 작업에 기여하는 방향으로 메울 계획입니다.
· 포인트자소서 3번 P6의 '배울 것' 정렬과 같은 결. 끝이 의지로 닫힘.
-
다른 직원이 일을 안 한다면 나는 어떻게 할 것인가?
예상 꼬리질문- 그게 반복되면 그때도 그냥 넘어가실 건가요?
예시 답변사실 업무라는 걸 안 해봤으니 다른 직원이 일을 안 하면 그게 그대로 제가 해야 할 일이 되는 건지 잘 모르겠습니다. 다만 저는 타인이 일을 안 하는 건 상관이 없고, 저는 제가 할 수 있는 만큼 언제나 최선을 다해 일을 하겠습니다. 여유가 생겨서 동료의 업무가 흘러들어온다면 그것도 제가 할 수 있다면 그대로 할 것 같습니다. 대학 때 팀프로젝트에서도 그런 일이 있었는데 그냥 제가 했고, 오히려 더 많은 부분에 참여하면서 성장하는 느낌이 들어서 싫지만은 않았습니다. 다만 이 태도를 강요하지는 않겠습니다 — 제가 할 수 있을 때 하는 것이지, 동료의 책임을 대신 지겠다는 뜻은 아닙니다.
· 포인트솔직한 '잘 모르겠다' + 성장 기회 + 마지막에 '강요하지 않겠다' 한계 명시.
-
학점이 좋네요? 비결이 있다면?
예상 꼬리질문- 학점 관리와 실무는 다를 수 있는데, 그 차이는 어떻게 보세요?
예시 답변감사합니다. 따로 비결은 없고, 남들 일주일 전에 준비할 때 저는 한 달 전부터 준비했습니다. 몰아서 처리하느라 밤을 새우는 게 싫어서 그렇게 하게 됐습니다.
· 포인트짧고 단단. 야근 답변과 같은 결 — '미루는 비효율을 싫어한다'.
CS · SI 기초 지식
면접에서 가볍게 나올 수 있는 기술 용어. 자소서 미경험 항목을 '읽을 수 있다' 수준으로.
-
REST API와 GraphQL의 차이가 뭔가요?
예상 꼬리질문- GraphQL을 실제로 써본 적은 있나요?
- N+1 문제 들어보셨나요?
예시 답변REST는 리소스 중심 — /users/123처럼 URL이 자원을 가리키고 HTTP 메서드(GET/POST/PUT/DELETE)로 그 자원에 무엇을 할지 표현합니다. 클라이언트가 필요 이상/이하의 데이터를 받기 쉬운 게 단점입니다. GraphQL은 쿼리 중심 — 클라이언트가 받고 싶은 필드만 한 요청에 명시합니다. 한 번에 여러 자원을 묶어 가져올 수 있고, 화면이 자주 바뀌는 모바일 앱에서 효율이 좋습니다. 단, 서버 구현 복잡도와 캐싱이 어렵다는 트레이드오프가 있습니다. 공공데이터 API는 거의 다 REST인데, 시군구별로 응답 필드가 조금씩 다른 경우가 있어 GraphQL의 단일 스키마가 더 깔끔할 수 있는 영역이라고 생각합니다. 다만 발주처의 표준을 따라야 하는 SI 특성상 도구 선택보다 표준 준수가 먼저입니다.
· 포인트SI에서는 표준이 도구 선택보다 우선이라는 결로 닫기.
-
CORS가 뭔가요?
예상 꼬리질문- preflight 요청이 뭔지 아시나요?
예시 답변Cross-Origin Resource Sharing의 약자입니다. 브라우저가 보안을 위해 한 출처(origin)의 페이지에서 다른 출처로 요청을 보낼 때, 서버가 명시적으로 허용해 주지 않으면 차단하는 정책입니다. 챗봇 같은 프론트엔드를 만들 때 API 서버가 다른 도메인에 있으면 이 정책을 먼저 풀어야 화면에서 호출이 됩니다. 서버 쪽에서 Access-Control-Allow-Origin 헤더로 어디를 허용할지 정해 주는 식으로 동작합니다. SI 시스템은 보통 백엔드/프론트가 다른 도메인(혹은 포트)으로 분리되기 때문에 개발 초기에 한 번씩 부딪히는 이슈이고, 단순히 헤더 한 줄이라고 보기보다 그게 어떤 보안 모델 위에 있는 정책인지를 알아 두는 것이 맞다고 봅니다.
· 포인트보안 모델 위에 있는 정책이라는 인식으로 깊이 표시.
-
OOP가 뭔가요? 왜 쓰나요?
예상 꼬리질문- 다형성을 실제 코드로 짜본 예시를 들어주실 수 있나요?
예시 답변객체 지향 프로그래밍 — 데이터와 그 데이터를 다루는 함수를 하나의 단위(객체)로 묶고, 그 객체들 사이의 관계(상속·합성·다형성)로 프로그램을 구성하는 패러다임입니다. 현실 세계의 개념을 코드로 옮길 때 매핑이 자연스럽고, 같은 인터페이스를 구현한 여러 객체를 갈아 끼우기 쉬워서 변경에 강해지기 때문입니다. 다만 저는 Rust로 개발하면서 OOP의 '상속'보다 트레이트(인터페이스) 중심의 다형성을 더 많이 쓰게 되었습니다. 상속의 강제 결합이 컴파일러에 의해 거부되기 때문인데, 이게 Rust의 디자인 철학이기도 합니다.
· 포인트OOP 정의 + Rust의 트레이트 다형성으로 실제 사용 경험 연결.
-
TDD가 뭔가요? 해 본 적 있나요?
예상 꼬리질문- 테스트를 안 짜서 실제로 문제가 생긴 적이 있나요?
예시 답변Test-Driven Development — 실패하는 테스트를 먼저 작성하고, 그 테스트를 통과시키기 위한 최소 코드를 짜고, 그다음에 리팩토링하는 흐름을 반복하는 개발 방식입니다. 해 본 적은 거의 없습니다. 개인 프로젝트에서는 늘 기능을 먼저 만들고 테스트는 그 후에야 붙였습니다. 그래서 지금 제 코드는 테스트 커버리지가 낮고, 그게 약점이라고 솔직히 말할 수 있습니다. 마르미-III의 단계별 산출물에는 단위 테스트와 통합 테스트가 들어 있는 걸로 알고 있어서, 들어갔을 때 TDD 흐름을 의식적으로 시도해 보겠습니다. 특히 챗봇의 검색 품질을 평가셋으로 검증하는 일은 TDD의 형식과 잘 맞는다고 보고 있습니다.
· 포인트약점 솔직 인정 + 챗봇 평가셋으로 TDD 착지.
-
ORM이 뭔가요?
예상 꼬리질문- N+1 쿼리 문제를 ORM에서 어떻게 방지하는지 아시나요?
예시 답변Object-Relational Mapping — 관계형 데이터베이스의 테이블을 객체처럼 다룰 수 있게 해주는 도구입니다. SQL을 직접 쓰지 않고도 객체를 저장하고 불러올 수 있습니다. Java의 JPA/Hibernate, Python의 SQLAlchemy, Node의 Prisma가 대표적입니다. 직접 SQL을 짜는 것보다 마이그레이션과 모델 변경에 강한 편이지만, 복잡한 쿼리에서는 결국 raw SQL로 빠지는 한계가 있습니다. SI에서 ORM은 마이그레이션 도구로 가장 많이 쓰인다고 알고 있습니다. 스키마 변경을 코드로 추적할 수 있고, 여러 환경(dev/staging/prod)에 같은 변경을 일관되게 적용할 수 있기 때문입니다.
· 포인트SI에서의 활용 = 마이그레이션 도구로 회수.
-
컴포넌트와 모듈의 차이가 뭔가요?
예상 꼬리질문- React 컴포넌트를 직접 설계할 때 경계를 어떻게 나누시나요?
예시 답변모듈은 일반적으로 언어 차원의 분리 단위 — 파일·네임스페이스·패키지. '이 코드 묶음은 무엇을 한다'의 경계입니다. 컴포넌트는 보통 UI/프론트엔드에서 쓰이는 용어로, 자기 자신의 상태와 라이프사이클을 가진 독립 단위입니다. React 컴포넌트가 대표적입니다. 비유하자면, 모듈은 책의 장(chapter)이고 컴포넌트는 페이지 안의 위젯에 가깝습니다. SI 프론트엔드를 만들 때 이 둘을 혼동하면 한 화면의 변경이 다른 화면까지 새는 일이 생깁니다. 그래서 의식적으로 컴포넌트 경계를 좁게 유지하는 편이 안전합니다.
· 포인트비유 + SI 프론트엔드 경계.
자소서 크로스체크
자기소개서 원문에만 있고 다른 Q&A에는 없는 구체적인 디테일 — 자소서를 읽은 면접관이 직접 파고들 수 있는 지점들.
-
졸업 연구 '추격 NPC 난이도 조절'이 정확히 어떤 프로젝트였나요?
예상 꼬리질문- 보상/패널티 식을 구체적으로 어떻게 바꿔보셨나요?
예시 답변플레이어의 이동 경로를 강화학습으로 학습시켜서, NPC가 플레이어의 성장 속도에 맞춰 계속 추격 난이도를 조절하도록 만든 졸업 연구였습니다. 보상과 패널티 식을 여러 번 바꿔가며 어느 구성이 잘 배우는지 누적 보상으로 비교했고, 학습에 쓰지 않은 새로운 경로에서도 잘 예측하는지까지 검증했습니다. 이 과정에서 게임 개발 자체보다 학습이 실제로 무엇을 배우고 있는지 확인하는 쪽에 더 흥미를 느꼈고, 그게 지금 AI·에이전트 쪽으로 방향을 튼 계기가 됐습니다.
· 포인트자소서 1번 문항의 원류. 강화학습 프로젝트(포트폴리오 Runaway)와 직접 연결.
-
사회복무요원 때 만든 도구가 내부망 문제로 못 쓰였다고 하셨는데, 어떤 도구였나요?
예상 꼬리질문- 그 이후로 실제로 도입 환경부터 먼저 확인한 사례가 있나요?
예시 답변반복 업무를 자동화하는 웹 앱이었는데, 업무용 PC가 내부망에 묶여 있어서 제가 만든 외부 웹 앱에 접속 자체가 안 됐습니다. 만들 때는 '이게 왜 좋은지'만 생각했지, '이게 실제로 그 자리에 배치될 수 있는 환경인지'는 확인하지 않았던 겁니다. 그 이후로 만들기 전에 도입 환경(망 분리, 권한, 열람 제한)부터 먼저 확인하는 습관이 생겼고, 그게 지금 SI 절차를 배우고 싶은 이유와 직접 연결됩니다.
· 포인트자소서 1번의 핵심 좌절 사례. '무엇을 만들지보다 어떻게 도입할지'로 착지.
-
헌혈량 예측 프로젝트가 상급 기관 API가 닫혀서 중단됐다고 하셨는데, 그 이후엔 어떻게 하셨나요?
예상 꼬리질문- 공식 Open API가 없는 데이터는 어떻게 다루시겠어요?
예시 답변그 시점에 데이터 소스 자체가 끊겨서 파이프라인을 그대로 이어갈 수는 없었습니다. 다만 스냅샷으로 모아뒀던 데이터와 모델 구조는 남아 있어서, 그걸 정리해서 지금 포트폴리오의 헌혈량 예측 데모로 다시 구성했습니다. 이 경험에서 배운 건, 외부 API에 의존하는 파이프라인은 그 API가 언제 사라져도 이상하지 않다는 전제를 깔고 설계해야 한다는 점입니다. 공공데이터도 마찬가지라고 보고, 계약이 명시된 공식 Open API 쪽을 우선하고 스크래핑성 접근은 최후 수단으로 두려 합니다.
· 포인트실패를 '설계 원칙'으로 승화. 공공데이터 안정성에 대한 감각을 보여줌.
-
문진 기준 데이터베이스는 정식 도입이 안 됐다고 하셨는데, 왜 안 됐나요?
예상 꼬리질문- 내부 기준에 접근할 수 있었다면 다르게 만들었을까요?
예시 답변적십자사 홈페이지에 공시된 문진 기준을 가져다 썼는데, 그 공시 데이터가 실제 내부 심사 기준과 미묘하게 달랐습니다. 저는 공개된 정보만으로 만들었지만, 실제 판단은 더 최신이거나 더 세부적인 내부 지침을 따라야 했던 거죠. 그래서 정식 도입까지는 못 갔고, 소집해제 직전까지 저와 몇몇 동료만 참고용으로 썼습니다. 여기서 배운 건 '공개된 자료 = 최신 기준'이 아니라는 점이고, SI에서는 그 기준의 출처와 갱신 주기까지 확인하는 게 절차의 일부라는 걸 알게 됐습니다.
· 포인트공시 데이터 vs 내부 기준의 괴리. 데이터 신뢰성에 대한 감각.
-
만든 것을 조직에 제안했다가 받아들여지지 않은 경험이 있나요?
예상 꼬리질문- '심사하는 사람의 언어'로 옮긴다는 게 구체적으로 어떤 건가요?
예시 답변네, 두 가지가 있습니다. 하나는 명단 출력을 자동화한 웹 앱이었는데, 기존 방식이 익숙하다는 이유로 안 쓰여서 중지됐습니다. 다른 하나는 헌혈버스 기념품 관리 키오스크였는데, 사내 업무개선 제안 공모전에 냈고 지사 심사는 통과했지만 본사에서 떨어졌습니다. 돌아보면 두 경우 다 '무엇을 만들었는지'는 설명했지만 '왜 필요한지'를 심사하거나 결정하는 사람의 언어로 옮기지는 못했던 것 같습니다. 그 이후로는 제안할 때 기능 나열보다, 그 기능이 없어서 지금 발생하는 비용(시간·오류·반복 작업)을 먼저 숫자로 짚으려고 합니다.
· 포인트설득 실패 → '언어 번역 실패'로 재정의. 자소서 2번 핵심 에피소드.
-
자소서에 시간 관리가 약점이라고 하셨는데, 지금은 어떻게 관리하고 계신가요?
예상 꼬리질문- '이번엔 안 넣을 것'을 정했는데 나중에 꼭 필요해진 적은 없었나요?
예시 답변개인 프로젝트에는 마감이 없다 보니, 릴리스할 수 있는 상태가 됐는데도 계속 기능을 추가하다가 몇 달씩 늘어지는 게 진짜 문제였습니다. 지금은 스스로 마감을 정하고, 이번 버전에는 넣지 않을 것을 먼저 적어 둔 다음 시작합니다. '더 넣을 수 있는 것'과 '이번엔 안 넣을 것'을 미리 갈라두면, 마감이 다가와도 무엇을 포기해야 할지 헤매지 않습니다. 다만 이 규칙이 아직 완전히 정착된 건 아니라서, SI처럼 외부 일정(발주처, WBS)이 마감을 정해주는 환경에서 그 규칙이 더 단단해질 거라 기대합니다.
· 포인트자소서 2번의 '시간 관리' 약점 — 다른 답변들엔 없던 축이라 여기서 처음 정면으로 답함.
-
대화 설계와 프롬프트 최적화를 다뤄본 적 없다고 하셨는데, 어떻게 배우실 계획인가요?
예상 꼬리질문- 기존에 짠 모호성 처리 로직을 구체적으로 설명해주실 수 있나요?
예시 답변제가 만든 도구는 저 혼자 쓰는 거라 '모르면 다시 물어보면 그만'이었는데, 챗봇은 모르는 걸 모른다고 명확히 말하지 못하면 그 자체로 신뢰를 잃습니다. 그 차이가 제가 안 다뤄본 영역이라고 생각합니다. 배우는 방법은 두 가지로 잡고 있습니다. 첫째, 실습 초반에 기존 챗봇의 응답 로그(혹은 유사 사례)를 보면서 '어디서 모호하게 답했는지'를 직접 분류해보는 것. 둘째, 제가 이미 만든 모호성 처리 로직(에이전트가 섣부르게 답하지 않도록 짠 부분)을 대화 설계 관점에서 다시 리뷰해서, 챗봇에 맞게 고쳐 쓰는 것입니다.
· 포인트미경험 → 구체적 학습 계획 두 가지로 착지. 자소서 3번과 같은 결.
-
LangChain 공식 문서를 실습 전까지 학습해보겠다고 자소서에 쓰셨는데, 지금 어디까지 하셨나요?
예상 꼬리질문- 비교해보고 LangChain이 확실히 더 낫다고 느낀 부분이 있었나요?
예시 답변계속 진행 중입니다. 지금까지는 체인 구성, 프롬프트 템플릿, 메모리 추상화 같은 기본 개념 문서를 훑었고, 제가 직접 구현했던 융합·청킹·감쇠 로직이 LangChain의 기본 제공 컴포넌트와 어디가 같고 어디가 다른지 비교해보는 단계입니다. 실습 시작 전까지 작은 체인 하나는 직접 돌려보고, 제가 만든 구조와 비교한 메모를 정리해서 가져가는 게 목표입니다.
· 포인트정직하게 '진행 중' — 완료했다고 과장하지 않음. 구체적 다음 행동으로 착지. 실제 진행 상황에 맞게 수정해서 쓸 것.
-
'지식'과 '기억'을 굳이 두 시스템으로 나눈 이유가 뭔가요?
예상 꼬리질문- 하나로 합쳤다면 실제로 어떤 문제가 났을 것 같나요?
예시 답변둘의 성격이 근본적으로 다르기 때문입니다. 지식은 사용자가 직접 쓰고 고치는 마크다운 문서라 생애 주기가 없고, 색인이 틀어져도 원본 파일에서 언제든 다시 만들 수 있습니다. 기억은 에이전트가 스스로 알아낸 것을 저장하는 구조화된 데이터라, 사용자가 직접 고칠 수 없고 시간이 지나면 감쇠·압축·정리가 필요합니다. 이 둘을 하나의 저장소로 합쳤다면, 사용자가 쓴 문서까지 자동으로 감쇠되거나 에이전트가 알아낸 기억을 사용자가 실수로 편집해버리는 문제가 생겼을 겁니다. 회상은 같은 검색 계층으로 꺼내지만, 저장과 생애 주기는 분리해야 한다는 게 설계의 핵심이었습니다.
· 포인트자소서 4번의 가장 기술적인 설계 결정. 면접에서 직접 나올 확률 높음.
-
Flash Attention을 라이브러리 대신 직접 구현하신 이유가 있나요?
예상 꼬리질문- 표준 라이브러리를 나중에라도 다시 검토할 계획이 있나요?
예시 답변검색 결과를 재순위할 때, 표준 라이브러리들이 가정하는 입력 형태(토큰 시퀀스, 고정 배치 크기)가 제 검색 결과 구조(가변 개수의 청크, 메타데이터 포함)와 잘 안 맞았습니다. 그리고 제가 다루는 재순위 규모는 GPU 클러스터가 필요한 큰 배치가 아니라, 검색 결과 수십 개 안에서 문맥 관련성을 빠르게 재정렬하는 정도라서, 그 규모에 맞게 가볍게 직접 짜는 편이 의존성도 줄고 제가 그 안에서 무엇이 일어나는지 정확히 통제할 수 있었습니다. 실제로 검색 품질 문제가 생겼을 때 라이브러리 블랙박스를 열어보는 대신 제 코드를 바로 고칠 수 있었던 것도 컸습니다.
· 포인트직접 구현 이유 — 입력 형태 불일치 + 통제 가능성. 준비 없이 답하면 '그냥 해봤다'로 들릴 위험이 있는 질문.
-
인지 과학(SOAR/ACT-R)에서 따온 아홉 가지 기억 타입이 뭔가요?
예상 꼬리질문- 세 단계 중요도 분류는 실제로 회상 정확도에 얼마나 영향을 줬나요?
예시 답변아홉 개 명칭을 전부 나열하기보다, 설계 의도를 말씀드리는 게 더 정확할 것 같습니다. SOAR/ACT-R 같은 인지 아키텍처 모델은 기억을 '무엇을 기억하는가'에 따라 여러 층으로 나눕니다 — 예를 들어 절차적 기억(어떻게 하는지), 의미적 기억(사실), 일화적 기억(경험) 같은 구분입니다. 저는 이 아이디어를 가져와서 에이전트가 알아낸 것들을 성격별로 나눠 저장하고, 중요도에 따라 세 단계로 분류해 감쇠 속도를 다르게 뒀습니다. 사람이 모든 기억을 똑같은 무게로 안 다루듯이, 에이전트 기억도 종류에 따라 다르게 다뤄야 회상이 정확해진다고 본 겁니다.
· 포인트아홉 개 명칭을 못 외웠어도 설계 의도로 답변 — 솔직하고 안전한 우회 전략.
-
Dream이라는 백그라운드 작업은 정확히 뭘 하나요?
예상 꼬리질문- 압축 중에 중요한 정보가 유실될 위험은 없나요?
예시 답변기억이 쌓이기만 하면 오히려 찾기 어려워지기 때문에, 일정량이 넘으면 비슷한 기억끼리 묶어 요약하고 쓸모없는 걸 정리하는 백그라운드 작업입니다. 네 단계로 나눠서 점진적으로 진행하고, 중간에 멈춰도 체크포인트에서 이어서 끝낼 수 있게 만들었습니다. 사람이 잠들었을 때 낮 동안의 기억을 정리한다는 비유에서 이름을 가져왔고, 사용자가 직접 관리하지 않아도 자주 쓰는 기억은 살아남고 안 쓰는 기억은 자연스럽게 정리되도록 하는 게 목적입니다.
· 포인트이름의 유래(수면 중 기억 정리 비유) + 체크포인트 재개 가능성까지.
면접 직전 점검 메모
- 자소서 1번 결론 — 좌절 세 번의 이유가 전부 절차와 권한 바깥. 그래서 SI 절차가 필요한 것.
- 자소서 2번 결론 — 만든 다섯 종 중 셋은 지금도 쓰임. 다인 개발의 결핍을 절차가 정해진 환경에서 보완하겠다는 의지.
- 자소서 3번 결론 — 1단계는 산출물 양식 매핑, 2단계는 평가셋 → 정량 비교, 끝은 다른 사람이 이어받을 수 있는 상태로.
- 자소서 4번 결론 — RAG는 직접 구현. oxicode-sdk 16 port, oxios-memory 3계층, oxibrain-ports 5 trait — 면접에서 5분 설명 가능.
- 회사 특정성 — 챗봇 + 공공데이터의 교집합. 폐쇄망, 행정 도메인의 '버전 있는 현실'.
- 마지막이 인상이 된다 — 모든 답변은 약점 고백이 아니라 의지형으로 닫을 것.