개발자들은 다양한 프로그램을 활용하여 기존의 것 또는 새로운 것을 만들게 되는데, 새로운 버전에서 문제가 발생하여 이전 버전으로 롤백해야하거나, 이전에는 주로 활용되지 않는 기능으로 파악하여 삭제했는데 다시 구성하거나 복원해야하는 경우가 간혹 있다.

이때, 파일을 일일이 가지고 있으면 저장소 관리 측면에서도 비효율적이며 다시 구성해야하는 문제까지 발생하게 되는데 이런 문제를 방지하고 효율적으로 관리하게 도와주는 시스템이 오늘 작성할 VCS(Version Control System : 이하 VCS 또는 버전 관리 시스템)이다.

Git은 대부분의 개발자들이 활용하고 있고, 다양한 OS 기반에서 사용이 가능하다. 개발자들이 가장 활발 하게 사용 하고 있는 Git에 대해 서술해보겠다.

Git : 클릭시 git 홈페이지로 이동

git 메인 홈페이지에 기재되어 있는 깃에대한 설명인데, 해석해보자면

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

' 깃은 무료 오픈소스로서, 분산된 버전을 컨트롤하기 위해 디자인 되었고, 소형 프로젝트부터 대형 프로젝트에 이르기까지 효과적으로 컨트롤 할 수 있습니다. ' 라고 쓰여 있다.

이때 키워드는 ' 분산된 버전 ' 과 ' 컨트롤 ' 이라 볼 수 있는데,

많은 프로젝트를 진행하다보면 이미 폐기되어 비활성화된 프로젝트가 아닌 이상 프로젝트 내용은 계속 변하기 마련이다.

다만 계속 변해가는 내용중에서 특정 업데이트 이후 발생하게된 버그가 있어 이전 버전과 비교 또는 이전 버전으로 롤백 해야하거나 이전 버전의 프로젝트를 보관해야하는경우 사람이 개별적으로 보관하는건 소형프로젝트가 아니라면 문제가 발생(잘못 덮어쓰기 해버렸거나, 데이터를 소실했거나 등) 하기 마련이고 자동화를 기본적으로 생각하게되는 개발자 입장에선 비효율적인 행동일 것이다.

다시 git 홈페이지의 설명으로 돌아가보면,

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

' 깃은 쉽게 배울수 있으며 작은 청사진을 제공 함으로써 가볍고 빠른 퍼포먼스를 제공합니다. Subversion , CVS, Perforce, ClearCase와 같은 SCM(공급망 관리) 툴의 기능을 압도하는 기능 : 가벼운 로컬 브랜칭 , 편리한 스테이징 에리어, 다중 작업 흐름 관리를 제공합니다. '

이 내용의 키워드는 ' 다른 툴을 압도 하는 기능 ' , ' 쉽게 배울수 있다 ' 두가지가 될텐데,

실제로 활용되는 예시들을 찾아보면 Git을 단독으로 사용하기 보단 Git과 GitHub를 같이 활용하게 된다.

이때 git은 버전을 나눠 저장하기 위한 도구로써 활용되고 github는 git의 정보들을 인터넷에 올려두는 온라인 저장소의 역활을 하게 된다.

오늘은 git에 대해 간단히 알아보았고, 설치법 및 상세 활용편은 추후 작성하여 연계하도록 하겠다.

추후 작성할 내역

• Git 설치법
• Git 활용편

취업을 준비하고 있는 입장에서 취업을 위해 최근 회사들이 요구하는 스택이나 지식이 어떤건지 주기적으로 파악하면서 필요한걸 골라내다보니, 배우는 내용들이 급증하기 시작했다.

다들 블로그를 쓰는데는 이유가 있구나...

개발 공부를 진행함에 따라 배운 내용이 쌓이고 자주 쓰지 않는 지식들은 기억의 바닥에 눌려 ' 아, 이거 분명 배웠던 내용인것 같은데? 이건 어떻게 쓰는거고 어떤 영향이 있었지? ' 같은 추상적인 지식만 생각나 실제 활용하는데 어려움이 생기기 시작했고, 지속적인 정리의 필요성을 직접 느끼게 되어 예전에 작성하고자 했으나 차일피일 미루게 된 velog를 다시 활용해보기로 했다.

지속 가능한 블로그 활용을 위해

주기적으로 업데이트하여 내가 작성해야할 내용들은 어떤건지, 작성한 내용은 어떤 내용이 있는지 index 처럼 활용하기 위해 본 내용을 작성하게 되었다.

추후 블로그를 작성할 때 ' 복잡해서 뭘 해야할지 모르겠다.'라는 핑계로 작성을 미루게 되는것을 방지하기 위해 리스트를 작성하는 규칙을 먼저 정했다.

리스트 작성 규칙

1. 우선순위가 높을 수록 상단에 작성할 것.
2. 대분류는 [ > ] 를 사용해 인용 형식으로 (인용문 작성으로 칸을 나누는 효과를 통해 대분류를 좀 더 빠르게 파악 할 수 있도록), 중분류는 하단에 [ - ]키를 활용하여 리스트화, 세부내용은 [ Tab - ] 를 활용해 들여쓰기된 리스트화할 것.
3. 작성이 완료된 경우 작성한 내용을 하이퍼 링크 등록 후 내용이 최초 작성된 날짜, 추가 업데이트한 날짜 및 업데이트 내역을 적을 것.
4. 되도록이면 작성 할 내용을 한가지 주제를 정해 작성하되, 내용이 방대한 경우 [ 기초 > 이해 > 응용 ] 또는 [ 기초 > 대안 > 발전 ] 형태로 작성할 것.
5. 적어도 작성하는 동안은 해당 내용을 명확히 이해한 뒤 작성 할 것.
6. 적어도 1주에 한번 이상 글을 작성하되, 부득이 하게 작성하지 못하는 경우 어떤 내용을 작성할지 정하여 해당 내용의 초안을 작성해 둘 것.
7. 중간에 작성하는것을 포기하지 말고 자주 들여다 볼 것.

내용 작성 규칙

1. 블로그 작성은 [ 지식의 이해 > 지식의 저장 > 이해한 내용의 전달 > 전달과정에서 발생하는 지식의 확장 ]을 목표로 한다.
2. 축약어를 사용하는경우 원어를 추가 기재해두고, 국어로 대응 되는 단어가 있는 경우 해당 단어를 소괄호 안에 확장기재하여 둔다. ex) JS(JavaScript : 자바스크립트) = 1번 항목의 '이해한 내용의 전달'을 함에 있어 내용을 처음 접하는 사람도 연계된 내용을 보기 전에 해당 페이지만으로도 이해할 수 있게 돕기 위함 및 글 작성시 내 지식의 확장 연계를 위해 기재하기로 한다.
3. 2번 항목에서 작성한 내용이 같은 페이지 내에서 재언급 되는경우 처음을 제외한 이후 작성시에는 확장기재를 하지 않는다. ex) JS(JavaScript : 자바스크립트) 는 HTML , CSS 만으로 구동되던 Web을 이용자에게 (...) 이러한 이유로 JS를 널리 활용하게 되었다. = 내용을 작성함에 있어 불필요한 타이핑이 늘어나게 되고 가독성이 떨어질 우려가 있다.
4. 단편적인 지식 전달이 목표가 아닌 온전한 지식의 전달 및 읽는이의 이해를 돕기 위해 작성한다. = 그 지식을 찾아 온 사람이 일부의 지식으로 잘못된 지식이 생기지 않게 방지 하기 위함 및 추후 내가 다시 수월하게 이해하기 위함이다.
5. 연계되는 내용이 이미 작성되어 있는 경우 관련 내용의 링크를 추가해둔다. 연계되는 내용을 작성할 예정인 경우 추가 예정임을 본문에 표기해두고 블로그맵(현재페이지)에 메모해둔다.
6. 당연하게도 참고한 자료들(Reference : 레퍼런스)의 링크를 모두 하단에 기재해둔다.

Usable knowledge

• VCS (Version Control System : 버전 관리 시스템)

  • Git : 2022.03.12
  • Github
  • Before Git ( Git 이전 : Subversion , Mercurial , CVS )

• Design Model ? : 개발 디자인 모델

  • Design Model : MVC ( Model-View-Controller 모델 )
  • Design Model : MVP ( Minimum Viable Product 모델 )
  • Design Model : MVVM ( model-view-viewmodel 모델 )
  • Design Model : Flux ( Flux 모델 , 편의상 모델로 분류했으나 실제로는 Flux Architecture 로 구분.)

• DevOps

• Develope Model ? : 개발 방법론

  • WaterFall 워터폴 방법론
  • Lean 린 방법론
  • Agile 애자일 방법론

• OOP (Objective Oriented Programming : 객체 지향 프로그래밍)

• SEO (Search Engine Optimization : 검색엔진 최적화)

• Markdown (.md)

FE (Front End)

• web
• Web Publisher
• Front End Developer
• HTML(Hyper Text Markup Language) , CSS (Cascading Style Sheets)
• Vanilla JS
• ECMA Script
• JS es5 & JS es6
• Node.js
• Library Vs. Framework
• React
• React-native
• TypeScript

면접대비 자문 자답

• 만들어본 프로젝트는 무엇이 있습니까?
• 비전공자인데, 어떤 방식으로 개발을 배웠습니까?
• 독학을해서 어려웠던점이 무엇입니까?
• 왜 FE로 시작했습니까?
• 왜 React를 배웠습니까?
• 어떤 것들을 만들어 봤습니까?

CS (Computer Science)

• 네트워크 및 통신 관련 지식

리스트 작성 2022.02.19

학점은행제 마감일정 처리로 2022-03-31 까지 2주간 작성한 이력 없음 1주일 휴무 후 다시 작성 시작 예정

취업을 하기 위해 여러 프로젝트를 거치게 되고, 개인 프로젝트와 팀을 이뤄 만드는 프로젝트 모두 기술적으로 배워둔걸 정리해둘 필요가 있다고 판단되어 기술 블로그를 만들어 볼까 고민해봤다. 리스트업 한 목록은 다음과 같다.

Naver, Daum 등 포털사이트 에서 제공하는 블로그 Tistory Velog gh-pages 첫째로 Naver, Daum 의 경우 기본적인 텍스트 에디터가 불만족 스러웠고 마크다운을 쓰기에 부적합해 추후 gh-pages 등으로 개인 블로그를 만들어 나갈 예정인 나로써는 추후에 번거로운 일이 생길거 같아 제외. (스마트 에디터 2 로 바뀐 네이버도 내 생각으론 그다지 좋게 보이지 않았다. )

둘째로 생각하게 된 Tistory 의 경우 마크 다운 형식을 활용할 수 있고 꾸며 나갈 수 있다는 장점이 있지만 온갖 광고로 덕지덕지 치댄 모습의 블로그 형태를 자주 봐서 그다지 좋게 보이지 않았고 일간 작성 글 수 제한이 있다는 점이 추후 불편할거 같았다.

그래서 세번째로 생각했던 Velog는 가끔 구글링으로 개발 정보를 찾다보면 마주하게 되던 깔끔한 이미지 사이트 였기 때문에

Velog 에서 기술 블로그를 시작하게 되었다.

최근 특정 문제가 있었던 것으로 보여 불안하긴 했지만,

어차피 처음부터 깃헙 gh-pages로 하나하나 만들어 가볼 생각이 있어서 나중에 옮겨갈 예정인것도 있고, Notion 에서 기본적인 초안이나 백업 형태는 작성해둘테니 내용의 유실은 걱정할 필요가 없을거 같다는 판단끝에 서비스 종료 관련된 부분은 염려하지 않기로 했다.

얼마나 많은걸 쌓아 나갈 수 있을지 기대반 걱정반 수학여행 전날의 그 기분을 다시 느끼는것 같다.

※ 본 내용은 2021년에 작성해둔 내용을 새로 정리함에 따라 2022.02.19 재등록 하였습니다.