패키지 구조 어떻게 짰나요?

 

 

 

패키지 구조 어떻게 짰나요?

프로젝트를 하다 보면, 확장성을 고려해서 패키지 구조를 세분화하거나, 추상화를 도입하게 되는 경우가 많다. 특히 백엔드에서는 기능별로 책임을 분리하고, 향후 기능 추가를 대비해 모듈화하는 것이 좋은 습관처럼 여겨지곤 한다.

하지만 면접에서 “패키지 구조 왜 그렇게 짰나요?”라는 질문을 받는다면, 단순히 “확장을 위해서요”라고만 답하긴 어렵다. 왜냐하면 확장만을 위해 구조를 설계했는데 실제로는 사용되지 않거나 오히려 복잡해졌다면, 그것은 오버 엔지니어링이 될 수 있기 때문이다.

 

실제로 나도 의도적으로 기능을 나누고 설계를 했지만, 결과적으로는 사용되지 않거나 불필요하게 복잡해졌던 경험이 있다. 이런 상황에서 중요한 건 ‘현재의 필요’와 ‘미래의 가능성’을 어떻게 균형 있게 판단했느냐, 그리고 그 판단을 어떻게 설명할 수 있느냐다.

 

확장을 고려한 설계는 분명 좋은 습관이다. 하지만 다음과 같은 질문을 던져볼 필요가 있다.

• 지금 이 구조는 다른 기능에서도 재사용되고 있는가?
• 실제로 2개 이상에서 확장되어 사용되고 있는가?
• 현재 구조가 오히려 읽기 어렵거나 테스트하기 어렵지는 않은가?
• 이 추상화는 실제 동작하는가, 아니면 예비용인가?

이 기준을 통해 오버 엔지니어링인지, 합리적인 설계인지 판단할 수 있다.

 

실제로 배민 면접에서는 설계와 구현 중 어떤 게 더 중요한가? 라는 질문이 나오기도 했다.

 

 

 

MVC (Model, View, Controller)

MVC는 Model-View-Controller의 약자로, 프론트와 백엔드를 아우르는 가장 기본적인 아키텍처 중 하나다.

• Model: 데이터를 처리(CRUD)하는 영역. DB, 상태 관리, 계산 로직 등 비즈니스 로직의 핵심이 여기에 있다.
• View: 사용자에게 보여지는 UI 부분. HTML, 화면 구성 등 프론트엔드의 시각적 요소가 해당된다.
• Controller: 사용자의 요청을 받아 Model과 View를 연결하는 역할을 한다. (Model 과 View 는 서로 관여할 수 없다) 주로 라우팅, 요청 처리 등을 담당한다.

즉, Model은 무엇을 보여줄지, View는 어떻게 보여줄지, Controller는 언제 무엇을 보여줄지를 결정한다.

 

그런데, 왜 나눠야 하는가?
→ 역할을 분리하면 코드의 책임이 명확해진다.

• 협업 시 이해하기 쉽고,
• 유지보수 시 수정 범위가 좁아지고,
• 확장 시 구조를 변경하지 않고 기능만 추가할 수 있다.

 

 

디자인 패턴

디자인 패턴은 반복되는 문제를 해결하기 위한 설계의 힌트다. 

https://refactoring.guru/ko/design-patterns

디자인 패턴들

 

 

 

TDD (Tedst Driven Development)

테스트 주도 개발, 말 그대로 테스트 코드를 먼저 작성한 뒤, 그 테스트를 통과하기 위한 실제 코드를 작성하는 방식이다.

 

이 방식은 다음과 같은 순서를 따른다:

1. 실패하는 테스트 작성
2. 테스트를 통과하는 최소한의 코드 구현
3. 코드 리팩터링

장점은 다음과 같다:

• 기능 요구사항을 명확하게 정의할 수 있다.
• 디버깅보다 예방이 중심이다.
• 리팩터링에 대한 두려움이 줄어든다.

처음에는 익숙하지 않지만, 팀 규모가 커지거나 기능이 복잡해질수록 TDD의 가치가 분명해진다.

 

 

 

development vs implement

두 단어 모두 ‘개발하다’라고 번역되지만 실제 의미는 다르다.

• development: 계획, 설계, 구현, 테스트 등 전체적인 개발 과정 전반
• implement: 그 중에서도 구체적으로 코드를 작성하는 행위

예를 들어, 시스템 아키텍처를 짜고 어떤 기능이 들어가야 할지를 논의하는 것은 development에 가깝고, 그 기능을 실제 코드로 구현하는 건 implement다. 면접에서 “개발했습니다”라는 말을 할 때 이 차이를 이해하고 사용하면 커뮤니케이션이 훨씬 정확해진다.

 

 

 

애자일 vs 폭포수

폭포수(Waterfall)는 전통적인 개발 방식으로, 기획 → 설계 → 구현 → 테스트 → 배포가 순차적으로 이뤄지는 구조다.

반면, 애자일(Agile)은 반복적이고 점진적인 방식이다. 작은 단위로 나눠서 개발과 피드백을 빠르게 반복하며 완성도를 높인다.

폭포수는 설계가 철저하지만 변화에 유연하지 못하고, 애자일은 변화에 민감하지만 초기 기획이 비교적 느슨할 수 있다. 요즘 대부분의 팀은 애자일 방식을 채택하거나, 두 방식을 혼합해서 사용한다.

 

 

 

IDE (Integrated Development Environment)

통합 개발 환경: 코드 작성, 실행, 디버깅, 테스트 등 개발에 필요한 도구들을 하나의 툴에서 통합적으로 제공한다.

예를 들어, IntelliJ, Eclipse, VS Code, Android Studio 등이 대표적인 IDE다. IDE를 잘 활용하면 생산성과 디버깅 효율이 크게 올라간다.

 

 

 

Git과 GitHub의 차이점은?

개발을 시작했을 때 헷갈리는 것 중 하나가 Git과 GitHub의 차이다. 이 둘은 이름도 비슷하고 함께 쓰이는 경우가 많아서 같은 것으로 착각하기 쉽지만, 엄연히 다르다.

 

Git은 '버전 관리 도구'

Git은 내 컴퓨터에 설치해서 사용하는 분산 버전 관리 시스템이다. 파일의 변경 이력을 기록하고, 이전 버전으로 되돌리거나, 여러 작업을 병렬로 진행할 수 있게 해준다. 쉽게 말해, ‘내 프로젝트의 타임머신’ 같은 존재다. 누가, 언제, 어떤 코드를 수정했는지를 기록하고, 실수했을 때도 과거로 돌아갈 수 있도록 해준다. Git은 오프라인에서도 작동한해서 코드를 안전하게 관리할 수 있다.

 

GitHub는 '코드를 공유하는 공간'

GitHub는 Git으로 관리하고 있는 코드 저장소를 인터넷을 통해 공유하고 협업할 수 있게 해주는 플랫폼이다. 웹 기반의 서비스이며, Git이 만든 버전 기록을 기반으로 여러 개발자들이 동시에 작업하고 협업할 수 있게 도와준다. 말 그대로 ‘Git 저장소를 올려두는 웹사이트’인 셈이다. 마이크로소프트가 인수해서 운영하고 있다.

 

 

쉽게 비유하자면?

• Git은 내 컴퓨터에 설치된 버전 관리 프로그램
• GitHub는 인터넷에 있는 코드 공유 창고

다시 말해, 내가 혼자 작업할 땐 Git만 있어도 충분하지만, 협업을 하거나 원격에 코드를 백업하려면 GitHub 같은 서비스가 필요하다.

 

 

[면접 질문] 협업할 때 Git 써보셨나요? → stash

Git stash는 협업 중 잠깐 코드 작업을 미뤄야 할 때 매우 유용한 기능이다. 예를 들어, 내가 어떤 기능을 작업하고 있다가 급하게 main 브랜치의 이슈를 수정해야 할 경우, 현재 작업 중인 변경사항을 커밋하지 않고 임시로 저장해두고, 다른 작업으로 전환할 수 있다. 협업할 때 다양한 브랜치 전환이나 긴급 작업 요청이 있을 수 있는데, 그럴 때 stash는 현재 진행 중인 작업을 안전하게 보관하는 임시 서랍 역할을 해준다.

 

 

build 가 뭔가요?

빌드는 소스코드, 설정, 이미지, 리소스 등 여러 구성 요소를 하나로 묶어 컴퓨터가 실행 가능한 형태로 변환하는 전체 과정을 말한다.

Java 에서는 .java 소스 파일을 .class 바이트코드로 바꾸는 과정이 빌드이고, 프론트엔드에서는 여러 .js, .css, .html 파일을 번들링하고 최적화하는 것도 빌드 과정에 포함된다. 쉽게 말해, 사람이 쓴 코드를 컴퓨터가 이해할 수 있도록 바꾸는 과정이 빌드다.

 

예전엔 자바스크립트는 빌드 없이 그냥 HTML에 넣고 실행하는 정도로 사용됐지만, 최근의 프론트엔드 개발은 빌드 과정을 필수적으로 포함한다. 예를 들어 React, Vue 같은 프레임워크를 사용하면 다음과 같은 작업이 필요하다:

• 여러 JS 파일을 하나로 합치기 (번들링)
• 최신 문법을 옛 브라우저도 이해할 수 있게 바꾸기 (트랜스파일링)
• CSS 최적화, 이미지 압축 등 리소스 정리
• 결과물은 /dist, /build 같은 폴더에 저장

이런 작업을 Webpack, Vite, Parcel 같은 빌드 도구가 수행한다. 즉, 자바스크립트도 현대적인 환경에서는 빌드 과정을 반드시 거친다.

 

 

컴파일러 vs 인터프리터

컴퓨터는 소스코드를 그대로 이해하지 못하기 때문에, 번역이 필요하다. 이 번역 방식은 두 가지로 나뉜다.

구분	방식	언제 번역 되는가	번역 단위	대표 언어
컴파일러	컴파일	실행 전에 한 번에 통째로 번역	전체 파일	C, C++, Java
인터프리터	인터프리트	실행하면서 한 줄씩 번역	한 줄 또는 명령 단위	Python, JavaScript

• 컴파일러 : 전체 소스코드를 미리 기계어로 바꿔놓는다. 속도는 빠르지만, 코드 전체가 문제 없이 컴파일되어야 실행 가능하다.
• 인터프리터 : 실행 도중 한 줄씩 해석하며 실행한다. 에러가 나도 앞줄까지는 실행되고, 수정 및 테스트가 빠른 장점이 있다.