긍정적 사고, 음식의 절제, 규칙적인 운동

AI가 교수도 평생 한 번 봤다는 진단(OIH)을 찾아냈습니다 — 환자 의무기록 수만 장을 구조화한 결과 

https://news.hada.io/topic?id=30764

• 
  한국에서 오랜 기간 투병 중인 환자의 의무기록을 제주에서 서울까지 전국 병원에서 대신 발급해, 종이 수만 장을 스캔·OCR·구조화한 뒤 AI로 분석했다.
• 그 과정에서 AI가 OIH(오피오이드 유발 통각과민) 가능성을 제시했고, 담당 교수가 "평생 한 번밖에 못 본 케이스"라며 자신이 놓쳤음을 인정, 척수자극기 수술이 앞당겨졌다.

출발점: 흩어진 기록, 읽지 못하는 환자

• 오래 투병한 환자일수록 자신의 의료 기록을 하나로 통합해 보지 못한다. 기록은 병원마다 흩어져 있고, 전원할 때마다 종이 사본을 떼어 제출하는 방식으로만 흐른다.
• 이번 환자는 후종인대 골화증(OPLL)에 의한 척수병증으로 감압·유합술을 받았으나, 수술 후 통증이 심해지는 FBSS(척추수술 후 통증 증후군)가 발생했다.
• 거쳐 간 병원만 해운대백병원 → 서울대병원 → 부산성모병원, 그리고 교수가 옮겨 간 제주대병원까지. 서울대 한 곳에서만 종이 사본이 천 수백 장이었다.

우리가 한 일: 전국 발급 → 데이터화

• 환자를 대신해 부산·서울·제주에 흩어진 병원 4곳에서 의무기록을 직접 발급받았다. 종이로 수만 장 규모.
• 그 안에는 의사의 진료 노트, 수년치 검사 결과 추이, 수술·약물·행정 서류가 뒤섞여 있었다. 사람이 수만 장을 읽고 시계열로 정렬하는 것은 사실상 불가능하다.

파이프라인: 스캔 → OCR → 구조화 → 시계열 통합

• 스캔으로 디지털화하고, OCR로 손글씨 진료 노트·인쇄 검사지를 텍스트로 추출, 날짜·병원·검사 항목·수치·약물·수술 이벤트를 표준 스키마로 정규화했다.
• 병원 4곳의 기록을 하나의 타임라인으로 합쳐 5년치 longitudinal EMR을 구성. 단일 LLM에 몇 줄 입력하는 것과는 데이터 기반 자체가 다르다.

발견의 순간: 마약성 진통제의 역설

• 환자는 통증으로 마약성 진통제를 썼으나, 용량을 늘려도 통증이 잡히지 않고 오히려 심해지는 비정상 반응을 보였다.
• 이 비전형 경험을 기록과 함께 입력하며 질문을 이어가던 중, AI가 OIH(Opioid-Induced Hyperalgesia, 오피오이드 유발 통각과민)를 제시했다. 환자는 그 전까지 이 개념의 존재 자체를 몰랐다.

결과: 교수가 놓친 것, 그리고 앞당겨진 수술

• 다음 외래에서 교수에게 상의하자 교수는 "나도 평생 한 번밖에 못 본 케이스"라며 자신이 놓쳤음을 인정했다.
• OIH 해석이 서자 마약성 진통제를 줄이고, 척수자극기(SCS) 삽입 필요성에 확신을 얻었으며, 막연히 고려만 하던 수술을 확실히 진행하기로 결정. 정보 제공에서 멈추지 않고 실제 행동의 변화로 이어졌다.

이것이 의미하는 것

• 모델이 똑똑해서가 아니라 데이터 기반이 달라서 가능했던 일이다. 가장 어려운 일은 추론이 아니라 제주에서 서울까지 흩어진 수만 장의 종이를 기계 판독 가능한 하나의 데이터로 만드는 것이었다.

본 사례는 환자 동의 하에 개인 식별 정보를 제거하고 재구성했다. 의학적 판단은 반드시 담당 의료진과 상의해야 한다.

Gemini에서 연결된 앱 사용 및 관리하기

https://support.google.com/gemini/answer/13695044

How to Be a 30x AI Engineer with a Taste( 취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법)

https://pakodas.substack.com/p/how-to-be-a-30x-ai-engineer-with-a-taste

https://news.hada.io/topic?id=30338

https://news.hada.io/topic?id=30263

1. AI 코딩 시대의 변화와 패러다임 전환

• 코드 생성의 상품화: 2025년 말 주요 AI 모델(Opus 4.5, GPT-5.2, Gemini 3 등)이 숙련된 엔지니어 수준의 코드를 수 분 만에 작성하게 되면서, 단순히 코드를 타이핑하는 기술의 가치는 급락했습니다.
• 엔지니어 역량의 재정의: AI가 코드의 대부분을 작성하는 세계에서 엔지니어의 진짜 차별점은 속도가 아니라 문제 분해, 아키텍처 설계, 신뢰성 검증, 트레이드오프 판단을 아우르는 ‘취향(Taste)’으로 이동했습니다.

2. '취향(Taste)'의 3가지 정의

최고의 엔지니어링 팀이 말하는 취향은 결국 '내부 평가 함수의 품질'이 어디로 향하는가에 따라 3가지 형태로 나뉩니다.

• 인식 (Recognition): 어떤 구현이 왜 더 나은지 논리적으로 설명하기 전에, 직관적·패턴 매칭으로 더 깔끔하고 확장 가능한 코드를 식별하는 능력입니다. (예: 팀의 행동 양식을 유도하기 위해 TypeScript 대신 Rust를 선택하는 결정)
• 나침반 (Compass): 무언가를 만들기 전에 '옳은 기능인지 아닌지' 방향을 아는 능력입니다. 수많은 프로토타입을 거치며 임의적이지 않고 필연적인 해법으로 수렴해 나가는 기준이 됩니다.
• 비전 (Vision): 현재가 아니라 2년 뒤에 중요해질 것을 내다보는 능력입니다. 지루한 코드 생성이 아닌, 시스템 설계 및 모델이 소프트웨어의 존재 이유를 이해하도록 만드는 제품 전략에 집중하는 것입니다.

3. 취향이 막대한 가치를 만드는 5가지 영역

4. 나쁜 취향 vs 좋은 취향 (실제 사례 비교)

• 기술 스택 선택: 관습이나 유행에 따라 선택하면 '취향 없음', 모델의 강점(예: Claude 모델이 이미 잘 다루는 분포)이나 구체적인 제약 조건에 근거해 선택하면 '취향 있음'입니다.
• AI 생성 코드 리뷰: AI가 짠 코드를 테스트만 통과했다고 바로 출시하면 '취향 없음', 전체 시스템 구조와 검증 계층(로컬 CI 등)의 정확성을 인지하고 코드보다 '생성 프롬프트(의도)'를 리뷰하면 '취향 있음'입니다.

5. 취향을 기르기 위한 90일 가이드 & 추천 프로젝트

[ 90일 훈련 계획 ]

• 1개월차 (인식 구축): 존경받는 개발자 도구 10개와 기술 논문 10편을 분석하며 첫 60초의 느낌과 우아한 방법론의 통찰을 기록합니다.
• 2개월차 (나침반 구축): 같은 종류의 예시(API 문서, 블로그 등) 두 개를 비교해 왜 하나가 더 나은지 구체적 메커니즘을 밝혀 적는 연습을 합니다.
• 3개월차 (비전 적용): 기존 프로젝트의 온보딩/README를 재설계하고, 모든 아키텍처 결정을 관습이 아닌 제1원칙(First Principles)으로 설명하는 시스템을 설계합니다.

[ 실행해 볼 수 있는 5가지 프로젝트 ]

1. AI 코드 평가 프레임워크 구축: AI가 생성한 PR이 프로덕션에 적합한지 채점하는 자체 루브릭 정의 (품질 판단력 향상)
2. 오픈소스 온보딩 재설계: 타 기여자가 첫날 바로 PR을 보낼 수 있도록 개발자 경험(DX)의 첫 5분을 개선 (사용자 공감 능력 향상)
3. 팀 내 '취향 테스트' 만들기: 엔지니어 간의 의견 불일치 지점을 찾아내어 조직의 표준과 아키텍처 기준을 정렬
4. 48시간 제약 내 제품 출시: 극단적인 시간 제약 속에서 기능을 쳐내고 포함하는 필수적 취향 결정 강제 수행
5. 사고를 바꾸는 기술 블로그 작성: 단순 튜토리얼이 아닌, 독자의 관점을 뒤흔드는 독창적인 시각 공유 (스토리텔링 능력 향상)

💡 결론

AI가 타이핑을 대신해 주면서 엔지니어의 전통적인 '손코딩 상실감'은 현실이 되었습니다. 하지만 어떤 코드가 존재해야 하고, 어떻게 구조화되어야 하며, 언제 충분한지를 아는 '취향'은 언제나 엔지니어링의 본질이었습니다. 앞으로 번창할 엔지니어는 이 취향 중심의 판단력에 경력을 최적화하는 사람입니다.

Claude Code CLI에서 /btw (By The Way) 명령어는 

현재 메인 작업 흐름이나 대화 기록을 오염시키지 않고, 

가벼운 단발성 질문(Side Question)을 병렬로 던질 수 있는 기능입니다.

대규모 리팩토링이나 복잡한 프로젝트 분석 같은 무거운 태스크를 

Claude에게 실행시켜 둔 상태에서 매우 유용하게 활용할 수 있는 내장(Built-in) 커맨드입니다.

claude.md 처럼 분석에 필요한 기본 .md 파일 목록

Claude Code CLI 환경에서 프로젝트를 분석하거나 개발을 진행할 때, claude.md(또는 CLAUDE.md) 외에도 함께 구성해 두면 Claude가 자동으로 조회하여 분석 품질을 극대화할 수 있는 핵심 기본 .md 파일 세트가 있습니다.

제공해주신 파일 관리 및 가이드 가이드라인에 기반하여, 프로젝트 루트 디렉토리에 구축해 두면 가장 좋은 추천 가이드라인 파일 목록과 그 안에 들어갈 핵심 내용을 정리해 드립니다.

📂 Claude CLI 분석 효율을 극대화하는 4대 기본 .md 파일 목록

1. claude.md (또는 CLAUDE.md) - 프로젝트 개발 마스터 지침서

Claude Code CLI가 실행될 때 가장 먼저 찾아서 컨텍스트에 주입하는 가장 중요한 마스터 파일입니다.

• 핵심 포함 내용:
  • 프로젝트 실행, 빌드, 테스트, 배포를 위한 실제 터미널 명령어 명시 (npm run dev, mvn spring-boot:run 등)
  • 이 프로젝트에서 엄격하게 준수해야 하는 코딩 스타일 및 네이밍 규칙 (예: "자바스크립트는 CamelCase 준수, 변수명은 명사형으로 작성")
  • 필수 예외 처리 방식 및 프레임워크 제약 조건

2. domain.md - 비즈니스 및 도메인 용어 사전

프로젝트의 기획적 배경, 비즈니스 규칙, 그리고 데이터베이스 설계 시 사용되는 고유 도메인 용어들을 정리해 두는 파일입니다. Claude가 코드를 분석하거나 데이터베이스 사전을 만들 때 엉뚱한 기술 용어 대신 현업에서 쓰는 정확한 용어를 사용하도록 교정해 줍니다.

• 핵심 포함 내용:
  • 용어 매핑 정의: 예) 현업 용어인 "학원"은 소스 코드와 DB에서 Academy 대신 Institute 또는 School로 통일한다.
  • 도메인 특화 규칙: 예) "회원 구분값은 1: 정회원, 2: 준회원, 3: 탈퇴회원으로 고정한다."
  • 서비스의 주요 비즈니스 도메인 범위 및 타겟층 요약

3. architecture.md (또는 system.md) - 아키텍처 및 시스템 구조 정의서

프로젝트의 전반적인 기술 스택, 폴더 구조, 데이터 흐름을 정의해 두는 파일입니다. Claude가 소스 코드를 읽기 전에 전체 지도를 먼저 파악하게 하므로, 방대한 양의 소스 코드를 분석할 때 기술적 오판을 방지해 줍니다.

• 핵심 포함 내용:
  • 기술 스택 일람: 언어 버전(Node 18+, JDK 17 등), 프레임워크(Spring Boot 3.x, Next.js 14 등), 데이터베이스(MySQL, Redis 등)
  • 디렉토리 가이드: 주요 기능이나 모듈이 어떤 폴더 구조(app/playville, src/main/java 등) 패턴으로 설계되어 있는지 설명
  • 백엔드와 프론트엔드 간의 데이터 교환 패턴 및 외부 연동 API 시스템 목록

4. roadmap.md (또는 tasks.md) - 마일스톤 및 기술 부채 현황판

현재 프로젝트의 개발 진행 상황, 추후 개선해야 할 리팩토링 항목, 혹은 마이그레이션 타스크를 기록해 두는 파일입니다. Claude에게 다음 작업을 지시할 때 "roadmap.md에 적힌 다음 우선순위 작업을 진행해줘"라고 바로 연계할 수 있습니다.

• 핵심 포함 내용:
  • 현재 파악된 기술 부채 및 리팩토링 대상 코드 목록
  • 기획서나 DDL 분석을 통해 도출된 추후 구현 예정 기능 일람
  • 마일스톤별 진행 상황 (Todo / In Progress / Done) 표시

💡 파일 기반 운용을 위한 Claude Code CLI 실무 팁

1. 컨텍스트 자동 동기화: Claude Code CLI는 현재 폴더 내부의 모든 파일 상태를 실시간으로 추적합니다. VS Code 등에서 위의 .md 파일들을 수정한 뒤, 대화창에 /reset 명령어를 입력하면 이전 대화 기록을 깔끔하게 비우면서 방금 수정한 가이드 파일들의 최신 내용을 컨텍스트에 완벽하게 새로고침(Reload) 합니다.
2. Qwen/LLM 프롬프트 파일화 활용: 만약 특정 모델(예: Qwen 등)의 스타일이나 복잡한 프롬프트 가이드를 고정적으로 쓰고 싶다면, 프로젝트 루트에 qwen_guide.md나 prompt_guide.md라는 이름으로 파일을 따로 빼두고, Claude에게 "코드 생성 시 현재 폴더의 prompt_guide.md 규칙을 준수해줘"라고 명령 파일로 사용할 수도 있습니다.

CLAUDE.md

## 역할 정의
- **터미널 A (Master)**: 최종 의사결정권자. B, C, D가 제기한 질문이나 답변 후보 중 가장 적절한 것을 선택하고 승인한다.
- **터미널 B (기획/분석)**: 기획서 분석 및 요구사항 추출 담당.
- **터미널 C (프론트엔드)**: UI/UX 및 클라이언트 로직 담당.
- **터미널 D (백엔드)**: DB 구조 및 API 설계 담당.

## 프로세스 규칙
1. B, C, D는 각자 지정된 프롬프트를 실행하되, 독립적으로 최종 산출물을 쓰지 않고 중간 결과나 마스터의 판단이 필요한 질문을 `interaction_queue.md` 파일에 기록한다.
2. Master(A)는 `interaction_queue.md`를 실시간으로 모니터링하여 검토한 뒤, 최종 답변을 선택하고 승인 코드를 전달한다.