폭풍을 이겨낸 2023년, 항해사가 될 2024년

1. 들어가며

올해는 와탭랩스에서 로그 모니터링 서비스를 만들었다. 올해 초에는 고객사가 한 곳도 존재하지 않았던 prototype 상태였다. 연말이 된 지금, 와탭 로그 모니터링은 SaaS 환경에서는 1일 최대 23억건 (약 160만건 / 1분)의 로그를 수용하고 있으며 On-Premise 환경에서는 최대 6000대의 서버에서 발생하는 로그를 모니터링하고 있다.

 

폭풍을 이겨낸 뒤에야 내가 지나온 길이 어떤 의미였는지 조금씩 이해가 된다. 올해 초의 나는 내가 어떤 일을 하고 있는지 잘 이해하지 못했다. 그저 개발이 좋아서 개발하고 있을 뿐, 내가 하는 이 일이 세상에 어떤 의미가 있는지를 알지 못했다. 그저 IT 서비스 담당자들의 퇴근시간을 앞당겨주는 일을 하는 것인가 착각하기도 했다. B2B 비즈니스를 하는 회사에서 일을 하다보니, 모니터링이라는 일반 사용자와는 거리가 매우 멀리 떨어진 일을 하다보니, 내가 여기서 키보드를 두들기고 있는데 무슨 의미인지 와닿지 않았다.

 

이제는 확실하게 말할 수 있다. 나는 올해 '대형 커머스 고객사의 11월 이벤트'와 '대형 커피 브랜드의 프리퀀시 이벤트'가 문제없이 서비스될 수 있도록 도왔다. 회사 차원에서 주어진 이 목표를 달성했고, 몸은 너덜너덜해졌지만 내 주머니는 예상치 못했던 보물들로 가득 차있었다.

 

2023년의 회고에서는 올해의 항해가 끝난 뒤 내 주머니에 들어있던 보물들에 대해 소개해보려고 한다.

2. 폭풍을 이겨낸 뒤에 보이는 것들

2.1. 나는 무슨 일을 하는 사람일까

올해 초에는 내가 어떤 일을 하고 있는지, 세상에 어떤 의미가 있을 일을 하고 있는지를 잘 알지 못했다. 개발이 좋아서 개발을 하고 있을뿐 그 이상의 가치를 만들어내고 있다고 생각하지 못했다.  그저 IT 서비스 담당자들의 퇴근시간을 앞당겨주는 일을 하고 있다는 비관적인 생각을 하기도 하고 300만원 벌 때는 행복했는데 (걱정에 대하여) 라는 글을 쓰기도 했다. (이 글은 좀 허무맹랑하게 끝나버렸는데 나중에 '이상감옥'이라는 과점에서 다시 한 번 글을 써보려고 한다. 

 

그런데 이제는 친구가 나에게 커피를 먹고 싶은데 주문이 안 된다고 나한테 물어보기도 한다. ‘로그 검색 엔진’ 이라는 기술을 ‘로그 모니터링’이라는 서비스로 만드는 과정에서 전력을 다하고, 책임감이 생기고, ‘나 이런 일 하는 사람이구나’라고 정체성이 생기고, 이런 생각들을 친구에게 여러번 이야기하고, 그런 뒤에야 내가 무슨 일을 하고 있는지 와닿기 시작했다. 나 의미 있는 일을 하고 있구나. 그리고 아래에 적어둔 올해 내가 얻은 다른 보물들을 찬찬히 생각해보면서 내가 어떤 사람이구나 느껴지기도 했다.

2.2. 필연적이었던 로그 모니터링 개발

이제는 조금씩 보이기 시작한다. 왜 CTO 성조님께서 로그 검색 엔진을 만드셨고 왜 로그 모니터링 서비스를 만들 수 있도록 도와주셨는지 이해가 간다. 모니터링 시장에서는 “End To End Monitoring” 이 중요하다. Browser에서 사용자가 이벤트를 발생시키면 Server에서 돌아가는 Application에 트랜잭션이 도착하고 Database에서 데이터를 조회하고 문제가 발생하며 Log를 남긴다.

 

IT 서비스에서 발생하는 모든 행위를 모니터링 하기 위해서는 Metric, Trace 그리고 Log가 필요하다. Metric은 숫자 형태의 데이터이고, Trace는 Stack형태의 전용 데이터 포맷이 있다. 그리고 Log는 문자열 형태의 데이터이다. 올해 초 기준으로 Metric과 Trace는 충분히 활용할 수 있을 만큼 고도화된 상태였다. 그런데 ‘문자열 중심의 메트릭’인 로그에 대해서는, 사용자가 여러 검색 조건을 입력해서 빠르게 검색할 수 있을 만큼, 고도화되어 있지 못했다. 문자열 메트릭 또는 로그 모니터링을 제품하는 방향성은 필연적이었다. 이미 글로벌한 그리고 당연한 방향성이었다.

2.3. 로그 모니터링을 만들면서 느낀 점

로그 모니터링을 만들면서 겪었던 기술적 한계와 이를 해결한 경험을 별도의 글에서 다룰 생각이다. 양이 너무 많아서 올해 안에 작성하기는 어려울 것 같다. 글을 작성한 뒤에 “여기”에서 볼 수 있도록 링크를 추가하려고 한다. // TODO

2.4. 로그 모니터링을 만든 뒤 ‘조직’에게 달라진 점

로그 모니터링을 만든 뒤에 조직에서 달라진 점은 ‘문자열 메트릭’에 대한 빠른 검색이 가능해졌다는 점이다. 기존에도 문자열 메트릭에 대한 검색 기능이 있었지만, 로그 검색 엔진을 활용한 방법만큼 빠르고 효율적이고 범용적이지는 못했다. 로그 검색 엔진은 로그가 직접적으로 생성되는 대상인 Application, Server, Database, K8S 뿐만 아니라 Browser, Network 모니터링 제품의 개발에도 적극적으로 사용되고 있다. 이력서에서는 이것을 “End To End Monitoring 모니터링 플랫폼을 구성하는 핵심 컴포넌트로 성장했다”라고 표현해봤다.

 

기억에 남는 순간이 있다. Browser, Network 모니터링 개발의 완전 초창기에 각 제품의 PM님들께서 나에게 데이터를 저장하고 조회하는 방식에 대해서 질문을 하셨다. Browser는 Session 단위로, Network는 IP, Port 단위로 데이터가 수집된다. 그런데 Session 정보와 IP, Port 단위는 기존에 사용하던 ‘숫자 중심의 메트릭’이 아니라서 검색이 불가능하거나 속도가 너무 느린게 문제라고 하셨다. 그 때 ‘로그 검색 엔진’에서 ingest하는 포멧에 맞추어서 각 제품의 메트릭을 수집하고 검색할 수 있는 방법을 알려드렸다. “어? 그게 돼요? ..(투닥투닥).. 와~ 개발 안해도 된다~” 정말 해맑게 웃으시면서 좋아하시던 Network 모니터링 개발팀분들의 목소리가 아직도 귀에 선명하다.

2.5. 로그 모니터링을 만든 뒤 ‘나’에게 달라진 점

내가 올해 한 것은 ‘B2B SaaS Log Monitoring 개발’이라고 할 수 있는데, 각 단어 별로 느낀 점들이 상당히 많다.

2.5.1. 와탭이라는 Monitoring 서비스를 사용하는 나만의 관점이 생겼다

로그 모니터링을 만들기 위해서는 가장 먼저 로그 검색 엔진의 동작 방식을 이해해야 했다. 실시간으로 쏟아지는 높은 부하의 시계열 데이터가 어떻게 처리될 수 있는지 알아야 했다. 그리고 그 과정에서 가장 병목이 되는 자원이 무엇인지, 로그 검색 엔진에서는 어떻게 그 자원을 효율적으로 사용하고 있는지 파악할 수 있었다.

 

로그 모니터링에서 발생하는 대부분의 성능 문제는 주로 DISK IO 병목에서 발생했다. 수집되는 데이터를 저장하고 조회하는 것을 하나의 프로세스에서 처리하고 있었고, 하나의 서버 인스턴스에서 사용할 수 있는 DISK IOPS는 물리적인 한계가 있었다. 수집되는 데이터를 놓칠 수는 없기에 항상 일정 DISK IOPS는 데이터 저장에 사용되고 있고, 남아있는 DISK IOPS 안에서 데이터를 조회해야했다.

 

기본적인 저장과 조회의 기능이 궤도에 오른 뒤에는 CPU에서 병목이 생겼다. 비정형 데이터를 검색 가능한 정형 데이터로 변환하는 과정에서 파싱을 하는 과정이 필요한데, 이때 java-grok이라는 라이브러리를 사용한다. 내부적으로 정규표현식을 사용하기 때문에 태생적으로 CPU를 많이 사용한다. 수집되는 모든 로그가 비정형 로그이기 때문에 모든 로그를 정형 로그로 변경해야 검색이 원활하고 그래서 수집되는 로그의 양이 많아지면 CPU를 더 많이 사용하게 된다.

 

여담이지만 java-grok 라이브러리를 분석하고 수정 재배포하는 과정에서 해당 라이브러리의 개발자랑 linkedin을 통해서 연락이 닿았던 점이 신기한 경험이었다.

 

로그 모니터링에서 가장 중요한 병목이 DISK IOPS, CPU라는 것을 확인한 뒤에는 정기 배포 날에 어떤 지표를 먼저 확인해야하는지 알 수 있었다. 어떤 지표를 어떤 이유에서 봐야하는지에 대한 느낌을 파악한 뒤에는 이것저것 주워들으면서 나만의 확인 리스트를 만들었다. 요즘에는 이슈가 발생하면 Log (가장 직접적인 원인을 찾기 위한 근거 확인) , Cpu/Mem/Disk/Network(시스템 전체에 대한 영향도 파악), HitMap(문제 발생 시점에 에러가 얼마나 많이 발생했는지에 대한 개형), Trace(문제가 되는 트랜잭션의 상세 정보)를 먼저 확인한다. 그리고 문제의 원인은 집 밖에 있었다 라는 글에 나온것처럼 디테일한 경험들도 차분히 누적되고 있다. 

 

올해 8월정도에 와탭 로그 모니터링에 Distributed File System (DFS)이 도입되었다. 물론 나는 DFS 핵심 로직의 개발에는 참여하지 못했고 CTO 성조님의 도움을 받아 이해하고 활용만 하고 있다. DFS 핵심 로직에서 Network를 다루는 부분은 수정하지 못한다. 데이터 끊겨서 유실될까봐 무섭다.

 

DFS의 로직을 직접 작성하지는 못했지만, DFS의 도입 과정에서 Scale Out과 Scale Up이 각각 얼마나 큰 성능 향상을 가져오고 어떤 방법이 더 효과적인 방법인지 판단하는 과정을 거쳤다. 그리고 이 과정에서 Scale Out/Up된 서버들을 운영하고 배포하는 관점에서는 어떤 것들을 챙겨야하는지도 몸소 느껴볼 수 있었다. 당연하지만 DFS의 도입 과정에서 성능 개선이 정말 크게 되었는데, 6단계에 걸쳐서 성능 테스트를 진행하고 리포팅했던 것도 나중에 “여기”에 글을 써서 공유해보려고 한다. // TODO

2.5.2. 개발 자신감이 많이 생겼다

엄청나게 복잡하고 어려웠던 ‘로그 검색 엔진’의 로직을 이제는 이해하고 동료에게 설명할 수 있게 되면서 자신감이 생겼다. Spring Framework가 제공하는 기능들은 이제는 어떤 식으로 검색해야지 잘 도움을 받을 수 있는지 느낌을 찾았고, Java로 File을 다루는 코드에 대해서는 “시간만 쓰면 다 이해할 수 있다”라는 생각까지 하기도 한다. 이제는 질문할 때 어떤 역할을 하는 코드인지 모르겠다 질문하지는 않는다. 데이터가 어떤 형태로 저장되어 있는지 또는 이 기능의 밑에 깔려있는 전제조건은 무엇인지 등을 질문하게 된다. 물론 위에서 언급한 DFS처럼 직접 수정하지 못하는 모듈도 많다.

 

이렇게 자신감을 갖게된 몇 가지 순간이 있다. 로그 데이터는 파싱 과정을 거치면서 비정형 데이터에서 정형 데이터로 변형된다. 그리고 이렇게 정형화된 데이터는 로그 검색에서 활용되기 위해서 별도의 파일로 저장된다. 그런데 이 별도의 파일에 데이터를 쓰고 읽는 과정에서 숨겨져있던 버그를 내가 발견하고 머리를 싸맨 끝에 해결을 했다. CTO 성조님께서 “어? 이제 좀 이해했나보네? 허허” 라고 말씀해주셨을 때 참 기분이 좋았던 기억이 있다.

 

또 한 번은 로그 검색 기능이 정상적으로 동작하지 않았다. 검색 과정에서 놓치는 데이터가 있었다. 로그 검색 엔진의 동작 과정이 머리 속에 촤라락 그려짐에도 불구하고 왜 검색이 안되는지 도저히 알 수가 없었다. 로그 검색 엔진에서 검색이 제대로 동작하지 않으면 검색 엔진이라고 할 수 없지 않은가.. PM님께 최대 2~3일만 써서 찾아보겠다고 말씀드리고 기적적으로 딱 3일차 저녁에 원인을 찾았다.

 

원인은 검색 과정에서 수행하는 이분 탐색 과정에서 누락이 발생한 것이었고 더 근본적인 원인은 데이터의 정렬이 보장되지 않아서 발생한 문제였다. 이는 수백-수천대의 서버에서 발생하고 수집되는 로그의 시간이 정렬되지 않은 상태로 와탭의 서버에 ingest 되기 때문이었다. 고객사 환경의 서버 시간을 ms 단위까지 맞추어도 네트워크 구간의 이슈로 정렬이 안되는 경우가 있었고, AWS LOG처럼 태생적으로 배치 형태로 생성되고 ingest되는 데이터도 있었다. 멀티 환경에서의 수집되는 시계열 데이터의 정렬을 100% 보장하기는 어려웠고, 이 문제를 우아하게 풀고 Google에 갈 수(도) 있는 길을 걷기보다는 실리적으로 빠르게 문제에 대응할 수 있는 방법을 찾았다. (로그 타임스탬프 기준 변경)

 

Spring Framework, 사내 라이브러리, 로그 검색 엔진에 대해서 깊이 파보고 문제를 해결해보면서 “안되는게 어디있어? (야근)하면 다 되지!” 라는 자신감이 생겼다. 어떻게보면 이것이 올해 얻은 가장 큰 열매이지 않을까.

2.5.3. 데이터를 바라보는 나만의 관점이 생겼다

제품을 개발하면서 가장 어려운 것은 데이터를 이해하는 일이다. 이 데이터가 어떤 정보를 가지고 있고 어떤 특징을 가졌는지 이해해야한다. 이것보다 더 어려운 것은 이 데이터를 사용자가 왜 필요한지 아는 것이다. 사실은 사용자도 이 데이터가 왜 필요한지 모른다. 그래서 결국은 데이터 자체의 특징을 잘 이해하고 이렇게 저렇게 바라보면서 데이터 속에 숨어져있는 인사이트를 찾고 이 아이디어를 서비스로 녹여내는 것이다. 어렵게 이 과정이 진행되어 서비스가 반영되어도 고객은 서비스가 어려우면 잘 안쓴다. 아니 잘 못쓴다.

 

그래서 동료들에게 더 공유해야한다. 프론트 개발자, 디자이너, 테크니컬 라이터분들에게 데이터에 대한 설명을 더 자세하게 설명을 해드렸어야 했다. 그렇지 못하다보니 백엔드 개발자인 내가 데이터를 너무 0과 1의 세계에서 딱딱하게 바라보는 관점이 서비스에 그대로 드러나고 사용자 친화적이지 못한 기능들이 개발되었다.

 

내년에는 APM 통계 페이지의 개편이 이루어지는 것이 검토되고 있다는 이야기를 들었다. 프론트 개발자라서 서버에 수집되는 데이터가 어떤 의미를 가진 데이터인지, 어떤 형태로 저장되는지 잘 알지 못해도 되는게 아니다. 백엔드 개발자처럼 잘 이해할 필요는 없지만, 그 데이터의 특징과 저장/조회 구조의 한계를 파악하고 이를 좀 더 유연한 관점으로 풀어내고 결국 사용자에게 더 사용하기 쉬운 서비스를 제공해야 한다.

 

백엔드 개발자가 쉽게 잘 요약해서 다른 직군의 사람들에게 설명을 제공할 수 없다. 한 번 설명을 할 수는 있겠지만 너무너무 부족하다. 적어도 와탭이라는 모니터링 도메인을 만드는 이 회사에서는. 다 같이 데이터에 대한 이해가 된 상태가 되어야 다같이 고민하고 기획에 참여할 수 있다. 그래야 더 나은 제품을 개발하고 더 즐겁게 의미있게 일할 수 있다. 이게 여기 회사에서 개발자들이 하는 일이다.

 

로그 모니터링의 내년 개선 방향을 프론트 개발자 수연님과 같이 이야기했었다. 이번에는 내가 가지고 있는 아이디어를 일부러 설명드리지 않았다. 대신 내년에 로그 모니터링을 어떤 모습으로 발전시킬 수 있을지 각자 고민해오고 비교해보기로 했다. 지금까지는 내가 너무 디테일한 부분까지 아이디어를 제공해서 오히려 프론트 개발자의 상상력을 제한했다는 생각이 들었기 때문이다. 뜬금없지만 이렇게 같이 마음 맞춰 일할 수 있는 수연님이 계셔서 참 다행이고 감사하다.

2.5.4. B2B SaaS 서비스를 만드는 흐름을 좀 알 것 같다

로그 모니터링의 고도화를 위해 요구사항 수집, 기술 검토, 개발, 성능 최적화, 방향성 제안, 사내외 제품 소개 등을 약 2년째 담당하고 있다. 사내외의 다양한 직군의 사람들과 많이 이야기하며 B2B SaaS 생태계에 대해서 많이 배웠다.

 

제일 중요한 점이라면 우아하고 복잡한 접근법보다, 간단하고 빠르게 제공한 뒤에 빠른 피드백을 얻는 것이 중요하다. 왜냐하면 어떤 기능이 시장에 필요한지 모르기 때문이다. 위에서 말한 것처럼 ‘사실은 사용자도 이 데이터가 왜 필요한지 모른다.’ 그래서 짧은 스트린트를 여러번 돌 각오를 해야한다.

 

회식자리에서 가끔식 영업하시는 분들의 이야기를 듣다보면 이 바닥?이 어떻게 돌아가는지 알 것 같기도 하다.

2.5.5. 서비스 전체에 대한 고민을 해야 더 좋은 결과물이 나온다.

내가 담당하는 기능만 잘하기 위해서가 아니라, 서비스 전체를 위한 고민을 해야 더 좋은 결과물이 나온다. 서비스 전체를 위한 고민을 하기 위해서는 큰 덩어리 개념들을 하나가 아니라 여러가지를 알고 있어야 한다. 동료들과 다른 팀이 하고 있는 일에도 관심을 가지고 적극적으로 도와주다보면 이 덩어리 개념들이 모여서 더 커지는 경험을 하게 된다.

 

2022년에는 알림만 알고 있었다. 2023년에는 로그도 알게 되었다. 로그 데이터(문자열 메트릭)를 알게 되면서 이미 알고 있었던 숫자 메트릭에 대한 알림(메트릭스 알림) 뿐만 아니라 문자열 메트릭에 대한 알림(로그 실시간 알림)에 대해서도 고민할 수 있게 되었다.

 

본 회고에서 큰 주제로 다루지는 않겠지만, 올해 말에 AWS Marketplace 연동을 진행하고 있다. 이 과정에서 잘 모르고 있었던 계정/프로젝트/미터링 정보의 생성 및 처리 로직에 대해서 깊게 파악할 수 있었다. 한 명의 사용자가 서비스를 원활하게 사용하기 위해서 어떤 정보들을 어떻게 관리해야하는지 폭넓은 시야를 가질 수 있었다. 기존에는 FileDB에 저장된 시계열 데이터를 어떻게 다루어야하는지만 알고 있었다면, 이제는 RDB에 저장된 계정/프로젝트/권한/라이센스/미터링 정보를 활용해서 어떻게 시계열 데이터를 활용해야하는지의 큰 그림을 그릴 수 있게 되었다.

 

예를 들어 OpenTelemetry를 사용해서 새로운 종류의 메트릭을 수립하려고 할 때, 신규 제품으로 등록할 것인지, 기존 제품에 추가적인 메트릭으로 추가할 것인지에 따라서 어떤 부가 작업이 수반되어야 하는지 미리 예측할 수 있었다. 만약 신규 제품으로 등록하려면, 잠깐만 생각해봐도, 아래와 같은 개발 작업이 추가적으로 필요하다

1. 프로젝트를 만들 때 계정이 가지고 있는 라이센스 정보를 확인해서 프로젝트를 만들 수 있는지 확인해야 한다.
2. 신규 제품의 과금 기준과 가격을 결정하고, 이 결정에 따라서 미터링 정보가 생성되고 반영될 수 있도록 수정해야 한다. 이 과정에서 타사 제품의 가격을 확인해서 가격 경쟁력 여부를 고려해야한다.
3. AWS Marketplace를 통해서도 과금이 되어야하는 제품이라면 1달 단위로 과금하는 기존 방식에서 1시간 단위로 과금이 되도록 AWS Marektplace 전용 미터링 정보의 변환 공식을 적용하고 API에 반영하고 대사 작업을 진행해야 한다.

2.5.6. 잘 갖추어진 야생

내가 올해 이렇게 많은 성장을 할 수 있었던 것은 나에게 ‘잘 갖추어진 야생’이라는 환경이 주어진 덕분이라고 생각한다. 내가 한 마리의 사자라면 들판에는 토끼들이 참 많이 있었다. 토끼를 잡아야한다는 목적이 주어지기도 했고, 목적이 없이 가만히 있다가 배고파서 잡으려 발버둥치기도 했다. 감사하게도 내 주변에는 경험이 많은 다른 사자들이 많았다. 내가 토끼를 잡을 때까지 묵묵하게 기다려주시고, 어떻게 잡아야하는지 모를 때 방법을 알려주셨다. 때로는 새로나온 토끼라면서 잡아주시기도 하셨고 가끔은 직접 만드신? 토끼라면서 구경시켜주시기도 했다.

 

올해 정말 많은 분들의 도움을 받았다. 내가 찾아가서 이름을 부르면 약간 경계의 눈빛으로 바라보시면서도 적극적으로 도움을 주신 모든 분들께 감사하다는 말씀을 전하고 싶다. 특히 CTO 성조님, 백엔드 리더 은하님과 병우님 그리고 데브옵스 리더 재진님께 온 마음을 담아 감사하다고 말씀드리고 싶다. 무엇을 더 봐야하는지 어떤 질문을 해야하는지도 모를만큼 꽉 막혀있을 때, 많은 도움을 주신 덕분에 제품도 나도 많이 성장할 수 있었다고 생각한다. 

3. 항해사가 될 2024년

올해에는 솔직히 너무 많은 생각의 폭풍들이 머리 속을 훑고 지나갔다.

 

B2C는 B2B보다 재밌지 않을까? B2C로 1인 개발자로서의 커리어를 쌓아가면 어떤 인생일까? 내가 정말 잘 하고 있을까? 너무 좁은 분야에서 일을 하고 있는건 아닐까? 난 그저 IT 담당자들의 퇴근 시간을 앞당기는 일을하고 있을뿐인가? 내가 하고 있는 일의 중요성을 남들에게 잘 어필하려면 어떻게 해야할까? 남들의 눈치를 보는 성격은 아닌데 왜 난 이런 걱정을 하고 있을까? 너무 부족하고 배우고 싶은 분야가 너무 많은데 어떤 것부터 해야할까? 저 사람은 어떻게 저렇게 멋진 일을 하고 있을까?

 

스스로를 불행하게 만드는 3가지 심리가 있다고 한다. 시선감옥, 쾌락감옥, 이상감옥. 올해의 나는 세 가지 중에서는 이상감옥에 갇힌 사람이었다. 더 잘하고 싶어서, 더 멋진 사람이 되기 위해서, 더 중요한 사람이 되기 위해서, 더 많은 인정을 받기 위해서 노력했다.

 

최근까지도 이상감옥의 끝을 달린 적이 있는데, 책 ‘AI 전쟁’을 써주신 네이버의 AI 수장 하정우님께 콜드 메시지를 보낸적이 있었다. 정말 감사하게도 어떤 방향으로 고민해봐야하는지 말씀해주셨고, 신기하게도 전문 용어를 좀 사용해서 검색하니 훨씬 더 양질의 정보를 얻을 수 있었다.

 

투박한 질문에 핵심적인 답변을 해주셔서 정말 큰 도움이 되었습니다. 다시 한 번 감사드립니다.

 

시계열 데이터를 대상으로 LLM을 어떻게 활용할지는 좀 더 정리되면 “여기”에 링크로 달아보려고 한다.   아래의 글에서 생각을 정리해봤다.

2024.01.02 - [개발/Monitoring Insight] - 모니터링 데이터에는 LLM를 어떻게 붙여야할까?

 

 

중요한 점은 네이버 AI 수장님과의 대화가 아쉽게 짧게 끝난 뒤에 아득함이 느껴졌다는 것이다. 책을 읽고 정말 대단한 분이라는 생각이 들었는데 나도 그런 사람이 되고 싶어졌다. 그런데 그 길이 너무 멀고 아득하게 느껴졌다. 이상과 현실 사이에서 오는 괴리감의 감옥에 빠져버린 것이다.

 

2024년에는 하고 싶은 것들이 정말 많다. 그리고 이 생각들을 모두 실현시킬 수 있다는 자신감도 있다. 다만 이 과정에서 이상감독이 나를 찾아와서 방해를 하지 않도록 주의해야 한다. 2024년에는 이상감옥의 아득함에 압도되지 않고 나만의 페이스에 맞추어 열정 속을 차분하게 항해해야겠다. 출발선에서는 CKA, ElasticSearch, Lucene, DataPlatform, X2Metric이라는 부표들이 그리 멀지 않은 곳에 보인다.