개발자가 낯선 도메인에 빠르게 적응하는 법 | 이직·전배 후 코드와 비즈니스 로직 파악하기
이 글의 핵심
이직이나 전배로 금융, 물류, 제조, 의료, 게임 같은 낯선 산업 도메인의 코드베이스에 합류했을 때 겪는 막막함을 다룹니다. 코드는 읽히는데 '왜 이렇게 짜여 있는지' 모르는 상태에서 벗어나는 법, 도메인 용어집부터 정리하는 순서, git blame과 이슈 트래커로 '왜'를 역추적하는 법, 작은 티켓으로 지식을 체화하는 전략, 도메인 전문가에게 효율적으로 질문하는 법, 그리고 정상적인 적응 기간과 번아웃 신호까지 실전 체크리스트로 정리합니다.
들어가며: 이 글은 “합격 이후”에 대한 이야기입니다
이직이나 전배에 성공해서 새 회사, 새 팀에 합류했습니다. 그런데 첫 출근 2주 차에 마주한 코드는 이전 회사와는 완전히 다른 세상입니다. 문법은 익숙한데 SettlementBatchJob, ClaimAdjudicationService, WMSInboundEvent 같은 클래스 이름과, if (isPartialShipment && !hasBackorderFlag) 같은 조건문 앞에서 손이 멈춥니다. 코드는 분명히 읽히는데, “이걸 왜 이렇게 짜놨는지”는 전혀 감이 오지 않습니다.
pkglog에는 이미 이력서와 포트폴리오, 지원 전략을 다루는 개발 취업 실전 팁, 이직 준비 과정을 정리한 개발자 이직 실전 가이드, 코딩 테스트와 시스템 설계 면접을 대비하는 기술 면접 완벽 대비 가이드가 있습니다. 이 글은 그 이후, 이미 합격해서 팀에 들어온 다음의 이야기를 다룹니다. 취업 준비가 아니라, 낯선 산업 도메인(금융, 물류, 제조, 의료, 게임 등)의 코드베이스와 비즈니스 로직을 실무에서 빠르게 파악하는 방법에 초점을 맞춥니다.
이 글을 읽으면
- 도메인 적응이 왜 유독 힘든지, 그 구조적인 이유를 이해하고 불필요한 자책을 줄일 수 있습니다.
- 코드베이스보다 먼저 손봐야 할 것(도메인 용어집)과 그 정리 순서를 알 수 있습니다.
- git log, git blame, 이슈 트래커로 “왜 이렇게 짜여 있는지”를 역추적하는 구체적인 방법을 익힙니다.
- 어떤 순서로 코드를 손대야 지식이 가장 빠르게 체화되는지 알 수 있습니다.
- 질문하는 법, 도메인 전문가와 대화하는 법, 그리고 정상적인 적응 기간과 번아웃 신호까지 파악합니다.
1. 왜 도메인 적응이 유독 힘든가
코드를 읽는 것과 코드를 이해하는 것은 다른 일입니다
새 도메인에 들어가면 대부분의 개발자가 겪는 첫 번째 착각은 “코드는 다 읽히는데 왜 이렇게 막막하지?”입니다. 그 답은 간단합니다. 문법을 읽는 것과 의도를 파악하는 것은 완전히 다른 작업이기 때문입니다.
def calculate_settlement_amount(order, refund_policy):
if order.status == "PARTIAL_CANCEL" and refund_policy.grace_period_passed:
return order.total - order.cancelled_amount - order.penalty_fee
return order.total - order.cancelled_amount이 함수는 문법적으로 아무 문제 없이 읽힙니다. 하지만 “왜 grace_period가 지나면 penalty_fee를 빼는가?”라는 질문에 답하지 못하면, 이 코드를 안전하게 수정할 수 없습니다. penalty_fee가 법적 요건 때문에 존재하는지, 특정 결제 대행사와의 계약 조건 때문인지, 혹은 과거 어떤 장애의 임시 패치인지에 따라 수정 방향이 완전히 달라지기 때문입니다. 코드 자체는 장벽이 아닙니다. 그 코드 뒤에 숨어 있는 비즈니스 규칙과 예외 케이스의 총합이 장벽입니다.
도메인 지식은 코드에 다 쓰여 있지 않습니다
또 하나의 구조적인 문제는, 도메인 지식의 상당 부분이 코드에 명시적으로 드러나지 않는다는 점입니다. “왜 이 필드가 nullable인가”, “왜 이 배치는 새벽 3시에만 도는가”, “왜 이 API는 항상 재시도를 3번만 하는가” 같은 규칙은 대부분 회의록, 슬랙 스레드, 퇴사한 개발자의 머릿속, 혹은 아무 데도 남지 않은 채로 존재합니다. 코드 리딩만으로는 절대 채워지지 않는 영역이 있다는 것을 인정하는 것이 첫 단계입니다.
시니어도 도메인이 바뀌면 처음엔 헤맵니다
이 사실은 아무리 강조해도 부족합니다. 10년 차 시니어 백엔드 개발자가 이커머스에서 금융 도메인으로, 혹은 게임 서버에서 의료 도메인으로 옮기면 첫 한두 달은 거의 예외 없이 헤맵니다. 시니어의 강점은 도메인 지식이 아니라 낯선 코드를 안전하게 파악하는 절차와 감각을 이미 갖추고 있다는 점입니다. 오히려 경력이 오래될수록 “예전 도메인에서는 이렇게 하면 당연히 맞았는데” 하는 직관이 새 도메인에서는 틀린 신호로 작동해서 더 헷갈리는 경우도 많습니다. 지금 헤매고 있다면 그것은 능력 부족의 증거가 아니라, 도메인 전환이라는 작업의 정상적인 한 단계라는 점을 먼저 받아들이는 것이 중요합니다.
2. 코드베이스보다 먼저, 도메인 용어집을 정리하라
Ubiquitous Language부터 시작하는 이유
도메인 주도 설계(DDD)에서 말하는 유비쿼터스 랭귀지(ubiquitous language)는 “팀 전체가 같은 단어를 같은 의미로 쓰는 것”을 뜻합니다. 신규 입사자가 가장 먼저 겪는 혼란은 코드 구조가 아니라 용어 자체입니다. 물류 도메인이라면 “출고”와 “배송”이 시스템 내부에서 서로 다른 상태를 가리키는지, 금융 도메인이라면 “승인”과 “체결”이 같은 단계인지 다른 단계인지, 이런 것부터 헷갈립니다.
코드를 읽기 전에 노트나 위키 페이지 하나를 만들고, 회의나 코드 리뷰, 슬랙에서 마주치는 도메인 용어를 그때그때 적어 나가세요. 형식은 단순하게 유지합니다.
## 도메인 용어집 (계속 업데이트)
- **PartialShipment**: 한 주문의 상품 일부만 먼저 출고되는 경우.
풀필먼트 센터가 여러 곳으로 나뉜 주문에서 발생.
관련 코드: OrderShippingService.splitByWarehouse()
- **GracePeriod**: 취소 요청 후 페널티 없이 취소 가능한 유예 기간.
결제 시점 기준 D+1까지. (2024년 전자상거래법 개정 반영, PR #1842 참고)
- **Backorder**: 재고 부족으로 즉시 출고가 불가능한 상태.
BackorderFlag가 true면 정산 배치에서 제외됨.이렇게 정리한 용어집은 단순한 사전이 아닙니다. 새로운 티켓을 받았을 때 “이 티켓에 나오는 단어가 용어집에 있는가, 없는가”를 확인하는 것만으로도 이 작업이 익숙한 영역인지 아닌지 즉시 판단할 수 있습니다. 그리고 용어집이 쌓일수록 코드 안의 변수명과 클래스명이 갑자기 “읽히기” 시작하는 순간이 옵니다. 코드베이스 구조를 외우는 것보다 이 순간이 훨씬 먼저, 훨씬 빠르게 옵니다.
3. “왜 이렇게 짜여 있는가”를 역추적하는 법
git log와 git blame은 최고의 온보딩 문서입니다
코드에 남지 않은 맥락 중 상당수는 사실 커밋 히스토리와 이슈 트래커에 남아 있습니다. 다만 찾는 방법을 모르면 그냥 지나칩니다. 의도가 궁금한 코드 블록을 발견하면 다음 순서로 접근하세요.
# 1. 해당 라인이 언제, 누구에 의해, 어떤 커밋으로 추가됐는지 확인
git blame -L 40,55 order_service.py
# 2. 해당 커밋의 전체 diff와 커밋 메시지 확인
git show <commit-hash>
# 3. 파일 이름이 바뀌었거나 리팩터링을 거쳤어도 이력을 계속 추적
git log --follow -p -- order_service.py
# 4. 특정 함수/변수가 언제 도입됐는지 히스토리 전체에서 검색
git log -S "GracePeriod" --oneline --allgit log -S(pickaxe 검색)는 특히 유용합니다. 함수 이름이나 특정 문자열이 코드베이스에 처음 등장한 커밋, 그리고 그 이후 변경된 모든 커밋을 순서대로 보여주기 때문에, “이 로직이 왜 이렇게 진화했는가”를 시간순으로 재구성할 수 있습니다.
PR 설명과 이슈 트래커에서 “왜”를 찾기
커밋 메시지 자체가 부실한 팀도 많습니다. 그럴 때는 커밋 해시로 연결된 PR을 GitHub/GitLab에서 열어 보세요. 대부분의 팀은 커밋 메시지보다 PR 본문에 더 많은 맥락(관련 티켓 링크, 논의 스레드, 리뷰 코멘트)을 남겨둡니다.
# 커밋이 속한 PR 번호 찾기 (GitHub CLI)
gh pr list --search "<commit-hash>" --state merged
# 해당 PR의 설명과 리뷰 코멘트까지 확인
gh pr view <pr-number> --commentsPR을 찾았다면 연결된 지라(Jira)나 리니어(Linear) 티켓도 함께 열어보세요. “왜 이 기능이 필요했는가”에 대한 원본 요구사항, 기획자와의 논의, 심지어 “이 예외 케이스는 특정 고객사 때문에 추가됐다”는 배경까지 확인할 수 있는 경우가 많습니다. 이 세 가지(커밋 → PR → 티켓)를 하나의 체인으로 엮어서 추적하는 습관을 들이면, 문서화가 부실한 팀에서도 “왜”에 대한 답을 상당수 스스로 찾아낼 수 있습니다.
4. 핵심 엔티티부터 파악하라: 직접 그려보는 것이 가장 빠릅니다
모든 테이블을 외우려 하지 마세요
새 코드베이스의 DB 스키마를 열어보면 수십, 수백 개의 테이블이 있을 것입니다. 이걸 전부 이해하고 시작하겠다는 목표는 그 자체로 비효율적입니다. 대신 가장 자주 호출되고, 가장 많은 다른 테이블과 관계를 맺는 핵심 엔티티부터 좁혀서 파악하세요.
핵심 엔티티를 찾는 실용적인 방법은 코드에서의 참조 빈도를 확인하는 것입니다.
# 어떤 모델/엔티티가 코드베이스 전체에서 가장 많이 참조되는지 확인
grep -rl "class.*Order" --include="*.py" . | wc -l
grep -rn "Order\.objects\." --include="*.py" . | wc -l
# 가장 자주 조인되는 테이블 조합 확인 (ORM 쿼리 로그나 슬로우 쿼리 로그 활용)애플리케이션 로그에서 실행되는 SQL을 몇 시간 관찰하는 것도 좋은 방법입니다. 실제 트래픽에서 가장 자주 조회되고 조인되는 테이블이 바로 이 시스템의 핵심입니다.
직접 손으로 다이어그램을 그려보기
핵심 엔티티 5~10개를 찾았다면, 문서에 이미 있는 ERD를 보는 것보다 직접 손으로 관계를 그려보는 것이 훨씬 오래 기억에 남습니다. mermaid나 종이 어느 쪽이든 좋습니다.
erDiagram
ORDER ||--o{ ORDER_ITEM : contains
ORDER ||--o| SHIPMENT : has
ORDER }o--|| CUSTOMER : belongs_to
SHIPMENT ||--o{ SHIPMENT_EVENT : tracks
ORDER_ITEM }o--|| PRODUCT : references
ORDER ||--o| SETTLEMENT : settles_into
직접 그리는 과정에서 “이 관계가 1:1인지 1:N인지 헷갈리네”, “SETTLEMENT은 왜 ORDER와 직접 연결이 아니라 별도 배치를 거치지?” 같은 질문이 자연스럽게 떠오릅니다. 이 질문들이 바로 다음에 팀원에게 물어볼 목록이 됩니다. 문서를 읽기만 할 때는 이런 질문이 잘 떠오르지 않지만, 직접 그리다가 막히는 지점에서는 반드시 질문이 생깁니다.
5. 작은 티켓부터 시작해 손으로 체화하라
읽기만 해서는 체화되지 않습니다
도메인 지식을 완벽하게 이해한 다음 코드를 만지겠다는 계획은 대부분 실패합니다. 이해라는 것은 읽는 것만으로는 잘 쌓이지 않고, 직접 고쳐보고 리뷰를 받고 실제 동작이 바뀌는 것을 확인하는 과정에서 훨씬 빠르게 쌓입니다.
합류 후 처음 몇 주는 다음 기준으로 티켓을 골라보세요.
- 영향 범위가 명확하고 좁은 버그 픽스 (예: 특정 조건에서 잘못된 라벨이 표시되는 UI 버그)
- 롤백이 쉬운 작업 (feature flag로 감쌀 수 있거나, 되돌리기 쉬운 변경)
- 기존 테스트 코드가 있어서 회귀를 바로 확인할 수 있는 영역
- 코드 변경량은 적지만, 관련된 도메인 개념은 넓게 걸쳐 있는 티켓 (예: 로깅 필드 하나를 추가하는데 여러 서비스를 거치는 경우)
이런 티켓을 처리하면서 리뷰어의 코멘트(“여기서는 refund_policy가 아니라 cancellation_policy를 봐야 해요” 같은)를 받는 순간, 문서 열 페이지를 읽는 것보다 훨씬 강하게 도메인 규칙이 각인됩니다. 작은 변경을 반복하면서 “코드 수정 → 피드백 → 도메인 지식 보정”의 루프를 빠르게 여러 번 돌리는 것이, 큰 기능을 처음부터 혼자 설계하려는 것보다 압도적으로 안전하고 효율적입니다.
6. 질문하는 법: 부끄러워하지 않고, 효율적으로
질문의 품질을 높이는 것이 핵심입니다
“이거 왜 이렇게 되어 있어요?”라는 질문 자체는 부끄러운 것이 아닙니다. 다만 질문의 형태에 따라 상대방이 답하기 쉬운 정도가 크게 달라집니다. 다음 두 질문을 비교해 보세요.
- 비효율적인 질문: “이 OrderService 코드 왜 이렇게 짜여 있어요?”
- 효율적인 질문: “OrderService.calculateSettlement에서 GracePeriod가 지나면 penalty_fee를 빼는데, 이게 결제사 계약 조건 때문인가요, 아니면 법적 요건 때문인가요? git blame으로 봤을 때 2024년 PR #1842에서 추가된 것 같은데, 그 PR 설명에 명확한 이유가 없어서 여쭤봅니다.”
두 번째 질문은 이미 스스로 조사한 흔적(git blame, PR 번호)을 담고 있고, 답변자가 “네, 맞습니다” 또는 “아니요, 사실은 이래서입니다” 정도로 짧게 답할 수 있는 구조입니다. 질문하기 전에 최소한 git blame과 관련 PR/티켓 정도는 확인하는 습관을 들이면, 질문의 밀도가 크게 올라가고 팀원들도 훨씬 편하게 답해줍니다.
온보딩 문서가 없다면, 스스로 만들면서 학습하라
많은 팀이 온보딩 문서를 갖추지 못한 이유는 게을러서가 아니라, 이미 도메인에 익숙한 사람은 “무엇이 낯선지” 자체를 모르기 때문입니다. 오히려 지금 막 합류한 사람만이 어떤 부분이 헷갈리는지 정확히 알고 있습니다. 이 위치를 활용하세요.
- 용어를 정리한 노트, 역추적한 “왜”의 기록, 직접 그린 엔티티 다이어그램을 그대로 팀 위키나 리포지토리의
docs/onboarding.md에 옮겨 적습니다. - 질문하고 답을 받은 내용은 슬랙 DM에만 남기지 말고, 짧게라도 문서화해서 다음 사람이 같은 질문을 반복하지 않게 합니다.
- 3개월쯤 지나 이 노트를 다시 보면, 처음엔 사소해 보였던 메모들이 실제로 팀에서 가장 정확한 온보딩 자료가 되어 있는 경우가 많습니다.
이 과정은 본인의 학습 효율을 높이는 동시에, 팀에 기여하는 첫 번째 눈에 보이는 결과물이 되기도 합니다.
7. 도메인 전문가와 대화하는 법
기술 용어 대신 비즈니스 시나리오로 물어보기
기획자, PM, 현업 담당자에게 질문할 때 코드 용어를 그대로 쓰면 대화가 어긋나기 쉽습니다. “PartialShipment 상태일 때 SettlementBatch가 스킵되는 게 맞나요?”라고 물으면 상대방은 코드 용어를 몰라서 즉답을 못 합니다. 대신 실제 업무 시나리오로 바꿔서 물어보세요.
- 기술 용어 질문: “OrderStatus가 PARTIAL_CANCEL일 때 정산 로직이 어떻게 동작해야 하나요?”
- 시나리오 질문: “고객이 주문한 상품 3개 중 1개만 취소했을 때, 판매자에게 정산되는 금액에서 그 1개 값이 언제 빠지나요? 취소 요청 당일인가요, 다음 정산 주기인가요?”
시나리오 질문은 도메인 전문가가 본인의 언어로 답할 수 있게 해주고, 그 답을 코드로 번역하는 작업은 개발자인 당신이 맡으면 됩니다. 이 번역 과정 자체가 도메인 지식을 코드 구조에 매핑하는 훈련이 되기 때문에 일부러 이 순서를 지키는 것이 좋습니다.
엣지 케이스는 항상 “실제로 그런 일이 있었나요?”로 확인하기
도메인 전문가와의 대화에서 가장 값진 정보는 대부분 “예외적으로 이런 경우가 있었어요”라는 답변에서 나옵니다. 코드에 남아 있는 이상한 조건문의 절반은 실제로 벌어졌던 특정 사건(특정 고객사의 요청, 특정 규제 대응, 특정 장애의 임시 조치)의 흔적입니다. “이 조건은 왜 있나요?”보다 “이 조건이 없었을 때 실제로 문제가 된 적이 있나요?”라고 물으면 훨씬 구체적인 배경을 들을 수 있습니다.
8. 심리적인 측면: 완벽주의를 내려놓고, 정상 타임라인을 받아들이기
“완전히 이해한 다음 코드를 짜야 한다”는 착각
새 도메인에서 가장 흔한 자기 발목잡기는 “이 도메인을 완전히 이해하기 전에는 함부로 코드를 건드리면 안 된다”는 완벽주의입니다. 이 생각은 안전해 보이지만 실제로는 적응 속도를 크게 늦춥니다. 완전한 이해는 코드를 건드리기 전이 아니라, 여러 번 작은 변경을 반복하며 피드백을 받는 과정에서 만들어지기 때문입니다. 리뷰 프로세스와 테스트, 스테이징 환경이라는 안전망이 이미 마련돼 있다면, 작은 리스크의 변경은 오히려 학습을 위한 가장 좋은 도구입니다.
현실적인 타임라인
개인마다 차이는 있지만, 다음 정도가 일반적인 감각입니다.
- 1~2주차: 개발 환경 세팅, 코드 구조 훑어보기, 용어집 작성 시작. 이 시기에 도메인을 이해하지 못하는 것은 당연합니다.
- 3~6주차: 작은 티켓을 처리하며 핵심 엔티티와 주요 플로우가 눈에 익기 시작. “이 코드가 어디쯈 있는지” 정도는 감이 잡힙니다.
- 2~3개월차: 팀 내 논의에서 도메인 용어를 자연스럽게 쓰고, 새로운 티켓의 영향 범위를 어느 정도 스스로 판단할 수 있게 됩니다.
- 3~6개월차: 도메인 특유의 예외 케이스와 함정까지 감을 잡고, 신규 입사자에게 설명해줄 수 있는 수준에 도달합니다.
이 타임라인보다 늦다고 해서 문제가 있는 것은 아닙니다. 도메인의 복잡도, 팀의 문서화 수준, 코드베이스의 규모에 따라 이 기간은 크게 달라집니다. 다만 “한 달이 지났는데도 하나도 모르겠다”는 느낌 자체는 이 시기의 정상적인 감정이라는 것을 기억해두면 불필요한 자기 의심을 줄일 수 있습니다.
번아웃 신호 체크
다음 중 두세 가지 이상이 몇 주 이상 지속된다면, 학습 속도의 문제가 아니라 번아웃의 초기 신호일 수 있습니다. 이때는 학습 방법을 바꾸는 것보다 먼저 매니저나 팀 리드와 업무량, 기대 수준을 조율하는 대화를 하는 것이 우선입니다.
- 매일 새로운 용어와 코드를 마주하는 것 자체가 피로가 아니라 두려움으로 느껴진다.
- 질문하는 것이 무능함을 들키는 일처럼 느껴져서 점점 질문을 줄이고 있다.
- 퇴근 후에도 계속 “내가 이 도메인을 이해하지 못하는 것 같다”는 생각이 떠나지 않는다.
- 작은 실수 하나에도 “역시 나는 이 도메인에 안 맞는 것 같다”는 결론으로 곧장 건너뛴다.
이런 신호는 실력 부족이 아니라 정보 과부하 상태에서 나타나는 자연스러운 반응입니다. 학습량을 줄이고, 지금까지 이해한 것을 정리하는 시간을 갖는 것만으로도 상당 부분 완화됩니다.
9. 실전 체크리스트
새 도메인에 합류한 첫 1~2개월 동안 아래 항목을 순서대로 진행해보세요.
- 도메인 용어집 문서를 만들고, 회의/코드리뷰/슬랙에서 마주치는 용어를 그때그때 기록한다.
- 코드베이스 전체를 훑기 전에, 참조 빈도 기준으로 핵심 엔티티 5~10개를 먼저 좁힌다.
- 핵심 엔티티 간의 관계를 문서 복붙이 아니라 직접 다이어그램으로 그려본다.
- 이해가 안 되는 조건문/함수를 만나면
git blame→git show→ 연결된 PR → 연결된 티켓 순서로 역추적한다. - 리스크가 낮고 영향 범위가 좁은 버그 픽스 티켓을 우선 골라 손으로 직접 고쳐본다.
- 질문 전에 최소한의 스스로 조사(git blame, 관련 PR 확인)를 마친 뒤, 조사한 내용과 함께 질문한다.
- 도메인 전문가에게는 기술 용어 대신 실제 업무 시나리오로 질문을 바꿔서 물어본다.
- 학습 과정에서 만든 노트를 팀 위키나
docs/onboarding.md로 옮겨 다음 입사자를 위한 문서로 남긴다. - “완전히 이해해야 손댈 수 있다”는 생각이 들 때마다, 대신 리스크가 낮은 변경 하나를 골라 실행한다.
- 번아웃 신호(질문 회피, 퇴근 후 지속되는 자기 의심)가 감지되면 학습 방법이 아니라 매니저와의 기대치 조율을 먼저 시도한다.
마치며
낯선 도메인에서의 막막함은 실력의 문제가 아니라, 아직 채워지지 않은 맥락의 문제입니다. 코드를 읽는 속도와 그 코드 뒤의 비즈니스 규칙을 이해하는 속도는 서로 다르게 움직이고, 후자는 문서를 정독한다고 빨라지지 않습니다. 용어집을 정리하고, 커밋 히스토리와 이슈 트래커로 “왜”를 역추적하고, 작은 변경을 반복하며 손으로 체화하는 과정을 거치면, 처음에는 막막했던 코드가 어느 순간부터 자연스럽게 읽히기 시작합니다. 그 순간까지의 몇 주에서 몇 개월은, 지나고 나면 누구나 겪는 평범한 적응 기간이었다는 것을 기억해두시길 바랍니다.
같이 보면 좋은 글 (내부 링크)
이 주제와 연결되는 다른 글입니다.
- 개발자 이직 실전 가이드 | 퇴사부터 합격까지 3개월 로드맵
- 개발 취업 실전 팁 | 이력서·포트폴리오·지원 전략부터 면접까지
- 개발자 기술 면접 완벽 대비 가이드 | 알고리즘부터 시스템 설계까지