시선아이티 면접 Q&A
면접 일정: 2026-08-18 13:30 · 실습기간 2026-09-01~12-31 (계획서 기준). 22개 핵심 질문에 대한 한국어 답변. 각 답변은 oxi 생태계 코드베이스 + LangChain 표준 + Java/JSP·eGovFrame + ForGIS·sLLM 스택 추정을 결합. 질문마다 예상 꼬리질문을 붙였고, "내 답변 써보기"로 직접 타이핑하며 연습할 수 있다 — 입력한 내용은 이 브라우저에만 저장된다.
22개 핵심 Q&A
- 01
자기소개 + 왜 시선아이티인가?
예상 꼬리질문- oxi 프로젝트가 시선아이티 실무에 구체적으로 어떻게 연결되나요?
- Rust로 배운 걸 GIS/SI 실무에 어떻게 적용할 수 있을까요?
예시 답변GIS·AI·공간정보 기반 IT기업이라는 점이 흥미롭습니다. 특히 '공공기관 실 업무에 사용할 지능형 인터페이스'와 'Seesun LLM 플랫폼 자체 보유'라는 점이 인상적입니다. 저는 oxicode/oxibrain/oxibrowser/oxios 4개 Rust 프로젝트로 AI 에이전트 + 메모리 + 브라우저 + OS 풀스택을 바이브코딩으로 만들었고, 그 과정에서 RAG·LLM·memory·agent orchestration을 깊이 경험했습니다. 시선아이티가 자체 LLM 플랫폼을 보유하고 LangChain 표준을 따르면서도 Rust 풀스택의 가능성을 탐색하는 단계라면, 제 경험이 직접적으로 기여할 수 있다고 생각합니다.
- 02관련 페이지 →
GIS가 무엇인가요? 공간정보와 AI를 어떻게 융합할 수 있나요?
예상 꼬리질문- 포함/교차/최근접 같은 공간 질의를 직접 구현해본 적 있나요?
- PostGIS를 안 써보셨다면 어떤 부분이 걱정되나요?
예시 답변GIS는 지리 데이터를 수집·저장·분석·시각화하는 시스템입니다. 벡터(점·선·면)와 래스터(위성영상) 데이터를 다루고, 좌표계 변환·지오코딩(주소→좌표)·공간 질의(포함/교차/최근접)가 핵심 연산이며, 공간 인덱스는 R-Tree, 공간 DB는 PostGIS가 표준입니다. AI 융합은 두 가지 — (1) 자연어→공간 질의 변환: '가장 가까운 지점은' 같은 발화를 LLM이 의도 파악 후 지오코딩·공간 연산 API를 tool-calling으로 실행, (2) 경로 최적화·최적 입지 같은 조합 최적화에 ML/휴리스틱 적용. 저는 optimal-route-planner에서 비대칭 TSP를 Branch and Bound로 정확 풀이하고 LRU 캐시를 붙인 경험이 있어, 공간정보 도메인의 고전 문제를 직접 다뤄봤습니다.
- 03관련 페이지 →
LangChain을 왜 쓰나요? 다른 프레임워크와 차이는?
예상 꼬리질문- LangChain을 실제로 프로젝트에 써본 적 있나요?
- LCEL 없이 순수 Python으로 같은 걸 만들면 뭐가 달라지나요?
예시 답변LangChain은 Python 진영의 LLM orchestration 표준입니다. 80+ provider, 100+ vector store, 50+ document loader 통합이 가장 성숙하고, LCEL(LangChain Expression Language)로 chain/agent를 Runnable 프로토콜로 표준화할 수 있습니다. LangGraph로 stateful multi-agent, LangSmith로 observability까지 제공합니다. LlamaIndex는 RAG-first 설계로 retrieval/ingestion이 더 성숙하고, Haystack은 엔터프라이즈 RAG + REST API 배포에 강합니다. AutoGen은 Microsoft Research의 multi-agent 대화 프레임워크로 GroupChat 패턴이 직관적입니다. 시선아이티처럼 RAG + chatbot + SI 시스템 연동이 모두 필요하면 LangChain이 표준이고, RAG만 heavy하게 하면 LlamaIndex가 더 적합합니다.
- 04관련 페이지 →
RAG를 어떻게 구현하나요?
예상 꼬리질문- chunk 크기는 어떻게 정하나요?
- retrieval 결과가 엉뚱할 때 어디부터 디버깅하나요?
예시 답변RAG는 (1) 문서 ingestion + chunking + embedding + vector store 색인, (2) query → retrieval → rerank → context packing, (3) prompt + retrieved context → LLM generation 3단계입니다. Seesun LLM 플랫폼 위에서 LangChain Retriever + VectorStore + Reader를 구성하거나, LlamaIndex의 QueryEngine을 사용합니다. oxibrain은 in-house로 L0 retrieval stack을 구현했는데 — n-gram Jaccard lexical (FTS5) + dense vector (sqlite-vec) + RRF fusion + MMR rerank + token budget 기반 context packing. P11 invariant 'No language is privileged'로 다국어 동일 처리합니다.
- 05관련 페이지 →
'챗봇이 내부 시스템과 연동된다'는 게 기술적으로 무슨 뜻인가요?
예상 꼬리질문- tool-calling이 잘못된 인자를 넘기면 어떻게 처리하나요?
- 내부 API 호출 권한은 어떻게 통제하시겠어요?
예시 답변LLM tool-calling(function calling) 이야기입니다. 계획서의 '단순한 키워드 매칭을 넘어 사용자의 의도와 문맥을 파악하며 SI로 구축된 내부 시스템과 연동' — 즉 LLM이 사용자 발화에서 의도와 파라미터를 추출해 내부 API를 호출하고, 그 결과를 받아 자연어로 요약·안내하는 패턴입니다. 구현은 (1) 내부 시스템 API를 tool schema로 정의, (2) LLM이 어떤 tool을 어떤 인자로 호출할지 결정, (3) 실행 결과를 context에 넣어 답변 생성. oxicode-ai가 이 구조를 구현했습니다 — native tool use 지원 provider + 미지원 모델을 위한 dialect 텍스트 프로토콜 폴백. oxios는 외부 API를 AgentTool로 wrap하고 with_auth로 권한을 통제합니다. 공공기관 특성상 호출 감사(audit trail)까지 함께 설계하면 완성도 있는 답이 됩니다.
- 06관련 페이지 →
마르미-III 방법론을 아나요?
예상 꼬리질문- 실제로 마르미-III 산출물을 작성해본 적 있나요?
- 애자일이랑 마르미-III를 같이 쓸 수 있나요?
예시 답변한국 정보화 사업의 표준 방법론입니다. 정보화 사업 감리법인 등록 기준에 따라 공공 SI 사업은 마르미-III 적용이 의무입니다. 5단계 (분석 → 설계 → 구현 → 시험 → 운영) + 130+ 표준 산출물로 구성됩니다. 분석 단계에서는 요구사항 정의서 + WBS, 설계 단계에서는 화면설계서 + 테이블 명세서 + ERD, 구현 단계에서는 단위 테스트 + 코드 리뷰, 시험 단계에서는 통합 테스트 + 결함 관리표, 운영 단계에서는 사용자 매뉴얼 + 유지보수 계획서. oxi 생태계는 표준 방법론을 직접 구현하지 않지만, oxicode-cli의 18개 subcommand가 SI 프로젝트 운영 패턴과 동형입니다.
- 07
AI Chatbot에서 페르소나와 프롬프트 엔지니어링은 어떻게?
예상 꼬리질문- 프롬프트 인젝션은 어떻게 방어하나요?
- 페르소나가 여러 개일 때 전환은 어떻게 하나요?
예시 답변페르소나는 chatbot의 정체성/캐릭터로 system prompt fragment로 표현됩니다. 시선아이티는 공공기관 실 업무용 chatbot이라 응답 스타일/말투 + 도메인 지식이 결합된 페르소나가 필요합니다. oxicode-sdk의 PersonaProvider port가 selectable name으로 페르소나를 주입합니다. 프롬프트 엔지니어링은 few-shot + chain-of-thought + ReAct 패턴으로 정확도를 높이고, oxicode-ai의 dialect 모듈(coercion/history/render/xml/mod)이 native tool 지원 없는 모델을 위한 텍스트 기반 tool-calling 형식을 제공합니다. oxibrain M10의 'Few-shot selection from golden corpus' 패턴이 정답입니다.
- 08
LLM 평가 지표는 무엇인가요? hallucination 어떻게 잡나요?
예상 꼬리질문- 사람이 직접 평가하는 것과 LLM-as-judge 중 뭐가 더 신뢰도 높나요?
- hallucination을 100% 막을 수 있나요?
예시 답변평가 지표는 (1) accuracy (정답 일치율), (2) precision/recall (retrieval quality), (3) faithfulness (답변이 retrieved context에 근거하는가), (4) hallucination rate (근거 없는 답변 비율), (5) latency (응답 시간), (6) cost (token 비용)입니다. oxibrain의 EvalMetrics가 fabricated_entity_rate (구조적 0.00 검증), statement_precision/recall, resolution_f1를 측정합니다. LLM-as-judge 패턴으로 자동 평가하고, LangSmith/Langfuse/Helicone 같은 외부 도구로 실시간 모니터링합니다. hallucination은 RAG + grounded generation + claim-level verification으로 잡습니다.
- 09
ERD/WBS 어떻게 그리나요? 어떤 도구를 쓰나요?
예상 꼬리질문- 정규화를 어디까지 하는 게 적절하다고 보나요?
- WBS 일정이 밀리면 어떻게 대응하나요?
예시 답변ERD는 ERMaster(한국 공공 표준), draw.io, MySQL Workbench, dbdiagram.io를 씁니다. WBS는 MS Project, JIRA, OpenProject를 씁니다. 시선아이티는 공공 SI 사업이라 표준 산출물이 중요합니다. oxicode-catalog의 4계층 모델(SNAP/LIVE/Layer 2/LOCAL)이 시스템 카탈로그 관리의 코드 equivalent — provider×model×protocol의 3차원 매트릭스. oxibrain의 projection tables (beliefs, statements, entities, entity_keys, episodes)이 ERD의 코드 equivalent — schema를 Rust 코드로 직접 정의해서 type-safe + migration 자동화.
- 10
코드 리뷰는 어떻게 하나요? 어떤 도구를 쓰나요?
예상 꼬리질문- 리뷰어와 의견이 갈리면 어떻게 하나요?
- 코드 리뷰를 실제로 받아본 경험이 있나요?
예시 답변Pull Request 기반 코드 리뷰 — GitHub PR + GitHub Actions CI + code owner review. 정적 분석 — ESLint/Prettier(JS), cargo fmt + clippy(Rust), SonarQube. 자동화된 코드 리뷰 — ast_edit, ast_grep, lsp, debug, review tools. 시선아이티는 oxicode와 같은 Rust 풀스택은 아닐 수 있지만 (Python/JS 가능성 ↑), 동일한 CI 패턴 적용. SP 품질관리의 코드 equivalent: cargo fmt --all -- --check + cargo clippy --all-targets --all-features -- -D warnings + cargo test + cargo bench.
- 11
통합 테스트 시 회귀를 어떻게 잡나요?
예상 꼬리질문- 테스트 커버리지는 몇 %면 충분하다고 보나요?
- 가끔씩만 실패하는(flaky) 테스트는 어떻게 다루나요?
예시 답변(1) test pyramid — unit > integration > e2e 비율, (2) regression test suite — 매 PR마다 full suite 실행, (3) CI gate — 실패 시 머지 차단, (4) property-based testing — oxibrain은 random generation으로 invariant 검증, (5) crash recovery test — oxibrain §17.4 'kill mid-ingest at each stage boundary, assert resumption with no duplicate'. 시선아이티는 마르미-III 검증 단계에서 통합 테스트 시나리오 + 결함 관리표로 추적합니다.
- 12관련 페이지 →
Rust를 왜 쓰나요? Python 대신?
예상 꼬리질문- 시선아이티가 Java/Python 스택이면 어떻게 적응하실 건가요?
- Rust 컴파일 시간이 느린 건 단점 아닌가요?
예시 답변type safety + zero-cost abstraction + async + Send/Sync 경계가 명시적입니다. oxi의 boa_engine 0.20 (!Send Context → std::thread 고정) + oxibrain single-writer actor + oxios Kernel/Supervisor/Surface 모두 Send/Sync 경계가 명시적입니다. LangChain은 Python 표준이지만 asyncio 동시성 한계 + API 변경 빈번 + observability 유료라는 단점이 있어, production 환경에 따라 Rust가 더 안정적입니다. 단 Python 생태계/자료/예제/LangSmith 같은 cloud observability는 부족합니다.
- 13관련 페이지 →
oxi 생태계를 만들면서 가장 어려웠던 점은?
예상 꼬리질문- 그 문제를 처음엔 어떻게 잘못 풀었나요?
- 혼자 만들면서 리뷰 없이 진행한 게 아쉽지 않았나요?
예시 답변(1) boa_engine 0.20의 !Send Context 처리 — std::thread에 고정하고 mpsc channel로 통신하는 패턴 설계. (2) oxibrain의 ledger/projection 분리 — P1 invariant 'reprojection must rebuild everything'. (3) oxios-gateway의 Surface 트레이트 추상화 — Vec
>로 web/remote를 통합. (4) oxicode-sdk의 16 port trait + cross-cutting 6 trait — SDK = behavior, consumer = policy 분리 원칙. (5) ouroboros 자기-개선 loop의 안정성 — directive 파싱 + resilience + fallback. 면접에서는 이런 구체적 설계 도전 + 해결 과정을 답할 수 있습니다. - 14관련 페이지 →
왜 oxicode-sdk 0.73을 단일 wire 의존으로 쓰나요?
예상 꼬리질문- SDK 버전이 올라가서 호환성이 깨지면 어떻게 하나요?
- path dependency 대신 crates.io만 쓰는 이유를 한 문장으로 말한다면?
예시 답변SDK = behavior (인터페이스 + 참조구현), consumer = policy (도메인 결정) 분리 원칙입니다. oxicode-sdk은 16 port trait (StateStore, EventBus, MemoryStore, HookRunner, ModelCatalog, InternalUrlRouter, EmbeddingProvider 등) + cross-cutting 6 (AuditPersistence, AgentDecorator, Middleware, SnapshotStore, AuditSink, KernelToolProvider)를 정의합니다. oxios는 oxicode-sdk을 crates.io에서만 받고 path dep으로 끌어오지 않으며, 어떤 타입도 SDK로부터 pub use 재노출하지 않습니다. 면접에서는 'SDK는 행동, oxios는 정책'으로 명확히 답할 수 있습니다.
- 15관련 페이지 →
oxibrain을 standalone product로 분리한 이유는?
예상 꼬리질문- 분리하면 네트워크 hop이 늘어서 성능은 손해 아닌가요?
- 분리 전/후로 API 계약(스키마)은 어떻게 관리하나요?
예시 답변(1) 지식/메모리는 선택적 standalone product — oxios가 망가져도 oxibrain이 살아야 함, (2) AGENTS.md가 'It is a standalone product, not an oxios component' 명시, (3) cargo tree guard로 oxios/oxicode 의존이 빌드에 들어오는 것 자체를 차단, (4) scope 기반 multi-tenant token + in-house JSON-RPC MCP로 enterprise-grade 보안, (5) apps/brain-ui가 1st-class web client. 면접에서는 'second brain은 optional dependency, agent OS는 그것을 glue하는 orchestration layer'로 답할 수 있습니다.
- 16관련 페이지 →
oxibrowser의 wreq + reqwest 공존 의도는?
예상 꼬리질문- Chrome이 버전업되면 핑거프린트 유지보수는 어떻게 하나요?
- 봇 탐지 우회가 윤리적으로 문제되지 않나요?
예시 답변두 HTTP 클라이언트는 역할이 다릅니다. wreq = Chrome 149 TLS/HTTP2 핑거프린트 에뮬레이션으로 봇 탐지 우회 (브라우저 트래픽). reqwest = rustls-tls 표준 HTTPS (검색 모듈). 둘을 분리해 (a) 검색 다운스트림이 wreq의 RC 버전을 끌어들이지 않게 하고, (b) oxibrowser = { default-features = false } 경량 사용 시 search만 reqwest로 컴파일되게 합니다. 면접에서는 'bot 우회는 핑거프린트 합성이 핵심, 검색은 빠른 표준 HTTPS가 핵심 — trade-off 충돌로 분리'로 답할 수 있습니다.
- 17관련 페이지 →
oxios의 ouroboros 자기-개신 loop는 어떻게 작동하나요?
예상 꼬리질문- 자기-개선이 잘못된 방향으로 가면 어떻게 막나요?
- 사람이 개입하지 않고 얼마나 자율적으로 도나요?
예시 답변oxios-ouroboros crate의 7개 파일: directive (지시 파싱), engine (실행), model_resolver (모델 결정), prompts (프롬프트), resilience (회복), fallback (대안), types (타입 정의). 자기-개선 loop는 directive → engine → 결과 평가 → 다음 directive 생성으로, 시스템이 자신의 성능을 측정하고 개선 방향을 결정합니다. 면접 답변 포인트: 'ouroboros는 단순 자동화가 아니라 시스템이 자신의 메트릭을 보고 다음 행동을 결정하는 메타-루프'입니다.
- 18관련 페이지 →
시선아이티의 자체 GIS 엔진 ForGIS에 대해 어떻게 이해하나요?
예상 꼬리질문- 오픈소스 GeoServer로 바꾸면 뭐가 달라지나요?
- OGC 표준을 안 지키면 어떤 문제가 생기나요?
예시 답변ForGIS는 시선아이티의 자체 공간정보 서버 솔루션으로 Server/Desktop/Mobile/Datacenter 변형이 있습니다. 벡터·래스터 데이터를 다루고 OGC(Open GeoSpatial Consortium) 국제 표준 — WMS(맵 이미지 GetMap), WFS(피처 트랜잭션), WCS(커버리지), WMTS(타일 캐시) — 를 준수합니다. 즉 오픈소스 GeoServer에 대응되는 자체 엔진이라 보면 되고, 웹 기반 이미지 가속화 기술을 더해 렌더링 속도를 끌어올렸다고 봅니다. 면접 포인트: '왜 자체 엔진을 만들었나?' — 한국 공공 SI 시장의 표준 준수 + 클라이언트 종속성 제거 + RFP 가산점 — '오픈소스 대비 트레이드오프' — 비용·기술 종속 vs 맞춤 최적화·국내 표준 적합성. 표준 클라이언트(QGIS/OpenLayers/Leaflet)와의 호환성·TMS 타일 캐시·좌표계 정확도가 핵심 평가 항목입니다.
- 19관련 페이지 →
Java/JSP 백엔드와 전자정부 표준프레임워크(eGovFrame)에 대해 어떻게 이해하나요?
예상 꼬리질문- Java를 실제로 써본 경험이 있나요?
- eGovFrame 없이 Spring Boot로만 하면 안 되나요?
예시 답변국내 공공 SI의 사실상 표준 백엔드 스택이 Java/JSP + 관계형 DBMS(Oracle/Tibero/Altibase 등) 위에 전자정부 표준프레임워크(eGovFrame)입니다. eGovFrame은 한국정보화진흥원이 배포하는 표준 개발 프레임워크로, Spring 기반 경량 패턴 + 공통 컴포넌트(게시판·로그인·결재·통합검색 등)를 제공합니다. 표준 준수 여부가 감리·수주에서 가점이 됩니다. 시선아이티 채용공고의 '개발 PL: JAVA, JSP, DBMS 고급'도 그 맥락입니다. 면접 포인트: 'eGovFrame 공통 컴포넌트 사용 vs 직접 구현' (표준 적합성 vs 맞춤형 복잡도), 'WAS 선택(Tomcat/JBoss/WebLogic/JEUS)', '전자정부 표준 컴포넌트의 한계', 'DB 기술' (MyBatis vs JPA·iBatis vs Spring Data).
maven/gradle빌드와 WAS 배포, JSP/Servlet 컨테이너의 동작 모델이 기본 지식입니다. - 20관련 페이지 →
sLLM(경량 언어모델)은 왜 공공 SI에서 중요한가요?
예상 꼬리질문- 양자화하면 정확도가 떨어지는 건 어떻게 보완하나요?
- sLLM으로 부족하면 언제 외부 대형 LLM을 쓰나요?
예시 답변sLLM(small Large Language Model)은 (1) 양자화(INT8/INT4) + 증류(Distillation)로 모델 파라미터 수를 줄여 일반 LLM 대비 GPU 자원이 훨씬 적어도 운영 가능, (2) 폐쇄망/공공망 운영이 가능 — 한국 공공 SI는 데이터 외부 반출 제한·개인정보보호법·클라우드컴퓨팅법 등 규제로 외부 API 사용이 막히는 경우가 많습니다. 시선아이티의 자체 SLM 플랫폼/AI Chatbot 사업이 이 영역입니다. 면접 포인트: '왜 sLLM인가?' — 데이터 외부 반출 제약 + 비용↓ + 지연↓ + 폐쇄망 운영 가능, '한국어 특화' — NIPA의 HyperClova·구름·KoGPT 등 한국어 sLLM, 'RAG/도구 호출과 결합' — 모델 자체 능력은 한정이라 RAG/도구 호출로 보완하는 것이 표준. Python·LangChain·HuggingFace·ONNX Runtime·vLLM 스택이 이쪽 백엔드 추측.
- 21
실습이 끝나고 정규직 전환 제안이 오면 어떻게 하시겠어요?
예상 꼬리질문- 다른 회사에서 더 좋은 조건을 제안하면 어떻게 하실 건가요?
- 전환이 안 될 수도 있는데, 그래도 실습에 최선을 다할 건가요?
예시 답변전환 제안이 온다면 감사한 마음으로 받아들이고 싶습니다. 애초에 여기 지원한 이유가 '챗봇 + 공공데이터'라는 흔치 않은 조합이었고 — 그 판단이 실습 기간 동안 실제로 확인된다면 계속 다니지 않을 이유가 없습니다. 오히려 실습 3개월은 서로를 확인하는 시간이라고 생각합니다. 저는 이 기간 동안 커리큘럼에 있는 AI Chatbot·SI 두 트랙을 최대한 흡수해서, 전환 시점에는 '가르쳐야 하는 신입'이 아니라 '바로 투입 가능한 신입'이 되는 걸 목표로 하겠습니다.
- 22
마지막으로 질문 있으세요?
예시 답변(1) 'Seesun LLM 플랫폼의 기술 스택은 어떤가요? 자체 fine-tuning vs RAG 우선 전략인가요?' (2) '신입이 첫 3개월 동안 어떤 직무부터 시작하나요? AI Chatbot vs SI 중 어느 쪽이 주력인가요?' (3) '현재 팀은 몇 명이고 어떤 기술 스택을 쓰나요? (Java/JSP+eGovFrame 인지 Python인지)' (4) '다음 분기 주요 프로젝트가 있나요?' (5) 'GIS 도메인에서 LLM 활용 사례가 있나요? (ForGIS + sLLM 결합)' (6) '자체 솔루션 ForGIS 외에 어떤 GIS 도구 셋을 쓰나요? QGIS·GeoServer·GDAL 등' — 진지한 관심 + 도메인 이해도를 동시에 보여주는 질문들입니다.
면접 준비 체크리스트
- 자기소개 1분 + 왜 시선아이티 1분 (총 2분)
- LangChain vs LlamaIndex vs Haystack 비교 답변 가능
- RAG 3단계 (ingestion + retrieval + generation) 명확히 설명 가능
- 마르미-III 5단계 + 표준 산출물 130+ 설명 가능
- GIS 개념(벡터/래스터·지오코딩·R-Tree·PostGIS) + 공간정보×AI 융합 답변 가능
- '내부 시스템 연동 챗봇' = LLM tool-calling으로 설명 가능
- oxi 생태계 4개 프로젝트 + 그 관계를 한 그림으로 그릴 수 있음
- oxicode-sdk 16 port + cross-cutting 6 trait 정확히 알고 있음
- oxibrain을 standalone으로 분리한 이유 5가지 설명 가능
- oxibrowser의 wreq + reqwest 두 클라이언트 공존 의도 설명 가능
- oxios의 Kernel/Supervisor/Surface 3계층 + 6 crates 설명 가능
- 정규직 전환 의향 질문에 흔들리지 않고 답할 수 있음
- 질문 5개 (Seesun LLM 스택, 첫 3개월 직무, 팀 기술 스택, 다음 분기, GIS+LLM)