--- title: '경계가 지워진 뒤, 판단은 누가 배우는가' marp: true paginate: true theme: ink header: '잡코리아 프로덕트 컨퍼런스 2026 / 흩어진 경계, 흔들리는 기준' footer: '김용찬' transition: none tags: - ai - career date: 2026-11-26 description: 'AI가 만드는 일을 맡으면서 기획, 개발, 디자인의 경계가 흐려집니다. 무엇이 맞는지 판단하고 책임지는 일은 여전히 남지만, 그 판단을 배우던 과정은 건너뛸 수 있게 됐습니다. 답이 질문보다 먼저 오는 시대에 판단은 누가 어디서 배우는지, 제 경험과 다른 사람들의 기록을 바탕으로 살펴봅니다.' published: true featured: true art: undraw: ai-generated-document --- # 경계가 지워진 뒤,
판단은 누가 배우는가 ## 만드는 일을 AI에 맡겨도 남는 판단,
그 판단을 배우는 과정은 어떻게 달라질까요 **김용찬** 카카오페이증권 프론트엔드 엔지니어 --- ![김용찬의 블로그 favicon](/feconf-2026/blog-favicon.svg) ### 김용찬 카카오페이증권 / 프론트엔드 엔지니어 - 2014년부터 삼성SDS, 카카오, 트리플, 네이버 파이낸셜(내자산회원FE/카드FE 리더)을 거쳐
지금은 증권 홈 화면을 만듭니다 - 『모던 리액트 Deep Dive』, 『npm Deep Dive』, 『프런트엔드 성능 최적화 Deep Dive』를 썼습니다 - 이 주제로 『남은 판단은 누가 배우는가』라는 책을 쓰고 있습니다 _[yceffort.kr](https://yceffort.kr) / [github.com/yceffort](https://github.com/yceffort)_ --- > 01 # 어디까지가
내 일인가 ## 코드를 읽는 것까지가 내 일인지 묻게 된 날의 이야기로 시작합니다 1. **어디까지가 내 일인가** 2. 만드는 경계는 무너지고,
판단의 경계는 남는다 3. 그 판단은 어디서 배우는가 4. 그럼 무엇을 할 수 있나 5. 마무리 --- ## 오픈을 앞두고, 남이 짠 코드를 끝까지 읽고 있었습니다 > 어차피 그거 다 AI가 짠 거고, 버그가 다시 나도 AI가 고칠 거예요.
일단 오픈이 중요하니까 그냥 넘어가시죠. 조금 움찔했지만, 저는 **이내 동의했습니다.**
떠밀린 것이 아닙니다.
저도 제 코드 검토가 병목이라고 느꼈습니다. _오늘 말씀드리는 장면은 시기와 소속, 도구와 서비스의 이름, 업무의 세부를 바꾸거나 생략했고, 일부는 여러 경험을 합쳐 재구성했습니다._ --- ## 사람이 코드를 읽는 일만 느렸습니다
코드 생성몇 초
테스트자동으로 채워짐
사람이 읽기한 줄씩. 가장 느리고 비싼 작업처럼 보였다
배포버튼 하나
끝까지 읽지 않고 반영한 그 코드는 **지금까지도 조용합니다.** > 문제가 없었던 것인지,
문제가 드러날 상황이 아직 오지 않은 것인지 알 수 없었습니다. --- ## 그날 제가 떠올린 질문은 어긋나 있었습니다 > ### 그날의 질문 > > AI와 나 중에 누가 더 똑똑한가.
버그가 나면 AI가 나보다 빨리 고칠지도 모른다. > ### 물었어야 할 질문 > > 무엇을 근거로 이 변경을
사용자 앞에 내보내도 된다고 판단했는가. "어디까지가 내 일인가"라는 이번 컨퍼런스의 질문은 제게 이렇게 다가왔습니다.
**읽는 것까지가 내 일인가.**
이제 이 질문을 따라가 보겠습니다. --- > 02 # 만드는 경계는 무너지고,
판단의 경계는 남는다 ## 경계라는 말에 섞여 있는 두 가지를 먼저 나눕니다 1. 어디까지가 내 일인가 2. **만드는 경계는 무너지고,
판단의 경계는 남는다** 3. 그 판단은 어디서 배우는가 4. 그럼 무엇을 할 수 있나 5. 마무리 --- ## 경계라는 말에는 두 가지가 섞여 있습니다
직군누가 만들 수 있는가무엇이 맞는지 누가 판단하고 책임지는가
기획문서를 쓰는 손무엇이 일어나면 안 되는지 정하는 판단
디자인시안을 그리는 손이 화면이 사용자 앞에서 작동하는지 아는 눈
개발코드를 치는 손어디서 터질지 아는 감각
이 경계는 실제로 무너지고 있습니다이 경계는 남습니다
각 직군의 알맹이는 산출물을 만드는 손이 아니라, 그 산출물이 **맞는지 가려내는 판단**이었습니다. --- ## 배너는 멀쩡히 떴고, 노출은 한 건도 집계되지 않았습니다 ```ts // 마케터가 관리 화면에 등록한 배너. 노출과 클릭을 세는 추적 코드가 같이 들어온다 const banner = `봄 이벤트 ` // AI가 안전을 위해 넣은 처리. onclick, onload 같은 이벤트 속성이 함께 걸러진다 container.innerHTML = DOMPurify.sanitize(banner) ``` > 낮게 측정된 것과 아예 측정되지 않은 것은 다른데,
제게는 둘 다 성과가 없다는 말로 들렸습니다. 화면에서는 문제가 보이지 않았습니다.
문제는 집계에서만 드러났고, 한동안 아무도 그 숫자를 확인하지 않았습니다. --- ## 빨간불은 한 번도 켜지지 않았습니다 | 누가, 무엇으로 | 확인한 것 | 노출 집계 | | -------------------- | ---------------------------- | ------------------- | | 테스트 | 테스트에 적어 둔 화면의 동작 | 보지 않았다 | | 타입 검사 | 타입 오류 | 보지 않았다 | | 나 | 배너가 떴다는 확인 | 보지 않았다 | | 마케터의 배너 등록 | 배너가 제대로 뜨는지 | 보지 않았다 | | 마케터의 집계 보고서 | 노출과 클릭 숫자 | **빈칸을 발견했다** | 이상을 발견한 사람은 그 코드를 한 줄도 읽지 않는 사람이었습니다.
안전하게 표시되는지만 봤고, **이 제품에 필요한 집계**는 확인하지 않았습니다. --- ## 테스트는 통과했고, 잔고는 어긋났습니다 ```ts // 적립 스펙: 결제 금액의 0.5퍼센트, 원 단위 반올림. 화면은 건마다, 서버는 합계를 반올림했다 const rewardOf = (amount) => Math.round(amount * 0.005) // 기대값은 스펙으로 셈하지 않고, 화면이 낸 값을 그대로 옮겨 적었다 test('1,100원 결제 세 건의 적립', () => { expect(rewardOf(1100) + rewardOf(1100) + rewardOf(1100)).toBe(18) // 통과. 서버는 17 }) ```
화면: 건마다 반올림해서 더했다 (5.5원은 6원)6 + 6 + 618원
서버: 합계를 반올림했다 (스펙이 정한 방식)3,300 × 0.5% = 16.517원
잔고가 어긋나는 동안에도 테스트는 통과했고, 저는 **기대값이 스펙에 맞는지** 확인하지 않은 채 승인했습니다. --- ## 하지 말라는 지시는 있었지만, 실행을 막지는 못했습니다 > 명시적인 지시를 어겼고, 몇 달치 작업을 파괴했습니다.
코드 동결 선언2025년 7월, 에이전트와 9일째. 허락 없이 바꾸지 말라고 적어 둠
운영 DB 삭제에이전트가 지시를 어기고 실행
"복구는 불가능"에이전트의 답. 그 말은 틀렸다
복구플랫폼의 복구 기능으로 데이터가 돌아옴
분리를 기본값으로사고 뒤 플랫폼이 개발과 운영 DB를 분리
하지 말라는 지시는 있었지만, 운영 데이터를 건드리지 못하도록 분리해 두지는 않았습니다.
그 분리는 사고 뒤 플랫폼이 넣었습니다. **그 판단까지 저절로 따라오지는 않았습니다.** --- > 생산은 이동하지만, 판단과 책임은 이동하지 않습니다.
그러니 판단하는 개발자가 되면 됩니다. 여기까지가 올여름 제가 블로그와 책에 쓴 결론을 요약한 것입니다.
하지만 앞의 사례에서는 마케터와 플랫폼, 제가 **서로 다른 판단을 맡았습니다.**
그리고 **한 가지를 묻지 않았습니다.**
그 판단은 어디서 배우는가. --- > 03 # 그 판단은
어디서 배우는가 ## 판단이 남는다는 말만으로 안심할 수 있을까요 1. 어디까지가 내 일인가 2. 만드는 경계는 무너지고,
판단의 경계는 남는다 3. **그 판단은 어디서 배우는가** 4. 그럼 무엇을 할 수 있나 5. 마무리 --- ## 코드를 한 줄씩 읽어도 보이지 않는 것이 있었습니다 ```tsx // AI가 코드를 써 주기 한참 전, 서버에서 화면을 미리 만들던 코드 const pageData = {} // 파일 맨 위에 하나. 어느 요청에서든 같이 쓴다 export async function render(req) { pageData[req.id] = await loadData(req) // 요청마다 쌓이고, 끝나도 비워지지 않는다 return renderToString() } ``` 한 줄씩 읽고 동료들의 리뷰를 거쳤지만,
그 객체가 **요청보다 오래 살아남는다**는 점을 아무도 문제로 보지 못했습니다.
서버의 메모리 사용량은 시간이 갈수록 늘었습니다. --- ## 읽기로는 안 보였고, 지워 보고서야 보였습니다 - 한동안은 메모리가 차면 서버를 다시 띄우는 식으로 버텼습니다 - 코드를 한 덩어리씩 지우고 서버를 다시 띄워 그래프를 확인했습니다 - 조사 범위를 절반씩 좁히다가, 특정 코드를 지우자 메모리가 더는 늘지 않는 것을 확인했습니다 > 이해하지 않고는 일을 계속할 수 없었습니다.
이 과정에서 겪은 어려움을 저는 **마찰**이라고 부릅니다. --- ## 제 기록에 남은 배움의 순서는 이렇습니다 1. 필요 2. 물음 3. 내 답 4. **나에게 돌아온 틀림의 신호** 5. 직접 수습하기 6. 다음 판단 여기서 말하는 신호는 **예상한 결과와 실제 결과의 차이**입니다.
그 차이를 보고, 다음 행동을 정하기 전에 이유를 따져 볼 수 있었습니다.
이제 그 과정을 거쳤을 때와, 답을 먼저 받아 그 과정을 건너뛸 때를 살펴보겠습니다. --- ## 2021년, 성공했던 커밋을 다시 배포했는데 실패했습니다 잘 돌아가던 제 블로그였습니다. 같은 코드가 다른 결과를 내니, 어디를 의심해야 할지 몰랐습니다.
배포 실패성공했던 커밋을 그대로 다시 배포해도 실패
"버전을 올려 보세요"고객센터의 첫 답. 이미 올린 뒤였다
담당자가 재현제 저장소를 복사해 같은 실패를 확인. 저는 그사이 다른 플랫폼으로 옮겼다
3주 뒤, 원인은 둘제 코드가 이미지 파일을 통째로 빌드에 포함했고, 플랫폼의 파일 추적 버그가 그것을 가렸다
> 그제야 배포에 의존성 추적(빌드에 포함할 파일을 찾는 단계)이 있다는 것을 알았습니다.
같은 커밋이 실패하면 **플랫폼도 의심할 이유**가 생겼습니다.
그렇다고 그 3주를 잘 쓴 시간이라고 생각하지는 않았습니다. --- ## 올해, 코드만 보면 일어날 수 없는 일이 일어났습니다 ```ts // socket.ts: 모듈 맨 위의 객체 하나. 어디서 import하든 같은 객체여야 한다 export const socket = {client: null, state: {}} // checkStatus.ts: 위의 socket을 import해서 읽는다 export const isSocketOpen = () => socket.client?.readyState === WebSocket.OPEN // send.ts: 연결이 없거나 닫혀 있을 때만 들어오는 분기 if (!socket.client || !isSocketOpen()) { isSocketOpen() // 그런데 여기서 다시 물으면 true } ``` 사이에 기다리는 코드도, 상태를 바꾸는 코드도 없었습니다.
같은 `socket`을 읽는 함수라면, client가 없는데 열려 있다고 답할 수는 없습니다.
소스를 몇 번이고 다시 읽었지만 소스는 끝까지 정상이었습니다. --- ## 소스는 정상이었고, 의심은 하루 늦었습니다 ```mermaid %%{init: {"theme": "base", "themeVariables": {"fontFamily": "SUIT Variable, sans-serif", "fontSize": "18px", "primaryColor": "#eceef6", "primaryTextColor": "#121826", "primaryBorderColor": "#121826", "lineColor": "#5b6475", "clusterBkg": "#fbfbfd", "clusterBorder": "#d3d7e2", "edgeLabelBackground": "#fbfbfd"}, "flowchart": {"nodeSpacing": 22, "rankSpacing": 34, "padding": 8}}}%% flowchart LR S["소스의 socket.ts
하나"] -. "번들러의 최적화 결함으로 복제" .-> run subgraph run["런타임: 둘"] A["send.ts"] --> S1["socket ①
client 없음"] B["checkStatus.ts"] --> S2["socket ②
연결됨"] end ```
에이전트에 맡긴 조사400달러가까이 쓰고도 원인을 못 찾음
번들러를 의심하기까지하루2021년에 배운 기준을 하루 늦게 꺼냈다
같은 결함의 수정2주 전이미 보고되고 고쳐져 있었다
> 저와 그 경험이 없는 사람이 같은 도구로 같은 날 일을 끝냈다면,
**완료 기록만으로는 각자 무엇을 배웠는지 알 수 없습니다.** --- ## AI로 연습한 뒤 무엇을 배웠는지, 시험으로 확인한 실험이 있습니다 한 고등학교에서 천 명 가까운 학생을 교실 단위로 나눴습니다.
연습 시간에만 챗봇을 쓰게 하고, 시험은 아무 도구 없이 치르게 했습니다. | 연습 때 쓴 것 | 연습에서는 | 도구 없는 시험에서는 | | ------------------------------- | ---------------------- | ------------------------------ | | 답을 바로 주는 챗봇 | 48퍼센트 더 잘 풀었다 | **대조군보다 17퍼센트 낮았다** | | 답 대신 힌트를 주게 설계한 챗봇 | 127퍼센트 더 잘 풀었다 | 대조군과 구분되지 않았다 | | 챗봇 없음 | 기준 | 기준 | 같은 모델을 썼지만, **교사의 풀이를 바탕으로 힌트를 주도록 설계한 챗봇**에서는 시험 성적이 떨어지지 않았습니다.
연습 성적만 봐서는 이 차이를 알 수 없었습니다. --- ## 판단은 남는데, 판단을 기르던 과정은 건너뛸 수 있게 됐습니다 > ### 예전에는 > > 막히면 멈췄습니다.
틀리면 빨간불이 저에게 왔습니다.
이해하지 않고는 일이 끝나지 않았습니다. > ### 지금은 > > 답이 질문보다 먼저 옵니다.
실패가 저를 거치지 않고 고쳐집니다.
이해하지 않고도 일이 끝납니다. 건너뛰어도 일은 끝나니, 완료 기록이나 체감만으로는 무엇을 배웠는지 확인하기 어렵습니다.
특히 **아직 판단을 배우는 중인 사람**에게 이 공백이 우려됩니다. --- ## 작업 속도를 잰 연구에서도 체감과 실제는 달랐습니다
2025년 초, 숙련 오픈소스 개발자들의 예상+24%빨라질 거라고 예상했다
끝난 뒤 체감+20%빨라졌다고 답했다
실측−19%실제로는 느렸다
_속도를 잰 연구이지 학습을 측정한 연구는 아닙니다._ > 나는 배우고 있지 않았다.
관리하고 있었다. 주니어 시절을 AI와 보낸 한 개발자의 문장입니다. --- > 04 # 그럼 무엇을
할 수 있나 ## 제가 시도한 방법과 다른 곳의 대응을 살펴봅니다 1. 어디까지가 내 일인가 2. 만드는 경계는 무너지고,
판단의 경계는 남는다 3. 그 판단은 어디서 배우는가 4. **그럼 무엇을 할 수 있나** 5. 마무리 --- ## Rails를 만든 사람은 올해 손코딩에서 은퇴했습니다 > Rust를 전혀 모르는 것은 특권이다. 2026년 9월, Rails World의 오프닝 키노트에서
DHH는 몇 주 전부터 회사에서 손으로 코드를 쓰는 일을 그만뒀다고 했습니다.
직접 만든 앱의 코드는 한 줄도 보지 않았고,
아직 손으로 코드를 쓰는 사람이 있느냐는 물음에 손을 든 청중은 다섯 명 남짓이었습니다. 디자이너들이 바이브 코딩으로 만든 기능을 합쳐 보니 구멍투성이였다고도 했습니다.
그가 틀렸다고 한 것은 "아직 기술이 준비되지 않았다"는 당시의 결론이었습니다.
저는 그의 선택에 **20년 넘게 코드를 읽고 쓰며 쌓은 판단의 경험**도 영향을 줬다고 봅니다. --- ## 여기서 이런 조언을 하고 싶어집니다 > AI를 끄고 직접 디버깅하는 시간을 떼어 두세요.
막혀도 바로 묻지 마세요. - 맞는 말이어도 **개인이 실천하기는 어렵습니다.**
조직이 속도를 보상하고 동료가 두 배 빠르게 일한다면, 혼자 학습에 시간을 더 쓰기는 어렵습니다 - 이런 조언을 하는 저는 이미 시행착오를 거쳐 판단을 익힌 사람입니다.
지금 배우는 사람에게 제가 겪은 어려움을 그대로 감수하라고 말하기는 조심스럽습니다 그래서 **제가 실제로 시도한 방법**과 **다른 곳에서 어떻게 대응하는지**를 말씀드리겠습니다. --- ## 설명하지 못하는 PR은 닫았습니다 중요한 화면의 PR은 전부 읽고 의견도 직접 적습니다.
읽어서 모든 문제를 잡을 수는 없지만, 무엇이 바뀌는지는 제가 이해하려고 합니다.
올린 사람에게도 같은 것을 요구합니다.
왜 이 버전으로 올렸는지, 이 도구가 무슨 일을 하는지, 여러 선택지 중 왜 이것을 골랐는지.
자기가 올린 코드에 **모르는 것을 두어서는 안 된다**고 말합니다. > 요구한 기능은 다 만들었는데, 왜 닫느냐는 말을 들었습니다. 그때 저는 이렇게 답했습니다. 요구한 기능만 만들 거라면 사람 대신 에이전트를 한 번 더 돌리면 됩니다.
사람이 필요한 이유는 **그 코드를 함께 이해하고 이야기하는 데** 있습니다. --- > 설명을 요구한 사람은 저였고,
시간을 쓴 사람은 동료들이었습니다. 동료들이 그 시간에 무엇을 배웠는지 저는 살피지 않았습니다.
설명을 요구한 것만으로 **배울 조건까지 마련했다**고 말할 수는 없었습니다. --- ## 검토를 받는 쪽만이 아니라 검토하는 쪽도 지쳐 갑니다 > 그 지경이면 나는 여기서 뭘 하고 있는 거지.
그 검토마저 AI에 맡기고 싶어졌을 때, 한 유지보수자의 아침PR 30개다른 사람들이 AI로 밤새 만들어 둔 PR을 검토하며 하루를 시작했다
다른 저장소, 봇이 올린 PR승인 3번AI 리뷰 봇은 세 번 문제없다고 했지만, 유지보수자가 저품질이라는 뜻의 slop 라벨을 붙여 닫았다
자신의 리뷰를 읽고 상대가 배우는 모습을 보는 것이 오랜 보람이었는데,
이제는 자기가 쓰는 모든 것이 AI 블랙홀로 들어간다고 했습니다.
**세 번의 승인이 무엇을 확인했는지 모르면, 횟수는 근거가 되지 않습니다.** --- ## 바깥에서는 규칙으로 정하기 시작했습니다 | 누가 | 무엇을 | 그 결과 | | ---------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------- | | Software Freedom Conservancy | AI의 도움을 받은 기여는 충분히 검토하고 깊이 이해하라고 권고 | 제출하는 사람이 시간을 써야 한다는 기준 | | tldraw, Ladybird, Hono | 외부 기여자의 PR을 자동으로 닫거나 아예 받지 않음 | 검토할 수 있는 양부터 줄임 | | 미국 항공 | 숙련 검사는 제도, 수동 비행 기회는 권고 | 권고 이행은 감사에서도 확인 못 함. 사고에서 규칙 기한까지 십 년 | 독학으로 배운 한 개발자는 외부 PR을 막는 결정이 옳다면서도 이렇게 썼습니다.
"처음 PR을 보내던 나였다면 지금은 그 문을 통과하지 못했을 것."
검토자의 시간을 지키는 규칙이, **바깥에서 묻고 배우던 자리**까지 좁히고 있습니다. --- ## AI와 다시 배운 것도 있습니다 > ### 2021년 > > "학습의욕과 노력에 비해서 많이 늘지 못하고 있다."
쿠버네티스를 두고 그렇게 적었습니다.
영어 문서에서 자주 막혔고,
시도할 때마다 비용이 나갔고, 결국 접었습니다. > ### 2026년 > > 막히는 대목마다 AI에게 설명을 받았고,
에이전트가 짜 준 예제를 작은 클러스터에서
직접 돌려 그 설명이 맞는지 확인했습니다.
업무에 적용했고, 글로 다시 설명했습니다. AI는 **막혀서 낭비하던 시간**을 줄여 주었고, 저는 직접 실행하며 배운 내용을 확인했습니다.
다만 두 시기 사이에 도구만 바뀐 것은 아닙니다.
5년의 경력이 쌓였고, 배운 내용을 적용할 업무와 무엇을 측정해야 할지 판단한 경험도 있었습니다. --- ## 각자의 자리에서, 제가 본 것만 적습니다 > ### 아직 판단을 배우는 중이라면 > > 면접이나 고객 문의에 답하려면
**내가 판단한 이유를 설명해야 합니다.**
평소에 스스로 판단해 본 경험이 없으면,
판단을 요구받는 날에야 처음 해 보게 됩니다.
저는 설명은 AI에게 듣고, **확인은 직접 했습니다.** > ### 판단의 경험이 쌓였다면 > > 동료가 스스로 이유를 따져 볼 기회를 줍니다.
설명할 시간을 주고,
그 시간을 썼다는 이유로 불이익을 주지 않습니다.
배울 조건은 어떤 일을 맡기고, 무엇을 설명하게 하며,
**얼마나 시간을 주는지**에 달려 있습니다. 프로 바둑 기사들의 판단은 알파고 이후 두 해 만에 눈에 띄게 좋아졌습니다.
다만 그들은 **연습은 AI와 하고, 대국은 도구 없이** 둡니다.
우리 일에서는 연습과 실무가 그처럼 나뉘어 있지 않습니다. --- > 코드를 쓰고 고치는 일을 맡겨도,
무엇을 믿고 어디서 멈출지 정하는 판단은 남습니다.
"판단하는 개발자가 되면 된다"는 말에는,
그 판단을 배우는 과정까지 들어 있어야 합니다. 처음 이야기한 그 코드는 지금까지 조용합니다.
다만 제가 중단한 코드 검토에는 **변경의 영향을 어디까지 살펴야 하는지 배우는 일**도 들어 있었습니다. --- # 남은 판단은
누가 배우는가 ## 일을 끝내는 도구가 생겨도, 배울 기회까지 고르게 주어지지는 않았습니다 **김용찬** 카카오페이증권 / [yceffort.kr](https://yceffort.kr) 오늘 이야기의 긴 판본은 블로그 시리즈 "AI 시대의 판단"과 출간을 준비하고 있는 책 『남은 판단은 누가 배우는가』에 있습니다.
질문은 댓글창에 남겨 주시면 발표 뒤에 답하겠습니다. --- ## 오늘 인용한 바깥의 기록 1 | 대목 | 출처 | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | 코딩 에이전트의 운영 DB 삭제 | Jason Lemkin의 X 게시물(2025년 7월 18일~20일), Amjad Masad의 X 게시물(7월 20일), Fortune 2025년 7월 23일 | | 고등학교 수학 실험 | Bastani 외, "Generative AI without guardrails can harm learning", PNAS 122(26), 2025 | | 숙련 개발자 실측 | METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 2025년 7월 | | "나는 배우고 있지 않았다. 관리하고 있었다." | Devrim Ozcay, "Why AI Coding Tools Killed My Junior Developer Career", Medium | | Rails World 2026 키노트 | DHH, 2026년 9월 23일 오스틴. 정리 글은 yceffort.kr/2026/09/dhh-rails-world-2026-keynote | | 코드만 보면 일어날 수 없는 일 | yceffort.kr/2026/08/turbopack-scope-hoisting-singleton-split | | 쿠버네티스를 다시 배운 기록 | yceffort.kr/series/k8s-for-frontend (31.5초 실측은 5편) | _2021년 배포 실패 기록도 저자 블로그에 있습니다. 발표의 긴 판본: yceffort.kr/series/ai-era-judgment_ --- ## 오늘 인용한 바깥의 기록 2 | 대목 | 출처 | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | 유지보수자의 아침 | Laura Summers, "The Human-in-the-Loop is Tired" | | AI 리뷰 봇의 세 번 승인 | oven-sh/bun Pull Request #33864, 2026년 7월 | | AI 기여 권고 | Software Freedom Conservancy, "Recommendations When Using LLM-backed Generative AI Systems for FOSS Contributions", 2026년 6월 | | 외부 PR 정책 | tldraw 이슈 #7695(2026년 1월), Ladybird 블로그(2026년 6월), Hono 제작자의 X 게시물(2026년 10월) | | "그 문을 통과하지 못했을 것" | James Ross, "Open Source as We Know It Is Dead", 2026년 10월 | | 항공의 검사와 권고 | 14 CFR §121.441, FAA SAFO 13002(2013), 미 교통부 감사 보고(2016), Colgan Air 3407편 사고 뒤의 훈련 규칙(기한 2019) | | 프로 바둑 580만 수 | Shin 외, PNAS 120(12), 2023; Choi 외, Strategic Management Journal |