블로그를 찾아주시는 분들도 아마 저처럼 “이론은 중요하지만, 결국 내가 맡은 첫 프로젝트의 테스크를 해결하기 위해 글을 읽으신 분이 많을 것” 이라고 생각합니다. 그래서 이번 글에서는 앞선 이론에서 다뤘던 내용을 직접 실습해보는 데 집중하려고 합니다. 물론, 이론을 이해하고 시작하면 훨씬 더 쉽게 다가갈 수 있기 때문에, 실습 편을 따라 하시기 전에 이론 설명도 꼭 한 번 읽어보시길 추천드려요. 단순히 따라하는 것과 원리를 알고 응용하는 것은 분명히 다르니까요.

이 글을 보시면 프로젝트 세팅과 기본적인 협업을 맛볼 수 있을것이라고 생각합니다.

이번 실습은 Git이 이미 컴퓨터에 설치되어 있다는 전제로 진행합니다. 혹시 아직 Git을 설치하지 않으셨다면, 먼저 설치부터 해 주세요.

B. Organization 세팅

1.Organization

GitHub 우측 상단 프로필 메뉴에서 Settings → Organizations로 이동합니다.

우측 상단의 New organization 버튼을 클릭합니다.

https://github.com/settings/organizations 탭에 들어가 위 화면의 New Organization을 누르면 됩니다.

Organization 정보를 입력합니다.

• Organization name: 조직 이름
• Contact email: 연락 가능한 이메일
• This organization belongs to: 개인 계정 혹은 비즈니스 중 선택 이렇게 Organization 정보를 작성하면 됩니다.

멤버 초대

• Organization을 생성한 뒤, 상단 메뉴에서 People 탭을 선택합니다.
• Invite member 버튼을 클릭합니다.
• 초대할 사용자의 GitHub 이름, 이메일 등을 입력하여 멤버로 초대하면 됩니다.

만들고 나서는 People항목의 Invite Member로 초대하시면 됩니다.

2. Repository

직접 코드를 저장하고 관리할 Repository(저장소)를 만들어보겠습니다.

New Repository 선택

GitHub Organization 또는 개인 계정의 메인 페이지에서 "New Repository" 버튼을 클릭하세요.

• Repository 이름을 입력합니다.
• 필수 정보만 단순하게 입력해도 됩니다.
• 공개(public)/비공개(private) 여부를 선택할 수 있습니다.

옵션 설정 예시

아래와 같이 주로 사용하는 최소한의 설정만 선택해도 무방합니다.

• Repository name: 저장소 이름 (예: my-first-repo)
• Description: 저장소 설명 (필 optional)
• Public/Private: 노출 범위 선택

저는 보통 요렇게 만 설정을 하고 만듭니다.

Add a README file: 체크

• 이 옵션을 켜두면 저장소가 생성될 때 자동으로 README.md 파일이 포함되어 생성됩니다.
• 처음부터 "첫 커밋" 이 올라간 상태가 되어, 로컬에서 별도의 git init 없이 바로 git clone 명령으로 프로젝트를 내려받아 사용할 수 있습니다.

3. Template

레포지토리를 생성했다면, 이제 이슈(Issue)와 풀 리퀘스트(Pull Request)에 사용할 템플릿을 만들어 협업의 효율을 높일 수 있습니다.

템플릿 생성 방법

• Add File → Create new file로 새로운 파일을 추가합니다.
• 템플릿 관리와 자동 적용을 위해** .github 폴더**를 생성합니다

폴더 및 파일 구조

• .github/ISSUE_TEMPLATE/: 이 안에 Issue에 사용할 템플릿 파일(.yml 혹은 .md)을 넣습니다.

• .github/pull_request_template.md: Pull Request에 사용할 템플릿 파일은 .github 폴더 바로 안에 만듭니다.

템플릿 작동 원리

• .github/ISSUE_TEMPLATE 폴더 내에 파일이 있으면 GitHub가 자동으로 감지해 이슈 등록 시 템플릿을 사용할 수 있도록 해줍니다.
• Pull Request 역시 .github 폴더 내의 pull_request_template.md를 자동으로 불러옵니다.
• 이 구조를 맞추면 GitHub가 저장소를 분석해, 새로운 이슈나 PR을 생성할 때 선택할 수 있는 템플릿 옵션을 제공합니다.

적용 화면

Issue 작성 버튼을 누르면, 아래와 같이 템플릿 리스트가 나타나 사용자가 원하는 양식을 골라 쓸 수 있습니다.

이렇게 템플릿을 만들어두면 협업에서 발생할 수 있는 의사소통 오류를 줄이고, 효율적으로 프로젝트를 이끌어갈 수 있습니다. GitHub가 제공하는 템플릿 기능을 최대한 활용해보세요!

4. 코드 꼬임이 걱정된다면 — 브랜치 보호 규칙 활용하기

첫 협업 프로젝트에서는 실수로 잘못된 코드가 저장소에 합쳐져 버릴까봐 걱정이 많을 수 있습니다. 이런 불안감을 줄이기 위한 가장 확실한 방법은 브랜치 보호 규칙(Branch Protection Rule)을 설정하는 것입니다.

브랜치 보호 규칙 설정 방법

조직(Organization) 또는 저장소(Repository)에서 Settings → Branch → Add classic branch protection rule 메뉴로 이동합니다.

보호할 브랜치 지정 및 승인 절차(Approvals) 설정

• 예시) main 또는 develop 등 실제로 배포하거나 중요한 브랜치를 지정하세요.

• 브랜치명에 패턴(예: main, release/* 등)도 사용할 수 있습니다.

• "Require approvals before merging" 항목에서 몇 명의 리뷰어 승인이 필요한지 지정할 수 있습니다.

  예를 들어 "2"를 입력하면 적어도 두 명이 승인해야만 PR(Pull Request)이 병합됩니다.

이렇게 브랜치 보호 규칙을 활용하면, 첫 팀 프로젝트에서도 코드 꼬임에 대한 불안이나 실수 걱정을 획기적으로 줄일 수 있습니다. 무작정 코드가 섞이는 걸 방지하고, 모두가 검토한 코드만 합쳐진다는 경험을 직접 할 수 있을거에요.

C. 코드 올려보기

1. Clone

프로젝트의 실질적인 시작은 레포지토리를 자신의 컴퓨터로 복제(clone)하는 과정에서 시작됩니다.

레포지토리 주소 복사

• GitHub의 해당 레포지토리 페이지로 이동합니다.
• 화면 상단의 Code 버튼을 클릭하면 HTTPS 주소를 복사할 수 있습니다.
• 복사한 주소를 이후 명령어에 사용할 예정입니다.

빈 디렉토리 준비

• 터미널(명령 프롬프트)에서 작업할 공간을 만들면 프로젝트 관리가 편리합니다.
• 예를 들면, 홈 디렉토리에서 git이라는 폴더를 만들어 여러 프로젝트를 한 눈에 관리할 수 있습니다.

2. Issue 작성하기

이슈 템플릿 활용해서 Issue 등록

• GitHub 저장소의 Issues 탭에 들어가서, 미리 만들어둔 이슈 템플릿 중 원하는 양식을 선택합니다.
• 템플릿에 맞게 이슈 내용을 구체적으로 작성합니다.
• 이슈를 제출하면 해당 작업의 시작점이 됩니다.

이슈에서 브랜치 생성 (Create branch)

• 작성한 이슈 하단이나 우측에서 Create branch 버튼을 클릭합니다.
• 새 브랜치가 자동으로 생성되며, 브랜치와 이슈가 서로 자동으로 연결됩니다. 이렇게 하면 추후에 해당 이슈를 통해 관련 브랜치 이력까지 한눈에 추적할 수 있어 프로젝트 관리가 쉬워집니다.

브랜치 네이밍 규칙

• 브랜치 이름은 팀 내 약속에 따라 통일하면 좋습니다.
• 일반적으로는 feature/이슈번호-작업내용 또는 fix/이슈번호-수정내용 형태가 많이 활용됩니다.

IDE에서 작업 브랜치로 이동

• 터미널에서 최신 브랜치 정보를 받아오기 위해 fetch 명령어로 받아올 수 있습니다.
• checkout을 통해 해당 브랜치로 이동합니다.

• 이슈 기반 브랜치 전략을 쓰면, 누가 어떤 작업을 맡았는지 명확하게 관리할 수 있어 협업 프로젝트에 특히 유용합니다.

• 브랜치와 이슈가 자동으로 연결되므로, 코드 리뷰, 변경 내역 추적, PR 작성까지 일련의 작업이 훨씬 체계적으로 흘러갑니다.

3. 코드 올리기 (add commit push)

코드를 작업한 뒤 GitHub에 올리는 전 과정을 Jetbrains IDE의 GUI 기반으로 설명합니다. 초보자를 위해 최대한 gui를 통한 작업을 소개해드리려고 합니다.

변경사항 확인

• 파일을 수정하면 IDE 좌측 Commit(커밋) 패널에 변경된 파일이 파란색 등으로 표시됩니다.
• 이 패널에서 어떤 파일이 수정되었는지 한눈에 확인할 수 있습니다

커밋할 파일 선택 및 커밋 메세지

• 올리고 싶은(커밋하고 싶은) 파일의 체크박스를 선택합니다.
• 여러 파일을 한 번에, 또는 일부만 선택해서 커밋할 수 있습니다.
• 아래 입력창에 간결하고 명확한 커밋 메시지를 작성합니다. 예: "로그인 폼 레이아웃 수정", "README 추가" 등.
• Commit 버튼 클릭 후, 이어서 Push 버튼을 클릭하면 방금 만든 커밋이 내 이슈 브랜치의 원격 저장소(GitHub)에 업로드됩니다

• 이렇게 하면 별도의 터미널 명령어 입력 없이, GUI 기반으로
• add → commit → push 전체 과정*을 마칠 수 있습니다.

• 초보자도 실수 없이, 변경한 내용을 팀원들과 안전하게 공유할 수 있게 됩니다.

4. Pull request

작업한 내용을 공유하고, 코드 리뷰를 받기 위해서는 Pull Request (PR)를 만들어야 합니다. PR은 협업 과정에서 가장 중요한 과정 중 하나로, 내 작업물을 다른 사람과 검토하고 합치는 단계입니다.

IDE에서 PR? 저는 GitHub에서 합니다

JetBrains IDE (예: IntelliJ, WebStorm 등)에서도 왼쪽 메뉴에 Pull Request 항목이 존재하지만, 👉 글자가 작고 불편해서 저는 GitHub 웹 사이트에서 직접 PR을 생성하는 방식을 선호합니다.

GitHub에서 PR 생성하기

• GitHub 저장소의 "Pull Requests" 탭으로 이동합니다.
• GitHub는 자동으로 내가 작업한 브랜치 중 현재 PR 대상이 될 수 있는 브랜치 목록을 보여줍니다.
• 해당 브랜치에서 변경된 내용을 기준으로 PR을 생성하라는 추천 정보가 뜨기도 합니다.

만약 추천 목록이 보이지 않아도 걱정 마세요! "New pull request" 버튼을 클릭하면 수동으로 브랜치를 지정하여 PR을 만들 수 있습니다.

PR 템플릿 작성 및 이슈 연결

• 이전에 만들었던 PR 템플릿이 자동으로 입력됩니다.
• 템플릿에 따라 변경 내용을 차근차근 정리하고, 설명을 작성해주세요.
• 이때 #이슈번호 형태로 작성하면 자동으로 이슈와 PR이 연결됩니다. 예시: Fixes #23 또는 Closes #10 이렇게 해두면 해당 PR이 머지될 때 이슈가 자동으로 닫히기도 하며, "어떤 이슈를 해결하는 PR인지 명확하게 드러나서 협업에 도움이 됩니다.

D. 내 코드를 main 최종에 합치기

Pull Request를 만든 뒤에는 곧바로 main 브랜치(혹은 상위 브랜치)로 머지할 수 있어야 하지만, 앞서 설정한 브랜치 보호 규칙(Approvals 설정) 덕분에 PR을 바로 머지할 수 없도록 잠겨 있는 상태가 됩니다.

이 방식은 초보자들이 실수로 코드를 바로 머지하는 일을 방지하고, 꼭 검토(리뷰)를 거치도록 만들어주는 안전 장치 역할을 합니다.

1. 코드 리뷰 (Code Review)

화면의 "Files changed" 탭에 들어가면 변경된 코드들을 한눈에 볼 수 있습니다.

• 코드 옆 줄번호에 마우스를 올리면 “+” 버튼이 나타납니다.
• 이 버튼을 누르면 해당 줄에 리뷰 코멘트를 남길 수 있습니다.

💡 리뷰를 통해 코드의 개선 사항이나 이해되지 않는 부분을 질문하거나, 의견을 나눌 수 있어 협업의 퀄리티를 높여줍니다.

2. Approve

문제가 없다고 판단되면 리뷰어는 "Approve" 버튼을 클릭해 PR을 승인합니다.

• 승인되지 않은 PR은 머지가 잠겨 있으므로, 반드시 리뷰 → approve 과정을 거쳐야 합니다.

위와 같이 Merge 버튼이 활성화되면서 머지할 수 있는 상태가 됩니다.

3. merge 하기

Merge pull request" 버튼을 눌러 작업한 내용을 main 브랜치에 병합하세요.

• 이로써 내가 만든 기능 또는 수정사항이 공식 브랜치(main)에 반영됩니다.
• 옵션에 따라 Squash and merge, Rebase and merge 등을 선택할 수도 있습니다. (기본은 일반 Merge)

E. 마무리

처음엔 많이 서툴고, 뭐가 뭔지 몰라 망설였던 것도 사실이었죠. 하지만 하나씩 직접 따라 해보니, 생각보다 금방 익숙해지더라고요.

“완벽하게 다 알고 시작해야 할까?” 고민하지 말고, 그냥 한 번 해본다는 마음으로 도전하세요. 에러도 겪고, 새로운 것도 부딪히다 보면 금세 자신감이 붙고 협업도 더 즐거워질 거예요.

실습을 쓰는 블로그는 처음이여서 글이 서투른것 같습니다. 다음에는 더 개선해서 써보겠습니다...

이 글은 git을 사용해 본적 없이 첫 프로젝트를 진행하시는 분을 위해 준비했습니다. 저 역시 처음에는 협업을 하면 코드를 어떻게 하는거지 이게 그냥 된다고? 라는 신기함과 내가 잘못해서 코드를 날리면 어쩌지라는 두려움으로 시작했던 것 같습니다. 그래서 저와 같은 사람들을 위해 이론부터 실습까지 소개하는 글을 쓰려고 합니다.

B. Git

1. Git 이란?

처음엔 "그냥 파일 저장하는 거 아닌가?" 싶었지만, Git은 단순한 저장이 아니라 코드의 모든 변경 이력을 남기고, 여러 명이 동시에 작업해도 충돌을 최소화해주는 협업 도구다. 내가 작업한 내용이 언제, 왜, 어떻게 바뀌었는지 추적할 수 있고, 실수했을 때 이전 상태로 쉽게 되돌릴 수 있다. 특히, 팀 프로젝트에서 누가 어떤 기능을 만들고 있는지 한눈에 파악할 수 있어서, "내가 뭘 해야 하지?"라는 불안감이 줄어들었다.

(자연스레 기여도를 추적 할 수도 있달까...? 하지만 Git에 있는 기여도가 전부라고는 생각하지 않습니다.)

2. clone

clone의 영어를 해석해면 똑같은 걸 여러개 만드는 거다. 처음에는 "이게 뭘 복사해온다는 거지?" 싶었는데, 실제로 해보니 원격 저장소(GitHub 등)에 올라가 있는 프로젝트 전체를 내 컴퓨터로 통째로 복제해오는 작업이었다.

인터넷 상에 있는거를** 내 로컬(컴퓨터)**로 똑같은걸 옮겨오는 작업이라는 게 핵심이다.

사용 방법

1. 터미널에서 내가 원하는 컵퓨터의 파일로 이동한다.
2. git clone <사진의 github 주소> 복사해서 붙여 넣으면 된다.
3. .git 디렉토리가 자동으로 생성되어, 바로 Git 명령어를 사용할 수 있었다.

.git이라는 것은

여러분이 Git을 사용해서 파일을 추적하거나, 이전 상태로 되돌리거나, 여러 명이 함께 작업할 때 ‘무슨 일이 있었는지’ 기록해두는 역할을 합니다.

2년전 Git과제에서 clone이 뭔지 몰라서 과제에서 힘들었던 경험이 있네요...

3. add

add는 "이 파일을 다음 커밋에 포함시켜줘!"라고 Git에게 알려주는 단계였다.
실제로는 git add .로 전체 파일을 올리기도 하고, git add 파일명으로 특정 파일만 올릴 수도 있다.
처음엔 add와 commit을 헷갈리기 쉽지만, add는 "준비", commit은 "저장"이라고 생각하면 이해가 쉬웠다.

꿀팁: 실수로 필요 없는 파일까지 add했다면, git reset으로 스테이징을 해제할 수 있다.

4. commit

commit은 Git에서 변경된 파일을 “로컬 저장소”에 저장하는 작업입니다.
쉽게 말해, 내 컴퓨터 안에서 “이 시점의 변경사항을 기록해!” 라고 명령하는 것과 같습니다.
commit을 하면, 변경 내용과 함께 “커밋 메시지”를 남기게 되며, 이 메시지는 나중에 변경 이력을 추적할 때 큰 도움이 됩니다.

처음 커밋할 때는 "메시지는 아무거나 써도 되겠지?"라고 생각했다가, 나중에 변경 이력을 볼 때 후회했다.
git commit -m "메시지"로 커밋할 때, 어떤 변경을 했는지 명확하게 적는 습관이 정말 중요하다.
예를 들어, "회원가입 기능 추가", "버그 수정: 로그인 오류"처럼 구체적으로 작성하면, 나중에 팀원들과 소통할 때도 편하다.

커밋 메시지는 나중의 나에게 보내는 메모라고 생각하면, 더 신경 쓰게 된다. 커밋은 github에 올리는게 아니라 나의 로컬에 버전을 업데이트 하는 것!!이라고 생각을 하면 좋을 것 같스습니다.

5. push

push라는 것은 로컬 저장소에 업데이트 된 커밋들을 원격 저장소에 올리는 명령어입니다[1][2][4].

내가 처음 push를 할 때, "왜 내 코드가 깃허브에 안 올라가지?"라며 당황했던 기억이 난다.
git push origin 브랜치명으로 로컬에서 작업한 내용을 원격 저장소(깃허브 등)에 올릴 수 있다.

origin은 그냥 "내 깃허브 주소"라고 생각하면 쉽습니다.

그래서 push를 할 때는

git push origin 

이렇게 해야 하고,
이게 "브랜치명이라는 원격 저장소에 올려줘"라는 뜻이라고 생각하시면 좋을 것 같습니다.

꿀팁: push 전에 항상 git pull로 다른 사람의 변경사항을 먼저 받아오면, 충돌을 줄일 수 있다. 처음엔 push가 무서웠지만, 익숙해지면 협업의 핵심이 된다.

6. fetch

git fetch는 원격 저장소(GitHub 등)에 있는 최신 변경사항을 내 컴퓨터(로컬 저장소)로 가져오는 명령어입니다.
이 과정에서 내 작업 디렉토리(내가 실제로 보고 있는 파일들)는 바뀌지 않고, 가져온 변경사항이 바로 적용되지 않습니다.
즉, 원격 저장소의 이력만 업데이트하고, 실제 내 코드에는 아무 변화가 없습니다.

fetch는 “원격 저장소에 새로운 내용이 있나?”를 확인하고, 그 내용을 내 로컬 저장소에 ‘다운로드’만 해둡니다. 내 작업 폴더에는 아무 영향이 없으니, 안전하게 최신 상태를 확인할 수 있습니다. 이후에 git merge나 git rebase 등으로 원격 변경사항을 내 작업에 반영할 수 있습니다.

pull과의 차이점

• git pull은 내부적으로 git fetch + git merge를 한 번에 실행합니다.
  즉, 원격 변경사항을 가져오고 바로 내 작업에 합쳐버립니다.
• git fetch는 가져오기만 하고, 합치지는 않는다는 점이 다릅니다. "가져오기만 하고, 합치지는 않는다"는 점이 pull과 fetch의 가장 큰 차이입니다.

처음 fetch를 썼을 때, "pull이랑 뭐가 다르지?"라는 의문이 들었다. git fetch는 원격 저장소의 변경사항을 내 로컬 저장소에 가져오지만, 바로 내 작업에 반영되지는 않는다. 즉, "가져오기만 하고, 합치지는 않는다"는 점이 다르다.

7. merge

git merge는 서로 다른 브랜치(작업 흐름)를 하나로 합치는 명령어입니다.
쉽게 말해, “각자 작업한 내용을 한데 모아, 하나의 결과물로 만드는 과정”입니다.
여러 명이 동시에 작업해도, 각자 브랜치에서 개발한 뒤 마지막에 merge로 합치면 협업이 가능합니다. 하지만 같은 파일의 같은 부분을 여러 명이 수정했다면, 충돌(conflict)이 발생할 수 있습니다.

처음 merge를 할 때는 충돌(conflict)이 무서울 수 있지만, 충돌 메시지를 보고 직접 수정하고 add, commit을 다시 하면 해결됩니다.

충돌이 날 때마다 "내가 뭘 잘못했나?" 생각하지 말고, 차분히 변경 내용을 비교해보면 금방 익숙해진다.

pull하면 오류가 뜨는데 fetch + merge를 하면 잘 되는 이유

• git pull은 내부적으로 git fetch + git merge를 한 번에 실행합니다.
  즉, 원격 변경사항을 가져오고 곧바로 내 작업과 합칩니다. 이 과정에서 충돌이 발생하면, 바로 충돌 해결 단계로 넘어가게 됩니다.
  하지만 pull은 모든 과정을 한 번에 처리하기 때문에, 변경사항을 충분히 검토하지 못하고 충돌이 발생하는 경우가 많습니다.

• git fetch + git merge는,
  먼저 fetch로 원격 저장소의 최신 커밋을 내 로컬 저장소로만 가져오고, 그 다음 merge를 통해 실제로 내 작업과 합치면서 충돌이 발생하면, 내가 직접 충돌난 파일을 확인하고 꼼꼼히 비교·수정할 수 있습니다. 충돌을 모두 해결한 뒤에만 병합이 완료됩니다.

C. Git으로 협업 하기.

1. Oranization

GitHub에서 여러 명이 함께 프로젝트를 관리할 때, 조직(Organization) 기능을 사용하면 팀 단위로 저장소를 만들고 권한을 체계적으로 관리할 수 있습니다.
개인 계정이 아니라, 회사·동아리·스터디 등 단체 차원의 공간을 만드는 것과 비슷합니다.

처음에는 그냥 개인 깃허브에 저장소를 만들고 초대해서 썼는데, 팀원들 파트별 저장소를 만들고, 프로젝트가 많아지니 관리가 너무 힘들었다.
Organization을 사용하게 되면, 저장소를 한 곳에 모아두고, 팀원별로 권한도 쉽게 설정할 수 있어서 협업이 훨씬 편해졌습니다.

• 팀 프로젝트를 장기적으로 하거나, 여러 저장소를 관리할 땐 꼭 Organization을 사용해보세요.

• 팀원 초대는 이메일이나 깃허브 아이디로 간단하게 할 수 있습니다.
• Organization 내에서는 저장소별로 권한을 다르게 줄 수 있어, 실수로 중요한 코드가 지워질 걱정이 줄어듭니다.

2. Issue

issue(이슈) 는 프로젝트에서 발생하는 문제, 버그, 개선사항, 질문 등을 기록하고 관리하는 기능입니다.
일종의 “할 일 목록” 또는 “토론 게시판” 역할을 합니다.

카카오톡이나 슬랙으로만 할 일을 공유하면, 금방 잊히거나 누락되는 경우가 많았습니다.
반면, GitHub Issue를 활용하면 프로젝트 기간 동안 GitHub를 자주 사용하게 되어, 누가 어떤 일을 맡았는지와 어떤 버그가 있는지 한눈에 파악할 수 있어 프로젝트를 훨씬 체계적으로 진행할 수 있었습니다.

진행 상황도 카톡으로 일일이 물어보지 않아도, GitHub에서 바로 "아, 이 부분을 진행하고 있구나" 하고 쉽게 확인할 수 있습니다.

구체적인 제목과 내용 작성

예시: 단순히 “로그인 오류 발생”이 아니라, “로그인 시 500 에러 발생, 재현 방법 첨부”처럼 문제 상황과 재현 방법까지 명확히 적으면, 다른 팀원도 빠르게 이해하고 대응할 수 있습니다.

라벨(Label) 활용

이슈에 버그, 기능, 질문 등 다양한 라벨을 붙여 분류하면 관리가 훨씬 쉬워집니다.
라벨별로 이슈를 필터링해서 필요한 항목만 한눈에 볼 수 있어, 우선순위나 담당 영역을 정할 때 유용합니다.

담당자 지정

각 이슈에 담당자를 지정하면, 누가 어떤 일을 맡았는지 명확해집니다.
책임 소재가 분명해져서, 진행 상황을 추적하거나 업무 분배를 할 때 혼란이 줄어듭니다.

브랜치와의 연동

이슈와 브랜치를 연결해두면, 실제 작업 브랜치가 어떤 이슈와 관련되어 있는지 쉽게 파악할 수 있습니다.
관련 브랜치에서 작업하다가 PR을 만들 때도 자동으로 이슈와 연결되어, 관리가 편리해집니다.

체크리스트 활용

이슈 본문에 Checklist(체크박스 목록)를 만들어두면, 세부 작업 항목별로 진행 상황을 표시할 수 있습니다.
각 항목이 완료될 때마다 체크하면, 팀원 모두가 실시간으로 진척도를 확인할 수 있어 협업이 한층 더 효율적입니다.

Issue를 잘 활용하면, 프로젝트의 모든 할 일과 문제, 개선사항을 체계적으로 관리할 수 있습니다. 구체적인 작성, 라벨과 담당자 지정, 브랜치 연동, 체크리스트 등 다양한 기능을 적극적으로 사용해보세요. 이렇게 하면 협업의 투명성과 효율성이 크게 높아집니다.

3. Pull Request

Pull Request(PR) 는 “내가 작업한 내용을 메인 저장소에 합쳐주세요!”라고 요청하는 기능입니다.
협업에서 각자 브랜치에서 작업한 뒤, 최종적으로 코드 리뷰와 승인을 거쳐 메인 브랜치에 반영할 때 사용합니다.

내가 push를 했다고 끝나는 것이 아니라, 보통 push는 브랜치에 올리는 개념이고, Issue와 연결된 브랜치에 할 일을 다 했을 때 메인브랜치에 나의 브랜치 내역을 합치는 과정을 말합니다.

Comment

Comment(댓글) 는 Pull Request(또는 Issue)에 달 수 있는 의견, 질문, 제안, 피드백입니다.

팀원들이 내 코드를 보고 자유롭게 의견을 남길 수 있습니다.
댓글은 단순히 글로 남길 수도 있고, 코드의 특정 줄에 직접 달 수도 있어서, 어떤 부분을 이야기하는지 명확하게 전달할 수 있습니다.

Approve

Approve(승인) 는 리뷰어(팀원)가 “이제 이 코드는 메인 브랜치에 합쳐도 괜찮다!”고 공식적으로 OK 사인을 주는 기능입니다.

Approve가 완료되어야만 메인 브랜치로 코드를 합칠 수 있도록(병합) 설정하는 경우가 많습니다.
즉, Approve는 “코드 검토가 끝났으니, 이제 합쳐도 안전하다”는 신호입니다.

4. Template

이슈, PR 등에서 반복적으로 작성하는 내용을 미리 양식(Template)으로 만들어두는 기능입니다.
덕분에 팀원 모두가 일관된 형식으로 내용을 작성할 수 있습니다.

사용법 :

• .github/ISSUE_TEMPLATE/ 폴더에 템플릿 파일을 만들어두면, 새 이슈/PR 작성 시 자동으로 양식이 적용됩니다.

제목, 내용, 체크리스트 등 자주 쓰는 항목을 미리 넣어두면, 실수도 줄고 협업 효율이 올라갑니다. 팀원들과 함께 템플릿을 개선해가며, 프로젝트에 맞는 양식을 만들어보세요. 리뷰 할때도 형식이 같아 휠씬 편리합니다.

C. 마무리

처음에는 git과 GitHub가 어렵고 막막하게 느껴질 수 있지만, 한 번 구조와 흐름을 익혀두면 협업이 훨씬 편해지고 내가 만든 코드가 ‘기록’으로 남는 재미도 느낄 수 있습니다.

처음엔 실수도 하고, 충돌도 겪으면서 조금씩 익숙해지는 과정이 필요합니다. 하지만 분명히, "이런 식으로 협업이 돌아가는구나!"라는 감각이 생기면 혼자 개발할 때보다 훨씬 더 성장할 수 있습니다.

저 역시 처음엔 두려움이 컸지만, 프로젝트를 거듭할수록 git과 GitHub의 진짜 힘을 느끼게 되었고, 지금은 오히려 없으면 불안할 정도로 든든한 도구가 됐습니다.

이 글이 여러분의 첫 git 협업에 조금이나마 도움이 되었기를 바랍니다. 함께 성장하는 협업, git과 함께 시작해보세요!

궁금한 점이 있거나, 더 알고 싶은 내용이 있다면 언제든 댓글이나 질문 남겨주세요. 다음 글은 실습편을 작성해보려고 합니다. 이번글과 이어지니 다음글도 읽어주세요..

이 글은 ERD와 API를 설계할 때 어떤 툴을 사용하면 협업에 더 효과적일지 고민하는 분들을 위한 글입니다. 아래는 제가 실제 프로젝트에서 사용해본 여러 툴에 대한 주관적인 경험과 생각을 정리한 내용입니다. 혹시 더 좋은 툴을 사용해보셨다면 댓글로 추천해주시면 직접 사용해보고 후기를 업데이트하겠습니다.

ERD

1. dbdiagram.io 🔗

쿼리로 그리는 ERD

처음 프로젝트에서 ERD를 그려야 했을 때, dbdiagram.io를 사용해봤어요. 이 툴의 가장 큰 특징은 마우스로 박스를 끌어다 놓는 방식이 아니라, 쿼리 문법으로 ERD를 그릴 수 있다는 점입니다. 예전에 SQL 쿼리 실습을 조금 해본 덕분에, 오히려 이런 방식이 더 편하게 느껴졌고, 실제로 테이블 구조를 쿼리로 직접 써보니까 SQL에 더 익숙해지는 효과도 있었습니다.

예쁘고 깔끔한 UI

dbdiagram.io는 UI가 깔끔하고 예쁘다는 점이 정말 인상적이었어요. 발표 자료(PPT)에 ERD를 넣을 때 캡처해서 쓰면 보기 좋은 결과물이 나옵니다.
다른 ERD 툴들에 비해 색감, 폰트, 다이어그램 정렬이 잘 되어 있어서, 결과물을 공유할 때 뿌듯함이 남아요. (UI 느낌이 제 취향이기도 했고요.)

협업할 땐 아쉬운 점도...

아쉬운 점도 있었습니다. 여러 명이 동시에 쿼리 문서를 수정할 수 없어서 협업에는 불편했습니다.
실시간 동기화가 지원되지 않다 보니(유료 버전에서는 실시간 가능), 한 명이 쿼리를 작성하고 다른 팀원들은 그걸 보면서 피드백만 주는 식으로 진행했어요.
실시간으로 같이 수정하고 싶은 순간이 많았는데, 이 부분은 확실히 아쉬웠던 기억이 남습니다. 그래서 다른 툴을 찾아보는 계기가 되기도 했어요.

정리

정리하자면: 쿼리 기반이라 SQL에 더 익숙해질 수 있고, 결과물이 예뻐서 발표 자료에 넣기 좋았던 툴! 다만, 여러 명이 동시에 작업하는 협업에는 조금 불편함이 있었던 점은 참고하면 좋을 것 같습니다.

2. erdcloud 🔗

처음에는 dbdiagram 같은 쿼리 기반 툴을 써봤지만, 코드나 쿼리 입력이 익숙하지 않아서 금방 한계에 부딪혔습니다. 그러다 ERDCloud를 알게 되었고, 아이콘을 클릭해서 테이블을 만들고, 관계도 선으로 연결하는 방식이 정말 직관적이어서 금방 적응할 수 있었습니다.

직관적인 아이콘

• 테이블과 관계를 마우스로 클릭하고 드래그해서 만들 수 있습니다.
• 테이블 안에 컬럼도 칸을 클릭해서 입력만 하면 바로 추가됩니다.

협업 기능

• TEAM 기능으로 팀을 만들고, 이메일로 팀원 초대가 가능합니다.
• 댓글 기능이 있어 팀원들과 의견을 주고받을 수 있습니다.

실시간 동기화

• 팀원이 동시에 작업을 해도 변경 사항이 바로 반영되어 협업에 더 좋습니다. (무료에요!!)

사용하면서 느낀 아쉬운 점

• 테이블에 값을 입력할 때 엔터를 꼭 눌러야 저장됩니다. 처음엔 조금 헷갈릴 수 있어요.
• 화면 오른쪽에 광고가 떠서 집중이 잘 안 될 때가 있습니다.
• dbdiagram에 비해 디자인이나 일부 기능이 살짝 구식처럼 느껴질 때가 있습니다. 그래도 기본적인 기능은 충분히 쓸 만합니다.

복잡한 설치나 어려운 코딩 없이, 그림 그리듯이 데이터베이스 구조를 만들고 팀원과 실시간으로 협업할 수 있다는 점이 ERDCloud의 가장 큰 매력이라고 생각합니다.

API 명세서

1. Swagger

Swagger는 API를 설계하고 문서화하는 오픈소스 도구입니다. 복잡한 API 구조를 쉽게 설명하고, 팀원들과 효과적으로 소통하며, 실제로 API가 어떻게 동작하는지 직접 테스트할 수 있도록 도와줍니다.

자동 문서화

• Swagger는 코드 기반으로 API 문서를 자동 생성해줍니다.
• 서버 코드에서 요청과 응답을 처리하는 부분에 Swagger 관련 코드를 추가하면, 별도의 문서 작업 없이 API 명세가 자동으로 문서화되어 웹 페이지 형태로 확인할 수 있습니다.

인터랙티브한 테스트

• Swagger 코드를 서버에 작성하고 서버 로직을 구현한 뒤에는, 자동으로 생성된 문서화 페이지에서 각 API를 직접 테스트해볼 수 있습니다.
• 개발자들은 응답 결과나 오류 여부를 즉시 확인할 수 있어 개발 효율성이 높아집니다.

표준화 형식

• Swagger는 OpenAPI라는 표준을 따릅니다.
• 이 덕분에 다양한 언어와 프레임워크에서 폭넓게 사용할 수 있으며, 범용적으로 가장 널리 쓰이는 API 문서화 방식 중 하나입니다.

개인적 생각

Swagger는 코드 기반으로 문서를 작성하는 도구이기 때문에, 프로젝트 개발 환경이 어느 정도 갖춰진 후에 도입하는 것이 적합하다고 생각합니다. 그래서 첫 프로젝트를 진행하는 분들에게는 추천하지 않습니다.

서버 코드에서 언제든지 문서를 수정할 수 있기 때문에, API 명세의 주도권이 백엔드 개발자에게 치우치는 느낌이 있습니다. 저는 API 명세서는 중립적으로 관리되는 것이 가장 이상적이라고 생각하기 때문에, 프로젝트 초기에 Swagger를 도입하는 데에는 다소 망설임이 있습니다.

프론트엔드 개발자가 Swagger 문서화 페이지에 접근하려면 서버가 배포된 상태여야 하는데, 첫 프로젝트에서는 서버 설계와 배포 자체가 쉽지 않을 수 있습니다. 저 역시 개발을 시작할 때 바로 서버 세팅과 자동 배포 파이프라인을 구축하는 편이지만, 초보자에게는 이러한 과정이 부담스러울 수 있다고 생각합니다.

따라서 첫 프로젝트를 진행하는 분들은 Swagger 같은 자동화 도구보다는 직접 API 문서를 작성해보는 경험을 쌓는 것이 더 도움이 될 것이라 생각합니다.

2. Postman & Apidog

Postman과 Apidog은 API를 쉽게 테스트하고 관리할 수 있게 도와주는 무료 도구입니다. 복잡한 코드 없이도 API 요청을 만들고, 응답을 확인하며, 팀원들과 결과를 공유할 수 있습니다.

쉬운 API 테스트

• UI 기반으로 GET, POST, PUT, DELETE 등 다양한 HTTP 요청을 손쉽게 만들 수 있습니다.
• 요청에 필요한 파라미터, 헤더, 바디 등을 직접 입력하고, 클릭 한 번으로 응답을 바로 확인할 수 있습니다.
• 복잡한 코드 작성 없이도 UI 기반으로 API가 어떻게 동작하는지 쉽게 실험해볼 수 있습니다.

요청과 응답 기록

• 보낸 요청과 받은 응답이 자동으로 기록되어, 언제든지 다시 확인하거나 재사용할 수 있습니다.
• 요청을 저장해두고, 나중에 반복적으로 테스트할 수 있습니다.

팀 협업 지원

• 요청이나 컬렉션을 팀원과 쉽게 공유할 수 있습니다.
• API 문서를 자동으로 생성해주어, 팀원들과의 소통이 쉬워집니다.

개인적 생각

Postman과 Apidog은 문서를 자동으로 생성해주지는 않지만, UI 기반으로 API의 엔드포인트와 요청 값을 입력해 직접 API를 테스트할 수 있는 툴입니다.

이런 방식으로 테스트를 진행하면, 요청과 응답 기록이 자동으로 저장되어 워크스페이스에 초대한 팀원들과 테스트 결과를 함께 관리할 수 있습니다.

특히 서버가 아직 배포되지 않은 상황에서도, API만 동작하는 환경이 준비되어 있다면 프론트엔드 개발자가 워크스페이스에 초대되어 직접 테스트 결과를 확인할 수 있습니다.

이 과정에서 API 명세 문서를 보는 것보다 실제 요청과 응답을 직접 확인하는 것이 이해에 훨씬 도움이 되는 경우가 많습니다.

Postman vs. Apidog: 협업 인원 차이

Postman과 Apidog은 기능적으로 유사하지만, 가장 큰 차이점은 무료로 협업할 수 있는 인원 수입니다.

Postman은 무료 플랜에서 최대 3명까지 협업이 가능하지만, Apidog은 4명까지 지원합니다.

학교 프로젝트처럼 4명 내외의 팀을 구성하는 경우가 많기 때문에, 이런 상황에서는 Apidog이 특히 유용한 선택이 될 수 있습니다.

3. Notion

저는 노션으로 할때는 이런식으로 표 템플릿을 만들어서 API를 각각 정의하고 그 안의 페이지에서 세부적인 요청과 응답에 필요한 값을 세부적으로 적어줍니다.

높은 자유도와 유연성

다양한 형식(텍스트, 표, 코드, 이미지, 다이어그램 등)으로 API 명세를 자유롭게 작성할 수 있습니다. 프로젝트에 맞는 구조를 직접 설계할 수 있어, 팀의 스타일에 맞게 문서를 꾸밀 수 있습니다.

실시간 협업과 공유

여러 명이 동시에 문서를 작성하고, 변경 이력을 쉽게 추적할 수 있습니다. 워크스페이스 내에서 팀원들과 손쉽게 공유하고, 의견을 주고받으며 협업이 가능합니다.

템플릿과 데이터베이스 활용

반복되는 API 명세 형식을 템플릿으로 만들어 일관성 있는 문서화를 할 수 있습니다. 데이터베이스 기능을 이용하면 API 목록을 표 형태로 관리하거나, 필터·정렬이 가능합니다.

비용

저는 학교 계정을 통해서 계정이 업그레이드 된 상태로 사용을 하고 있어서 블록 개수와 같은 게 지장 없이 워크스페이스를 많이 많이 사용할 수 있어 편하게 사용하고 있습니다.

나의 생각

Notion으로 API 명세서를 작성하면 문서의 자유도가 매우 높아서, 프로젝트 상황이나 팀의 스타일에 맞게 원하는 방식으로 정보를 구성할 수 있습니다. 텍스트, 표, 코드 블록, 이미지 등 다양한 요소를 자유롭게 활용할 수 있고, 템플릿 기능을 이용하면 반복적인 작업도 일관성 있게 효율적으로 진행할 수 있습니다. 여러 API 문서를 작성할 때 같은 형식의 템플릿을 적용하면, 팀원 누구나 쉽게 이해하고 관리할 수 있는 구조를 만들 수 있다는 점이 큰 장점입니다.

특히 Notion은 코드에 의존하지 않고, 진짜 문서 기반으로 명세서를 작성하기 때문에 특정 개발자에게 치우치지 않고 팀 전체가 동등하게 의견을 반영할 수 있습니다. 제가 중립성을 강조하는 이유는, Swagger 같은 코드 기반 자동화 도구를 사용할 경우 실제로 백엔드 개발자가 코드를 수정하면서 API 명세를 임의로 바꾸거나, 형식보다는 개인의 편의에 따라 문서를 변경하는 경우를 종종 봤기 때문입니다. 이런 상황에서는 프론트엔드나 다른 팀원이 변경 사항을 바로 알기 어렵고, 커뮤니케이션이 단절되는 문제가 생길 수 있습니다.

반면 Notion에서는 수정 이력 추적과 알림 시스템이 잘 되어 있어서 누가 언제 어떤 내용을 변경했는지 쉽게 확인할 수 있습니다. 문서가 수정되면 팀원들에게 자동으로 알림이 가고, 변경 이력을 통해 이전 상태로 되돌릴 수도 있습니다. 또한 댓글이나 멘션 기능을 통해 의견을 주고받으며 실시간으로 협업할 수 있기 때문에, 팀 전체가 명확하게 소통하고 중립적이고 투명한 방식으로 API 명세를 관리할 수 있습니다.

C. 마무리

이번 글에서는 ERD와 API 명세서 설계 시 협업에 도움이 되는 다양한 툴에 대해, 실제 사용 경험을 바탕으로 주관적인 생각을 정리해보았습니다. 여러 툴들이 존재하고, 각 툴마다 장단점이 다르니 프로젝트 상황에 맞게 선택하는 것이 중요합니다. 특히 첫 프로젝트를 준비하는 분들에게는 상황을 파악하고 툴을 선정하는 데 어려움이 있을 거라고 생각하여, 조금이나마 도움이 되었으면 하는 마음으로 직접 써본 툴 위주로 간단하게 소개해드렸습니다.

툴의 개념적인 설명만으로도 분량이 많아질 수 있어서, 이번에는 툴 소개에 집중해 하나의 글로 정리했습니다. 실제로 프로젝트를 하다 보면 자신에게 딱 맞는 툴을 찾는 과정이 쉽지 않을 수 있습니다. 그래서 저처럼 여러 툴을 직접 사용해보며 느꼈던 점들을 공유하고자 했습니다. 만약 이 글에서 마음에 드는 툴이 있다면, 공식 홈페이지나 다른 사용 후기 등을 참고해보시면 사용법은 금방 익히실 수 있을 거라 생각합니다.

상황에 따라 더 좋은 툴이 있을 수도 있으니, 혹시 추천하고 싶은 툴이 있다면 댓글로 알려주시면 저도 사용해보고 후기를 업데이트하겠습니다. 앞으로도 다양한 협업 도구와 경험을 나누는 글을 계속해서 남겨보겠습니다.

이번 글은 저의 주관적인 생각이 많이 담겨서 내용이 조금 길어진 것 같아요. 읽어보시고 제 생각과 다른 점이 있다면 댓글로 의견 남겨주세요. 함께 더 좋은 방향을 찾아가고 싶어요!

이 글은 첫 프로젝트에서 API명세서를 작성하는 과제를 받은 학생을 위한 글입니다.첫 프로젝트에서 API에 대해 잘 모르는데, API 명세서를 작성해오라는 과제를 받았습니다. 당시 저는 API에 대한 지식이 전혀 없어서,'API 명세서를 작성하라' 는 말을 들었을 때 머릿속에 물음표가 가득했습니다. '통신을 하는 걸 명세하라는 건가?', '보고서처럼 작성해야 하나?' 등 여러 생각이 들었지만, 정작 무엇을 어떻게 작성해야 하는지 몰라 이것저것 검색해보았습니다. 하지만 대부분 문서 형태로만 설명되어 있었고, 이게 진짜 의도한 바가 맞는지, 무엇을 위한 명세서인지 혼란스러웠습니다.

결국 제대로 된 API 명세서를 작성하지 못했고, 그 결과 개발 과정에서 통일성이 없어졌습니다. 개발 실력도 부족한 상태에서 통일성 없는 개발을 하다 보니, API를 계속 수정하게 되었고, 오히려 프로젝트 기간만 늘어나는 상황이 벌어졌습니다.

이 글을 읽는, 저처럼 API 명세서를 처음 작성해보는 분들이라면, 통일성 있는 API 명세서를 통해 개발 시간을 단축하고, 원하는 데드라인에 맞춰 프로젝트를 완수할 수 있기를 바랍니다.

B. 기본 개념

1. API

API란 무엇인가?

API는 Application Programming Interface의 약자로, "어플리케이션 프로그래밍에서의 인터페이스" 역할을 합니다. 여기서 인터페이스란, 두 시스템이 데이터를 주고받을 때 지키는 '약속' 이라고 이해하면 쉽습니다. 즉, API는 두 시스템(예: 프로그램과 프로그램) 간에 데이터를 주고받을 때의 규칙이나 방법을 정의한 것입니다.

음식점 예시로 이해하는 API

음식점에서 손님이 웨이터에게 주문을 하고, 웨이터는 그 주문을 주방장에게 전달해 음식을 받아 다시 손님에게 전달하는 과정을 생각해볼 수 있습니다.

• 손님(프론트엔드): 원하는 음식을 주문(요청)합니다.

• 웨이터(API): 주문을 받아 주방장에게 전달하고, 완성된 음식을 다시 손님에게 전달합니다.

• 주방장(서버): 주문서를 받아 레시피(로직) 대로 음식을 만들어 웨이터에게 전달합니다.

이처럼 웹 프로그래밍에서도 프론트엔드(손님)는 API(웨이터)를 통해 서버(주방장)에게 요청을 보내고, 서버는 처리 결과를 API를 통해 다시 프론트엔드에 전달합니다.

2. RestAPI

웹 개발에서 가장 널리 사용되고, 배우기 쉽고, 확장성과 이식성이 뛰어난 API 방식이 바로 REST API입니다. 많은 첫 프로젝트에서 REST API를 선택하는 이유도 바로 이 때문입니다.

REST API의 기본 개념

REST API는 서로 다른 프로그램(앱, 웹, 서버 등)이 정해진 주소(URL)와 명령어(HTTP Method)만 알면, 서로 정보를 편리하게 주고받을 수 있도록 해주는 약속(규칙)입니다.

• 누구나 주소와 명령어만 알면

• 복잡한 내부 구조를 몰라도

• 데이터를 요청하고, 저장하고, 수정하고, 삭제할 수 있는 표준화된 소통 방법입니다.

REST API 구성요소 – 음식점 비유로 쉽게 이해하기

• 엔드포인트(Endpoint): 음식점에서 메뉴판에 "제육볶음", "돈가스"처럼 각각의 음식이 고유한 이름을 가지고 있듯, 서버에도 각각의 정보(자원)에 접근할 수 있는 고유한 주소(URL)가 있습니다. 이 주소가 바로 엔드포인트입니다.

• HTTP 메서드(Method): 음식점에서 단순히 주문만 하는 게 아니라, "주문하기"(생성), "주문 확인"(조회), "주문 변경"(수정), "주문 취소"(삭제) 등 다양한 행동을 할 수 있듯이, REST API도 각 엔드포인트에서 어떤 동작을 할지 정하는 명령어를 사용합니다. 대표적으로 GET(조회), POST(생성), PUT/PATCH(수정), DELETE(삭제) 등이 있습니다.

• 요청(Request)와 응답(Response): 손님이 "제육볶음 1인분 주세요"라고 요청하면, 주방은 음식을 만들어 "제육볶음 나왔습니다"라고 응답합니다. 이처럼 클라이언트(손님)가 서버(주방)에 요청을 보내고, 서버는 그에 맞는 응답을 돌려주는 구조입니다.

• 데이터 형식: 음식이 그릇에 담겨 나오듯, 서버와 클라이언트가 주고받는 정보도 일정한 포장(형식)으로 전달됩니다. 주로 JSON이라는 형식을 사용해 데이터를 주고받습니다.

• 상태 코드(Status Code): 음식점에서 "주문이 정상적으로 접수되었습니다", "없는 메뉴입니다", "주방 사정으로 제공이 어렵습니다"처럼 주문 처리 결과를 알려주듯, 서버도 요청이 성공했는지, 오류가 났는지 숫자 코드로 결과를 알려줍니다. 예를 들어 200(성공), 201(생성됨), 404(없는 메뉴), 500(서버 오류) 등이 있습니다.

이렇게 REST API는 메뉴판(주소), 주문 방식(메서드), 대화(요청/응답), 음식 포장(데이터 형식), 주문 결과(상태 코드)처럼 누구나 쉽게 이해할 수 있는 규칙으로, 앱과 서버가 정보를 주고받도록 도와줍니다

3. EndPoint

URL 구조

EndPoint URL은 위 그림과 같은 구조로 되어있고, 저희는 Port뒤에 있는 부분을 주목해서 보겠습니다.

• Application Context: 서비스가 여러개일 때 구분자의 역할을 해줍니다. (이 부분은 프로젝트의 크기가 클 때 사용하지만 첫 프로젝트 기준으로는 신경쓰지 않아도 된다고 생각합니다.)

• Version : API 버전은, 기존 손님(사용자)이 헷갈리지 않게 옛날 메뉴판을 그대로 두고, 새로운 메뉴(기능)는 새 메뉴판(버전)으로 따로 제공하는 것과 같다고 생각하면 좋을 것 같아요. 지속적인 업데이트가 되는 부분에서 주로 사용을 합니다.

• Resource : 이 통신에서 데이터의 주체가 되는 것을 말합니다. 예를 들어 주문, 손님, 음식과 같은 주체를 기준으로 나누면 편합니다.

  첫 프로젝트라면 이전 글에서 ERD에서 테이블을 기준으로 나눠줘도 됩니다. 간혹 화면을 중심으로 나누는 경우가 있는데 이렇게 할 경우 API를 재사용이 힘들고, 일관이 떨어질 수 있어서 주의해주세요.

• Path Variable : URL의 경로에 포함되어 특정 리소스를 식별할 때 사용됩니다. 조금 더 쉽게 설명하자면, 음식점에서 3번 테이블에 앉아 주문을 할 때를 떠올려보세요. 이 경우, "/orders/3"과 같은 URL에서 orders는 주문이라는 리소스, 3은 3번 테이블을 가리킵니다.

  URL 경로에 숫자나 이름 등 구체적인 값을 넣어,

• *"어떤 주문인지" 또는 "어떤 대상을 요청하는지"를 정확하게 지정하는 방식입니다.**

• Query Parameter : URL의 ? 뒤에 붙어 추가 옵션이나 검색, 필터링, 정렬 등에 사용되는 파라미터입니다. 조금 더 쉽게 설명하자면, 음식점 사장님이 배달로 들어온 주문 내역을 확인한다고 가정을 한다면
  이 경우, "/orders?type=delivery"과 같은 URL에서 orders는 주문이라는 리소스가 되고 type=delivery는 이를 조회하기 위한 조건이 됩니다.

Path Variable 과 Query Parameter가 비슷하다고 생각을 한다면

• Path Variable은 리소스를 식별할 수 있게 해주는 것과
• Query Parameter 리소스의 속 옵션 이라고 생각하시면 좋을 것 같습니다.

4. Method

Method의 대표적인 것들 만 표로 살펴보면

이를 데이터베이스 쿼리 조회로 생각을 하시게 되면 GET(SELECT), POST(INSERT), PUT(UPDATE), PATCH(UPDATE), DELETE(DELETE)가 되고 URL이 어떤 목적성을 가지고 행동을 할 것 같은지에 대해서 생각을 하면 금방 답을 찾을 수 있으실 겁니다.

5. 상태 코드

상태코드는 서버가 요청을 받았을 때, 그 결과가 어땠는지 숫자로 알려주는 신호입니다. 마치 음식점에서

• "주문이 정상적으로 들어갔습니다!"

• "없는 메뉴입니다!"

• "주방에 문제가 생겼어요!"

라고 알려주는 것과 비슷합니다.

프로젝트에서 많이 사용되는 상태코드를 표로 보여드리면 아래와 같습니다.

코드별 대처법

• 여기서 200번대가 왔다면 프론트 개발자분들 정말 잘하신겁니다. 성공하셨어요.
• 근데 400번대 코드가 왔다면, 프론트 개발에 뭔가 잘못 되었을 가능성이 큽니다. 명세서를 다시 확인해보세요. 나는 진짜 잘못한거 없는데? 라면 그건 백엔드가 명세서를 안지킨거에요. 카톡 보내셔도 됩니다.
• 500번대가 코드가 왔다면, 그냥 바로 백엔드 개발자분께 연락하세요.서버에서 뭔가 잘못되었을 겁니다.

6. Request/Response, 데이터 형식

API를 설계할 때 많은 개발자들이 구조, 성능, 보안 등 다양한 요소를 고민합니다. 하지만 실제로 프론트엔드와 백엔드가 가장 많이 부딪히는 부분은 바로 데이터 형식입니다. 이 글에서는 왜 데이터 형식의 통일이 중요한지, 그리고 이를 어떻게 적용하면 좋은지에 대해 이야기해보겠습니다.

데이터 형식이 중요한 이유

서로 다른 팀이 협업할 때, 혹은 한 사람이 프론트와 백엔드를 모두 개발할 때도, API의 데이터 형식이 일관되지 않으면 코드가 불필요하게 복잡해집니다. 예를 들어, 음식점에서 비슷한 메뉴를 모두 다른 그릇에 담아 내보낸다고 생각해보세요. 설거지와 보관, 재사용이 모두 비효율적이겠죠. API도 마찬가지입니다.

• 일관된 형식은 프론트엔드에서 데이터를 파싱하고 상태를 관리하는 코드를 단순화합니다.

• 재사용성이 높아집니다. 공통된 파싱 함수, 상태 관리 로직을 여러 곳에서 활용할 수 있습니다.

• 유지보수가 쉬워집니다. 새로운 API가 추가되어도 기존 로직을 그대로 사용할 수 있습니다.

공통 응답의 예시입니다.

{
  "status": "{상태코드}",
  "success": true,
  "data": "{반환값}"
}

이렇게 하면 프론트엔드와 백엔드 모두 아래와 같은 장점을 누릴 수 있습니다.

• 프론트엔드: 항상 같은 구조로 데이터를 받아오기 때문에, 공통 파싱 함수로 모든 API 응답을 처리할 수 있습니다.

• 백엔드: 응답을 만들 때 매번 새로운 구조를 고민할 필요 없이, 정해진 그릇에 값만 담아주면 됩니다.

키 네이밍도 통일하자

키 이름이 userId, useRId, userid처럼 제각각이면, 프론트엔드에서 상태 관리 변수나 파싱 로직을 재사용하기 어렵습니다. 키 네이밍 컨벤션을 팀 내에서 미리 정해두는 것이 중요합니다.

• 예시: 항상 userId로 통일

• API 문서에 명확하게 표기

서로를 배려하는 API 설계

API를 설계할 때 "나는 이렇게 주면 편해"가 아니라, 상대방이 어떻게 받을지 한 번 더 고민해보세요. 프론트엔드는 어떤 데이터 구조가 파싱하기 쉬울지, 백엔드는 어떤 구조가 유지보수에 유리할지 서로 의견을 나누며 합의점을 찾아가는 과정이 중요합니다.

• 상황에 따라 트래픽, 성능, 보안 등 우선순위가 달라질 수 있습니다.

• 하지만 기본적으로 통일된 데이터 형식은 협업의 효율성을 극대화합니다.

REST API에서 Request/Response 데이터 형식의 통일은 프론트엔드와 백엔드 모두의 생산성을 높이고, 코드의 재사용성과 유지보수성을 크게 향상시킵니다. 작은 습관이지만, 프로젝트의 규모가 커질수록 그 효과는 더욱 커집니다. 데이터 형식을 통일하는 습관을 가지는 것이 좋습니다.

C. 마무리

저도 처음에는 API 명세서라는 게 너무 막막하고, 어디서부터 어떻게 시작해야 할지 정말 감이 안 잡혔던 기억이 납니다. 하지만 이렇게 하나씩 개념을 정리하고, 음식점 비유처럼 일상적인 예시로 이해하려고 노력하다 보면 어느새 머릿속에 API의 큰 그림이 그려지기 시작하더라고요.

사실, API 명세서 작성이란 게 거창하거나 어려운 일이 아닙니다. 서로 간에 "이런 방식으로 소통하자!"고 약속을 정하는 거고, 그 약속이 잘 지켜지면 개발도 훨씬 수월해집니다. 처음에는 다소 낯설고 헷갈릴 수 있지만, 한 번 제대로 경험해보면 다음부터는 훨씬 쉽게, 또 자신감 있게 작성할 수 있을 거예요.

무엇보다 중요한 건, 혼자서 끙끙대지 말고 궁금한 점이 있으면 팀원들과 적극적으로 소통하는 겁니다. 명세서도 결국 협업을 위한 도구니까요. 그리고 데이터 형식, 키 네이밍, 상태 코드 등 사소해 보이는 부분도 팀 내에서 미리 통일해두면 나중에 훨씬 덜 힘들어집니다.

이 글을 읽으신 분들도 저처럼 시행착오를 줄이고, 통일성 있는 API 명세서를 통해 프로젝트를 더 효율적으로, 즐겁게 완성하실 수 있기를 진심으로 응원합니다! 앞으로도 개발하면서 궁금한 점이 생기면 주저하지 말고 검색하고, 질문하고, 서로 도와가며 성장해나가세요. 여러분의 첫 API 명세서 경험이 좋은 출발점이 되길 바랍니다.

아직 많이 부족하지만 더 좋은 글을 써서 도움이 되도록 노력해보겠습니다. 감사합니다.
다음 블로그 글은 "ERD와 명세서 작성에 활용했던 툴"에 대해서 소개해드릴게요.

이 글은 첫 프로젝트에서 ERD를 그려야 하는 과제를 받은 학생을 위한 글입니다. 저의 경우 첫 프로젝트를 시작할 때 데이터베이스에 대해 어느 정도 알고 있었기 때문에 ERD를 설계하는 데 큰 무리는 없었습니다. 하지만 데이터베이스 테이블 설계를 처음 하거나 개념을 잘 모르는 상태에서 시작한다면, 개발 과정에서 불필요한 절차가 추가될 수 있고, 너무 복잡하게 설계할 경우 개발 시간에 지장을 줄 수 있습니다. 그래서 처음 시작하는 초심자가 알고 있으면 좋을 점들을 소개하고, 저와 주변에서 봤던 사례를 통해 설계를 보다 쉽게 할 수 있도록 이 글을 작성하게 되었습니다.

B. 기본 개념

1. 데이터베이스

데이터베이스는 여러 가지 정보를 체계적으로 저장하고, 필요할 때 쉽게 꺼내 쓸 수 있게 해주는 정보 저장소입니다.

무신사 사이트를 예로 들면, 무신사는 상품들이 카테고리별로 분류되어 있어서 사용자가 아우터가 필요하면 해당 카테고리에 들어가 원하는 옷을 찾아보거나 구매할 수 있습니다.

여기서 ‘이름’, ‘가격’, ‘브랜드’ 처럼 위에 있는 게 바로 열(컬럼)이에요. 그리고 그 아래에 실제로 들어가는 ‘에어포스’, ‘100,000’, ‘나이키’ 같은 정보들이 행(로우)가 되는 거죠. 이때, 중복되지 않는 컬럼을 기본키 (Primay Key) 라고 생각하시면 밑의 내용을 이해하기 편할 것 같습니다.

이렇게 상품 하나하나가 행으로 쌓이면서, 전체가 하나의 ‘상품’ 이라는 표(테이블)가 됩니다. 그리고 이런 표들이 여러 개 모여서, 우리가 흔히 말하는 데이터베이스가 만들어지는 거예요.

데이터베이스라는 건 이런 표(테이블)들이 모여 있는, 일종의 ‘정보 저장소’ 입니다.

2. 정규화

이제 위와 같이 테이블들만 만들어서 데이터베이스를 구성한다고 좋은 설계를 했다고 하기는 어렵습니다. 더 좋은 설계와 개발과정에서 도움이 되기 위해서는 데이터가 불필요하게 여러 번 반복되거나, 엉뚱하게 사라지거나, 잘못 바뀌는 것 을 막기 위해 데이터를 잘 정리해서 저장하는 정규화하는 방식으로 설계를 해야합니다.

정규화에는 제1, 제2, 제3, BCNF, 제4, 제5 와같은 정규화 방식이 있지만 이번 글에서는 제1~제3 정규화 까지 소개해 드릴게요.

이 글을 읽으실 때, 정규화를 해야 하는 이유보다는 정규화를 하지 않을 때 발생하는 문제에 초점을 맞추면 정규화의 필요성을 더 쉽게 이해할 수 있습니다. 이런 방식으로 접근하면 데이터베이스 설계 시 명확한 의도를 가지고 설계할 수 있습니다.

3. 제1정규화

데이터베이스 테이블의 각 컬럼(열)에 반드시 하나의 값만 들어가도록 만드는 것입니다. 즉, 한 칸에 여러 개의 값(리스트, 배열 등)이 들어가면 안 되고, 반복되는 값이나 그룹이 있으면 각각의 값이 따로 저장되도록 테이블을 나누는 작업입니다.

위의 표는 제1정규화가 적용되지 않은 대표적인 사례입니다. 제1정규화에서는 컬럼에 하나의 값만 들어가야 하지만, ","를 통해 두 개의 값이 들어간 것을 볼 수 있습니다. 이런 구조에서는 데이터를 조회할 때 ","를 기준으로 파싱해야 하거나, 상품 목록을 추가할 때 이전 값에 문자열을 이어 붙이는 등의 불필요한 작업이 추가로 필요할 수 있습니다.

뿐만 아니라, 삭제할 때도 예를 들어 '아식스'를 삭제하고 싶다면, 해당 컬럼을 불러와서 '에어포스, 아식스'라는 문자열에서 '아식스'만 삭제하고 다시 업데이트해야 하는 불편함이 생깁니다.

이렇게 테이블을 설계하면,

• 상품별로 데이터를 쉽게 추가, 수정, 삭제할 수 있습니다. 예를 들어, 특정 주문에서 '아식스'만 삭제하거나 추가할 때 한 행만 삭제/추가하면 되기 때문에 훨씬 간단합니다.
• 상품별 검색이 쉬워집니다. '에어포스'를 주문한 모든 고객을 바로 조회할 수 있습니다.
• 데이터 중복과 오류를 줄이고, 데이터 무결성을 지킬 수 있습니다.
• 저장 공간도 효율적으로 사용할 수 있습니다.

4. 제2정규화

제2정규화는 데이터베이스 정규화 과정 중 두 번째 단계로, 제1정규화를 만족한 테이블에서 "부분 함수 종속"을 제거하는 작업입니다.

이렇게만 말하면 “부분 함수 종속이 뭐야?” 라는 의문이 생길 수 있어요.

아래와 같은 주문 테이블에서 다시 설명하겠습니다.

여기서 주문번호는 한 번의 주문을 의미하고, 한 주문에는 여러 상품이 들어갈 수 있습니다.

• 한 주문(주문번호)은 여러 상품(상품코드)을 가질 수 있으니 일대다(1:N) 관계입니다.
• 반대로, 한 상품(상품코드)은 여러 주문에 포함될 수 있으니 다대일(N:1) 관계도 숨어 있습니다.

부분 함수 종속이란?

이 테이블에서 기본키는 (주문번호, 상품코드)입니다. 왜냐하면 이 두 개를 묶어야만 각 행이 유일하게 구분되기 때문입니다.

• 상품명과 브랜드는 상품코드만 알면 항상 정해집니다.
• 예를 들어, 상품코드가 A001이면 상품명은 항상 '에어포스1', 브랜드는 항상 '나이키'입니다. 즉, 주문번호와 상품코드(두 개의 정보)로 행을 구분하지만, 상품명과 브랜드는 상품코드(한 개의 정보)만으로 결정됩니다. 이렇게 기본키 전체가 아니라 일부(상품코드)만으로 다른 값이 정해지는 것을 “부분 함수 종속”이라고 합니다.

부분 함수 종속이 있으면 생기는 문제

1. 데이터 중복과 관리의 어려움 예를 들어, '나이키' 브랜드 이름이 '나이키스포츠'로 바뀌면, 상품코드가 A001인 모든 행의 브랜드를 일일이 수정해야 합니다. 만약 이런 행이 수십만 개라면? 수정이 너무 번거롭고, 일부만 바꾸면 데이터가 서로 달라질 수 있습니다.

2. 불필요한 데이터 중복 같은 상품(예: A001 에어포스1 나이키)이 여러 주문에 포함될 때마다 똑같은 상품명과 브랜드가 반복 저장됩니다. 이로 인해 데이터베이스 용량이 커지고, 관리가 어려워집니다.

2정규화로 해결하기

이 문제를 해결하기 위해 2정규화를 적용합니다. 상품코드만 알면 알 수 있는 정보(상품명, 브랜드)를 별도의 상품 테이블로 분리하는 거죠.

이렇게 하면,

• 주문 테이블은 한 주문에 어떤 상품이 들어있는지만 관리합니다. (주문과 상품의 다대다 관계를 연결)
• 상품 테이블은 상품코드별로 상품명과 브랜드를 한 번만 저장합니다. (상품과 브랜드의 다대일 관계)

5. 제3정규화

제3정규화 는 데이터베이스 정규화의 세 번째 단계로, 2정규화까지 마친 테이블에서 '직접적인 관계가 없는 정보끼리의 간접적인 의존성' 을 없애는 과정입니다.

3정규화가 필요한 이유

2정규화를 거치면 중복이 줄고, 부분 함수 종속이 사라집니다. 하지만 여전히 직접적으로 연결되지 않은 정보끼리, 다른 정보를 통해 연결(의존)되는 문제가 남아 있을 수 있습니다. 이런 관계를 전이적(간접적) 종속이라고 부릅니다.

부분함수 종속이랑 별 다를게 없는거 아니라고 생각할 수 있을 거 같아 아래의 표로 다시 설명드리자면

여기서 상품코드만 알면 상품명과 브랜드를 알 수 있습니다. 그런데 브랜드주소는 상품코드가 아니라, 브랜드만 알면 항상 정해집니다.

이때 브랜드는 기본키가 아닌 컬럼 입니다. 이게 전이적(간접적) 종속이고, 상품코드 → 브랜드 → 브랜드주소 이런 관계가 형성 됩니다. 반면, 부분 종속 함수는 기본키 중 일부만 사용해서 값이 정해지는 것을 의미합니다.

전이적(간접적) 종속이 있으면 생기는 문제

• 브랜드주소가 '나이키' 브랜드에 속한 상품마다 반복 저장됩니다.
• 만약 나이키 본사가 이사하면, 나이키 브랜드가 들어간 모든 상품의 브랜드주소를 수정해야 합니다.
• 실수로 일부만 수정하면, 브랜드주소가 서로 다르게 남아 데이터가 꼬일 수 있습니다.

3정규화로 해결하기

3정규화는 이렇게 간접적으로 연결된 정보를 분리해서, 각각의 정보가 "직접적으로"만 연결되도록 테이블을 나누는 과정입니다.

위와 같이 하게 되면 테이블의 각각의 정보들이 직접적으로만 연결이 이루어질 수 있습니다.

• 이제 브랜드주소가 바뀌어도 브랜드 테이블 한 곳만 수정하면 됩니다.
• 상품 테이블에는 브랜드만 저장되니, 중복이 사라지고 관리가 쉬워집니다.

C. ERD 설계 순서

1. 요구사항 파악 및 테이블 도출

무엇을 저장할지, 어떤 기능이 필요한지 정리

• 이전 단계에서 디자인(와이어프레임)을 통해 시각화한 요구사항을 보며, 어떤 데이터가 필요한지 적어봅니다.
• 이해가 안 되면 “어떤 데이터를 저장해야 이 서비스가 동작할까?”를 계속 고민해보세요.

팁:

• 명사(사람, 상품, 주문 등)를 중심으로 생각하면 테이블이 쉽게 보일 거에요.

2. 테이블별 정의

각 테이블에 어떤 정보가 들어갈지 나열

• 예를 들어 “회원” 테이블에는 이름, 이메일, 비밀번호, 가입일 등이 들어갑니다.
• “주문” 테이블에는 주문번호, 주문일시, 회원ID, 배송주소 등이 들어갑니다.
• 각 테이블의 기본키(Primary Key)도 정합니다
• 저는 덤벙거리는 성격이여서 정보를 빼먹지 않기 위해서 디자인(와이어프레임)을 여러번 보면서 뭐가 필요할까? 고민하는 과정을 여러번 반복합니다.

팁:

• 처음에는 생각나는 대로 최대한 많이 적어도 괜찮습니다. 나중에 정규화 과정에서 정리하면 됩니다.

3. 테이블 정규화

정규화를 잘하려면, 각 데이터를 “이 정보가 어디에 속해야 가장 자연스러운가?”, “이 정보는 무엇에 의존해서 결정되는가?” 라는 질문을 반복적으로 던지며 테이블을 나누는 것이 중요합니다.

팁 :

1. 정보의 소속과 관계를 문장으로 풀어보세요.

• “상품은 브랜드를 가진다.”
• “주문은 여러 상품을 가진다.”
• “상품은 한 브랜드에 속한다.”
• “회원은 여러 주문을 할 수 있다.”

  이런 식으로 관계를 중얼중얼 거리면, 어떤 데이터가 어느 테이블에 있어야 할지, 테이블 간의 연결이 어떻게 되어야 할지 쉽게 떠올리는데 많이 도움되는 것 같아요.(저는 손가락으로 테이블을 이동하면서 중얼거려요.)

2. 중복과 불필요한 의존성을 찾아 분리하세요.

• 한 테이블에서 같은 정보가 반복된다면, 그 정보는 별도의 테이블로 분리해 더 효율적인 설계를 할 수 있을거에요.
• 어떤 값이 기본키 전체가 아닌 일부에만 의존한다면, 그 속성은 따로 떼어내야 합니다.
• 한 정보가 다른 정보에 간접적으로 의존한다면(예: 상품이 브랜드주소를 직접 갖고 있다면), 중간 단계를 분리해 각각 직접적으로만 연결되도록 만드세요.

정규화 과정에서 테이블 간 관계도 자연스럽게 명확해집니다.

“는 ~를 가진다”, “에 속한다”처럼 관계를 문장으로 만들어보면, 어떤 테이블이 어떤 테이블과 연결되어야 하는지 쉽게 파악할 수 있습니다. (중얼거리기가 저만의 팁인거 같아요.)

D. 마무리

첫 프로젝트를 하는 분들을 대상으로 했기 때문에 단계를 조금 간소화하여 적었지만, 프로젝트를 진행하면서 시간적 여유가 있다면 ERD 설계의 순서를 이론적으로 한 번 더 찾아보시는 것을 추천드립니다. 제가 생각하는 ERD 설계의 핵심은 어떤 정보를 저장할지와 서로 어떻게 분리해야 효율적일지를 가장 많이 고민하는 것 같습니다. 차근차근 도식화해 보세요! 정규화를 무조건 한다고 해서 항상 좋은 것은 아닙니다. 많은 경험을 쌓고 개발에서 불편함을 겪다 보면, 정규화를 하지 않는 것이 더 좋은 경우도 있을 거예요.

다음 글은 "API와 명세서" 라는 글로 뵙겠습니다.

이 글은 첫 팀 프로젝트를 시작하는 분들을 위해 준비했습니다. 저 역시 처음에는 어디서부터 손을 대야 할지 몰라 많이 헤맸던 기억이 있습니다. 그래서 저처럼 막막함을 느끼는 분들이 조금이나마 쉽게 다가갈 수 있도록 읽는 사람이 가장 이해하기 쉽게 쓰려고 합니다.

저는 앞으로 첫 프로젝트를 준비하는 분들에게 도움이 될 만한 내용을 시리즈로 작성할 예정입니다. 이번 글에서는 첫 프로젝트를 할 때 꼭 알려주고 싶은, 제가 많이 사용한 프로젝트 진행 프로세스를 소개하려고 합니다.

글을 쓰면서 저도 다시 한 번 프로젝트 과정을 정리해 보고, 여러분께 도움이 되는 경험을 나누고 싶어요. 혹시 읽으시다가 궁금한 점이나 본인만의 팁이 있다면, 댓글로 자유롭게 남겨 주시면 서로에게 큰 도움이 될 거예요.

B. 설계의 중요성

프로젝트를 처음 하는 분이 보통 생각하시는 게 기획과 설계를 후다닥 하고 개발 기간을 길게 잡자라는 분들을 많이 보았던 것 같습니다. 하지만 이렇게 하면 설계와 기획의 부재로 개발 기간이 더욱 길어져 마감 기한을 잘못 잡을 수 있습니다. 기획과 설계가 탄탄할수록 구현 기간이 짧아지고, 오히려 모두가 한 곳을 바라보게 되어 좀 더 양질의 프로젝트가 나오는 것 같다고 생각합니다.

위에 사진 처럼 구현,구축 단계는 많은 프로세스 중 일부에 해당합니다. 예전에 피드백을 해주신 CSO(최고전략책임자)분 께서는 기획과 설계를 통해서 모두가 한 곳을 바라 볼 수 있게 하는 게 중요하다고 하셨고, 저 또한 모두가 같은 생각을 할 때 프로젝트의 개발 및 수정상황에서도 빠르게 이해하고 이행할 수 있는 팀합이 나오게 되는 것 같았습니다.

🧭 설계는 항해를 할때 나침반의 역할을 해준다고 생각합니다. 나침반 없이 항해하는 배가 목적지에 잘 도착 할 수 있을까요?

C. 프로젝트 설계 (나만의 방법)

프로젝트를 진행할 때 저는 아래와 같은 순서로 설계를 진행합니다.

• 아이디어 선정
• 기능 명세 ( 프로젝트 구체화 )
• 디자인 ( 와이어프레임 )
• 피드백 ( 와이어프레임 기반 피드백 )
• 데이터베이스 설계, API 설계
• 피드백 ( 프론트-백엔드 협업 조율 )
• 구현

가장 중요하다고 생각하는 피드백 단계를 위해 위와 같은 프로세스로 프로젝트를 진행합니다. 아래에서 각 단계에서 어떤 일을 하고, 어떤 부분을 중요시하는지 소개해 드리겠습니다.

1. 아이디어 선정

저는 프로젝트 아이디어를 정할 때 흥미롭고 재미있어 보이는 주제를 선호합니다. 세미나, Meet-up과 같은 강연을 듣거나 최신 기술 트렌드에서 영감을 얻는 경우가 많아요. 하지만 대부분의 팀원들은 처음엔 ‘뭘 해야 할지 모르겠다’ 는 막막함을 느끼는 경우가 많습니다. 흔히들 “이게 정말 괜찮은 아이디어일까?”, “너무 평범하지 않을까?” 라는 고민을 하게 되죠. 그래서 중요한 것이 브레인스토밍 입니다. 보통은 각자 생각나는 아이디어를 자유롭게 공유한 뒤, 여러 의견을 합쳐보거나, 서로의 경험을 바탕으로 현실적인 주제를 선택하는 것이 모두가 만족하는 프로젝트의 주제가 될 수 있습니다.

💡 저 역시 처음엔 ‘특별한 아이디어’ 에 집착하다가 의견을 내지 못했지만, 일단 던져보고 브레인 스토밍을 하며 함께 이야기를 하니 더 좋은 아이디어가 되는 걸 경험했습니다.

2. MVP 선정

아이디어가 정해지면, 저는 기능을 리스트로 쭉 적어보고 우선순위를 정하는 방식으로 진행합니다. 핵심 기능(MVP)만 남기고, 부수적인 기능은 과감히 빼는 편이에요. 대부분 처음 팀 프로젝트를 하는 분들은 ‘이것도 넣고 싶고, 저것도 해보고 싶다’ 며 기능을 많이 넣으려는 경향이 있습니다. 하지만 이렇게 하면 실제 구현 단계에서 부담이 커지고, 일정에 쫓기게 됩니다. 그래서 많은 분들이 “처음엔 욕심을 많이 냈다가, 결국 핵심만 남기고 나머지는 포기했다” 는 경험을 공유하곤 합니다.

또한 이 과정에서 중요한 것은 "이 기능을 구현할 수 있을까?" 입니다. 저는 MVP를 선정하는 과정에서 사용할 것 같은 기술이나 기능들의 레퍼런스 를 찾아보면서 예상 시간과 현실 가능성을 찾아 보는 편입니다. 이것의 결과를 MVP선정과 프로젝트의 볼륨을 정하는 편입니다.

저 역시 첫 프로젝트 때는 많은 기능 욕심에 부리다가, 첫 프로젝트를 완성하지 못한 경험이 있습니다. 지금은 꼭 필요한 기능부터 차근차근 구현하는 게 가장 효율적이라는 걸 깨달았습니다.

3. 디자인 ( 와이어프레임 )

전공 첫 팀 프로젝트에서는 기획자라는 역할이 명확하지 않아 요구사항 명세가 부족해질 수밖에 없다고 생각합니다. 이런 상황에서 저는 와이어프레임 작업의 중요성을 강조합니다.

와이어프레임은 팀 프로젝트의 요구사항을 시각적으로 표현하는 첫 단계입니다. 프로젝트가 실제로 어떻게 동작할지, 어떤 흐름으로 진행되는지 모든 팀원이 한눈에 이해할 수 있도록 도와줍니다.

또한, 프로젝트는 결국 디자인된 UI 위에서 모든 기능이 구현되고 동작하기 때문에, 백엔드 개발자도 와이어프레임을 꼼꼼히 살펴봐야 한다고 생각합니다. 와이어프레임을 통해 프로젝트의 시나리오와 전체적인 흐름을 파악하면, 프론트엔드와의 소통도 훨씬 원활해지고, 실제 연동 과정에서 발생할 수 있는 이슈도 빠르게 발견하고 해결할 수 있습니다.

아직 현업 경험은 없지만, 지금까지의 경험상 프로젝트에 대한 이해도와 관심이 높을수록 디버깅도 훨씬 수월하게 느껴졌습니다. 그래서 저는 와이어프레임 작업이 단순히 디자인을 위한 단계가 아니라, 모든 팀원이 프로젝트를 깊이 이해하고 협업의 기반을 다지는 핵심 과정이라고 생각합니다.

4. 피드백

와이어프레임 기반 피드백

기능 명세가 어느 정도 정리된 후에는, 프로젝트의 기능적 구조만을 담은 와이어프레임을 작성합니다. 이 과정에서 모든 팀원이 각 기능이 어떻게 동작하는지 시각적으로 확인할 수 있습니다.

💡 와이어프레임을 통해 각자의 생각을 한 번 더 맞춰보고, 구체적인 요구사항을 명확히 할 수 있습니다. 특히 첫 프로젝트에서는 세세한 요구사항을 문서로만 정리하기 어렵기 때문에, 시각적인 자료가 큰 도움이 됩니다.

5. 데이터베이스 설계, API 명세서

데이터베이스 설계

먼저 ERD는 데이터베이스의 테이블 구조와 관계를 시각적으로 정의하는 도구입니다. 저는 프로젝트 요구사항이나 디자인을 참고해 필요한 데이터를 정리하고, 어떤 API에서 어떤 테이블이 사용될지 고민합니다.

이후 테이블을 정규화하여 데이터베이스를 설계합니다[4].
ERD 설계 과정에서는 데이터베이스에 대한 기본 지식이 필요하며, 설계 초기 단계에서 충분히 논의하고 검토하는 것이 중요합니다.
왜냐하면 잘못 설계된 데이터베이스는 성능 저하, 데이터 중복, 무결성 문제 등 다양한 문제를 초래할 수 있기 때문입니다.
이번 블로그에서는 프로젝트 순서 중 ERD 설계가 왜 필요한지, 어떤 역할을 하는지 인지하시면 좋겠습니다.

데이터베이스 설계 과정에서 API의 초안을 머릿속으로 생각하거나 적어 보면서, API 명세서를 작성할 때 참고하는 편입니다.

API 명세서 작성

프론트와 백엔드는 따로 작성한다고 생각하시겠지만, 결국 이 둘은 소통을 해야 하며, 이때의 약속과 협력 과정이 API 명세서 작성 단계라고 생각합니다. 저의 경우, 프론트가 디자인을 기반으로 퍼블리싱 작업을 시작하면, 제가 ERD, MVP, 디자인을 참고해 필요한 API 명세서를 작성한 뒤, 프론트와 피드백을 주고받으며 수정할 부분을 확인합니다.

API 명세서에는 프론트와 백엔드가 통신할 때 필요한 HTTP Method, URL, JSON 요청/응답 형식, 진행 상황, 담당자 등을 기록해 누가 어떤 부분을 수정하고 진행하는지 확인할 수 있습니다.

저는 처음 프로젝트에서 API 명세서를 작성해야 한다고 했을 때, 어떻게 작성해야 하는지 몰라 우왕좌왕했던 기억이 있습니다. 이 글을 보시고 노션 API 명세서 템플릿이 필요하시다면 댓글로 남겨 주세요.

저의 경우, 노션을 통해 API 명세서를 작성하는 것이 어느 한쪽에 치우치지 않고 중간에서 문서 관리가 잘 이루어지는 것 같아 이 방법을 선호합니다. 하지만 이 방법 이외에도 Swagger나 다른 툴을 사용해서 API 명세서를 작성할 수 있습니다.

6. 피드백

프론트-백엔드 협업 조율

데이터베이스와 API 설계가 끝난 뒤에는 프론트엔드 개발자와 함께 개발 방향을 다시 한 번 조율합니다. 서로의 이해관계를 확인하고, 실제 구현에서 발생할 수 있는 이슈를 미리 점검합니다.

💡 만약 프론트엔드에 프로젝트 경험이 적은 분이 있다면, 저는 백엔드에서 부담을 더 가져가고 프론트엔드가 더 편하게 개발할 수 있도록 역할을 조정합니다. 팀원의 역량과 상황에 따라 업무를 유연하게 분배하는 것이 프로젝트의 완성도를 높인다고 생각합니다.

이런 과정을 통해 프로젝트를 진행하면 팀원 모두가 같은 목표를 향해 나아갈 수 있고, 예상치 못한 문제도 미리 발견하여 효율적으로 대응할 수 있습니다.

D. 마무리

프로젝트를 처음 시작할 때 느끼는 막막함과 두려움은 누구나 겪는 자연스러운 과정입니다. 저 역시 첫 팀 프로젝트를 준비하며 많은 시행착오를 겪었고, 그 경험을 바탕으로 이번 글을 정리하게 되었습니다.

프로젝트 설계와 피드백, 그리고 팀원 간의 소통이 얼마나 중요한지 다시 한 번 느끼게 되었고, 이 과정을 통해 모두가 같은 목표를 향해 나아갈 때 훨씬 더 완성도 높은 결과물을 만들 수 있다는 것을 알게 되었습니다.

여러분도 이 글에서 소개한 단계들을 차근차근 따라가며, ‘나도 할 수 있다’ 는 자신감을 꼭 가져가셨으면 합니다. 완벽한 계획이나 특별한 아이디어가 아니어도 괜찮아요. 중요한 것은 팀원들과 함께 고민하고, 피드백을 주고받으며 조금씩 나아가는 과정 그 자체입니다.

혹시 프로젝트를 진행하면서 궁금한 점이나 공유하고 싶은 팁이 있다면, 댓글로 자유롭게 남겨주세요. 서로의 경험을 나누며 함께 성장하는 즐거움을 느끼셨으면 좋겠습니다. 여러분의 첫 팀 프로젝트가 좋은 추억과 값진 경험이 되길 진심으로 응원합니다! 읽는 분들이 '나도 할 수 있겠다'는 자신감을 얻어가셨으면 좋겠습니다!

"혼자가면 빨리갈 수 있지만, 함께 가면 더 멀리 갈 수있다." 라는 말 처럼 프로젝트라는 것도 함께 완성이라는 먼 과정을 가야하는 것이라고 생각합니다. 이 글을 있는 분들의 첫 프로젝트가 완성이라는 개발의 시작이라는 출발점에 도착하길 빌겠습니다. 다음 글은 ERD 설계의 기본개념 라는 글로 뵙겠습니다.

개요

Helm은 그냥 npm같은 개념이라고 생각하고 있는데 이게 정말 맞는 것인지 세미나를 들으면서 알아 가고 싶습니다.

스터디 전 스몰토크 📢

이제 좀 친해져서 서로 말을 편하게 하게 된 것 같아서 좋아요

챕터 1: Kubernetes 복습

핵심 개념

• 쿠버네티스(Kubernetes): 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 플랫폼입니다. 복잡한 컨테이너 오케스트레이션 작업을 단순화하여 개발자와 운영팀의 효율성을 높여줍니다.
• kubectl: 쿠버네티스 클러스터를 제어하고 관리하기 위한 명령줄 도구입니다. kubectl을 사용하여 파드 생성, 서비스 노출, 로그 확인 등 다양한 작업을 수행할 수 있습니다.
• Namespace: 클러스터 내 리소스를 논리적으로 분리하는 데 사용됩니다. 서로 다른 팀이나 프로젝트가 같은 클러스터를 공유할 때, Namespace를 통해 리소스를 격리하고 관리할 수 있습니다.
• cgroup: 컨테이너 또는 프로세스 그룹이 사용할 수 있는 CPU, 메모리 등의 자원을 제한하는 데 사용됩니다. cgroup을 통해 특정 컨테이너가 과도한 자원을 사용하여 다른 컨테이너에 영향을 주는 것을 방지할 수 있습니다.

왜 쿠버네티스를 사용하는가?

• 쿠버네티스는 다음과 같은 이점을 제공하여 현대적인 애플리케이션 개발 및 운영에 필수적인 도구로 자리 잡았습니다.

• 확장성: 애플리케이션의 부하에 따라 자동으로 파드를 추가하거나 제거하여 효율적인 자원 활용을 가능하게 합니다.

• 고가용성: 여러 노드에 파드를 분산 배치하고, 장애 발생 시 자동으로 복구하여 애플리케이션의 가용성을 높입니다.

• 셀프 힐링: 파드 또는 노드 장애를 감지하고 자동으로 복구하여 시스템의 안정성을 유지합니다.

• 선언적 구성: YAML 파일을 통해 원하는 시스템 상태를 정의하면, 쿠버네티스가 자동으로 해당 상태를 유지합니다.

챕터 2: Helm 소개

Helm이란 무엇인가?

• Helm은 쿠버네티스 애플리케이션의 패키징, 배포, 관리를 단순화하는 패키지 관리자입니다. 복잡한 쿠버네티스 YAML 파일들을 관리하는 어려움을 해결하고, 애플리케이션 배포 과정을 간소화합니다.

Helm의 핵심 구성 요소

• Chart: Helm 패키지의 기본 단위입니다. 애플리케이션을 구성하는 쿠버네티스 리소스들의 템플릿과 설정 정보를 포함합니다.
• Repository: Chart를 저장하고 공유하는 저장소입니다. Helm 클라이언트는 Repository에서 Chart를 검색하고 다운로드할 수 있습니다.
• Release: Chart를 특정 쿠버네티스 클러스터에 설치한 인스턴스입니다. Release는 고유한 이름과 버전을 가지며, 업그레이드 또는 롤백이 가능합니다.

Helm을 사용하는 이유

• 재사용성: Chart를 통해 애플리케이션 구성을 템플릿화하고, 다른 환경에 쉽게 재사용할 수 있습니다. 버전 관리: Release를 통해 애플리케이션의 배포 버전을 관리하고, 필요에 따라 이전 버전으로 롤백할 수 있습니다.
• 의존성 관리: Chart 간의 의존성을 관리하여 복잡한 애플리케이션을 효율적으로 배포할 수 있습니다.
• 커뮤니티: Helm은 활발한 커뮤니티를 통해 다양한 Chart를 제공하고, 사용자 지원을 제공합니다.

챕터3: 실습

minikube를 사용해서 helm 사용해보기

• 직접 클러스터를 만들어보고 파트를 생성해보면서 지난번 실습때 제대로 아쉬웠던 부분을 많이 보강할 수 있었던 것 같습니다.
• 또한 심화 학습을 할 수 있는 링크를 첨부하여 향후 공부 방향성을 제시했던 것이 도움이 되었습니다.

스터디 후기

• 비유법을 많이 사용해서 설명을 해주셨는데 이해하는데 너무 좋았습니다. 마스터노드를 정부, 노드들을 토지로 비유해주어 저도 다른사람에게 설명할 때 비유법을 통해 이해를 쉽게 할 수 있도록 세미나를 해보고 싶어졌습니다.

개요

목차별 간략 설명 및 마크다운 정리

1. DevOps, FaaS, CaaS

• DevOps: 개발(Development)과 운영(Operations)의 합성어로, 소프트웨어 개발과 IT 운영 간의 협업을 강조하는 문화, 방식, 도구를 의미합니다.
• FaaS (Function as a Service): 함수 단위로 코드를 실행하고 관리하는 클라우드 서비스 모델입니다. 서버 관리 없이 코드만 작성하여 실행할 수 있습니다.
• CaaS (Container as a Service): 컨테이너 기반 애플리케이션을 실행하고 관리하는 클라우드 서비스 모델입니다. 컨테이너 오케스트레이션 및 확장을 쉽게 처리할 수 있습니다.

2. 도커 그 이후...

• 도커 이후의 문제점들: 도커 사용 시 발생하는 컨테이너 관리, 확장, 네트워킹 등의 문제점을 다룹니다.
• Container Orchestration: 쿠버네티스와 같은 컨테이너 오케스트레이션 도구의 필요성과 역할을 설명합니다.
• 클러스터: 여러 서버를 하나의 시스템처럼 운영하는 클러스터 개념과 장점을 설명합니다.
• 상태 관리: 컨테이너 환경에서 데이터 및 설정 정보의 지속성을 유지하는 방법을 다룹니다.
• 배포 관리, 배포 버전 관리: 컨테이너 기반 애플리케이션의 효율적인 배포 및 버전 관리 전략을 설명합니다.
• 서비스 등록 및 조회, 볼륨 스토리지: 서비스 디스커버리, 컨테이너 간 데이터 공유 및 영속적인 스토리지 관리 방법을 다룹니다.
• 정리: 도커 이후 등장한 기술들의 핵심 내용을 요약합니다.

3. Kubernetes의 기본 개념

• 컨테이너: 도커 컨테이너와 쿠버네티스에서의 컨테이너 활용 방식을 설명합니다.
• 파드: 쿠버네티스의 기본 배포 단위인 파드의 개념과 역할을 설명합니다.
• 쿠버네티스에서의 파드 운영: 파드 생성, 관리, 확장 등의 방법을 다룹니다.
• 노드, 워커노드: 쿠버네티스 클러스터를 구성하는 노드와 워커노드의 역할을 설명합니다.
• 쿠버네티스: 쿠버네티스의 핵심 기능 및 아키텍처를 설명합니다.

4. Minikube로 실습해보기

• Minikube: 로컬 환경에서 쿠버네티스 클러스터를 실행할 수 있는 Minikube 도구를 소개합니다.
• Minikube 설치: Minikube 설치 방법을 안내합니다.
• Minikube를 이용해서 로컬 쿠버네티스 클러스터를 생성: Minikube를 사용하여 로컬 쿠버네티스 환경을 구축하는 방법을 설명합니다.
• MSA 프로젝트 로컬에서 실행해보기: Minikube 환경에서 MSA (Microservices Architecture) 프로젝트를 배포하고 실행하는 실습을 진행합니다.
• Minikube GUI 설치: Minikube GUI 도구를 설치하고 사용하는 방법을 안내합니다.
• 포트포워딩으로 서비스 확인: Minikube 환경에서 외부 접속을 위한 포트 포워딩 설정 및 서비스 확인 방법을 설명합니다.

  스터디 목표

  쿠버네티스를 공부하기 위해 필요한 기본적인 개념의 진입 장벽을 낮춰보자. !!

스터디 전 스몰토크 📢

추석주에 진행했던 스터디여서 추석에 다들 있었던 일과 추석연휴로 인해서 생긴 휴강들이 많아서 재미있는 TMI들이 많아서 많이 웃었던거 같아요.

스터디 자료

메일 주시면 세미나 자료 드리겠습니다.

• email: rokmcp150@dgu.ac.kr

  스터디를 준비하며

  세미나 준비를 이틀 전에 시작을 했습니다. 쿠버네티스라는 것이 공부를 하면서 느꼈지만, 정말 많은 개념이 있고 진입장벽이 좀 높다는 생각을 많이 하게 되었습니다.

그래서 기본적인 개념을 위조로 스터디원들이 잘 이해할 수 있도록 세미나를 준비하려고 노력하였습니다. 하지만 기본적인 개념만 다루고 이를 실습에 적용하려고 하니 세미나의 전체적인 내용이 실습에 반영되지 않았던게 가장 아쉬웠습니다. 그래서 다음에 또 세미나를 하게 된다면 이런 부분을 잘 준비해야겠다는 생각을 했습니다.

개요

이번 세미나는 클라우드 컴퓨팅의 역사, 그리고 Docker 입니다. 세미나 전에 도커를 사용은 하고 있지만 도커가 뭔지는 정확히 공부한 경험이 없어서 재미있는 세미나가 될 거 라고 생각했습니다.

이번 세미나에서는 클라우드 컴퓨팅, 컨테이너, 도커등의 전반적인 역사와 사용하게 된 배경에 대한 플로우로 진행되었습니다.

스터디 전 스몰토크

스몰토크는 크게 없었지만 스터디 전에 같이 점심을 먹으면서 간단한 아이스브레이킹(?) 하는 시간을 가졌습니다.

세미나 내용 정리

클라우드 컴퓨팅이란?

• 클라우드 컴퓨팅: 인터넷을 통해 필요한 만큼의 컴퓨팅 자원을 사용하는 방식입니다. 물리적 서버 구매 대신 가상화된 자원을 활용합니다.
• 클라우드 서비스 모델: IaaS, PaaS, CaaS, SaaS
• IaaS (Infrastructure as a Service): 예시로 Amazon EC2가 있습니다.
• PaaS (Platform as a Service): IaaS보다 더 많은 기능을 제공합니다. 운영 체제와 런타임 환경까지 포함됩니다. 예: Vercel, Heroku
• SaaS (Software as a Service): 완전한 소프트웨어 솔루션을 제공합니다. 예: Notion, Gmail
• CaaS (Container as a Service): 컨테이너 관리 도구
  • 예시: Amazon EKS, Google Kubernetes Engine

클라우드 컴퓨팅의 발전 과정

• 온프레미스 (On-premise): 물리적 서버 + 베어메탈 (자체 OS로 애플리케이션 실행)
• 2000년대 초반: 가상화 기술 도입, 하지만 여전히 물리적 서버 사용
• 2000년대 중반: 클라우드 컴퓨팅의 초기 형태 등장
• 2010년대: Docker 기술 도입
• 현재: 쿠버네티스 (Kubernetes) 도입 및 확산

베어메탈 (Bare Metal) 환경

• 전통적인 방식 (약 40년간 사용): 실제 하드웨어에 직접 OS 설치, 단일 OS에 단일 애플리케이션 구동
• 주요 문제점: 고사양 서버의 리소스 낭비, 버전 관리의 어려움, 보안 취약성 (한 지점의 침해가 전체에 영향), 확장성 제한 등 다양한 운영상의 문제점 발생

가상화 기술

• 단일 물리적 컴퓨터를 여러 가상 환경으로 분할하여 사용
• 하이퍼바이저 (Hypervisor): 단일 물리적 컴퓨터에서 다수의 운영 체제를 동시에 실행할 수 있게 하는 기술. 이로 인해 가상 머신 (VM) 시대가 시작되었습니다.
• 장점: VM의 리소스 할당을 통한 자원 격리 가능. 베어메탈의 문제점 대부분 해결. 각 VM은 독립된 환경을 제공하며, VM 간 통신은 내부 IP와 포트를 통해 이루어집니다.
• 현재 과제: 유휴 리소스의 효율적 관리 방안 모색 중

온프레미스(On-premise) 방식

• 이 방식은 앞서 언급한 방식들의 문제점을 해결하려는 시도입니다.

오프프레미스(Off-premise) 방식: 클라우드 컴퓨팅

• 장점 → 사용한 만큼만 비용을 지불합니다.
• AWS는 온프레미스인 반면, 오프프레미스 방식을 사용하면 자원 확보가 용이합니다.

VM(가상 머신)의 한계

• VM은 각각 독립적인 운영체제를 가지고 있어 무겁습니다.
• 이를 개선하기 위해 컨테이너가 등장했습니다. 경량화 별표 5개 컨테이너는 커널을 공유하여(운영체제 공유와 유사) 일관된 실행 환경을 구축합니다.
• 컨테이너는 OS를 포함하지 않아 매우 가볍습니다. 빠르고 필요한 기능을 모두 갖추고 있어 확장성이 뛰어납니다.
• 컨테이너 런타임: 컨테이너를 실행하고 관리하는 소프트웨어 (예: Docker)
• User Space → Docker가 생성한 컨테이너 내부에 User Space가 있으며, 여기서 동일한 OS 커널을 공유합니다.

하드웨어 CPU 구조: CISC(복잡한 구조), RISC(ARM, 스마트폰에 주로 사용되는 구조)

클러스터 기반 오케스트레이션 도구

• 여러 서버를 하나의 시스템처럼 자동화하여 클러스터를 구성합니다.
• 확장성 있게 배포하고 관리합니다. 노드를 물리적으로 파드, 노드로 구성합니다.

컨테이너

• Docker 데몬이 컨테이너 생성에 관여합니다.
• 커널은 운영체제의 일부이며, 운영체제는 소프트웨어입니다. 커널에서 컨텍스트 스위치가 일어나 CPU 등으로 전환됩니다.
• 운영체제는 커널과 사용자 GUI 등으로 구성됩니다. 각 컨테이너는 호스트의 커널을 공유합니다.
• 컨테이너는 OS를 어떻게 공유할까요?
• User Space → 사용자 앱이 실행되는 영역으로, 각 컨테이너는 하나의 User Space를 가집니다.
• 컨테이너 런타임 → 컨테이너 이미지를 생성하고 관리하는 소프트웨어입니다. Namespace와 Cgroups 같은 격리 메커니즘을 설정하여 컨테이너 간, 그리고 컨테이너와 외부 간의 독립성을 유지합니다.
• 컨테이너 이미지 → 코드, 종속성, 파일 시스템을 포함한 불변의 템플릿입니다.
• Namespace와 Cgroups는 커널의 기능입니다. Docker가 제공하는 것이 아니라 커널이 제공하는 것으로, Docker는 이를 이용해 하드웨어 자원을 그룹별로 관리합니다.
• Cgroups API를 이용해 컨테이너를 그룹화하여 자원을 분리합니다.
• Docker Desktop을 실행할 때 노트북 RAM을 많이 사용하는데, 이는 리소스를 먼저 많이 할당한 후 관리하는 방식인가요?
• Namespace에 대해 더 자세히 알아보기

컨테이너가 채택한 파일 저장 방식

• 오버레이 파일 시스템: 업데이트가 계속 쌓이는 방식입니다.
• 불변성을 유지하기 위해

  스터디 후기

  도커에 대해서 조금 알고 있긴했고 사용하면서 편리하다고는 생각은 많이했습니다. 하지만 이거를 왜 쓰는지 사용하면 어떤게 좋은지에 대해서 알지 못한 상태로 사용을 했습니다.

이번 세미나에서 클라우드 컴퓨팅 부터 시작해서 많은 실습과 역사를 자연스럽게 이어주는 방식으로 세미나를 진행해 주셔서 직접 실습하면서 이래서 좋고 이래서 안 좋았다는 것을 알게 되어서 너무 재미있었습니다.

개요

Goorm Univ 동국대학교 첫 OT로, 앞으로의 활동의 계획들과 각 스터디 별로 준비한 스터디에 대한 간략한 진행계획을 발표하는 시간을 가졌습니다.

활동

OT에서 앞으로 할 활동에 대한 소개와 각자 소속된 스터디 1주차 활동보고서를 공유하는 시간을 가졌습니다.

각 스터디를 소개하고 자기소개를 했는데 오랜만에 하는 자기소개여서 은근히 긴장히 되더라고요..ㅎㅎ

모든 팀의 스터디 계획을 들었는데 모두 열심히 준비하고 있고 좋은 스터디들이 많다는 것을 알게 되었어요.

OT시간에는 다들 처음보는 자리여서 어색한 분위기가 있었는데 뒷풀이에 가서 다같이 술을 먹으니 다들 말이 많고 활동적인 사람들이 많더라고요. 그래서 더 재미있었습니다.

다른 사람들과 친해지고 싶어서 술도 많이 먹고 다 먹고 다같이 사진도 찍었어요

후기

이번년도 종강을 하고 교내 단과대에서 주최한 해커톤에 처음으로 참가하여 대상을 받았습니다.

해커톤을 하면서 마음 맞는 사람들과 함께 빠른기간내에 만들어 내는 해커톤이라는 것에 관심이 생겼고, 좀 더 체계적으로 진행되는 해커톤에 참가하고 싶어 구름 univ에 지원을 하였습니다.

구름 univ에서는 해커톤 전에 역량을 증가시키기 위해서 KDC/KDT와 같은 역량 증가를 위한 활동을 할 수 있는 해준다고 합니다.

또한 같은 자체적으로 스터디를 만들고 참여할 수 있는 시스템을 만들어서 저는 이번에  "ArgoCD 오픈소스 컨트리뷰션 스터디" 에 들어가게 되었습니다. 단순한 오픈소스 기여만을 목적으로 하는 스터디가 아닌 인프라 세미나를 준비해서 발표하는 스터디여서 인프라 역량을 향상시키기에 너무 좋은 스터디에 들어간 거 같습니다.