본문으로 건너뛰기

용어 사전

중요도: 참고 · 낯선 단어를 만났을 때 빠르게 확인합니다. 정의만 외우기보다, 실제 대화에서 어떻게 쓰는지 함께 봅니다.

협업과 작업 관리​

Backlog​

아직 시작하지 않았지만 앞으로 처리할 후보 작업 목록입니다. 당장 해야 할 일 목록과는 다르게 우선순위가 바뀌거나 다시 다듬어질 수 있습니다.

사용 예시: “버그를 지금 고치기 어렵다면 Backlog에 넣고 다음 스프린트 때 우선순위를 정하자.”

Priority​

작업을 먼저 처리해야 하는 정도입니다. 단순히 어렵거나 큰 작업이 높은 Priority인 것은 아니며, 사용자 영향·마감·의존성·위험도를 함께 고려합니다.

사용 예시: “로그인 불가 버그는 사용자가 서비스를 시작할 수 없으니 P0으로 올리자.”

Dependency​

한 작업이 다른 작업의 결과를 필요로 하는 관계입니다. Dependency가 보이면 작업 순서를 조정하거나, 병렬로 가능한 범위를 먼저 나눕니다.

사용 예시: “인벤토리 UI는 아이템 데이터 구조가 정해진 뒤에 연결할 수 있으니 해당 Issue에 Dependency를 표시한다.”

Blocker​

작업 진행을 멈추게 하는 문제나 외부 의존성입니다. Blocker는 혼자 오래 붙잡기보다, 발생 시점과 필요한 도움을 빠르게 공유하는 것이 중요합니다.

사용 예시: “빌드가 특정 Unity 버전에서만 실패한다. 오늘 배포의 Blocker라 채널에 공유한다.”

Scope​

한 작업 또는 릴리스에서 다루기로 합의한 범위입니다. 요구가 추가될 때 Scope가 커졌는지 명시하면, 일정과 품질의 균형을 다시 판단할 수 있습니다.

사용 예시: “이번 PR의 Scope는 대시 이동 로직까지다. 이펙트 개선은 별도 Issue로 분리하자.”

Definition of Done (DoD)​

작업을 실제로 완료로 판정하는 기준입니다. 코드를 작성한 것만으로 Done이 아니라, 테스트·리뷰·문서화·배포 확인처럼 팀이 합의한 조건까지 충족해야 합니다.

사용 예시: “이 기능의 DoD는 PR 승인, 플레이 모드 확인, 관련 Issue 닫기까지로 하자.”

Git과 배포​

Branch​

공유 기준선에 영향을 주지 않고 독립적으로 작업하는 흐름입니다. 작업의 목적이 드러나는 이름을 사용하고, 하나의 Branch에는 가능한 한 하나의 변경 목표를 둡니다.

사용 예시: “feat/player-dash Branch에서 대시 기능만 구현하고, 리팩터링은 별도 Branch로 나눈다.”

Commit​

의미 있는 변경을 남기는 이력 단위입니다. 나중에 변경 이유를 찾거나 되돌릴 수 있도록, 하나의 목적을 가진 작은 단위로 만드는 것이 좋습니다.

사용 예시: “fix: prevent dash while stunned처럼 무엇을 고쳤는지 알 수 있게 Commit한다.”

Pull Request (PR)​

변경을 공유하고 Merge 전에 검토를 요청하는 단위입니다. 단순한 합치기 요청이 아니라, 변경의 의도·확인 방법·논의 기록을 팀에 남기는 공간입니다.

사용 예시: “PR 설명에 Issue 링크, 변경 요약, Unity에서 확인한 플레이 절차를 적는다.”

Code Review​

동료가 변경의 정확성, 읽기 쉬움, 예외 상황, 회귀 가능성을 확인하는 과정입니다. 승인 여부만이 목적이 아니라 지식을 나누고 위험을 줄이는 대화입니다.

사용 예시: “이 조건문은 null일 때도 안전한지 리뷰 코멘트로 질문한다.”

CI (Continuous Integration)​

변경이 공유될 때마다 Build·Test·Lint 같은 검증을 자동으로 실행하는 방식입니다. 사람이 매번 같은 기본 검사를 반복하지 않도록 해, 문제를 빠르게 발견하게 합니다.

사용 예시: “PR을 열면 CI가 Unity Build를 실행하고, 실패하면 Merge 전에 원인을 해결한다.”

Status Check​

PR에 연결된 자동 검증 또는 필수 확인 결과입니다. 녹색 체크가 Merge 안전성을 모두 보장하지는 않지만, 팀이 정한 기본 검증을 통과했다는 신호입니다.

사용 예시: “필수 Status Check가 실패했으니 승인받았더라도 Merge하지 않는다.”

Regression​

새 변경 때문에 이전에 정상 동작하던 기능이 깨지는 현상입니다. 기능을 추가할 때 관련된 기존 흐름을 함께 확인하는 이유입니다.

사용 예시: “대시를 추가한 뒤 점프가 안 되면, 대시 기능의 Regression으로 보고 재현 절차를 PR에 남긴다.”

Hotfix​

서비스나 주요 Build에서 발견된 심각한 문제를 빠르게 수정하는 변경입니다. 급하더라도 원인·영향 범위·검증 결과는 짧게라도 남깁니다.

사용 예시: “게임 실행 자체가 안 되는 오류라 Hotfix Branch를 만들고 최소 수정만 배포한다.”

29. Software Engineering에서 자주 쓰는 용어​

Architecture​

시스템 전체의 구조와 Component 사이의 관계입니다. 좋은 Architecture는 기능을 어디에 두고, 어떤 방향으로 의존하게 할지 명확하게 해 변경 비용을 줄입니다.

사용 예시: “UI가 게임 규칙을 직접 계산하지 않고, 별도 게임 로직 계층을 통해 상태를 받도록 Architecture를 정한다.”

Coupling​

두 Component가 얼마나 강하게 연결돼 있는지를 뜻합니다. Coupling이 지나치게 강하면 한 곳의 변경이 예상치 못한 곳까지 영향을 줄 수 있습니다.

사용 예시: “PlayerController가 모든 UI 객체를 직접 참조하면 Coupling이 강해지므로 이벤트나 인터페이스를 검토한다.”

Cohesion​

하나의 Class 또는 Module 안의 기능들이 얼마나 같은 책임을 향하는지를 뜻합니다. Cohesion이 높으면 코드를 어디서 찾아야 할지 예측하기 쉬워집니다.

사용 예시: “저장 기능과 전투 로직을 한 Class에 섞기보다, 각 책임에 맞춰 나누면 Cohesion이 높아진다.”

Responsibility​

Class·Module·System이 맡아야 하는 역할입니다. 책임이 명확하면 이름을 짓고 테스트하고 변경 영향을 파악하기 쉬워집니다.

사용 예시: “DamageCalculator의 Responsibility는 피해량 계산이지, UI 텍스트 변경이 아니다.”

Refactoring​

외부 동작은 유지하면서 내부 구조를 개선하는 작업입니다. 기능 추가와 구분해서 기록하면, 리뷰어가 동작 변경 여부를 더 정확히 확인할 수 있습니다.

사용 예시: “테스트를 유지한 채 중복 조건문을 메서드로 추출하는 것은 Refactoring이다.”

Technical Debt​

빠른 개발 또는 임시 설계 때문에 나중에 추가 비용이 발생하는 상태입니다. 의도적으로 감수할 수는 있지만, 왜 만들었고 언제 갚을지를 기록해야 관리할 수 있습니다.

사용 예시: “데모 일정 때문에 임시 데이터 구조를 쓴다면, 정식 모델로 교체할 Issue를 함께 만든다.”

Legacy Code​

기존에 존재해 변경하기 어렵거나 현재 구조와 잘 맞지 않는 코드·시스템을 말합니다. 오래됐다는 이유만으로 나쁜 것은 아니며, 동작과 의존성을 먼저 파악해야 합니다.

사용 예시: “레거시 전투 시스템을 바로 삭제하지 말고, 호출 지점과 테스트 유무부터 조사한다.”

Breaking Change​

기존 Interface 또는 사용 방식과 호환되지 않는 변경입니다. 영향을 받는 사용자·모듈에 알리고, 필요하다면 이전 방식의 전환 경로를 마련합니다.

사용 예시: “TakeDamage(int)를 삭제하고 호출 방식도 바꾸면 Breaking Change로 공지한다.”

문제 해결과 성능​

Edge Case​

일반적이지는 않지만 특정 경계 조건에서 발생하는 상황입니다. 입력값이 비어 있거나, 대상이 없거나, 수치가 최대·최소인 경우가 대표적입니다.

사용 예시: “적이 사망한 같은 프레임에 타겟을 선택하는 경우는 전투 로직의 Edge Case다.”

Troubleshooting​

증상을 확인하고, 재현하고, 원인을 가설로 세워 검증한 뒤 수정과 재검증까지 하는 문제 해결 과정 전체입니다.

사용 예시: “에러 메시지만 보고 수정하지 말고, 재현 절차와 로그를 먼저 남긴 뒤 가설별로 Troubleshooting한다.”

Bottleneck​

전체 성능 또는 진행 속도를 가장 크게 제한하는 지점입니다. 느린 부분 전체를 고치기보다, 측정으로 병목을 먼저 찾아야 합니다.

사용 예시: “프레임이 떨어질 때 Profiler로 CPU·GPU·메모리 중 Bottleneck이 어디인지 확인한다.”

Tick​

게임 엔진에서 Frame 또는 정해진 Update 주기마다 반복되는 처리 단위입니다. Unity에서는 Update, FixedUpdate, LateUpdate와 연결해 이해할 수 있지만 정확한 구조는 엔진마다 다릅니다.

사용 예시: “매 Tick마다 모든 적을 탐색하면 적 수가 많을 때 성능 문제가 생길 수 있다.”

Workaround​

근본 원인을 해결하지 못한 상태에서, 문제를 피해 기능을 동작하게 하는 임시 방법입니다. Workaround는 이유와 제거 계획을 남겨야 영구 부채가 되지 않습니다.

사용 예시: “외부 SDK 버그가 고쳐질 때까지 해당 기능을 비활성화하는 것은 Workaround다.”

30. PoC / Prototype / MVP​

PoC (Proof of Concept)​

특정 기술이나 아이디어가 실제로 가능한지 확인하는 작은 구현입니다. 완성도보다 핵심 위험을 빠르게 검증하는 것이 목적입니다.

사용 예시: “Unity Netcode로 4인 협동 플레이가 가능한지 확인하는 실험은 PoC다.”

Prototype​

게임 방식이나 사용자 경험이 실제로 작동하고 재미있는지 빠르게 검증하는 구현입니다. 그래픽 완성도보다 핵심 플레이 경험에 집중합니다.

사용 예시: “임시 큐브만으로 대시·회피 조작이 재미있는지 확인하는 것은 Prototype이다.”

MVP (Minimum Viable Product)​

사용자에게 제공할 수 있는 최소 제품 형태입니다. PoC나 Prototype보다 제품으로서의 흐름과 가치가 갖춰져야 합니다.

사용 예시: “로그인, 한 판 플레이, 결과 확인까지 가능한 최소 게임 루프를 갖춘 빌드는 MVP 후보가 된다.”

Git·GitHub·Unity 협업의 상세 흐름은 협업 가이드에서 확인합니다. 약어는 약어와 표현에서 따로 관리합니다.