codex에게 대용량 코드베이스를 인식 시키는 방법은 어떤게 있나요?

안녕하세요 박현준님,좋은 질문입니다. 실제 대용량 코드베이스에서 Codex를 쓸 때 가장 많이 부딪히는 부분이 바로 이 지점입니다.결론부터 말씀드리면, 10만 개 이상의 Java 파일을 한 번에 모두 컨텍스트에 넣어서 Codex가 전체를 “통째로 이해하게” 만드는 방식은 현실적으로 어렵습니다 ㅎㅎ. 그리고 실무에서도 (최소한 저는) 보통 그렇게 사용하지 않습니다.대신 작업 단위를 작게 나누고, 필요한 범위의 코드만 점진적으로 읽히면서 진행합니다. 예를 들어 “전체 시스템을 이해해줘”가 아니라 “이 API가 호출되는 흐름을 찾아줘”, “이 클래스가 어디서 사용되는지 추적해줘”, “이 모듈에서 validation 로직을 수정해줘”처럼 범위를 좁혀서 접근합니다. 아니면 파일을 제시하고 거기에 질문을 하시면 됩니다.AGENTS.md도 모든 폴더마다 만드는 것이 정답은 아닙니다. 자바 프로젝트처럼 depth가 깊고 파일 수가 많은 경우에는 각 폴더마다 문서를 유지하는 방식이 오히려 관리 비용이 커질 수 있습니다. 보통은 루트에 공통 AGENTS.md를 두고, 정말 중요한 모듈이나 규칙이 다른 영역에만 추가로 두는 방식이 더 현실적입니다.AGENTS.md에는 소스 코드 전체 설명을 넣기보다는 다음과 같은 “작업 규칙”을 넣는 것이 좋습니다.프로젝트 빌드 방법테스트 실행 방법패키지 구조의 큰 방향코딩 컨벤션(여기에 예를 주시면 좋습니다)수정 전 반드시 확인해야 하는 파일PR 작성 기준건드리면 안 되는 영역자주 쓰는 명령어즉 AGENTS.md는 코드 전체의 최신 요약본이라기보다, Codex가 이 저장소에서 작업할 때 따라야 하는 가이드에 가깝습니다.그리고 실제로는 Codex에게 코드 탐색을 시키면서 필요한 정보를 찾게 합니다. 예를 들어 Java 프로젝트라면 클래스명, 메서드명, 인터페이스 구현체, import, 호출 관계를 검색하게 하고, 관련 파일을 읽은 뒤 수정하게 하는 식입니다. 사람이 IDE에서 “Find Usage”나 “Go to Implementation”을 쓰는 것과 비슷하게, Codex도 한 번에 모든 것을 기억하는 것이 아니라 필요한 순간에 찾아가면서 작업하게 만드는 방식입니다.대용량 코드베이스에서는 특히 다음 흐름이 좋습니다.먼저 작업 목표를 아주 구체적으로 준다.Codex에게 관련 파일과 호출 흐름을 먼저 조사하게 한다.바로 수정하지 말고 수정 계획을 먼저 설명하게 한다.영향 범위가 맞는지 확인한 뒤 수정하게 한다.관련 테스트만 먼저 실행한다.마지막에 전체 빌드나 더 넓은 테스트를 돌린다.예를 들면 이런 식입니다.“이 프로젝트 전체를 분석해줘”보다는,“OrderService에서 주문 취소 시 재고 복구가 어디서 처리되는지 찾아줘. 관련 클래스와 호출 흐름을 먼저 정리하고, 아직 코드는 수정하지 마.”처럼 요청하는 것이 훨씬 효과적입니다.그 다음에,“방금 찾은 흐름을 기준으로, 취소 사유가 SOLD_OUT인 경우에는 재고 복구를 하지 않도록 수정 계획을 먼저 작성해줘. 테스트 대상도 같이 제안해줘.”처럼 단계적으로 진행하는 방식입니다.정리하면, 대용량 코드베이스에서 중요한 것은 “전체를 한 번에 컨텍스트에 넣는 것”이 아니라 “필요한 코드를 잘 찾게 하는 구조와 프롬프트”입니다. AGENTS.md는 그중 하나의 보조 장치이고, 모든 폴더에 억지로 만들 필요는 없습니다. 루트 중심으로 공통 규칙을 관리하고, 정말 복잡하거나 독립적인 모듈에만 추가하는 정도가 현실적입니다.답변이 도움이 되었으면 좋겠습니다. 그리고 정말 좋은 질문 감사합니다.

Replit UI 변경으로 인한 실습 진행 문의

안녕하세요 김은주님,네, 전혀 문제 없습니다.다만 기존 강의와 현재 환경이 조금 달라진 부분이 있어서, 수강하시는 데 불편함이 없도록 관련 내용을 이번에 업데이트했습니다. 특히 Visual Studio Code 환경에서 어떻게 동일하게 따라 할 수 있는지에 대한 영상도 새로 추가해 두었으니 참고해 주시면 됩니다.강의 진행에는 큰 지장이 없으니 편하게 학습하셔도 됩니다.감사합니다.

클로드코드의 서브에이전트 메모리 전략

안녕하세요 유준모님,좋은 질문입니다. 자세한 내용은 https://code.claude.com/docs/en/sub-agents에 답변이 되어 있지만, 간단하게 말씀드리자면 다음과 같습니다. 그리고 질문 주신 게 사실 두 가지가 살짝 섞여 있어서 나눠서 말씀드릴게요.먼저 서브에이전트도 메인이 읽는 CLAUDE.md 계층(~/.claude/CLAUDE.md 글로벌 + 프로젝트 + CLAUDE.local.md)을 그대로 상속받아 로드합니다. 그러니까 "단일 에이전트만 파일시스템 쓰고 서브에이전트는 안 쓴다"가 아니라, 똑같이 받아요. 다만 각 호출은 매번 fresh context로 시작하기 때문에 메인 대화 히스토리나 이미 읽은 파일은 못 봅니다. (예외로 내장 Explore/Plan만 속도 때문에 CLAUDE.md를 건너뜁니다.)그리고 질문하신 "글로벌/프로젝트/로컬 단위로 메모리를 어떻게 관리하냐"는 건 세션을 넘어 누적되는 영구 메모리 얘기인데, 이게 frontmatter의 memory 필드로 정확히 정해져 있어요 (v2.1.33부터). scope가 딱 세 개라서 말씀하신 구분과 그대로 맞아떨어집니다:memory: user → ~/.claude/agent-memory// (글로벌, 모든 프로젝트 공통)memory: project → .claude/agent-memory// (프로젝트 특화, git으로 팀 공유)memory: local → .claude/agent-memory-local// (프로젝트 특화지만 git 제외)이걸 켜면 해당 폴더의 MEMORY.md(앞 200줄/25KB까지)가 system prompt에 자동으로 들어가고, Read/Write/Edit도 자동 활성화돼서 에이전트가 스스로 메모리를 읽고 갱신합니다. 단일 에이전트의 CLAUDE.md랑 똑같이 파일시스템 기반인데, 에이전트별로 격리된 폴더를 갖는다는 점만 다른 거죠."정해진 게 없어서 알아서"가 아니라 명확히 규약이 있다고 보시면 됩니다. 보통은 project를 기본으로 쓰시고, 메모리가 알아서 잘 안 채워지는 편이라 프롬프트에 "끝나면 배운 거 메모리에 저장해" 정도를 박아두면 효과 좋습니다.ㅎㅎ 그리고 강의가 마음에 드셨다면 좋은 리뷰 꼭 부탁드리겠습니다!

AI Agent를 섞어 쓸 때 설정 파일 관리 질문입니다!

안녕하세요 Staty님,중요한 질문 잘 하신 것 같습니다!실무에서는 아직 완전히 표준화된 방식이 있다고 보기는 어렵습니다. 그 이유는 회사마다 다른 정책이 있고 써야되는 Model들이 정해져 있어서요. 다만 제가 본 팀들은 보통 AI Agent별 설정을 모두 Git에 포함시키기보다는, 공통 규칙과 프로젝트 컨텍스트를 먼저 공유하고 Agent별 설정은 최소화하는 방향을 선호합니다.예를 들어 다음과 같이 관리하는 경우가 많습니다.프로젝트 공통 규칙docs/specs/README.mdAGENTS.md 또는 CONTRIBUTING.mdAgent별 설정.codex/.claude/공통적으로 알아야 할 내용(아키텍처, 코딩 규칙, 배포 방식, PR 정책 등)은 Git으로 관리되는 문서에 두고, Codex와 Claude는 그 내용을 읽어가도록 구성합니다. 이유는 Agent가 바뀌더라도 프로젝트 지식은 그대로 유지되기 때문입니다. 만약 모든 규칙을 .codex, .claude 안에 각각 복사해두면 시간이 지나면서 내용이 서로 달라지는 문제가 자주 발생합니다.그래서 제가 추천하는 방식은:프로젝트 공통 지식은 Git으로 관리Agent별 디렉터리에는 해당 Agent만 필요한 설정만 저장가능한 한 중복 규칙은 만들지 않기입니다.실제로 저도 개인적인 프로젝트로는 Codex와 Claude를 같이 사용하는 경우에는 프로젝트 루트에 공통 문서를 두고, 각 Agent 설정은 최소한으로 유지하는 편입니다. Agent는 바뀔 수 있지만 프로젝트 지식은 남아야 하기 때문입니다.아직 인더스트리에 기준이 성숙해지지 않아서, 제가 100% 확신은 못 드리지만 현재 사용하는 방법을 공유해 드렸습니다.

시스템 아키텍처를 강의에 나온 것 처럼 그리고 싶은데 공유 가능할까요?

안녕하세요 hollla03님,특별한 프롬프트를 사용한 것은 아닙니다. 😊보통 저는 먼저 Codex에게 "제가 만들고 싶은 앱의 아키텍처를 설계해줘" 또는 "시스템 디자인 플랜을 만들어줘"라고 요청해서 전체 구조를 정리해서 PLAN.md 파일로 적어줘라고 합니다그 다음에 나온 결과를 바탕으로:React FrontendDjango BackendPostgreSQLRedisJWT 인증AWS 배포처럼 사용 기술을 구체적으로 추가한 뒤,"위 내용을 기반으로 시스템 아키텍처 다이어그램을 그려줘"라고 ChatGPT에 요청하면 강의에서 보신 것과 비슷한 형태의 아키텍처 그림을 생성할 수 있습니다.중요한 것은 그림을 그리는 프롬프트 자체보다, 먼저 어떤 기능과 구조를 원하는지 아키텍처 플랜을 충분히 만드는 것입니다. 그 후 다이어그램 생성은 ChatGPT가 비교적 쉽게 해주는 편입니다. 🙂

안녕하세요. 실습 관련해서 여쭤볼 것이 있습니다.

안녕하세요 양키님,좋은 질문 감사합니다.강의 중간에 이론 설명이 꽤 들어가는 이유는 단순히 명령어만 따라 치는 것보다 "왜 이렇게 동작하는지"를 이해해야 이후 실습이나 실무에서 응용하기 쉽기 때문입니다. 그래서 일부 섹션은 이론을 먼저 설명한 뒤, 뒤쪽에서 해당 내용을 실제로 실습하는 형태로 구성되어 있습니다. 😊처음 수강하실 때는 모든 내용을 완벽하게 따라 하려고 하기보다는 개념 설명 구간에서는 흐름을 이해하는 데 집중하시고, 실습 파트가 나오면 그때 직접 따라 해보시는 것을 추천드립니다.만약 "갑자기 실습이 시작된 것 같다"는 느낌이 드신다면, 아마 앞에서 설명한 개념이 실제 환경에서 어떻게 적용되는지를 바로 보여드리는 과정 때문일 수 있습니다. 강의는 개념 → 실습 → 개념 → 실습 형태로 반복되도록 구성되어 있습니다.처음 한 번은 전체 흐름을 가볍게 보시고, 두 번째 볼 때 직접 따라 하시면 훨씬 이해가 잘 되실 거예요. 수강하시다가 특정 강의에서 어떤 부분이 연결되지 않는지 알려주시면 더 자세히 설명드리겠습니다.한번에 이해가는게 아니라 여러번 실습하고 이론하면서 익히셔야합니다.

session이 점점 길어지면 어떻게 대처하나요?

안녕하세요. 체화영 Robby님,좋은 질문 감사합니다1. Context가 거의 다 찼을 때 계속 압축(Compaction)하면서 사용해도 될까요?기본적으로는 가능합니다.Codex는 Context Window가 부족해지면 자동으로 이전 대화 내용을 요약(Compact)하여 계속 작업을 이어갈 수 있도록 설계되어 있습니다. 따라서 논리적으로 연결된 작업이라면 같은 세션에서 계속 개발하셔도 큰 문제는 없습니다.다만 압축 과정에서 일부 세부 정보가 요약될 수 있기 때문에, 최근에 논의한 내용이나 중요한 의사결정 사항이 있다면 별도로 관리하는 것을 추천드립니다.제가 강의에서 설명 드렸던 거 같은데, 예를 들어,프로젝트 요구사항(MD 파일)아키텍처 결정 사항(ADR)작업 TODO 목록에이전트 규칙(RULES.md)등을 디렉토리별이나 파일로 관리해두면 새로운 작업 시에도 안정적으로 이어갈 수 있습니다(그거 다시 읽어달라고 하면 됩니다)또한 Hook 기능을 활용하여 작업 결과를 자동으로 파일에 기록하거나, 중요한 문서를 세션 시작 시 다시 읽도록 구성하는 것도 좋은 방법입니다(제가 강의 뒤쪽에 설명 드려놨습니다)2. 새 세션을 만들면 이전 세션 내용을 모두 기억하나요?아닙니다.새로운 세션은 기본적으로 이전 세션의 대화 내용을 자동으로 기억하지 않습니다.즉, "새 세션을 열었으니 Codex가 이전 작업을 모두 알고 있을 것이다" 라고 가정하고 개발하시면 안 됩니다. 새 세션은 현재 Repository 상태와 현재 읽은 파일들(예를들어 AGENTS.md)을 기반으로 판단합니다.3. 이전 세션의 중요한 내용을 새 세션에서 이어서 사용하는 방법은?실무에서는 보통 다음 방법을 사용합니다.방법 1. 프로젝트 문서화예를 들어PROJECT.mdARCHITECTURE.mdTASKS.mdRELEASE.md같은 파일에 중요한 의사결정 사항을 기록합니다.새 세션 시작 시 "먼저 PROJECT.md와 TASKS.md를 읽고 현재 상태를 파악해줘"라고 하면 이전 작업 맥락을 상당 부분 복원할 수 있습니다.방법 2. Hook 활용Hook을 사용하여사용자 요청에이전트 결과주요 결정 사항을 자동 저장하도록 구성할 수 있습니다.이후 새 세션에서 해당 로그를 다시 읽어 작업을 이어갈 수 있습니다(제 훅 강의에서 설명했던 거 같은데... 아마 맞을 겁니다 ㅎㅎ)방법 3. Session Handoff 문서 생성개인적으로 가장 추천하는 방법입니다.작업 종료 전에 "다음 세션을 위한 Handoff 문서를 작성해줘" 라고 요청하여현재 진행 상황완료된 작업남은 작업주의사항다음 액션을 정리한 MD 파일을 생성합니다(이것도 제가 강의에서 설명 드려놨습니다 ㅎㅎ)새 세션에서는 해당 파일만 읽어도 이전 작업의 맥락을 거의 복원할 수 있습니다.실제로 장기간 진행되는 프로젝트에서는 Context를 믿기보다는 Repository 안에 상태를 저장하는 방식이 훨씬 안정적입니다.

처음 접하는 문제에서 하이레벨 디자인의 완성도를 높이는 방법이 궁금합니다.

안녕하세요 이재영님,좋은 질문입니다.사실 시스템 디자인 인터뷰에서는 하이레벨 디자인을 한 번에 완벽하게 맞추는 것을 기대하지 않습니다. 오히려 처음에는 70~80% 수준의 설계를 만들고, 딥다이브 과정에서 발견한 문제를 어떻게 보완하는지를 보는 경우가 많습니다.다만 말씀하신 것처럼 익숙하지 않은 도메인에서 하이레벨 설계가 흔들리는 경우에는 몇 가지 체크리스트를 가지고 접근하면 도움이 됩니다.제가 추천하는 방법은 하이레벨 디자인을 그리기 전에 반드시 아래 질문들을 먼저 스스로 던지는 것입니다.데이터는 어디서 생성되는가?읽기가 많은가, 쓰기가 많은가?실시간성이 중요한가?데이터 크기는 어느 정도인가?장애가 발생하면 무엇이 가장 치명적인가?순서(Ordering)가 중요한가?강한 일관성(Strong Consistency)이 필요한가?글로벌 서비스인가, 단일 리전 서비스인가?대부분의 시스템은 결국... Client → API → Processing Layer → Storage → Cache/Search 라는 공통 패턴 안에서 움직이기 때문에, 위 질문에 대한 답만 정리해도 필요한 컴포넌트가 상당 부분 자연스럽게 드러납니다.또 하나의 팁은 하이레벨 디자인 단계에서 "설계"보다 "리스크 목록"을 먼저 만드는 것입니다.예를 들어 X를 설계한다고 하면Fan-out 문제Celebrity ProblemTimeline 정렬Hot Partition캐시 무효화같은 리스크를 먼저 적고 시작합니다(여기는 여러 시스템 디자인를 접해보는게 좋습니다) 그러면 하이레벨 설계가 해당 리스크들을 해결하는 방향으로 자연스럽게 발전하게 됩니다.그리고 인터뷰 중에 딥다이브하다가 설계 오류를 발견해서 하이레벨로 다시 올라가는 것은 오히려 좋은 신호일 수 있습니다.예를 들어 "지금까지는 단일 DB로 설명했는데, 읽기 트래픽 규모를 고려하면 이 부분은 샤딩이 필요하겠습니다." 처럼 명시적으로 수정 이유를 설명하면 인터뷰어는 "이 사람이 설계를 검증하면서 진행하는구나" 라고 받아들이는 경우가 많습니다 ㅎㅎㅎ (그래서 제 생각에는 좋은 듯)실제 FAANG 계열 인터뷰에서도 처음 설계를 끝까지 고수하는 것보다, 새로운 정보가 나오면 설계를 업데이트하는 능력을 더 높게 평가하는 경우가 많습니다.개인적으로는 처음 보는 문제를 만났을 때, 요구사항 → 트래픽 추정 → 병목 예상 → 리스크 목록 작성 → 하이레벨 디자인 순서로 접근하는 연습을 추천드립니다.하이레벨 디자인은 결국 "컴포넌트를 그리는 과정"이 아니라 "어떤 리스크를 해결할 것인가를 표현하는 과정"에 가깝기 때문에, 리스크를 먼저 찾는 습관이 생기면 익숙하지 않은 도메인에서도 훨씬 안정적으로 설계할 수 있게 됩니다.그리고 너무 걱정하지 않으셔도 되는 부분이, 시스템 디자인 인터뷰를 많이 본 지원자들의 공통적인 성장 포인트가 바로 말씀하신 "딥다이브하다가 하이레벨을 수정하는 경험"입니다. 그 과정을 반복하면서 처음 보는 문제도 점점 더 빠르게 구조화할 수 있게 됩니다. 🙂

선생님 질문이 있어요

안녕하세요 adele lee님,좋은 질문입니다 😊결론부터 말씀드리면 올라마(Ollama)는 '실행기'이고, 허깅페이스(Hugging Face)는 '모델 저장소(모델 마켓)'에 가깝습니다.예를 들어:Ollama = 넷플릭스 앱Hugging Face = 영화들이 모여있는 영화관/콘텐츠 창고라고 생각하시면 이해가 쉽습니다.우리가 Ollama를 설치하면 LLM을 실행할 수 있는 환경이 생기지만, 실제로 어떤 모델을 사용할지는 별개의 문제입니다.예를 들어:Llama 3QwenGemmaMistralDeepSeek같은 모델들은 대부분 Hugging Face에 공개되어 있습니다.그래서 AI 개발자들은 새로운 모델이 나오면 먼저 Hugging Face에서 확인하는 경우가 많습니다.강의에서 Hugging Face를 설명드리는 이유는:세상에 어떤 LLM 모델들이 있는지 이해하기 위해모델 성능, 크기, 라이선스를 확인하기 위해나중에 Ollama에 없는 모델도 직접 받아서 사용할 수 있기 때문에현재 AI 생태계의 GitHub 같은 역할을 하는 곳이기 때문입니다.질문 주신 것처럼"허깅페이스가 있어서 우리가 LLM을 쓸 수 있게 된 건가요?"는 정확히는 아닙니다.하지만 현재 오픈소스 AI 생태계에서 Hugging Face는 거의 표준 플랫폼이 되었고, 수많은 LLM 모델들이 Hugging Face를 통해 배포되고 공유되고 있습니다.그래서 "LLM을 실행하는 도구는 Ollama", "LLM을 찾고 비교하고 다운로드하는 곳은 Hugging Face" 정도로 이해하시면 됩니다.개발자가 아니시더라도 앞으로 AI를 공부하시다 보면 "이 모델은 Hugging Face에 올라와 있습니다"라는 말을 정말 자주 보시게 될 거라서 기본 개념 정도는 알아두시면 많은 도움이 됩니다 😊

airflow 3로 되면서 2.x대에 지원 중단된 패키지가 많네요..ㅠ

맞습니다 ㅠㅠ Airflow 3.x로 오면서 예전 2.x 강의/블로그 코드 중에 deprecated 되거나 import path가 바뀐 것들이 꽤 있습니다.말씀하신 방향이 맞습니다.SimpleHttpOperator -> HttpOperator PostgresOperator -> SQLExecuteQueryOperator다만 코드 구조가 완전히 달라지는 수준은 아니고, 대부분은 Operator 이름과 import 경로, 일부 파라미터 이름을 바꾸는 정도로 대응 가능합니다.예를 들어 Postgres 쪽은 예전에는 이런 식이었다면:from airflow.providers.postgres.operators.postgres import PostgresOperator task = PostgresOperator( task_id="run_sql", postgres_conn_id="postgres_default", sql="sql/my_query.sql", )Airflow 3.x 기준으로는 보통 이렇게 바꿉니다.from airflow.providers.common.sql.operators.sql import SQLExecuteQueryOperator task = SQLExecuteQueryOperator( task_id="run_sql", conn_id="postgres_default", sql="sql/my_query.sql", )핵심 차이는 postgres_conn_id가 아니라 더 일반화된 conn_id를 쓴다는 점입니다. SQLExecuteQueryOperator는 Postgres 전용이라기보다 여러 SQL 계열 DB에서 공통으로 쓰기 위한 Operator라고 보시면 됩니다.HTTP도 비슷합니다.SimpleHttpOperator -> HttpOperator이런 변경은 Airflow가 특정 DB/서비스 전용 Operator를 줄이고, provider/common 계열 Operator로 정리해가는 흐름이라고 보시면 됩니다.주니어 입장에서는 정말 따라가기 힘든 게 맞습니다. Airflow는 특히 core 버전과 provider 패키지 버전이 같이 움직이다 보니, 강의 코드와 현재 설치 버전이 달라지면 import부터 막히는 경우가 많습니다.그래서 실무에서는 보통 이렇게 접근하시면 좋습니다.강의는 전체 구조와 개념을 이해하는 용도로 보기실제 코드는 현재 설치된 Airflow/provider 문서를 기준으로 import 확인하기Operator가 deprecated 되면 “대체 Operator가 무엇인지”만 확인해서 교체하기DAG 구조, task dependency, connection, schedule 개념은 거의 그대로 가져가기즉, 코드 한두 줄이 바뀌었다고 강의 내용이 틀어진 것은 아니고, Airflow 생태계가 버전업되면서 표준 Operator 이름이 정리된 것으로 보시면 됩니다.말씀 주신 부분은 중요한 변경점이라 강의 공지나 보충 자료에 Airflow 3.x 기준 migration 예시를 추가해두겠습니다. 좋은 제보 감사합니다.