검색, 재정렬, 생성을 분리해서 측정한 팀 연구 기록입니다. AI가 답을 못 만드는 것이 아니라, 원하는 기사를 제대로 찾지 못하는 것이 진짜 문제였습니다. 이번 연구는 그 원인이 어디에 있는지를 하나씩 분리해 확인한 과정입니다.

INSK v4 - 운영 가능한 AI 뉴스 추천 시스템으로 다시 설계하기 > INSK 시리즈의 마지막 글. > 프로젝트를 다시 만들며 바뀐 것은 판단 기준이었다. 프로젝트 소개 INSK는 AI를 활용해 뉴스를 수집, 분석하고, 부서별 관심사에 맞는 뉴스를 추천하는

2026년 5월, AI 기술을 보러 두 곳을 방문했다.그런데 가장 오래 기억에 남은 건 AI 모델이 아니라, 그 AI를 운영하는 시스템이었다.

이번 글은 Clmakase을 함께 만든 팀 이야기다.

스케일아웃하면 나아질 줄 알았다 - 15만 VU 부하 테스트에서 깨진 3가지 직관에서 브로커 장애에 대비한 두 버전의 결과만 비교했다. 이번에는 그 결과에 이르기까지 어떤 기준으로 구조를 선택했는지를 정리해 보려고 한다.

'모든 신호는 정상처럼 보였지만, 실제 서비스는 의도대로 동작하지 않았다.'

스케일아웃하면 성능이 올라갈 줄 알았다. Karpenter만 설치하면 먼저 실행할 노드 없이도 알아서 생성될 줄 알았다. Pod가 죽으면 애플리케이션 문제일 줄 알았다.

병렬프로그래밍에서 멀티스레드를 다루던 도중 레이스 컨디션 상황에 대한 언급이 나왔다.마침 냉장GOAT에서 레이스 컨디션을 메인으로 다루었고, ParkingMate에서도 이중 예약 방지를 위해 동일한 문제를 다룬 적이 있어 이번 기회에 자세히 정리하고자 한다.

인프라 이해에 대한 필요성을 느껴 네트워크, 도커, 쿠버네티스, 클라우드 등을 학습하고 대규모 트래픽 실무형 프로젝트를 진행하며 팀워크와 엔지니어적 사고를 느낄 수 있었던 CloudWave 수료 후기.

프로젝트 개발 중 Claude 계정 3개를 돌려쓰다가, 토큰이 아니라 내 사용 방법에 문제가 있지 않을까 의문을 가지게 되었고, 갖가지 방법들을 시도하여 성공적으로 Claude를 다루게 된 과정에 대한 기록.

이 문서는 INSK를 운영 환경에 올리면서 실제로 겪은 문제들을 정리한 기록이다. 해결 방법을 정리하기보다는, 왜 이런 문제가 발생했는지,그리고 이 문제가 어떤 설계 전제 위에서 발생했는지를 남기는 것이 목적이다.

개발자 기준으로 세운 판단들이 운영 환경에서 어떻게 흔들리는지를 확인하기 위한 중간 정리

“돌아간다”는 사실이, 더 이상 충분하지 않다고 느꼈을 때

INSK 개발편 1 프로토타입을 버리고, 처음으로 ‘서비스’를 만들겠다고 결정한 순간

Redis vs Memcached — 캐시를 도입하면서 고민했던 기록 INSK와 냉장Goat를 만들면서 처음으로 “캐시”를 진지하게 고민하게 됐다. 데이터가 많아지고 기능이 늘어나면서, DB만으로는 점점 부담이 커졌기 때문이다. 그래서 자연스럽게 이런 질문이 생겼다

데이터 분석과 머신러닝을 학습할 수 있는 SK AI Dream Camp를 수료하고, 이에 대한 호기심에 전공심화 과목인 심층학습을 수강하였다. 두 과정을 연달아 학습하며, 느낀 점을 작성하고자 한다.

미래역량 프로그램 SK mySUNI 써니C 4기 'AI Tool'을 활용한 '직무 X AI프로젝트'

기술의 성지를 넘어, 엔지니어들의 생각과 철학까지.

"첫 해커톤에서 배운 것은 기술이 아닌 협업과 문제해결의 진정한 의미였다"

복잡도(complexity)\-시간(Time complexity) : 계산량\-공간(Space complexity) : 메모리 계산량이 적은 복잡도가 낮은 효율성이 높은 알고리즘을 짜야 함. 점근적 복잡도 : (데이