구독하기

전체 글

74
브라우저에서 문서 다루기

PDF 위 박스가 어긋나는 건 확대 탓이 아니다

브라우저에서 문서 다루기 #2 — 박스를 화면 좌표로 저장하면 배율이 바뀔 때 어긋나고, PDF 좌표로 저장해도 y만 뒤집으면 잘린 PDF와 돌아간 PDF에서 어긋나요. 그린 것과 같은 viewport로 바꾸면 셋 다 사라집니다.지난 글에서 react-pdf를 Next.js에 띄우는 데까지 했어요. 띄우고 나면 바로 다음 요구가 오는데요, PDF 위에 박스를 그리고 저장했다가 다시 열었을 때 같은 자리에 보여 달라는 거죠. 이 글에서는 그 박스가 왜 어긋나는지, 무엇을 저장해야 안 어긋나는지 정리해 볼게요.처음 만든 박스는 제자리에 있다가 확대하면 슬금슬금 밀려났어요. 배율 문제를 고치고 나니 이번엔 어떤 PDF에서만 옆으로 비껴났고요. 두 번 다 원인은 좌표를 무엇으로 저장했느냐였어요.좌표계가 두 개예..

2026.09.23
브라우저에서 문서 다루기

pdf.js를 Next.js에 붙이는 방법은 이미 반쯤 바뀌었다

브라우저에서 문서 다루기 #1 — 검색해서 나오는 설정 네 가지 중 셋은 버려도 되고, 하나는 지금도 필요해요. 빈 next.config로 직접 확인해 볼게요.PDF를 웹에서 보여줘야 할 일이 생기면 보통 react-pdf로 갑니다. 그리고 검색을 하면 거의 모든 글이 next.config부터 고치라고 하는데요, 그대로 따라 했다가 오히려 한참 헤맸어요.이 글에서는 그 처방들이 지금도 유효한지 하나씩 확인하고, 왜 그중 하나만 살아남는지 정리해 볼게요. 확인은 빈 설정으로 만든 최소 재현 저장소로 했습니다.검색하면 나오는 네 가지 처방대략 이 넷이 세트로 따라다닙니다.// ① 압축 끄기module.exports = { swcMinify: false }// ② canvas를 빈 모듈로 보내기webpack:..

2026.09.23
에이전트와 일하는 프런트엔드

우리는 우리 속도를 못 잰다

에이전트와 일하는 프런트엔드 #5 — 19% 느려졌다는 그 연구가 1년 뒤 어떻게 됐는지, 그리고 왜 연구팀 본인이 결과를 물렸는지 정리해 볼게요."AI 쓰면 개발자가 19% 느려진대." 이 문장을 올해 몇 번 보셨을 거예요. 출처는 METR이 2025년 7월에 낸 무작위 대조 실험인데요, 저도 한동안 이 숫자를 그대로 인용했습니다.그런데 이 연구는 그 뒤로 두 번 더 움직였어요. 움직인 내용이 원래 결과보다 중요한데요, 이 글에서는 그 19%가 1년 뒤 어떻게 됐는지, 그리고 왜 연구팀이 자기 측정을 물렸는지 정리해 볼게요.널리 인용되는 19%가 어디서 왔는지부터조건을 먼저 보고 가는 게 좋겠어요. 나중에 이야기가 뒤집히는 지점이 전부 이 조건 안에 있거든요.METR은 경험 많은 오픈소스 기여자 16명..

2026.09.23
에이전트와 일하는 프런트엔드

검토를 돕는 도구는 판정하지 않는다

에이전트와 일하는 프런트엔드 #4 — 검토를 돕는 도구가 판정까지 하면 왜 사람이 같이 틀리는지, 측정된 숫자 두 개로 이야기해 보려고 해요.3편은 이렇게 끝냈어요. 에이전트에게 구현은 맡길 수 있어도 판정 기준은 맡길 수 없다.그 글은 에이전트를 쓰는 쪽에서 쓴 거였는데요. 요즘 제가 하는 일은 반대쪽이에요. 사람이 문서를 검토하는 걸 도와주는 시스템을 만들고 있거든요. 그러니까 질문이 이렇게 바뀝니다.판정을 사람이 해야 한다면, 도구는 도대체 뭘 해야 하나?답이 "도구가 1차로 판정하고 사람이 확인한다"인 것 같지만, 이 답에는 측정된 반박이 두 개 있어요. 이 글에서는 그 두 결과를 먼저 보고, 거기서 나오는 프런트엔드 설계 원칙 다섯 개를 정리해 볼게요.AI 교육 20시간으로도 자동화 편향은 안 ..

2026.09.22
에이전트와 일하는 프런트엔드

에이전트가 쓴 테스트는 무엇을 증명하나

에이전트와 일하는 프런트엔드 #3 — 에이전트에게 테스트를 맡기면 왜 동어반복이 나오는지, 측정된 결과와 규제 용어로 정리해 볼게요.지난 글은 이렇게 끝냈어요. 검증 구조를 먼저 갖춘 팀만 에이전트를 제대로 쓸 수 있다.쓰고 나서 스스로 이런 생각이 들었는데요. 그럼 그 검증 구조도 에이전트한테 만들게 하면 되는 거 아닌가? 테스트 짜는 건 에이전트가 제일 잘하는 일처럼 보이거든요.안 돼요. 그리고 안 되는 이유가 취향 문제가 아니라 측정되어 있습니다.버그 있는 코드를 주면, 테스트가 버그를 정답으로 박제해요토론토대 연구진이 올해 7월에 낸 결과예요. Defects4J v3.0의 실제 결함 233건, 함수 318개를 놓고, 모델 11개(Gemini · Claude · Grok · GPT · DeepSee..

2026.09.22
에이전트와 일하는 프런트엔드

AI가 쓴 코드, 누가 책임지나

에이전트와 일하는 프런트엔드 #2 — AI가 쓴 코드의 책임을 규제는 어떻게 다루고 있는지, 적용 범위를 뭉개지 않고 정리해 볼게요.유럽 GMP 부속서 초안에 이런 취지의 문장이 들어갔어요. GMP에 중요한 결정은 "정적이고 결정론적인(static, deterministic)" 모델만 내릴 수 있다. 동적 모델, 생성형 AI, 대규모 언어 모델은 중요 용도에서 제외한다.LLM을 아예 금지한 건 아닌데요. 일탈 보고서 요약, SOP 검색, 정비 메모 초안 같은 중요하지 않은 작업에는 쓸 수 있어요. 단 조건이 붙습니다. 자격 있는 사람이 루프 안에 있어야 하고, 그 사람이 출력물을 검토하며, 문서화된 책임을 집니다.규제기관이 "AI 잘 쓰세요" 같은 덕담이 아니라 규정 문안으로 선을 그은 건 이게 처음이에..

2026.09.21
브라우저에서 문서 다루기

PDF 위 박스가 어긋나는 건 확대 탓이 아니다

브라우저에서 문서 다루기 #2 — 박스를 화면 좌표로 저장하면 배율이 바뀔 때 어긋나고, PDF 좌표로 저장해도 y만 뒤집으면 잘린 PDF와 돌아간 PDF에서 어긋나요. 그린 것과 같은 viewport로 바꾸면 셋 다 사라집니다.지난 글에서 react-pdf를 Next.js에 띄우는 데까지 했어요. 띄우고 나면 바로 다음 요구가 오는데요, PDF 위에 박스를 그리고 저장했다가 다시 열었을 때 같은 자리에 보여 달라는 거죠. 이 글에서는 그 박스가 왜 어긋나는지, 무엇을 저장해야 안 어긋나는지 정리해 볼게요.처음 만든 박스는 제자리에 있다가 확대하면 슬금슬금 밀려났어요. 배율 문제를 고치고 나니 이번엔 어떤 PDF에서만 옆으로 비껴났고요. 두 번 다 원인은 좌표를 무엇으로 저장했느냐였어요.좌표계가 두 개예..

2026. 9. 23.
브라우저에서 문서 다루기

pdf.js를 Next.js에 붙이는 방법은 이미 반쯤 바뀌었다

브라우저에서 문서 다루기 #1 — 검색해서 나오는 설정 네 가지 중 셋은 버려도 되고, 하나는 지금도 필요해요. 빈 next.config로 직접 확인해 볼게요.PDF를 웹에서 보여줘야 할 일이 생기면 보통 react-pdf로 갑니다. 그리고 검색을 하면 거의 모든 글이 next.config부터 고치라고 하는데요, 그대로 따라 했다가 오히려 한참 헤맸어요.이 글에서는 그 처방들이 지금도 유효한지 하나씩 확인하고, 왜 그중 하나만 살아남는지 정리해 볼게요. 확인은 빈 설정으로 만든 최소 재현 저장소로 했습니다.검색하면 나오는 네 가지 처방대략 이 넷이 세트로 따라다닙니다.// ① 압축 끄기module.exports = { swcMinify: false }// ② canvas를 빈 모듈로 보내기webpack:..

2026. 9. 23.
에이전트와 일하는 프런트엔드

우리는 우리 속도를 못 잰다

에이전트와 일하는 프런트엔드 #5 — 19% 느려졌다는 그 연구가 1년 뒤 어떻게 됐는지, 그리고 왜 연구팀 본인이 결과를 물렸는지 정리해 볼게요."AI 쓰면 개발자가 19% 느려진대." 이 문장을 올해 몇 번 보셨을 거예요. 출처는 METR이 2025년 7월에 낸 무작위 대조 실험인데요, 저도 한동안 이 숫자를 그대로 인용했습니다.그런데 이 연구는 그 뒤로 두 번 더 움직였어요. 움직인 내용이 원래 결과보다 중요한데요, 이 글에서는 그 19%가 1년 뒤 어떻게 됐는지, 그리고 왜 연구팀이 자기 측정을 물렸는지 정리해 볼게요.널리 인용되는 19%가 어디서 왔는지부터조건을 먼저 보고 가는 게 좋겠어요. 나중에 이야기가 뒤집히는 지점이 전부 이 조건 안에 있거든요.METR은 경험 많은 오픈소스 기여자 16명..

2026. 9. 23.
에이전트와 일하는 프런트엔드

검토를 돕는 도구는 판정하지 않는다

에이전트와 일하는 프런트엔드 #4 — 검토를 돕는 도구가 판정까지 하면 왜 사람이 같이 틀리는지, 측정된 숫자 두 개로 이야기해 보려고 해요.3편은 이렇게 끝냈어요. 에이전트에게 구현은 맡길 수 있어도 판정 기준은 맡길 수 없다.그 글은 에이전트를 쓰는 쪽에서 쓴 거였는데요. 요즘 제가 하는 일은 반대쪽이에요. 사람이 문서를 검토하는 걸 도와주는 시스템을 만들고 있거든요. 그러니까 질문이 이렇게 바뀝니다.판정을 사람이 해야 한다면, 도구는 도대체 뭘 해야 하나?답이 "도구가 1차로 판정하고 사람이 확인한다"인 것 같지만, 이 답에는 측정된 반박이 두 개 있어요. 이 글에서는 그 두 결과를 먼저 보고, 거기서 나오는 프런트엔드 설계 원칙 다섯 개를 정리해 볼게요.AI 교육 20시간으로도 자동화 편향은 안 ..

2026. 9. 22.
에이전트와 일하는 프런트엔드

에이전트가 쓴 테스트는 무엇을 증명하나

에이전트와 일하는 프런트엔드 #3 — 에이전트에게 테스트를 맡기면 왜 동어반복이 나오는지, 측정된 결과와 규제 용어로 정리해 볼게요.지난 글은 이렇게 끝냈어요. 검증 구조를 먼저 갖춘 팀만 에이전트를 제대로 쓸 수 있다.쓰고 나서 스스로 이런 생각이 들었는데요. 그럼 그 검증 구조도 에이전트한테 만들게 하면 되는 거 아닌가? 테스트 짜는 건 에이전트가 제일 잘하는 일처럼 보이거든요.안 돼요. 그리고 안 되는 이유가 취향 문제가 아니라 측정되어 있습니다.버그 있는 코드를 주면, 테스트가 버그를 정답으로 박제해요토론토대 연구진이 올해 7월에 낸 결과예요. Defects4J v3.0의 실제 결함 233건, 함수 318개를 놓고, 모델 11개(Gemini · Claude · Grok · GPT · DeepSee..

2026. 9. 22.
에이전트와 일하는 프런트엔드

AI가 쓴 코드, 누가 책임지나

에이전트와 일하는 프런트엔드 #2 — AI가 쓴 코드의 책임을 규제는 어떻게 다루고 있는지, 적용 범위를 뭉개지 않고 정리해 볼게요.유럽 GMP 부속서 초안에 이런 취지의 문장이 들어갔어요. GMP에 중요한 결정은 "정적이고 결정론적인(static, deterministic)" 모델만 내릴 수 있다. 동적 모델, 생성형 AI, 대규모 언어 모델은 중요 용도에서 제외한다.LLM을 아예 금지한 건 아닌데요. 일탈 보고서 요약, SOP 검색, 정비 메모 초안 같은 중요하지 않은 작업에는 쓸 수 있어요. 단 조건이 붙습니다. 자격 있는 사람이 루프 안에 있어야 하고, 그 사람이 출력물을 검토하며, 문서화된 책임을 집니다.규제기관이 "AI 잘 쓰세요" 같은 덕담이 아니라 규정 문안으로 선을 그은 건 이게 처음이에..

2026. 9. 21.