Page History

...

연말에 과거1년을 돌아보면, 이상하게 비슷한 날짜에 같은 장애처리를 합니다. SSL인증서 만료처럼

우리는 1년이 지나면 잊어버리게 되어있습니다. 1년전에 발생한 장애이슈에대해

한번한 실수는 보통 한사람이 다시 잘안합니다. 시간이지나면 하거나 과거에했던  과거에했던 누군가의 실수를 팀내 다른사람이 되풀이할뿐이죠

...

새로 영입된 아키텍트는 한참 분석하더니 결론을 내렸습니다. 이것은 블랙 박스다라고 

언젠가 원래는 팀장이 아키텍트역활을 한다라고 들은적이 없습니다했었습니다. 팀장은 결코 자신의  팀장은 결코 자신이 팀장인  기간내에 작성된 팀코드를 블랙박스다란 결론을 내릴수없습니다.

 이것을 그리고 그것은 좀더 좋은 단어로 바꿔 불렀습니다. 레거시 코드이며, 이것을 개발하는 팀은 레거시팀이다라고 그리고 신규개발팀을 만들었습니다.

저는 이의미에 반대하였습니다. 제가 레거시팀의 메인개발자였으며 

오래된 기술을 사용한다고 해도 현재 서비스를 잘하고 있는데 어떻게 유산이냐고?  새로운 서비스로 바꾸고 나서 그렇게 불러달라고

하지만 늦게 수긍을 하였습니다. 레거시인 이유는 사용된 기술이 오래되서가 아니라

기존코드가 비지니스 흐름 분석이 안되고 개선 지점을 찾을수없으며 문서화도 안되고 배포도 어려운

예전 고전적인 개발방법을 통해 개발이되었기때문이다라고~ 

어쨋든 이것을 지켜보는 상위 관리팀에서 극단의 지침을 내립니다. 이것은 플래폼의 문제를 뛰어넘는것입니다.

그냥 놀아라, 너희가 노는것을 보장해주겠다.

하지만 활동을 하고 싶은면 너가 하는일이무엇인지?  사소한 일도 티켓을 만들어라~만들고 그 과정을 문서화해라~

티켓:특정한 것을 할 수 있는 자격. (네이버사전)

...

처음에는 , 뭔가 답답했습니다. 우리는 우리만의 아날로그적인 감성과 , 아날로그적으로 일하는것을 더 선호했습니다.

내가 하는일의 제목을 무엇으로 달지?  할당은 하고? 요청해야할 제목은 무엇으로 할것이며? 문서로 어떻게 설득을 시킬것이며 할당은 누구에게 하지?

이전에는 그냥 담당팀 아무개한테 해달라고 하면 해줬는데~~

이런 고민을 하는게 아주 소모적이였습니다. 처음에는 소모적 으로 느껴졌습니다.

그리고 내가 하는 일을 스스로 보고하여 트래킹 당하는것도 싫었습니다.

...

• 퇴근시간 갑자기 생긴일에 응대를 해주면 착한 개발자 
• 문의받은 그내용이 무엇인지 어렵풋이알지만 신속하게 잘못된 유추한 정보로 응대를 해줘도 착한 개발자

기존의 그결과는 이렇습니다.

• 유추한 정보가 전달되더니 서비스에 반영됩니다. 실제 그러했습니다.
• 팀의 리소스가 분배되지않고, 팀장을 건너뛰어 팀내 외부 담당전문 개발자가 생깁니다. 팀장도 진행사항을 놓치게됩니다.
• 퇴근시간이되면 문의하는 습관이 생깁니다. 상대가 칼퇴하면 문제 삼습니다.
• 런칭 1주일도 안남아서, 이거 담주 올라가야하니 빨리해주세요 라고 요청합니다. 계획되지 않은걸 문제삼지 않고, 1주일이내에 못끝낸 담당자가 잘못되게 됩니다.

그렇습니다. 기존에는 자신의 팀업무를 위해서 특정누구한테 문의가 집중되었으며 관리도 안되었습니다.

할당수로 측정이되니, 이제 팀내에서 분업을 어떻게 시킬까 고민을 하게 만들었습니다. 대부분의 팀의 일은

이제 팀장에게 직접 할당이 되니까요. 그리고 팀장끼리 협업을 해야합니다. 자신의 팀 문제가 아니면 다른팀에게

넘겨야하니까요

 어쨋건 우리가하는일을 트래킹 시스템을 도입하고 ,아주 세세한 일까지

기록하기로 합의를 하였으며, 프로세스의 잘잘못은 이후에 바로잡아가기로 합니다.

모든 문제의 파악은, 직관적인 티켓을 통해서만 하기로 하였으니까요....,

신규기능 추가

 신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.

...

그리고 사업부에서 BA(비지니스분석,기획)에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 할당합니다.

기획초안 작성

 이제 BA는 발빠르게 움직입니다. 도대체 이게 무슨 내용이지?  기존 작동법부터 배우기시작합니다.

...

BA와 개발자는 의사소통이 어렵기 때문에, 아케텍트에게 개발가능하게 구체화 해달라고 할당 합니다.

분석

 각 개발팀이 모여 어떻게 누가? 어떻게 개발해야할지 분석에 들어갑니다.  

...

이때 대부분의 사업요구서와 기획티켓이 연관이되기때문에 여기에 직간접 참여한 모든 개발자및 QA 데브옵스 디자이너등등

자신이 무엇때문에 일을 하고 있는지 그 이유에대해서 이유와 사명감에 대해서 알게됩니다. 

 아키텍트의 참관하에 BA가 설명을하고 어떤 개발팀이 필요한지 물어봅니다.  

개발팀의 거짓말을 방지하기위해 감독역활로 아키텍트는 그냥 참관합니다. 가끔 이건 안되요 하면 아키텍트가 열심히 리서치해서

해법을 찾아주기도 합니다. 아주 자끔입니다가끔입니다.

QA는 QA범위 산정을 위해 미리 참관을하지만, 새롭게 작동되는 방식에대해 의문을 제기하기도 합니다. 기존작동은 아시냐구요?  

...

알고싶지는 않지만, 서버두대 추가로 해야되는 고급 일들이 많아 보입니다. 그리고 데브옵스는 임무를 마치고 자기일 하러 갑니다. 아직 프로젝트이프로젝트가

완료되려면 완료 되려면 한참 남았으니까요 

...

두리뭉실하게 재해석을 하고 파이팅을 외치며 회의는 끝나게 됩니다. 금요일은  빨리 퇴근 해야하기떄문에 이야기가 길어지면

안되기때문입니다.

설계

 아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작하며

...

뭣이 중한디? 아무나 빨리하고 일정을 맞추시오. DB에서 영업을뛰어 이 비지니스로직이 DB로 가면 가게되면 공수가생겨 업데이트가 연기가 됩니다

PM이 BA및 아키텍트의 조건부 승인을 받아냅니다. 런칭 날짜가 더 중요하니 이 로직은 그냥 서버에 있게하고 서버가 하게하고 다음에 개선하자

어느정도 아키텍쳐가 그려지는듯 하더니   이러는 동안 PRD(프로덕요구사항)에 수정이 일어나고,

...

QA는 조용하게 이때까지 준비한 테스트 케이스를  모두 폐기하고, 최종 결론본에 맞춰 처음부터 다시작성합니다.

개발

개발 이전에 수많은 분석및 설계 티켓이 먼저 생성되었습니다. 그렇습니다. 그것은 티켓번호 7782입니다.

...

완벽하게 작동됩니다. 라고 이야기하는것입니다.

DEV-QA

개발이 완료되고, release 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다.

...

DEV-릴리즈 프리징이되었으며 이것은 서비스에바로올려도 문제가 없을것이다란 희망입니다. 그리고 통합환경인 INT로 넘어갑니다.

INT-QA

INT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release 프리징을 통해 이미 완료 되었으며

...

이경우 stable 브랜치를 통해 fix는 가능하나, 굳이 그러지 않습니다.

운영

 INT-QA/LOAD TEST 가 완료되었다고 운영에 반영할수 있는것은 아닙니다.

...

운영 수동배포는 다음에 빅이슈 되어 처리해야할 개발과제가 됩니다. 대부분 고질적 문제로 자동배포는 빠르게 해결이안됩니다.

빌드관리자의 승인거부는 승인은 릴리즈 날짜를 방해하는 요소가 배포서비스를 안정화하겠다란 의지이며요소가아니며,  배포서비스를 안정화하겠다란 의지입니다.

결국 추후 자동배포처리가 모두 되었습니다. . 이 이후부터 빌드관리자의 승인거부는 절대적인게 됩니다.

Image Added

-길거리에서 긴급처리한 실제 카톡내용입니다. 다행히 노트북과 버려진 테이블이 있었습니다.

이것은 운영장애 발생이 아닌,  하루전 갑자기 자동빌드가 깨져서 빌드를 정상화하는것입니다.

물론 수동으로 Deploy로 처리할수 있는 부분이지만, 자동배포이후 그것은 허용되질 않았습니다. 등장인물은 PM,데브옵스,개발자,QA ( INT에서 검증후 내보냄)

이제 험난한 과정을 거치고 드디어 런칭하였습니다.  이제부터느 운영이기때문에 집중 테스트가 진행됩니다.

...

디플로이 스냅샷을 통해 롤백이 가능합니다. ( 여기서 디플로이 스냅샷은 자동으로 생성되는것 or 수동으로라도 운영빌드된 패키지가 백업이 됨을 의미)

이러한 문제는 아무문제없어하고 보통 모든 운영 반영 테스트를 마치고 새벽에 잠이들때 발생합니다.

이때 이미 일반적으로 회사는 퇴근후 개인 사생활을 보장했기때문에 개인 휴대폰을 통해 연락할수 없으며

...

어쨋건 이 모든 과정이 끝나면  PKIV-001 멀티로그인 대장정대서사시(EPIC) 티켓이 끝나게 막을 됩니다.

정리

이 긴내용에 언급된 티켓을  생성순으로 리스트업하면

...