메모 - 카카오 컨퍼런스

• [[KnowledgeBase/PARA/03_Resources/R001_개발_레퍼런스(참고문서)/if kakao 타임 테이블]]

퀘스트

• 13시 세션 참여 ✅ 2025-09-25
• B1F에서 카나나 세이프카드 체험 ✅ 2025-09-24
• b2f입구에서 AI Talk 보드 작성 ✅ 2025-09-24
• b2f에서 카나나 모델 체험 ✅ 2025-09-24
• b1f에서 PlayMCP 체험 ✅ 2025-09-25
• 14시 세션 참여 ✅ 2025-09-25
• 15시 세션 참여 ✅ 2025-09-25
• 16시 세션 참여 ✅ 2025-09-25

계획

• 1시에
  • 1F Conference Room 2
  • AI Coding Agent: 실험을 통해 확인한 생산성 그 이상의 가능성
    • 회사에 AI Coding 팀이 있으므로
• 2시에
  • B1F Team Room 1-2
  • 구조 설계로 함께 성장하기: 주니어의 시도를 리스크 없이 끌어안는 방법
• 3시에
  • B1F Team Room 1-2
  • 복잡한 흐름 앞에서, 우리가 선택한 건 퍼넬이었다
• 4시에
  • B1F Team Room 3-4-5
  • 김대리, SQL 팡션? 사용하지 마세요. MCP 쓰세요: AI 기술을 이용한 데이터 민주화
• 4시 20분에
  • B1F Team Room 3-4-5
  • AI를 활용한 자동 게임보안 검수 시스템

일지

• 출발
  • 지각함
    • 택시탐
  • 뭔 시골 깡촌에 있네
• MCP 관련
  • MCP로 뭘 하겠다
• 에이전트 모델 개발자 옴
  • 에이전틱 AI라고 부르는듯
    • 핵심 능력
      • 지각, 추론, 행동
  • 카카오톡 서비스 내에서 사용할 AI인듯
    • 카나나 모델?
  • 카나나2는 어떻게 만들것인지
    • 장기적으로는 글로벌
    • 가볍게 생각하는 모델과 깊게 생각하는 모델을 결합하여 하이브리드로 간다고함
  • MLA란
    • https://digitalbourgeois.tistory.com/809
  • MoE란
    • https://railly-linker.tistory.com/176
  • 시연
    • 신호등 분석
    • 메뉴판 분석
    • 나름 있어보이긴함
    • 특히 메뉴판 매우 자세하게 분석하네
      • any to any
    • 카나나 v
      • 비전
    • 카나나 a
      • 오디오
    • 이 대본을 배우가 연기하듯 읽어줘
      • 진짜 감정을 담아서 말함.
    • 그 외에 비주얼, 음성 생성 모델도 많음
      • 이미지
      • 영상
      • 소리
    • 이러한 것들이 멀티 모달이라고 할 수 있음.
  • 내 생각 : 카카오는 AI를 코어부터 개발할 생각이구나
  • 근데 얼마나 잘할 수 있을까?
• AI 기업윤리
  • 뭐 의미 있나
• CTO 강연
  • AI 네이티브란 무엇인가
  • AI를 OS로 바라보기
    • AI는 인류라는 OS를 한단계 버전업하는 혁명이라고 생각한다.
      • 멋진 표현이다
    • LLM을 OS레이어로 인식하고 활용해야 한다고 생각함
      • 임베디드 OS처럼 커스텀 LLM을 만들자
  • 초거대기업들은 AI 총력전을 벌이고 있다.
    • 국가단위다
    • 140조짜리다
  • 카카오에서 120달러씩 주고 개발자들에게 AI 시켜봄
  • 기업 전체의 생산성이 올라가는것은 명확하게 입증됨
    • 그렇다면 다음 스탭은?
    • 진짜 생산성이 증가합니까? 드라마틱하게?
      • 네. 드라마틱하게 증가합니다.
        • 그러나 커뮤니케이션 속도는 똑같음
          • 커뮤니케이션을 줄이면 생산성이 빨라짐
            • AI를 잘 이해했거나 한명이 멀티포지션을 소화하는 경우 효율적임
    • 개발자가 2~3인분하는데 주니어 굳이 뽑아야하나요?
      • 기술 도메인 전문성
        • 카카오같은 대규모 트래픽 경험은 AI에 결코 대체되지 않는다
      • AI와 협업하는 마인드
      • 균형감 있는 사람
        • 너무 AI에 휘둘리지 않는 사람
    • 굳이 따지자면 굳이 뽑을 필요 없다는 뜻으로 이해됨
  • 개발자의 미래?
    • 무엇을 할것인가? 가 아닌 어떻게 할 것인가?
    • 결국 AI의 손이 미치지 않은 모든 산업 분야에서 AI가 제 역할을 하게 될 것이다.
• 12시부터 체험존이 운영되었는데 솔직히 구경하기 쉽지 않았음. 줄이 너무너무 김
  • 카카오에서 선보이는 AI 기반 서비스가 기대되긴 했음.
  • 그러나 다른 테크 기업들도 이정도는 하지 않을까 라는 생각도 같이 들었음.
• AI 코딩
  • 나는 낚시하는 개발자 이호정이다
  • 실제로 바이브코딩, AI가 쓸만한지 검증하는 일을 했다.
  • 거대한 코드베이스, 카카오 레벨의 프로덕트에서 적용 가능한지 검증했다.
  • 첫번째로 낚시앱을 개발해봄
    • 내가 제주도 살고, 낚시 좋아하니까
    • 일주일만에 만들어야 했음.
    • 단순 개발뿐만 아니라 기획 등등 다 AI적용함
    • 코딩 자체는 3일걸림
  • 어쨌든 완료는 했음
    • 코드는 개판이었음
    • 프로덕션 적용하기엔 문제가 있다는 판단을 함
  • 팀으로 적용해봄
    • 알짜들로 구성된 3인파티
    • 생산성이 2배 올랐음.
  • 대규모로 적용해보려고 함
    • 월 120달러까지 무료로 쓰게해줌
    • 코딩 가이드북 만들어서 배포함
      • 이것도 AI로 만듬
  • 105명의 개발자를 기반으로 다시 검증함
    • 다양한 직무, 다양한 연차로
    • 생산성 2배
      • 생산성을 논하는것은 이제 의미가 없다
      • 설문조사, 심층 인터뷰, 조직, 과제별 인터뷰 등등으로 피드백 받음
        • 이제 AI없이 개발 가능하다가 32%밖에 없음
        • 약 70%는 AI없이 개발 '불가'하다고 함
          • 팀에서 팀원을 뺏어가는것임
          • 돈내서라도 쓸거다
          • 업무를 하고싶지 않다
          • 오히려 16년차는 전부 AI없이 못한다고하고 1년차들은 할만하다고 함
      • 숫자는 거짓말을 하지 않는다
        • 11%가 리드타임이 80%이상 단축됐다고함
        • 40%가 50%이상 단축됐다고함
        • 오히려 늘었다는 사람은 2%였음
      • 직렬별로는 큰 차이가 나지 않았음.
      • AI 에이전트가 뭐에 가깝나
        • 검색도구 38%
        • 주니어개발자 27%
        • 유능한 동료 27%
        • 전략적 파트너
        • 독립적인 에이전트 5%
    • PoC가 85% 단축됨
      • 2주 -> 2일
    • 작업 시간 자체가 줄어드니까 다른 일에 집중할 수 있어서 좋았음.
    • 전반적으로 16년차 이상 개발자들은 타 연차에 비해 생산성이 말도 안되게 상승했다고 답변함
    • 결론
      • 어떻게 할 수 있는가
        • 사람
          • 정책 구조 설계와 추상화 사고에 집중
        • 구현
          • AI에 위임
        • 16년차 이상 개발자들은 병렬, 비동기 작업 처리의 일상화
      • 무엇을 할 수 있는가
        • 신기술에 대한 두려움 감소
        • PoC 초고속
      • 누가 일하는가
        • 크지 않으면 1인 프로젝트 가능
        • 업무 스트레스 감소
        • AI 노하우가 올라가면서 개발 효율 급격한 상승
    • 필요한 자질
      • 주도성
      • 지적 호기심
      • 비판적 사고
• 어쩌다 시니어
  • 난 시니어인가?
    • 이제 시니어로의 역할을 조금씩 수행해야 하는 사람이 되어가고 있음.
    • 근데 이런걸 배운적이 있나?
      • 배운적 없는 것 같음
        • 왜 못배웠지?
          • 회사에서 그냥 당장의 업무를 하는것도 벅참
          • 일 끝나면 다음 프로젝트 시작
            • 반복적인 프로세스하다보면 어느순간 리더하라고 함
  • 결국 나는 여러 프로젝트를 성공적으로 수행한 경험많은 주니어 개발자가 됨
    • 시니어 개발자의 할일?
      • 프로젝트의 안정적인 완수
        • 일 잘하는 사람에게 잘할 수 있는 일 부여
      • 동료의 성장
        • 반복적 업무가 아닌 도전적 과제를 부여
    • 실로 모순적인 목표라고 할 수 있음.
    • 우리는 성장할 곳과 일할 곳을 구분하기 어려움
  • 어떻게 할 수 있을까?
    • 업무 설계로 만드는 안전망
      • 어디까지가 리스크 없는 범위일까?
      • 가장 확실한건 '내가'하는 것임
      • 스스로를 트럭팩터
        • https://namu.wiki/w/%EB%B2%84%EC%8A%A4%20%ED%8C%A9%ED%84%B0로
          로 만드는 일
      • 과중한 업무가 주어진 경우
        • 도전적이지만 실패확률 높음.
        • 자신감 떨어짐
      • 난이도를 정략적으로 측정
        • 이상 사태를 빠르게 파악
      • feature slicing
        • 피쳐를 잘 나눠야함
        • 충분히 쪼개진 피쳐는 이해하기 쉬운 과업 단위임
      • planing poker
        • 다양한 팀원들이 공수를 측정하는 것
        • 이렇게 산정된 일정을 외부에 개런티 할 수 있나?
          • 잘 만든다면 충분히 가능하다고 봄
        • 공수 산정 기준
          • 피쳐를 프로젝트로 나누면 생각이 다름
            • a프로젝트 한달, 누구는 세달, 누구는 4달
          • 피쳐로 하면 하루, 이틀 이런차이만 남
      • 주니어 개발자와 시니어개발자의 차이
        • 일을 분리해서 바라보는 능력임
        • 피쳐를 만드는 능력
          • 다같이 산정할 수 있는 피쳐
          • 동시에 누구에게도 할당할 수 있는 피쳐
          • 쉽게 난이도 판단을 할 수 있음
    • 구조적 원칙으로 만드는 안전망 ISP와 DIP
      • 어려운 과제의 위험을 어떻게 격리할 수 있을까?
        • 기술적으로 해결 가능할까?
      • ISP
        • ISP는 왜 어려운가
          • 끊임없이 변화하는 요구사항
          • 불확실한 미래
          • 불필요한 인터페이스 확장
          • 프론트엔드
            • 프론트엔드는 일반적으로 인터페이스를 설계하는 게 아니라 소비하는 입장이므로 이런 문제가 자주 발생함.
              • 제공받은 API 단위를 어떻게 나눌 것인가?
            • 시니어가 ISP로 인터페이스를 설계하여 위험 범위 한정 할 수 있음
        • 명확한 인터페이스 기반으로 업무 할당
          • 작업 범위 명확
          • 사이드 이펙트 차단
          • 자신감 부여
      • DIP
        • 상위 수준 모듈이 하위 모듈에 직접 의존하지 않도록 하는 설계 원칙
        • 구체적인 구현 격리
          • 기능 요구사항을 명확하게 정의해야함.
          • api, 에러처리 등의 여러 페이지에서 사용되는 경우
            • 수십개의 페이지에서 수정을 반복하게 됨.
          • 유지보수 비용이 급격히 오름
          • 커스텀훅을 통해 상태, 데이터 패칭, 에러 헨들링을 별도의 환경으로 격리
          • 그렇게 하면 컴포넌트에서는 무엇을 그릴지만 고민하면 됨.
          • 작업 순서를 다르게 해도 인터페이스와 기능분리가 명확하기 때문에 문제가 덜함.
    • 정리
      • 책임과 성장은 기술적으로 해결할 수 있는 문제였다
      • 정답이 아닌 좋은 질문을 설계하는 것이 좋은 시니어 개발자이다.
• 답은 퍼널이었다.
  • 난 카카오 프론트엔드 개발자임
  • 퍼널이 뭔지 암?
    • 넷퍼널?
  • 카카오톡 채널 개발하는듯
    • 채널 관리자 센터에서 채널톡, 각 매장 관리 가능함
    • 정책 통합을 통해 앱에서도 매장관리가 가능해짐
      • 정책 통합 때문에 동선이 복잡해짐.
        • 기획서 자체는 잘 되어있었지만 동선이 너무 많음
          • 유저 유형도 너무 많음.
        • 그나마 재사용 되는 페이지가 많고, 페이지에 노출되는 정보가 단순했음.
      • 어떻게 동선 관리를 할 수 있을까?
        • url로 이동
          • react dom router
          • 전체 흐름이 파악 안됨
          • 문서 의존도 높음
          • 담당자가 아니면 추적 힘듬
        • state로 이동 제어
          • 상태값 기반 페이지 매핑 및 이동?
          • 페이지 히스토리를 직접 관리해야함
          • 디버깅이 난해함
          • 불확실함
        • 섞어서 하기로 함.
          • 퍼널?
            • 서비스, 웹사이트, 또는 제품에서 많은 사용자가 유입되지만 실제 구매·회원가입 등 최종 목표까지 도달하는 사람은 점점 줄어들며, 이 과정을 깔때기 구조로 표현한다.
          • 유저 여정을 어떻게 모델링할까?
            • step-funnel-flow
            • step
              • 로그인, 사용자 정보 입력 등
            • funnel
              • 신규안내, 오프라인 매장 여부 등 스탭의 모음
            • flow
              • 퍼널의 모음
              • 예시
                • 채널 없이 새로 시작하는 flow
                • 매장 없는데 채널에서 심사 신청하는 경우
            • 퍼널의 순서는 바뀔 수 있음.
      • 기획자에게 전달하여 역기획 후 기획자에게 제안함.
        • 라 동선에서 C퍼널 제거 후 D부터 시작할 수 있을까요?
          • 이런식으로 제안함
        • 효과적으로 관리 가능했음.
      • 지표 분석
        • 특정 퍼널에서 이탈이 높은 이유 분석 가능
        • 데이터 기반 결정 가능
          • 이탈 지점 파악, 퍼널 단축 가이드 강화
        • 동선 정리를 넘어 개발에도 확장
    • 퍼널의 확장
      • 라이브러리 쓰려다가 직접 개발하기로 함
      • 브라우저의 히스토리에 대한 고민
        • 웹뷰이기 때문에 url이 외부에 노출되지 않음
        • 안드로이드에도 호환되어야함.
        • url과 state의 절충안으로 쿼리스트링을 사용하기로 함.
          • 중첩된 퍼널의 구조는 어떻게 표현하지?
            • A-B-C일때
              • B안에서 B1과 B2가 이루어진다면?
            • 쿼리스트링에 &를 연결하여 해결함
      • 타입의 안정성은?
        • 유틸리티 타입을 통해 효과적인 타입 관리가 가능했음.
      • 코드로 보는 흐름은?
        • 간결한 코드를 통해 처음보는 코드에도 쉽게 적응할 수 있도록 함.
      • 중첩 퍼널의 경우 복잡도가 크게 증가함
        • 퍼널 전환 시점에 필요한 정보와 필요하지 않은 정보를 구분해야함.
          • 퍼널 이동 시 하위 퍼널을 제거하는 로직을 추가함.
      • 추가 이슈
        • 뒤로가기를 막을 수 있는가
        • 페이지 전환 시 데이터 초기화
          • useBlock 등
    • 결론
      • 처음에는 개발적인 고민에서 시작함
      • 그러나 기획으로 확장됨
      • 그리고 다시 기술로 돌아옴
      • 개발자는 기술을 추구하지만 회사는 비즈니스를 추구함
  • QnA가 흥미로웠음.
    • 딱히 니즈가 있어서 그런건 아니었고 직접 만들어보고 싶어서 그랬다고함
• 데이터 민주화
  • 기존 데이터 체계에 문제가 있다고 생각했음.
  • 이 문제를 해결하기 위해 데이터를 체계적으로 통합하기 위한 프로젝트를 진행함
    • KUP라고 부름
    • 데이터 확산을 막는 여러 장벽이 있음
      • 요약하자면 데이터를 가져다 쓰기 너무 어렵다
        • 사람에 의존적인 데이터 요청 및 반복
        • 분석가
          • 추출 요청 너무 귀찮음
        • 요청자
          • 부담스러움
      • 이를 해결하기 위한
        • 스노우 플레이크
          • 권한 제어 기능
          • 보안 지키면서 비기술 직군까지 데이터 가져올 수 있음
        • LLM + MCP
          • 비기술자가 SQL 작성 할 수 있게 됨.
      • 테스트해봄
        • MCP 연결 만으로 사용자 요구에 맞는 SQL 작성, 결과까지 가져올 수 있는가?
          • 잘 안되더라
          • SQL은 대부분 동작안함
          • 많은 시간이 듬
          • 반복 질문에서 매번 같은 과정을 되풀이함
        • 해결하고 싶었지만 MCP가 주는 가벼움과 확장성을 유지하고 싶었음
          • MCP데이터랩 만들게됨
            • MCP가 참고할 수 있는 데이터 저장소
            • 우리가 가지고 있는 데이터 노하우 및 정보를 하나의 저장소에 저장
            • 셀프 서비스 데이터 활용
          • 왜 MCP인가
            • 표준화, 호환성, 확장성, 단순성
        • MCP
          • 시스템 아키텍처 및 데이터 흐름
            • 요청,인증, 서버 등
        • query101
          • 중앙 집중식 SQL저장소
          • 벡터, 키워드 기반 자연어 검색
          • 데이터베이스 타입 지원
          • SQL 품질 유지를 위한 평가시스템
          • KARS
            • 이상 탐지용 관제 시스템임
            • 검증된 SQL이므로 이를 활용
          • 카스에서 추출하고 맥락 분석, 디스크립션 생성, 임베딩
            • 초기 데이터 확보 완료
        • 활용 결과
          • 거의 90% 단축됨
            • 크레딧 90%감소
            • 시간 90% 감소
            • 이는 쿼리 횟수가 줄어들었기 때문임
              • 데이터 구조를 파악하기 위한 쿼리가 줄어들었음
        • 새로운 문제
          • 이전에 처리해본 요청에는 효과적이지만 완젼히 새로운 요청에 대해서는 커버가 안됨
          • 새로운 SQL 등록
            • 대응이 느림
          • agent 개발 등
          • CAT 도입
            • 시퀀셜 띵킹에서 영감을 받음
            • 도메인 지식을 이용한 SQL 생성
            • 필요하다면 외부 지식 베이스 + LLM
    • 활용 시나리오
      • 운영팀의 신규 접속자 현황 파악
      • BM 설계를 위한 환불 사유 비교
      • 신규 개인화 서비스 런칭
      • 등등등
    • 결론
      • ai 기술을 이용해 어떻게 데이터 접근성을 높일 수 있을까
        • MCP데이터랩
        • query101
        • CAT
• AI 기반 개발 자동 보안 검수 시스템
  • AI때문에 공격이 고도화되어서 보안팀은 너무 힘들었음
  • 게임은 소프트웨어 보안 기준이랑 다른 해킹 유형임
    • 너무나 변칙적임
  • 게임 보안을 설명할 수 있는 새로운 체계가 필요했음.
  • AI로 게임 보안 체계를 만듬
    • GWE / GVE
      • 어떻게 공격을 당할 수 있는가
      • 무엇이 뚫렸는가
        • 실제 사례를 기반으로 한 취약점 데이터베이스
  • 게임 보안 지식을 수집, 분석, 전처리, 검증 함
    • 완성도를 점점 고도화시킴
    • 각 게임엔진별 맞춤 보안검수
  • 정적, 동적 행위까지, 실행 즉시 점검
    • 게임이 실행되는 모든 레이어를 AI와 함께 검증함
    • GamesTotal: 자동화 분석 아키텍처
      • 정적
        • 엔진 설정, 디버그 흔적, 민감정보 등
      • 동적
        • 메모리변조, 인젝션, 컨텐츠 값 수정
      • 행위 분석
        • 스피드핵 패턴 판별
        • esp freecom 행위
      • 모든 단계에서 AI가 관여함
        • 1단계
          • 개발환경 구성
          • 분석 프레임워크도 직접 로드
          • 메모리 덤프, pak 분석
        • 2단계
          • 정적분석
          • 엔진별 메모리 덤프, 함수 매핑
          • 코드분석, 엔진구조 취약점 및 미사용 함수 식별
        • 3단계
          • 동적 분석
          • 엔진 객체 동작 재현
          • 난독화 검증
          • 모딩 탐지
        • 4단계
          • 정상, 변조 플레이 시나리오 비교
          • 프레임, 메타데이터 저장
          • 공격 패턴, 이상행위 분류
          • 좌표 이동 등을 통해 분석하고
            • 이상하게 움직이면 탐지
        • 5단계
          • 못들음
      • 기존 인력 그대로, 위협의 속도를 따라잡다
    • 그 다음 스탭은?
      • GVE DB 고도화
      • 실시간 연계
    • 게임 보안을 이해하는 AI는 실현 가능하며 우리는 구현했다.
      • 보안 자동화를 현실로 하겠다.