현실적인 신입 개발자의 회사 깃 도입기

배경

이전 회사에서 신입으로서 VCS(Version Control System)를 사용하지 않아 많은 어려움이 있었어요. 부트캠프에서 처음 깃/깃헙을 배웠을 땐 개발 프로세스 중에 당연한 거라고 여겨져서 깃이 없을 때는 어떤 상황을 맞닥뜨릴지 전혀 몰랐습니다. 역시 버전 관리가 되지 않으면 여러 단점이 있었어요.

개발을 완료하고 이전 코드와 비교가 불가능한 점은 내 코드가 어떤 식으로 변경됐는지 한눈에 들어오지 않기 때문에 코드에 대한 자신감이 사라집니다. 변경사항을 볼 수 없기 때문에 동료로부터 아무 피드백도 받지 못합니다. 피드백받는 순간은 그 코드로 인하여 서비스가 비정상적으로 돌아갈 경우일 뿐입니다. 아니면 코드 누가 짰냐고 소리쳤을 경우에만 확인이 가능한 것이었어요.

변경 사항을 볼 수 없기 때문에 코드의 히스토리를 알 수가 없습니다. 쌓인 히스토리는 코드를 수정할 때 왜 코드가 변경이 되었는지 분석할 때 참고가 많이 될 건데 말이죠. VCS가 없다는 것은 동굴 속에서 호롱불 하나 들고 벽을 더듬거리며 출구를 찾는 것과 비슷했습니다. 팀으로써 바라보아도 전체적으로 이런 저런 이유들로 생산성 저하를 가져다주었던 것 같아요. 혹여나 혼자 개발하더라도 먼 훗날의 나와의 협업을 위해 VCS는 필수라고 생각합니다.

 

깃 도입을 위한 개발 프로세스 변경

이전 회사는 조그마한 서비스가 여러개 있었습니다. 그 서비스들은 개발용 서버가 있는 서비스도 있고 없는 서비스도 있었어요. 하지만 개발 서버에서 운영 서버로 배포할 때도 그 프로세스가 맞는 거 같진 않습니다. 코드를 수정하고, 수동으로 수정한 파일을 가져와서 상용 서버에 드래그 앤 드롭식으로 혹은, 개발이 완료된 코드들을 모두 카피해서 운영 서버를 열어서 붙여넣기를 한다던가 하기 때문이었습니다.

파일 하나를 수정하는 것은 괜찮았습니다. 그런데 MVC 패턴으로 된 코드들은요? M, V, C 각각 3개를 들고 와서 수동으로 해주어야했어요. 아, 당시에 PHP 와 CodeIgniter 라는 프레임워크를 사용했었습니다. 그것뿐이면 다행인데, 보통 간단한 것을 개발하더라도 여러 디렉토리를 건드려야 하기 때문에 순식간에 복잡해지고 작업 중에 다른 일을 하게 되면 어디까지 수정했는지 잊어버리는 일도 매우 자주 발생했어요. 개선이 절대적으로 필요했습니다. (근데 당시 동료분 말씀에 의하면 이렇게 작업하는 회사가 많다고 합니다?)

회사에 개발자란 저포함하여 신입 개발자만 둘이라 어떤 식으로 도입할지 결정하는 것도 둘이서 머리를 맞대어 열심히 생각했습니다. 운영서버, 개발서버, 로컬로 나누어서 개발을 하고 버전 관리를 하도록 생각을 했습니다. 로컬에서 개발하면서 형상 관리를 하고 상용서버와 똑같은 환경인 개발서버에서 최종적으로 테스트까지 하고 상용서버로 배포하기로 했어요. 

 

개인적으로는 이 과정에서 로컬의 존재가 있어야 할 이유를 찾지 못해서 이야기를 더 하고 싶었지만 동료 개발자님의 강력한 주장으로 그렇게 하기로 했었던 기억이 나네요. 로컬 개발 환경이 필요없다고 생각한 이유는 인원도 둘 뿐이고 PHP 로 구성된 웹사이트였어서 테스트하기가 정말 간편했거든요. 그리고 운영 서버와 똑같은 환경이라서요. 어쨌든 그리하여 윈도우에 개발환경을 만들기 시작했습니다.

윈도우에 개발환경 셋팅

우분투에서 돌아가던 서버 코드를 가져와 윈도우에 개발환경을 구축하는 것은 초보 개발자인 저에겐 너무 힘들었습니다. 당시 회사 PHP 버전이 5.3.29인데 이 레거시 환경을 윈도우에 구축하기가 꽤 어렵더라고요. 해당 버전을 검색해봐도 잘 나오지 않았고 찾았긴 했던 것 같은데 설치하는 과정에서 많이 막혔던거 같았습니다. 그리고 운영서버와 최대한 같은 환경을 구축해야한다는 생각이 있었는데 VM이나 도커에 대한 개념도 잘 몰랐기 때문에 어떻게 해야할지 참 난감했어요.

그래서 도커를 조금씩 배우기 시작했어요. 도커를 배우면서 가장 크게 느낀 것은 환경 구축의 편리함이었습니다. 그냥 도커허브에서 구축된 이미지만 다운받아 사용하면 됐기 때문입니다. 마침 도커허브에 우분투에 PHP 5.3.29 를 설치한 이미지가 있었거든요. 그런데 구축의 편리함이라는 이유 외에는 사용할 다른 이유가 아무것도 없었기 때문에 단지 관리해야 할 기술을 하나 더 늘리는 것은 아니라고 생각했고, 개발 프로세스가 불필요히게 두꺼워지기만 했다고 생각했습니다. 결국엔 도커는 사용하지 않기로 했지요.

어쨌든 조금 구축에 어려움을 느꼈지만 윈도우에 개발 환경을 구축하는 건 성공하긴 했습니다. 이제 외부 협력사들의 API를 호출하는 테스트를 해야 하는데 보안상 따로 개발 서버의 IP를 알려줘야 했습니다. 그 개발 서버는 결국에 localhost를 가리키기 때문에 회사의 IP를 알려줘야 했습니다. 회사 IP만 알려주면 되는 게 아니고 응답을 받기 위한 회사 네트워크망에 연결되어있는 컴퓨터에 포트포워딩하는 작업도 따로 해줘야 한다는 번거로움이 있었던 것 같아요. 결국 클라우드에 올라가 있던 개발 서버에서만 테스트할 수 있었습니다.

계획 변경

개발 서버에서만 테스트할 수 있다고 생각했기 때문에 당시 동료분도 로컬 환경 구축이 굳이 필요하지 않다고 생각을 바꾸게 됐었습니다. 계획을 틀어서 다시 작업하기로 했습니다. 다시 회의를 하면서 어떤 식으로 깃/깃헙을 도입할지 고민했습니다. 원래 하던 거처럼 서버 하나에 sftp로 접속해서 코드를 수정해서 업로드하는 방식으로 하기로 했습니다. 그런데 이렇게 되면 형상 관리를 어떻게 해야할지 고민이더라고요. 기존 방식대로 sftp로 업로드하는 형식으로 진행하면 서버 하나에서 동시에 작업하기 때문에 버전 관리가 안됩니다.

그러다 VSCode에서는 익스텐션 중에 "sftp"라는 익스텐션에서 환경설정으로 로컬에 코드를 가지고와 동기화하면서 로컬에서 버전 관리하는 방법을 찾았습니다. 하지만 개인적으로 VSCode로 sftp 작업하는 것은 매우 불편했었어요. 다른 서버와 매끄러운 전환이 불가능할뿐더러 Shift + Cmd + P 를 계속 누르면서 가독성이 떨어지게 나열되어있는 파일목록에서 원하는 걸 가져와야 했거든요. JetBrains의 PhpStorm으로 넘어온 이유도 그런 것이고 통합적으로 제공해주는 것들이 Intellij로 코딩을 시작해서 그런지 훨씬 제 워크플로우에 익숙했습니다.

sftp를 통한 개발 작업, 로컬과 동기화

 

PhpStorm에서도 그런 식으로 제공해주는 기능이 분명히 있을 것이라 생각하고 찾아보니 스택오버플로우에서는 Unfortunately,,로 시작하는 답변만 보였습니다. 안된다는 말이죠.

그러다 rsync를 이용해서 하는 방법을 소개해주는 글을 봤습니다. rsync를 이용하면 확실히 될 것 같아 원격 서버와 로컬과 연동해보려고 시도해보았습니다. 실패했습니다. 설정을 잘못했거나 제가 실수한 부분이 분명히 있었을 겁니다. 근데 실습을 하면서 정말 이런 식으로 해야 하나? 스스로 의구심이 많이 들었습니다. 그땐 그냥..느낌상요.

고민하다가 다시 여러 가지 키워드를 바꿔가며 찾아보니, 바로 파일을 불러와 수정 후에 업로드하는 형식이 아니라, 원격 서버의 디렉토리와 로컬 디렉토리와 매핑해서 간단하게 할 수 있는 방법이 이미 존재했습니다. 그리하여 해당 방법으로 깃/깃헙을 도입하는 구조는 최종적으로 아래와 같게 되었어요.

 

깃 도입 도식화

회사 네트워크에서 개별 로컬호스트로 포트포워딩을 해줘야 하는 것도 신경 써주지 않아도 되고, 이미 외부 협력사 서버에 개발서버의 IP가 등록되어있기 때문에 더 이상 신경 안 쓰고 개발만 하면 되도록 변경됐습니다.

추가적으로, PHP는 서버를 종료하지 않고 코드를 수정하는 순간 바로 서버에 적용이 되기 때문에 자바처럼 따로 빌드를 하지 않아도 됩니다. 그래서 이렇게 간단한 구조가 나왔는데요. 아마 자바였다면 상용서버와 깃헙 사이에 추가적인 작업이 필요했을것 같아요.

마무리

사실 깃 도입하는 것과는 무관한 이야기이지만 회사 사람과의 소통이 정말 중요하다고 느꼈습니다. 자기가 타당하고 논리적으로 이게 맞다고 생각해도 다른 사람과 협의를 거쳐야 합니다. 내가 틀리다 생각하는 결정을 내려도 전체적으로 볼때 가장 합리적인 결정일 수 있다고 생각했어요.

혼자 일을 하는 것이 아니기 때문에 적절한 커뮤니케이션과 협업이 가장 중요하다고 느꼈습니다. 특히 바로 제 옆에 있는 동료 개발자와 대화를 끊임없이 해야 한다고 느꼈습니다. 서로 다르기 때문에 한 문장을 말해도 의미가 완전히 다르게 전달될 여지가 충분히 있다고 생각해요. 계속 말하고 듣고 반복하며 상대방의 의중을 알아차려야 한다고 생각했습니다.

여기까지 결국에 따지고 보면, 깃 도입은 복잡스러운 것 없이 아주 간단한 구조였습니다. 하지만 여기까지 오는 데에 그 과정은 절대 간단하지 않았습니다. 혼자하는 프로젝트가 아니기 때문이었어요.

어쨌든 깃 도입으로 인해 우리는 버전 관리의 편리성과 변경 이력 추적의 장점을 경험할 수 있었습니다. 이전에는 코드 수정 후의 변화를 파악하기 어렵고, 동료로부터 피드백을 받을 기회가 제한되었던 상황이었습니다. 하지만 이제는 깃을 통해 변경사항을 쉽게 확인하고, 손쉽게 협업하며 피드백을 주고받을 수 있게 되었습니다.

매 순간 버전 관리가 되지 않아 다가왔던 압박감들이나 스트레스가 한순간에 다 날아갔던 기억이 떠오릅니다. VCS 하나가 이렇게 행복한지 몰랐어요.