https://taez224.github.io/ 가든에 공개한 생각 노트. 노트의 기록 날짜를 기준으로 정렬합니다. ko https://taez224.github.io/notes/operator-classification-burden/https://taez224.github.io/notes/operator-classification-burden/ Mon, 05 Oct 2026 15:00:00 GMT생각 노트 사용자를 위한 입력 폼을 만들다 보면 선택지를 많이 제공하는 것이 사용자를 배려하는 일처럼 느껴진다. 하지만 사용자가 원하는 것을 고르는 선택과, 운영자가 처리하기 편하도록 정보를 분류하는 선택은 다르다. 후자를 사용자에게 요구하면 사용자는 전하려던 내용을 입력하기 전에 서비스의 분류 기준부터 이해해야 한다. 선택지가 많지 않더라도 무엇을 골라야 할지 망설이다 입력을 포기할 수도 있다. https://taez224.github.io/notes/verification-not-validation/https://taez224.github.io/notes/verification-not-validation/ Mon, 21 Sep 2026 15:00:00 GMT생각 노트 AI 코딩 도구를 쓰면서 테스트를 작성하고 통과시키는 데 드는 수고가 크게 줄었다. 수정을 요청하면 AI가 관련 테스트를 알아서 만들고, TDD를 요청하면 테스트부터 구현과 리팩터링까지 이어간다. 테스트까지 모두 통과하면 내가 요청한 기능도 완성됐다고 여기기 쉽다. 하지만 테스트 통과는 테스트에 담긴 조건을 만족했다는 뜻일 뿐이다. https://taez224.github.io/notes/delegate-by-skill-to-build/https://taez224.github.io/notes/delegate-by-skill-to-build/ Mon, 07 Sep 2026 15:00:00 GMT생각 노트 같은 작업이라도 결과물을 완성하려는지, 그 과정을 통해 역량을 기르려는지에 따라 AI에 맡길 범위가 달라진다. 자동화 여부는 작업의 명칭이 아니라, 그 과정에서 기르거나 보존하려는 역량으로 판단해야 한다. 나중에 다시 이해할 수 있도록 비문을 다듬는 일은 AI에 맡길 수 있다. 하지만 글쓰기 역량을 기르는 것이 목적이라면 그 다듬는 과정 자체가 남겨야 할 사고가 된다. https://taez224.github.io/notes/gardening-principles/https://taez224.github.io/notes/gardening-principles/ Sun, 06 Sep 2026 15:00:00 GMT생각 노트 이 위키에 노트를 쓰고 고치고 연결하는 기준. https://taez224.github.io/notes/human-agency/https://taez224.github.io/notes/human-agency/ Wed, 19 Aug 2026 15:00:00 GMT생각 노트 판단만으로는 일이 달라지지 않는다. 무엇에 무게를 둘지 알았다고 해도 그 판단이 실제 선택에 반영되지 않으면 처음 정한 방향은 그대로 남는다. Human Agency는 그 판단을 실제 선택으로 옮기고 결과를 책임지는 힘이다. 방향을 바꾸는 것만 그 증거는 아니다. 재질문 끝에 지금 방식을 그대로 쓰기로 한 결정도 같은 증거다. https://taez224.github.io/notes/abstraction-and-resolution/https://taez224.github.io/notes/abstraction-and-resolution/ Thu, 13 Aug 2026 15:00:00 GMT생각 노트 경험을 다른 문제에 다시 쓰려면 추상화가 필요하다. 여러 사건에서 닮은 점을 남기면 새 문제에 쓸 만한 후보를 빨리 찾을 수 있다. 대신 닮은 점을 남기는 동안 이번 선택을 가르는 차이도 함께 빠질 수 있다. 그래서 후보를 찾은 뒤에는 필요에 따라 해상도를 다시 높여야 한다. 여기서 고해상도로 본다는 것은 정보를 가능한 한 많이 모으는 일이 아니다. https://taez224.github.io/notes/taste/https://taez224.github.io/notes/taste/ Thu, 06 Aug 2026 15:00:00 GMT생각 노트 흔히 '취향'이나 '안목'으로 번역되지만, 그것만으로 taste를 다 설명할 수는 없는 것 같다. Andrew Ng이 말한 맥락적 우위에는 내가 직접 쌓은 지식과 경험, 필요할 때 찾아볼 문서와 데이터, 물어볼 사람의 시선이 함께 들어간다. 그중 지금 필요한 것을 꺼내 연결하고 무엇에 더 무게를 둘지 정하는 일. 나는 그게 taste에 가깝다고 생각한다. https://taez224.github.io/notes/hiring-for-judgment/https://taez224.github.io/notes/hiring-for-judgment/ Sun, 26 Jul 2026 15:00:00 GMT생각 노트 코딩 테스트나 AI 리터러시처럼 분리된 대리 지표만으로는 실제 업무 역량을 알기 어렵다. 해당 직무를 대표하는 업무와 환경을 샘플로 만들고, 지원자가 문제에 어떻게 접근하며 결과를 어떻게 검증하고 설명하는지를 봐야 한다. AI 사용은 별도 시험 과목이 아니라, 실제 업무에서 쓰는 도구라면 샘플 업무 환경에 포함할 요소다. https://taez224.github.io/notes/judgment-turns-context-into-criteria/https://taez224.github.io/notes/judgment-turns-context-into-criteria/ Thu, 23 Jul 2026 15:00:00 GMT생각 노트 AI 시대에 taste가 중요하다는 말은 맞다. 다만 taste로 드러나는 판단의 바탕에는 사용자의 상황, 제품의 목적, 팀의 역량, 운영 제약과 실패 비용처럼 AI가 아직 충분히 알지 못하는 맥락상의 우위가 있다. 맥락을 머릿속에만 두어서는 안 된다. 인간의 판단력은 그 맥락을 목표·제약·대표 사례·평가 기준·피드백으로 바꾸고 AI가 실제 실행에 쓸 수 있게 할 때 작동한다. https://taez224.github.io/notes/cherny-five-archetypes/https://taez224.github.io/notes/cherny-five-archetypes/ Sun, 19 Jul 2026 15:00:00 GMT생각 노트 Boris Cherny는 엔지니어·PM·디자이너 같은 직무명보다, 사람들이 실제로 어떤 방식으로 일하는지를 다섯 가지 아키타입으로 설명했다. 한 사람이 하나의 역할에만 머무는 것은 아니며, 상황에 따라 둘 또는 셋의 역할을 함께 맡을 수 있다. Prototyper: 새로운 아이디어를 많이 내고 빠르게 시도한다. 그중 대부분은 실제 제품으로 이어지지 않을 수 있다. https://taez224.github.io/notes/platform-team-ai-foundation/https://taez224.github.io/notes/platform-team-ai-foundation/ Wed, 15 Jul 2026 15:00:00 GMT생각 노트 플랫폼팀은 전사 여러 팀이 함께 사용하는 개발 환경과 배포 경로, 운영 기준을 공통 기반으로 설계해 온 조직이다. AI가 업무의 일부가 된 지금은 이 책임의 범위도 AI 활용까지 확장되어야 한다. 개인이 각자 AI를 탐색하고 실험하는 과정은 필요하다. 그러나 조직의 승인이나 관리 밖에서 AI 도구가 확산되는 Shadow AI는 데이터와 보안, 규정 준수의 위험을 만들 수 있다. https://taez224.github.io/notes/second-brain-supports-first/https://taez224.github.io/notes/second-brain-supports-first/ Tue, 14 Jul 2026 15:00:00 GMT생각 노트 AI를 붙인 세컨드 브레인의 목적은 폴더·형식·중복 확인·검색 후보처럼 기록을 포기하게 만드는 운영 부담을 줄이는 데 있다. 세컨드 브레인은 퍼스트 브레인의 기억과 사고를 보조해야지, 무엇이 중요하고 무엇을 내 지식으로 남길지까지 대신 결정해서는 안 된다. https://taez224.github.io/notes/agent-guidance-boundaries/https://taez224.github.io/notes/agent-guidance-boundaries/ Sun, 12 Jul 2026 15:00:00 GMT생각 노트 에이전트 지침의 규칙에는 성격이 다른 두 종류가 섞여 있고, 수명이 서로 다르다. 승인 경계는 사용자 권한과 책임의 문제다. 핵심은 매번 같은 문구나 절차를 유지하는 것이 아니라, 누가 어떤 결정을 어느 범위까지 승인·위임했는지를 보존하는 데 있다. https://taez224.github.io/notes/essential-vs-accidental-complexity/https://taez224.github.io/notes/essential-vs-accidental-complexity/ Sun, 12 Jul 2026 15:00:00 GMT생각 노트 소프트웨어의 복잡성은 문제와 도메인 자체에서 오는 본질적 복잡성과, 도구·구현 방식·반복 작업에서 생기는 부수적 복잡성으로 나눠볼 수 있다. 부수적 복잡성은 우발적 복잡성(accidental complexity)이라고도 부른다. 부수적 복잡성을 본질적인 것처럼 방치하면 개선 기회를 놓친다. https://taez224.github.io/notes/ai-generates-i-verify/https://taez224.github.io/notes/ai-generates-i-verify/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 내게 맞는 AI 분업은 생성의 일부를 AI에 맡기고 검증 책임은 내가 유지하는 방식이다. 나는 무언가를 만들면서 동시에 의심하고 다듬는 성향이 강하다. AI가 초안 생성을 맡으면 나는 결과를 평가하고 허점을 찾는 역할에 더 집중할 수 있다. 이 분업은 누구에게나 통하는 보편 처방이 아니다. AI가 만든 결과를 설명하고 반례를 찾고 직접 검증할 수 있어야 성립한다. https://taez224.github.io/notes/delegate-by-task/https://taez224.github.io/notes/delegate-by-task/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 한 사람의 역량과 자신감은 영역마다 독립적으로 쌓인다. 한 업무에 숙련되었다고 해서 다른 업무에서도 같은 수준의 판단력과 자신감을 갖추고 있는 건 아니다. 위임이나 신뢰의 범위를 정할 때는 "이 사람을 얼마나 믿는가"가 아니라 "이 사람이 이 업무를 얼마나 해봤는가"를 물어야 한다. https://taez224.github.io/notes/drafts-need-divergence/https://taez224.github.io/notes/drafts-need-divergence/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 아이디어를 만드는 사람과 그걸 다듬는 사람이 한 사람이면, 다듬는 본능이 만드는 도중에 끼어들기 쉽다. 초안이 채 나오기도 전에 "이게 말이 되나"를 검열하기 시작하면, 정작 나왔어야 할 다른 선택지들은 떠오르지도 못한 채 사라진다. 발산과 수렴은 순서가 있는 별개의 단계이지, 동시에 돌아가는 하나의 과정이 아니다. 해법은 의지로 참는 게 아니라 규칙으로 강제하는 것이다. https://taez224.github.io/notes/individual-absorptive-capacity/https://taez224.github.io/notes/individual-absorptive-capacity/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 경영학에서 흡수 역량은 주로 조직이 외부 지식의 가치를 알아보고, 내부 상황에 맞게 소화해 실제 성과에 활용하는 능력을 뜻한다. AI 시대에는 이 역량을 개인 수준에서도 봐야 한다. AI를 통해 한 사람이 과거에는 여러 사람이 나눠 하던 탐색·분석·초안 작성·실행을 빠르게 이어갈 수 있게 됐기 때문이다. 개인에게 AI가 내놓은 답은 우선 외부에서 들어온 지식처럼 다뤄야 한다. https://taez224.github.io/notes/my-burnout-signals/https://taez224.github.io/notes/my-burnout-signals/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 내 HEXACO 결과에서는 불안이 낮아졌지만, 이것만으로 소진이 없다고 판단할 수는 없다. 내 번아웃은 초조함보다 하던 개선 제안이 줄고, 문제를 봐도 "어차피 그런 거지"라고 넘기며, 회의에서 조용해지는 방식으로 나타날 가능성이 더 크다. 그래서 내 상태를 볼 때는 불안 수치보다 "최근에 뭔가를 더 낫게 만들자고 말한 적이 있는가"가 더 유용한 신호다. https://taez224.github.io/notes/output-as-team-asset/https://taez224.github.io/notes/output-as-team-asset/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 결과물이 팀 경계를 넘을 때, 동료가 근거로 평가할 수 있고(판단 가능성) 시간이 지나도 왜 그런 선택을 했는지 따라갈 수 있고(추적 가능성) 잘못됐을 때 알아채고 되돌릴 수 있어야(복구 가능성) 비로소 팀의 지식이 된다. 셋 중 하나라도 없으면, 형식은 팀 안에 들어왔어도 실제로는 여전히 개인(또는 도구)에게 기대야 하는 의존성으로 남는다. https://taez224.github.io/notes/sparring-with-ai/https://taez224.github.io/notes/sparring-with-ai/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 AI는 맡긴 결과물을 만드는 도구이자, 질문과 반론을 주고받으며 아직 모양이 잡히지 않은 생각을 끌어내고 다듬는 상대다. 이때 목적은 대화를 오래 이어가거나 완벽한 결론을 내는 것이 아니다. 대화가 끝났을 때 내가 납득할 수 있는 하나의 주장을 내 말로 간결하게 남기면 충분하다. 같은 과업 안에서도 위임과 스파링은 오간다. AI의 답을 결과물로 받아들이면 위임에 가깝다. https://taez224.github.io/notes/system-over-willpower/https://taez224.github.io/notes/system-over-willpower/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 기준은 높은데 그 기준을 지킬 의지나 습관이 따라주지 않을 때, "더 부지런해지자"는 처방은 보통 실패한다. 기준 자체를 낮추는 대신, 그 기준을 자동으로 지켜주는 도구나 규칙을 만드는 쪽이 실제로 작동하는 전략이다. 완성도에는 예민하지만 정리·정돈에는 무관심한 조합에서 흔히 나타난다. https://taez224.github.io/notes/workslop-is-structural/https://taez224.github.io/notes/workslop-is-structural/ Sat, 11 Jul 2026 15:00:00 GMT생각 노트 AI를 쓰라는 압박이 위에서 모호하게 내려오고, 이미 과부하인 실무자가 그 압박을 받아내면서 저품질 산출물이 늘어난다. 이걸 받은 사람은 보낸 사람의 게으름이나 무능을 탓하기 쉽다. 그러나 저품질 산출물을 개인의 태도만으로 환원하면 AI 도입 압박과 실무자 과부하가 만나는 구조를 놓친다. 판단 오류 자체는 새롭지 않다. 새로운 건 AI 도입 압박이라는, 이 오류가 작동할 새로운 무대다. https://taez224.github.io/notes/ai-capability-is-recovery-rate/https://taez224.github.io/notes/ai-capability-is-recovery-rate/ Fri, 10 Jul 2026 15:00:00 GMT생각 노트 AI 활용도를 볼 때 생성량보다 회수율을 보고 싶다. 회수율은 AI가 만든 산출물이 팀 안에서 다시 쓸 수 있는 자산으로 얼마나 바뀌었는지를 보는 기준이다. 더 나은 코드가 남았는가. 더 정확한 테스트가 남았는가. 더 명확한 설계 판단이 남았는가. 다음 사람이 이해할 수 있는 문서가 남았는가. 다음 문제를 풀 단서가 팀 안에 남았는가. https://taez224.github.io/notes/capture-vs-promotion/https://taez224.github.io/notes/capture-vs-promotion/ Fri, 10 Jul 2026 15:00:00 GMT생각 노트 생각을 포착하는 단계와 영구 노트로 승격하는 단계는 목적이 다르다. 포착은 속도와 원형 보존이 중요하다. 승격은 재사용 가능성, 맥락, 다른 노트와의 관계를 판단해야 한다. 두 단계를 합치면 짧은 생각을 기록할 때마다 완성도를 고민하느라 포착을 미루거나, 반대로 검토되지 않은 메모가 Slipbox에 쌓인다. https://taez224.github.io/notes/friction-by-risk/https://taez224.github.io/notes/friction-by-risk/ Fri, 10 Jul 2026 15:00:00 GMT생각 노트 AI를 단순한 코드 생성기로 쓰면 부채가 쌓인다. AI를 사고의 파트너로 쓰면 부채를 상환 가능한 학습 자산으로 바꿀 수 있다. 차이는 속도가 아니라 마찰의 설계에 있다. 좋은 AI 활용에는 일부러 불편한 순간이 필요하다. 다만 모든 변경에 같은 무게의 마찰을 붙이면 그 자체가 새로운 비용이 된다. 중요한 것은 위험도에 맞게 마찰의 강도를 조절하는 것이다. https://taez224.github.io/notes/good-tech-reduces-friction/https://taez224.github.io/notes/good-tech-reduces-friction/ Fri, 10 Jul 2026 15:00:00 GMT생각 노트 좋은 기술은 도구와 기능을 더 많이 쌓는 데서 그치지 않고, 기존의 복잡성을 줄여 작업 흐름을 일관되게 만든다. 기능 수보다 그 기술을 쓰는 과정에서 불필요한 마찰이 실제로 줄었는지가 가치 판단의 기준이 된다. 플랫폼 팀의 목표를 설명하며 나온 문장이지만, 도구와 프로세스 전반에 적용 가능한 원칙이다. 기능을 계속 추가하는 방향의 개발은 오히려 선택지와 운영 부담을 늘릴 수 있다. https://taez224.github.io/notes/learning-speed-sets-pace/https://taez224.github.io/notes/learning-speed-sets-pace/ Fri, 10 Jul 2026 15:00:00 GMT생각 노트 기술 위에 문화가 없으면 시스템은 쉽게 고립된다. 혁신의 속도를 가르는 건 얼마나 최신 기술을 쓰느냐가 아니라, 조직 안에서 사람들이 얼마나 빠르게 배우고 그 배움을 공유하느냐다. 문서화와 피드백, 경험 공유가 일상화될 때 집단지능이 살아난다. AI 시대 플랫폼 팀의 역할을 설명하며 나온 문장이지만, 특정 조직 형태에 국한된 이야기는 아니다. https://taez224.github.io/notes/notes-for-future-retrieval/https://taez224.github.io/notes/notes-for-future-retrieval/ Fri, 10 Jul 2026 15:00:00 GMT생각 노트 좋은 제텔카스텐 영구 노트는 지금의 내용을 잘 정리하는 데서 끝나지 않는다. 미래의 내가 어떤 상황에서 왜 이 노트를 찾을지 생각하고, 그때 떠올릴 표현과 다른 노트에서 접근할 경로를 함께 남겨야 한다. 회의록이나 일간 기록처럼 애초에 재사용을 전제하지 않는 노트에는 해당하지 않는다. https://taez224.github.io/notes/skill-floor-relationship-ceiling/https://taez224.github.io/notes/skill-floor-relationship-ceiling/ Fri, 10 Jul 2026 15:00:00 GMT생각 노트 기술적 기반은 성과의 하한선(floor)을 높인다. 안정적인 인프라와 도구는 최소한의 효율과 안전망을 보장한다. 하지만 진정한 성장은 상한선(ceiling)을 끌어올릴 때 일어나고, 그 상한선은 신뢰·공감·동기부여 같은 관계적 요인이 결정한다. 그래서 생산성 향상은 새 도구를 들여오는 데서 시작되지 않는다. 그 도구를 어떤 구조와 심리적 토양 위에서 쓰는가가 더 중요하다.