Lead 레벨 · SW 엔지니어
질문&답변
안녕하세요 김은주님, 네, 전혀 문제 없습니다. 다만 기존 강의와 현재 환경이 조금 달라진 부분이 있어서, 수강하시는 데 불편함이 없도록 관련 내용을 이번에 업데이트했습니다. 특히 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 를 기본으로 쓰시고, 메모리가 알아서 잘 안 채워지는 편이라 프롬프트에 "끝나면 배운 거 메모리에 저장해" 정도를 박아두면 효과 좋습니다. ㅎㅎ 그리고 강의가 마음에 드셨다면 좋은 리뷰 꼭 부탁드리겠습니다!
질문&답변
안녕하세요 Staty님, 중요한 질문 잘 하신 것 같습니다! 실무에서는 아직 완전히 표준화된 방식이 있다고 보기는 어렵습니다. 그 이유는 회사마다 다른 정책이 있고 써야되는 Model들이 정해져 있어서요. 다만 제가 본 팀들은 보통 AI Agent별 설정을 모두 Git에 포함시키기보다는, 공통 규칙과 프로젝트 컨텍스트를 먼저 공유하고 Agent별 설정은 최소화하는 방향 을 선호합니다. 예를 들어 다음과 같이 관리하는 경우가 많습니다. 프로젝트 공통 규칙 docs/ specs/ README.md AGENTS.md 또는 CONTRIBUTING.md Agent별 설정 .codex/ .claude/ 공통적으로 알아야 할 내용(아키텍처, 코딩 규칙, 배포 방식, PR 정책 등)은 Git으로 관리되는 문서에 두고, Codex와 Claude는 그 내용을 읽어가도록 구성 합니다. 이유는 Agent가 바뀌더라도 프로젝트 지식은 그대로 유지되기 때문 입니다. 만약 모든 규칙을 .codex, .claude 안에 각각 복사해두면 시간이 지나면서 내용이 서로 달라지는 문제가 자주 발생합니다. 그래서 제가 추천하는 방식은: 프로젝트 공통 지식은 Git으로 관리 Agent별 디렉터리에는 해당 Agent만 필요한 설정만 저장 가능한 한 중복 규칙은 만들지 않기 입니다. 실제로 저도 개인적인 프로젝트로는 Codex와 Claude를 같이 사용하는 경우에는 프로젝트 루트에 공통 문서를 두고, 각 Agent 설정은 최소한으로 유지하는 편입니다. Agent는 바뀔 수 있지만 프로젝트 지식은 남아야 하기 때문입니다. 아직 인더스트리에 기준이 성숙해지지 않아서, 제가 100% 확신은 못 드리지만 현재 사용하는 방법을 공유해 드렸습니다.
질문&답변
안녕하세요 hollla03님, 특별한 프롬프트를 사용한 것은 아닙니다. 😊 보통 저는 먼저 Codex에게 "제가 만들고 싶은 앱의 아키텍처를 설계해줘" 또는 "시스템 디자인 플랜을 만들어줘"라고 요청해서 전체 구조를 정리해서 PLAN.md 파일로 적어줘라고 합니다 그 다음에 나온 결과를 바탕으로: React Frontend Django Backend PostgreSQL Redis JWT 인증 AWS 배포 처럼 사용 기술을 구체적으로 추가한 뒤, "위 내용을 기반으로 시스템 아키텍처 다이어그램을 그려줘" 라고 ChatGPT에 요청하면 강의에서 보신 것과 비슷한 형태의 아키텍처 그림을 생성할 수 있습니다. 중요한 것은 그림을 그리는 프롬프트 자체보다, 먼저 어떤 기능과 구조를 원하는지 아키텍처 플랜을 충분히 만드는 것입니다. 그 후 다이어그램 생성은 ChatGPT가 비교적 쉽게 해주는 편입니다. 🙂
질문&답변
안녕하세요 양키님, 좋은 질문 감사합니다. 강의 중간에 이론 설명이 꽤 들어가는 이유는 단순히 명령어만 따라 치는 것보다 "왜 이렇게 동작하는지"를 이해해야 이후 실습이나 실무에서 응용하기 쉽기 때문입니다. 그래서 일부 섹션은 이론을 먼저 설명한 뒤, 뒤쪽에서 해당 내용을 실제로 실습하는 형태로 구성 되어 있습니다. 😊 처음 수강하실 때는 모든 내용을 완벽하게 따라 하려고 하기보다는 개념 설명 구간에서는 흐름을 이해하는 데 집중하시고, 실습 파트가 나오면 그때 직접 따라 해보시는 것을 추천드립니다. 만약 "갑자기 실습이 시작된 것 같다"는 느낌이 드신다면, 아마 앞에서 설명한 개념이 실제 환경에서 어떻게 적용되는지를 바로 보여드리는 과정 때문일 수 있습니다. 강의는 개념 → 실습 → 개념 → 실습 형태로 반복되도록 구성되어 있습니다. 처음 한 번은 전체 흐름을 가볍게 보시고, 두 번째 볼 때 직접 따라 하시면 훨씬 이해가 잘 되실 거예요. 수강하시다가 특정 강의에서 어떤 부분이 연결되지 않는지 알려주시면 더 자세히 설명드리겠습니다.한번에 이해가는게 아니라 여러번 실습하고 이론하면서 익히셔야합니다.
질문&답변
안녕하세요. 체화영 Robby님, 좋은 질문 감사합니다 1. Context가 거의 다 찼을 때 계속 압축(Compaction)하면서 사용해도 될까요? 기본적으로는 가능합니다. Codex는 Context Window가 부족해지면 자동으로 이전 대화 내용을 요약(Compact)하여 계속 작업을 이어갈 수 있도록 설계되어 있습니다. 따라서 논리적으로 연결된 작업이라면 같은 세션에서 계속 개발하셔도 큰 문제는 없습니다. 다만 압축 과정에서 일부 세부 정보가 요약될 수 있기 때문에, 최근에 논의한 내용이나 중요한 의사결정 사항이 있다면 별도로 관리하는 것을 추천드립니다. 제가 강의에서 설명 드렸던 거 같은데, 예를 들어, 프로젝트 요구사항(MD 파일) 아키텍처 결정 사항(ADR) 작업 TODO 목록 에이전트 규칙(RULES.md) 등을 디렉토리별이나 파일로 관리해두면 새로운 작업 시에도 안정적으로 이어갈 수 있습니다(그거 다시 읽어달라고 하면 됩니다) 또한 Hook 기능을 활용하여 작업 결과를 자동으로 파일에 기록하거나, 중요한 문서를 세션 시작 시 다시 읽도록 구성하는 것도 좋은 방법입니다(제가 강의 뒤쪽에 설명 드려놨습니다) 2. 새 세션을 만들면 이전 세션 내용을 모두 기억하나요? 아닙니다. 새로운 세션은 기본적으로 이전 세션의 대화 내용을 자동으로 기억하지 않습니다. 즉, "새 세션을 열었으니 Codex가 이전 작업을 모두 알고 있을 것이다" 라고 가정하고 개발하시면 안 됩니다. 새 세션은 현재 Repository 상태와 현재 읽은 파일들(예를들어 AGENTS.md)을 기반으로 판단합니다. 3. 이전 세션의 중요한 내용을 새 세션에서 이어서 사용하는 방법은? 실무에서는 보통 다음 방법을 사용합니다. 방법 1. 프로젝트 문서화 예를 들어 PROJECT.md ARCHITECTURE.md TASKS.md RELEASE.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 Problem Timeline 정렬 Hot Partition 캐시 무효화 같은 리스크를 먼저 적고 시작합니다(여기는 여러 시스템 디자인를 접해보는게 좋습니다) 그러면 하이레벨 설계가 해당 리스크들을 해결하는 방향으로 자연스럽게 발전하게 됩니다. 그리고 인터뷰 중에 딥다이브하다가 설계 오류를 발견해서 하이레벨로 다시 올라가는 것은 오히려 좋은 신호일 수 있습니다. 예를 들어 "지금까지는 단일 DB로 설명했는데, 읽기 트래픽 규모를 고려하면 이 부분은 샤딩이 필요하겠습니다." 처럼 명시적으로 수정 이유를 설명하면 인터뷰어는 "이 사람이 설계를 검증하면서 진행하는구나" 라고 받아들이는 경우가 많습니다 ㅎㅎㅎ (그래서 제 생각에는 좋은 듯) 실제 FAANG 계열 인터뷰에서도 처음 설계를 끝까지 고수하는 것보다, 새로운 정보가 나오면 설계를 업데이트하는 능력을 더 높게 평가하는 경우가 많습니다. 개인적으로는 처음 보는 문제를 만났을 때, 요구사항 → 트래픽 추정 → 병목 예상 → 리스크 목록 작성 → 하이레벨 디자인 순서로 접근하는 연습을 추천드립니다. 하이레벨 디자인은 결국 "컴포넌트를 그리는 과정"이 아니라 " 어떤 리스크를 해결할 것인가를 표현하는 과정 "에 가깝기 때문에, 리스크를 먼저 찾는 습관이 생기면 익숙하지 않은 도메인에서도 훨씬 안정적으로 설계할 수 있게 됩니다. 그리고 너무 걱정하지 않으셔도 되는 부분이, 시스템 디자인 인터뷰를 많이 본 지원자들의 공통적인 성장 포인트가 바로 말씀하신 "딥다이브하다가 하이레벨을 수정하는 경험"입니다. 그 과정을 반복하면서 처음 보는 문제도 점점 더 빠르게 구조화할 수 있게 됩니다. 🙂
질문&답변
안녕하세요 adele lee님, 좋은 질문입니다 😊 결론부터 말씀드리면 올라마(Ollama)는 '실행기'이고, 허깅페이스(Hugging Face)는 '모델 저장소(모델 마켓)'에 가깝습니다. 예를 들어: Ollama = 넷플릭스 앱 Hugging Face = 영화들이 모여있는 영화관/콘텐츠 창고 라고 생각하시면 이해가 쉽습니다. 우리가 Ollama를 설치하면 LLM을 실행할 수 있는 환경이 생기지만, 실제로 어떤 모델을 사용할지는 별개의 문제입니다. 예를 들어: Llama 3 Qwen Gemma Mistral DeepSeek 같은 모델들은 대부분 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.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 예시를 추가해두겠습니다. 좋은 제보 감사합니다.
질문&답변
안녕하세요 홍태경님. 좋은 질문 감사합니다. 네, 말씀하신 방식 충분히 가능합니다. 오히려 ETL 작업에서는 SQL을 Python 코드 안에 길게 넣기보다, dags/sql/ 같은 별도 디렉토리에 .sql 파일로 분리해서 관리하는 방식이 더 깔끔한 경우가 많습니다. 예를 들면 구조는 이렇게 가져갈 수 있습니다. dags/ my_etl_dag.py sql/ create_staging_table.sql insert_staging_daily.sql insert_mart_daily.sql 관련 내용은 Airflow의 “Templating”과 “SQLExecuteQueryOperator” 문서를 보시면 도움이 됩니다. 그리고 SQL을 많이 사용하신다면 DBT 관련 제 강의( https://inf.run/5LhTN )도 보시면 크게 도움이 되실 겁니다.
