올해 내가 회사 안,밖에서 심은 잔디
1️⃣ What Changed
AI Engineer
내가 속한 사업부 내 AI Agent 그룹이 만들어지며 갑자기 조직을 이동하게 되었다. 입사 후 2년동안 Test Engineering 그룹에서 Unit Test 적용, Unit Test Gating 시스템에 대한 업무를 주로 했다. 그래서 내가 AI에 대해 다루어보았던 건, 혼자 local에서 Ollama로 모델을 띄우고, LangChain을 이용해서 RAG 적용해보고 Code Review Bot을 만든 경험밖에 없었다. 이동 후 주변에는 이미 AI를 오랫동안 공부한 사람들이 많았고, 관련 석박까지 나온 분들도 많아서 기가 좀 죽었다. 근데 또 ‘AI를 오래 해봤자 얼마나 했겠어’ 하는 마음으로 공부하고 또 공부하고 또 공부했다.
커리어에 변화가 생기면서 블로그도 이주했다. 이전에 사용하던 Velog에서 조금 더 자유도가 높은 Github Pages로!
2️⃣ Learnings
what I’ve learned
MCP
처음 오자마자 공부했던 게 MCP이다. 이미 사내에 개발되어 배포중인 MCP 서버들이 있었고, 그걸 vs code extension인 Roocode에 연결해서 사용을 시작했다.
그 후에 SDK 방식, FastMCP 방식으로 MCP서버를 개발해보고, 또 사내에 CodeLab, 기술 블로그 형식으로 교육 자료를 배포함으로써 개념을 익혔다.
Agent
그룹 이름이 AI Agent 그룹인만큼 Agent에 대한 요구가 상당히 많았다. 개념을 익히는 데 그리 오랜 시간은 걸리지 않았지만, ADK로 Agent를 만들고, Multi Agent로 확장해 나가는 과정에서 어떤 개발 패턴을 사용해야 하는지, 어떤 모델을 사용해야 하는지, Multi Tool과 Multi Agent중 어떤 걸 택해야 하는지에 대한 Know-how는 아직 많이 부족한 상태다.
Vibe Coding
Roocode, Cursor, Claude를 사용하게 되면서, Vibe Coding을 신나게 했다. 파트 내에서도 쏟아지는 코드 양이 너무 많아 리뷰가 불가능할 정도였다.
Vibe Coding을 하면서 배운 점이 참 많은데, 간단한 코드는 몰라도 production level로 올라가야 하는 코드는 Vibe Coding을 시작하기 전에 설계를 견고하게 해야한다.
이제는 TDD(Test-Driven-Development)가 아니라 SDD(Spec-Driven-Development)시대라고 하는데, 사실 따지고 보면 둘 다 똑같은 개념이라 생각한다. 코드를 짜기 전에, 명세를 촘촘하게 작성하는 것이다. 근데 또 이렇게 촘촘하게 짜서 Claude로 개발하다 보니, LLM에게 너무 많은 context를 주게 되고, 결국 Hallucination으로 이어졌다.
그래서 요즘엔 GPT나 gemini와 함께 전체 설계를 하고, 각 모듈로 나누어 Claude에게 지시하는 bottom-up 방식을 사용하고 있다.
LiteLLM
우리 그룹에서 GPU에 직접 모델을 올리고, 내리고 하는 과정을 하면서 LiteLLM에 대한 공부도 했다. 사실 아직도 LiteLLM을 다루는 건 괜시리 무섭긴 하다. 파트 내에서 파트장님, 멘토님, 파트원분들이 만드는 Token 관련 시스템 (인증, 권한, 사용량 추적하기 위한 시스템)들을 옆에서 보면서 정말 많이 배웠다.
3️⃣ Achievements
What I’ve achieved
AI Fest Langding Web Page
갑자기 AI Agent 행사 진행을 하게 되었다. 그런데 AI Agent 대회 신청서를 받아야 하는데 Confluence로 받는다는 것이다. 시간도 없었고, 할 일도 많았지만 도저히 대회 신청서를 Confluence로 받는 걸 용납할 수 없었다. 그래서 내가 경진대회 Web Page를 빨리 만들어보겠다고 했다. 이때 당장 남은 시간 일주일.
If KaKao 컨퍼런스 페이지를 모티브로 해서 Frontend는 React, Backend는 FastAPI, DB는 SQLite로 개발했다. 입사 전에 SrpingBoot, Java, Vue.js등을 이용해서 Web 개발한 경험이 도움이 많이 됐다. 처음엔 혼자 개발하다가 점점 규모가 커지면서 다른 분들도 도와주셨다. 입사 전에 Web 개발을 할 때는 Frontend, Backend를 명확하게 나누어서 협업하는 게 힘들어서 개발하면서 conflict도 많이 났는데, RnR을 확실하게 나누고 개발하니 수월했다. 내년에 더 잘할 수 있을 것 같다.
MCP Registry
그룹 내에서 개발하는 MCP 종류가 많아지면서 Smithery 와 같이 MCP를 관리하는 Registry가 필요했다. 내가 하고 싶다고 했고, 파트장님이 같이 할 사람이 필요하냐고 물어 보시길래 혼자 하겠다고 했다. (우리 파트에서는 각자 하나씩 프로젝트를 맡아서 하고, Issue가 있을 땐 서로 돕는다)
Stack은 Backend: FastAPI, Frontend: React와 Next.js, DB: Postgres를 사용했다. Smithery, MCP Inspector 등에 구현되어 있는 기능들을 다 구현하려고 했다. MCP 서버 등록, Health Check, Tool 자동으로 불러오기, Tool 기능을 바로 사용해볼 수 있게 LLM에 해당 MCP 바로 붙여서 쓸 수 있게 하기 등 많은 기능을 넣었다. 앞으로 더 구현하고 싶은 기능이 많다. 내년에도 이 개발은 쭉 이어질 예정이다.
개발이 어느 정도 되었을 때 사장님이랑 임원들 앞에서 발표도 했다. 예전에는 발표하는 게 정말 스트레스이고 싫었는데, 이번엔 나 혼자 만든 프로젝트를 사장단 앞에서 발표할 수 있는 기회가 주어진다는 게 큰 영광이고 내가 자랑스러웠다.
4️⃣ Misses & Regrets
What Didn’t go well
코드 리뷰의 부재
Vibe Coding으로 많은 코드를 만들어 내면서, 코드 리뷰를 소홀하게 했다. 결국 프로젝트가 커지면서 문제가 발생했다. Frontend 코드를 짜는게 익숙하지 않다 보니 Claude가 짜준 코드가 표준이라고 생각했다. Next.js 서버를 두면서 유지보수가 힘들어졌는데, 나중에 Nginx 만으로 Backend와 Frontend 서버를 다 묶으려고 했으나, SSR 코드를 제거하지 못해 여전히 Frontend 서버를 production에서 권장되지 않는 방법으로 띄우고 있다.
많은 개념을 LLM을 통해 배우려 한 것
처음에 MCP 만드는 방법, LangGraph 를 사용하는 방법 등을 LLM에게 많이 의존했다. 그런데 현재 내가 다루는 기술들은 LLM에 잘 학습되지 않은 게 많아서 권장하지 않는 방법으로 코드를 짠다거나 하는 일들이 누적되었다. 그래서 그 이후로는 Google ADK docs, FastMCP docs 등 공식 docs를 보면서 공부하는 방향으로 변경했다.
내가 만든 게 정말 실무 개발자들에게 도움이 되었는가
실무에 도움이 되는 MCP를 만들고, Agent를 만들고 싶은데 제품 개발과 가까이 있는 개발자들에게 도움이 되는 걸 만드는 건 쉽지 않다. 근본적인 원인은 내가 입사하자마자 상용 제품 개발이 아니라 바로 SE팀에 들어가게 되면서 상용 제품 개발 workflow를 잘 이해하지 못하고 있다는 점이다.
그래서 결국 내가 필요한 MCP, Agent만 만들게 되고, 나한테만 도움이 되는 개발 환경을 꾸리고 있다. 내년엔 내가 필요한 Agent가 아닌, 상용 제품을 개발하는 개발자들에게 정말 도움이 되고 그것이 곧 제품의 품질 향상으로 이어지고, 성과금도 많이 받는(ㅋㅋ) 꿈을 꿔야지.