For Engineering

어느 폴더가 용량을 먹는지 찾기du -sh * # 현재 폴더 항목별 용량du -sh * | sort -h # 작은 것부터 정렬 예시 출력:$ du -sh * | sort -h4.0K README.md1.2M logs340M node_modules2.1G data -s는 합계만,-h는 사람이 읽는 단위. df로 "디스크가 찼다"를 알고, du로 "어디가 범인인지"를 찾는다.'| sort -h'를 붙이면 용량 큰 게 아래로 와서 바로 눈에 띈다.

디스크 얼마나 찼는지 파티션별로 확인df -h -h로 사람이 읽기 쉬운 단위로 본다. 루트(/)와 마운트 지점별 Use%가 100%에 가까운지 확인한다. 어디가 찼는지 알았으면, 그 경로 안에서 범인을 찾을 땐 du를 쓴다.

메모리 얼마나 쓰고 있나 한 줄로 확인free -h -h는 사람이 읽기 쉬운 단위(Gi/Mi)로 보여준다. 실제 남은 메모리는 free 열이 아니라 available 열을 본다. 캐시(buff/cache)는 필요하면 회수되므로 available이 진짜 여유다.

부제: LLM이 읽기 전에 쓰지 못하게 막기캘린더를 다루는 에이전트에서 가끔 사고가 났다. 모델이 기존 일정을 읽지 않고 바로 일정을 만들거나 고쳤다. 그러면 두 가지 문제가 생긴다.이미 있는 약속과 겹치는 시간에 새 일정을 덮어쓴다.수정·삭제할 때 event_id를 실제로 모르니 그럴듯한 값을 지어낸다(환각).문제프롬프트와 도구 설명(docstring)에 "먼저 조회하라"고 적어도 회귀가 반복됐다. 지시는 권고일 뿐이라, 모델이 안 지키면 그만이다.여기서 Claude Code의 패턴이 떠올랐다. Claude Code는 파일을 Write하기 전에 그 파일을 Read하지 않았으면 시스템이 거부한다. 지시가 아니라 도구 레이어에서 강제하는 방식이다. 이걸 우리 도구 레이어에 옮겨오기로 했다.정리한 방식 — ..

부제: 시스템 프롬프트가 안 먹힐 때 — 생성 지점에 한 번 더먼저 이건 자주 쓰는 기술이 아니라 치트키에 가깝다. 시스템 프롬프트로 안 되는 게 확인됐을 때, 마지막에 꺼내는 카드다. 남발하면 부작용이 있어서, 왜 통하는지와 언제 쓰면 안 되는지를 같이 적는다.증상대화가 길어지면 봇의 말투가 흐트러졌다. 응답 옆에 괄호로 부연을 달거나((이건 좀 우려돼요)), 무대지시처럼 상황을 설명하거나, 시스템 내레이션조로 사용자를 진단하듯 말했다. 원래 페르소나에서 벗어난, 이른바 OOC(out-of-character)다.시스템 프롬프트 맨 위에 말투 규칙을 분명히 적어 뒀는데도 그랬다.왜 생기나대화가 길어질수록, 생성 지점에서 시스템 프롬프트까지의 거리가 멀어진다.1턴째: 시스템 프롬프트 → 사용자 메시지 (가..

부제: command를 덮어썼더니 ${VAR}가 그대로 남았다nginx 설정을 템플릿으로 두고, 환경변수를 채워 렌더하는 방식을 쓰고 있었다. TLS 인증서 경로에 도메인을 변수로 넣어 뒀다.ssl_certificate /etc/letsencrypt/live/${SSL_DOMAIN}/fullchain.pem;그런데 어느 순간 ${SSL_DOMAIN}이 치환되지 않고 글자 그대로 남았다. nginx는 ${SSL_DOMAIN}이라는 이름의 디렉터리에서 인증서를 찾으려다 실패했고, 443(HTTPS)이 뜨지 못했다.증상디스크의 템플릿은 멀쩡했다. ${SSL_DOMAIN}을 채우는 단계가 그냥 안 돌았다. 변수 치환(envsubst)이 통째로 건너뛰어진 것이다.근본 원인 — command를 덮어쓰면 치환 단계도..

부제: 이미 아는 건 다시 추출하지 않게 — 프로필을 미리 알려주기 대화에서 장기기억을 뽑아내는 단계가 있다. 대화를 읽고 "사용자에 대해 새로 알게 된 것"을 추려 저장하는 LLM 한 패스다. 여기서 사용자 이름 같은 게 자꾸 중복으로 들어왔다.배경 — 기억에도 종류가 있다저장하는 기억을 둘로 나눠 뒀다.정체성(identity): 천천히 변하는 특성 (직업, 알레르기 같은)에피소드(episodic): 시점에 묶인 경험 (어제 10km 뛴 것, 오늘 기분)이 구분은 인지심리학의 의미기억/일화기억 구분(Tulving (1972), Episodic and Semantic Memory — 일화기억과 의미기억의 구분.)에서 가져왔다. 그런데 이름·생일·성별 같은 건 둘 중 어디일까. 이건 "경험"이 아니라 프로..

이번 글은 성공담이 아니라 해보고 접은 이야기다. 그래도 왜 접었는지가 남으면 다음에 같은 길을 덜 헤맬 것 같아 적는다.아이디어에이전트가 사용자의 장기기억(메모리)을 참고해 답한다. 문제는 "언제 기억을 다시 불러오고 갱신할까"다. 가장 단순한 방법은 매 채팅마다 부르는 것이다. 확실하지만 무식하다.그래서 이런 생각을 했다. 사용자가 축구 이야기를 하다가 영양제로 넘어가는 것처럼 문맥(주제)이 바뀌는 순간에만 기억을 갱신하면 되지 않을까. 문맥이 그대로면 굳이 다시 부를 필요가 없다.문맥 변화는 임베딩으로 잡으려 했다. 최근 대화쌍 3개와 사용자의 최신 입력을 임베딩해서 유사도를 재고, 유사도가 충분히 낮으면 "주제가 바뀌었다"고 판단하는 식이다.무엇이 막혔나현실의 유사도 값이 뒤죽박죽이었다. 주제가 ..

컨테이너별 메모리·CPU를 모니터링하려고 했다. 보통은 cAdvisor 같은 익스포터를 붙이는데, 이 호스트에선 그게 잘 안 맞았다. 그래서 커널의 cgroup을 직접 읽기로 했다. 왜 cAdvisor를 안 썼나이 호스트는 컨테이너 이미지 저장에 containerd-snapshotter(overlayfs)를 쓴다. 이 조합에서 cAdvisor는 컨테이너를 제대로 못 봤다.도커 방식으로 조회하면 컨테이너를 0개로 인식했다.containerd 방식으로 조회하면 이름이 해시로 잡혀, compose 서비스 라벨이 사라졌다. 서비스 단위(api, postgres …)로 묶어 보는 대시보드를 만들 수가 없다.새 컨테이너(cAdvisor 등)를 여럿 띄우는 것도 부담이라, 작은 수집기 하나만 추가해서 cgroup을 ..

도구를 쓰는 멀티턴 대화에서, 모델이 가끔 이상한 행동을 했다. 자기 thinking(추론) 채널 안에 generate_placeholder_thoughts 같은, 실제로 존재하지 않는 도구를 호출하는 흉내를 냈다. 어디에도 정의한 적 없는 도구였다.배경 — thought signature가 뭔가Gemini는 도구 호출(functionCall)에 thought signature라는 암호화된 토큰을 붙여 준다. 이건 직전 턴의 추론을 이어가기 위한 일종의 앵커다. 다음 턴에 이 signature를 그대로 돌려보내면, 모델이 "내가 방금 무슨 생각을 하고 있었지"를 이어받는다.문제는 우리 쪽 코드에 있었다.증상대화 상태를 체크포인트에 저장하기 전에, 이 signature를 떼어내고 있었다. signature..