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

카카오 신입 개발자 온보딩은 기술의 정답을 암기하는 교육이 아니라, 대규모 트래픽과 운영 환경을 견디는 합리적 설계를 배우는 과정이었다. DB에서는 변경과 운영 비용을 고려하고, 보안에서는 취약점을 자신의 코드 문제로 인식하며, AI에서는 모델의 불확실성을 시스템 설계로 통제하는 관점을 익혔다. 결국 개발자의 핵심 역량은 상황과 리소스에 맞는 선택을 하고, 그 근거를 팀과 공유·설득하는 능력이라는 결론에 도달한다.

DB: 이론적 정답보다 운영 가능성을 우선하기

• 무결성은 반드시 DB가 전부 책임져야 하는 규칙이 아니라, DB와 애플리케이션 중 어디에 책임을 둘지 정하는 운영 모델이다.
• 물리적 Foreign Key는 무결성을 보장하지만, 트래픽과 변경이 많은 환경에서는 락, 성능 저하, 스키마 변경의 유연성 문제를 일으킬 수 있다.
• 애플리케이션이 무결성을 담당한다면 테스트와 데이터 보정 로직을 강화해야 한다.
• 삭제된 데이터를 복구하거나 감사 추적해야 하므로 deleted_at을 활용한 소프트 딜리트가 실무의 중요한 운영 전략이 된다.

인덱스와 SQL: 결과가 아니라 실행 경로 설계하기

• 인덱스는 단순히 조회 속도를 높이는 기능이 아니라, 데이터 특성과 질의 방식에 맞는 자료구조 선택이다.
• B-Tree 외에도 GIN, GiST, SP-GiST, Vector 인덱스 등 다양한 선택지가 있으며, DB가 어떤 질문을 받는지에 따라 적합한 인덱스가 달라진다.
• 실행 계획을 확인하면 동일한 SQL이라도 인덱스를 사용하는지, 테이블 전체를 스캔하는지 파악할 수 있다.
• 이러한 실행 경로의 차이는 디스크 I/O와 응답 시간에 직접 영향을 준다.
• SQL 작성은 단순히 원하는 결과를 반환하는 작업이 아니라, 효율적인 실행 경로를 유도하는 작업으로 이해해야 한다.

중복과 반정규화: 데이터 중복을 성능 전략으로 활용하기

• 정규화와 JOIN이 항상 최선은 아니며, 데이터 규모와 트래픽이 커지면 JOIN이 병목이 될 수 있다.
• 읽기 성능을 위해 일부 데이터를 의도적으로 중복 저장하는 반정규화가 합리적인 선택이 될 수 있다.
• 당시의 비즈니스 상태를 보존해야 한다면 관련 정보를 스냅샷으로 저장하는 방식도 필요하다.
• MongoDB에서는 관계를 ref로만 연결할 경우 조회가 복잡해질 수 있어, 화면에 필요한 정보를 함께 저장하면 추가 조회를 줄일 수 있다.

DB 생태계: 성능·일관성·확장성의 트레이드오프 이해하기

• MySQL의 고가용성 구조, PostgreSQL의 PK 설계, Neon의 스토리지·컴퓨팅 분리 등 DBMS마다 고유한 설계 철학이 있다.
• 어떤 시스템도 모든 상황에서 최선일 수 없으며, 성능·일관성·확장성·운영 비용 사이의 균형을 선택해야 한다.
• Hadoop과 Spark 같은 빅데이터 기술도 개별 도구가 아니라 저장, 관리, 처리, 분석으로 이어지는 데이터 생태계의 일부로 이해해야 한다.
• 이론적으로 완벽한 구조보다 변경에 안전하고 운영 비용을 감당할 수 있는 설계를 우선하게 되었다.

보안: 외부 조직의 일이 아니라 개발자의 기본값

• 개인정보 유출 가능성을 가정하면서 보안을 규정이나 인프라팀의 업무가 아닌 자신의 코드에서 시작되는 책임으로 인식하게 되었다.
• Dev/Prod 분리, VPN, 백신 등은 편의성을 일부 희생하더라도 안전을 확보하기 위한 장치다.
• DDoS 대응에서는 공격을 차단하는 것뿐 아니라 정상적인 트래픽 폭증과 공격을 구분하는 일이 어렵다는 점을 배웠다.
• 개발자가 적용할 수 있는 기본 방어책으로 Rate Limit을 활용하고, 이상 징후가 발생하면 혼자 해결하지 않고 대응 체계에 연결해야 한다.

API 보안과 지속적인 점검

• 취약점을 직접 공격해보는 실습을 통해 보안을 이론이 아닌 자신의 코드에 대한 문제로 체감했다.
• AI를 활용한 취약점 탐색, QR 코드 공격, 앱 권한 악용처럼 방어 기술과 공격 기술이 함께 발전하고 있다.
• 보안은 배포 직전에 한 번 점검하는 절차가 아니라 개발 초기부터 기본값으로 포함되어야 한다.
• 코드 품질은 작성자가 자리를 비워도 다른 개발자가 빠르게 이해하고 운영할 수 있는지까지 포함한다.

AI Agent: 모델보다 중요한 것은 시스템 설계

• AI Agent는 특별한 모델 자체라기보다, 도구 호출, 라우팅, 예외 처리, LLM 호출을 조합한 시스템 설계에 가깝다.
• 기존 서비스 개발에서 사용하던 함수 분리와 조건 분기, 장애 대응 습관을 AI 시스템에도 적용할 수 있다.
• LLM은 확률 모델이므로 매번 결과가 달라질 수 있어, 한 번의 뛰어난 답보다 일관된 출력과 안정적인 실행 흐름을 설계해야 한다.
• Prompt Chaining으로 작업을 단계별로 나누고, Few-shot으로 출력 형식을 구체화하며, Routing으로 상황에 따라 프롬프트를 분기할 수 있다.

멀티 에이전트와 RAG·MCP의 결합

• 하나의 거대한 AI에 모든 역할을 맡기기보다 분석, 콘텐츠 생성 등 역할을 나눈 멀티 에이전트 구조가 더 빠르고 안정적일 수 있다.
• 이는 기능과 책임을 분리하는 MSA의 설계 철학과 유사하다.
• MCP는 내부 시스템의 데이터와 기능을 AI가 호출할 수 있는 Tool로 노출해, 원격 Function Calling처럼 활용하게 한다.
• RAG는 문서를 청킹하고 유사 벡터를 검색해 관련 정보를 컨텍스트에 추가함으로써 할루시네이션을 구조적으로 줄인다.
• AI를 잘 활용하려면 결과가 마음에 들지 않을 때 감정적으로 반응하기보다 목표, 출력 형식, 예시, 필요한 데이터와 컨텍스트를 명확히 정의해야 한다.

실무에서는 “무엇이 이론적으로 맞는가”보다 트래픽, 변경 가능성, 보안 위험, 운영 비용을 함께 검토해야 한다. DB 설계와 보안 점검, AI 기능 개발 모두를 일회성 작업이 아니라 지속적으로 관찰하고 개선하는 시스템으로 접근하는 것이 바람직하다.