커밋에서 티켓 클로우즈까지

  하루에도 여러차례 서비스코드를 개선하기위해 커밋을하고, 그 커밋은 어떠한 결정에 의해 이루어지며

그 어떠한 결정과정은 , 메일함 어딘가에 있습니다. 메신져 어딘가에 있습니다. 친절한 담당자가 

잘 대응을 해주었으니까요.  그렇게 매직 코드는 쌓여만 갑니다.

장애처리와 관련해서는 해결을위한 처리도 원인 파악을 통해 이루어졌지만

지식및 운영에 관련하여 그어떠한 노하우도 쌓이지않고 추적이 되지 않으니 또 생깁니다.

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

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

하지만 우리들만의 방식으로 잘 운영이되고있습니다. 운영팀을 도입했지만, 그들은 서버를 켜고끌뿐입니다.

개발과 운영이 분리되지 않습니다. 왜? 개발자가 직접 배포하고 운영도 해야 하니까요

우리는  남들이 컨트롤 못하게 곳곳에  수동조작 버튼을 곳곳에 심어놓았습니다. 그리고 그것은 문서화도 안되어있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

그러면서 잘못된 세가지를 알게되었습니다.

• 상대팀의 리소스를 , 내가 함부로 사용할수 없다란것. 
• 또한 그 리소스에 대한 역활및 사용권한에대해  애시당초 정의한적 없었다란것
• 미리 계획하고 요청했을 기회를 무시하고 , 나중에 언제든 요청하면 바로 해주겠지하고 미룬것

기존에는 이러한게  미덕이였습니다.

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

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

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

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

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

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

넘겨야하니까요

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

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

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

신규기능 추가

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

티켓이름  "PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가"  

내용: 다중기기 사용자가 늘고있으니, 멀티로그인을 허용해라~~ 이하 생략,아니 없음

하지만 어딘가 이러한 티켓이 발견이 됩니다. "BI-001 다중기기를 로그인을 허용했을때 수익증가율 분석"

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

기획초안 작성

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

유니크한 로그인이 뭔지 그떄 파악하고 , 멀티로그인이 가능함으로 할수 있는 여러가지 아이디어를 넣기시작합니다.

기존 기능과 충돌나는 사항에 에대해 고려하지 못할수도 있습니다.

그리고 기획문서 초안이 완성되는 시점, 관련 개발팀을 소집합니다.

"기획-001:멀티 로그인을 통한 플래폼 기능개선"  내용: prd에서 내용약간 추가됨

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

분석

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

PM은 이때 냄새를 맡고 , 개발관련 스케쥴을 컨트롤 하려고 합니다. 런칭일을 준수하지 못하면

프로덕트 메니져에게 혼나기 떄문입니다.

"PKIV-001-다중기기 사용자를 대비한 멀티 로그인  대장정(EPIC)"  우선 가장 거대한 티켓을 만들고 봅니다.  

(여기서 PKIV는 프로덕트기준 약속된 개발관련 접두어이며 자동으로 붙습니다.)

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

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

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

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

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

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

서버팀도 한마디 합니다. "이거  다중기기 허용하면 부하증가 어떻게 하실겁니까?" 하지만  아차합니다. 자기팀에서 해야되는 일이기때문에

괞히 부하이야기 꺼냈다가 아키텍트가 로드 테스트팀을 붙여서 로드테스트 티켓도 만들어버립니다.

갑자기 PM은 그래 서버가 필요해? 잘 쉬고 있는 데브 옵스를 데리고 오고, 데브옵스는 "ITO-001-개발서버두대추가" 티켓을  즉석으로 만들고

PKIV- 멀티로긴 개발대장정(EPIC) 티켓에 연결시킵니다. 물론 이 서브티켓에는 BIGIP설정및 SSL인증서 라우터룰셋팅등 잡다한 티켓이 생성됩니다.

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

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

결국 DB / 서버 / 클라이언트/모바일팀  4팀에서 개발을 하기로 결정하고 기획서의 숨겨지고 함축된 의미에 대해

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

안되기때문입니다.

설계

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

어떠한 기능에대해  비지니스 로직이 어디에 있어야 하는가에 대해 물어보기 시작됩니다.

DB냐? 서버냐?  게으른 서버개발자는 이것을 클라이언트에게 넘기기도 하고

똑똑한 클라이언트 개발자는 아키텍트를 설득시켜 다시 넘기기도합니다. 그리고 그것은 다시 DB로 넘어가기도합니다.

아키텍트는 아름다운 중재를 합니다. 반반씩 해라~~~  DB반 서버반....  이 단계가 길어집니다. PM이 개입합니다.

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

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

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

기획서가 변경됩니다.   기획-001 티켓을 은근슬쩍 수정하여 공지합니다

멀티 로그인 허용이지만 모바일은  허용하고,PC는 비허용

이때까지한 설계가 수포로 돌아가거나, 수정이 필요합니다. 원래부터 탄탄한 구조가 아니였기에 옵션화를 통해 할수 있는게 아닙니다.

여러가지 사이드 이펙트 문제로 아키텍/개발자/기획 의 논쟁이 끝나지 않습니다. 

이런문제는 모든 충돌사항을 수용을 시켜야 해결이되며, 그것이 끝날때까지는 개발이 시작될수없습니다.

이때 항상 해결자가 등장하여, 어떠한 중립적인 아키텍쳐를 제시하여 그 문제를 해결을 합니다.  

이러한 설계 티켓번호는 분쟁이 심하면 내용으로 기억되지 않습니다.

숫자로 기억됩니다.  7782번 티켓이라고  ..... 개발시간을 다 까먹었지만 릴리즈 날자는 변경없이 다음 단계로 돌입하게되며

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

개발

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

PKIV-001 대서사시(EPIC) 에대한 서브 티켓으로

• PKIV02-DB팀의 다중 로그인 추가에 대한 이야기(STORY)
• PKIV03-서버팀의 다중 로그인 추가에 대한 이야기(STORY) 
• PKIV04-클라이트팀의 다중 로그인 추가에 대한 이야기(STORY)
• PKIV05-다중로그인 테스트에대한 아름다운 QA의 이야기(STORY)

각팀에서 해야할 스토리들이 만들어집니다.  

그 이야기에 대한 하부를 어떻게 그룹핑하고 풀어야 할지는 각 개발팀이 만들어야 하며 이때부터

진행사항을 PM이 개입하기 시작합니다. PM은 작업 과정에는 관심이 없고 스토리가 모두 완료되는것에만 관심이 있습니다.

실질적인 하위 일(TASK)이 모두 끝나야 각팀의 이야기가 끝나기 때문입니다. 

개발팀은 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다.

대부분 버그는 개발자가 안 알려준곳에서만 생깁니다. 체크리스트는 개발자가 알려준곳 제외하고 나머지를 정리하는것입니다.

소스및 소스에따른 구동환경은 다음과 같이 진행됩니다.

최신 master로부터  featured-기능 브랜치를 각각 만들고,  로컬 개발테스트가 완료되면   release 브랜치로 통합하여 QA를 준비합니다.

이와 동시에  데브옵스는 릴리즈 브랜치를 확인하고 DEV 배포 환경을 준비합니다. (완전 자동화는 아님)

DEV 배포환경이라고 각 기능서버가 한대씩만 존재 하지 않습니다.

실전과같이  스위칭 환경 테스팅도 포함되기때문에 스위칭이되는 장비는 최소  이중화가되어 쌍을 이룹니다.

또한  실제 개발 서브 도메인을 사용합니다.  host를 변경하여 테스트하는 순간 변질된 테스트이기때문입니다.

한가지 팁을 알려드리면, 이런것이 가능한것은 내부/외부 모든 url은 설정화이며 백오피스에 런타임으로도 바꾸면

모든 서버및, 모슨 수만명의 브라우져 사용자에게 실시간 변경사항 적용되기 때문에 가능합니다.

host를 변경하는 테스트를 DEV테스트라고 하지 않습니다. 이것은 QA에 내보낼수 없는 로컬 테스트입니다.

사용자에게  system 폴더에 있는 host파일을 관리자 권한으로 열어서 따따따.com을 111 로 바꾸면 우리의 솔류션은

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

DEV-QA

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

기획서의 내용이 추가되고 개발이 추가됩니다. 동시에 기능 TEST를 하고 A를 FIX하고 문제가 없던 B가 문제가 생깁니다. 

QA는 불평을 합니다. A를  개선하고 FIX 하였는데, B가 왜 문제 생기냐고?

개발자는 쏘리하고 B도 수정해줍니다. 험난한 고비를 넘어 QA의 SING-OFF가 나기직전입니다.

개발내용에따라, 이중화된 서버중 한대를 내리거나, 인터넷 연결선을 단절하거나 극단의 테스트를  마지막에 수행하기도 합니다.

이것에 대한 복구도 개발서버가 커버를 해야하는 부분입니다.  이러한 극단 테스트는 

10번 시도하고 8번정도 복구가됩니다.  인터넷 제공업체의 인터넷 품질에 대해 커버를 모두할수는 없기에 테스트 OK하고 넘어갑니다. 

 이제 대서사시(EPIC) 종료를 위해

통합 테스트 환경인  INT 단계로 넘어가게 됩니다. INT로 넘어가기전의 소스는 가급적 수정이 일어나면 안됩니다.

대서사시의 마무리단계에서, 중간 이야기를 변경하면 그 이후의 이야기도 다시 작성해야 하기때문에 독자들이 화를 낼것입니다.

(QA를 또해야하고, QASingOFF 날짜도 PM과 약속한 QA가 완료해야할 날짜가 있기때문입니다. )

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

INT-QA

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

희망사항이 이어진다고 하면, 여기서 넘어온 릴리즈 환경이 리얼서비스환경에 반영이되어도 문제가 없어야합니다. 

 QA완료된 릴리즈 프리징 된 배포버젼이 리얼에 올라가도 문제가 없는게 우리의 희망사항이나

이상은 그렇지 않습니다. 그래서 DEV에 했던 단편적인 테스트를 모두 집합시켜 INT에 한방에 반영하여 풀테스트를 진행합니다. 

가끔 이런 문제제기를 합니다.  INT에서 10%를 빼겠다고, 왜 이런것이 깔끔하게 안되냐고?

답은 간단합니다  INT를 포기하고 DEV단계로 다시 가야하는 이슈입니다. 소스머지가 완벽한다고 해도 안될일입니다.

애시당초 INT에서는 머지를하거나 뺄려고 만든 환경이 아니기 때문입니다. 이것은 SVN,GIT과 상관없이 형상관리를 초월하는 문제입니다.

애시당초  기능활성 미지수인것은 실시간 옵션화로 미리 계획되어야 되는일이며 실제로 수많은 예상기능들이

그렇게하여 소스와 머지된상태로 비활성화되어 올라갔습니다. 또한 옵션 활성/미활성에따른 이중 테스트도 포함이 되었구요

INT환경은  또한 실제 서비스환경과 비슷한 테스트 환경으로,  DB 역시 서비스수준으로 노이즈가 없어야합니다.

 코드프리징이 일어난 Release라 할지라도,DEV에 가지않고  중요한 작은범위의 변경정도는 할수가 있습니다.

추가 변경 테스트를  INT에서 해야하고 소스차가 생겼기때문에 이상황에서는 DEV의 가치는 없어졌습니다. 

그리고 일정상 어떠한 문제에대해서 안올리는게 좋다란 QA판단을 합니다.

A를 고치니...더 중요한 B문제를 놓치는 케이스가 분명 있기때문에 코드변경시 일정내에 QA에서 검증을 할수 없다라고 합니다.  

이것은 이미 보고된 문제임으로 프로덕트 조건 승인이 까지 이루어지면 다음에 개선하기로하고 넘어가는 경우도 있으며

분명 무리하게 고친것보다 , 더 안정적이게 됩니다.

이제 힘든 QA활동을 마쳤습니다. 이것이 바로 프로덕에 갈꺼같지만 몇가지 단계가 더 남았습니다.

INT SignOff는 Release → Master로 통합될수 있다란 의미이자  실반영을 해도 된다란 약속이며 실제로 머지가 됩니다.

하지만 여기서 끝이아니고 실제 운영반영을 위한 민방위 훈련이 하루종일 시행이됩니다.

데브옵스는 INT의 모든 배포 변경사항을  현재 운영 서비스와 동일하게 롤백하고

그동안 INT가 Release대상으로 디플로이 된것을 , Master로 변경합니다.   

Master를 통해 실서비스 반영과 똑같은 스텝으로 , 실제 반영  가상 테스트 시나리오 에 돌입하게 됩니다.

이상적으로 운영 순서에따른,혹은 설정사항 순서 적용에따른 문제를 미리 찾을수 있습니다.

QA는 모든 업데이트 타임을 보고받고, 그 타이밍에 맞는 스모크 테스트를 합니다. 

한가지 예로 로그인서버가 순차 교체가 된다고하면,  그 타이밍에 로그인을 계속 시도하는것입니다.

이쯔음 데브옵스는  동시에 Master를 통한 운영 빌드및 디플로이를 준비합니다.

(빌드와 배포는  분리되어야하는것으로 빌드를 미리해둡니다. )

-만약 이때, 운영버그를 발견한다면,그것은 지금것 방치되었다란 의미이며  무리하게 Fix하지 않고 다음으로 미룹니다

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

운영

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

배포단계에 보안에 문제가 있는부분은 없는지? 이상하게 배포하고 있지 않는지?

"DA001-멀티로그인 추가에따른 운영반영"  티켓이 만들어집니다.  이곳에는 각종 적용스텝,롤백플랜등이 들어있습니다.

만약 하나라도 이상한점이 있거나 수동조작으로 악성코드를 심을수 있는 상황을 개발자에게 제공할 기회를 준다고 하면,

최고 빌드관리자의  승인거부하에 프로덕에  올라갈수 없습니다.

이경우 런칭일정준수상  프로덕트 관리자의 조건부 승인이 추가로 필요합니다. 

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

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

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

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

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

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

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

QA에선 테스트기간 1주일동안 못찾은 문제를, 1분만에 찾는 초능력을 발휘하기도 합니다.

 서비스 운영에 반영후, hotfix가 생기면 아직 master가 최신 개발반영소스라 master를 통해 hotfix 진행이 가능합니다. 

운영에 발생한 버그는 , QA와 분리하여 진행됩니다.  "OP-001 로그인안됨  심각단계 : L2"

 아주 큰 결정력이 따르지만 , 만약 긴급 롤백이 생긴다면, 개발소스를 통해 하는게 아니라... 이미 운영에 빌드완료되고 디플로이 셋트가 있기때문에

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

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

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

개인 전화번도또한 리스트업을 하지 않았습니다. 참 좋은 회사죠......

 그래서 회사가 준비했습니다. 운영대응 개발자에게 폰을 하나씩 지급했습니다. 무제한 데이터로 아주 잘사용했습니다.

하지만 이 전화는 새벽에 울립니다. L2일때 말이죠 

여기서 L3정도의 우선순위 Fix이면 바로 반영 하기보다, 반영과정에 문제가 없는지 체크가 필요하기 때문에

약소한 INT단계를 한번더 거친후 문제가 없음을 확인하고, 서비스에서 HOTFIX 반영이 이루어집니다.

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

정리

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

• PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가
  • 기획-001:멀티 로그인을 통한 플래폼 기능개선
  • 7782
  • PKIV-001-다중기기 사용자를 대비한 멀티 로그인 추가
    • PKIV02-DB 다중로그인 추가
    • SP A 수정
    • SP B 추가
    • PKIV03-서버 다중로그인추가
    • LS변경
    • GS변경
    • DC변경
    • TMS변경
    • PKIV04-클라이언트 다중로그인추가
    • 관련 메시지추가
  • ITO-001-멀티로긴 운영서버 두대추가
    • ITO-002-잡다한 설정하기
  • PKIV-005 다중로그인 QA
    • 여러가지 아주 많은 이슈
  • DA001-멀티로그인운영반영
    • 업데이트 절차
    • 롤백방안
    • 서버적용범위
    • 관련 PRD
  • OP-001 로그인안됨 심각단계 : L2
    • PKIV-새벽에 잠깨는 ,로그인해결개발티켓

 위와같이 한가지 개발 프로세스가 PRD를 통하여 연관 작업을 모두 파악할수 있으며

반대로, 장애 이슈를 통해서도 이 이슈의 태초의 이슈인 프로덕 요구사항을 파악할수가 있습니다.

새벽에 나의 잠을 깨운 티켓및 담당자 추적도 가능합니다. 

이야기가 정리없이 길었지만

이것의 중요한 의미는 서사시(epic)가  축적이되어 우리의 자산(백과사전)이 된다라는 것입니다.

현재 개발 프로세스를 다시 공부하면서 다음 4가지를 통합 구축중에 있습니다.

JIRA : http://jira.webnori.com/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all

빌드/배포 CI툴 : http://bam.webnori.com/allPlans.action

GIT툴 : http://git.webnori.com/dashboard

개발 프로세스와 연동되는 문서화 기능  : http://wiki.webnori.com/