요구사항이 불분명한 프로젝트의 일생
어떤 프로젝트는 예상보다 훨씬 더 긴 기간 동안 엄청난 비용을 들여 개발하지만 여간해서 출시되지 않습니다. 왜 그럴까요?

멋진 디렉터님들이 행사에 나타나 하시는 말씀을 들어 보면 모든 프로젝트에는 항상 명확한 비전이 있고 모두가 그 비전을 이루기 위해 최선을 다하고 있는 것처럼 보입니다. 그 비전은 종종 고객들의 요구사항과 일치하지 않을 수 있지만 또 다른 이벤트에서 이 사실을 인정하고 다시 고객들의 요구에 맞는 방향으로 프로젝트의 요구사항을 변경해 개발해 나가고 있다는 이야기를 접할 수도 있습니다. 이런 모습을 보면 모든 프로젝트에는 항상 명확한 목표가 있고 이 목표를 달성하기 위한 요구사항이 있으며 프로젝트에 속한 모두가 그 요구사항을 달성하기 위해 노력하고 있는 것 같다고 느낄 수 있는데 이는 종종 맞을 때도 있지만 다른 더 많은 경우에 맞지 않을 수 있습니다. 놀랍게도 연 인원 수 백 명의 생계를 유지하는 엄청난 개발비를 투입한 프로젝트가 명확한 목표와 이에 기반한 요구사항 없이 어쩔 수 없는 개발을 계속하고 있는 경우는 생각보다 쉽게 발견할 수 있습니다. 회사는 이런 무서운 상태를 알고 있는 것일까요? 회사는 과연 수 백 명에 달하는 사람들의 생계를 유지하기 위해 이런 위험한 자선사업을 감행하고 있는 것일까요?
온라인 게임이 한창 나타나기 시작하던 시대에는 여러 회사들이 게임 이름 뒤에 ‘_온라인’을 붙인 비슷비슷한 게임을 개발해 공개하곤 했습니다. 처음 잠깐 동안은 이런 게임이 나타나는 상황이 그리 이상하지 않았지만 게임 각각은 고객들의 시간을 강하게 요구하는 MMO 장르였던 관계로 그런 비슷한 게임 수 십 개가 시장에 동시에 나타나자 순식간에 피로감을 느끼게 됩니다. 고객들은 방금 소개한 접미사가 붙어 있는 게임에 이전만큼 그리 큰 관심을 가지지 않았고 또 주로 고객들을 주 대상으로 삼는 매체들도 이런 현상을 비판하며 얻은 조회수를 통해 광고 수익을 얻습니다. 하지만 이런 고객들의 피로감과 이 피로감에 기반한 비즈니스가 유효한 경제적 성과를 달성하고 있음에도 불구하고 이런 사실이 회사를 지탱하는 여러 스폰서들에게까지 전달되는데는 훨씬 긴 시간이 걸린 것 같습니다. 우리들 스스로도 뻔한 접미사가 붙은 온라인 게임의 등장에 감흥이 없던 상황에서도 뻔한 MMO 게임을 개발할 자리를 찾기는 그리 어렵지 않아 비슷한 게임을 여러 번, 서로 다른 사람들과 서로 다른 방법으로 개발하는 과정을 견딜 정신력만 있다면 향후 수 년 동안에 걸친 직업적 안정성을 얻을 수 있는 시대였습니다.
상황이 이렇다 보니 모든 프로젝트가 항상 명확한 목표를 가지고 있는 사람들에 의해 지탱되지도 않았고 또 항상 어느 정도 의미 있는 개발 경험을 가진 사람들에 의해 운영되지도 않았습니다. 스폰서는 회사를 통해 우리들에게 시장에서 유의미한 경제적 성과를 달성한 게임을 가리키며 그와 유사한 결과를 개발하라는 것 이외에는 별다른 요구사항을 제시하지 않았고 우리들 스스로도 그 정도 요구사항을 인지한 채 개발을 시작할 뿐이입니다. 어차피 우리들도 그 흔해 빠진 접미사를 붙인 게임을 만들기 시작했는데 어차피 우리들이 만들고 있는 게임 역시 고객들의 오랜 시간 투자를 요구하는 MMO 장르였고 명확한 목표가 없었으니 남들이 이미 만든 온갖 기능을 붙이지 않을 이유를 찾을 수 없었으며 어느 정도 시야를 좁힌 고객들을 대상으로 하지도 않았기 때문에 소위 백화점식 게임을 개발하는 것 이외에는 선택의 여지가 없었습니다. 이런 상황이다 보니 경영진을 대상으로 한 보고에 항상 나오는 키워드는 ‘엣지’였습니다. 어릴 때는 다른 제품과 비교한 엣지를 확보하고 이를 기반으로 게임의 나머지 부분과 탄탄한 연관을 가진 게임을 설계하는 일이 우리의 목표라고 생각했고 또 종종 n%의 법칙이라는 대부분은 익숙한 경험을 주지만 동시에 그 일부만 특별한 경험을 줄 때 고객들로부터 유효한 경제적 성과를 달성할 수 있다는 이론과 잘 어울린다고 생각합니다. 하지만 우리들에게 그 모호한 엣지가 필요했던 이유는 이를 제외한 나머지 부분은 남들과 똑같았기 때문입니다.
팀원님들과 술을 마시다가 문득 제 이력서에 적혀 있던 어떤 프로젝트에 대한 질문을 받았습니다. 실은 이 날 점심때 질문을 받았는데 있다가 술 마시며 이야기하자고 답변을 미뤘습니다. 그 프로젝트는 이전에 잘 알려진 전작의 후속작이었고 외부에는 나름 차근차근 개발 되어 가고 있다고 알려져 있을 뿐 아니라 한번은 유명한 이벤트에 영상과 플레이어블을 공개해 호평을 받았습니다. 이 게임이 돌아가는 모습을 본 사람들은 그 회사가 게임을 잘 뽑았다며 시장에서 꽤 좋은 성과를 거둘 수 있을 것 같다고 말하곤 했습니다. 그런데 저는 그런 좋은 결과를 만들어내고 있는 프로젝트를 떠났다고 제 이력서에 적어 놓았기 때문에 궁금해하지 않을 수 없었을 겁니다. 이런 이력은 나쁜 평가를 받기 쉽습니다. 외부에서 볼 때 잘 돌아가고 있는 것 같은 프로젝트로부터 이탈한 기록은 이 사람이 내부에서 뭔가 문제를 일으켰기 때문이라고 해석될 여지가 크기 때문입니다. 저에게 질문을 하신 분 역시 그런 완전히 멀쩡한 플레이 영상과 플레이어블을 공개한 프로젝트라면 아무리 힘들어도 조금만 더 버티면 런칭 할 수 있을 텐데 왜 런칭으로부터 그리 멀어 보이지 않는 시점에 프로젝트로부터 이탈했는지 궁금해 하고 계셨습니다. 혹시 제가 도저히 함께 일할 수 없는 싸이코라 팀에서 쫓겨났다는 사실을 숨기고 있을른지도 모릅니다.
저는 그 프로젝트에서 겪은 경험을 앞에서 이야기를 시작하며 소개한 2천년대 초반의 ‘_온라인'이라는 접두사를 공유한 수많은 게임들이 목표 없이 출시되던 시대에 흔히 겪을 수 있던 요구사항이 불분명한 프로젝트의 전형적인 사례라고 평가했습니다. 이전 시대에는 초기 온라인 시장에서 의미 있는 성과를 거둔 몇 가지 서로 다른 MMO 게임을 복제하는데 초점을 맞춰 영혼이 없이 개발해야만 임무를 완수할 수 있을 때가 있다 같은 생각을 하며 개발했는데 이 때 프로젝트 내에서 기획팀이 가장 많이 받은 질문은 그래서 이 게임의 다른 게임과 차별점이 무엇인가 하는 점이었습니다. 일단 개발을 시작했고 여느 MMO 게임과 비슷한 결과를 만드는데 초점을 맞춰 마일스톤 목표를 설정하고 개발을 시작했지만 여전히 이 게임이 다른 게임과 다른 점이 확실하지 않았기 때문에 마일스톤 보고 시점이 다가오면 고위의사결정자들은 프로젝트 전체에 게임의 엣지가 무엇인지 계속해서 질문하곤 했고 우리들은 그저 남들과 똑같은 게임을 만들던 자아로부터 잠깐 분리되어 우리가 가진 남들과 다른 차이점을 쥐어짜는데 열중하곤 했습니다. 마일스톤마다 우리들의 목표는 이미 다른 일이 끼어들 틈 없이 촘촘하게 계획된 목표를 달성하는데 초점을 맞추고 있었는데 이 목표들은 이미 다른 게임에 뻔히 있는 온갖 요소를 우리들이 바닥부터 개발하는 것들입니다. 애초에 남들과 비슷한 제품을 만들고 있는 마당에 남들과 차별화된 요소를 동시에 우리들 스스로가 생각해야 하는 상황은 전반적으로 그리 잘 동작하지 않습니다.
요구사항이 불분명한 프로젝트는 보통 타겟으로 삼은 명백한 게임이 있고 이를 복제하는데 초점을 맞춰 프로젝트를 시작합니다. 술자리에서 질문을 받은 그 게임 역시 원작이 있었기에 프로젝트의 초점은 그 원작을 복제하는데서 시작하게 됩니다. 초기에 팀을 빌딩하며 핵심 멤버들이 모이자 원작에서 고객들에게 강렬한 인상을 주었다고 알려진 부분을 우리가 새로운 엔진, 새로운 개발 기반에서 재현하기 시작합니다. 우리들이 그 경험을 제법 잘 만들어낼 수 있다는 사실을 경영진에게 증명하자 본격적으로 팀을 빌딩하기 시작했고 또 동시에 본격적으로 마일스톤 목표가 찍히며 개발이 진행됩니다. 초반 마일스톤은 원작을 새로운 플랫폼에 재현하는데 초점을 맞췄는데 사실 현대에 스스로 미들웨어를 개발하지 않는 회사들의 대규모 개발에 사실상의 표준으로 자리 잡은 언리얼 기반으로 개발하는 이상 원작과 다른 플랫폼을 타겟으로 개발하더라도 기술적으로 별다른 차이는 없었습니다. 타겟 플랫폼의 차이는 인터페이스나 자동 기능의 구현 수준 정도의 차이를 만들 뿐입니다. 그렇게 원작의 인상 깊은 경험을 우리들의 기반 위에 재현하고 이 경험 사이를 연결하는 나머지 기반을 개발해 나가는 사이에 시간은 순식간에 흘러갔는데 나름 순조롭게 개발되고 있어 전반적으로 나쁘지는 않았지만 경영진은 우리들에게 지속적으로 원작과 차이를 주문하기 시작합니다.
애초에 다른 게임, 여기서는 원작과 거의 같은 경험을 제공하는데 초점을 맞춰 개발하기 시작한 프로젝트가 갑작스레 원작과 다른, 또 시장에 이미 출시된 다른 게임과 다른 ‘엣지’를 갑자기 만들어 게임에 적용하려면 어떻게 해야 할까요. 가장 흔한 접근은 일단 시장에 이미 출시된 다른 게임들을 살펴본 다음 이들이 고객들로부터 좋은 평가를 받는 부분, 그리고 우리들 스스로 좋다고 생각하는 점을 가져오는 것입니다. 가령 시장에서 모바일 리니지 시리즈가 엄청난 경제적 성과를 거두고 있었는데 우리는 이미 원작을 모바일 기반으로 개발하며 모바일 환경에서 고객들에게 원작과 비슷한 수준의 집중과 조작을 요구할 수 없었기에 다양한 자동 기능을 준비하고 있는 상황이었습니다. 우리는 우리 나름대로 해석한 자동 기능을 준비한 상황이었는데 게임에 엣지를 요구 받기 시작하며 맨 먼저 일어난 일은 원작, 그리고 그때까지 우리들이 개발하던 게임에는 없었던 모바일 리니지 방식의 자동 개념을 도입하는 것입니다. 모바일 리니지 시리즈는 이제 강한 피로감을 느끼게 만드는 지경에 다다랐지만 개인적으로 이들은 게임의 여러 측면이 ‘그렇게 만들어질 수밖에 없는 결과’로 업계에서 게임디자인을 업으로 삼는 사람 관점에서 ‘아름답다'고 말할 수 있는 몇 안되는 결과입니다. 이들을 구성한 여러 규칙, 인터페이스, 전투 메커닉, 성장 시스템, 경쟁 요소 등은 각각이 서로 지독하도록 긴밀하게 연결되어 완전한 경험을 만들어내고 있습니다. 이들로부터 어느 한 부분을 복제해 오려면 지금 무슨 일을 하고 있는지 정확히 알아야만 합니다.
공개적으로 모바일 리니지를 복제할 때 정신을 바짝 차리지 않으면 안된다는 사실을 설명하려 할 때 종종 드는 예시를 인벤토리 인터페이스 설계 철학에 설명한 적이 있는데 모바일 게임에서 인벤토리, 캐릭터 정보 인터페이스가 화면 전체를 가리게 만들어도 될지, 그렇지 않을지를 결정하려 할 때 우리들이 무엇을 복제하고 있고 이들이 왜 그런 선택을 했는지 이해하지 못하면 이상한 결과를 만들게 됩니다. 가령 방금 소개한 인벤토리 사례에서는 게임이 유저에게 지속적으로 항상성을 유지하도록 강요합니다. 이 때문에 유저는 인벤토리에 다양한 기능을 수행하는 주문서 아이템과 포션 아이템을 가지고 있어야 하고 이들을 필요할 때 즉시 사용하고 또 항상성 유지를 위해 일부 포션은 계속해서 자동으로 사용되도록 해야 하며 이들의 잔여 수량과 적용 상태를 게임 내내 계속해서 관리하고 있어야 합니다. 이를 위해 인벤토리 인터페이스는 인게임 화면을 계속해서 볼 수 있는 상태에서 조작할 수 있어야 하기 때문에 전체화면을 사용해서는 안됩니다. 이런 사실을 이해하지 못한 채 별 생각 없이 ‘예쁘게 보일 생각으로’ 전체화면을 사용하는 인벤토리 인터페이스를 만든 다음 시장에서 큰 성공을 거두고 있는 모바일 리니지 시리즈의 플레이를 복제하려고 하면 분명 어지간한 기능을 가져와 구현했는데도 비슷한 플레이를 만들어낼 수 없는 상태에 빠집니다. 이 때 우리들이 무엇을 복제했는지, 복제한 메커닉이 왜 그렇게 만들어졌는지, 또 그 메커닉을 지탱하는 여러 인터페이스가 어떻게 동작하는지 잘 모르고 있다면 분명 기능은 가져왔지만 제대로 동작하지 않는 게임을 만든 채 출시해 실패할 수밖에 없습니다.
요구사항이 불분명한 프로젝트를 계속해서 개발하다 보면 이렇게 원작을 포함한 다른 여러 게임으로부터 별 생각 없이 가져온 여러 요소들이 조합되어 일단 돌아가는 것처럼 보이지만 막상 본격적으로 성장 경험을 만들려고 보면 잘 동작하지 않는 상태가 되기 쉽습니다. 여기서 곤란한 점은 이들이 왜 예상한 대로 동작하지 않는지, 또 왜 이들이 어떤 한 가지 맥락을 통해 통일성 있게 묶이지 않는지, 그리고 이 상태를 빠져나오려면 무엇을 해야 하는지 눈치채기 어렵다는 점입니다. 매 마일스톤은 계속해서 돌아오고 마일스톤 계획은 이미 욱여 넣어야 하는 온갖 새로운 기능으로 가득하며 이 기능들은 우리들 스스로의 요구사항이 불분명한 관계로 각각의 시점에 시장에서 의미 있는 성과를 거두고 있는 게임으로부터 가져온 여러 메커닉들로 가득합니다. 이런 상황에서 경영진부터 시작해 일선의 실무자들에 이르기까지 마일스톤 계획을 달성하는데 집중하고 있기 때문에 이들이 모여 개발한 여러 기능이 조합된 게임이 예상한 대로 동작하지 않는다는 사실은 쉽게 무시되며 이 상태를 극복할 임무는 주로 기껏해야 엑셀 테이블에 기반해 숫자를 넣기에 바쁜 밸런스 디자이너들에게 맡겨집니다. 실상은 근본적으로 우리들이 매 마일스톤마다 그 시점의 아무 게임으로부터 가져온 아무 메커닉들이 조합된 이 상태가 합쳐져 갈 때 이들 전체의 경험을 관통할 아무 요구사항도 없었기에 이들이 의도에 맞게 동작하는지를 전체적으로 평가할 기준조차 불분명합니다.
요구사항이 불분명한 프로젝트는 매 마일스톤 목표가 그 시점에 공개된 게임의 기능을 복제해 오는 계획으로 가득 차 있지만 만약 이렇게 메커닉을 복제해 오기를 박복하기만 하면 된다면 사실 게임디자인 관점에서 어려운 일은 아닙니다. 그저 이미 동작하는 다른 게임을 직접 만져본 다음 이를 역기획 해서 우리 시스템에 맞는 설계를 제출하기만 하면 되기 때문입니다. 하지만 이 일은 예상보다 훨씬 복잡해지는데 이유는 상당 기간에 걸쳐 서로 다른 여러 게임으로부터 그때그때 복제해 온 여러 메커닉들은 미래에 새로 복제해 올 예정인 메커닉과 근본적으로 호환되지 않을 때가 많기 때문입니다. 가령 이전에 복제하려고 한참 만져보던 어떤 모바일 게임은 그 프로젝트를 리드하고 있는 분이 어떤 매체와 가진 인터뷰에서 모바일 게임에 만연한 자동 기능 없이 전투 본연의 재미를 추구하는데 집중했다고 말했지만 우리들이 만져본 그 게임은 모바일 리니지 시리즈의 전투 매니지먼트 개념을 채용하면서도 동시에 자동전투 기능이 없어 직접 모든 조작을 입력해 전투 해야 하는 상황에서도 캐릭터의 항상성을 계속해서 유지해야 하는 이상한 게임이 되고 말았습니다. 새 마일스톤 목표에 포함된 기능이 이전에 개발한 기능과 호환되지 않는다면 새 기능을 개발하기만 하면 된다고 생각할 때 예상했던 비용은 이전에 개발한 기능을 뜯어 고치는 비용을 포함해 급격히 증가하는데 만약 고위의사결정자들이나 경영진이 이런 상황을 이해하지 못하면 어쨌든 마일스톤 목표를 달성하기 위해 각각의 메커닉이 서로 합쳐진 상태에 맞춰 온전히 다듬어지지 않은 채 마일스톤이 마감되기도 합니다. 그러면 다시 게임 전체에 걸친 경험을 만들 수 없는 상태를 되풀이하게 됩니다.
요구사항이 불분명한 프로젝트의 또 다른 문제는 언제, 어떤 상태가 되면 게임을 완성했다고 평가할 수 있는지 알 수 없다는 점입니다. 지금까지 계속해서 매 마일스톤마다 그 시점에 시장에 이미 출시된 게임들이 적당한 성과를 내고 있어 보이는 이유, 그럴싸해 보이는 기능 따위를 복제하는데 집중해 왔기 때문에 우리가 매 마일스톤마다 마무리하고 있는 빌드가 전체 개발 과정 중에서 어느 단계에 와 있는지 판단할 근거가 없습니다. 여전히 새로 추가되는 기능과 이에 의해 망가져 고쳐야 하는 이전에 개발한 기능이 공존하며 이들을 통합된 경험으로 만드는, 사실은 개발을 시작할 때 정의된 다음 상황에 따라 업데이트 되어야 했을 바로 그 일은 여전히 사실상 별다른 권한이 없는 밸런스 디자이너들에게 맡겨져 있을 뿐입니다. 이런 상황에서 게임의 일부분을 체험할 수 있는 빌드를 만들면 게임이 전체적으로 일관된 맥락에 기반한 경험을 주지 못한다는 사실을 쉽게 숨길 수 있어 프로젝트가 처한 곤란한 상황을 전혀 말하지 않으면서도 시장의 기대를 받을 수 있습니다. 이 빌드는 게임의 일부분만을 체험할 수 있으므로 지속적인 플레이에 따라 성장이 올바르게 동작하는지, 또 게임의 여러 넛지와 허들이 올바르게 동작하는지, 캐릭터가 일정 수준 이상 성장했을 때 지속적으로 게임에 시간을 투자할 만한 적절한 목표와 이유를 제공하는지 알 수 없고 또 알 필요도 없습니다. 그저 체험 가능한 부분이 얼마나 큰 임팩트를 주는지에 초점을 맞추고 있을 뿐입니다.
그래서 커다란 게임 전시회에 공개된 멋진 영상과 임팩트 있는 플레이를 체험할 수 있는 대단한 빌드가 있음에도 불구하고 팀을 떠나는 결정을 한 사람이 나쁜 평가를 받을 수 있습니다. 실상은 몇 년에 걸쳐 얼마나 만들었는지 평가할 수 없는 상태의 게임을 계속해서 개발하고 있고 몇 년에 걸쳐 비슷한 부분을 반복해서 개발하고 있으며 그 과정에서 이전에 만들어진 기능을 함께 수정해야 하는 비용을 예측하지 못해 늘어난 개발비용을 기간 내에 소화하기 위해 초과근무를 일삼고 목표를 알 수 없어 개발해 낸 기능이 게임의 나머지 부분에 맞물려 올바르게 동작하는지 평가할 수 없는 상황을 겪다 보면 어지간한 사람들은 결국 망가지게 됩니다. 팀이 서서히 바뀌어 가는 이야기에서 소개한 대로 결국 팀에는 이 상황을 버틸 수 있는, 혹은 버텨야만 하는 종류의 사람들이 남게 됩니다. 그렇다고 뭔가 문제가 생기지는 않습니다. 여전히 팀은 외부에 게임 전체의 일부를 체험할 수 있는 빌드를 낼 수 있고 이 빌드는 그 경험에 한해서는 고객들에게 임팩트를 줄 것이 분명하며 그때그때 추가한 온갖 기능은 이들을 영상으로 만들 때 극도로 매력적으로 보일 수 있습니다.
여전히 마일스톤 목표는 탄탄하게 준비되고 목표가 완수될 때 빌드의 상태 역시 예측할 수 있으며 마일스톤이 완료될 때 팀 내에서도 마치 체험 빌드를 플레이 하는 것처럼 게임의 일부만을 테스트 하기 때문에 어떤 문제도 일어나지 않습니다. 다만 아무리 오랜 기간이 흘러도 게임은 완성되지 않으며 관리자 입장에서는 입사와 퇴사를 계속하는 사람들을 온보딩 시키며 비슷한 기능을 계속해서 개발하기를 반복해야 하며 이미 가득 찬 채로 도착하는 마일스톤 계획을 살펴보며 이 개발을 완수하더라도 게임은 결코 완성되지 않고 또 다음 마일스톤을 시작하기 전에 우리가 만든 빌드를 바라보는 대신 시장에 나와 있는 다른 게임을 살펴보고 또 어떤 기능을 복제해 와야 할 지 고민하기를 반복하는 상황을 각자가 감내하고 있을 뿐입니다. 결국 저 역시 상황을 견디지 못하고 프로젝트를 떠나기로 결정했는데 이 결정은 밖에서 볼 때 그렇게 대단한 체험 빌드를 만들어낸 프로젝트를 떠나는 행동으로 비치기 때문에 좋지 않게 해석될 수밖에 없습니다. 억울하기도 하지만 다른 한편으로는 왜 그렇게 보일 수밖에 없는지 역시 이해합니다.
이런 프로젝트는 종종 오랜 세월에 걸쳐 막대한 개발비를 소모한 다음 취소되거나 흔히 우리들이 ‘출시 당했다’고 표현하는 게임의 온갖 기능이 전혀 마무리되지 않은 채 시장에 나와 온갖 괴상한 동작을 일삼으며 고객들에게 커다란 놀라움을 선사한 다음 어느 날 조용히 앱스토어에서 사라지는 것이 보통입니다. 또 어떤 경우에는 10년의 밤에 소개한 대로 불굴의 의지로 이 모든 상황을 돌파한 끝에 게임을 출시하는데 성공하기도 하고 또 다른 게임은 개발을 시작한 다음 7년 동안 개발한 끝에 출시에 도달한 다음 의미 있는 경제적 성과를 거두기도 합니다. 그러니까 이런 개발 방법이 잘못되었다고 보기는 어렵습니다. 다만 세상에는 이런 개발 방법을 오랜 세월에 걸쳐 감당해낼 수 있는 사람과 그렇지 않은 사람이 있으며 적어도 저는 이를 감당해내기 어려운 사람이라는 사실을 지난 몇몇 프로젝트 경험으로부터 알게 되었습니다.

이 설명을 마치고 술을 한 잔 더 마신 다음 혈중 니코틴이 부족해진 사람들이 단체로 자리를 떠나 휑한 테이블과 마주한 채 빈 잔에 또 술 한 잔을 따라 다른 사람들보다 술 한 잔을 더 마신 다음 이 이야기에 등장한 실제 회사 이름, 프로젝트 이름을 말하지 않은 채 요구사항이 불분명한 상태로 개발되는 전형적인 프로젝트에 대한 이야기를 한 번 하기로 마음 먹었습니다.
이번 53호에는 지난 2주간 공유한 이야기를 함께 보내 드립니다.




추가로 며칠 전 출근하다 마주친 친구 사진을 보내드립니다.

그럼 또 2주 뒤에 뵙겠습니다. :)