Noah's 개발자로 살아남기

[컨텍스트 엔지니어링] compact 뒤에 스킬은 어떻게 되나

긴 세션에서 자동 압축이 돌았다. 그 뒤로 스킬이 시키는 절차를 몇 단계 건너뛰기 시작했다. 규칙이 흐려지는 건 전에도 봤는데, 이번엔 스킬 쪽이었다.문서를 찾아보니 압축 때 스킬을 어떻게 처리하는지 규칙이 적혀 있었다. 잘라서 살린다. 그리고 잘리는 기준이 생각보다 구체적이었다.배경/compact 뒤 규칙이 사라지는 이유에서 압축이 CLAUDE.md 의 지시를 흐리게 만드는 걸 다뤘다. 그때 결론은 "규칙은 컨텍스트지 설정이 아니다" 였다.그 뒤로 긴 절차는 CLAUDE.md 에서 스킬로 옮겼다. 스킬 본문은 호출할 때만 로드되니 평소 컨텍스트를 안 먹는다. 좋은 거래였다.그런데 압축이 돌면 그 본문은 어떻게 되나. 이미 로드된 상태였으니 요약에 뭉개지는지, 통째로 남는지, 아예 빠지는지 알 수가 없었..

한 줄도 안 고쳤는데 git status 가 파일 전체를 변경으로 잡았다. git diff 를 열어 봤더니 삭제 3줄에 추가 3줄인데, 지운 줄과 더한 줄의 내용이 똑같아 보였다. 바뀐 건 글자가 아니라 줄 끝이었다. CRLF 와 LF.현상 win.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)diff 를 열면 이렇게 나온다.-line1-line2-line3+line1+line2+line3눈으로는 구분이 안 된다. 왼쪽 세 줄과 오른쪽 세 줄이 같은 글자다.환경항목값git2.50.1 (Apple Git-155)macOS26.4core.autocrlf미설정 (macOS 기본)재현Windows 에서 만든 파일이 그대로 들어온 상황을 만든다.gi..

목록에 검색 필터를 붙였다. 검색어가 바뀔 때마다 useEffect 로 filtered state 를 갱신했다. 동작은 했는데 렌더 로그가 한 글자에 두 번씩 찍혔다. 재보니 정말 두 번이었고, 그 사이에 필터 전 목록이 한 번 화면에 나갔다.배경3편에서 의존성 배열을 정확히 채우는 법까지 갔다. 린터가 넣으라면 넣으라고, 끄지 말라고 썼다.그 글의 전제는 "이 effect 는 필요하다" 였다. 의존성을 어떻게 채울지만 다뤘지, 그 effect 가 있어야 하는지는 안 물었다.이번에 걸린 게 그 지점이다. 의존성을 아무리 정확히 채워도 애초에 없어도 되는 effect 라면 정확한 게 의미가 없다.질문: props 나 다른 state 에서 계산되는 값을 state 로 두면 무엇이 잘못되는가?개념 — 파생 상..

git stash pop 이 충돌로 멈췄다. 순간 치워 뒀던 작업이 날아간 줄 알았다. 안 날아간다. pop 이 실패하면 stash 는 스택에 그대로 남는다. 대신 성공했을 때와 달리 자동으로 안 지워지므로, 충돌을 푼 뒤 직접 지워야 한다.현상Auto-merging f.txtCONFLICT (content): Merge conflict in f.txtOn branch mainUnmerged paths: (use "git restore --staged ..." to unstage) (use "git add ..." to mark resolution) both modified: f.txtno changes added to commit (use "git add" and/or "git commit -..

탭을 바꿨더니 입력하던 값이 사라졌다. 컴포넌트는 같은 컴포넌트였고, 조건부 렌더 한 줄만 바꿨을 뿐이다. 값이 남을 때와 사라질 때를 가르는 게 컴포넌트가 아니라면 대체 무엇인지 알아야 했다.배경1편에서 훅이 호출 순서로 슬롯을 찾는다는 데까지 갔다. useState 를 조건문 안에 넣으면 안 되는 이유가 거기 있었다. 그런데 그 글은 한 컴포넌트 안쪽 이야기였다. 그 슬롯 덩어리 자체가 어디에 매달려 있는지는 안 다뤘다.이번에 만난 문제가 그 바깥이었다. 같은 를 렌더하는데 어떤 때는 값이 남고 어떤 때는 0으로 돌아갔다. 조건부 렌더의 두 갈래에 같은 컴포넌트를 뒀는데도 그랬다.질문: React 는 어떤 컴포넌트의 state 를 어디에 붙여 두고, 언제 버리는가?개념 — state는 컴포넌트에 붙..

혼자 만드는 앱 프로젝트에 브랜치 전략을 얹은 적이 있다. 기능 묶음마다 브랜치를 따고, 끝나면 main 에 합치는 식이었다. 마일스톤 세 개를 그렇게 진행했다.중간에 Git Flow 를 제대로 도입할까 고민했다. develop, feature/*, release/*, hotfix/* 를 다 갖추는 구성이다. 검색하면 가장 많이 나오는 그림이고, 제대로 된 팀은 다 이렇게 한다는 인상을 받았다.그런데 혼자인 프로젝트에 release 브랜치를 만들어 두면 무슨 일이 벌어지는지 생각해 봤다. 릴리스를 준비하는 동안 다른 사람이 develop 에 계속 커밋하는 상황을 막으려고 만든 게 release 브랜치다. 그 다른 사람이 없다. 나 혼자 두 브랜치를 오가며 머지 커밋을 만들 뿐이었다.그래서 안 했다. 대신..

운영에서 급한 버그가 나서 develop 에 고친 커밋을 release 브랜치로 cherry-pick 했다. 배포는 잘 됐다. 문제는 그다음이었다. 릴리스가 끝나고 develop 을 release 에 정식으로 합쳤더니, 같은 수정이 커밋 목록에 두 번 나왔다.파일 내용은 멀쩡했다. 충돌도 안 났다. 그런데 히스토리에는 같은 제목의 커밋이 두 개 남았다. 나중에 "이 수정이 언제 들어갔지" 를 찾을 때 어느 쪽을 봐야 하는지 알 수 없었다.같은 변경을 cherry-pick 했을 뿐인데 왜 커밋이 두 개가 되는가?환경항목버전Git2.50.1 (Apple Git-155)확인한 문서git-scm.com git-cherry-pick, git-merge (2026-08-10 기준)cherry-pick 은 커밋을 옮..

배포된 버전에서 버그를 재현하려고 태그를 체크아웃했다. 그때 이런 경고가 나왔다.You are in 'detached HEAD' state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by switching back to a branch."둘러보고, 실험적인 변경을 하고, 커밋할 수 있다" 까지 읽고 넘겼다. 그래서 거기서 수정하고 커밋했다. 그리고 브랜치로 돌아왔더니 그 커밋이 어디에도 없었다.경고문 뒷부분에 답이 있었다. 브랜치로 돌아가면 그 상태에서 만든 커밋을 "버릴 수 있다" ..

git push --force 는 원격 브랜치를 내 히스토리로 통째로 덮는다. 그 사이 남이 올린 커밋이 있었다면 아무도 가리키지 않는 상태가 되어 사라진다. 공식 문서도 이걸 경고 문장으로 적어 뒀다.되살리는 건 대개 가능하다. 다만 원격이 아니라 커밋을 만든 사람의 로컬에서 꺼내야 한다. 그리고 애초에 --force 대신 --force-with-lease 를 쓰면 이 상황 자체가 막힌다.현상브랜치를 정리하려고 rebase 한 뒤 밀어 넣었다. 잠시 뒤 동료가 자기 커밋이 없어졌다고 했다.$ git push --force origin feature/checkout + a1b2c3d...9f8e7d6 feature/checkout -> feature/checkout (forced update)+ 기호와 ..

충돌이 나면 파일에 로 시작하는 덩어리가 생긴다. 위쪽이 내 것, 아래쪽이 상대 것이라는 건 알고 있었다. 그런데 정작 고를 때마다 막혔다. 둘 다 말이 되는 코드였고, 어느 쪽이 "맞는" 건지 판단할 근거가 화면에 없었다.한동안은 감으로 골랐다. 내가 방금 쓴 쪽을 남기거나, 최신 커밋 쪽을 남기거나. 그러다 남의 수정을 통째로 덮어 버린 걸 나중에 발견한 적이 있다. 그때부터 이 화면이 정확히 뭘 보여주는 건지 알아야겠다고 생각했다. 와 >>>>>>> 사이에 놓인 것은 정확히 무엇이고, 나는 무엇을 고르고 있는 건가?환경항목버전Git2.50.1 (Apple Git-155)확인한 문서git-scm.com git-merge (2026-08-10 기준)충돌은 두 쪽을 비교해서 나는 게 아니다merge 는..