Jaehyun Shin

더 많이 써도 더 안 지켜졌다 - 어느 시점부터 이상하다는 걸 알고 있었다.

2026-04-09T15:20:46Z

2026년 4월 9일 Jaehyun Shin Log 지시를 더 자세히 쓸수록 잘 따를 것 같은데, 실제로는 그렇지 않았다. 오히려 어느 순간부터 더 자세히 써도 달라지지 않았다. 표현의 문제라고 생각했다. 더 명확하게, 더 구체적으로 쓰면 될 거라고. 그래서 더 썼다. 그 결과가 380줄짜리 설정 파일이었다. 200줄을 넘으면 AI의 지시 준수율이

10. 사고는 자동화되지 않는다 - 자동화의 끝에서 남는 것

2026-03-01T23:00:34Z

이 연재는 자동화를 비판하기 위해 시작되지 않았다. 자동화는 여전히 유효하고, 여전히 강력하다. 다만, 끝에 가서 이 문장 하나가 남는다. 사고는 자동화되지 않는다. 자동화가 대신할 수 없는 것 자동화는 실행을 대신한다. 속도를 대신하고, 반복을 대신한다. 하지만 자동화는 왜라는 질문을 대신하지 않는다. 왜 이 방향이었는지 왜 지금 이 선택이었는지

9. 이 구조가 필요한 사람들 - 특정 직무의 문제가 아니다

2026-02-22T23:01:00Z

이 구조는 개발자를 위한 것도, 기획자를 위한 것도 아니다. 역할의 문제가 아니라, 상황의 문제다. 혼자 결정해야 하는 순간이 있고 판단을 설명해야 하는 순간이 있고 나중의 내가 다시 이해해야 하는 순간이 있다면 이 구조는 필요해진다. 다시 설명해야 하는 사람들 이 구조가 필요한 첫 번째 사람들은 다시 설명해야 하는 사람들이다. 왜 이 결정을 했

8. 자동화의 경계에 대하여 - 무엇을 자동화하면 안 되는가

2026-02-15T22:00:01Z

자동화는 언제나 유혹처럼 등장한다. 더 빠르게, 더 안정적으로, 더 적은 개입으로. 그래서 질문은 보통 이렇게 시작된다. “이것도 자동화할 수 있지 않을까?” 하지만 더 중요한 질문은 따로 있다. “이것은 자동화해도 되는 판단인가?” 자동화는 실행을 대신한다 자동화가 잘하는 일은 분명하다. 반복을 줄이고 속도를 높이고 실수를 최소화한다 이 영역

7. 다시 시작하기 어려운 이유 - 우리는 왜 항상 처음부터라고 느끼는가

2026-02-08T22:00:02Z

프로젝트를 다시 열면 늘 같은 말이 나온다. “이건 처음부터 다시 봐야 할 것 같아요.” 이 말은 실제로 처음이라는 뜻이 아니다. 다시 시작할 기준을 찾지 못했다는 뜻이다. 다시 시작은 왜 항상 비용이 큰가 다시 시작이 어려운 이유는 작업량 때문이 아니다. 코드가 많아서도 아니고 문서가 부족해서도 아니다 문제는 판단을 어디서부터 이어야 할지 모

6. 사고를 보존하는 최소 조건 - 자동화보다 먼저 설계했어야 했던 것

2026-02-01T22:00:03Z

우리는 늘 같은 순서로 움직인다. 먼저 만들고, 돌아가게 하고, 문제가 생기면 고친다. 사고를 보존하지 못하는 이유는 대부분 여기서 시작된다. 사고를 남길 구조를 미리 설계하지 않았기 때문이다. 사고는 의지가 아니라 구조에 남는다 사고를 잘 기록하자는 말은 대부분 개인의 노력으로 끝난다. 더 잘 정리하자 문서를 꼼꼼히 쓰자 회의록을 남기자 하지만

5. 결과만 남는 구조의 함정 - 우리는 왜 항상 같은 설명에 도착하는가

2026-01-25T22:00:10Z

문제가 생기면 대부분 같은 말로 정리된다. “결과는 나쁘지 않았다” “일단 돌아가고 있다” “다시 손보면 된다” 이 말들은 모두 사실이다. 그리고 동시에 아무것도 설명하지 않는다. 결과 중심 구조는 왜 매력적인가 결과는 관리하기 쉽다. 숫자로 남고 비교할 수 있고 보고서에 넣기 좋다 그래서 구조는 점점 결과를 기준으로 설계된다. 문제는 이때부터

4. 기록되지 않은 사고의 문제 - 프로젝트가 중단될 때, 가장 먼저 사라지는 것

2026-01-18T22:00:04Z

프로젝트가 멈출 때 가장 먼저 사라지는 것은 코드도, 문서도 아니다. 사고다. 파일은 남아 있고, 구조도 남아 있고, 기록도 남아 있다. 그런데 다시 시작하려고 하면 어디서부터 판단해야 할지 알 수 없다. 기록은 있는데, 사고는 없다 우리는 종종 이렇게 말한다. 문서는 남아 있다 로그도 있다 히스토리도 있다 그런데도 왜 이 결정을 했는지는 알 수 없

3. 실행과 판단이 분리되는 순간 - 사고는 사라지지 않는다

2026-01-11T22:00:10Z

다만, 구조 밖으로 밀려날 뿐이다 자동화가 사고를 지운다고 말하면, 대부분은 고개를 젓는다. 맞다. 사고는 여전히 존재한다. 문제는 사고가 더 이상 호출되지 않는 상태다. 분리는 의도가 아니라 결과다 누군가 판단을 지우자고 결정하지 않는다. 분리는 항상 결과로 발생한다. 판단을 규칙으로 바꾸고 규칙이 충분히 안정되면 더 이상 사람에게 묻지 않게 된다

2. 자동화가 남기지 않는 것들 - 자동화는 늘 성공처럼 보인다

2026-01-04T23:00:55Z

자동화는 보통 성공으로 기록된다. 속도는 빨라지고, 실수는 줄어들고, 결과는 안정된다. 그래서 문제는 잘 보이지 않는다. 다시 열어보기 전까지는. 다시 열었을 때 생기는 공백 시간이 지나 구조를 다시 보면, 작동은 한다. 결과도 나온다. 하지만 설명이 멈춘다. 왜 이 순서였는지 왜 이 조건이 필요한지 왜 다른 선택지는 버려졌는지 그때의 판단을 말해줄 문

1. 사고는 어디에서 사라지는가 - 자동화 이후의 공백

2026-01-04T22:00:11Z

자동화는 늘었는데, 왜 다시 열면 더 헷갈릴까? 프로젝트를 잠시 멈췄다가 다시 열었을 때, 이상하게도 늘 비슷한 순간에 멈칫하게 된다. 자동화는 분명 더 많이 되어 있다. 버튼은 늘었고, 흐름도 정리돼 있다. 다시 실행만 하면 될 것처럼 보인다. 그런데 막상 손을 얹는 순간, 이 질문이 먼저 떠오른다. “내가 왜 여기까지 왔지?” 처음에는 기능의

사고는 어디에서 사라지는가 - 자동화 이후의 공백

2026-01-01T13:31:02Z

왜 자동화를 더 했는데, 다시 열면 더 헷갈릴까 프로젝트를 잠시 멈췄다가 다시 열었을 때, 이상하게도 늘 비슷한 순간에 멈칫하게 된다. 자동화는 분명 더 많이 되어 있다. 버튼은 늘었고, 흐름도 정리돼 있다. 다시 실행만 하면 될 것처럼 보인다. 그런데 막상 손을 얹는 순간, 이 질문이 먼저 떠오른다. “내가 왜 여기까지 왔지?” 처음에는 기능의