Search
Duplicate

if(kakaoAI)2024 컨퍼런스 후기

contents

 if(kakaoAI)2024

if(kakaoAI)2024 DAY2 컨퍼런스에 다녀왔습니다.
일단, 판교와 컨퍼런스 장까지의 거리가 있어서 카카오에서 제공해주는 셔틀 버스를 타야지 쉽게 이동이 가능했습니다. 들락날락 하기가 쉽지 않은 탓에 사람들이 끝까지 남아 있지 않고 얼른 가버린 거 같기도…
셔틀버스에서 받은 굿즈들
세션장은 산 좋고, 물 좋은 곳에 위치했습니다. 여기서 코딩하면 머리는 맑아지겠다 싶은 곳이었습니다.
오전 세션은 카카오가 만든 AI Kanana에 대한 설명이었고, 흥미롭게 들었던 거 같습니다.
제일 흥미로웠던 건 Codebuddy라는 AI CodeReview봇이었는데, 카카오 내에서만 쓰는 거 같더라구요.
항상 Pull Request 작성에 많은 시간을 들이는터라, 제 코드를 읽어서 자동으로 PR를 생성해주고 리뷰를 해주는 Codebuddy는 꽤나 탐났습니다. 언젠가 모두가 사용할 수 있었으면 좋겠네요…
오전 세션 이후에는 카카오에서 제공해주는 점심 도시락을 먹었습니다. 꽤나 차가웠던 기억..
도시락 흡입 후엔 AI 캠퍼스를 돌아다니면서 체험 부스를 즐겼습니다. 여러 전시 부스에 들려서 구경도 하고 질문도 했습니다.
오후 1시부터는 본격적으로 세션이 진행되었는데요. 컨퍼런스 가기 전에 들어야지 했던 모바일 세션들 위주로 들었던 거 같습니다. 시간이 겹쳐서 못 들었던 세션들도 있지만, 다시보기를 하면 되기에..

 Day2 Session

컨퍼런스 가기 전, 호기롭게 듣고 싶은 세션을 정리해서 갔지만 마음처럼 다 듣진 못했습니다.
위의 세션들을 순서대로 듣고 왔는데요, 기억에 남았던 몇가지 세션을 소개해보고자 합니다.

 TDD로 앞서가는 프론트엔드: 디자인, API 없이도 개발을 시작하는 방법

＞ 간략한 세션 설명

•
프론트엔드 개발은 대부분의 협업자의 작업이 끝난 후에 개발 가능하기 때문에, 이 부분을 개선하기 위해서 API나 디자인이 없는 상태에서 개발을 시작하기 위해 테스트 주도 개발(TDD) 방식을 적용할 수 있음.
•
디자인이 준비되지 않은 경우, 컴포넌트 테스트를 통해서 실질적인 디자인이나 마크업 없이도 개발 가능.
•
API가 준비되지 않은 경우, Mock 데이터를 활용한 테스트 가능.
•
이때, API Layer와 ViewModel Layer를 분리함으로써 뷰와 API의 종속성을 줄일 수 있음.
•
실무에서는 다소 진입 장벽이 있지만, 프로젝트 일정과 초기 작업에 큰 도움을 줄 수 있음.
•
FE 리소스가 다른 협업 부서에 비해 여유 있는 상황인 팀에서 사용하기 좋음.

＞ 세션 참여 후 느낀점

해당 세션은 프론트엔드(FE) 세션이었는데요. TDD 개발 방법론에 대한 이야기라, 프론트엔드 지식이 크게 없어도 듣기에 어려움이 없을 것 같아 듣게 되었습니다.
근 2-3년 간 TDD에 대한 개발자들의 관심이 높아지면서 저도 어깨너머로 많이 들었던 방법론이었습니다.
회사에 들어간 후에 단위 테스트를 많이 작성하게 되면서 TDD에 대한 저의 관심도 많이 늘어났지만, TDD와 나 사이의 허들을 넘지 못해서 지켜보기만 했습니다. 또한, 혼자 하는 것이 아닌 팀 단위로 함께 TDD를 적용해야 할 거 같아서 해 볼 엄두가 나지 않았습니다.
그럼 해당 세션을 듣고 나서는 생각이 좀 달라진 거 같냐고 물어본다면 “약간” 이라고 답할 수 있을 거 같습니다.
사실 지금까지 조금은 TDD스럽게 개발을 하고 있진 않았나 싶기도 합니다. 물론, TDD에 대한 깊은 공부가 선행되지 않았기에 모르는 자의 거만함일 수도 있지만.
세션에서 프론트엔드 개발이 개발의 병목 요소라고 말씀하시면서, 이 병목을 없애기 위한 방법으로 두 가지를 소개합니다. 첫번째는 디자인 없이 개발하기, 두번째는 API 없이 개발하기 입니다.
두 가지 방법 중 API 없이 개발하는 일은 가끔 발생합니다.
완전히 새로운 피처에 참여하게 되면 백엔드 개발을 기다려야 하는 상황이 발생할 때가 있습니다. 그럴 때마다 사용했던 방법이 바로 Mock를 사용해서 가짜 서버 Response 데이터를 만드는 일이었습니다.
실제로 세션에서 API Mocking 방식에 대한 말씀을 하셔서 실제로 적용해봤다는 생각에 조금 뿌듯했습니다.
디자인 없이 개발하는 경우는 크게 없기에 Mock 디자인 컴포넌트를 만드는 일이 있을까 싶긴 하지만, 한편으로는 Mock 디자인 컴포넌트를 만드는 게 좋은 방법일까 하는 생각도 듭니다. 모바일 개발자의 관점에서 컴포넌트를 만들고 제거하는 추가적인 비용만 더 들지 않을까 라는 생각이 들었습니다.
모든 내용 중에서 실무에서 어떤 방식으로 사용했는지, 어려움이 없었는지에 대한 부분이 가장 관심이 갔습니다.
스피커분께서도 현실에서 장벽이 많다라고 언급해주셨고, 개발뿐만 아니라 기획, 디자인, 서버 등 협업하는 팀에 TDD 도입이 얼마나 이득인지에 대한 증명을 하셔야 했다고 합니다.
그런 부분들을 생각하면 회사에서 TDD를 도입해서 진행하는데는 한계가 있지 않을까 싶기도 합니다.
마지막에 세션을 정리하면서 [이런 팀이라면 도입을 고민해보세요] 라는 화면을 보여주셨는데요.
“FE 리소스가 다른 협업 부서에 비해 여유 있는 상황인 팀” 이라는 문장을 보고 TDD 적용에서 대한 우선순위를 살짝쿵 낮췄습니다. 언젠가 여유가 된다면 TDD를 적용해보고 싶다는 생각이 들었던 세션이었습니다.

 네이티브 차트 개발 여정

＞ 간략한 세션 설명

•
기존 차트 라이브러리는 고도의 커스터마이징 요구와 성능/메모리 이슈를 해결하기 어려워, Core Graphics와 Quartz를 활용하여 직접 가볍고 효율적인 차트를 개발하게 됨.
•
Clipping Path와 CGContext의 상태 관리(save/restore)를 활용해 차트 내에서 범위별 색상을 적용하여 중복 및 겹침 문제를 최소화.
•
CGBlendMode의 Porter-Duff 합성 연산자를 사용해 색상 레이어 겹침 문제 해결.
•
ViewPort 방식을 도입해 화면에 보이는 데이터만 렌더링하도록 최적화.
•
기존 25,920개의 데이터를 모두 렌더링하던 것을 26~384개로 줄이며 성능 및 메모리 사용량을 개선.

＞ 세션 참여 후 느낀점

최근에 웹뷰를 사용한 차트를 개발하게 되면서 네이티브 차트에 대한 니즈가 있었기에 해당 세션을 들으러 컨퍼런스에 갔다해도 과언은 아닙니다.
다양한 차트 관련 내용을 소개해주셨지만, 그중에서도 ViewPort라는 개념을 사용해서 차트를 구현하는 방법이 가장 신기했습니다. 생각해보지 못했던 관점이었기도 했구요.
많은 데이터를 차트로 그릴 때, 안보이는 영역까지 그리게 되면서 메모리를 많이 차지하게 되는데 그러한 문제를 해결하기 위한 방법으로 강연자님은 ViewPort를 사용하셨습니다.
ViewPort는 스크롤 영역 중에서 사용자에게 보이는 영역에 대해서만 데이터를 그려주기 때문에 메모리 부담이 사라지고 성능이 개선되는 이점이 있는 방식이었습니다.
현재 저희 앱에서는 차트 위에 수 많은 데이터가 올라갑니다.
Socket를 사용하기 때문에 빠른 속도로 서버로부터 데이터를 받는 형식입니다. 그렇기 때문에 1분 안에 엄청난 양의 데이터가 쌓일 수 있는 구조입니다.
그렇기 때문에 차트 화면이 있는 Screen 진입 시에 메모리와 CPU가 빠르게 치솟게 됩니다. 발열도 쉽게 일어나고 해당 화면에 오래 머무를 수록 메모리 이슈로 앱이 강제 종료될 수 있는 가능성이 존재합니다.
ViewPort를 도입해서 차트를 구현하게 된다면, 어쩌면 위에서 말한 문제들이 해결되지 않을까 하는 생각이 들었습니다.
하지만, 한 가지 의문이 드는 부분도 있습니다.
강연자님이 만드신 앱에서는 차트 자체 줌 인이나 줌 아웃 안되는 것으로 보였는데, 해당 기능을 사용할 수 있는 차트라면 ViewPort 방식을 도입할 수 있는가?
현재 제가 필요한 차트는 줌인, 줌아웃 기능이 필요하기 때문에 과연 ViewPort를 적용한다면 줌인, 줌아웃이 제대로 작동할 것인가가 궁금합니다. ViewPort가 보이는 영역에 대한 데이터를 그려주는 방식이기에 데이터는 제대로 그려야 내겠지만, 영역의 크기가 줄어들었다 늘었다 했을 때 그냥 데이터를 그려내는 것보다 어떠한 이점이 있을 지 궁금하긴 합니다. 실제로 구현을 해봐야 겠지만요.
위의 문제만 아니라면 충분히 이점이 있지 않을까 하는 생각입니다.
차트 화면 하나에 여러 개의 차트가 올라갈 수 있기 때문에 하나의 차트에 드는 데이터 부담만 줄인다면 여러 개의 차트가 올라갔을 때는 그 이점이 빛을 발하지 않을까 싶습니다.

 마치며…

이번 컨퍼런스는 저에게 많은 인사이트를 주는 경험이었습니다. 현재 가지고 있던 다양한 문제에 대한 새로운 시각을 제시하는 시간이기도 했습니다. 20-40분 사이의 세션이었지만, 그 속에서 강연자 분들의 많은 고민과 생각들을 엿볼 수 있었습니다.
실제로 컨퍼런스에서 발표한 방식들이 제가 처한 상황을 타파하는데 도움이 될진 모르겠지만, 좁혀진 저의 시각을 조금이나마 넓혀주었다는 점에서 의미가 있었습니다.
또한, AI가 성장함에 따라 개발자에게 얼마나 더 효율적인 개발 환경을 제공할 지도 기대하게 되었습니다.
모바일 세션에 앞서 진행된 AI 세션에서 나온 코드 리뷰 도우미 CodeBuddy나 KakaoAI Kanana를 보면서, 앞으로 펼쳐질 세상에선 AI가 필수적인 존재가 되겠구나 싶었습니다.
이전에 성장에 관련된 아티클을 여러 번 본 적이 있습니다.
아티클들은 하나같이 정체하지 않고 진전하는 개발자가 되기 위해서는 [다양한 사람들과의 교류]가 필요하다고 말합니다. 현재 자신의 생각이 갇혀 있지 않고, 다양한 사람들과 교류하면서 새로운 의견을 듣고 또 나누라는 뜻이겠죠.
이번 컨퍼런스가 저에겐 교류의 시간이었습니다. 덕분에 2024년을 마무리하기 전에 어떤 지식들을 추가적으로 공부하면 좋을 지 생각해볼 수 있었구요. 아무쪼록 많은 도움이 되는 컨퍼런스였습니다.