HOME INFO PROJECT BLOG ESSAY
Article Projects Lab
한국어 English
article |

글또 10기를 마무리하며

빠르게 지나간 6달을 돌아보며..

사실 마지막 12주차 글은 기술 글로 마무리할까 싶었는데, 이상하게 손에 잡히지 않아 급하게 회고로 틀었다.

24년 회고에 글또 활동의 절반을 얼추 적긴 했는데, 디테일도 부족하고 연말에 의무감때문에 적은 느낌이 들기도 해서 이번에 10기 활동을 마치면서 반 년 가량 걸어왔던 길을 돌아보자.

이번 회고의 목적은 글또 시작 당시의 목표를 돌아보고 아쉬운게 있었다면 무엇이었는지 적는 것이다.

글또의 시작

딸기 농사 한 작기를 마치고, 작년 7월에 서울로 올라온 나는 개발자가 되기로 마음은 먹었지만 방향을 잡지못해 바다를 둥둥 떠다니는 배 같았다.

보통 개발을 시작하면 부트캠프를 가곤 하는데, 나는 혼자 해낼 수 있을 것이라는 이유 모를 확신이 있어서 혼자 공부를 계속 이어나갔다.

개발 스택도 얼추 정했지만 시장이 얼어서 그런건지 내 결과물이 흥미롭지 않아서 그런지 면접까지 가는 비율이 적었다.

거기에 ‘내가 되고자 하는 개발자의 모습은 무엇일까?‘에 대한 고민을 하던 시기였다. 개발자로서 뭔가 추구미가 없었다고 해야될까..

그러던 중, 우연히도 (아마 트위터였던거 같은데) 글또 모집 공고를 보게 되었다. 내가 좋아하는 글쓰기, 거기다 온라인에서만 보던 개발자들과 만날 수 있는 네트워킹 기회도 있다?

비전공자로 개발을 시작함에 있어 어려움을 겪었던 부분 중 하나가 ‘네트워킹’이었다. 조언을 구할 사람이 없었던 것! 너무 좋은 기회여서 지원서를 작성하기 시작했다.

그런데 왠걸 시작부터 ‘삶의 지도’를 쓰라니 이 무슨?! 유년기부터 지금까지 어떻게 현재의 내가 형성되었는지에 대한 글을 작성해본적이 좀 되어서 신선하기도 했고 ‘뭐 이런거까지?‘라는 생각을 했었다.

제출 전 날까지 ‘흠 귀찮은데 하지말까?‘라고 잠시 생각을 했었는데, 결과적으로 제출했고 지금 생각하면 너무나 잘한 선택이다.

그렇게 온 메일. 사실 잊고 있다가 ‘너무 글을 대충 썼나’싶었는데, 알고보니 스팸 메일에 들어가있어서 소식을 뒤늦게 확인했던 것이다.

합격이라는 소식을 꽤나 오랜만에 들어서 그런지 괜시리 벅찼다. 불안했던 감정에서 벗어나 잠겨있던 물에서 나온 기분이었다.

알고보니 성윤님의 큰 뜻이 있었는데:

불합격을 많이 드리는 것이 내게 불편한 마음이였다. 그래서 나는 최대한 기회를 드리고 싶었다. 불합격이 많은 요즘 시대에 내가 합격을 드려서, 참여자분들의 자존감이 조금이나마 도움이 되면 좋지 않을까? 라는 생각을 했다. 그럼에도 불구하고 기준은 명확히 설정해서 그 기준을 지켰다. 그 기준을 통과하지 못한 분들에게 불합격 메일을 보내는 것은 여전히 내게 힘든 기억이다. 인원이 많아질수록 이 괴로운 경험이 커진다.

정말이지 그릇이 다른 분이다. 그렇게 글또 10기 활동이 시작되었다.

글또 초반 한 달은 무엇을 할지 몰라서 원래 목적인 글쓰기에 집중하려고 했다. 성윤님의 글쓰기 특강도 듣고 글쓰기에 대한 자신감을 가지고 감을 찾는 시간을 보냈었다.

그렇게 작성했던 첫 글인데.. 지금와서보니 정말 성의없다..

원래 jekyll 기반 + vimwiki로 만들었던 블로그에서 medium으로 이주하려고 했는데 한글 폰트가 맘에들지 않아서, 결국 지금 사용하고 있는 astro 블로그로 이주하게 되었다.

사실 템플릿이 좋아서 원작자에게 허락을 맡고 살짝 개조했는데, 나중에 알고보니 글또에서 활동하셨던 분이었다! (10기에는 안 계신거 같다.)

그렇게 글또 초반에는 글쓰기 근육(?)을 만들어 가는 시간을 보냈다. 하지만 이제 소모임에 들어가기 시작하는데..

소모임

글또 활동을 말하면 소모임을 빼놓을 수 없다. 내 글또 활동에 활기를 넣어준 소중한 모임들.

피크민또

요즘 나를 보는 사람들은 피크민에 미친놈처럼 볼 지도 모른다. 왜 시작했을까?

한창 시골에 있을 때 농장 일이 끝나고 부쩍 산책을 가는 시간이 많아졌다. 시골은 뭔가 이상하다. 분명 서울과 같은 시간일텐데 해지는 시간이 빠르다..

항상 일 끝나고 카페가서 책 읽고 작업하다가 지는 해를 보면서 집에 돌아가는 것이 하나의 루틴이 되었는데, 의식적으로 걷기 시작하면서 정신적으로 고양되는 느낌을 많이 받았다.

그렇게 하나의 루틴이 생긴 뒤에 서울에 올라온 뒤에도 산책을 꾸준히 하고 있는데, 피크민이라는 게임이 트위터에서 갑자기 열풍이 불기 시작하면서 호기심에 시작하게 되었다.

사실 처음에는 그렇게 귀여운지 몰랐는데 오히려 대놓고 귀엽지 않아서 보면서 정이 든 느낌이다.

열풍이 불었던 만큼 글또에서도 피크민 소모임도 있었는데 내 피크민또 첫 글을 보면..

빨간 국화가 너무 안 나와서 극대노했었나보다..

그러다 피크민또의 4장인 채정님이 열어주신 오프라인 산책 모임에 참여하게 되었는데 그것이 나의 첫 글또 사람들과의 만남이었다.

날씨는 아직 겨울이 시작되기 전 문턱이어서 산책하기도 좋았었는데, 그렇게 산책을 마치고 피자 피크민을 얻으러 용산에 피자집을 갔던 기억이.. 지금 생각해보면 참 무해하다.

최근에 채은님과 ‘내가 왜 피크민에 이끌렸을까?‘에 대한 이상한(?) 토론을 한 적이 있었는데 결국 내린 결론도 ‘무해함’ 이었다.

정말로 피크민을 하는 사람들 중에 나쁜 사람은 없다! 피크민 덕분에 글또의 첫 인상이 좋아졌고 그 감정은 아직도 여전하다.

첫 피크민 산책에서 만났던 글또분들과 계속 산책이나 다른 소모임에서 인연을 이어가고 있고 이 관계를 오래 유지하고 싶다.

다들 여러모로 내 정신적 건강에 큰 도움이 되주셔서 감사하다.

오늘도한문제풀었또

오늘도한문제풀었또는 알고리즘을 풀어 제출하는 소모임이다.

소모임이 생기고 초창기에는 체계없이 ‘저 이 문제 풀었어요~‘하고 이렇게 인증하는 형식이었는데 몇 가지 문제점이 보여서 4장인 지한님에게 의견을 건의드렸다.

슬랙봇으로 알고리즘 제출을 자동화하여 글또의 깃 저장소에 알아서 커밋 + 푸시하도록 하는 기능을 건의드렸는데, 지한님도 긍정적으로 검토해주셔서 적용할 수 있었다.

다음은 자동화 과정을 적은 글이다.

슬랙봇은 또봇의 아버지인 은찬님의 인프런 강의를 듣고 만들었는데, 꽤나 재밌는 경험이었다.

서비스 제작 초창기에 슬랙봇 관련 질문을 했던 적이 있는데, 은찬님과 나는 얼굴도 본 적 없었지만 감사하게도 DM으로 큰 도움을 주셔서 완성할 수 있었고 문제점 개선까지 해냈다. (나의 파이썬 스승님..)

처음으로 나에게 서비스를 만드는 기쁨을 가져다 준 좋은 경험이었다. 다시 한번 지한님과 은찬님께 감사하다.

독서 모임

피크민또에서 인연이 된 채정님과 종진님의 추천으로 알게된 독서모임에 참여하게 되었는데, 생각보다 인기가 많아서 빨리 마감되었다.

사실 살면서 책을 혼자만 읽었지 독서 모임을 해본 적이 없어서 다소 긴장되었지만, 다들 잘 대해 주셔서 마음이 편했다.

다만 내가 읽고 싶은 책이 너무 많기도 하고, 독서 모임의 책이 재미가 없는 부분이 나올 때는 미뤘다가 몰아 읽게 되었는데 그렇게 되서 독후감만 남기고 발제를 준비하지 못했다.

3회차부터는 미리 읽어서 내 생각을 더 잘 전하고, 기억에 남는 모임이 되도록 흥미있는 발제를 준비하는 것을 목표로 하고 있다.

현재 독서 모임은 2회차 까지 진행되었는데, 글또가 끝나도 독서 모임은 계속된다! 타인의 시간이 투자되는 만큼 의미있는 경험이 되도록 나도 노력해야겠다.

그리고 후술할 쓸모또에서 알게된 유영님이 주선하신 ‘낮술낭독회’에 참여했다.

첫 낭독회는 설날 대체 휴무날이었던거 같은데, 눈이 펑펑와서 기억에 아직도 남는다.

사실 온라인 모각코에서 캠으로만 마주했던 채은님을 제외하고는 모두 구면이었는데, 큰 어색함없이 낭독회를 즐겼다. (아직도 생생한 의성님의 종교 이야기)

최근에 했던 2번째 낭독회에는 다른 재미가 있었다. 낭독회에서 처음 알게된 원규님은 블로그 글부터 심상치 않음을 느꼈는데 거기서 SF 매니아만이 할 수 있는 철학적인 질문과 함께 내 머리에 오랜만에 쥐가 났다.

낭독회로 알게된 것은 이전에는 책읽고 내 생각을 글로 적는 것에 그쳤다면, 내 생각을 타인과 공유하면서 얻는 기쁨을 알 수 있었다. 거기에 소중한 인연까지..!

나에게 소중한 경험을 선사해준 채정님, 유영님 두 분에게 감사하다.

쓸모또

쓸모또는 ‘쓸모 있는 10분 모각글또’인데 글또에서 제일 열심히 활동한 소모임이다. 참여한 이유는 매번 일요일에 버저비터로 글을 제출하는 것이 일상이었기 때문에 그걸 좀 깨보고자 참여했다.

글또를 지원하면서 적었던 목표 중 하나는 ‘타인이 내 글을 읽고 재밌고 잘 읽혔으면’ 이었다.

정현님이 기획해주신 퇴고모임과 쓸모또의 주기적인 글쓰기 시간 확보가 시너지를 일으키면서 글 쓰기에 자극도 받으며 마감에 쫓기지 않는 글을 작성할 수 있었다.

항상 첫 주 OT때 버릇처럼 말하지만 글 제출 시간을 평균 3일을 앞당길 수 있었다..!

그렇게 선정된 첫번째 큐레이션 글이다. 글쓰는 기쁨을 알려주고, 퇴고에 도움주신 모또짱 동민님과 종은님, 예림님에게 감사하다.

또한 쓸모또는 글쓰기뿐만 아니라 인류애를 느낄 수 있는 공간이다.

사실 내가 들어오기 전까지도 쓸모또는 사람이 그렇게 많지 않았다. 정말 작은 소모임 느낌(나작쓸..)이었는데, 느낌상 1월부터 사람이 부쩍 늘어났다.

어느 모임이건 사람이 많아지면 누군가는 소외감을 느낄수 있는데, 동민님과 소진님이 그런 분위기가 되지 않도록 정말 애쓰셨다.

여기서 느낀 것은 커뮤니티라는 것은 결국 좋은 사람이 모이면 좋은 커뮤니티가 된다는 것이다.

여러모로 나를 가장 많이 바꾼 소모임으로, 내 정신적인 회복에 가장 도움되었고 나도 받은만큼 타인에게 긍정적인 영향을 주고 싶다는 생각이 들게 만든 소모임이다.

쓸모또의 마무리를 다음주 일요일에 오프라인 행사와 함께 대미를 장식할 것인데 다들 재밌게 즐겨주셨으면 좋겠다.

삶의 지또

주원님이 주도하신 소모임으로 글또 지원 시 썼던 삶의 지도를 다시쓰는 소모임이다.

사실 처음 삶의 지도를 제출할 때 너무 필터링을 많이 거쳐서 진정성이 없다고 생각했었는데 기회가 되서 다시 적어보기로 했다.

나를 꾸밈없이 적어보려고 했는데 글 재주가 없다보니 그 때의 감정이 뒤죽박죽 섞이고, 액션 아이템을 적었을 때는 뭔가 글쓰는 기력이 다해서 용두사미가 된 듯 하다.

다른 분들의 삶의 지도도 보게 되었는데, 나는 정말 정적인 삶을 살았구나를 느낀다. 다들 순탄하지 않고 한 기로에 서서 많은 고민을 했다는 것이 텍스트를 통해 피부로 전해졌다.

단체 커피챗은 뭔가 부담스러워서 삶의지도 완성 전에 개인적으로 피크민또에서 처음 만난 의성님과 커피챗을 가졌는데, 여러모로 통하는 것도 많고 아직 신입임에도 배울 것이 정말 많은 개발자분이어서 자극받았다.

게다가 개발자로서 지향하는 부분이 나와 대부분 같아서 더욱 이끌렸다. 앞으로의 행보가 기대되는 개발자 중 한 분이다.

좋은 사람과 인연이 생기는 것은 항상 즐겁다. 이를 유지하는 것은 이제 내 손에 달렸다.

나를 다시 되돌아보는 시간을 갖는 소모임을 만들어주신 주원님에게 감사하다. (이렇게 계속 쓰고보니 뭔가 감사회고 같기도..)

아쉬웠던 점

아쉬운 점이 있긴한데, 글또 활동때문에 생긴 아쉬운 점은 아니다.

할건 하면서 후회없는 글또 생활을 하긴 했는데, 서비스가 돌아가게 만들기도 전에 쓸데없이 서비스의 디테일한 부분에 대한 고민이 많아져서 거기에 쏟은 시간이 좀 많았다.

문해력 검사 사이트를 만들면서 테스트 코드 작성에 갑자기 꽂혀 그 쪽으로 깊게 파고 들어가질 않나, 프로젝트를 하면서 개인적으로 스프린트를 해봤는데 익숙치 않아 시간을 효율적으로 쓰지 못한 점..

중간에 프로젝트에 대한 흥미가 떨어지면 다른 기술을 학습하거나(최근엔 MCP..), 병렬로 다른 프로젝트(mac os 전용 뽀모도로..)를 만지다보니 하나의 큰 아웃풋을 만들어내기 힘들었다.

여기서 내린 진단과 액션은 다음과 같다.

  • 혼자서 개발 과정을 결정 -> 팀을 짜서 진행한다.
  • 고민하는 시간이 무한하다. -> 시간을 정해놓고 완성하는 강제성이 필요하다.

그에 대한 해결책은 팀 프로젝트에 참여하기이다.

최근에 chingu라는 사이드 프로젝트 매칭 서비스를 발견했는데, 외국인 개발자들과 작업해보고 싶다는 생각이 들기도 했고 특별한 경험이 될 것 같아서 5월 5일에 시작하는 이 프로젝트를 시작해 볼 예정이다.

외국인들과의 소통은 어떤 점이 힘들까 궁금하기도 하고, 협업에서 어떤 점이 힘든지 알아내는 것을 목표로 하고 있다.

추가적인 액션은 이 짧은 회고 시간에 구체적으로 적기는 힘들 것 같고, 현재 문제점을 진단하면서 추후 구체화하도록 해보자.

맺음

이건 아쉬운 점에 적는게 맞는 것 같은데 ‘이런 커뮤니티를 너무 늦게 알았다’는 점이 아쉽다. 커뮤니티 활동이 나를 이렇게 크게 바꿔 놓을 줄 누가 알았을까.

글또의 키워드를 하나만 꼽는다고 한다면 ‘따뜻함’이다. 이런 커뮤니티 문화를 만들기 위해 성윤님과 운영진들의 노고 덕에 단순 글쓰기 커뮤니티를 넘어 서로 성장하고 따뜻함을 주고받는 공간으로 자리잡았다고 생각한다.

시간은 유한하다. 우리에게 남은 계절은 100번도 남지 않았기에, 인간관계도 항상 나를 스쳐지가지만 사랑할 수 밖에 없는 계절같은 존재라고 생각하며 항상 타인에게 따뜻하도록 하자.

나는 글또가 끝나도 2주마다 글을 쓰는 관성을 유지하려고 한다. 더 이상 강제성은 없지만 여태까지 패스도 안 써왔으니 아깝기도 하고 나는 충분히 할 수 있음을 증명하고 싶다.

잘가 글또. 어쩌면 새로운 시작이 될 수도 있으니 안녕?

article |

Git 이전의 버전 관리 시스템은 어땠을까?

개요

형상관리는 영어 약자로 SCM(Software Configuration Management)이라 하며, 소프트웨어 혹은 소스코드의 변경 사항을 체계적으로 관리하기 위한 개념입니다.

이 형상관리의 하위 개념으로 버전 관리 시스템(VCS, Version Controll System), 소스코드관리(Source Code Management) 등 여러가지 개념이 존재하지만 통상적으로 동일한 개념을 의미합니다.

이번 글에서는 형상 관리라는 단어 대신 ‘버전 관리’라는 단어로 통일해서 설명할 것입니다.

이 버전 관리의 전반적인 목표는 동일한 문서의 여러 버전을 저장하고 관리하는 것인데요:

작업을 하다보면 버그가 발생해서 복구를 해야할 때도 있고, 프로젝트의 과거 어떤 시점으로 돌아가야 할 필요가 있습니다.

하지만 위 그림처럼 파일을 관리하면 시간 순서에 따라 구성된 파일 버전의 기록을 제공한다는 점에서 잘 작동할테지만, 파일이 버전마다 어떻게 변경되었는지, 특정 버전을 저장한 이유 또는 다양한 버전이 어떻게 관련되어 있는지에 대한 정보를 제공하지 않습니다.

또한 사용자가 파일 버전의 이름을 지정할 때 실수를 하거나 돌아가서 순서가 아닌 파일을 편집하는 작업이 발생하겠죠.

이런 문제점을 해결 해주는 것이 바로 버전 관리 시스템(Version Control System, VCS) 입니다. 개발자들이 사용하는 Git이 바로 버전 관리 시스템의 종류 중 하나입니다.

버전 관리 시스템 덕분에 개발자들이 완전히 다른 위치에서 작업하더라도 프로젝트의 일관되고 최신 기록에 액세스할 수 있도록 보존할 수 있는 것이죠.

이 글에서는 Git 등장 이전에 어떤 불편함 때문에 버전 관리 시스템이 탄생하였고, 어느 부분이 개선되어 왔는지 시간 순으로 나열하면서 ‘Git은 어떻게 주류가 되었는지’에 대해 설명합니다.

예상 독자는 다음과 같습니다.

  • 소프트웨어 개발 역사에 관심이 있으신 분
  • 버전 관리 시스템의 발전 과정이 궁금하신 분

세대로 살펴보는 버전 관리 시스템

버전 관리 시스템의 선구자

IBM사의 운영체제인 OS/360(IBM System/360 Operating System)IEBUPDTE는 버전 관리 시스템의 선구자 격이 되는 프로그램입니다.

1960년대의 컴퓨터는 펀치 카드(천공 카드)를 사용해 데이터를 저장했는데요, IEBUPDTE는 DASD(Direct Access Storage Device)로 소스 라이브러리를 배포하는데 사용되었습니다.

예시는 IBM 메인프레임 운영 체제에서 배치 작업을 실행하는 스크립팅 언어인 JCL(Job Control Language)입니다.

//UPDATEPGM JOB (ACCT),'PROGRAMMER',MSGLEVEL=(1,1)
//STEP1    EXEC PGM=IEBUPDTE,PARM=MOD
//SYSPRINT DD SYSOUT=A
//SYSUT1   DD DSN=USER.SOURCE.LIB,DISP=OLD
//SYSUT2   DD DSN=USER.SOURCE.LIB,DISP=OLD
//SYSIN    DD *
./ ADD NAME=MYPROG,LIST=ALL,SOURCE=0,LEVEL=01
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. MYPROG.
000300 ENVIRONMENT DIVISION.
000400 DATA DIVISION.
000500 PROCEDURE DIVISION.
000600     DISPLAY "HELLO, WORLD!".
000700     STOP RUN.
./ NUMBER NEW1=000800,INCR=100
000800     DISPLAY "VERSION 2 CHANGES".
./ ENDUP
/*

./ ADD NAME=MYPROG,LIST=ALL,SOURCE=0,LEVEL=01:

이 라인은 ‘MYPROG’라는 이름의 새 멤버를 추가하거나 기존 멤버를 업데이트하며, LEVEL=01은 이 멤버의 버전 번호를 나타냅니다.

000100 ~ 000700:

이는 프로그램의 원본 코드입니다. 각 라인의 앞 6자리는 시퀀스 번호로, 코드의 순서를 관리합니다.

./ NUMBER NEW1=000800,INCR=100:

이 라인은 새로운 코드 라인의 시퀀스 번호를 설정합니다. NEW1=000800은 새 라인의 시작 번호를, INCR=100은 증가 간격을 나타냅니다.

000800 DISPLAY "VERSION 2 CHANGES".:

이는 새로 추가된 코드 라인으로, 버전 2의 변경사항을 나타냅니다.

./ ENDUP:

마지막으로 업데이트 작업의 끝을 나타냅니다.

이 시스템에서 확인할 수 있는 것은 다음과 같은데요:

  • 멤버 이름과 레벨 번호로 각 버전을 식별
  • 시퀀스 번호를 사용하여 코드의 각 라인을 추적
  • 새로운 코드를 추가할 때 ./ NUMBER 명령어로 시퀀스 번호를 관리
  • 전체 코드를 다시 작성하지 않고 변경사항만 추가

현대의 버전 관리 시스템에 비교했을 때 제한적이지만, 당시로써는 코드의 변경점을 추적하고 관리하는 효과적인 방법이었습니다.

IEBUPDTE는 현대 버전 관리 시스템의 직접적인 전신은 아니지만, 버전 관리의 개념을 소프트웨어 개발 과정에 도입했다고 알려진 첫 시스템입니다.

1세대

1세대의 버전 관리 시스템의 특징은 로컬 버전 제어 소프트웨어라는 것 입니다.

개별 파일의 변경 사항을 추적하도록 의도되었으며, 체크아웃된 파일은 한 번에 한 사용자만 로컬에서 편집할 수 있었습니다.

또한 모든 사용자가 자신의 계정으로 동일한 공유 UNIX 호스트에 로그인한다는 가정 하에 구축되었죠.

SCCS(Source Code Control System)

1970년대 초에는 VT100(사진의 컴퓨터)과 같은 비디오 단말기와 UNIX 운영체제 및 DEC(Digital Equipment Corporation)사의 TSS/8과 같이 컴퓨터를 대화식으로 사용하려는 시도에서 탄생한 ‘시분할 운영 체제’가 저렴해지고 널리 보급되기 시작했습니다.

1972년은 데니스 리치가 만든 C언어가 탄생한 해이기도 한데요, SCCS는 C언어로 작성되었습니다.

이런 시대적 배경과 필요성에 의해 1972년에 벨 연구소의 마크 로시킨드(Marc J. Rochkind)는 IBM의 운영체제인 OS/370에서 소스 파일 개정 추적 문제를 해결하기 위해 SCCS를 설계했습니다.

여기서 델타(delta) 라는 개념이 사용됩니다. 수학에서는 ‘변화량’을 의미하는 단어지만, 버전 관리 시스템(VCS)에서는 두 버전 간의 (변화로 인한) 차이점을 의미합니다.

파일이나 코드의 특정 시점에서 발생한 변경 사항을 나타내며, 주로 텍스트 파일의 추가, 삭제, 수정 등의 내용을 포함합니다.

예시로 살펴보겠습니다.

foo
bar

먼저 sccs create <filename.ext> 명령어로 SCCS에 새 파일을 체크인하고 해당 파일에 대한 새 히스토리 파일을 만들고 foo와 bar라는 단어를 저장합니다. 이제 다음과 같이 파일을 수정합니다.

bar
baz

이걸 GIT의 diff로 변경 내역을 확인한다면 다음과 같은 형식일텐데요:

--- a/test
+++ b/test
@@ -1,2 +1,2 @@
-foo
 bar
+baz

반면 SCCS는 다음과 같은 방법을 사용합니다.

^AI 1
^AD 2
foo
^AE 2
bar
^AI 2
baz
^AE 2
^AE 1

첫 줄의 ^AI 1^AD 2는 “버전 1에서 이 줄이 삽입되었고, 버전 2에서 삭제되었다”는 것이고, 그 다음 줄의 내용은 foo라는 것을 나타냅니다.

이러한 방식을 인터리브 델타(Interleaved Deltas) 또는 위브(weave) 라고 부릅니다.

‘weave’의 사전적 의미는 옷감이나 직물같은 것을 ‘엮다’라는 의미인데요, SCCS는 원본 텍스트 파일 안에 변경된 줄과 그 정보를 함께 엮어서 저장합니다.

이렇게 개발자들은 이전 버전의 원본 소스 코드와 저장된 변경 사항을 검색할 수 있게 되었는데 여기서 몇 가지 한계점이 있습니다.

로컬 전용 시스템(local-only)

먼저 사용자 간에 변경 사항(위에서 설명한 델타)를 교환하는 방법을 제공하지 않았습니다.

당시에는 시분할 컴퓨터 시대였기 때문에 이런 기능이 필요하지 않았습니다. 그래서 중앙 컴퓨터에 계정을 가지고 독립적으로 작업하거나 동료들과 작업 폴더를 공유하는 방식을 작업했습니다.

단일 파일 추적(single-file only)

또한 시스템 상의 한계로 ‘한 번에 하나의 파일’만 변경 사항을 추적할 수 있었습니다.

요즘처럼 여러 파일을 포함하는 ‘저장소’의 개념이나 여러 파일에 걸친 ‘원자적 커밋(atomic commits)‘이라는 개념은 아직 존재하지 않았습니다.

잠금 메커니즘(locking)

SCCS는 단일 작성자의 접근을 보장하기 위해 잠금 방식을 사용했습니다.

SCCS 시스템 제어 하의 파일은 사용자가 편집을 위해 가져오기 전까지는 디스크에서 읽기 전용(read-only)이였습니다.

여기서 다른 사용자가 파일을 체크아웃(해당 파일을 가져옴과 동시에 변경 권한을 갖게되는 것)한 상태라면 SCCS는 작업을 중단했죠.

오늘날 SCCS를 사용하는 사람은 거의 없지만 델타 저장, 커밋에 대한 주석 추가 및 체크아웃 중 버전 ID 확장과 같은 아이디어는 여러 버전 관리 시스템에서 이어졌습니다.

RCS(Revision Control System)

SCCS가 만들어진 이후 첫 9년 동안은 유일한 버전 관리 시스템이었지만, 1982년 퍼듀 대학의 월터 티치(Walter F. Tichy)가 당시 오픈 소스가 아니었던 SCCS에 대한 대안으로 RCS를 개발했습니다.

SCCS와 비교해서 RCS의 가장 큰 변화는 역 델타(Reversed, Separated Deltas)를 채택한 것입니다.

역 델타 방식의 의의는 변경 내역을 순차적으로 추적하는 것입니다.

먼저 파일이 체크인(버전관리 시스템에 해당 파일을 반영함과 동시에 변경권한을 잃는 것)되면 파일 내용의 전체 스냅샷이 히스토리 파일에 저장됩니다. 파일이 수정되어 다시 체크인되면 기존 히스토리 파일 내용을 기반으로 델타가 계산됩니다.

여기서 이전 스냅샷은 삭제되고 새 스냅샷과 델타가 저장되어 이전 상태로 돌아갑니다. 이는 역 델타 이전의 리비전(수정 사항)을 체크아웃하기 위해 RCS가 파일의 최신 버전에서 시작하여 이전 리비전에 도달할 때까지 연속 델타를 적용하기 때문에 호출되는 것입니다.

이 방법을 사용하면 현재 리비전의 전체 스냅샷을 항상 사용할 수 있으므로 현재 리비전을 매우 빠르게 체크아웃할 수 있게되죠.

그러나 체크아웃 리비전이 오래될수록 현재 스냅샷에 대해 계산해야 하는 델타 수가 늘어나기 때문에 체크아웃에 걸리는 시간이 길어지게 되는 맹점이 있습니다.

SCCS와 비교하여 RCS는 과거 버전은 델타(diff)만 저장하므로, 파일 크기가 작아지고 저장 공간이 절약할 수 있고, 역 델타 방식을 사용하기 때문에 최신 버전 파일의 조회 속도가 훨씬 빨라졌습니다.

하지만 사용자가 버전 기록을 편집할 수 있다는 점에서 보안성이 거의 없으며, 여전히 한 번에 한 명의 사용자만 작업할 수 있었습니다.

2세대

2세대 버전 관리 시스템의 특징은 중앙 집중형 버전 제어 도구 라는 것입니다.

저장소가 로컬에 있지 않고 원격에 존재하기 때문에 여러 사람이 원격 서버에 소스를 저장하거나 사용할 수 있게 된 것이죠.

모든 소스들이 하나의 서버에서 통합되기 때문에 버전 관리 업무도 쉽게 처리할 수 있으며, 개발자 간 소스 파일 공유도 편리해졌습니다.

CVS(Concurrent Versions System)

1986년에 딕 그뤼너(Dick Grune)가 RCS를 기반으로 한 CVS(Concurrent Versions Systems)를 개발했습니다.

CVS가 가지는 의의는 버전 관리 시스템 역사상 처음으로 여러 개발자가 동시에 같은 파일을 체크아웃하고 작업할 수 있도록 허용했다는 것입니다.

뿐만 아니라 파일 단위의 버전 관리를 제공하는 RCS와 달리 프로젝트 단위의 버전 관리를 제공했죠.

CVS의 등장으로 두 명 이상의 개발자가 파일 작업을 수행할 수 있게 되었고 사용자는 updateversion 명령으로 서버의 해당 파일의 최신 버전으로 파일을 업데이트할 수 있게 되었습니다.

또한 파일 잠금(locking) 개념을 가지고 있던 RCS와는 달리 CVS는 충돌을 해결하기 위해 병합(merge) 모델을 기본적으로 사용했으며, 브랜치 및 심볼릭 태그를 도입 한 최초의 버전 관리 시스템입니다.

이렇게 다중 사용자 환경을 제공하고 프로젝트 단위의 버전 관리를 제공하는 CVS에도 여전히 한계가 있습니다.

불안정한 동시성 제어와 원격 저장소의 느린 속도와 같은 문제가 있어 추후 설명할 SVN으로 대체됩니다.

SVN(Subversion)

SVN은 CVS의 한계를 극복하고자 2000년에 Collabnet Inc 사에서 만들어졌으며(현재는 Apache 재단에서 관리), CVS에 포함된 많은 기능을 보존하면서 사용자가 두 버전 관리 시스템 사이를 전환할 수 있도록 했습니다.

로컬 전용, 파일 잠금 등 많은 문제를 개선해왔지만 여전히 원자적인 커밋은 지원하는 시스템은 없었습니다.

드디어 SVN에서 문제가 발생할 경우 커밋이 완전히 성공하거나 완전히 중단되도록 보장하는 원자적 커밋 기능이 도입되었습니다.

클라이언트에서 커밋이 발생하면, 사용자가 변경된 파일이나 추가 혹은 삭제된 파일이 서버 레포지토리에 반영됩니다.

이때 커밋 시 원자성 트랜잭션을 가지는데 말그대로 체인징셋(changing-set, 위에서 변경된 파일들) 전체가 커밋되거나 하나라도 실패시 롤백이 됩니다.

이렇게 많은 문제점을 개선해왔지만 중앙 집정식 버전 관리는 저장소가 로컬에 있지 않고 원격에 존재하기 때문에 여러 사람이 원격 서버에 소스를 저장하거나 사용할 수 있지만 치명적인 단점이 있습니다.

먼저 서버에 문제 발생 시 복구 전까지 버전 관리 시스템을 사용할 수 없는 것이고, 서버에 모든 소스가 저장되어 있기 때문에 서버의 데이터가 손실될 경우 100% 복구하기 어려울 수도 있다는 점입니다.

위에서 제기한 문제점을 하나씩 제거하면서 개선되어 왔음에도 불구하고 여전히 중앙 서버가 존재해야 한다는 한계가 존재했습니다.

3세대

3세대를 나누는 특징은 분산 버전 제어 시스템(DCVS, Distributed Version Controll System) 입니다.

위에서 살펴본 중앙 집중형 버전 관리가 가진 단점의 원인은 각 클라이언트가 원격 서버의 모든 정보를 가지고 있지 않고 가장 최신 버전의 스냅샷만을 가지고 있었기 때문입니다.

분산 버전 제어 시스템은 서버에서 소스코드를 clone할 때 최신 버전의 코드만 가져오지 않고, 원격 서버의 저장소에 기록되어 있는 모든 정보를 가져오는 방식으로 중앙 집중형 버전 관리의 문제점을 해결했습니다.

이렇게 되면 서버의 데이터도 로컬에 존재하기 때문에 불필요한 서버 접근을 최소화하여 속도도 빠를 뿐더러, 소스 코드를 서버에 pull 혹은 push 할 때를 제외하고는 네트워크에 접속한 상태가 아니더라도 대부분의 작업을 로컬에서 수행하고 최종 작업 결과만 서버에 push하면 됩니다. (현재 사용하는 GIT 처럼 말이죠!)

Git

리누스 토발즈가 만든 Git은 버전 관리 시스템의 메인 스트림이 되었습니다.

Git은 분산형 버전 관리 시스템(DVCS, Distributed Version Controll System)으로 중앙에 위치한 원격 저장소로컬 저장소 두 영역에서 모든 버전 관리 작업을 수행할 수 있어 SVN과 달리 네트워크 연결 없이도 모든 관리 작업을 수행할 수 있게 되었습니다.

또한 히스토리 관리에 있어서도 SVN은 한번 커밋을 하게되면 이를 수정하기가 매우 어려운 반면, Git은 상황에 따라 다르지만 커밋을 되돌리거나 하는 방법으로 자유롭게 수정, 변경할 수 있습니다.

Git은 위에서 언급했던 로컬 환경 문제, 원자성 보장, 잠금 메커니즘, 병합 문제를 문제점을 해결하고 더불어 속도와 무결성 검사 등등 여러 요소를 개선하면서 현대 소프트웨어의 개발 표준으로 자리잡게 되었습니다.

맺음

달에 하나 origin series를 작성하기로 했는데 이번 달에도 성공적으로 마쳤네요.

역사를 좋아하다보니 이렇게 타임 라인을 따라 거슬러 올라가면 기술의 흥미도가 더 올라가는 것 같습니다. 과거의 개발자들은 어떻게 저런 생각을 했을지 경외감도 들기도 하고..

현재 Git은 버전 관리 시스템의 왕으로 군림하고 있지만 갑자기 새로운 패러다임을 가진 시스템이 나올 수 있지 않을까요? (물론 그러기엔 Github의 존재가 너무 크기는 한데..)

개인적으로 Git은 학습 곡선이 굉장히 높기 때문에 좀 더 유저 친화적인 기술이 있으면 어떨까 생각을 항상 하긴 합니다..

그렇게 되려면 Git을 대체할 핵심 개념이 필요할 것 같은데 그게 무엇인지는 모르겠지만, 세계 어느 미지의 연구실에서 갑자기 Git을 뒤집을 만한 시스템을 완성하고 있다면..? (망상)

읽어주셔서 감사하고 피드백이나 잘못된 내용이 있다면 달게 받겠습니다.

출처