자격증 준비

최근들어 개발자들이 잘 따지않는 자격증에 대한 흥미가 있어 찾던 중, Github에서 제공하는 자격증 시험이 있는것을 봤다.

https://resources.github.com/learn/certifications/

현재는 네가지 자격증을 취득할 수 있는데, 종류는 다음과 같다

Github Foundations : GitHub에서 협업, 기여 및 작업하는 기본 주제와 개념에 대한 이해를 강조
Github Actions : GitHub Actions를 사용하여 워크플로 자동화 및 개발 가속화에 대한 능력을 인증
Github Advanced Security : GitHub Advanced Security 인증을 통해 코드 보안 지식을 강조
Github Administration : GitHub 관리자 시험으로 건강한 GitHub 환경을 최적화하고 관리하는 능력을 인증
Github Copilot : GitHub Copilot 인증 시험은 다양한 프로그래밍 언어에서 AI 기반 코드 완성 도구를 사용하는 기술을 평가 (10월 출시 예정)

자격증 비용으로는 모두 99$ 였으며, Github Foundations의 경우 바우처가 적용되어 49.5$로 응시가 가능했다.

Github 자격증의 경우 국내 블로그 자료를 한번도 본적이 없기 때문에, 딱 이거다 싶어서 바로 자격증 준비를 시작했다. 나는 자격증은 따고 싶으나 별로 내키는 자격증이 없어서 가장 저렴하고 쉬운 foundations를 준비하기로 했다.

아무래도 자료가 없다보니 AWS 자격증을 준비했던 것처럼 편리한 덤프 사이트를 찾기가 어려웠다. 그 중 Github public Repository에서 ghcertified라는 서비스를 볼 수 있었다.

https://github.com/FidelusAleksander/ghcertified

이 서비스는 github 자격증을 준비하는 사람들에게 덤프 문제를 제공해주는 사이트 였는데, 이를 통해 쉽게 공부할 수 있겠다라는 생각을 했다.

하지만 해당 서비스에서 조금 아쉬운점이 있었는데 그것은 바로 구글 번역을 적용 후 다음 문제로 넘어가면, 다시 구글 번역을 적용해야 한다는 점이었다.

부끄럽지만 영어에 익숙하지 않은 나는 이것이 굉장히 불편했다. 그러고보니, 이 레포지토리는 오픈소스로 기여가 가능한 레포지토리 라는점을 깨닫고, 오픈소스 기여를 해야겠다! 바로 생각이 들었다.

오픈소스 기여 할까말까

해당 서비스는 quizdown.js 라는 퀴즈 UI를 빠르게 개발하게 해주는 오픈소스 라이브러리를 사용하고 있었는데, 이 quizdown.js가 바로 다음 퀴즈에 번역이 적용되지 않는 현상이 있었던 것이다. 따라서 이 라이브러리를 살펴보다보니 Svelte라는 언어로 개발되어 있었고, 여기서 포기할까 고민했다. 나는 Svelte를 사용해본적이 전혀 없었기 때문이다. (니꼴라스님 유튜부에서 한번 보긴했다.)

https://github.com/bonartm/quizdown-js

하지만 마음을 다잡고 나는 프로니까 문제가 되는 부분을 천천히 찾아봤고, 나와 동일한 고민을 했던 사람의 StackOverflow 글을 볼 수 있었다.

https://stackoverflow.com/questions/72272843/how-can-i-use-google-translate-directly-on-sveltekit-web-pages

해당 링크의 하단에 이 문제를 또 오픈소스로 만들어서 공유해주신 분이 계셨고, 옳지! 이분의 라이브러리를 quizdown.js에 적용하여 PR을 올리면 되겠다!고 생각했다.

하지만 해당 서비스는 버전 문제가 있었으니,,,

바로 quizdown.js 는 Svelte 3 버전을 사용중이었고, svelte-google-translate 오픈소스는 Svelte 4 버전을 사용중이었다.

어찌저찌 svelte 3에서 4로 마이그레이션 해주는 기능 및 수정이 필요한 부분들을 찾아찾아서 여러가지 시도를 해봤지만, 프레임워크에 대한 지식이 부족하여 아무래도 단기간에 수정하기에는 어려웠다.

따라서, 다른 개발자들의 도움을 얻기로 했다.

오픈소스 고쳐주세요

먼저 svelte-google-translate 오픈소스 개발자님의 레포지토리에 이슈를 생성하여 내가 지금 하고자하는 일에 대해 간략히 설명하고, 하위 호환성을 추가 해줄 수 없냐고 요청드렸다.

그런데 quizdown.js 라이브러리를 4버전으로 올리면 안되냐고 하셔서 제가 못나서 못합니다.. 라고 말씀드렸더니, 이분께서 직접 quizdown.js를 svelte 4 버전으로 마이그레이션 해주셨다!

빨리 PR 봐주세요

하지만 여기서 또 문제가 생겼는데, quizdown.js 라이브러리는 마지막 커밋이 2년전이다. 즉, 더이상 관리되고 있는 라이브러리가 아니었다.

나 지금 이거 빨랑 수정해가지고 자격증 공부하고싶은데, PR 리뷰가 너무 늦어지는 문제가 있었다.

그래서 포크떠서 내가 적용했다.

이러면 안될것 같지만, 내가 quizdown.js 라이브러리를 수정하고, 해당 라이브러리를 적용한 버전의 ghcertified 개인 레포지토리를 새로 팠다. 나처럼 Github 자격증을 따는데 번역 문제로 불편함을 느끼는 사람이 있다면 활용해줬으면 좋겠다. 기능들은 이미 넣어놨으니, ghcertified의 로컬에서 실행하기 위한 문서를 읽고, 로컬에서 해당 서비스를 실행하여 사용한다면 번역 하는데에 번거로움 없이 문제를 풀 수 있다.

https://github.com/gogoadl/ghcertified

느낀점

해외 개발자들과 소통하는 것은 굉장히 재미있기도 하고 많은 경험이 되는 것 같다. 이번 경험을 통해서는 말하는 감자와 같은 나의 요청에 흔쾌히 타인의 오픈소스를 수정해주신 개발자님께 감사를 드리고 싶다. 자 이제 자격증 공부하로 가뿌자

git-submodule

하나의 저장소에서 다른 저장소를 포함하고 관리할 수 있게 해주는 기능

주로 의존성 관리 및 외부 프로젝트 통합에 사용

어떻게 적용하는가

git submodule add {대상 레포지토리}

위 명령어 수행 시 github desktop에서 두가지 파일이 stage 되는것을 알 수 있다.

근데 git add랑 git stage랑 무엇이 다른걸까?

아래의 링크에서 볼 수 있듯이 똑같다고 한다. 이제 다음 스텝으로 가자

https://superuser.com/questions/1395627/differences-between-git-add-and-git-stage

gitmodules 파일에 아래의 내용이 추가 되었다.

[submodule "github-submodule-test"]
    path = github-submodule-test
    url = https://github.com/gogoadl/github-submodule-test.git

branch를 직접 지정해줄수도 있다고 한다.

또한 submodule을 추가 했던 레포지토리 자체의 변경사항도 있다고 나온다.

위 내용을 푸쉬하면 submodule이 등록된것을 확인 할 수 있다.

submodule 업데이트 반영

submodule을 포함하여 개발 중 submodule의 업데이트가 발생할 수 있다. 이를 반영하는 방법은 아래와 같다.

# .gitmodules 파일에 정의되어 있는 브랜치의 최신 버전으로 업데이트 (혹은 default 브랜치)
git submodule update --remote

역시나 다양한 케이스의 업데이트 방식을 지원하는 것 같다. 궁금하면 좀 더 찾아보자.

submodule 실제 활용 케이스 살펴보기

예전에 한글화에 기여했었던 서비스인 fxsound의 경우 서비스의 문자열 데이터를 저장하고 있는 Strings 레포지토리를 submodule로 관리하는 것을 알 수 있다.

현재 기여를 준비하고 있는 gihub가 주관하는 자격증의 시험 문제 덤프 서비스인 ghcertified에서도 .gitmodules로 서브모듈을 관리하고 있다. (이미지에 노란색으로 표시했다.)

이 프로젝트에서는 레포지토리 자체에서 submodule을 가지고 있지 않고, 필요할 때 submodule update를 통해 가져오도록 문서에서도 안내하고 있다.

마무리

submodule이 무엇인지, submodule을 어떻게 활용할 수 있는지 간단히 살펴보았다.

지금 당장 나에게 필요한 기능은 아니지만, 추후 필요할 때 사용할 수 있게끔 숙지해두자.

Github Security

왜 사용하나

오픈소스와 같은 많은 사용자들이 이용하는 소스코드에 취약점이 발견 될 경우, Security 탭에서 취약점을 보고 할 수 있다.

취약점을 보고 할 경우 가시성은 해당 레포지토리의 관리자 및 협력자에게만 표시되며, 이를 통해 해당 취약점을 내부 관계자들이 파악하고 조치할 수 있다.

Github Security Policy

저장소에 보안 정책을 추가하여 프로젝트의 보안 취약점을 보고하는 방법에 대한 지침을 제공 할 수 있다.

Github 에서는 각 레포지토리마다 각자의 다양한 정책을 가지고 있다. 예를 들면 Pull Request Template, Issue Template 또는 Contributor가 되기 위해 미리 숙지 해야할 것들과 같이, 보안 이슈를 보고하기 위해서도 사용자들이 보안 취약점을 보고하기 위한 가이드를 제공할 수 있다.

어떻게?

저장소의 루트, docs, .github 폴더에 SECURITY.md 파일을 추가할 수 있다. 이 파일을 앞에 언급한 저장소의 폴더에 생성 할 경우 사람들이 검토할 수 있는 설명이 있는 행이 자동으로 생성된다.

이를 통해 다른 사용자가 취약점 보고를 위한 가이드라인과 정보를 얻을 수 있다.

Github Report Vulnerabilities

만약 레포지토리의 소스코드에서 보안 취약점을 발견 한 경우 Private vulnerability reporting 을 활성화 하여 사용자들로부터 보안 취약점 보고를 받을 수 있다.

이를 활성화 한 경우 보안 취약점을 보고 할 수 있는데, 아래와 같은 폼으로 해당 보안 취약점에 대해 자세히 설명할 수 있다.

아무래도 보안 취약점이므로, 어떤 문제가 발생하는지, 이슈 재연 시나리오 및 해당 취약점을 검증하는 프로세스가 기본 폼으로 작성되어 있다.

마무리

짧지만, 최근들어 Github Foundations를 공부하면서 Github에서 제공하는 다양한 기능들을 간단히 소개해보고자 한다. Github Foundations는 국내에서 검색했을 때 자료가 없었고, 여기서 배운 내용들이 한국 개발자들이 Github를 더 효율적으로 사용하고, 필요했었지만 기능의 존재 유무조차 알지 못해 넘어갔던 부분들을 어느정도 해소시킬 수 있지 않을까 생각한다.

Github 시험 오답노트

Github가 오픈소스 프로젝트에 대해 제공하는 것

• 소프트웨어 개발 워크플로우 전반에 걸쳐 학습하고 활용할 수 있는 모범 사례
• 소프트웨어 개발 기능 및 서비스
• 보고된 보안 취약점을 식별하고 수정하기 위한 코드 스캐닝

-> 법적 준수는 강제하지 않는다.

Github Organization내의 청구 관리자가 수행 가능한 것

• 계정 업그레이드, 다운로드
• 결제 방법 추가, 업데이트 또는 제거
• 결제 내역 보기
• 영수증 다운로드
• 청구 관리자 보기, 초대 및 제거
• 스폰서십 시작, 수정 또는 취소
• 모든 청구 관리자는 조직의 청구일에 이메일로 청구 영수증을 받게 된다.

수행할 수 없는 것

• 조직에서 저장소를 만들거나 액세스
• 조직의 비공개 회원 보기
• Github Marketplace 앱에 대한 구독, 구매, 편집 또는 취소
• Github Copilot Business 구독 구매, 편집 또는 취소

Github Repository에서 이슈를 생성 할 수 있는 사람은?

• 저장소에 대한 읽기 액세스 권한이 있는 모든 Github 사용자

Gist를 만들기 위해서는 저장소 홈페이지 대신 Gist 홈페이지로 이동하여 생성할 수 있다.

Github Projects Insight를 통해 팀원에게 할당된 항목 수를 시각화 하는 차트 만들기

현재 차트 - 각 개인에게 할당된 항목 수, 각 다가올 스프린트에 할당된 이슈 수

기록 차트 - 사용자에게 할당된 기존 항목이 아닌 프로젝트 항목의 상태 변경 사항 추적
사용자 차트 - 유효한 차트 유형이 아님.
프로젝트 차트 - 유효한 차트 유형이 아님.

Github Projects에서 사용 가능한 레이아웃 종류

• 보드 레이아웃 - 칸반 보드 형식
• 로드맵 레이아웃 - WBS 형식?
• 테이블 레이아웃 - 노션 데이터베이스 형식

리스트 레이아웃은 존재하지 않음.

Github Mobile에서 사용할 수 있는 기능

• 이슈, 풀 리퀘스트를 읽고, 검토 및 협업
• 알림 관리, 분류 및 지우기
• 풀 리퀘스트에서 웹 기반 코드 편집

Github Mobile에서 사용할 수 없는 기능

자동화된 테스트 및 지속적인 통합

Github Advanced Security (GHAS) 라이센스에 포함되는 기능

1. 종속성 검토 - 풀 리퀘스트 병합 전 종속성 변경 사항의 전체 영향을 보여주고 취약한 버전의 세부정보 확인
2. 비밀 스캐닝 - 키와 토큰과 같은 비밀 감지, 푸시 보호가 활성화된 경우 저장소 푸시될 때 비밀도 감지
3. 코드 스캐닝 - 코드에서 잠재적인 보안 취약점과 코딩 오류 검색

Github Projects를 사용하면 조직 프로젝트, 사용자 프로젝트 두 가지 유형의 프로젝트 생성 가능

Codespaces를 효율적으로 리소스 활용을 보장하며 비용을 줄이는 방법

-> Codespace 자동 삭제를 위한 기본 보존 기간을 줄인다.
비활성 코드스페이스는 자동 삭제된다. 또한, 중지된 코드스페이스를 보관할 기간을 최대 30일 까지 선택할 수 있다. 그러나 Codespaces는 스토리지 요금이 부과되므로 기본 기간을 변경하여 보관 기간을 줄이는 것이 좋다.

Github 무료 플랜에서는 이슈 및 풀 리퀘스트에 공개 저장소의 경우 최대 10명, 비공개 저장소의 경우 1명까지 할당 가능하다.

Github Actions 구성 요소 중 동일한 러너에서 실행되는 단계로 구성되는 것은
-> Job

Event - 워크플로 실행을 트리거하는 특정 활동
Action - 실행되는 스크립트
Workflow - 하나 이상의 Action을 실행하는 전체 프로세스

개요

백엔드 포지션으로 새로운 길을 시작한 이후 3개월이 지났다. 사실 업무를 진행하면서 그동안 내가 노력해왔던 것들이 헛되지 않았다고 생각할 만큼 업무에 있어서는 아직 자신감이 있는 것 같다. 하지만 그 외적인 부분으로 역시 개선해야 할 일들이 많이 남아있다. 3개월간 업무? 또는 삶에 있어서 다시한번 생각해야 할 것들을 이번 회고에 포함하여 짧게 적어본다.

1. 메타인지

최근들어 가장 많이 느끼고 있는 키워드는 바로 “메타인지”이다. 내가 지금 어떠한 상황에 처해있고, 나의 어떤 장점들을 활용해서 사람들에게 도움을 줄 지 생각해야 한다. 프로젝트를 진행하면서도, 팀원들이 처한 상황은 모두 다르다. 그 상황에서 누군가는 자신의 성장을 위해서 빠르게, 또 누군가는 자신의 또 다른 목적을 위해서 느리게 행동한다면, 프로젝트에 참여한 다른 팀원들에게 불편함을 줄 수 있지 않을까한다. 본인이 현재 속해있는 팀의 상황을 잘 파악하고, 본인이 할 수 있는 최선을 다 하자. 내가 그 팀에서 하고자 하는것을 이룰수 없다면 떠나면 된다. 절이 싫다면 중이 떠나는 것이다.

2. 끊임없이 노력하자

내가 아무리 노력하고 있다고 해도, 이 업계는 괴물같은 사람이 계속 나타나기 마련이다. 프로젝트에서 사람들이 배려해주는 것을 당연하게 생각하지 않고 꾸준히 자신의 목표를 향해 노력해야 한다. 나의 편의를 봐주는 사람들을 위해 계속 노력하고 발전하고, 그들이 편의를 봐준 만큼, 그들이 필요로 할 때 내가 도움이 될 수 있게 노력해야 한다.

3. 나를 필요로 하는 사람을 찾자

하찮은 이력이지만, 나의 도움을 필요로 하는 사람들에게 최선을 다해야 한다. 중요한 키워드는 “나를 필요로 하는 사람을 내가 찾을 것”이다. 이 행동은 타인을 위한 것이기도 하지만, 나를 위한 것이기도 하다. 도움이 필요한 사람들에게 자존심 세우지 않고, 나를 필요로 하는 사람을 적극적으로 찾자. (사실 도움을 주기보다, 깨닫는 것이 더 많을때가 많은 것 같다.)

4. 사회성 기르기

최근들어 사람들과 대화를 할 때 말하고 나서 “이 말을 지금 하면 안될 것 같은데” 라는 생각이 든적이 많은 것 같다. 아무래도 개발과 같은 업무 위주로 많이 생각하다 보니 사회성이 떨어지는 것 같다. 일도 중요하지만, 사회는 결국 더불어 살아가는 것이다. 사람들과의 관계를 절대 소홀히 하지 말도록 하자.

Github Issue Form

Github를 사용하면서 주로 이슈 템플릿을 활용하여 이슈를 관리 했었는데, Github Foundations를 공부하면서 다른 형식으로 이슈 관리를 제공하는 Issue Form에 대해 알게되어 소개하고자 글을 포스팅 합니다.

이미 Github Issue Template를 사용해 본 경험이 있고, Github에 친숙한 분들을 대상으로 빠르게 글을 작성해봅니다.

Issue Form 생성하기

Issue Form은 기존 이슈 템플릿과 동일하게 레포지토리 내의 .github/ISSUE_TEMPLATE/ 경로에서 이슈 폼 파일을 정의할 수 있습니다.

사용하고자 하는 폼의 유형에 따라 .yml 파일을 정의하면 되는데, Github 문서 에서 제공하는 기본 이슈 폼을 그대로 작성해보겠습니다.

아래의 내용으로 .github/ISSUE_TEMPLATE/bug.yml 파일을 생성 합니다.

자세한 yml 파일 구성 양식은 Github Issue Form 공식 문서에서 확인할 수 있습니다.

https://docs.github.com/ko/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms

name: Bug Report
description: File a bug report.
title: "[Bug]: "
labels: ["bug", "triage"]
projects: ["octo-org/1", "octo-org/44"]
assignees:
  - octocat
body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to fill out this bug report!
  - type: input
    id: contact
    attributes:
      label: Contact Details
      description: How can we get in touch with you if we need more info?
      placeholder: ex. email@example.com
    validations:
      required: false
  - type: textarea
    id: what-happened
    attributes:
      label: What happened?
      description: Also tell us, what did you expect to happen?
      placeholder: Tell us what you see!
      value: "A bug happened!"
    validations:
      required: true
  - type: dropdown
    id: version
    attributes:
      label: Version
      description: What version of our software are you running?
      options:
        - 1.0.2 (Default)
        - 1.0.3 (Edge)
      default: 0
    validations:
      required: true
  - type: dropdown
    id: browsers
    attributes:
      label: What browsers are you seeing the problem on?
      multiple: true
      options:
        - Firefox
        - Chrome
        - Safari
        - Microsoft Edge
  - type: textarea
    id: logs
    attributes:
      label: Relevant log output
      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
      render: shell
  - type: checkboxes
    id: terms
    attributes:
      label: Code of Conduct
      description: By submitting this issue, you agree to follow our [Code of Conduct](https://example.com). 
      options:
        - label: I agree to follow this project's Code of Conduct
          required: true

성공적으로 레포지토리 내에 파일을 생성 한 경우, Github에서 새로운 이슈를 생성하면 다음과 같이 이슈 폼을 선택할 수 있습니다.

이슈 생성 화면을 보면 기존 이슈 템플릿보다 편리하고 구조화된 이슈를 생성하는 폼을 제공합니다. 

생성된 이슈는 이슈 템플릿으로 생성한 형식과 동일하게 표시됩니다.

이슈폼을 직접 생성해보면서 느낀점은 이슈의 형식에 좀더 제한을 두어, 더욱더 강력하고 편리하게 이슈를 관리할 수 있겠다고 느꼈습니다. 다음에 Github 에서 프로젝트를 관리할 일이 생긴다면, 이슈 폼을 적극 도입하지 않을까 합니다.

또한, 현재 이슈 폼은 베타 버전으로 언제든지 변경될 가능성이 있다고 합니다.

Git 용어

• 작업 트리 : 작업 중인 프로젝트가 들어 있는 중첨된 디렉토리와 파일의 집합
• 저장소 : 작업 트리의 최상위에 위치한 디렉토리, 모든 기록과 메타데이터를 보관
• 해시 : 해시 함수에 의해 생성된 숫자로, 파일이나 다른 객체의 내용을 고정된 숫자로 나타냄. Git은 160비트 길이의 해시를 사용
• 객체 : 블롭객체 - 일반 파일, 트리객체 - 디렉토리, 커밋객체 - 특정 버전,

SCM 소프트웨어 구성 관리 시스템 = VCS

git merge --abort
현재 진행중인 merge를 모두 삭제하고 merge를 시도하기 전으로 되돌림.

개인 저장소
본인, 본인이 명시적으로 접근 권한을 공유한 사람, 조직 저장소의 경우 특정 조직 구성원만 접근 가능

Github 계정 유형

Personal

• Github Free, Github Pro
• Guthub Free 사용자의 경우 개인 계정이 소유한 비공개 저장소는 제한된 기능 사용가능

Organization

• 계층적 접근 방식
• 조직 소유자 및 보안 관리자만이 조직의 설정을 관리 및 데이터에 대한 액세스 제어

Enterprise

• 관리자가 여러 조직의 정책과 청구를 중앙에서 관리하고 조직간의 내부 소싱을 활성화
• 조직 수준에서 정책에 사용할 수 있는 옵션 제어
  • SSO를 통한 인증
  • 보안, 규정 준수 및 배포 제어 강화
  • Github Actions를 사용한 비공개 또는 내부 저장소에 대한 배포 보호 규칙 Github Connect
• Github Enterprise Server - 조직이 인프라를 완벽하게 제어
• Github Enterprise Cloud

Github 청구

• 구독 : Github Pro, Github Team과 같은 사용자 계정 플랜과 Github Copilot, Github Marketplace와 같은 월별 비용이 발생하는 유료 제품 포함
• 사용 기반 청구 : 유료 제품의 비용이 제품을 얼마나 많이 사용하느냐에 따라 달라질 때 적용

Github Copilot

• ChatGPT와 유사한 경험 제공

  개발자 시나리오에 초점을 맞춘 편집기에 채팅 인터페이스를 제공하여 VS Code, Visual Studio와 기본적으로 통합됨.
  개발자가 입력한 코드, 표시된 오류 메세지를 인식하며 IDE에 내장되어 있다.
  개발자는 코드 블록이 수행하려는 작업에 대한 심층 분석 및 설명을 얻고, 단위 테스트 생성, 버그에 대한 제안된 수정사항을 얻을 수 있다.

• Pull Request를 위한 Copilot

• 문서에 대한 AI 생성답변

• 명령줄 인터페이스를 위한 copliot

• Github Copilot Business

• 회사에서 누가 Github Copilot을 사용할 수 있는지 제어할 수 있다.

• Github Copilot Enterprise

  조직을 위한 추가 개인화 계층과 개발자가 플랫폼 전체에서 코드베이스와 작업 버튼에 대해 대화할 수 있도록 하는 채팅 인터페이스로 Github와 통합

Github Codespace

Codespace를 만드는 방법

• Github 템플릿이나 Github.com의 템플릿 저장소를 이용해 새로운 프로젝트 시작
• 저장소의 브랜치에서 새로운 기능 작업
• 공개된 풀 리퀘스트를 통해 진행 중인 작업 살펴보기
• 저장소 기록의 커밋에서 특정 시점의 버그 조사

일시적으로 Codespace를 사용하여 코드 테스트, 동일한 Codespace로 돌아와 장기적으로 실행되는 기능 작업을 진행할수도 있다.

Github Project

Inner Source

제한된 대상을 가진 프로젝트에 오픈소스 패턴을 적용하는 관행.

ex) 어떤 회사는 일반적인 오픈소스 프로젝트의 구조를 반영하는 InnerSource 프로그램을 만들수 있지만, 그 회사의 직원만 접근할 수 있다.

회사의 방화벽 뒤에 있는 오픈소스 프로그램

InnerSource의 이점

1. 투명성 장려

   다른 회사 프로젝트의 소스코드에 대한 액세스는 생산성을 높이는데 도움이 될 수 있다. 다른 팀이 직면한 것과 유사한 문제를 어떻게 해결했는지와, 재사용할 수 있는 코드와 자산을 찾을 수 있다.

2. 마찰을 줄인다

   소비자 팀이 다른 팀이 소유한 프로젝트의 버그 수정이나 새로운 기능에 의존하는 경우, 그들은 필요한 변경사항을 제안할 수 있는 채널을 가질 수 있다.

3. 관행을 표준화

   InnerSource 프로그램을 구축하는 것은 동일한 관행을 따르지 않더라도 모든 개발 팀에서 사용할 수 있는 표준 규칙을 채택할 수 있는 좋은 기회이다.

저장소 가시성 및 권한 설정

• 공개 저장소 : 이 가시성은 진정으로 오픈소스이며, 조직 내부, 외부 사람들에게 액세스를 제공하는 프로젝트에 사용
• 내부 저장소 : 소유한 조직의 구성원에게만 표시. InnerSource 프로젝트에 이 가시성을 사용
• 비공개 저장소 : 소유자 및 그들이 추가한 팀 또는 개인에게 표시. 특정 사용자와 그룹만 액세스 할 수 있는 프로젝트에 이 가시성을 사용

권한 수준

• 읽기 : 프로젝트를 보거나 논의하고 싶은 비코드 기여자에게 권장
• 트리아지 : 쓰기권한 없이 이슈와 풀리퀘스트를 적극적으로 관리하는 기여자
• 쓰기 : 프로젝틍 ㅔ적극적으로 참여하는 기여자
• 수준 유지 : 민감하거나 파괴적인 작업에 접근하지 않고 저장소를 관리하는 프로젝트 관리자
• 관리자 : 프로젝트에 대한 전체 액세스 권한

안전한 Github 저장소를 유지하는 방법

보안 애플리케이션을 빌드하고 배포하는 데에 고려해야 할 세가지 사항

• 일반적인 지식 문제

  많은 개발자와 직원들이 보안을 이해한다고 생각하지만, 실제로 그렇지 않다. 지속적인 교육 및 훈련 프로그램이 필수적이다.

• 코드는 올바르고 안전하게 생성되어야 함

  기능이 보안을 염두에두고 설계되었는지도 확인해야 한다.

• 애플리케이션은 규칙과 규정을 준수해야 함

  코드를 빌드하는 동안 준수 여부를 테스트하고 배포 후에도 주기적으로 다시 테스트 해야한다.

보안 탭 기능

Github는 저장소와 조직 전반에서 데이터를 안전하게 유지하는데 도움이 되는 보안 기능을 제공한다.

• SECURITY.md 저장소에 파일을 추가하여 프로젝트의 보안 취약점을 보고하는 방법을 지정할 수 있는 보안 정책
• Github에서 저장소가 취약한 종속성이나 멀웨어를 사용하고 있음을 감지하면 알려주는 Dependabot 알림
• 코드의 취약점과 오류를 찾고, 분류하고, 수정하는데 도움이 되는 코드 스캐닝

Github Authentication

Github에서 인증하는 데에는 여러가지 옵션이 있다.

• 사용자 이름과 비밀번호
• 개인 액세스 토큰 (PAT)
• SSH 키

Github의 추가 보안 옵션

• 2FA
• SAML SSO
• LDAP
  Lightweight Directory Access Protocl(LDAP)는 디렉토리 정보 서비스에 액세스하고 유지하기 위한 애플리케이션 프로토콜. 타사 소프트웨어를 대기업 사용자 디렉토리와 통합하는데 사용되는 가장 일반적인 프로토콜

팀 권한 수준

조직 권한 수준

엔터프라이즈 권한 수준

CODEOWNERS 파일 추가

팀원이나 전체 팀을 저장소의 코드를 담당하는 코드 소유자로 지정 가능. 누군가가 코드 소유자에게 속한 코드를 수정하는 풀 리퀘스트를 열면 코드 소유자는 자동으로 검토자로 요청 됨

개요

이 튜토리얼에서는 Spring Boot 애플리케이션의 로깅 수준을 런타임에 변경하는 방법을 살펴보겠습니다. 많은 것들과 마찬가지로 Spring Boot에는 우리를 위해 구성하는 기본 제공 로깅 기능이 있습니다 . 실행 중인 애플리케이션의 로깅 수준을 조정하는 방법을 살펴보겠습니다.

이를 위해 세 가지 방법을 살펴보겠습니다. Spring Boot Actuator 로거 엔드포인트를 사용하는 방법, Logback 의 자동 스캔 기능을 사용하는 방법 , 마지막으로 Spring Boot Admin 도구를 사용하는 방법입니다.

이 번역본에서는 Spring Boot Actuator를 통해 로깅 레벨을 변경하는 방법만 안내합니다.

Spring boot Actuator

/ loggers Actuator 엔드포인트를 사용하여 로깅 레벨을 표시하고 변경하는 것으로 시작하겠습니다 . / loggers 엔드포인트는 actuator/loggers 에서 사용할 수 있으며 경로의 일부로 이름을 추가하여 특정 로거에 액세스할 수 있습니다.

예를 들어, URL http://localhost:8080/actuator/loggers/root 를 사용하여 루트 로거에 접근할 수 있습니다.

설정

Spring Boot Actuator를 사용하여 애플리케이션을 설정하는 것부터 시작해 보겠습니다.

먼저, pom.xml 파일 에 Spring Boot Actuator Maven 종속성을 추가해야 합니다 .

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
    <version>3.1.5</version>
</dependency>

gradle을 통해 종속성 추가

implementation 'org.springframework.boot:spring-boot-starter-actuator:3.1.5'

대부분의 엔드포인트는 기본적으로 비활성화되어 있으므로 application.properties 파일 에서 / loggers 엔드포인트 도 활성화해야 합니다 .

management.endpoints.web.exposure.include=loggers
management.endpoint.loggers.enabled=true

마지막으로, 실험의 효과를 볼 수 있도록 일련의 로깅 명령문을 포함하는 컨트롤러를 만들어 보겠습니다.

@RestController
@RequestMapping("/log")
public class LoggingController {
    private Log log = LogFactory.getLog(LoggingController.class);

    @GetMapping
    public String log() {
        log.trace("This is a TRACE level message");
        log.debug("This is a DEBUG level message");
        log.info("This is an INFO level message");
        log.warn("This is a WARN level message");
        log.error("This is an ERROR level message");
        return "See the log for details";
    }
}

/ loggersEndpoint 사용

애플리케이션을 시작하고 로그 API에 접근해 보겠습니다.

curl http://localhost:8080/log

그럼, 로그를 확인해 볼까요? 로그에는 세 개의 로깅 문장이 있습니다.

2019-09-02 09:51:53.498  INFO 12208 --- [nio-8080-exec-1] c.b.s.b.m.logging.LoggingController      : This is an INFO level message
2019-09-02 09:51:53.498  WARN 12208 --- [nio-8080-exec-1] c.b.s.b.m.logging.LoggingController      : This is a WARN level message
2019-09-02 09:51:53.498 ERROR 12208 --- [nio-8080-exec-1] c.b.s.b.m.logging.LoggingController      : This is an ERROR level message

이제 / loggers Actuator 엔드포인트를 호출하여 com.baeldung.spring.boot.management.logging 패키지 의 로깅 수준을 확인해 보겠습니다.

curl http://localhost:8080/actuator/loggers/com.baeldung.spring.boot.management.logging
  {"configuredLevel":null,"effectiveLevel":"INFO"}

로깅 수준을 변경하려면 / loggers 엔드포인트 에 POST 요청을 발행할 수 있습니다.

curl -i -X POST -H 'Content-Type: application/json' -d '{"configuredLevel": "TRACE"}'
  http://localhost:8080/actuator/loggers/com.baeldung.spring.boot.management.logging
  HTTP/1.1 204
  Date: Mon, 02 Sep 2019 13:56:52 GMT

로깅 수준을 다시 확인하면 TRACE 로 설정되어 있어야 합니다.

curl http://localhost:8080/actuator/loggers/com.baeldung.spring.boot.management.logging
  {"configuredLevel":"TRACE","effectiveLevel":"TRACE"}

마지막으로, 로그 API를 다시 실행하여 변경 사항이 실제로 어떻게 적용되는지 확인할 수 있습니다.

curl http://localhost:8080/log

이제 로그를 다시 확인해 보겠습니다.

2019-09-02 09:59:20.283 TRACE 12208 --- [io-8080-exec-10] c.b.s.b.m.logging.LoggingController      : This is a TRACE level message
2019-09-02 09:59:20.283 DEBUG 12208 --- [io-8080-exec-10] c.b.s.b.m.logging.LoggingController      : This is a DEBUG level message
2019-09-02 09:59:20.283  INFO 12208 --- [io-8080-exec-10] c.b.s.b.m.logging.LoggingController      : This is an INFO level message
2019-09-02 09:59:20.283  WARN 12208 --- [io-8080-exec-10] c.b.s.b.m.logging.LoggingController      : This is a WARN level message
2019-09-02 09:59:20.283 ERROR 12208 --- [io-8080-exec-10] c.b.s.b.m.logging.LoggingController      : This is an ERROR level message

Reference

https://www.baeldung.com/spring-boot-changing-log-level-at-runtime

첫 오픈소스 기여 후기

2024년 취업과 동시에 여러가지 목표가 있었는데, 그 중 하나인 오픈소스 기여를 매우 간단하게 성공했던 후기를 공유해보고자 한다. 많은 개발자들이 어렵게 생각하는 만큼, 나 역시 “나 같은 하찮은 개발자가 오픈소스에 기여할 수 있을까?” 고민 했었지만, 역시 일단 하고 두들겨 맞는게 가장 빠르게 목표를 달성할 수 있다고 생각하여 오픈소스에 기여할 방법을 찾아봤다.

오픈소스 기여 대상 탐색

처음에는 Github에서 Major한? 프레임워크(Vue.js, Spring Framework)를 대상으로 기여를 하려고 했으나, 이미 많은 사람들이 참여하고 있는 프로젝트들인 만큼 내가 기여할 수 있는 부분을 빠르게 찾기는 어려웠다. 그래서, SSAFY 자율 프로젝트 진행 중 피쳐플래깅 서비스로 레퍼런스에 이용했었던 Unleash라는 서비스를 보던 중, 충분히 납득할만한 기여사항을 발견하여 이 프로젝트의 문서화에 기여하기로 했다.

문서화 기여

해당 서비스는 피쳐 플래깅 서비스의 Java측 SDK로, ReadMe에 해당 서비스를 사용하기 위한 설정들이 적혀 있었는데, Maven 프로젝트 기준으로 세팅하는 방법이 적혀 있었다. 나는 평소 Gradle로만 프로젝트를 진행했었고, 많은 주니어 개발자들이 비슷한 경험을 했을것이라고 생각했다. 따라서, Gradle로 SDK 의존성을 추가하는 간단한 ReadMe를 작성했다.

아주 하찮은 수정사항이지만 해당 수정사항을 반영해야 하는 이유에 대해서 정성스레 PR을 올렸고, PR을 올린지 두시간만에 리뷰어님이 Approve와 함께 Merge를 진행해주셨다.

오픈소스 기여 후기

오픈소스에 기여하는것이 3년 이내에 해야할 버킷리스트에 포함되어 있을만큼 도전해보고 싶었던 일인데 정말 쉽고 빠르게 목표를 달성하여 기분이 좋기도 하고, 왜 진작 시도해보지 않았을까? 라는 생각도 든다. 비록 지금은 문서 수정이지만 앞으로 여러 오픈소스 프로젝트에 참여하고 국내 및 해외 개발자들과 소통하며 다양한 경험을 하고싶다.

SSAFY에서의 1년 회고하기

SSAFY 10기, 자바 전공반 합격 및 수료 후기

SSAFY 준비

에세이

23년 4월 중순에 SSAFY 서류 접수 기간이었던것으로 기억한다. 서류같은 경우 짧은 500자의 에세이를 작성했는데, 여러 블로그 글들을 참고하여 “내가 무엇을 잘한다” 라는 느낌 보다는 “내 부족한 점들을 SSAFY에서 얻어가겠다.” 라는 느낌으로 글을 작성했고, 서류 합격을 받을 수 있었다.

코딩 테스트

코딩 테스트의 경우 가끔씩 2~3 문제씩, SWEA, 백준 문제를 풀었다. 코딩테스트를 잘 하는 편은 아니지만 설렁설렁 준비했는데 두문제 다 맞았다. 크게 어려운 느낌은 없었다. 텅텅 비어있는 커밋 기록..

인터뷰 준비

면접 부터는 조금 어려웠는데, PT면접이 처음이라 면접스터디를 진행했다. 강민혁님 유튜브 영상을 많이 참고했고, 4차산업 관련된 IT 기술들에 대해서 조사하고 공부했었다. 인터뷰를 망치는 바람에 떨어졌었는데, 추가합격으로 SSAFY 10기 교육을 들을 수 있었다.

SSAFY 1학기

SSAFY 1학기 전공 자바반의 경우 기본적인 개발 역량과 더불어 알고리즘, Java Spring, Vue.js 개발에 대해서 배울 수 있었다. 강사님들마다 각각 교육하는 스타일이 다른 것 같았는데, 우리 강사님의 교육 방식은 많은 도움이 되었다. 첫번째로, 알고리즘 스터디를 권장하셔서 이전보다 알고리즘 역량이 많이 늘었던 것 같다. 두번째로, 기술 질문에 대해 정성스럽게 대답해주시고 경험에 기반한 설명과 함께 이론을 설명해주셔서 이해가 빠르게 되었다. 또한 1학기 막바지에는 프로젝트를 진행하는데, 이 프로젝트는 크게 도움이 되지는 않았던 것 같다. (2학기에 비해서..)

1학기는 아래의 키워드들로 얘기할 수 있을 것 같다.

1. 알고리즘
2. Spring Framework + Vue.js
3. 공통 프로젝트

SSAFY 2학기

SSAFY 2학기는 전공, 비전공 관계없이 모여 3개의 프로젝트를 진행한다. 프로젝트는 담당 컨설턴트님과 실습코치님이 함께 개발 방향을 도와주는데, 성향에 맞는 컨설턴트님과 코치님을 만나는 것도 중요한 것 같다. 2학기의 경우에는 시간도 부족하고 취준도 함께 진행하다보니 갈등이 생기기도 하고, 힘든 시간이었던 것 같다. 나는 프로젝트 경험보다 서류 작성 방법, 기업 분석과 같은 전공 지식을 제외한 취업준비가 필요했기에, 3개의 프로젝트 중 두번째인 특화 프로젝트에서는 주로 취준에 집중 했었다. SSAFY에서는 이러한 점을 좋게 여기지 않았는데, 왜냐하면 SSAFY 2학기는 취업 준비를 하는 기간이 아니라 프로젝트를 진행하는 기간이기 때문이다. 아무튼 나의 경우 이 기간동안 취업 준비를 많이 했고, 서류를 합격하는데 많은 도움이 되었던 것 같다.

SSAFY 수료

SSAFY를 수료함과 동시에 취업이 되어서 생각지도 못한 외국계 기업에서 일을 하게 되었다. 또한 SSAFY 에서의 1년간 교육을 수료하면서 많은 것들을 느낄 수 있었다. 기업의 채용 과정과 같이 에세이, 코딩테스트, 면접을 통해 교육생을 선정하다 보니 상향 평준화된 인원들과 함께 개발을 진행할 수 있는 소중한 기회였다. 또한, 학생 신분임에도 현업 개발자로 일했던 나보다도 깊은 지식을 가지고, 또 개발에 대한 열정을 가지고 임하는 몇몇 교육생들로부터 큰 귀감을 얻기도 했다.

2년 이상의 경력을 포기하면서도 SSAFY에 온 것은 앞으로의 개발자로서의 경력을 발전시키는 데 큰 도움이 될 것이라고 생각한다. 또한, SSAFY에서의 경험을 정리하면서 앞으로 개발자로서의 커리어를 어떻게 이어 나갈지 간단하게 정리해 본다.

1. back end 개발자로서의 역량을 높이기

1학기에는 평소 약점이라 생각했던 알고리즘 해결 능력을 높이는 데 주력했었다. 처음 알고리즘 수준은 프로그래머스 2단계 문제를 푸는 것도 어려울 만큼 알고리즘 지식이 부족했었기 때문에 교육장 내에서 끝자락에 있을 만큼 수준 차이가 있었고, 이를 줄이기 위해서 알고리즘 문제를 풀이하는 데에 많은 시간을 보낸 것 같다.

또한, 2학기에는 3개의 프로젝트 중 2개는 인프라 담당, 1개는 프론트엔드 담당으로 개발을 진행했었기 때문에, SSAFY에서 처음에 목표했던 백엔드 개발자로서의 경력을 쌓기 위한 준비를 많이 하지 못한 것이 아쉽다.

따라서, 입사 후에는 기존 서비스의 백엔드 파트 리팩토링을 통해 백엔드 개발자로서의 역량을 더 채우고자 한다.

1. 눈에 보이는 것을 남기기

1년간 SSAFY 교육과정을 이수하면서 느낀 점 중 하나는 눈에 보일만한 이력을 남기는 것의 중요성이다. SSAFY에서 교육받기 전에는 항상 스스로 부끄럼 없이 개발만 잘하면 된다고 생각했었는데, 아무리 실력이 뛰어나다고 해도 스스로를 어필하고 보여주지 못하면 이러한 노력에 대해서 결과를 극대화할 수 없다고 생각했다.

프로젝트, 블로그 포스팅, 자격증과 같이 기록이 남을 수 있는 결과물을 내는 것도 신경을 쓰며 개발을 진행하도록 하자. 2024년 하반기에는 개발 관련 자격증을 하나 취득하는 것을 목표로 진행하도록 하자. (리눅스 마스터 따기)

1. 더 성실해지기, 비즈니스 매너를 갖추기

SSAFY 교육과정을 진행하면서 과음으로 인하여 지각을 하기도 했고, 과제를 하느라 제때 퇴실 처리를 하지 못할 때도 있었고, 일찍 와서 공부하느라 지각 처리되기도 했었다. 이 역시 내가 아무리 공부했던, 과제를 했든 간에 출결에 이슈가 발생한다. 이러한 문제가 발생하지 않도록 더욱 출결과 같은 기본적인 매너를 잘 지킬 수 있도록 노력해야 할 필요가 있다.

또한, 교육과정은 쉬는 시간 없이 프로젝트를 진행하고, 얼어붙은 취업시장에서 취업 준비까지 병행했었다. 모두가 지치고 힘든 상황에서 상대방을 배려해 주는 것 역시 개발하면서 꼭 필요한 덕목이라고 생각한다. 업무가 미뤄지는 것, 이해되지 않는 코드를 보며 기분이 태도가 되어 팀원들에게 매너를 갖추지 않고 말했던 것에 대해 팀원들에게 진심으로 미안하게 생각한다. 다시는 이러한 실수를 하지 않도록 주의하도록 하자.