developer
어떻게(How)보다
왜(Why)에 집착합니다.
AI 서비스를 설계하고 구축하는 개발자입니다. 단순한 소프트웨어 엔지니어가 아니라, 문제의 본질을 찾아내는 Problem Solver가 되고자 합니다. 디테일을 챙기고, 추상화로 감싸고, 계층으로 쌓는 일을 합니다. 문제를 만나면 표면의 증상보다 그 아래의 본질을 꿰뚫어 보려 하고, 낯선 것 앞에서 겁먹기보다 호기심을 먼저 느끼는 편입니다.
about
AI 강의 콘텐츠 생성 플랫폼의 메인 개발자로, 기획부터 개발, 테스트, 배포, 운영까지 제품의 전 주기를 담당하고 있습니다. 아직 경험이 많지 않지만, 매일 부딪히는 문제들을 직접 정의하고 풀어가는 과정에서 조금씩 성장하고 있습니다.
코드를 잘 짜는 것도 중요하지만, 왜 이렇게 짜야 하는지를 이해하는 것이 더 중요하다고 생각합니다. 시스템이 어떻게 동작하는지는 잘 짜여진 코드보다 실패한 빌드와 깨진 가정들에서 더 많이 배운다는 걸 느끼고 있고, 그래서 문제를 만나면 피하기보다 파고드는 편입니다.
요즘은 AI를 활용해 코드가 쏟아지는 시대인 만큼, 테스트와 옵저버빌리티의 중요성을 더욱 실감하고 있습니다. 코드가 빠르게 만들어질수록 그것이 의도대로 동작하는지 검증하고, 시스템이 어떤 상태에 있는지 관찰할 수 있는 구조가 뒷받침되어야 한다고 생각합니다. 어떻게 하면 테스트를 더 의미 있게 설계하고, 시스템의 동작을 더 잘 기록하고 관찰할 수 있을지 탐구하고 있습니다.
how i think
문제를 정의하는 것부터
여러 사용자가 동시에 AI 이미지를 생성할 때 429(Rate Limit) 에러가 빈번하게 발생했습니다. 단순히 "요청이 너무 많다"에서 멈추지 않고, 왜 제어가 안 되는지를 파고들었더니 워커가 여러 서버에 분산되어 있어서 개별 서버에서의 제어만으로는 전체 사용량을 관리할 수 없다는 구조적 문제가 보였습니다. 증상이 아니라 구조를 먼저 이해하는 것이 결국 더 빠른 해결로 이어진다는 걸 배웠습니다.
당연한 것을 의심해보기
"문서를 LLM 컨텍스트에 넣어서 강의를 설계한다" — 이게 정말 맞는 접근일까? 인간 교수는 50권의 교재를 동시에 펼쳐놓고 강의를 설계하지 않습니다. 이미 읽고 이해한 상태에서 설계합니다. 이런 관찰에서 출발해서 기존 RAG 패턴에 대한 의문을 팀에 제안한 적이 있습니다. 맞는 답이었는지는 아직 모르겠지만, "원래 이렇게 하는 거야"라는 말에 한 번쯤 물음표를 붙여보는 습관은 계속 가져가고 싶습니다.
도구가 바뀌어도 할 일은 남는다
AI 에이전트와 함께 코딩하다 보면, 코드가 순식간에 생성되지만 "내가 뭘 만들고 있는지 모르는" 순간이 옵니다. 코드는 즉시 도착하지만 이해는 그렇지 않다는 걸 체감하면서, 테스트와 옵저버빌리티가 왜 중요한지를 실감하고 있습니다. AI가 생성하는 코드에 대한 책임은 결국 사람에게 있고, 그 책임을 지려면 내가 만든 것이 어떻게 동작하는지 끝까지 이해해야 한다고 생각합니다.
호기심을 잃지 않는 것
어셈블리에서 C로, 객체지향에서 프레임워크로, 그리고 지금 AI 에이전트로 — 도구는 계속 바뀌어왔지만 개발자는 매번 새로운 도구와 함께 진화해왔다고 합니다. 저는 아직 그 역사의 아주 초입에 있는 사람이지만, 새로운 도구 앞에서 겁먹기보다 호기심을 먼저 느끼는 편이고, 실패하더라도 직접 부딪혀보면서 배우는 게 가장 빠르다고 믿습니다.
아직 배울 것이 훨씬 많은 주니어입니다. 하지만 만든 것을 끝까지 이해하고, 본질을 보려 하고, 계속 배우려는 사람입니다. 더 자세한 이야기는 여기서 읽어주세요.