아는만큼 보인다

이 글은 Codex로 이전에 직접 작성한 글들을 읽게하고 생성한 글입니다 이전에 AI Agent로 개발하면서 느낀 점을 적은 적이 있는데요. AI에 관심이 많아 실제 개발에도 계속 사용하다 보니, 코드 작성 외에 신경 써야 하는 부분이 있었습니다.특히 Codex와 Claude Code를 번갈아 사용할 때 이 불편함이 컸습니다. 같은 저장소에서 작업하더라도 한쪽에서 나눈 대화와 결정한 내용이 다른 쪽에 그대로 전달되지는 않았습니다.Codex에서 구현하다가 Claude Code로 옮기면, 어떤 요구사항을 받았고 어디까지 진행했는지 다시 설명해야 했습니다. 반대로 Claude Code에서 정리한 내용을 Codex에 넘길 때도 마찬가지였고요. 코드는 파일로 남아 있지만, 왜 그렇게 구현했는지나 아직 확인하지 못..

vllm, mlx-vllm은 8비트 양자화 모델로컬장비: M5 Pro 16inch 64GB RAM 사용자 프롬프트: 하이 모델 서빙ollama: 답변하는데 3분넘게걸림, 메모리 55기가vllm: 답변 1~3분, 메모리 55기가 + 스왑 10기가 (최악)mlx-vlm: 답변 1분, 메모리 가장 준수 대략 55기가 사용 AI 에이전트qwencode(qwen official) -> 입력토큰 21921opencode -> 입력토큰 10285 평균속도 (mlx-vlm + opencode 조합)prefill(프롬프트 조회): 421tokens/sgeneration(프롬프트 생성): 9.25tokens/s 최적조합mlx-vlm + opencode메모리가 남는다면 MTP 모델을 별도로 추가하여 성능 업 가능

올해 들어서 Codex, Claude Code로만 개발을 하고 있는데, 여러가지 느낀점이 있어 기록합니다. 1. 단순작업, 단일작업은 직접 코드 작성하는게 더 빠르다. 병렬작업, 많은 작업을 할때만 ai가 더 빠르다2. 아직은 human in the loop이 필요하다. 사람이 병목이라곤 하지만 개입안하면 산으로 간다. 아무리 하네스를 잘 만들어둬도, AI가 판단한 것과 현실세계의 상황은 다르기 때문에 인간이 길을 정해줘야 할 때가 있다.3. 생각보다 프론트엔드 개발을 정교하게 못한다. 서버는 데이터로 검증하니 비교적 정확한데 프론트엔드는 ui 를 검증하기가 어렵다.그래서 computer use로 ai가 chrome 을 조작해서 qa 돌리도록 했더니 정확도는 향상됐는데 너무 느리다4. 구현할때마다 테스트..

이전에 홈서버 + K8s 를 구축해놨지만, 최근에 본격적으로 사이드프로젝트를 시작하면서 아직 서비스를 배포하기에는 부족함이 많다는것을 느꼈습니다.그래서 이참에 어떤것을 배포하기 위해 필요한 모든 인프라를 전부 구축해놓자고 생각했고, 도메인 구매하는것을 제외한 모든 것을 무료로 할 수 있도록 했습니다. 기술스택구성요소툴KubernetesMicroK8sIngress + TLSTraefik + Let's EncryptDNS (DDNS)DynuContainer RegistryZot (Self-Hosted)CI/CDGithub Actions (Self-Hosted Runner)Object StorageMinIO (Self-Hosted)DBPostgreSQL (Self-Hosted)Cache/QueueRedis/B..

재직중인 회사에서는 팀별로 다른 문서툴을 사용하고 있습니다.Confluence, Notion, Google Drive (Docs, Spreadsheet, ...)그래서 본인이 속해있는 조직이 아닌 문서를 확인해야될때 어디에 있는지, 어떻게 확인해야할지 잘 모르는 경우가 많습니다.기간에 따라 다른 팀이 맡으면 같은 프로젝트인데도 다른 위치에 존재하게 됩니다. (초기에는 Confluence에 작성하다가 지금은 Notion에 작성) 인수인계가 제대로 되지 않은채 남겨진 문서도 많고, 상황이 이러하다보니 가이드 문서를 작성하기도 쉽지 않습니다.실제로 문서 파편화로 인해 여러번 내부 논의가 있었지만, 별다른 개선은 이루어지지 않고 있는 상태입니다. 그래서 문서 전부 긁어다가 VectorDB에 넣고, 그걸 RAG로..

2026년이 왔습니다. 개발자가 된지 3년이 조금 지났지만, 3년동안 느낀것과 시니어 개발자분들께 커피챗을 요청하여 나눈 대화들, 링크드인을 비롯한 각종 개발 커뮤니티와 소식들을 보면 2025년부터 너무 혼란스럽다고 느껴집니다. 가장 큰 이유는 AI 라고 생각하는데요, 커피챗에서 시니어 개발자분께서 여태껏 봐온 개발 패러다임중에 가장 크다고 말씀하셨을 정도로 강력한거같습니다. 제가 봐온 여러가지 의견을 모아보자면..- AI로 개발하되 검수를 꼼꼼히 해야한다.- 스펙 주도 개발이 중심이 되어야 한다.- 스펙 주도 개발은 말이 안된다.- AI가 발전하니 개발자가 필요없다.- AI가 발전하니 프론트엔드 개발자, 백엔드 개발자와 같은 세부 직무가 제품 개발자처럼 한 사람이 다하는 직무로 변할것이다. - 위에 ..

모든 문제를 해결하기 위한 머신 러닝 방법1. 모델 클래스를 정의해라모델은 입력 x를 받아 출력 y를 예측하는 함수이다.모델 클래스는 가능한 함수들의 집합이다.즉, 프로그램을 어떻게 표현할 것인가? 2. 손실함수를 정의해라모델의 출력값이 실제 정답 y와 얼마나 다른지 측정한다.손실이 작을수록 좋은 모델이다.여러 모델 중 어느 것이 더 좋은지 평가하는 기준이 loss function 3. 최적화 알고리즘을 선택해라손실(loss)을 줄이기 위해 모델 파라미터를 어떻게 바꿀것인가 4. 큰 gpu에서 실행해라 Marr's levels of analysishttps://youtu.be/zY2QgvPfSm8?si=kdcvYbdQGg7AApFB&t=350 머신러닝은 데이터를 어떻게 생성하는지 확인한다.p(x, y)..

Part 1 머신러닝의 학습 종류에는 여러가지가 있는데 대표적인게 아래 3가지이다.1. 지도학습 (superised learning)정답이 있는 데이터로 학습시켜서 x에 대해 y를 예측학습데이터: (x, y) 처럼 x와 y(정답)이 한쌍으로 이루어져 있다.함수에 대한 세타, 즉 파라미터를 구하는데 최대한 실제 y와 가까워 지도록 자동으로 설정함2. 비지도학습 (unsupervised learning)정답이 없는 데이터로 학습시켜서 표현을 학습예를들어 generative modeling (이미지 생성 등), self-supervised representation leraning 등이 있다.최근 핫한 llm으로 이미지 생성하는것들이 이거에 속한다. 이미지를 생성하면 그 이미지는 실제 존재하는 사람, 사물이 ..

무엇이 딥러닝을 작동하게 하는가1. 많은 층을 가진 큰 모델2. 다량의 데이터셋3. 이것들을 전부 처리할 수 있는 컴퓨터 일반적으로 layer가 많을수록 모델의 성능이 좋다.layer가 많다는것은 추상화를 더 많이 한다는것이고 그렇다면 결과가 좋기 때문이다.이 결과는 ResNet의 과거 벤치마킹자료로 알 수 있는데, shallow model의 성능이 가장 안좋고 152개의 layer를 가진 model의 성능이 가장 좋다. 딥러닝에 대해 크게 두가지 관점이 있다고 한다. (21년도 강의 기준)1. 별로다. 너무 큰 모델, 큰 데이터, 큰 컴퓨팅이 필요하다2. 좋다. 우리가 데이터, layer, 컴퓨팅을 추가할수록 모델은 더더욱 좋아질 것이다. 많은 데이터와 고용량 모델을 사용한다면 feature 혹은 r..

일반적인 프로그래밍은 함수의 input과 output에 대한 규칙을 직접 정하는 것이다.이 방식은 예외가 많아질수록 굉장히 복잡해지고 많아진다. 머신러닝은 if else와 같은 조건문을 함수 수식으로 나타낼 수 있는데, 가장 간단하게는 아래처럼 나타낼 수 있다.x는 Input, θ는 학습된 파라미터, y는 output (label) 이다. 위 함수는 x와 θ를 표현할 수 있다.즉, x로부터 features 를 추출하여 함수를 만드는것이다.그러면 프로그램의 규칙을 직접 정의하는게 아니라 features를 정의할 수 있다. shallow learning model은 단지 함수 1개만으로 object label을 반환하는데,deep learning model은 학습된 파라미터를 사용하여 그냥 features가..