Search

반응형

'Software'에 해당되는 글 193건

  1. 2024.02.25 프로젝트 팀원의 단점만 보이는가?
  2. 2024.01.14 [Git]Git Bash 간단 명령어 정리. (init, config, status, add, commit)
반응형

최근 프로젝트를 몇 번 실패하고 퇴사한 직원이 있었다.

입사한 지 갓 1년을 넘은 경력직으로 이전에 대기업 전산직으로 근무했던 사람이었다.

나도 같이 프로젝트를 한 번 같이 했다.

내가 리더였고 그 직원은 팀원이었다.

처음 분위기는 좋았지만 한 달 정도 지나면서 다른 프로젝트에서 실패하고 리젝(reject)된 이유가 슬슬 보이기 시작했다.

내 장점 중 하나라고 한다면 프로젝트를 하면서 만나는 팀원들의 장단점을 빨리 알아차린다는 것이다. 물론 나 또한 장단점이 명확하다. 특히 야근과 주말근무를 엄청 싫어하기에 윗 분들은 별로 좋아하지 않는 타입니다. 

위에선 큰 기대를 하고 경력직으로 뽑은 이 직원은 입사 후 첫 프로젝트에서 리더로 들어갔지만 두어 달? 정도 있다가 리젝 되었다. 물론 보통 사람들은 자신의 잘못을 쉽게 인정하지 않는다. 나도 그렇기에..

작은 프로젝트 리더를 맡고 그 직원이 같이 참여하게 되었다. 리젝된 후 두 번째 프로젝트인 것이다. 리더가 나였기에 팀원으로 들어왔다. 왜 리젝 되었는지 이야기를 들어보니 본인의 잘못은 없었다. 그저 고객사의 문제를 강조했다. 그 고객사는 최근 나도 프로젝트를 진행했기에 어떤 상황인지 금방 이해하게 되었다.

작은 프로젝트는 시작되었다. 역시 말도 안되는 개발팀을 구성해 주었고 정말 답답한 마음이 앞섰다. 하지만 크고 작은 모든 프로젝트가 거의 완벽에 가까운 팀을 구성하긴 힘들다.

요구사항을 정리하고 기획을 시작하면서 단점이 드러나기 시작했다. 사실 이 직원뿐만 아니라 비슷한 또래의 임직원들의 고질병 같은 상황이 나타나기 시작한 것이다. 최근 시작하는 프로젝트에도 비슷한 나이대의 임원과 회의를 하는데 한마디로 꼰대다. 90년대 스타일의 개발 방식을 내세우면서 요즘 트렌드를 이해 못 한다고 했다. 굴삭기가 있는데 배우는데 복잡하다고 삽질이 최고다를 외치는 그런 분위기다.

여하튼 이 직원도 업무를 진행하는데 약간의 문제를 만들기 시작했다. 사실 리더의 역할 중 하나는 고객과 개발팀과의 적절한 업무적 조율을 잘해야 한다. 고객 편에 서면 개발팀의 개고생과 반발이 심해지고 프로젝트는 지옥의 나락으로 떨어진다. 최종적으로 지연과 함께 회사의 이익과 신뢰는 떨어질 수밖에 없다. 반대로 개발팀 편이나 본인 편을 강조하게 되면 고객사는 엄청난 불만이 발생하고 결국 리젝 되는 상황까지 발생하는 것이다.

이 직원은 그 동안의 경력을 기반으로 정말 많은 기능을 추가하고 있었다. 처음 이야기 한 것처럼 이 프로젝트는 작은 사이즈이다. 많은 기능을 넣으면 좋겠지만 고객의 요구도 아니고 기간, 팀 능력 및 금액적으로 봐도 불필요한 상황이었다. 사이즈에 맞게 적절한 기능을 고객과 협의해서 구현하는데 최적의 상황인데 마치 대형 프로젝트인 듯 상황을 만들어갔다. 고객의 입장에서도 해주면 좋겠는데 할 수 있겠냐는 우려를 표현했다. 그런 상황이 고객과 개발팀원들의 문의로 알게 되었고 내가 고객과 다시 조율해서 현실성 있는 구도로 다시 각을 잡았다. 그리고 그 직원에게 이래저래 상황을 설명하고 협의된 내용대로 진행하자고 했다. 그런데...

그런 상황을 그 직원은 자존심이 상했는지 리더인 나 몰래 다시 고객을 만나 설득하기 시작했다. 세상에...

그런 사실을 모르고 있다가 다음날 고객이 다시 메시지로 연락이 왔다. 불편하다고...정리가 안되는 거 같다고...

그래서 그냥 나랑 얘기한대로 진행할 테니 그 직원과 한 이야기는 넘기라고 했다.

그 뒤로도 업무의 역할 때문에 다툼이 있었다. 본인이 할 일이 아니라면서 짜증을 냈다. 가장 큰 문제는 개발 팀원 중 한 명의 요청 때문에  중요한 변경에 대해서 리더나 설계자와 전혀 상의하지 않고 임의로 변경하고 보고도 하지 않았다. 그것 때문에 다들 많은 시간 고생했다. 바뀌었는지 모르고 잘 실행되던 것이 계속 오류가 났기 때문이다. 결국 내가 발견했고 누가 이걸 변경했냐고 하니 그 개발 팀원이 알려줬다. 이래저래 요청하니 저분이 수정해 줬다고. ㅎㅎㅎ

같은 내용에 대한 반복적인 문의와 잘 삐지는? 그런 성향때문에 고객도 좀 힘들어했다.

그런 과정을 지켜보니 왜 이전 프로젝트에서 리젝되었는지 이해가 되었다. 그 뒤로도 몇 번의 기회가 있었지만 프로젝트에서 모두 리젝 되었다고 들었고 결국 퇴사하게 되었다.

다들 그 직원 탓만 하고 그 직원이 문제가 많아서 퇴사하게 되었다고 생각한다. 과연 그렇게 말하는 본인들은 잘 하는가?

물론 그 직원은 프로젝트 리더로서 자격이 부족함은 맞다. 반면 장점도 있었다.

다들 그 직원의 단점만 가지고 평가하고 선입견을 가졌기에 장점을 활용할 생각을 못한것이다.

모든 직원이 완벽하기를 기대한다는 것은 잘못된 생각이다. 그렇게 평가하는 본인은 정말 완벽하냐는 것이다.

사실 나에 대한 평가도 대충 알고 있다. 장점을 아는 사람들은 내 능력을 잘 활용하는데 그저 단점만 보는 리더들 때문에 답답한 늪에 빠지고 있다는 생각이 종종 든다.

나는 작은 프로젝트를 하면서 그 직원의 단점만 본것이 아니라 장점도 봤다. 그래서 그 장점을 최대한 활용하고 그 직원의 능력을 높이 평가해 줬다. 감정적으로 부딪힌 적도 있지만 최대한 빨리 정리했다. 그것도 리더의 능력이다.

하지만 보통 리더들은 자신의 주장과 자존심이 강해서 조금만 다른 의견을 보이면 화를 내거나 짜증을 내고 가버린다. 팀원들에게 엄청 무례한 행동이다. 그리고 자신에게 다른 의견을 제시하거나 바른 정보를 제공하면 감정적으로 대하기 시작하고 결국 진급이나 연봉에 영향까지 주기도 한다. 흔히 꼰대라고 한다.

진정한 리더라면...

우선 리더는 팀원을 존중해야 한다. 근태나 업무진행에 문제가 있는 경우는 당연히 조치를 해야 한다. 그리고 그 직원의 장점과 단점을 빨리 파악해서 장점을 잘 활용할 수 있도록 도와줘야 한다.

IT는 정말 빠르게 변하고 발전한다. 스마트 폰 앱을 만드는데 2G 폰 시절 개발방식을 라떼는~ 하면서 요구한다면 프로젝트는 산으로 갈 것이고 팀원들은 실망하게 될 것이다. 리더라면 직접 개발하지 않더라도 최신 트렌드는 꾸준히 이해하면서 팀원들과 커뮤니케이션을 해야 한다. 회의를 하는데 현재 프로젝트에서 요구하는 신 기술과 전혀 관계없는 라떼를 외친다면 빨리 그만둬라. 최근에도 회의를 하는데 엉뚱한 옛날이야기를 하길래 이 부분은 이런저런 신기술에 대한 부분이다라고 이야기해 주니 살짝 삐져서 가버렸다.

리더라면 회의 시간에 좋은 의견을 주는 팀원에게 긍정적 리액션을 해줘야 한다. 그런데 의견을 제시하는 것에 샘이 나는건지 무슨 의견만 내면 "그럼 니가 해" 라는 말을 툭툭 던지는 리더가 있다. 실제로 내가 일하는 곳에서도 있다.

그렇게 대응하면 어떤 팀원도 좋은 의견이 있어도 이야기 하지 않을 것이다. 발전도 없고 시간 낭비 회의가 될 것이기 때문이다.

프로젝트가 잘 진행되기 위해서는 리더의 역할과 능력이 정말 중요하다. 고객과 팀원과의 관계가 엄청 중요하기 때문이다. 그리고 리더는 항상 공부를 해야 한다. 라떼는 카페에서 맛있게 주문해서 먹는 걸로 끝내야 한다. 

그렇다고 그들의 오랜 경력과 경험을 무시하면 안된다. 프로젝트가 꼭 기술력으로만 성공하는 것이 아니기 때문에다.

멋진 리더가 되는 방법 중 하나는 팀원의 장점도 잘 살펴보고 응원하고 잘할 수 있도록 활용하는 것이다.

 

요즘은 정말 답답한 상황이 많이 발생하고 있다. 무엇이 중요한지 그래서 어떻게 해야 하는지 꼼꼼히 챙기고 진행하는 것이 필요한데 그저 대충대충 아무나 아무나 식으로 프로젝트를 준비하는 것을 보면서 정말 되기를 바라는 것일까 의문이 든다.

오늘도 열심히 스킬을 업 하는 신기한 연구소였습니다.

반응형
반응형

옛날 옛적 프로젝트에서는 소스관리나 형상 관리를 거의 사용하지 않고 각자 컴퓨터에서 개발하고 개발 서버에 반영했던 기억이 있습니다. 충돌도 자주 나고 엉뚱한 소스를 삭제해서 문제가 되기도 했답니다.

물류창고 자동화 프로젝트에 투입되어 저 아랫동네로 간 적이 있었습니다. 비주얼베이직으로 개발했는데 당시 해당 업체는 소스관리를 사용하고 있었습니다. 체크아웃, 체크인 등등 첨 듣는 용어를 사용하면서 우리도 이제 개발에 투입되었으니 소스관리를 해야 한다고 하더군요.

그 뒤로 프로젝트에 투입하면 CVS로 버전 관리를 하면서 commit, update 등을 사용하고 SVN으로 이동하더니 요즘은 git을 사용하더군요. 반면 최근 OO금융권 사이트에 갔는데 SVN과 Git을 혼용해서 사용하는 거 보면 SVN이 사장된 건 아닌가 봅니다.

개발자이지만 보통 중대형급 프로젝트에 투입되니 Git을 설정하고 구성하는 일을 해본적은 없고 보통 갖춰진 환경에서 push, pull 등의 명령어로 작업해 왔습니다. 그러나 개발자 사이트나 유튜브를 보면 git을 많이 활용하고 있더군요. 블로그에서 github에 기술 문서나 소스를 올리고 개인 영역을 만들어 홍보도 하고 예제 소스도 받을 수 있더군요.

그래서 늦었지만 ? git 책을 보면서 실습을 해봤습니다.

간단하게 로컬에서 git환경을 만들어봤고 명령어를 사용해 봤습니다.

까먹지 않게 몇 가지 정리해 봤습니다.

  1. git bash 실행하기

git으로 소스 관리하기 원하는 위치에 폴더를 만듭니다.

폴더로 들어가서 마우스 우클릭을 합니다. (git이 설치되어 있어야 합니다.) 

git bash가 안보임

만약 위 이미지처럼 git bash here가 안 보이면 추가 옵션 표시를 클릭합니다.

이제 Git Bash Here를 클릭합니다. 그러면 cmd 창이 열립니다.

 

2. git 생성하기

새로 만든 폴더에서 소스 관리를 위해 git 생성을 해보겠습니다. 엄청 쉽습니다. 현재 폴더는 텅텅 비어있겠죠?

이제 마법을 시작합니다. git bash에 다음 명령어를 입력합니다. 그전에 위 이미지의 우측 노란색 경로가 내가 위치한 곳이 맞는지 반드시 확인해야 합니다.

$git init를 실행하면 위 이미지처럼 생성이 됩니다.

그리고 이렇게 숨겨진 .git 폴더가 보입니다. 만약 안 보인다면 숨겨진 폴더 보기 옵션에서 설정하면 보입니다.

윈도우즈 11인 경우는 아래와 같이 설정을 체크하면 숨겨진 폴더가 보입니다.

 숨긴 항목 표시에 체크를 하면 .git 폴더가 보일 것이고 성공적으로 git 설정이 되었습니다.

이제 git config --list를 실행해 봅니다.

현재 위치 뒤로 (master)가 보이는데 현재 master 브랜치임을 의미합니다.

git config --list 실행해서 결과가 잘 나오면 설정이 잘 된 겁니다.

이제 다음 명령어를 입력합니다.

git status를 입력하면 현재 작업 진행 내역을 확인할 수 있습니다.

On branch master는 현재 master 브랜치에 위치하고 있다는 의미입니다.

No commits yet은 아직 commit 할 소스가 없다는 의미입니다.

 

3. 신규파일 추가하기.

이제 새로운 파일을 만들고 git으로 관리해 보겠습니다.

먼저 해당 폴더에 새로운 파일 하나를 만듭니다. 여러 가지 방법으로 만들 수 있지만 우클릭으로 텍스트파일을 하나 만들겠습니다. 아래 이미지와 같이 텍스트파일을 선택하고 파일이름을 first.txt로 만듭니다.

이제 이 파일을 열어서 내용을 입력합니다. 원하는 글자 아무거나 넣어도 됩니다.

사과를 입력해 보겠습니다. 그리고 저장합니다.

이제 다시 git bash창으로 이동해서 다음 명령어를 입력합니다.

git status를 입력하고 엔터를 치면 위 이미지처럼 결과가 나옵니다. 빨간색 first.txt 글자가 보입니다.

git add를 해서 commit를 하라는 의미입니다. 

git add first.txt라고 입력하고 엔터를 치면 빈 줄 하나 나옵니다. 정상으로 add가 되었다는 의미입니다.

다시 git status 명령어를 실행해 보겠습니다.

git add를 하고 난 후는 빨간색 first.txt가 초록색으로 변했습니다.

new file이라는 표시도 보입니다.

git add는 git 영역의 스테이지 공간에 옮기는 의미입니다.

git폴더에서 first.txt를 만들면 아직 git에 등록은 안되었지만 git 영역에서 새로 만들었기에 빨간색으로 추가하라는 메시지를 보여줍니다. git add를 하면 commit 전 git stage(스테이지) 공간에 목록이 생성됩니다. commit 대상이라는 의미입니다. 

즉, 새로 만든 파일이나 수정된 파일을 git 버전관리에 등록하기 위해서는 대기자 명단에 올려야 하는데 바로 git add가 그 역할을 합니다.

 

 4. git에 파일 등록하는 commit.

이제 다음 명령어를 사용해서 파일을 git에 올리고 버전관리를 해보겠습니다.

git commit -m "first filegit commit"라는 명령어로 파일을 등록했습니다.

-m은 해당 커밋에 대한 메시지를 등록하는 것으로 필수항목입니다. 빈 값이라도 넣어야 한다는 의미입니다.

-m "메시지" 부분에는 해당 커밋을 왜 하는지 관련 내용을 상세히 기록하면 나중에 확인하기 편하답니다.

만약 git commit만 입력한다면 전혀 새로운 메시지 입력 화면을 만나게 될 것입니다. 그럴 땐 당황하지 마세요.

아래 간단한 사용법을 보여드립니다.

first.txt에 배라는 글자를 추가하고 저장합니다.

그리고 git status 명령어를 입력하면 위 이미지처럼 수정된 파일이 있다고 해당 파일이 빨간색으로 표시됩니다.

git add를 사용해서 스테이지에 등록합니다.

그리고 git commit만 치면 아래와 같은 화면이 나옵니다.

바로 -m을 사용해서 commit 메시지를 입력하지 않았기에 강제로 이 화면으로 이동해서 메시지를 입력하게 만듭니다.

사용법은 i 나 a를 누르면 입력모드로 변신합니다.

그리고 원하는 내용을 입력합니다. -m과는 다르게 줄 바꿈 해서 다양한 내용을 입력할 수 있다는 겁니다.

3줄로 내용을 입력했습니다. 이제 이 내용을 저장해야 합니다.

저장하는 방법 : 키보드 좌측 상단 esc버튼을 누릅니다. 그리고 키보드 우측 중간쯤의 콜론(:)을 누릅니다. 

w!를 입력하면 저장이 됩니다. q!를 입력하면 빠져나옵니다. wq!를 같이 입력하면 저장하면서 빠져나옵니다. 

하단에 입력한 명령어가 보입니다. wq!로 저장 후 종료하겠습니다.

commit 메시지를 포함해서 정상 처리가 되었습니다.

 

5. git log로 이력 조회하기.

git log를 사용해서 어떤 히스토리가 생겼는지 그간 작업 내역을 조회합니다.

제일 하단에 first filegit commit가 17시 19분 51초에 처리되었다는 기록이 보입니다.

그 위로는 2줄로 입력한 commit 메시지가 보입니다. 

잘 처리되었습니다.

근데 3줄 입력한 메시지가 왜 2줄이냐면 중간에 한 줄 지우고 commit 했거든요. ^^

새로운 파일을 생성해서 git add와 git commit을 사용해 등록하고 수정 파일도 git에 등록하는 방법을 살펴봤습니다.

이 외에도 git 관련 명령어가 많이 있습니다.

다음 포스팅에 설명해 보겠습니다.

감기 조심하세요~

 

반응형