AI는 일하고, 사람은 기준을 만든다: if(kakao)26 Day 1 후기
🪄 AI가 '등장하는' 컨퍼런스에서 AI가 '메인'인 컨퍼런스로
2026년 10월 13일, 카카오 AI 캠퍼스에서 열린 if(kakao)26 첫째 날에 다녀왔다.
카카오 AI 캠퍼스 입구
지난 컨퍼런스들에서는 AI가 주제에 등장하는 정도였다면, 이번에는 AI가 모든 발표 세션의 기본 주제로 깔려 있었다. 행사 슬로건 역시 "모든 연결에 지능을"이었다.
이 글에서는 Day 1에 들은 세 세션을 정리한다.
| 시간 | 트랙 | 세션 |
|---|---|---|
| 13:00–14:00 | AI 시대의 개발자 (Fireside Chat) | AI로 오래 미뤄둔 변화를 실행하는 법 |
| 13:30–14:00 | 상생과 성장 | 잘 만들었다면, 잘 배운 것일까?: 카카오테크 캠퍼스가 고민한 주니어 개발자의 성장 |
| 14:00–14:30 | Model & Agent | "그 사진 찾아줘" 한마디면 끝: Kanana 멀티모달 임베딩 모델 개발기 |
체험존에서 만든 키캡. 뒤로 보이는 곳이 세션이 열린 Growing hall
🤝 AI는 일하고, 사람은 기준을 만든다: 미뤄둔 변화를 실행한 네 팀
「AI로 오래 미뤄둔 변화를 실행하는 법」은 여러 패널이 함께 무대에 앉아, 각자 "해야 하는 걸 알면서도 오래 미뤄 둔 일"을 AI로 실행한 사례를 하나씩 이야기하는 Fireside Chat이었다. 번역, 디자인 시스템 정리, 프레임워크 전환 등 주제는 달랐지만, 듣다 보니 공통된 메시지가 반복되었다.
AI는 일하고, 사람은 기준과 시스템을 만든다.
1. 번역: 각 화면에선 자연스럽던 번역이, 이어 보니 달라졌다
첫 사례는 우아한형제들의 다국어 번역이었다. 발표에 따르면 가게가 30만 곳에 이르고, '두쫀쿠' 같은 새로운 단어도 계속 생겨난다. 번역가가 직접 번역하면 100년이 걸릴 규모였다고 하니, 오래 미뤄 둘 수밖에 없었던 이유를 알 수 있었다.
흥미로웠던 점은 AI 번역의 품질이 아니라 기준이 흩어지는 문제였다. 같은 브랜드 용어 '한집배달'을 담당자마다 각자의 AI 도구 설정으로 번역하다 보니, 앞 화면에서는 Single Delivery, 다음 화면에서는 Express Delivery가 됐다. 한 문장씩 보면 둘 다 자연스럽지만, 화면을 이어서 쓰는 고객은 "내가 고른 그 서비스가 맞나?" 하고 헷갈릴 수 있다.
이 문제를 해결하기 위해 번역 → 검수 → 보고까지 담당하는 에이전트를 만들었다. AI는 번역 규칙을 검사하고, 사람은 규칙을 만들어 시스템을 운영·개선한다.
출처: if(kakao)26 「AI로 오래 미뤄둔 변화를 실행하는 법」 발표 화면
이러한 역할 분담은 '나의 할인가' 예시에서 잘 드러난다. AI는 세 언어 모두 '보통', 사람 검수 '불필요'로 분류했다. 다만 일본어에 대해서는 화면 맥락에 따라 더 간결한 표현을 검토해 보라는 의견을 함께 남겼다. AI가 점수를 매기고 의견을 내지만, 슬라이드 하단의 문장대로 "최종 표현의 확정과 시스템을 운영·개선하는 책임은 사람에게" 있다.
출처: if(kakao)26 「AI로 오래 미뤄둔 변화를 실행하는 법」 발표 화면
이 사례의 결론은 'AI가 잘했다'의 기준부터 정하기였다. 먼저 AI에게 무엇을 맡길지, 어떤 결과를 '잘했다'고 평가할지 정의한다. 이후 작게 시도하며 AI의 역할을 다듬고, 검증한 기준을 팀이 함께 쓰는 도구에 담는다. 슬라이드 하단의 "같은 모델을 쓰더라도, 각자 쓰면 결과가 달라질 수 있습니다"라는 문장은 앞의 Single Delivery / Express Delivery 문제를 그대로 설명한다. 기준을 한 곳에 두는 것이 품질 관리의 시작이다.
2. 디자인 시스템 정리: 1,000개 파일은 Boy Scout 룰로 끝나지 않는다
두 번째는 레몬베이스의 디자인 시스템 개선 사례였다. 출발점은 Boy Scout 룰의 한계였다. "코드를 처음 발견했을 때보다 더 깨끗하게 유지하고 떠나라"는 규칙은 좋지만, 실제로는 세 가지 이유로 잘 굴러가지 않았다고 한다.
- 양극화: 자주 수정되는 코드는 정리되지만, 손이 안 가는 코드는 레거시로 남는다.
- 맥락과 리뷰: 수백 개 파일의 사용 맥락과 변경 내용을 리뷰어도 함께 이해해야 한다.
- 우선순위: 사용자에게 보이는 화면은 같아서, 정리 작업은 다른 개발 과제에 밀린다.
슬라이드의 계산이 현실적이었다. 1,000개 파일 ÷ 하루 10개 = 100일. 그것도 매일 1순위일 때만.
출처: if(kakao)26 「AI로 오래 미뤄둔 변화를 실행하는 법」 발표 화면
해법에서 눈에 띈 점은 AI가 1,000개 파일을 직접 고치지 않는다는 것이었다. AI는 전체 파일의 패턴을 조사하고 변환 도구(Codemod)와 테스트를 작성한다. 사람은 변환 기준과 예외를 검토하고 도구를 승인한다. 실제 변환은 승인된 규칙으로 Codemod가 일괄 수행한다. 사람의 일이 "1,000개 파일 리뷰"에서 "규칙 하나와 예외 목록 검토"로 바뀐 셈이다.
그래도 사람이 맡아야 했던 5%의 경우가 있었다고 한다. 파일 간에 의존관계가 있거나, 파일을 넘나드는 도메인 정책을 이해해야 하는 경우에는 사람이 직접 수정했다. 여기서 메모에 질문 하나를 적었다.
그런데 이런 것까지 AI에게 자동화할 수는 없을까?
이 질문에 대한 힌트는 같은 세션의 네 번째 사례에서 얻었다.
3. Angular 11 → React 19: 기술은 바꾸고, 사용 경험은 그대로
세 번째는 OLIVE Platform(오픈소스 분석, 라이선스 의무 확인, 고지문 생성 서비스)의 프론트엔드 전환 사례였다. 서버와 API는 그대로 두고, 모바일 웹을 포함한 전체 화면과 기능을 Angular 11에서 React 19로 옮겼다. 두 사람이 실제 서비스 오픈까지 진행했다고 한다. 프론트엔드 개발자로서 가장 가깝게 다가온 사례였다.
출처: if(kakao)26 「AI로 오래 미뤄둔 변화를 실행하는 법」 발표 화면
AI에게 바로 "React로 바꿔 줘"라고 요청하지는 않았다. 먼저 React 구조, 개발 규칙, 자동 검사 환경을 준비했다. 기존 Angular 화면과 기능을 분석해 스토리와 인수 조건(어떤 기능이 어떻게 동작하면 완료인지 정한 기준)을 Jira 이슈로 등록한 뒤, 이슈별로 스킬을 실행하며 구현·테스트·리뷰를 반복했다. 특히 규칙은 프롬프트가 아니라 검사 스크립트로 만들고, 검사를 통과해야 작업이 끝난 것으로 간주했다.
AI가 전환을 마친 뒤에는 서비스를 아는 담당자가 Playwright, 기존 화면, 디자인 파일로 AI의 결과를 비교하며 차이를 찾아 보완했다. 발표에서 꼽은 차이는 세 종류였다.
- 화면·모바일: 간격, 색상, 버튼, 테두리, 모바일 배치
- 공통 컴포넌트: Ant Design 대응 누락으로 생긴 별도 구현과 CSS 덮어쓰기
- 이어지는 기능: 로그인, GitHub 연결, 프로젝트 분석 흐름
세 번째 항목이 특히 와닿았다. 화면 하나하나는 제대로 옮겨져도, 화면을 이어서 쓰는 흐름에서 문제가 드러났다. 번역 사례의 Single Delivery / Express Delivery와 같은 구조다. 따라서 AI가 작업을 시작하기 전에 무엇을 '완료'로 볼지 인수 조건으로 먼저 정의해 두는 것이 중요했다.
4. 사내 공모: 웨이브와 태스크로 나누기
마지막으로 들은 것은 kit.t의 사례였다.
출처: if(kakao)26 「AI로 오래 미뤄둔 변화를 실행하는 법」 발표 화면
사람은 방향을 정하고, 구체적인 계획은 AI에게 위임한다. 먼저 기존 코드를 분석한다. 이후 공통 모듈과 그 모듈에 의존하는 모듈을 수행 순서대로 묶어 웨이브로 만들고, 각 웨이브를 다시 최소 검증 단위의 태스크로 나눈다. 마지막으로 검증과 회고를 남겨 다음 작업에 반영한다.
앞에서 적은 질문과 연결해 보면, 레몬베이스 사례에서 사람에게 남았던 5%는 파일 간 의존관계였다. 반면 이 사례에서는 사람이 의존관계를 하나하나 고치는 대신, "공통 모듈 먼저, 의존 모듈은 그다음"이라는 순서로 바꿔 AI의 계획에 넣었다. 의존관계를 AI가 따를 수 있는 기준으로 만든 것이다.
내가 이해하기로, "이런 것까지 자동화할 수 없을까?"에 대한 답은 AI가 판단하게 하는 것보다 사람이 그 판단을 기준으로 바꿔 주는 것에 더 가깝다.
| 사례 | AI가 한 일 | 사람이 한 일 |
|---|---|---|
| 번역 | 번역, 규칙 검사, 등급 분류와 검토 의견 | 규칙과 '잘했다'의 기준 정의, 최종 표현 확정, 시스템 운영 |
| 디자인 시스템 | 패턴 조사, 변환 도구와 테스트 작성 | 변환 기준과 예외 검토, 도구 승인, 의존관계·도메인 정책이 걸린 수정 |
| React 전환 | 이슈별 구현·테스트·리뷰 | 구조·규칙·검사 환경과 인수 조건 준비, 사용자 흐름에서 차이 확인 |
| 웨이브와 태스크 | 구체적인 작업 계획 | 방향 설정, 검증과 회고 |
네 팀 모두 규칙과 기준을 먼저 세운 뒤, 작게 시도하며 AI의 역할을 다듬었다. 오래 미뤄 둔 일을 실행으로 옮길 수 있었던 이유는 사람이 AI에게 넘길 수 있는 형태로 기준을 만들어 두었기 때문이었다.
🌱 코드가 동작하더라도: 주니어 멘토링이 '왜'를 지키는 법
다음 세션인 「잘 만들었다면, 잘 배운 것일까?」는 그 기준을 만들 수 있는 사람이 어떻게 자라는가를 다뤘다. 카카오테크 캠퍼스의 멘토링 이야기다.
발표의 문제 제기는 이랬다. AI 덕분에 과제 결과는 좋아졌지만, 그 과정에서 코드 리뷰가 사라졌다. 구현 과정에서 문제가 생길 틈이 없으니, '왜'를 물을 기회도 사라졌다.
그래서 멘토 리뷰 가이드를 현업과는 다르게 설계했다고 한다. 현업에서는 코드가 동작하고 구현 목표를 충족하면 Approve한다. 반면 교육과정의 리뷰는 학습과 성장에 방점을 둔다. 코드가 동작하더라도 질문과 피드백을 통해 한 걸음 더 배우게 한다. 구현 의도와 선택한 이유를 묻고, 테스트·가독성·실무에서 고려할 점을 제안하며, 잘한 점은 구체적으로 칭찬한다.
발표에서 소개한 멘토와 학생의 대화 중 네 장면을 표로 정리했다.
| 질문 | 장면 | 배운 것 |
|---|---|---|
| 우리는 왜 LLM에게 도구를 쥐어줄까요? | 일정과 상관없는 질문에도 답하는 챗봇 | LLM은 기억도 실시간 정보도 없다. 도구를 준비하고 LLM에겐 판단만 맡긴다 |
| 과제는 100점인데, 서비스에 이대로 도입해도 될까요? | 메모가 200개일 때 어떻게 보여 줄까 | 기술 문제가 정책으로 풀릴 때도 있다 |
| 고쳐졌는데, 왜 고쳐졌는지 모르겠어요 | Claude가 알려준 대로 바꾸니 오류가 사라짐 | 결과가 아니라 원인을 찾아가는 순서를 배운다 |
| 무엇을 코드로, 무엇을 프롬프트로 해결해야 하나요? | 프롬프트에 "절대 쓰지 마"를 넣으니 "한국어로 쓴 if문" 같았다 | 틀리면 비싼 선택은 코드와 구조로 강제한다 |
세 번째 장면에서 멘토가 보여 준 원인을 찾아간 순서는 그대로 옮겨 둘 만하다.
- LangChain 소스에서 에러 지점 확인
- 공식 문서에서 그 방식이 골라진 이유 확인
- 두 방식의 차이를 소스로 나란히 비교
- 우리 모델이 지원하는지 문서로 확인
- 확실한 것과 더 볼 것을 구분
네 번째 장면에서는 현업의 판단 기준도 함께 소개됐다. 값만 보고 정할 수 있다면 코드가 판단하고, LLM에게는 값 추출만 맡긴다. 틀렸을 때 비용이 큰 선택은 코드로 강제하고 tool 목록에서 아예 제외한다. 흐름이 정해져 있으면 workflow, 유연해야 하면 agent를 사용한다. OLIVE 팀이 "규칙은 검사 스크립트로" 만든 것과 같은 판단이다.
발표는 학생들이 스스로 묻게 된 다섯 가지 질문으로 끝났다.
- 어떻게 검증하고서, '된다'고 말할 수 있는가?
- 왜 동작하는지, 확인한 사실과 추정을 나누어 설명할 수 있는가?
- 내 기준을 깨뜨리는 입력을 일부러 넣어봤는가?
- 틀린 선택을 프롬프트로 금지했는가, 코드와 구조로 막았는가?
- 이대로 실제 서비스에 넣으면, 사용자는 무엇을 겪게 되는가?
"아는 것이 아니라, 알고 있는 것을 유연하게 활용하는 것. 알 수 없다, 그러니 묻고 답해야 한다." 내 식으로 풀어보면, AI가 답을 주는 시대에 공부의 단위는 '정답을 아는 것'에서 '모르는 것을 확인하는 순서를 갖는 것'으로 옮겨 가고 있다.
🎯 정답보다 오답: Kanana 임베딩의 하드 네거티브
「"그 사진 찾아줘" 한마디면 끝」은 글과 사진을 같은 공간에서 검색하는 Kanana 멀티모달 임베딩 모델의 개발기였다. 프론트엔드 개발자인 나에게는 다소 먼 분야였다. 따라서 기법을 깊이 설명하기보다 발표 자료의 문장과 수치를 중심으로 정리하고, 내가 가져온 관점을 덧붙이려 한다.
배경은 Contrastive Learning이다. 한 배치 안에서 쿼리(글)와 후보(사진)를 서로 비교해, 정답은 가깝게, 오답은 멀게 학습한다. 개발 과정에서 부딪힌 문제와 접근은 다음과 같다(수치는 발표 자료 기준).
| 과제 | 접근 | 발표 자료 수치 |
|---|---|---|
| 큰 배치를 메모리에 담기 어렵다 | Gradient Caching: 임베딩을 먼저 모으고 그룹별로 역전파를 누적 | 같은 GPU로 더 큰 배치 학습 |
| 멀티모달 학습 후 텍스트 성능 하락 | 학습 전후 모델을 합치는 병합 | MTEB(kor, v2) 73.61 → 69.78 → 73.05 회복 |
| 벡터 저장 비용 | MRL: 벡터를 앞에서부터 잘라도 쓸 수 있게 학습 | 용량 1/8에서 Recall@5 하락 0.4%p 이내 |
| 결과 | 같은 크기(2B) 공개 모델과 비교 | M-BEIR 평균 56.5 vs 51.8, MTEB(kor, v2) 평균 72.4 vs 70.8 |
내가 가장 오래 붙잡은 것은 그 뒤에 나온 하드 네거티브 이야기였다. 정답과 오답의 상대적 유사도를 조정해 학습하는 구조에서는 어떤 오답을 보여 주느냐에 따라 모델이 배우는 구분 기준이 달라진다. 다만 처음에는 유익해 보이던 오답도 학습이 진행되면 오히려 도움이 되지 않을 수 있었다.
그래서 HNP라는 오답 선택 정책을 따로 학습시켰다고 한다.
- 후보 묶음을 가상 학습으로 비교하고
- Recall@K 차이를 보상으로 측정해
- 그 보상으로 다음 선택 정책을 개선한다
핵심은 "오답의 난이도뿐 아니라, 학습에 대한 기여를 고려한 선택"이다. 후보의 현재 유사도를 넘어, 그 선택이 만들 학습 효과까지 고려한다. 즉, 오답도 학습 효과로 전환한다.
🔗 세 이야기를 겹쳐 보면
| 이야기 | 무엇이 사라질 위험이 있나 | 사람이 무엇으로 지키나 |
|---|---|---|
| AI로 미뤄둔 변화 실행 | 화면을 넘나드는 일관성, 도메인 맥락 | 규칙과 기준을 먼저 세우고, 최종 확정과 시스템 개선을 사람이 맡는다 |
| 주니어 멘토링 | '왜'를 묻는 과정 | 동작해도 질문하는 리뷰, 스스로 던지는 다섯 가지 질문 |
| 멀티모달 임베딩 | 의미 있는 구분 기준 | 학습 기여를 측정해 고르는 오답 |
세 세션은 서로 다른 이야기처럼 보이지만, 결국 같은 답으로 이어졌다. AI는 번역하고, 코드를 바꾸고, 정답을 찾아낸다. 하지만 무엇이 맞는지의 기준은 사람이 만든다. 그 기준이 없으면 번역은 화면마다 달라지고, 과제는 100점인데 배운 건 없고, 모델은 쉬운 오답만 보고 자란다.
🛠️ 회고
세 세션에서 들은 내용을 AI와 함께 일할 때 쓸 체크리스트로 정리했다.
- '잘했다'의 기준부터. AI에게 일을 맡기기 전에, 무엇을 맡길지와 어떤 결과가 잘한 것인지를 먼저 문서로 쓴다.
- 작게 먼저. 한 기능, 한 화면에만 먼저 적용해 보고 AI의 역할 범위를 다듬는다.
- 규칙은 프롬프트보다 코드로. 틀리면 비싼 선택은 프롬프트로 금지하지 않고 lint, 검사 스크립트, 구조로 막는다.
- 화면 하나가 아니라 흐름을 검증한다. 화면마다 맞아도 이어서 쓰면 달라질 수 있다. 사용자 흐름까지 확인해야 '된다'고 말할 수 있다.
- 사람에게 남는 맥락을 기준으로 바꾼다. 파일 간 의존관계나 도메인 정책처럼 AI가 놓치는 맥락을, AI가 읽을 수 있는 순서와 규칙, 문서로 남긴다.
AI의 테스트 결과를 확인하는 데에도 사람의 시간이 꽤 든다. 그 과정까지 AI에게 넘기려면, AI가 어디까지 실행해도 되는지 범위를 문서로 명시해야 한다. 또한 사람이 검증한 테스트 기록이 기준으로 남아 있어야 한다.