오늘 내일배움단 활동을 처음 시작한 날이다..
오전 9시부터 오티를 하는데,
매니저님이 전반적으로 앞으로 4개월간 부트캠프를 어떻게 진행할 것인지
운영방식, 다양한 자료들이 있는 notion & 슬랙 &
어떤 마음으로 임해야하는지.. 개괄적인 내용을 접했다.
앞으로 4개월간 나는 어느정도로 성장하게 될까.
이건 오롯이 내 의지와 집중력에 달려있는 것이다..
나는 어떤 개발자가 되고 싶은지 생각하게 됐다.
좋은 개발자란? 이란 잘문에 대한 답을 스스로 내려오고 있었는데,
오늘 OT에서 제시해주는 내용과 결이 비슷하단 느낌을 받았다.
[1] 자기주도적으로 성장해나갈 줄 아는 사람이면서
[2] 팀과의 협업능력, 소통능력 One for All 정신이 있는 사람.
결국 완벽한 개발자는 완성된 인간과 비슷하다는 생각을 하게 됐다.
그래서 개발자가 더 좋아졌다.
개발자가 추구하는 모습의 그것과, 결국 한 인간이 살아가는 모습이 비슷하다고 느꼈기 때문이다.
좋은 개발자는 팀을 위하는 것이 나를 위한다는 것을 아는 사람이다.
이 세상 모든 위대한 일은 혼자 만들어진 것이 아닌 것처럼
예전과 같이 콘솔게임 혼자 개발하는 천재개발자의 시대는 갔고,
이제는 대규모로 팀을 이뤄가며 협업하는 시대가 됐다.
나의 이익과 나의 성장에만 매몰되어, 좁은 시야로 혼자만을 위한 맘으로 살아가면
어느 한계에 반드시 부딫히게 된다. 굵고 짧게 간다고 할까?
팀원을 챙기고, 팀을 사랑하며 개발자는 그렇다고 '얇게' 가는 것일까?
아니다.
팀을 위한 개발자는
1) 팀원의 의견을 존중하며 소통하며 내가 보지 못한 다른 시야를 얻고 성장한다.
2) 한 사람이 보는 면과, 두 사람이 보는 면은 차이가 크다. 하물며 몇십명의 시야는 개인의 시야보다 더 더 넓다.
팀을 존중하고 소통할 줄 아는 개발자는, 그런 '시야의 확장 기회'를 많이 얻는다.
이건 어떤 종류의 혼자 하는 성장보다 드라마틱한 변화를 가져온다는 것을 알고 있다.
3) 무엇보다, 내가 왜 개발을 하는걸까? 왜 일을 하고, 사회의 구성원으로 살아가는걸까?
개발이 재밌어서 - 라는 이유도 있겠지만, 무엇보다 행복을 위해 하는 것이 개발이라는 직업이다.
행복의 충분조건에는 돈, 최소한 먹고살 수 있는 직업 등등의 조건들이 붙을 수 있어도
행복을 이루는 요소는 결국 사람간의 정, 사랑, 애정과 추억을 주고받는 것이 매우매우 크다고 생각한다.
( 자아 성취, 자아의 발견, 성장 등의 행복도 있지만 - 이 또한 팀을 위한 개발자에겐 자연스럽게 따라온다 )
결국 죽을 때 가장 먼저 생각나는 것은, 내가 짠 코드들이 아니라 내가 사랑하는 사람과 나누었던 사랑의 흔적이다.
( 물론 코드도 생각날 수 있겠지 ㅋㅋ )
팀원을 사랑하지 않을 이유가 없다.
이제 4달간 새로운 시작이다. 전역한지 2주, 나 다시 열심히 살아보고 싶다.
===============
[ Git ]
개발자는 일할 때 팀원과 협업을 하게 된다.
내가 혼자 일하면 그냥 나 혼자 소스코드 수정하면서, 개발을 해나가면 되겠지만
요즘 같은 시대에서는 많은 사람들과 하나의 프로젝트 = 큰 소스코드를 짜기 때문에
특정 시점에 공유해놓았던 마더 프로젝트의 버전을 내가 작업하는 도중에,
다른 팀원 A가 마더 프로젝트를 수정해서 최신 버전의 마더프로젝트를 만들 수 있다.
그럼 나는 A한테 전화해서, 그 소스코드좀 메일로 보내주세요~ 하고 바뀐 파일에다가 내가 작업한 내용을 또 덮어쓰고..
그렇게 작업 끝내고 올리려고 하니까, 또 다른 팀원 B가 마더프로젝트를 수정해놨다면...
벌써부터 짜증나고 일할 맛이 안난다.
이런 팀원들간의 유의미한 결과물들이 쌓여 생긴 프로젝트의 "버전"을 관리해주는 툴이 git이다.
[ Git이 관리하는 '공간' ]
[1] 작업공간
- .git 파일이 존재하는 곳이다.
- " git init " 명령어를 통해, 현재 디렉토리 하에 있는 파일/폴더들을 git을 통해 버전관리를 시작할 수 있다.
( init = initialize : 초기화하다 라는 뜻이다 )
[2] 스테이지
- 작업공간에서 작업을 하다보면, 프로젝트에 있어서 "유의미한 변화"들이 생긴다.
버전에서의 변화는 결국 파일, 폴더 내용의 수정으로 이루어진다.
a 파일 ~ z 파일을 다 수정했지만, 내가 "의미있는 변화"에 해당한다고 생각하는 파일들은 따로 조합이 있을 것이다.
예를 들어, 웹 사이트에 로그인 기능을 구현했을 때
a파일 / c파일 / d파일 / q파일의 조합이 서로 의존적으로 로그인 기능을 구현하게 했다면
그 파일들만 ! 지금 버전의 다음 버전의 후보로 삼을 수 있는 것이다.
그 후보들을 넣어놓는 장소가 바로 "스테이지" 이다.
" git add a.txt c.js d.css q.txt"
이런 식으로 내가 원하는 a / c / d / q 파일을 스테이지에 올릴 수 있다.
즉, 이번 버전에 있는 파일 + 디렉토리 상태에서, a / c / d / q 파일을 수정한 결과물이
다음 버전이 될 후보자가 되는 것이다.
[3] 저장 공간 ( repository )
- 스테이지에 있는 "유의미한 변화"에 해당하는 파일 또는 디렉토리의 수정본을 저장소에 등록하는 것이다 ( = 다음 버전으로 등록 )
- 저장 공간에 저장된 코드는 이제부터 새로운 마더 프로젝트가 된다.
- git commit -m "새로운 버전의 특징을 설명하는 메시지"
이 명령어를 통해, 새로운 버전을 만들고, 그 버전이 어떤 의미를 가지는 지 메시지를 달아놓을 수 있다.
[ 로컬 레포지토리 / 리모트 레포지토리 ]
로컬 레포지토리와, 리모트 레포지토리가 따로 있지만,
일단 기억이 나지 않으니. 내일 작성해보겠다.