안녕하세요, 스포카 백엔드팀 프로그래머 남경호입니다.개발자라면 누구나 한 번쯤 더 나은 코드를 작성하고, 팀의 생산성과 유지보수성을 높이기 위해 고민해 보셨을 겁니다. 중복된 코드를 줄이고, 가독성을 높이며, 테스트 코드를 꼼꼼히 작성하거나, 알맞은 변수명을 고심하는 과정은 모두 그런 노력의 일환이죠. 하지만 이런 개선 작업이 효과적으로 이루어지려면, 팀 전체가 공통된 코딩 기준을 공유하고 지키는 것이 무엇보다 중요합니다.일관된 코딩 컨벤션은 단순한 규칙 이상의 역할을 합니다. 특히 여러 명의 개발자로 이루어진 팀에서는 코드의 가독성과 유지보수성을 높이고, 불필요한 논쟁을 줄이며, 협업의 효율성을 극대화하는 강력한 도구가 됩니다. 하지만 이러한 컨벤션을 설정하고, 이를 꾸준히 유지하는 과정은 절대 간단하지 않습니다. 문서로 정리한 규칙이 팀 내에서 제대로 적용되지 않거나, 시간이 지나며 점차 구식이 되는 문제를 겪어보신 분들도 많을 겁니다.우리 스포카 백엔드팀 역시 비슷한 과정을 겪었습니다. 코딩 컨벤션을 관리하기 위해 문서, 코드 리뷰, 그리고 자동화 도구를 활용하며, 더 나아가 Konsist라는 새로운 도구까지 도입하게 된 여정을 통해 다양한 시행착오를 경험했죠. 이 글에서는 단순한 도구 사용법을 넘어, 우리가 직면했던 문제들과 이를 어떻게 극복했는지에 대해 이야기해 보려 합니다.코딩 컨벤션 관리라는 쉽지 않은 도전이 어떻게 우리 팀의 개발 문화를 변화시켰는지, 그리고 여러분의 팀에도 어떤 인사이트를 줄 수 있을지 함께 살펴보시죠.모든 시작은 단순합니다. 우리 팀 역시 처음에는 README.md 파일을 통해 코딩 컨벤션을 관리하기 시작했습니다. 사내 문서 관리 도구인 Confluence를 사용하지 않은 이유는 간단했는데요. 코딩 컨벤션은 코드와 가장 밀접하게 연관되어 있기 때문에, 코드와 가장 가까운 곳에서 관리할 필요가 있다고 판단했기 때문입니다.README.md에는 서버 실행을 위한 준비 작업, IDEA 환경 설정, GIT 브랜치 전략, 그리고 코딩 컨벤션 등 백엔드 개발자가 우리 팀에서 알아야 할 모든 내용이 기재되어 있었습니다. 초기에는, 이 접근법이 꽤 효과적이었습니다. 새로운 팀원이 들어오더라도 문서를 참고해 작업 환경을 설정하거나 코드를 작성할 때 기준을 따를 수 있었으니까요.아래는 저희가 README.md에 작성했던 문서의 일부분입니다.일관된 EOF(End of File) 설정을 위한 가이드이처럼 문서는 개발자가 코드 작성 시 참고할 수 있는 명확한 기준을 제시해 주었고, 코드 리뷰 과정에서도 사소한 논쟁을 줄이는 데 기여했습니다. 하지만 시간이 지나면서 문제점이 하나둘씩 드러나기 시작했습니다.코딩 컨벤션은 한 번 정하고 끝나는 작업이 아닙니다. 시간이 흐르고 조직의 요구사항이나 기술 스택이 변화함에 따라 컨벤션도 업데이트되어야 합니다. 하지만 문서로 관리할 경우, 이를 지속적으로 유지하는 책임자가 없다면 문서가 점차 구식이 되는 문제가 발생합니다.예를 들어, 문서에 설명된 규칙이 실제 코드와 일치하지 않을 때, 팀원들

geuru.geon DevSecOps에서 Sonarqube가 어떤 역할을 하는지 쉽게 파악할 수 있는 글입니다! 평소 Sonarqube 도입에 대해 고민하고 계셨다면, 이번 기회에 안전한 코드로 서비스를 운영해 보시는 건 어떨까요? 😀owen.kh DevSecOps 환경 구성을 위해 카카오페이는 어떤 방향성를 가지고 있는지 알기 좋은 글입니다. 관련해 비슷한 고민을 하는 많은 담당자 분들께 도움이 되었으면 좋겠습니다~안녕하세요, 카카오페이 SRE팀 RE파트 데이빗입니다. 오늘은 DevSecOps와 Sonarqube에 대해 깊이 있게 알아보려고 해요. 어렵게 들리시나요? 걱정 마세요. 차근차근 설명해 드릴게요.DevSecOps가 뭔가요?DevSecOps는 Development(개발), Security(보안), Operations(운영)을 하나로 뭉친 말인데요. 쉽게 말해 “우리 처음부터 끝까지 보안에 신경 쓰면서 개발하자!”라는 뜻이에요. 예전에는 개발을 다 하고 나서 “자, 이제 보안 점검 좀 해볼까?” 하는 식이었어요. 마치 집을 다 짓고 나서 “앗, 도둑이 들어올 수 있겠네. 자물쇠를 달아야겠다!”라고 하는 것과 비슷하죠. DevSecOps는 집을 설계할 때부터 보안을 고려하는 거예요. “이 창문은 좀 위험해 보이니 특수 유리를 쓰자”, “현관문은 이중잠금장치로 하자” 이런 식으로요. 개발할 때도 코드 한 줄 쓸 때마다 “이 로직은 안전한가? 보안에 문제없나?” 생각하면서 만드는 거죠.DevOps와의 차이“그럼 DevOps랑 뭐가 다른데요?”라고 물으실 수 있어요. DevOps가 개발과 운영을 하나로 묶었다면, DevSecOps는 여기에 보안을 더한 거예요. DevOps를 맛있는 케이크를 만드는 과정이라고 생각해 볼까요? 개발팀이 케이크를 구워서 운영팀에게 건네주는 거죠. DevSecOps는 여기에 “케이크에 유해 성분은 없는지, 알러지 유발 물질은 없는지” 확인하는 과정을 추가한 거예요. 더 안전하고 믿을 수 있는 케이크를 만드는 거죠!• 보안을 핵심 요소로 강조• 보안 팀과의 긴밀한 협업전통적인 개발 방식과의 차이전통적인 개발은 마치 릴레이 경주 같았어요. 개발팀이 달리고, 그다음 보안팀이 달리고, 마지막으로 운영팀이 달리는 식이었죠. DevSecOps는 달라요. 세 팀이 손을 잡고 같이 달리는 거예요. 시작부터 끝까지 함께 가는 거죠. 이러면 중간에 실수가 생겨도 빨리 발견할 수 있고, 서로 도와가며 더 빠르고 안전하게 목표에 도달할 수 있어요.DevSecOps를 실제로 구현하려면 어떻게 해야 할까요? 세 가지 핵심 요소가 있어요.자동화와 보안 통합은 DevSecOps의 핵심 요소예요! 자동화는 수동으로 수행하던 많은 보안 관련 작업들을 자동화함으로써 효율성을 높이고 인적 오류를 줄일 수 있어요. 예를 들어 볼까요? 여러분이 매일 아침 100개 이상의 보안점검을 한다고 생각해 보세요. 끔찍하죠? 하지만 보안점검을 진행하고 리포트해 주는 서비스가 있다면 어떨까요? 버튼 하나만 누르면 카테고리와 점검 요약 정보들로 알려주니 훨씬 편

[기술공유] 정적 코드 분석 — SonarQube백엔드팀에서 올해부터 새로운 기술이나 적용해 보고 싶은 기술, 또는 본인이 개발 중에 겪었던 경험을 기반으로 노하우나 방법들을 돌아가면서 발표하는 시간을 가지기로 했습니다. 그 첫번째는 정적 코드 분석 — SonarQube에 관한 내용입니다.정적 코드 분석이란?코드를 실행하지 않고 분석하며 메모리 누수 또는 버퍼 오버플로우 등 일반적으로 알려진 오류 및 취약점 파악 및 표준 코딩 적용에 관한 내용을 분석변경된 코드에 관한 피드백 가능자동화된 검사로 코드 품질을 유지하는데 도움을 주고 기본적인 코드 리뷰 시간 절감 가능프로그래밍된 규칙 위반 사례만 식별 가능하여 실행 시 발생할 오류에 대한 부분이나 예외 사항이 있거나 잘못된 정보를 제공할 가능성이 있어 결과에 대한 확인 필요함SonarQube 특징지속적인 인스펙션지속적인 통합과 같이 빌드와 연동하여 지속적으로 코드에 대한 인스펙션을 수행합니다.품질 중앙화개발 조직의 코드 품질을 중앙 저장소에서 가시화하고 단일 위치에서 관리합니다.DevOps와의 통합다양한 빌드 시스템, CI 엔진과 통합되어 DevOps 실천을 지원합니다.품질 요구사항 설정품질 게이트를 통해 표준화된 코드 품질 요구사항을 설정합니다.다중 언어 분석20개가 넘는 프로그램 언어에 대한 코드 분석을 지원합니다.플러그인을 통한 확장다수의 플러그인을 통해 SonarQube의 기능을 확장할 수 있습니다.내부에서 사용하고 있는 javascript, Typescript 경우엔 무료 버전인 커뮤니티 버전에서도 지원하고 있어서 커뮤니티 버전 기준으로 설명드립니다. 참고로 기본적으로 커뮤니티 버전은 master(메인) 브랜치만 지원하는데 여러 브랜치나 PR에도 적용 가능한 플러그인을 설치하면 제약이 없어집니다. 클라우드 환경도 제공되고 있지만 본 글에서는 설치 버전에 관한 내용입니다.SonarQube 설치SonarQube 설치는 파일로 설치해서 실행하는 방법과 도커를 사용해서 실행하는 방법이 있습니다.(링크)설치 방법이 글에서는 도커로 실행하도록 하겠습니다. 실행 시 별도의 db를 설정해서 연결하지 않으면 서버를 재실행 시 모든 설정값들이 초기화가 되므로 docker-compose를 이용해서 실행하도록 하겠습니다. 참고로 SonarQube 이미지는 위에서 설명한 모든 브랜치를 이용 가능한 플러그인이 포함된 이미지로 작업했습니다. 공식 이미지 사용하고 별도로 플러그인을 설치하셔도 무방합니다.version: "3"services: sonarqube: image: mc1arke/sonarqube-with-community-branch-plugin hostname: sonarqube container_name: sonarqube depends_on: - db environment: SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar SONAR_JDBC_USERNAME: sonar SONAR_JDBC_PAS

안녕하세요 메쉬코리아 플랫폼실 최제필입니다 :) 이번 글에서는 Kubernetes(이하 k8s)에 배포되어 운영하는 여러 MSA를 위해 도입한 CI/CD 도구 및 방법론에 대해 공유하고자 합니다! CI (Continuous Integration)란? 지속적인 통합이란 의미로, 애플리케이션의 새로운 코드 변경 사항이 정기적으로 build 및 test 되어 공유 repository에 통합되는 것. CD(Continuous Delivery or Continuous Deploy) 란? 지속적인 배포란 의미로, 개발자들이 애플리케이션에 적용한 변경 사항이 bug test를 거쳐 repository에 자동으로 업로드되는 것. 즉 CI/CD란 개발 단계를 자동화하여 보다 짧은 주기로 배포하는 전략을 말하는데요. CI/CD 방법론을 적용하면 개발의 편의성이 증가하고, 소스코드 변경부터 배포까지의 작업을 자동화할 수 있기 때문에 수작업으로 할 때의 불편함을 줄일 수 있습니다. 기존 CI/CD Pipeline에는 어떤 문제점들이 있었을까? Mesh Korea의 대부분의 MSA는 JAVA 기반의 기술 스택으로 구성되어 있으며, CI/CD Pipeline을 위해 Bamboo, Spinnaker를 사용하고 있습니다. CI/CD 적용을 위해 개발자가 Bamboo Job / Spinnaker application을 설정해야 하며, 특히 CI <-> CD tool이 연동되어 있지 않아 Bamboo CI에서 빌드 된 Docker image tag를 복사하여 Spinnaker에 손으로 입력해야 하는 등 불편한 점이 많았습니다 Spinnaker는 멀티 클러스터 / 클라우드 배포 등 강력한 기능을 지닌 CD Workflow platform이지만 Mesh Korea의 Kubernetes 숙련도, 단일 Cloud 환경 사용 등 저희가 원하는 기능보다 훨씬 복잡하고 많은 기능을 사용하기 힘든 오버 엔지니어링이라고 판단하였고, 새로운 도구들을 도입하기로 했습니다. 그럼 지금부터 본격적인 CI/CD 도구 및 방법론 도입기, 시작하겠습니다! 다음과 같은 순서로 진행되니 참고 부탁드립니다. Jenkins CI Argo CD CI/CD 도입 및 이전을 위한 자동화 방식 Jenkins CI Mesh Korea의 DevOps를 위한 여러 플랫폼들은 Jenkins CI와 연동되며 k8s cluster에서 실행됩니다. IaC(Infrastructure as Code)를 위한 Terraform, Ansible, Packer 등 Pipeline 실행 시 Pod 내 바이너리가 설치된 컨테이너에서 실행됩니다. 실행되는 모든 CI Pipeline은 Jenkinsfile에 스크립트를 작성하여 실행합니다. CI에 필요한 모든 바이너리는 Jenkins에 설치하는 것이 아닌, 필요한 Container를 지정하여 Pod로 구성하여 독립적으로 실행합니다. 해당 내용을 MSA의 CI Pipeline으로 적용하기 위해 아래와 같은 내용을 진행하였습니다. 공용 CI Pipeline 개발 및 적용 기존 Bamboo에 적