본문 바로가기
기타/주절주절

[리뷰] Git을 통한 효율적인 자기소개서 작성하기 (a.k.a Git을 통한 효율적인 문서 저장 및 관리)

by YangsDev 2020. 1. 6.

나는 고등학교 졸업 이후, 병특을 위하여, ‘선취업 후진학’ 코스를 선택하게 되었다.

사실 거의 반년전부터 준비는 하고 있었지만, 변명을 좀 하자고 하면 자기소개서 (이하 자소서) 를 작성하기엔 ‘회사 프로젝트', ‘개인 프로젝트’ 등이 일정의 발목을 잡았다.

최종_최종_최종_아니진짜_최종_이제그만하자_최종.png

 

시간이 비교적 부족 했던 나는 저렇게 비효율적으로 글을 과연 적어야할까? 좀 더 효율적인 글 관리 방법은 없을까? 라는 고민을 해결 하고자 일단 요구사항을 정리 해보았다.

“글을 가장 빠르게 작성하고, 리뷰받고, 수정 사항을 하나 하나 다 남겨서, 나중에 히스토리 체크 및 롤백 하기도 편했으면 좋겠는데?”

음.. 먼가 어디서 많이 본 기분이다.

‘글'을 ‘코드’로 바꿔보았다.

“코드를 가장 빠르게 작성하고, 리뷰받고, 수정 사항을 하나 하나 다 남겨서, 나중에 히스토리 체크 및 롤백 하기도 편했으면 좋겠는데?”

Git으로 관리 안했으면 시간안에 다 못적었을것같다 라는 생각이 많이 든다.

생각해보면 결론적으로는 코드 형상 관리와 같은 요구사항이라는 생각이 들었다.

그래서 Git을 통해 자기소개서를 적어보기로 했다.

언제나 어디서나 작성 가능

이 부분도 매력적인 포인트로 일부 작용을 한 것 같다.

사실 상 인터넷이 접속되고 Github.com 접속이 가능하다면 언제나 가장 최신의 글을 베이스로 작성이 가능하다.

그래서 그때 당시 시간이 없었던 나는 버스에서 아이패드로도 적고, 휴대폰으로도 적고, 점심시간에도 적고, 정말 환경에 구애를 받지 않고 열심히 작성하였던 기억이 난다.

할일은 이슈로 정리

자기소개서 작성을 시작할때, 기본적으로 지금 당장 해야하는 일과 아닌일로 구분되게 된다.

나의 경우는 자기소개서 수정 일정이 긴 학교의 문항은 우선순위를 낮췄고,

비교적 짧은 학교들의 항목은 우선순위를 높혀보았다.

<주제를 잡고 글을 작성하는걸 이슈로 나눠서 관리 하는 모습>

그리고 1차 검수 2차 검수 오탈자 검수 등의 필요한 업무등으로 너무 나눴더니, 개발회사에서 겪는 티켓 관리와 같은 이슈를 겪어서 (일감이 너무 많아지는 이슈) 태그로 관리하게 중간에 정책을 변경하였다.

태그를 통한 상태 관리

 

이전에 적었던 그 문장이 생각이 안난다

망했..

이 부분이 가장 큰 장점이 아닐까 라는 생각이 든다.

자기소개서를 처음에 적을때 방향성에 대한 부분이 부족하여, 이런 내용으로 이야기를 적다가, 다시 돌렸다가 이렇게 적다가 저렇게 적다가 생각해보니 이게 더 좋은것 같아서 이전껄 찾아보려고 하면 기억이 안나는 아름다운 상황이 발생을 한다.

하지만 Git을 통해 좀 세세한 커밋을 하거나, IDE의 Local History 기능을 사용하면 이런 문제는 사라진다.

나의 경우는 조금 세세하게 커밋을 자주 자주 하고, 작업을 마치기전에 한방에 push를 했다보니 어디에서든 롤백이 가능했고 이전에 머라고 적었는지 참고하면서 적을 수 있었다.

초안 작성이 완료되면 Release 태그 관리

QA님 v1.0.2.0 릴리즈 했습니다 첨삭좀요~

어느정도 글의 뼈대가 완성되고 이제 첨삭을 시작 할 단계에 올랐다.

이전에 동생들의 자기소개서를 첨삭 해주면서 가장 자주 했던 대화를 떠올려보니 아래와 같았다.

“그래서 어떤게 최종 파일이냐?”

“아 선배 그게 아니라 이게 최종 파일이예요 ㅈㅅ”

“아…….. 그게 아니라 이게 최종이네요”

글을 쓰는 사람들도 여러가지 버전이 있다보니 어떤게 첨삭을 받아야 하는 최신 버전인지 모르는 경우가 너무 많았다.

그래서 개발 할때 처럼 릴리즈 알파, 베타 태그를 생성하고 첨삭을 받고 릴리즈 태그를 기반으로 이슈를 관리하고 등록하였다.

첨삭은 이슈&PR로 관리

알바 버전의 자소서까지 나오면 이제 첨삭을 시작한다.

그러면서 나오는 이슈들에 대해 여기저기 많은 채널을 통해 따로 듣다보니, 너무 정리가 안되었다.

 

이것도 어디서 많이 경험 해본 뉘양스다.

회사에서 베타 오픈을 했을때 여러 부서에서 많은 요청이 들어오게 된다.

그거랑 정말 똑같은 상황이 생겼다.

그래서 이슈 기능을 사용하기로 했다.

첨삭자 : 이건 좀 아닌듯?

 

기본적으로 어떤 내용에 대한 나의 코멘트가 어땠다 라는 이야기등을 남겨주면 아래와 같이 내가 코멘트를 남기면서 의견을 조율 했다.

작성자 : 아니다 악마야

 

또한, 글을 작성하면서 어떤 생각과 방향성을 가지고 작업했는지, 이 부분을 왜 이렇게 바꿨는지 등을 이슈 코멘트와 이슈와 연동된 커밋 메세지를 통해 확인 하다보니, 중간에 방향성이 흔들리는 일이 적어서 좋았다.

기억에 남는 재미있는 일은, 첨삭 하는 사람들끼리 이게 맞다 저게 맞다 하고 이슈에서 싸운 적도 있었다.

맞춤법 체크 및 PDF 생성을 위한 CI/CD

이 부분은 시간 관계상 실제로 하지는 못했지만, 구상했던 방법을 한번 적어본다.

기본적으로 맞춤법 띄어쓰기에 대해서는 1차 작성을 하고 수정하는 경우가 많았다.

그러다보니 막판에 글자수를 잘못 계산해서 급하게 글을 압축 하는일이 꽤 있었다.

이런 문제를 어떤식으로 해결 했어야 했을까 하고 고민을 해봤더니

매번 push 마다 맞춤법 검사를 돌리고, 띄어쓰기 체크를 한 후, 질문 별 글자수를 체크 했다면 더 좋지 않았을까 라는 생각도 해본다.

물론, 맞춤법 검사에 대해서는 기계가 잘못 이해 하는 부분이 있었을테니, CI봇을 통해 Issue를 생성 시켰어야 했을것같다.

아무래도 비개발자직군에게 첨삭을 요청할땐 PDF를 수동으로 생성해서 전달 했는데, 생각해보면 이 부분도 태그 발생 이벤트에 트리거를 걸고 MD를 PDF 로 변환하고 특정 링크를 통해 다운받게 했으면 시간을 조금 더 줄일수있지 않았을까 하는 생각이 든다.

마치며

< 3년뒤 이 사람은 반대로 첨삭을 해주게 됩니다.>

회사 업무와 자기소개서 작성을 병행하다 보니, 개인 시간은 사라지고 남는 건 피로 뿐이었다.

퇴근 후 7시에 잠들어서, 그 다음날 오후 7시에 일어날 정도로 엄청 피곤했다.

이렇게 처음부터 효율적으로 작업 할 수 있던 것은 내가 개발자이기 때문이라고 생각한다.

 

하지만, Git을 써본 경험이 없는 사람들도 조금만 배운다면 효율적으로 문서 관리를 할 수 있을 것이라 생각한다.

기회가 된다면 회사내에 문서를 많이 적는 그룹에도 한번 공유를 하고 싶다.

 

이 자리를 통해 개인적인 시간을 반납해 가면서

자소서 첨삭을 도와주신 Lesh Lee님, Dry8r3aD님, 배주웅님, 선윤지님, 송혜민님께 감사를 표한다.

에필로그

이 글에 대해 도움을 줬던 배주웅에게는 미리 글을 보여줬는데, 블로그 글도 첨삭 해줬다.

그리고 글 자체가 개발자들을 제외하곤 보기가 어렵다고 생각 될 수 도 있다고 본다.

처음에 초고를 작성 할땐 비개발자들도 이해할만한 예시와 기타등등을 고민 하였으나, 글이 너무 루즈 해질것같다 라는 생각이 좀 들어서 그냥 진행하지 않았다.

 

댓글0