시선아이티 면접 준비 · 커리큘럼 4단계

커리큘럼 4단계 심층 — 모르는 용어/설계 방식 정리

시선아이티 채용공고·현장실습 계획서의 4단계 실무 커리큘럼(AI Chatbot 4단계 + SI 4단계 = 총 8단계)에서 모를 수 있는 핵심 용어 + 설계 방식을 정의 + 왜 필요한가 + 어떻게 구현하는가로 정리한다. 면접에서 "잘 모르는 용어를 물어봤을 때" 답변할 수 있는 기반.

1단계 AI Chatbot

AI 및 챗봇 기초 이론 교육

NLP (자연어 처리, Natural Language Processing)

정의

컴퓨터가 인간의 자연어를 이해·생성·분석하는 기술의 총칭.

왜 필요한가

시선아이티의 Seesun LLM 플랫폼은 NLP pipeline을 내부적으로 사용 — 토크나이징 → 임베딩 → LLM forward pass → 디코딩.

어떻게 구현하는가

시선아이티는 LangChain 표준을 따르고, oxicode-ai의 dialect 모듈(coercion/history/render/xml/mod)이 native tool 지원 없는 모델을 위한 텍스트 기반 tool-calling 형식을 제공.

LLM (거대 언어 모델, Large Language Model)

정의

수십억~수천억 파라미터 규모의 transformer 기반 언어 모델. GPT(OpenAI), Llama(Meta), Claude(Anthropic) 등.

왜 필요한가

시선아이티 AI Chatbot의 두뇌. RAG pipeline의 'generation' 단계 담당.

어떻게 구현하는가

oxicode-ai가 models.dev 기반 145 provider 카탈로그 + 특수 API용 전용 wire adapter ~14종(anthropic/bedrock/google/vertex/devin/gitlab_duo/gemini_cli/cursor 등) 통합. streaming-first + type-safe events + provider-agnostic.

LangChain (랭체인)

정의

Python 진영의 LLM orchestration 표준 프레임워크. LCEL(LangChain Expression Language)로 chain/compose/Runnable 표준화.

왜 필요한가

시선아이티 채용공고·현장실습 계획서에 명시. 'AI Chatbot 개발 프레임워크(LangChain) 및 API 환경 구축'.

어떻게 구현하는가

LangChain = Python 표준, oxicode-ai의 Provider trait = Rust equivalent. 둘 다 streaming-first + provider-agnostic + type-safe events.

페르소나 (Persona)

정의

챗봇의 정체성/캐릭터. system prompt fragment로 표현.

왜 필요한가

시선아이티는 '페르소나 및 기능 정의'를 1단계에서 다룸. 공공기관 실 업무에 적합한 응답 스타일/말투 결정.

어떻게 구현하는가

oxicode-sdk의 PersonaProvider port (`ports/mod.rs:582`) — system prompt fragment를 selectable name으로 주입. oxios의 `~/.oxios/personas/` 디렉토리에서 페르소나 로딩.

2단계 AI Chatbot

데이터 준비 및 RAG(검색 증강 생성) 구현

RAG (검색 증강 생성, Retrieval-Augmented Generation)

정의

LLM이 외부 지식 베이스에서 관련 문서를 검색한 뒤 그 내용을 참고해 답변을 생성하는 패턴.

왜 필요한가

시선아이티 2단계 핵심. LLM의 hallucination을 줄이고 도메인 지식을 주입하는 표준 패턴.

어떻게 구현하는가

oxibrain의 L0 retrieval stack이 정답: n-gram Jaccard lexical + dense vector + RRF fusion + MMR rerank. P11 invariant 'No language is privileged'로 다국어 동일 처리.

벡터 임베딩 (Vector Embedding)

정의

텍스트를 고정 차원의 dense vector로 변환한 표현. 의미가 비슷한 텍스트는 vector 공간에서 가까이 위치.

왜 필요한가

RAG의 retrieval 단계에서 의미적 유사도 검색에 사용. '왕'과 'monarch'는 다른 단어지만 비슷한 vector.

어떻게 구현하는가

oxibrain-embed-local: BGE-M3 GGUF 모델, llama-cpp-2 백엔드 (Metal on aarch64, CPU elsewhere). oxicode-mnemopi도 자체 vector_index 모듈.

Retriever (검색기)

정의

RAG pipeline에서 쿼리와 관련된 문서를 검색하는 컴포넌트. BM25, dense vector, hybrid 등 다양한 종류.

왜 필요한가

RAG의 핵심. 검색 품질이 답변 품질을 결정.

어떻게 구현하는가

LangChain: Retriever/VectorStore/MultiQueryRetriever/ContextualCompression. oxibrain: lexical (FTS5) + dense (sqlite-vec) + RRF fusion.

Vector DB (벡터 데이터베이스)

정의

벡터 임베딩을 색인화하고 KNN(근접 이웃) 검색을 제공하는 특수 DB.

왜 필요한가

RAG의 retrieval backend. Pinecone/Weaviate/Qdrant/Milvus/Chroma/pgvector 등.

어떻게 구현하는가

oxibrain은 sqlite-vec 확장으로 자체 vector 색인 — 별도 DB 운영 불필요, SQLite 한 파일 안에 통합.

청킹 (Chunking)

정의

긴 문서를 LLM이 처리할 수 있는 작은 단위로 분할. 보통 256~1024 토큰.

왜 필요한가

LLM context window 제한 + retrieval 정밀도. 너무 크면 노이즈, 너무 작으면 맥락 손실.

어떻게 구현하는가

LangChain: RecursiveCharacterTextSplitter/SemanticChunker. LlamaIndex: SentenceSplitter. oxibrain: byte-anchored span projection으로 정확히 청크 경계 추적.

3단계 AI Chatbot

대화 설계 및 프롬프트 최적화

프롬프트 엔지니어링 (Prompt Engineering)

정의

LLM의 출력을 의도대로 제어하기 위해 입력(prompt)을 설계하는 기법. few-shot, chain-of-thought, ReAct 등.

왜 필요한가

시선아이티 3단계 핵심. 같은 모델이라도 prompt 설계에 따라 답변 품질이 크게 달라짐.

어떻게 구현하는가

LangChain: ChatPromptTemplate/MessagesPlaceholder/few-shot selectors. oxicode-ai: PersonaProvider + dialect module + provider_options로 system prompt + few-shot 예시 + temperature + thinking budget 동시 제어.

대화 경험 (UX) 설계

정의

챗봇과 사용자 간의 대화 흐름 설계. 멀티 턴, 컨텍스트 유지, 오류 처리.

왜 필요한가

단순 Q&A가 아닌 실제 업무 절차 안내, 맞춤형 정보 제공을 위해 필수.

어떻게 구현하는가

oxios의 channels (Web UI / CLI / Telegram / Remote RPC) + skills marketplace (ClawHub)로 channel-specific UX 제공. oxios의 A2A (a2a_api.rs)가 inter-agent 메시지 흐름 관리.

few-shot (퓨샷)

정의

prompt에 예시 Q&A를 포함시켜 LLM이 패턴을 학습하도록 하는 기법.

왜 필요한가

정확도 향상 + 모델 fine-tuning 없이 도메인 적응.

어떻게 구현하는가

oxibrain M10: 'Few-shot selection from golden corpus (§9.6)' — 25 episodes + 25 questions 골든 코퍼스에서 few-shot 선택.

Chain-of-Thought (CoT)

정의

LLM에게 '단계별로 생각하라'고 지시해 추론 능력을 향상시키는 기법.

왜 필요한가

복잡한 추론/계획 task에서 답변 정확도 향상.

어떻게 구현하는가

oxicode-ai의 ContentBlock::Thinking variant가 streaming thinking tokens 캡처. oxios의 `compression.rs` / `knowledge_lens.rs`가 CoT-style streaming 사용.

4단계 AI Chatbot

시스템 통합, 품질 평가 및 최종 시연

통합 테스트 (Integration Test)

정의

개별 모듈이 아닌 전체 시스템이 의도대로 동작하는지 확인하는 테스트.

왜 필요한가

단위 테스트는 통과해도 통합 시 인터페이스 mismatch, race condition 등이 발생 가능.

어떻게 구현하는가

oxibrain §17.4: 'crash recovery test' — kill mid-ingest at each stage boundary, assert resumption with no duplicate. oxios-ouroboros: 자기-개신 loop 회귀 자동화.

LLM-as-judge

정의

LLM을 사용해 다른 LLM의 출력을 자동으로 평가하는 패턴. 평가의 확장성 문제 해결.

왜 필요한가

시선아이티는 '품질 평가'를 4단계에서 다룸. human eval은 비용 + 시간이 많이 �.

어떻게 구현하는가

oxibrain eval/crates/oxibrain-cli/src/cmd/gate.rs — 3-arm 비교 (full context vs lexical+dense+RRF vs oxibrain complete) under both extractors (local + frontier). LangSmith/Langfuse/Helicone 같은 외부 도구.

관측 가능성 (Observability)

정의

시스템 내부 상태를 외부에서 측정·추적할 수 있는 능력. logging + metrics + tracing.

왜 필요한가

LLM application 디버깅 + 비용 추적 + 성능 최적화에 필수.

어떻게 구현하는가

oxios: AuditTrail + Tracer + CostTracker (oxicode-sdk observability 모듈, agent_runtime.rs:31). LangChain: LangSmith (cloud). Open source: Langfuse, Helicone.

Merkle Audit Trail

정의

Merkle hash chain으로 변조 불가능한 audit log. 각 entry가 이전 entry의 hash를 포함.

왜 필요한가

보안 + compliance. SI 시스템에서 사용자 행위 추적/감사.

어떻게 구현하는가

oxios의 RBAC + path sandboxing + Merkle audit trail (AGENTS.md:99). RFC-014 OWASP RBAC.

1단계 SI

SI 산업 이해 + 개발/형상관리 환경 구축

SI (시스템 통합, System Integration)

정의

공공기관/기업의 정보시스템을 요구사항 분석부터 설계·구축·운영까지 통합 제공하는 사업.

왜 필요한가

시선아이티의 두 직무 중 하나. GIS·AI·공간정보 도메인 전문성 + SI 사업 수행 역량 동시 요구.

어떻게 구현하는가

공공기관 SI사업은 정보화 사업 감리법인 등록 기준에 따라 마르미-III 방법론 적용 의무. oxios의 channels/web/CLI/Telegram + skills + marketplace가 enterprise SI deployment 패턴과 동형.

마르미-III (Marmi-III)

정의

한국 정보화 사업 표준 방법론. 분석 → 설계 → 구현 → 시험 → 운영 5단계 + 130+ 산출물.

왜 필요한가

공공기관 SI사업의 표준. 시선아이티 채용공고에 '마르미-III 방법론 및 단계별 산출물 이해' 명시.

어떻게 구현하는가

마르미-III 표준 문서는 한국정보화진흥원에서 배포. SI 업체는 마르미-III 기반 산출물 템플릿 보유. oxi 생태계는 표준 method론을 직접 구현하지 않지만, oxicode-cli의 18개 subcommand가 SI 프로젝트 운영 패턴과 동형.

Git/SVN 형상관리

정의

소스코드 변경 이력을 추적·관리하는 도구. branch/merge/commit/tag/revert 지원.

왜 필요한가

SI 프로젝트 필수. 다수 개발자가 협업하며 코드 충돌 방지 + 변경 추적.

어떻게 구현하는가

oxicode는 Git 기반. oxicode-cli의 `commit` subcommand + oxicode-lsp의 multi-server lifecycle + oxicode-ouroboros의 resilience 패턴.

2단계 SI

요구사항 분석 + 시스템 설계 (기획)

요구사항 정의서 (Requirement Specification)

정의

고객의 요구사항을 체계적으로 정리한 문서. 기능/비기능 요구사항 + 우선순위 + acceptance criteria.

왜 필요한가

SI 2단계 산출물. 개발 범위 합의 + 변경 관리의 기준.

어떻게 구현하는가

마르미-III 산출물 템플릿 사용. oxicode는 직접 지원하지 않지만, oxios의 KnowledgeDream 모듈이 잠재적으로 마르미-III 산출물 메타데이터 색인화 가능.

WBS (작업 분할 구조도, Work Breakdown Structure)

정의

프로젝트를 계층적으로 분해한 구조. 최상위 프로젝트 → 단계 → 작업 → 하위 작업.

왜 필요한가

SI 2단계 산출물. 일정/비용/리소스 관리 + 진척도 측정의 기준.

어떻게 구현하는가

MS Project, JIRA, OpenProject. oxi 생태계는 WBS 도구는 없지만, oxicode-cli의 sessions/tree/fork subcommand가 작업 단위 관리 패턴 제공.

UI/UX 설계서

정의

화면 단위로 UI 요소 + 사용자 흐름 + 인터랙션을 정의한 문서. �이어프레임/프로토타입 포함.

왜 필요한가

SI 2단계 산출물. 개발자가 구현할 화면의 정확한 명세.

어떻게 구현하는가

Figma, Sketch, Adobe XD, Balsamiq. oxi는 디자인 토큰(project-oxi/.github/DESIGN.md OKLCH)을 통해 일관된 UI 시스템 제공.

테이블 명세서 (Table Specification)

정의

DB 테이블 단위로 컬럼, 타입, 제약조건, 인덱스를 정의한 문서.

왜 필요한가

SI 2단계 산출물. DB 설계의 기준 + DDL 생성의 소스.

어떻게 구현하는가

ERMaster, draw.io, MySQL Workbench. oxibrain의 store 모듈이 SQLite 스키마를 Rust 코드로 직접 정의 — type-safe + migration 자동화.

ERD (Entity-Relationship Diagram)

정의

엔티티(테이블) 간 관계를 시각화한 다이어그램. 1:1, 1:N, N:M 관계 표현.

왜 필요한가

SI 2단계 산출물. DB 설계의 시각적 표현 + 리뷰/합의의 도구.

어떻게 구현하는가

ERMaster, draw.io, MySQL Workbench, dbdiagram.io. oxibrain의 projection tables (beliefs, statements, entities, entity_keys, episodes)이 ERD의 코드 equivalent.

3단계 SI

프로젝트 구현 + 단위 테스트 (개발)

프론트엔드 (FE) / 백엔드 (BE)

정의

FE = 사용자 화면 단 (React/Vue/Angular/Svelte). BE = 서버 로직 (Node.js/Python/Java/Rust/Go).

왜 필요한가

SI 3단계 기본 분리. 시선아이티는 GIS 도메인 시각화 → FE가 중요.

어떻게 구현하는가

FE/BE 모두 oxios-gateway가 web Surface로 통합 가능. oxios의 web/ 디렉토리는 React 19 + Tailwind v4 기반.

API 연동 (API Integration)

정의

외부 시스템의 REST/GraphQL/gRPC API를 호출해 데이터를 교환하는 패턴.

왜 필요한가

SI 시스템은 다수 외부 시스템과 연동 (행정정보, GIS 데이터, 인증 등).

어떻게 구현하는가

oxicode-ai가 145 provider 카탈로그(models.dev) + 전용 adapter 14종 통합 + oxibrowser-core가 HTTP/WS 클라이언트. oxios의 `engine_api.rs:1460`이 SDK 격리 속성으로 외부 API 검증.

단위 테스트 (Unit Test)

정의

개별 함수/모듈 단위로 동작을 검증하는 테스트. 격리된 환경에서 input → expected output 확인.

왜 필요한가

SI 3단계 필수. 결함 조기 발견 + 리팩토링 안전성.

어떻게 구현하는가

oxicode의 14 feature에 `#[oxicode_unstable(feature = "...")]` 매크로로 unit test 게이트. oxibrain은 property-based testing + §13.2 budget 측정으로 회귀 방지.

코드 리뷰 (Code Review)

정의

다른 개발자가 작성한 코드를 검토해 결함/스타일/설계 개선을 제안하는 프로세스.

왜 필요한가

SI 3단계 필수. 지식 공유 + 결함 발견 + 일관성 유지.

어떻게 구현하는가

oxicode의 `ast_edit`/`ast_grep`/`lsp`/`debug`/`review` tools가 자동화된 코드 리뷰. CI에서 cargo fmt + clippy -D warnings + cargo test가 SP 품질관리의 코드 equivalent.

CI/CD (지속적 통합/배포)

정의

코드 변경 시 자동으로 테스트/빌드/배포하는 파이프라인.

왜 필요한가

SI 프로젝트의 안정적 배포 + 빠른 피드백.

어떻게 구현하는가

GitHub Actions, GitLab CI, Jenkins. oxicode의 pre-commit + post-commit hooks + GitHub Actions가 표준 패턴.

4단계 SI

통합 테스트 + 품질 관리 (검증 및 종료)

통합 테스트 (Integration Test)

정의

여러 모듈이 함께 동작할 때의 인터페이스/데이터 흐름을 검증하는 테스트.

왜 필요한가

SI 4단계 필수. 단위 테스트 통과 ≠ 통합 시 정상 동작.

어떻게 구현하는가

oxibrain §17.4: crash recovery test. oxios-ouroboros: 자기-개선 loop 회귀 자동화.

버그 트래킹 (Bug Tracking)

정의

결함의 발견 → 분류 → 수정 → 검증 → 종료의 lifecycle 관리.

왜 필요한가

SI 4단계 필수. 결함 누락 방지 + 우선순위 결정.

어떻게 구현하는가

JIRA, Bugzilla, GitHub Issues. oxicode-cli의 `oxicode issue` subcommand + issue:// URI scheme.

Gap 분석 (Gap Analysis)

정의

초기 요구사항 대비 구현 결과물의 차이를 분석하는 기법.

왜 필요한가

SI 4단계 필수. 누락 기능/추가 요구 발견 + 보완 결정.

어떻게 구현하는가

마르미-III 검증 단계에서 결함 관리표로 추적. oxibrain의 `evaluate_fabrication_rate` + `statement_precision/recall`이 자동 Gap 분석의 코드 equivalent.

SP (Software Process) 인증

정의

한국 SW 공학 프로세스 인증. SP 인증 기준에 부합하는 산출물 작성.

왜 필요한가

공공 SI 사업의 표준 품질 보증.

어떻게 구현하는가

한국 SW 공학 인증원에서 인증. oxi는 자체 SP equivalent인 DESIGN_IMPROVEMENTS_V2.md + cargo fmt/clippy/test gate.

최종 산출물 (Final Deliverables)

정의

프로젝트 종료 시 고객에게 인도하는 모든 문서 + 코드 + 운영 매뉴얼.

왜 필요한가

SI 4단계 필수. 'SP 인증 기준에 부합하는 최종 산출물(사용자 매뉴얼 등) 정리 및 최종 발표'.

어떻게 구현하는가

마르미-III 130+ 산출물 템플릿. oxibrain의 `export_jsonl` + `import_jsonl`이 brain 데이터 백업/복원의 코드 equivalent.

면접에서 자주 나올 수 있는 추가 질문

  1. "RAG vs Fine-tuning 어떤 차이가 있나요?" — RAG는 외부 지식 검색으로 LLM을 augment, fine-tuning은 모델 가중치 자체를 업데이트. RAG는 즉시 업데이트 가능 + hallucination 적지만 latency ↑. Fine-tuning은 빠른 inference이지만 업데이트 비용 ↑. 시선아이티처럼 도메인 정보가 자주 바뀌면 RAG가 표준.
  2. "LangChain LCEL이 뭔가요?" — LangChain Expression Language. chain/agent를 Runnable 프로토콜로 표준화. | 파이프라인으로 chainable, .invoke()/.stream()/.batch() 표준 메서드.
  3. "Vector DB 없이 RAG 구현 가능한가요?" — 가능. oxibrain은 sqlite-vec 확장으로 SQLite 안에 vector 색인 통합. 소규모는 BM25 + PostgreSQL로도 가능.
  4. "Public API vs Private API 차이는?" — Public은 외부 개발자/시스템에 노출 (인증/문서/버전 관리 필요). Private는 내부 시스템 간 통신. 시선아이티의 Seesun LLM 플랫폼은 private API일 가능성 ↑.
  5. "GraphQL vs REST 어떤 차이가 있나요?" — REST는 resource 단위, GraphQL은 query 단위. GraphQL은 over-fetching/under-fetching 해결하지만 caching 복잡. 시선아이티 GIS 도메인처럼 관계형 데이터가 많으면 GraphQL이 효율적.