안녕하세요. 이번에 DB, Security & IT, AI 부분 회고 글을 맡은 변해광(zephy)입니다!

최근 카카오 신입 공채를 통해 개발자로 합류한 총 40명의 신입 Krew들이 밀도 높은 기술 온보딩 교육을 무사히 마쳤습니다.

학생 시절에는 주어진 요구사항에 맞춰 ‘기능이 동작하게’ 만드는 데 집중했다면, 카카오에서의 온보딩은 완전히 다른 차원의 질문을 던지는 시간이었습니다. DB, 보안, 그리고 AI에 이르는 폭넓은 교육을 관통하는 하나의 주제가 있었다면, 그것은 바로 “이 기술이 대규모 트래픽과 운영 환경 속에서 어떻게 버티고, 어떻게 비즈니스를 지켜내는가?”였습니다.

단순히 새로운 기술 스택을 배운 것을 넘어, ‘개발을 대하는 시선’ 자체가 어떻게 변하고 성장했는지 그 치열했던 회고를 공유하고자 합니다!

1. Database: “정답 찾기”에서 “변화에 대비하기”로

DB 파트에서 가장 크게 바뀐 건 기술적인 지식보다도 '사고의 출발점’이었습니다. 예전엔 설계를 보며 “이게 이론적으로 맞나?”를 물었다면, 이제는 “이게 운영에서 버틸 수 있나?”가 먼저 떠오릅니다.

무결성은 ‘규칙’이 아닌 ‘책임의 위치’다

학부 때는 학교 강의에서 배운대로 ERD를 그릴 때 Foreign Key(FK)를 단단하게 묶는 것이 곧 완성도라고 믿었습니다. 하지만 트래픽과 변경이 잦은 실무 환경에서 물리 FK는 락(Lock), 성능, 유연성 측면에서 큰 부담이 될 수 있다는 것을 배웠습니다.

FK를 걸지 않는다는 것이 무결성을 포기한다는 의미가 아닙니다. 무결성을 DB가 책임질 것인지, Application 단에서 책임질 것인지 그 '운영 모델’을 정하는 문제였습니다. Application에서 책임지기로 했다면, 그만큼 테스트와 보정 로직을 더 단단하게 가져가야 한다는 현실적인 감각을 익혔습니다.

삭제(Delete) 역시 마찬가지입니다. 실무에서는 데이터를 단순히 지우는 것보다, 감사 추적이나 복구 가능성을 위해 deleted_at 같은 필드를 두는 소프트 딜리트(Soft Delete)가 타협이 아닌 '필수 운영 전략’임을 깨달았습니다.

인덱스와 SQL, 보는 눈이 달라졌습니다

인덱스를 “B-Tree = 조회 빨라짐” 정도로만 이해하던 시절이 있었습니다. 교육에서는 인덱스를 속도 향상의 도구가 아니라 데이터 특성에 따른 구조 설계로 바라보자는 질문을 던졌고, 그 순간부터 GIN, GiST, SP-GiST, Vector 인덱스 같은 선택지가 "DB가 어떤 질문을 받는지에 따라 골라야 하는 자료구조의 결정"으로 보이기 시작했습니다.

SQL도 마찬가지였습니다. 결과만 맞으면 괜찮다고 생각했는데, 실행 계획을 보기 시작하면 같은 SQL이 전혀 다른 의미로 읽힙니다. 어떤 쿼리는 인덱스를 타고, 어떤 쿼리는 테이블 전체를 훑고, 그 차이가 디스크 I/O와 응답 시간으로 이어집니다.

이제는 SQL을 "작성한다"기보다 실행 경로를 "유도한다"는 감각에 더 가깝습니다.

"중복은 악"에서 "중복은 전략"으로

한때 데이터 중복을 보면 마음이 불편했습니다. 정규화가 미덕이고, JOIN은 당연한 과정이라고 생각했으니까요. 그런데 트래픽과 데이터가 커지면 JOIN은 곧바로 병목이 됩니다.

읽기 성능을 지키기 위한 의도적 반정규화는 타협이 아니라 전략일 수 있고, 비즈니스 요구사항을 지키기 위한 스냅샷 저장이 필요한 순간이 있다는 걸 체감했습니다. 특히 MongoDB 파트에서 이 감각이 크게 와닿았는데, ref로만 관계를 선언하면 처음엔 깔끔하지만 화면 요구사항이 커지는 순간 조회가 복잡해지고, 필요한 정보를 스냅샷으로 함께 저장해두면 추가 조회 없이도 화면을 채울 수 있었습니다.

데이터 생태계의 철학

MySQL의 고가용성(HA) 아키텍처, PostgreSQL의 PK 구조, 그리고 스토리지와 컴퓨팅 계층이 분리된 클라우드 네이티브 DB(Neon) 등을 학습하며, DBMS는 각자의 철학과 설계적 트레이드오프를 가진 시스템”, 아니면 “DBMS는 각자의 철학과 성능·일관성·확장성 사이의 트레이드오프를 반영한 시스템이라고 느끼게 되었습니다. 빅데이터 역시 Hadoop, Spark 등의 개별 기술이 아니라 저장-관리-처리-분석으로 이어지는 거대한 흐름으로 이해하는 시야를 얻었습니다.

“이론적으로 완벽한 설계보다, 변경에 안전하고 운영 비용을 감당할 수 있는 설계를 먼저 떠올리게 되었습니다.”

2. Security & IT: “남 일”에서 “내 기본값”으로

보안 교육의 첫 시작은 "만약 우리 서비스에서 개인정보 유출이 난다면?"이라는 무거운 가정이었습니다. 그 순간, 보안은 규정이나 인프라팀의 업무가 아니라 '내 코드에서 시작되는 결과’로 다가왔습니다.

보안은 기술이 아닌 일상의 기본값

단순히 인터넷에 접속하고 업무 장비를 사용하는 데에도 수많은 검사와 안전장치(Dev/Prod 분리, VPN, 백신 등)가 존재합니다. 안전은 다소간의 ‘불편함’ 위에 쌓여 있다는 사실을 체감했습니다.

CERT: "막는 것"보다 "구분하는 것"이 더 어렵습니다

DDoS 이야기에서 특히 현실감을 느꼈습니다. 공격은 24시간, 다양한 주소에서 들어오고, 방어자는 맞서야 하는 입장입니다. 그런데 더 어려운 포인트는 따로 있었습니다. 트래픽이 몰린 것인지, 공격인지 구분하는 것 자체가 어렵다는 점입니다. 특정 이벤트로 트래픽이 폭증하면, 그것이 기쁜 일인지 위험 신호인지 바로 판단하기 어렵습니다.

개인이 당장 할 수 있는 건 요청 수 제한(Rate Limit) 같은 기본 방어를 갖추는 것, 그리고 이상 징후가 보이면 혼자 해결하려 하지 말고 공유하고 대응 체계에 연결하는 것이었습니다.

API 보안: 직접 뚫어보니 '내 코드’가 보였습니다

API 보안 세션은 뉴크루들의 반응이 가장 뜨거웠습니다. 이론으로만 듣던 취약점을 직접 실습하며 공격자 시점을 경험했기 때문입니다. “직접 뚫어보니까 재밌다. 근데 내가 작성한 코드가 뚫리면 많이 슬퍼질 것 같다.” 이 감정이 중요한 성장이었다고 생각합니다. 보안을 남의 서비스 이야기에서 내 코드 이야기로 가져오는 순간이니까요.

보안은 "한 번 해두면 끝"이 아닙니다

교육 과정에서 최근 보안 이슈를 직접 찾아보기 시작한 뉴크루도 있었습니다. AI가 취약점을 찾아주는 흐름을 조사하면서 "방패도 창도 함께 똑똑해지는 시대"라는 감각을 얻었고, QR 코드나 앱 권한처럼 사람의 심리를 노리는 공격 기법까지 다루면서, 기술뿐 아니라 습관 수준에서의 경각심이 필요하다는 걸 체감했습니다.

보안 점검은 "마지막에 한 번"이 아니라, 개발 단계부터 기본값으로 붙어 있어야 한다는 결론에 도달했습니다.

결국 소프트웨어는 ‘사람’ 위에서 굴러간다

우리는 컴퓨터와 대화하는 것이 익숙하지만, 소프트웨어 엔지니어링은 결국 사람의 문제를 풀고 사람과 함께 일하는 과정입니다.

내가 당장 프로젝트에서 빠지더라도 다음 사람이 코드를 읽고 즉시 온보딩할 수 있도록 만드는 것이 진정한 '품질’이며, 무수히 많은 해결 방법 중 비즈니스 상황에 맞는 '최적을 고르는 힘’이 개발자의 진짜 실력임을 배웠습니다.

“보안은 막으면 끝나는 방패가 아니라 개발의 기본값이 되었고, 기술은 결국 사람, 소통, 품질, 그리고 올바른 판단 위에서 굴러간다는 것을 깨달았습니다.”

3. AI: “말 걸기”에서 “설계하고 연결하기”로

첫날 가장 크게 남은 문장은 이것이었습니다. “Agent는 모델이 아니라 설계다.”

수업 전에는 AI Agent 아키텍처가 범접하기 어려운 영역처럼 느껴졌습니다. 그런데 예제 코드를 보니 구조가 낯설지 않았습니다. 자주 쓰는 기능은 함수로 만들고(툴), 메인 로직에서 조건에 따라 호출하고(라우팅), 실패하면 예외 처리로 잡고, 그 사이에 LLM 호출이 하나 들어갑니다.

에이전트 개발은 결국 우리가 늘 하던 서비스 개발의 설계 습관을 AI에 적용하는 일에 가까웠습니다. 이걸 깨닫고 나니 AI가 갑자기 덜 무서워졌습니다. 모델을 만드는 일은 어렵더라도, 모델을 써서 일을 하게 만드는 설계는 우리가 할 수 있는 영역이니까요.

확률을 통제하는 시스템 설계

LLM은 본질적으로 매번 결과가 흔들릴 수 있는 확률 모델입니다. 우리가 원하는 것은 똑똑한 한 번의 대답이 아니라, 일관된 출력과 안정된 흐름이었습니다.

이를 위해 거대한 요청을 한 번에 던지는 대신 단계별로 쪼개어 컨텍스트 오염을 막고(Prompt Chaining), 예시를 통해 출력 규격을 명확히 강제하며(Few-shot), 조건에 따라 프롬프트를 분기시키는(Routing) 등 서버 코드의 아키텍처를 설계하듯 AI를 다루는 법을 배웠습니다.

멀티 에이전트와 시스템의 결합 (RAG, MCP)

거대한 모놀리식 AI 하나에 의존하는 대신, 데이터 분석, 콘텐츠 생성 등 역할을 나눈 ‘멀티 에이전트(Multi-Agent)’ 구조가 훨씬 빠르고 안정적이라는 사실은 MSA(Microservices Architecture)의 철학과 맞닿아 있었습니다.

특히 인상 깊었던 것은 MCP(Model Context Protocol)와 RAG(Retrieval-Augmented Generation)였습니다. MCP를 통해 우리 내부 시스템의 고유 기능과 데이터를 AI가 호출할 수 있는 함수(Tool) 형태로 노출함으로써, AI의 한계를 기업의 시스템 자원으로 극복하는 '원격 Function Calling’의 개념을 체득했습니다. 또한 RAG를 통해 할루시네이션을 정성적으로 줄이는 것이 아니라, 문서를 청킹하고 유사 벡터를 검색해 증강시키는 '구조적 통제’로 해결할 수 있음을 배웠습니다.

"화내기"에서 "명확히 요구하기"로

AI 파트의 마지막 슬라이드 제목이 솔직해서 웃음이 났습니다. “LLM에게 화만 낸다고 해결되지 않는다.” 그런데 웃기면서도, 사실이었습니다.

수업 이후 우리가 AI를 쓰는 방식은 '감정’에서 '요구사항’으로 이동했습니다. 이전에는 프롬프트를 던지고 결과가 별로면 화를 냈다면, 이후에는 목표를 제시하고, 출력 형식을 예시로 보여주고, Sub-Agent를 활용하고, RAG를 위한 데이터를 붙이고, 컨텍스트를 관리합니다.

이 변화는 "AI를 더 잘 쓰게 됐다"만이 아니었습니다. AI를 대화 상대로 대하는 것이 아니라, 일을 맡길 시스템으로 설계하기 시작한 것이었습니다.

AI 파트에서 가져간 문장 하나. AI는 똑똑한 답을 받는 기술이 아니라, 똑똑한 동작이 나오게 만드는 설계입니다.

“AI는 똑똑한 답을 ‘받기’ 위해 기도하는 대상이 아니라, 똑똑한 동작이 ‘나오도록’ 우리 시스템과 연결하고 설계하는 강력한 컴포넌트입니다.”

마치며: 안전하게 지키고, 가치 있게 만들자

이번 DB, 보안, AI 기술 온보딩을 한 문장으로 요약하자면, “정답을 맞히는 학생에서, 운영의 무게까지 고려하는 개발자로의 전환”이었습니다.

이론적으로 코드를 짜는 것을 넘어, 트래픽을 버티는 DB를 설계하고, 내 코드의 취약점을 의심하며, AI를 비즈니스 로직에 단단하게 결합하는 법을 배웠습니다.

그리고, 이번 기술 온보딩 교육 전체를 돌이켜보면, 지식 습득을 넘어 개발자로서의 본질적인 자세에 대해 깊이 깨달음을 얻는 시간이었다고 생각합니다. 개발이나 성장에 유일한 정답은 없으며, 당면한 리소스와 상황을 고려하여 가장 합리적인 선택을 도출하고, 그 결정을 팀원들에게 논리적으로 공유하고 설득하는 것이 개발자의 핵심 역량이지 않을까… 하는 생각을 하게 된 것 같습니다.

이 소중한 배움의 시간을 만들어주신 강의자분들과 동기들, 그리고 교육을 위해 물심양면으로 힘써주신 엘피, 셜리, 에이라, 스카이, 시몬을 비롯한 모든 관계자분들께 진심으로 감사드립니다.

이 교육에서 얻은 시야와 감각을 바탕으로, 앞으로 카카오의 서비스를 더 안전하게 지키고 더 큰 가치를 만들어내는 개발자들로 성장할 우리 Krew들을 지켜봐주세요!

학생에서 개발자로: DB, 보안부터 AI까지, 정답보다 합리적인 선택을 배우다