내가 생각한 Best Pratice의 의미
# Best Pratice의 의미
2024년 02월 25일
서론
나는 대학교 2학년 때 계절학기 특강에서 기초 웹 개발 수업을 수강했던 적이 있다.
let User_Name = 'Hojin';
function GetUserInfo() {
return {
name: User_Name,
age: 30,
};
}해당 코드에서 변수 이름이 snake_case이고 함수 이름이 PascalCase여서 감점을 받은 적이 있다.
<div class="container ">
<div class="box">Box 1</div>
<div class="box">Box 2</div>
<div class="box">Box 3</div>
</div>
//float
.container {
width: 100%;
}
.box {
width: 30%;
float: left;
margin: 10px;
background-color: lightblue;
}
//flex
.container {
display: flex;
justify-content: space-between;
}
.box {
flex: 1;
margin: 10px;
background-color: lightblue;
}또한 화면 구현 예제에서 float대신 당시에는 최신 css 기술이이였던, flex를 썻다고 쓴소리를 들은적도 있다.
당시 강사님께 해당 내용이 감점을 받을 정도로 심각한 오류인지 여쭤보았을 때, "암묵적인 룰에 동의하지 않은 것이니 감점 사유가 된다"라는 답변을 받았다. 코딩 권태기였던 당시, 이런 세세한 부분까지 의미를 두는 방식은 나를 힘들게 했다..
유명한 기업의 개발 블로그나 Stack Overflow에서 문제 해결 방법을 찾아볼 때 심심치 않게 등장하는 단어가 있다. 바로 **‘Best Practice’**다. 이 단어를 처음 보았을 때는 단순히 ‘최선의 관행, 모범 사례’ 정도로 이해했다. 즉, 개발자들 사이에서 “이렇게 쓰는 게 제일 좋더라, 그러니까 너도 이렇게 써” 라는 의미로 받아들였다. 하지만 한 가지 궁금증이 생겼다. ‘최선’이라는 것은 누가 정하는 것이며, 어떤 의미에서의 최선을 말하는 걸까? Best Practice를 무조건 따르는 것이 올바른 코드인 걸까?
💡 이 글을 통해 내가 생각하는 개발 관점에서의 ‘최선’이라는 의미와 Best Practice에 대한 접근법을 말해보고자 한다.
본론
일반적인 관점에서의 Best Pratice
“BEST PRACTICE”는 최고의 효과가 입증되고 재현이 가능한 창의적인 업무 추진 방식으로써, 기업이 개발, 구매, 생산, 판매 등 각 기능 분야별 경영혁신활동을 통하여 창출해낸 차별화된 BEST SKILL과 핵심역량을 포함하고 있다.
여기서 BEST SKILL은 타사가 쉽게 모방하거나 따라 하기 힘든 자사만이 가지고 있는 특별한 능력이나 경영자원을 의미하며, 직원들이 전사적으로 수행할 수 있는 일의 방식이다.
예를 들어 택배 사업에서 처음에는 트럭으로 배달하는 것이 가장 빠른 배송 방식이었으나 점점 도로에 차량이 많아지게 되고 차량정체 현상이 나타나게 되어 이제는 트럭으로 배달 하는 것이 가장 빠른 배송 방식이 아니게 되었다 그래서 도로 차량정체 현상을 극복하고자 트럭보다 더 빠른 오토바이를 이용한 배송 방식이 등장하게 되었다. 이처럼 사업환경의 변화를 극복하기 위하여 완전히 새롭고 기존 방식과 차별화되게 일하는 방식이 BEST SKILL이다.
BEST SKILL의 개발은 불필요한 낭비 요소를 제거하고, 진짜 문제와 근본원인을 찾아 개선 하기 위한 창의적인 해결안 도출과 실행을 통하여 가능해진다.
개발 관점에서의 Best Pratice
소프트웨어 개발의 Best Practice는 소프트웨어 개발 과정에서 품질을 높이고 효율성을 극대화하기 위해 따르는 방법론과 지침을 의미한다. 개발 관점에서 중요하게 고려해야 할 다양한 베스트 프랙티스들이 있는데, 대표적인 베스트 프랙티스는 다음과 같다.
1. 소프트웨어 설계
- 모듈화 설계: 소프트웨어를 독립적인 모듈로 나누어 설계한다. 각 모듈은 특정 기능을 담당하며, 모듈 간의 의존성을 최소화한다.
- 디자인 패턴: 재사용 가능하고 검증된 디자인 패턴을 활용하여 문제를 해결한다. 예를 들어, 싱글톤 패턴, 팩토리 패턴, 옵저버 패턴 등이 있다.
- 아키텍처 패턴: MVC, MVP, MVVM 등의 아키텍처 패턴을 사용하여 코드의 유지보수성을 높인다.
2. 코드 품질
- 코드 리뷰: 동료의 코드를 검토하여 버그를 조기에 발견하고, 코드의 품질을 높인다.
- 테스트 주도 개발(TDD): 테스트 케이스를 먼저 작성한 후, 이를 통과하도록 코드를 작성하는데, 이는 코드의 안정성과 품질을 높이는 데 효과적이다.
3. 지속적 통합 및 배포(CI/CD)
- 지속적 통합(CI): 코드 변경 시 자동으로 빌드하고 테스트하는 프로세스를 구축하는데, 이는 버그를 조기에 발견하고, 통합 문제를 줄이는 데 도움을 준다
- 지속적 배포(CD): 변경된 코드를 자동으로 배포하는 프로세스를 구축한다. 배포 시간을 단축하고, 배포의 일관성을 유지해준다.
[2nd Softeer Tech Meet-up] 통합 모빌리티 서비스 App 개발 Best Practice
해당 참고 동영상에서는 베스트 프랙티스 중 하나인 클린 아키텍처Clean Architecture를 도입하여, 처음부터 entity와 usecase 설계를 ios와 안드로이드가 협의하거나, 한 쪽이 작업하면 똑같이 만드는 것을 원칙으로 하였고, 코어와 서비스 부분을 구조뿐만 아니라 소스코드 대부분을 일치시켜 ios와 안드로이드 동시에 효율적으로 개발할 수 있었던 경험을 소개한다.
❗️ 클린 아키텍처란?
소프트웨어 시스템을 유지보수하기 쉽고, 테스트 가능하며, 확장 가능하게 만드는 아키텍처 패턴이다. 소프트웨어의 의존성을 최소화하고, 시스템의 각 계층을 명확히 분리하는 것을 목표로 한다.
❗ 이러한 다양한 Best Practice를 통해 소프트웨어 개발의 품질과 효율성을 극대화하기 위한 중요한 지침을 정하고, 이를 도입함으로써 코드 품질을 높이고, 개발 속도를 향상시키며, 협업을 개선하고, 시스템의 유연성과 보안을 강화할 수 있게 된다.
Best Pratice === Clean Code인가?
Best Pratice는 주로 특정 기술이나 프로세스에 관련된 규칙이나 지침을 포함할 뿐, Best Pratice가 곧 Clean Code를 의미하는 것은 아니다. 많은 경우에서 Best Practice와 Clean Code가 혼동되어 사용되는 경우가 있지만, Clean Code는 Best Practice의 일부분이며, 코드가 깨끗하고 읽기 쉽다면 그것이 Best Practice를 따른 결과라고 할 수 있다. 즉 Clean Code는 소프트웨어 개발의 다양한 Best Practice 중 하나로, 코드의 품질을 높이기 위한 방법으로 사용된다.
내가 생각하는 Best Practice의 문제점
솔직히 대규모의 프로젝트를 해본 경험이 없는 주니어 베이비 영유아 개발자로서 나는 Best Practice의 느낌은 썩 좋지만은 않다. 투 마치 한 생각일 수 있겠지만, 한국 사회에서, 운동이나 게임 같은 일상적인 활동에서부터 프로젝트나 코딩과 같은 창의적인 작업에 이르기까지, 효율성을 추구하는 것은 항상 긍정적이지는 않기 때문이다.
헬스를 예로 들어보면, 많은 사람들이 최소한의 시간과 노력으로 최대의 결과를 얻기 위해 각종 유튜브나 참고하여 헬스장도 등록하기 전에 침대에 누워 자신만의 효율적인 3분할 루틴을 구축하려 한다. 이는 바쁜 일정 속에서도 효율적으로 운동할 수 있는 방법이며, 이론적으로는 효과적일 수 있다. 그러나 이러한 접근 방식이 종종 실제로 개인의 필요와 목표를 무시하거나, 체계적이고 균형 잡힌 운동 계획을 설정하지 않고 과도하게 단기적인 목표에 집중하는 결과를 초래할 수 있다.
게임에서도 비슷한 패턴이다. 캐릭터의 빠른 육성을 위해 캐릭터를 생성하기도전에 공략집부터 읽어보는 우리는 효율적으로 게임을 한다고 안도감이 들지만, 개인적인 즐거움이나 창의적인 육성에는 제약이 있을것이다.
결론
나는 Best Pratice나 Clean Code처럼 효율 중심의 사고방식의 강제성이 소프트웨어 개발과 같은 창의성을 필요로 하는 분야에서도 부정적 영향을 미칠 수 있다고 생각한다. 효율성과 규칙을 과도하게 강조할 경우, 이러한 과정에서 중요한 창의적 사고와 탐구가 소홀해질 우려가 있고, 개발자는 프로젝트를 완성하는 과정에서 자신만의 비전과 스타일을 반영할 기회를 잃을 수 있다.
물론, 내가 반골 기질을 갖고 실력 좋은 개발자들이 시행착오를 걸쳐 힘들게 만들어놓은 규범을 무시하라는 뜻은 절대 아니다. 결국, 효율성을 추구하는 것은 중요하지만, 이는 항상 상황과 목표에 맞춰 고려되어야 한다는 것이다. 특히 창의적인 분야에서는 효율성이 창의성을 억압하지 않도록 주의해야 하며, 개인의 독특한 접근 방식과 창의적인 발상을 존중하는 마음으로 지적보다는 개선의 의미가 담긴 진정한 Best Pratice가 되었으면 한다.
