fullstack & ai developer
만드는 것보다
이해하는 것을 먼저.
안녕하세요. 국내 100개 이상의 대학에 LMS를 제공하는 에듀테크 기업에서 AI 서비스를 설계하고 구축하고 있습니다.
about
AI 강의 콘텐츠 생성 플랫폼의 메인 개발자로, 기획부터 개발, 테스트, 배포, 운영까지 제품의 전 주기를 담당하고 있습니다. 슬라이드, 영상, 음성을 AI로 자동 생성하는 서비스를 설계했고, 그 과정에서 분산 환경에서의 동시성 제어, 외부 API Rate Limiting, 비동기 작업 파이프라인 같은 문제들을 직접 정의하고 해결해왔습니다.
코드를 잘 짜는 것도 중요하지만, 왜 이렇게 짜야 하는지를 이해하는 것이 더 중요하다고 생각합니다. 기존에 당연하다고 여겨지는 패턴도 근본부터 의심해보고, 문제의 본질을 파악한 뒤에 가장 단순한 해결책을 찾으려고 합니다. "이건 원래 이렇게 하는 거야"라는 말에 쉽게 납득하지 못하는 편입니다.
how i think
문제를 정의하는 것부터 시작한다
AI Commons에서 Gemini API 429 에러를 만났을 때, 처음에는 단순히 sleep을 넣어봤습니다. 하지만 서버가 여러 대 분산되어 있어서 그것만으로는 해결이 안 됐고, 결국 "분산 환경에서 전체 사용량을 어떻게 공유 상태로 관리할 것인가"라는 진짜 문제에 도달했습니다. TCP AIMD 알고리즘을 차용한 분산 Rate Limiter를 Redis Lua로 구현하면서, 문제를 올바르게 정의하는 것이 해결의 절반이라는 걸 배웠습니다.
당연한 것을 의심한다
"문서를 LLM 컨텍스트에 넣어서 강의를 설계한다" — 이게 정말 맞는 접근일까요? 인간 교수는 50권의 교재를 동시에 펼쳐놓고 강의를 설계하지 않습니다. 이미 읽고 이해한 상태에서 설계합니다. 이 관찰에서 출발해, RAG의 "검색 후 생성" 패턴 대신 "지식 구조를 먼저 추출하고, 구조만으로 설계한다"는 접근법을 팀에 제안했습니다.
AI와 함께 일하는 방법을 고민한다
AI 에이전트와 함께 코딩하다 보면, 어느 순간 "내가 뭘 만들고 있는지 모르는" 상태가 됩니다. 그래서 테스트와 옵저버빌리티를 더 중요하게 생각하게 되었습니다. 단순히 테스트를 통과하는 코드가 아니라, 시스템이 동작하는 순간들을 기록하고 관찰하는 것. 프롬프트에 How(어떻게)보다 Why(왜)를 적는 것이 더 좋은 코드를 만든다는 것도 직접 경험으로 알게 되었습니다.
projects
아직 배울 것이 훨씬 많은 주니어입니다. 하지만 문제를 만나면 피하기보다 파고드는 편이고, 내가 만든 것이 어떻게 동작하는지 끝까지 이해하고 싶어하는 사람입니다. 더 자세한 이야기는 여기서 읽어주세요.