본문 바로가기

오늘의 커밋

오늘의 커밋. 주말과 번아웃

728x90

오늘은 알고리즘 문제를 풀고 커밋했습니다.

오브젝트를 정렬하는 문제로,

파이썬에서 클래스를 활용하는 방법과 정렬 및 람다식을 이용하는 방법에 대해 배울 수 있었습니다.

github.com/thekanon/algorism/blob/master/HackerRank/sortingComparator.py

 

thekanon/algorism

Contribute to thekanon/algorism development by creating an account on GitHub.

github.com


오늘은 출근하니 여러 이슈가 터졌습니다.

 

여기 프로젝트에서는 대체 왜 쓰는지 알 수 없는 기업용 형상 관리 툴을 이용하고 있습니다

 

소스 변경시점마다 해당 업무 담당자에게 결재를 받아야하는데, 소스가 프리징되어 있는 운영단계도 아니고

한창 결함 수정이 이루어지고 있는 테스트 단계에서 이러한 툴은 생산성을 크게 저하시킵니다.

무려 형상관리 프로세스가 9단계 입니다..

 

1. 변경 예정 파일 작성 및 업무 담당자 승인

2. 변경 예정 파일 등록

3. 파일 저장소에 저장

4. 개발 서버 배포 요청 및 개발자 로컬 테스트

5. 개발 서버 배포

6. 개발 서버 테스트

7. 운영서버 배포 요청 및 PL 개발 테스트

8. 운영서버 배포

9. 운영서버 테스트 및 업무담당자 최종 승인

 

하루에 많게는 5번 이상 수정되는 소스를 매번 이렇게 반영하는것은 사실상 불가능하죠.

결국은 개발자가 수정시마다 담당자의 계정으로 로그인/로그아웃 하여 승인하는 방식으로 사용하는데,

이렇게 되면 비싼 값을 들여 형상관리 솔루션을 도입한 의미가 없습니다.

 

그 외에도 이 솔루션은 여러가지로 문제가 많았는데,

가장 중요한 기능인 소스 배포 기능이 업무구분에 따라 제대로 동작하지 않았습니다.

 

업무 A는 개발서버에만 배포되고,

업무 B는 운영서버에만 배포되는 식으로요.

 

하지만 이쪽 업계의 특성상 이미 도입된 솔루션은 바꿀 수 없고, 개발자가 고생하는 결말로 가버렸죠.

(정말 고통스럽습니다)

 

여튼 각설하고, 이곳의 AA(Application Architect)분과 형상관리 관련한 커뮤니케이션이 잘 안되어 신나게 털렸습니다.

2가지 방법이 있었는데 모두 실패했죠.

1. 그냥 닥치고 있는다.

2. 의도를 제대로 파악한다

 

언젠가 고쳐야 할 부분이지만 저는 아직 공격적인 태도와 압박에 유연하게 대처하지 못하는 것 같아요.

포지션 상, 프로젝트의 그 어떤 개발자보다도 많은 말을 하고, 또 지금까지 자신있었던 것이지만 오늘은 조금 바보같았던 것 같습니다. 덕분에 하루종일 기분 다운된 상태로 일을 했죠.

 

더군다나 퇴근 직전에는 원인이 무엇인지 파악할수조차 없는 엑셀 생성 관련 오류를 발견했습니다.

월요일에 밀린 업무와 함께 이 이슈를 처리할 생각을 하니 정말이지 끔찍하군요..

 

사실 이러한 문제를 생전 처음겪는다던가, 답이없는 문제라던가 뭐 그런것은 아닙니다만

정말로 고통스럽네요.

 

아무래도 번아웃이 온것 같습니다.

 

프로젝트가 시작된 1월 중순부터 지금까지.. 그리고 11월 말까지

쉼없이 달려왔고, 또 계속 달려야 합니다.

 

하지만 지금까지 너무나 힘들었고,

앞으로 남아있는 일정을 생각하면 잘 해낼 수 있을지 걱정이 앞서며

지금까지 해왔던 나의 노력이 부정될까 겁이 납니다.

 

스트레스를 풀어봅시다

 

라익

디스

 

 

 

 

 

 

 

 

 

 

 

 

728x90