Joannes IT Blog

원문 : [MEDIUM] CI/CD Best Practices

1. 자동화(Automate Everything): 빌드, 테스트, 배포 과정 전체를 자동화합니다.
2. 버전 관리(Version Control): 코드베이스 관리를 위해 버전 관리 시스템(예: Git)을 사용합니다.
3. 단일 저장소(Single Repository): 관련 코드와 설정 파일을 단일 저장소에 유지합니다.
4. 빌드 자동화(Build Automation): 자동 빌드를 트리거하는 빌드 자동화 도구(예: Jenkins, Travis CI, GitLab CI)를 사용합니다.
5. 자동화된 테스팅(Automated Testing): 자동으로 실행되는 유닛, 통합, 종단간 테스트를 포함한 종합적인 테스트 스위트를 구현합니다.
6. 병렬 테스팅(Parallel Testing): 테스트 시간을 단축하고 개발자에게 빠른 피드백을 제공합니다.
7. 빠른 빌드와 테스트(Fast Builds and Tests): 빠른 피드백 루프를 통해 문제를 빠르게 식별하고 해결합니다.
8. 아티팩트 관리(Artifact Management): 빌드 아티팩트를 중앙 저장소에서 관리합니다.
9. 환경 일치(Environment Parity): 개발, 테스트, 생산 환경을 가능한 유사하게 유지합니다.
10. 코드로서의 인프라(Infrastructure as Code, IaC): 인프라를 코드로 정의합니다.
11. 구성 관리(Configuration Management): 환경 구성을 관리하는 도구를 사용합니다.
12. 지속적 배포 vs. 지속적 전달(Continuous Delivery vs. Continuous Deployment): 두 접근법을 이해하고 자신의 출시 프로세스에 가장 적합한 방법을 선택합니다.
13. 점진적 배포(Incremental Deployment): 작은 변경 사항을 배포하여 버그 도입 위험을 줄입니다.
14. 기능 플래그(Feature Flags): 런타임에 기능을 활성화하거나 비활성화합니다.
15. 모니터링 및 로깅(Monitoring and Logging): 테스트 및 생산 환경에서 강력한 모니터링과 로깅을 구현합니다.
16. 보안 스캐닝(Security Scanning): CI/CD 파이프라인에 보안 스캔을 통합합니다.
17. 롤백 전략(Rollback Strategies): 생산에 문제를 일으킨 배포를 빠르고 안전하게 이전 버전으로 롤백할 수 있어야 합니다.
18. 보안 고려사항(Security Considerations): CI/CD 파이프라인에 보안 검사를 통합합니다.
19. 문서화(Documentation): CI/CD 파이프라인 문서를 최신 상태로 유지합니다.
20. 협업 및 커뮤니케이션(Collaboration and Communication): 협업과 커뮤니케이션 문화를 촉진합니다.
21. 재해 복구 계획(Disaster Recovery Plan): 배포 과정에서 예상치 못한 실패로부터 빠르게 회복할 수 있는 재해 복구 계획을 마련합니다.

핵심 요약

• 자동화의 중요성: CI/CD 프로세스의 모든 단계(빌드, 테스트, 배포)를 자동화하여 효율성과 속도를 높입니다.
• 환경 일치 및 보안: 개발, 테스트, 생산 환경을 유사하게 유지하고, 보안 스캔과 검사를 통합하여 보안 취약점을 조기에 식별 및 수정합니다.
• 협업 및 지속적인 개선: 팀원 간의 협업과 커뮤니케이션을 강화하고, 지속적인 모니터링과 피드백을 통해 지속적으로 CI/CD 파이프라인을 개선합니다.

용어 정리

• CI/CD: 지속적 통합(Continuous Integration) 및 지속적 배포(Continuous Deployment)의 약어로, 소프트웨어 개발 프로세스에서 코드 변경사항을 자동으로 빌드, 테스트, 배포하는 접근법을 의미합니다.
• 아티팩트(Artifact): 소프트웨어 빌드 과정에서 생성된 파일(예: 컴파일된 바이너리, 라이브러리)을 의미합니다.
• IaC(Infrastructure as Code): 인프라 구성 요소를 코드 형태로 관리하여, 인프라의 배포와 관리를 자동화하는 방식입니다.
• 기능 플래그(Feature Flags): 소프트웨어의 특정 기능을 켜거나 끌 수 있는 설정을 의미합니다.

원문 : [MEDIUM] Software Development Trends 2023/2024 — Vol. 1.

소프트웨어 아키텍처

• 디자인 포터빌리티는 클라우드 네이티브 추상 모델을 강조하는 프레임워크를 통해 구현 세부 사항에서 비즈니스 로직을 분리함으로써 인기를 얻고 있음.
• 대규모 언어 모델은 로우코드 및 노코드 개발자의 새로운 세대를 가능하게 하는 것부터 아키텍처적 트레이드오프 이해까지, 중요한 영향을 미침.
• 소프트웨어의 지속 가능성은 향후 중요한 설계 요소가 될 것임. 소프트웨어 시스템의 탄소 발자국을 측정하고 줄이는 방법이 개선되고 있음.

개발자 설문 조사

• 개발자 대부분은 학사(Bachelor) 학위 이상을 소지하며, 온라인 리소스(동영상, 블로그)와 책을 통해 배움.
• 자바스크립트가 가장 인기 있는 프로그래밍 언어로, 파이썬과 SQL이 그 뒤를 잇음.
• AWS는 가장 널리 사용되는 클라우드 기술로, Azure와 GCP가 뒤따름.

API 보고서

• 대부분의 응답자는 API가 수익을 창출한다고 보고함. 특히 금융 서비스와 광고 산업에서 중요함.
• API 프로페셔널은 코딩 도움을 위해 생성적 AI를 사용하며, API 투자가 증가하거나 변하지 않을 것이라고 응답함.

기술 레이더

• AI 보조 소프트웨어 개발과 개발자 경험에 초점을 맞춘 엔지니어링 효율성 측정에 대한 관심이 높음.
• 원격 배달의 workaround는 전염병의 영향으로 완전한 원격 또는 하이브리드 작업이 지속적인 추세로 자리 잡음.

개발자 생태계 상태

• AI 사용: 개발자의 77%가 ChatGPT를 사용하며, GitHub Copilot도 널리 사용됨.
• 프로그래밍 언어: Scala, Go, Kotlin 개발자가 가장 높은 급여를 받음. JavaScript는 TypeScript에 자리를 내주고 있음.
• 개발자 대부분은 합리적인 근무 시간과 급여를 중요시하며, 새로운 기술 및 도구 학습을 전문적 목표로 함.

핵심 요약

• 클라우드 네이티브, 대규모 언어 모델, 지속 가능성이 소프트웨어 아키텍처의 중요한 트렌드임.
• 개발자는 주로 자바스크립트, AWS, AI 도구를 사용하며, API가 비즈니스 수익에 크게 기여함.
• AI 보조 개발, 원격 작업의 확립, 고급 프로그래밍 언어에 대한 수요 증가는 미래의 개발 트렌드를 형성함.

용어 정리

• 디자인 포터빌리티: 소프트웨어의 이식성을 높이기 위해 비즈니스 로직을 구현 세부 사항에서 분리하는 설계 접근법.
• 대규모 언어 모델(LLM): 자연어 처리(NLP)에서 사용되는 인공 지능의 한 형태로, 대규모 데이터셋을 학습하여 언어 관련 작업을 수행할 수 있는 모델.
• 지속 가능성: 소프트웨어 설계와 개발 과정에서 환경적 영향을 최소화하고자 하는 노력.

원문 : [MEDIUM] API Design 101: From Basics to Best Practices

API 디자인 기본부터 최고의 사례까지

• API 디자인 개요: API 디자인은 입력(예: 새 상품에 대한 상품 세부 정보)과 출력(예: 상품 조회 시 반환되는 정보)을 정의하는 것에 초점을 맞춥니다. 이는 인터페이스에 집중함을 의미하며, 낮은 수준의 구현보다는 상호작용 방식을 중시합니다.
• CRUD 작업: 생성(Create), 읽기(Read), 업데이트(Update), 삭제(Delete)는 데이터 기반 애플리케이션의 기본 작업입니다. 이 작업들은 사용자나 시스템이 e-commerce API와 상호작용하는 방식을 정의하는 데 중요합니다.
• 통신 프로토콜 및 데이터 전송 메커니즘: HTTP, WebSockets 등의 통신 프로토콜과 JSON, XML, 프로토콜 버퍼 같은 데이터 전송 메커니즘을 결정하는 것이 포함됩니다.
• API 패러다임: REST, GraphQL, gRPC와 같은 다양한 API 패러다임이 있으며, 각각 고유한 프로토콜과 표준을 가지고 있습니다.
• API 디자인에서의 관계: e-commerce 설정에서 사용자와 주문, 주문과 제품 등과 같은 관계를 가질 수 있으며, 이러한 관계를 반영하여 엔드포인트를 디자인하는 것이 중요합니다.
• 쿼리, 제한 및 GET 요청의 멱등성: GET 요청은 데이터를 변경하지 않고 검색만을 목적으로 해야 하며, 여러 번 호출해도 결과가 변경되지 않는 멱등성을 가져야 합니다.
• 역호환성 및 버전 관리: 엔드포인트를 수정할 때 기존 클라이언트를 깨뜨리지 않도록 역호환성을 유지하는 것이 중요합니다. 버전 관리를 통해 주요 변경 사항을 처리하는 것이 일반적인 방법입니다.
• 속도 제한 및 CORS: 사용자가 특정 시간 동안 요청할 수 있는 수를 제어하기 위해 속도 제한을 설정하는 것이 중요합니다. 또한, 웹 보안을 위해 CORS 설정을 설정하는 것이 일반적입니다.

핵심 요약

• API 디자인은 인터페이스에 초점을 맞추며 CRUD 작업을 통해 사용자와 시스템의 상호작용을 정의합니다.
• 다양한 API 패러다임(REST, GraphQL, gRPC)은 각각의 장단점과 특성을 가지며, 통신 프로토콜과 데이터 전송 메커니즘을 선택하는 것이 포함됩니다.
• API의 역호환성과 버전 관리는 기존 클라이언트를 보호하며, 속도 제한 및 CORS 설정은 API의 안정성과 보안을 유지하는 데 중요합니다.

용어 정리

• CRUD: 생성(Create), 읽기(Read), 업데이트(Update), 삭제(Delete)를 의미하는 데이터 기반 애플리케이션의 기본 작업입니다.
• 멱등성(Idempotence): 동일한 연산을 여러 번 적용해도 결과가 달라지지 않는 성질을 말합니다. GET 요청은 멱등해야 합니다.
• 역호환성(Backward Compatibility): 새로운 버전의 API가 이전 버전과 호환되어 기존 클라이언트가 여전히 작동할 수 있도록 하는 성질입니다.
• CORS (Cross-Origin Resource Sharing): 웹 페이지가 다른 도메인의 리소스에 접근할 수 있도록 허용하는 메커니즘으로, 웹 보안의 중요한 부분입니다.

원문 : [MEDIUM] Mobile Application Architecture vs. Design Patterns

모바일 애플리케이션 아키텍처: 기반 체계 설계

• 정의: 애플리케이션의 전체 구조 및 조직을 설계하는 청사진. 고수준의 구성요소, 그들 간의 상호작용 및 데이터 흐름을 정의.
• 인기 있는 아키텍처 패턴:
  • MVC (Model-View-Controller): 데이터 및 비즈니스 로직(Model), 프레젠테이션 및 UI 관리(View), 사용자 입력에 따른 Model 및 View 업데이트(Controller).
  • MVVM (Model-View-ViewModel): MVC의 진화형, 비즈니스 로직과 UI 분리.
  • Clean Architecture: 관심사의 분리와 의존성 역전을 강조.
  • Redux Architecture: 중앙 집중식 상태 관리와 단방향 데이터 흐름 제공.
• 핵심 고려사항: 애플리케이션의 전반적인 구조를 결정하며, 확장성 및 유지보수성을 용이하게 함.

디자인 패턴: 특정 문제 해결을 위한 솔루션

• 재사용 가능한 솔루션: 개발 과정 중 흔히 마주치는 문제에 대한 베스트 프랙티스 제공.
• 자주 사용되는 디자인 패턴:
  • Singleton Pattern: 클래스의 인스턴스가 단 하나만 존재하도록 보장.
  • Observer Pattern: 객체 간의 일대다 의존성 설정, 상태 변경 시 의존 객체에 알림.
  • Adapter Pattern: 기존 클래스의 인터페이스를 다른 인터페이스로 사용 가능하게 함.
  • Decorator Pattern: 객체에 동적으로 추가 책임을 부여.
• 세부적 문제 해결: 아키텍처 내 특정 문제에 대한 유연한 솔루션 제공.

아키텍처 vs. 디자인 패턴: 격차 해소

• 범위 및 규모: 아키텍처는 전체 애플리케이션의 구조를, 디자인 패턴은 특정 문제를 해결.
• 추상화 수준: 아키텍처는 고수준의 구성요소와 그 상호작용을, 디자인 패턴은 세부적인 코딩 문제를 다룸.
• 유연성 및 적응성: 아키텍처는 앱의 기반을 설정하고, 디자인 패턴은 유연성을 제공하여 변화에 쉽게 적응.

핵심 요약

• 모바일 애플리케이션 개발에서 성공은 견고한 아키텍처와 잘 적용된 디자인 패턴의 조화로운 통합에서 비롯된다. 아키텍처는 전체 프로젝트 구조를 결정하고, 디자인 패턴은 특정 도전 과제를 더 세부적인 수준에서 해결하는 정밀 도구를 제공한다. 이 두 기둥 간의 시너지는 개발자가 모바일 앱 개발의 복잡성을 탐색하게 하며, 시각적으로 매력적일 뿐만 아니라 장기적으로 확장 가능하고 유지보수가 용이한 애플리케이션을 창출할 수 있게 한다.

용어 정리

• MVC (Model-View-Controller): 데이터(Model), 사용자 인터페이스(View), 사용자 입력 처리(Controller)로 구성된 소프트웨어 디자인 패턴.
• MVVM (Model-View-ViewModel): MVC를 발전시킨 패턴으로, ViewModel을 통해 View와 Model 사이의 의존성을 줄임.
• Clean Architecture: 소프트웨어 설계의 관심사 분리를 강조하는 아키텍처 패턴.
• Redux Architecture: 애플리케이션 상태를 관리하기 위한 예측 가능한 상태 컨테이너.

원문 : [MEDIUM] How To Deal With Technical Debt

기술 부채 대처 방법

• 기술 부채는 개발 팀에 큰 불만과 소진을 초래할 수 있으며, 소프트웨어 엔지니어들은 이의 부정적인 영향을 인지하고 있지만, 개발 과정에서 빠르고 쉬운 솔루션을 선택하는 것의 위험성을 제품 팀에 설명할  필요가 있다.
• 워드 커닝햄이 1992년에 기술 부채라는 용어를 처음 사용했으며, 마틴 파울러는 기술 부채 생성의 네 가지 경로를 설명했지만, 특히 스타트업 회사에서 품질보다 속도를 우선시하면서 더 많은 기술 부채가 발생한다.
• 개발자 생산성에 대한 연구에서는 회사가 단기 목표를 위해 품질을 희생하면서 새로운 기술 부채를 도입해야 하는 상황이 자주 발생한다고 한다. 기술 부채는 조직 전체뿐만 아니라 개발자의 행복, 직업 만족도, 그리고 사기에도 영향을 미친다.
• 기술 부채의 주요 문제는 코드가 추상적인 개념이어서 비즈니스와 경영진에게 무슨 일이 발생하는지 설명하기 어렵다는 것이다.
• 기술 부채로 인해 새로운 기능 개발 능력이 감소하고, 시스템의 복잡성이 쌓이면서 개발 사이클당 새 기능에 대한 가능성이 감소한다.

기술 부채의 유형

• 나쁜 코드, 테스팅 부족, 모듈 간의 결합, 구식 라이브러리나 도구 사용, 수동 프로세스, 부적절한 아키텍처, 문서화 부족, 지식 공유 부족 등 다양한 유형의 기술 부채가 있다.

기술 부채와 싸우기 위한 전략

• 기술 부채를 우선시하고, 개발 프로세스와 코드베이스를 분석하여 병목 현상을 찾아내고, 기술 부채 맵을 생성한 후, 해당 부분을 식별하여 우선 순위를 정한다.
• 개발, 병목 현상, 속도 향상 필요성에 대해 투명하게 하고, 모든 이해 관계자가 동일한 이해를 공유할 수 있는 언어로 요약한다.
• 시스템에 대한 명확한 소유권과 책임을 설정하고, 기술 부채 해결을 제품 개발의 자연스러운 흐름에 포함시켜 팀이 문제를 해결할 수 있도록 한다.

핵심 요약

• 기술 부채는 개발 과정에서 불가피하게 발생하지만, 새로운 부채의 생성을 줄이고 기존 부채를 줄이는 전략이 필요하다.
• 다양한 유형의 기술 부채를 인식하고, 이를 관리 및 감소하기 위한 프로세스와 전략이 많은 조직에서 부족하다.
• 기술 부채를 우선 순위에 따라 해결하고, 투명성을 유지하며, 시스템에 대한 명확한 소유권을 확립하고, 팀이 기술 부채를 해결할 수 있도록 하는 것이 중요하다.

용어 정리

• 기술 부채(Technical Debt): 소프트웨어 개발 과정에서 품질을 희생하여 단기 목표를 달성하기 위해 선택한 설계나 코드상의 불완전함으로, 장기적으로 추가 작업이 필요한 상태.
• 코드 품질(Code Quality): 코드가 이해하기 쉽고, 유지보수가 용이하며, 오류가 적은 정도를 나타내는 지표.
• 아키텍처(Architecture): 소프트웨어 시스템의 전체적인 구조와 구성요소, 그 구성요소간의 관계 등을 설계하는 과정 또는 그 결과물.