살핌(Salpeem)

What

살핌(Salpeem)은 교사 중심의 학생 관찰·성장 기록 플랫폼이다. Next.js와 Supabase를 기반으로, 교사가 학생의 일상적 성장을 빠르게 관찰 입력하고, 축적된 기록을 Gemini AI로 자동으로 생기부 문장으로 변환한다.

Why

한국의 교사들은 매 학기 수십 명의 학생에 대해 생활기록부를 작성해야 한다. 이건 가장 큰 행정 부담이면서, 동시에 학생을 제대로 관찰하고 기록하는 것은 교육의 본질이다. 살핌은 이 둘이 모순이 아니라는 데서 출발했다. "학생을 제대로 살피는 것이 곧 업무를 줄이는 길"이라는 철학 위에 만들었다.

How

핵심 파이프라인은 수집 → 연결 → 통합이다.

교사가 수업 중 관찰한 내용을 자연어나 음성으로 입력하면, NLP 파싱이 학생명·날짜·과목을 자동 추출한다. 이 기록은 Supabase에 누가기록으로 축적되고, RLS로 학교별/개인별 데이터가 격리된다. 학기말에는 축적된 관찰 기록을 Gemini AI가 생기부 지침에 맞는 문장으로 변환한다. 이때 PII Masking으로 학생 실명을 토큰으로 치환하여 개인정보를 보호한다.

단순히 문장을 생성하는 것에서 끝나지 않는다. 역량 분석으로 학생의 인지/정의적 성장을 시각화하고, 클래스룸 과제 시스템과 연동하여 산출물까지 통합 관리한다. 모든 교과/생활 교사가 관찰 기록을 입력하는 협력 플랫폼으로 설계했다.

Impact

교육 현장의 실제 문제를 AI로 해결한 사례다. 교사의 행정 부담을 줄이면서도 학생 관찰의 교육적 가치를 높인다. 학교용과 개인용(개인용 살핌)을 모두 지원하여, 학교 단위 협업이 필요한 교사도, 혼자 가볍게 쓰고 싶은 교사도 사용할 수 있다.

Tech Stack

• Frontend: Next.js 16, React 19, TypeScript
• Styling: Tailwind CSS v4, Radix UI
• Backend: Supabase (PostgreSQL + Auth + RLS)
• AI: Gemini AI (생기부 생성, 역량 분석), Azure Speech SDK (음성 인식)
• Desktop: Electron (웹+데스크톱 하이브리드)
• Testing: Playwright (E2E), Vitest (단위)

Architecture

데이터 흐름은 세 단계로 나뉜다.

입력 단계에서 교사는 자연어 메모, 음성, 클래스룸 과제 제출 등 여러 경로로 관찰을 기록한다. 축적 단계에서 이 기록들은 학생별·영역별로 분류되어 누가기록(observations)과 포트폴리오(student_portfolios)로 저장된다. 산출 단계에서 AI가 축적된 기록을 분석하여 생기부 초안을 생성하고, 교사가 최종 검토한다.

27개 DB 마이그레이션으로 tenants → profiles → students → observations → records 체인이 구성되어 있다. RLS 정책이 모든 핵심 테이블에 적용되어, 같은 학교 교사끼리만 데이터를 공유하고, 개인용 계정은 완전히 격리된다.

Decision 1: RLS 기반 멀티테넌시로 학교/개인 계정 분리

Context: 학교용(여러 교사 공유)과 개인용(1명 교사) 데이터가 같은 DB에 공존해야 했다. 섞이면 보안 사고다. Decision: RLS 정책으로 테넌트 기반 격리. 학교 계정은 조직 단위로, 개인 계정은 사용자 단위로 접근을 제한했다. Consequence: 한 교사가 여러 학교 계정을 동시에 관리할 수 있게 됐고, 개인용 살핌 v0.5.0 출시가 가능해졌다. 다만 RLS 정책이 복잡해져서 E2E 테스트로 반드시 검증해야 했다.

Decision 2: school_events를 SSoT(Single Source of Truth)로 설정

Context: 활동(activity)과 클래스룸(classroom)을 별도로 관리하면 "활동 제목을 바꿨는데 클래스룸에는 안 반영" 같은 불일치가 생겼다. 교사가 혼란스러워하는 지점이었다. Decision: school_events를 마스터로, classrooms는 "활동의 실행 환경"으로 정위치. 활동을 만들면 클래스룸이 자동 생성되고, 활동 수정이 클래스룸에 자동 동기화된다. Consequence: UI 단계에서 데이터 불일치가 원천 차단됐다. 교사는 활동만 관리하면 된다.

Decision 3: PII Masking + 복원 파이프라인

Context: AI에 학생 실명을 보내면 개인정보 유출 위험이 있다. 그렇다고 이름 없이 보내면 "다율이는 수업 시간에..."같은 자연스러운 관찰 메모를 AI가 이해할 수 없다. Decision: 학생명을 [S000] 토큰으로 마스킹해서 AI에 전송하고, 응답 후 원명을 복원한다. 한국어 조사 변형("다율이", "[S000]이")도 자동 처리한다. Consequence: 개인정보 유출을 차단하면서도 AI 파싱 정확도를 유지했다. 교육 현장에서 실제로 요구하는 프라이버시 수준을 충족한다.

배운 점

AI 프롬프트 엔지니어링은 기술 문제가 아니라 도메인 이해 문제였다. 바이트 제한을 지키면서 맥락을 보존하고, 생기부 지침에 맞는 톤을 유지하려면 교육과정과 생기부 작성 규정을 깊이 이해해야 했다. 프롬프트를 아무리 정교하게 짜도, 교사가 실제로 어떻게 기록하는지 모르면 쓸모없는 문장이 나온다.

RLS는 강력하지만 한번 잘못 설계하면 전체 데이터 접근 구조가 흔들린다. 멀티테넌시 정책은 머릿속으로는 단순해 보여도, 실제로는 "담임이 다른 반 학생 기록을 볼 수 있어야 하나?"같은 교육 현장의 미묘한 권한 문제에 부딪힌다.

실패한 시도

DB 스키마를 여러 차례 대폭 수정했다. 특히 관찰 기록과 활동, 클래스룸 간의 관계를 정리하는 데 많은 시행착오가 있었다. 처음부터 SSoT 원칙을 적용했으면 시간을 아꼈을 것이다.

UI 디자인을 세 번 전환했다 — Cozy Garden에서 Simple로, 다시 Organic Brutalism으로. 교사 사용자에게 맞는 톤을 찾는 데 시간이 걸렸다. 이 경험이 개인용 살핌의 디자인 방향을 잡는 데 도움이 됐다.

2025년 중반 — 프로젝트 시작

교사 관찰 기록 플랫폼의 기초를 설계했다. Supabase와 Next.js 기반 아키텍처를 확립하고, 사용자 역할과 데이터 모델을 정의했다.

2026-01 — 클래스룸-포트폴리오 통합

교과 과제 시스템을 구현하고 포트폴리오와 자동 연동했다. school_events를 SSoT로 확정하여 활동-클래스룸 동기화 구조를 완성했다.

2026-02 — 개인용 살핌 v0.5.0 출시

학교 가입 없이 개인 교사가 독립적으로 사용할 수 있는 경로를 추가했다. RLS 기반 데이터 격리와 다중 프로필 지원을 구현했다. 이후 개인용은 별도 데스크톱 앱으로 분리 발전 중이다.

2026-03 — Organic Brutalism 리디자인

웹 퍼스트 레이아웃으로 전면 개편했다. 타이포그래피 중심의 절제된 디자인으로 교사 사용자에게 맞는 톤을 찾았다.

현재

활동-클래스룸-생기부 완전 동기화 아키텍처가 확립된 상태. AI 생기부 파이프라인을 고도화하고 있다.