• 상위항목 : 이민혁

이민혁이 진행했던 슈퍼레디 프로젝트와 관련한 항목.

프로젝트 '슈퍼레디'
수행기간	2014.11.01 ~ 2015.06.19 1)
플랫폼	iOS, Android 2), Web Frontend3) NodeJS 4), MySQL, Linux Based Cloud Server
수행인원	멘토 한대희, 조영규, 이해찬, 이민혁, 김종욱5), 서정민6), 장현우, 이경문

• 주의 : 이 프로젝트는 참여를 중지한 이후에도 팀이 계속 존속하기 때문에 팀의 지속성을 저해할 수 있는 내용은 기록하지 않습니다.

1단계 프로젝트 였던 Team RRGames의 프로젝트를 마친 후, 이때의 구성원 4인중 3인이 소프트웨어 마에스트로 2단계에 진출하였다. 프로젝트는 비교적 성공리에 마무리되었으나, 마에스트로 사무국의 정책⁷⁾과. 팀원과의 다른 방향성으로 인하여 각기 다른 프로젝트에 참여하게 되었다.

초창기 구성원 간 '미미박스'와 유사한 리뷰 및 테스팅 기반의 사용자 리뷰 컨텐츠 커뮤니티를 기획하였으며, 아이템 기획에 점차 변화가 생기면서, 리뷰의 컨텐츠 중 제일 호응도가 높은 것을 맛으로 판단하고 기획끝에 '선릉그집'서비스가 탄생하였다.

페이스북 페이지로 운영되었던 '내가 선릉에 그집 먹어봐서 아는데'	서비스 다이어그램

초기 서비스는 응모 기반의 '맛집리뷰'서비스를 목표로 하였다. 이것은 자영업 음식점과 소비자를 연결하는 플랫폼 서비스를 목표로 한것이며 아래의 흐름을 통해 생태계를 기획했다.

1. 자영업자의 쿠폰을 획득한 후, '베타테스트'응모 희망자를 서비스를 통하여 공모.
2. 소비자는 베타테스트 응모 획득 후, 해당 영업장에서 쿠폰메뉴 시식
3. 시식 후 리뷰 컨텐츠를 서비스 운영진에게 전달
4. 리뷰 및 피드백을 자영업자에게 전달한 후 리뷰 등재 여부 결정
5. 리뷰 등재시 홍보효과 달성

이 흐름으로 서비스를 2014년 12월 부터 2015년 1월까지 서비스를 시행하였다. 음식점을 운영하는 자영업자의 섭외와 고객 응모시스템을 확립하는 것이 관건이었던 서비스. 응모의 형태로 전달되는 쿠폰에 대해 소비자가 반응을 보였지만, 쿠폰 소비 완료 후 등재되는 리뷰에 대해서는 소비자들이 큰 흥미를 얻지 않았으며, 이에 따라 초기 기획했던 리뷰 컨텐츠를 통한 비즈니스 모델 확립 아이템이 위태로워지게 되었다. 반향을 일으키기 위해 페이스북의 유료 홍보채널을 활용⁸⁾ 하였으나, 서비스 지속시 적자가 예상되어 쿠폰이벤트 5회 진행 후, 서비스를 지속할 수 없다고 팀 내에서 판단하게 되었다.

유료 홍보를 진행하지 않으면 리뷰의 컨텐츠 도달 성취도를 높이기 쉽지 않다.

따라서 기획을 Pivot하게 되었는데, 이때는 고객에게 보여지는 컨텐츠의 '질'적 면모보다 '가격(양)'적 면모에 주목하게 되었고, 장시간 토론 결과 'SuperReady'가 태어나게 되었다.

이 서비스를 운영하면서 얻었던 교훈으로는,

• 자영업자와 소비자를 이어주는 플랫폼으로서의 서비스 구축의 어려움.
• 5차 쿠폰 이벤트를 진행해보면서 리뷰 컨텐츠 변조에 따른 인터페이스 A/B 테스트.
• 린 스타트업 기법에 입각한 '개발하지 않은 원시적 형태의 서비스'를 통한 프로토타이핑.
• 페이스북 인사이트 정보를 통한 SNS 홍보의 관리.

정도 되겠다.

SuperReady의 로고

이후 지속가능한 서비스에 대해 고민 하던 중 중/소규모 청과물 마트 등에서 배포하는 전단지에 대해 소비자의 수요가 있음을 주목한다. 인터넷 커뮤니티 등지에서 특정 구역에서 운영하는 '마트'의 전단지를 업로드 해 줄것을 요구하는 수요와, 대형 마트 체인에서 자체 웹서비스를 통해 전단지 정보를 배포하고 있음을 확인하였다.

하지만, 전단지의 배포방법은 신문지 첨부물의 형태 등 원시적인 형태이기 때문에, 광고의 도달율이 높지 않다는 점에 착안하고, 전단지 배포에 따른 전단지 제작비와 인건비가 높다라는 점에 착안하여 웹서비스화의 가능성을 포착하였다.

SuperReady라는 이름은 최초 서비스 기획 1개월 이후 지어졌다.

SuperReady의 개략적 서비스 구조.

SuperReady의 서비스 구조는 이전 선릉그집과 크게 다르지 않은데, 고객과 자영업자사이에 플랫폼의 역할을 하는것에서 벗어나지 않았기 때문이다. 이 플랫폼에서 양 끝에 있는 고객들에게 전달하려는 가치는 다음으로 정리될 수 있다.

• 소비자에게는 기존 전단지 대비 훨씬 동적이고 최신화된 전단지 정보를 전달한다.
• 자영업자에게는 실시간으로 전단 행사 정보를 소비자에게 전달하고 수치화된 광고효과를 화면으로 전달 받는다.

다만 소비자에게 전달하는 정보는 '리뷰'에서 '가격정보'로 바뀜에 따라 전달하는 정보가 주관적인 성격에서 객관적인 성격으로 바뀌었다. 자영업자는 소비자에게 보여주기 위한 정보의 인스턴스를 '전단지'라는 매개체를 통해 전달한다. 그러니까, 종이 형태의 정적인 형태가 아닌, 어플리케이션 형태의 '동적인' 전단지가 되는것.

'신문'등의 간행물의 첨부물 또는 인력을 통해 전달되는 전단지 정보가 담고 있는 가격정보의 가치에 대비해서 '도달율'자체가 높지않음을 문제점으로 지적하고, 어플리케이션을 통해 전단지 정보에 사용자가 능동적으로 정보에 접근 할 수 있게 한다. 어플리케이션은 전단지 대비, 사용자에게 바로 도달할 수 있는 장점이 있고, 전단 및 마트행사 정보를 실시간으로 갱신할 수 있는 등 활용의 여지가 높기 때문.

프로젝트 참여기간 까지의 서비스 기술 구조

서버와 클라이언트는 각 분야의 개발을 담당할 팀을 구성하여 독자적으로 개발을 진행했고, 이에따라 클라이언트와 서버에 따라 적용된 기술이 다양한 폭으로 분화되어있다. 각 영역의 올바른 정보 교환을 위해서 당연하게도 데이터 교환 규약은 JSON에 기반한 REST 통신으로 정해졌다.

서버의 논리는 Node JS위의 Express 프레임 워크에서 구현하였다. Database는 ER다이어그램에 기반한 데이터 모델링 이후 MariaDB에 적용하였다. 이후 사용자 토큰 등 캐시처럼 사용하는 데이터는 REDIS의 힘을 빌렸다. Jenkins / Grunt 등의 도구를 활용해서 배포 및 테스팅의 자동화를 도모했고, 코드 관리를 위해 Git브랜치를 Develop / Master / Release 단계로 세분화 했다. 따라서 안정적인 코드의 배포와 개발 및 테스팅이 가능하게 만들었다.

이미지 변환과 업로드를 담당하는 이미지서버를 따로 두었고 이 역시 Node JS를 통해 구현했다.

클라이언트 화면

소비자는 클라이언트에 접근 해서 마트에서 제공하는 전단 정보를 실시간으로 받아볼 수 있다.

아래는 사용자에게 제공되는 기능들.

• 자신과 가까운 곳의 마트 목록 확인.
• 마트별 전단 정보 확인
• 관심상품 목록 저장 후 오프라인 쇼핑에 활용.
• 관심상품 알람설정.⁹⁾

자영업자용 웹 관리자 화면

자영업자에게는 마트의 행사 정보를 관리하여 소비자에게 정보를 실시간으로 전달할 수 있는 인터페이스를 제공하고자 노력했다. 이 인터페이스는 '웹'으로 구현되었고, Node JS와 기타 JavaScript 라이브러리 들이 활용되었다.

사용한 라이브러리와 그 목적들 쓰자면,

• RequireJS : 프론트엔드 페이지별 요구되는 라이브러리 및 기능이 다르고 사용하는 라이브러리가 다양하기 때문에 이들의 namespace를 관리하기 위한 라이브러리.
• VueJS : MVVM 모델에 입각하여 프론트 페이지를 구현하도록 도와주는 라이브러리.
• UIKit : Bootstrap에 비견될 수 있는 뷰 템플릿. View의 독립적 구현을 위해 후에는 '거의' 걷어내었다.
• JQuery : 동적으로 정보를 보여주는 AJAX를 쓰기위해 도입.

이렇게 구현된 웹 인터페이스는 자영업자에게 아래의 기능을 제공한다.

• 자신 마트 정보의 관리. 응당 있어야 하는 기능.
• 행사 전단 정보의 CRUD. 이때 행사 전단정보는 상품정보와 상품묶음으로 행사 단위라 할 수 있는 '캠페인'을 포함한 의미.
• 마트 상품의 행사 정보를 소비자에게 Push 알림 전달. 하지만 프로젝트 기간 중에는 구현되지 않았다.

소비자에게 드러나는 것은 아니지만, 행사상품들의 묶음을 캠페인으로 규정하고, 캠페인 단위로 행사의 발생과 진행, 소멸을 관리 할 수 있도록 했다.

초기 서버는 Cafe24의 Virtual Linux Instance¹⁰⁾에서 동작했지만, 서버 인스턴스의 성능과, Scalability에의 대응문제 등을 고려하여 후에 Cloud Server인 Windows Azure로 이전하였다.

• 스크럼의 본론에 대해서는 애자일과 스크럼을 참고.

팀 프로젝트를 운영하기 위해 애자일 개발 방법론 중의 하나인 스크럼을 도입하였다. 스크럼의 효과를 획득하기 위해서 '온라인'으로 작업하는 시간보다는 '오프라인'에서 작업하는 비중을 늘리고, 오프라인 스크럼보드를 활용하였다.

보통 온라인에서 스크럼 보드를 활용할 필요성이 있을 경우에는 Trello를 활용하지만 여기에서는 사용하지 않았는데, 팀원 모두 오프라인에서 만나는 것이 팀의 의사소통에 도움이 된다라는 것에 동의하였기 때문. 따라서 스프린트의 진행 또한 한 장소(여기서는 마에스트로 센터)에 만나서 진행 했으며 규정된 시간은 오후 3시 ~ 9시.

스크럼을 진행하면서 이민혁은 스크럼 마스터를 담당했다. 스크럼 마스터에 대한 내용은 하단에 서술.

• 스프린트 팀이란 스프린트를 진행하는 구성원들을 의미하며 4~7명의 인원으로 구성된다. 개발자/스크럼 마스터/프로덕트 소유자로 구성되어있다.
• 프로덕트 소유자(Product Owner)는 스프린트 팀에게 필요한 요구사항을 전달하기 위해 프로덕트 백로그를 작성한다.
• 스크럼 마스터 매일 스프린트 회의를 개최하고 팀 구성원들의 진도를 파악한다. 본래 스크럼 마스터의 존재는 팀 스프린트 진행의 방해요소를 제거하고 자기조직화를 할 수 있도록 도와주기 위한 존재. 여기서는 프로젝트 팀과 '마에스트로 사무국'간의 가교역할을 해서 예산 획득과 문서처리와 같은 행정요소를 해결하는 역할을 수행한다.

본래 스프린트 팀 / 프로덕트 소유자 / 스크럼 마스터 는 구분되는 역할 이지만, 팀의 개발진도 문제상 모든 역할자들이 개발을 담당하도록 하였다.

스프린트 팀과는 별개로 6인의 팀 체제에서 3개의 서브 팀을 구성했다.

• 서버팀 : 팀장과 이민혁이 속해 있고, 전체적인 서비스 및 데이터 모델링 기획을 담당하고 서버 프로그래밍을 주도함.
• 안드로이드 클라이언트 팀 : 안드로이드 클라이언트 개발.
• 아이폰 클라이언트 팀 : iOS기반 클라이언트 개발 및 UX 요소 기획.

스프린트가 진행되는 매일마다 스크럼 마스터의 주도하에 스크럼 회의를 진행하였다. 스크럼 회의는 스프린트 시작 전에 모든 스크럼 팀원들이 참여하여 수행하였고, 회의 내용은 구글 드라이브에 문서화하였다.

스프린트 팀원들은 스크럼 보드에 스프린트 진행상황을 점검하여 태스크를 할일/진행중/완료 칸에 옮겨놓고, 기타 이슈사항들을 팀원들과 공유한다. 스크럼 마스터는 팀 내의 요구사항과 장애물들을 접수하여 스프린트 진행에 차질이 없도록 한다.

최초 스프린트 시작시 스프린트 간격은 2주였고, 스프린트 첫날에 스프린트 계획회의, 마지막날에 스프린트 리뷰/회고를 진행했다. 스프린트 회차가 누적두면서 점진적으로 스프린트 진행방식을 변동시켰다.

• 스프린트 계획 : 프로덕트 백로그에 기반해서 스프린트에 필요한 태스크를 '포스트 잇'등으로 기록하고 '할일'칸으로 기록한다. 스프린트 백로그 마다 Man-Date 시간을 명시한다.
• 스프린트 리뷰 : 스프린트 종료 후 스프린트 진행도를 점검하고 완성된 프로덕트를 고객에게 시연하고 평가받는다.
• 회고 : 팀원들 끼리만 참여하는 회의로 프로젝트 진행 했을때의 분위기, 장애물, 교훈 등을 이야기한다.
• 스크럼 보드 : 스프린트 계획 회의시 스프린트 백로그를 모두 게시하고, 스프린트 진행 상황에 따라 적절한 칸으로 태스크를 재배치 한다. 여기서는 태스크를 할일 / 진행중 / 완료에 구분하고, 기타 돌발적인 이슈들을 계획에 없던 일에 명시 했으며, 번다운 차트에 스프린트 진행상황을 기록했다.

스프린트의 진행상황은 '스크럼 보드'에 기록한다.

아래는 각 스프린트 회차 마다의 활동내역을 정리.

최초 스프린트 진행시에는 스프린트 백로그 하나의 Man-Date가 2 이상을 초과 하는 등 '태스크'를 세분화 하지 못했고, 이에따라 개인이 맡고 있는 태스크 진도를 투명하게 파악하는데 문제가 있었다. 게다가, 스프린트 태스크 숫자 뿐 아니라 그 내용 또한 추상적으로 적혀있었기 때문에, 개인이 태스크를 수행하는데에도 어려움이 있었다. 결국 첫 스프린트의 진행도는 약 70% 선에서 마무리 되었다.

이후 스프린트 진행에 따라서 스프린트 백로그를 세분화하고 올바른 태스크 수행 예상시간을 산정함에 따라 3차 이후 부터는 스프린트 진행이 안정권에 접어들었다.

최종발표는 2015년 6월 19일에 진행되었다. 대체로 창업할 의지를 발표 내용중에 많이 피력했기 때문에 심사위원들의 평가 '어조'는 대체로 긍정적이었던 분위기.

아래는 평가 내용.

• 이미지 정보를 처리하는 아키텍쳐를 중간발표 대비 고도화 시키긴 했으나, 채팅서버와 같은 실시간 서비스가 아닌 특성상 비동기적 처리를 통해 이미지를 변환하고 저장하는것은 다소 오버스펙이지 않은가 하는 평.
• 서비스를 운영하는데 좋은 팀이라는 것을 어필하는것이 굉장히 중요하다. 꾸준하게 스크럼 개발방법론 등을 적용하고 기록을 남겨놓는 것이 큰 도움이 될 것이며, 현재까지 스크럼을 도입해 온 것은 긍정적인 부분.
• 사장님이 자신의 광고효과를 측정하는 것이 캠페인의 페이지뷰만 보이는것은 현재로서는 한계점이 보인다. 좀 더 여러가지 제반사항을 보여주는 시스템이 필요할 것.
• 스테이징 기법으로 코드를 세분화하고 배포와 테스팅을 자동화는 시도 자체만으로도 긍정적인데 꽤나 잘 적용한 것으로 보인다.

발표 종료일에 Yellow Mobile에서 아이템에 대한 간단한 미팅 시간을 가졌고, 여기서도 아이템을 평가받았으나, 여기서는 다소 혹평.

• '배달의 민족'이 현재 자리잡게 된 이유는, 자영업자의 프로세스를 크게 수정하지 않고 현재의 서비스를 정착시켰기 때문. 예를들어, 고객이 지금 플랫폼을 통해 주문을 하면, 필요한 경우 배달의 민족은 직접 전화로 주문을 해서 자영업자들이 주문을 접수할 수 있도록 했다. 당시에는 웃음받았지만, 자영업자들이 프로세스를 수정하지 않고도 배달의 민족이 자리잡게 만들수 있었던 한 부분이었다. 따라서, '플랫폼'서비스가 잘 자리잡기 위해서는 '자영업자의 프로세스'의 수정을 최소화 할 수 있어야 한다.
• 현재 전단지 정보를 업로드 하는 과정이 다소 '노동 집약적'인 프로세스. 이를 크게 줄여야 정보의 생명주기를 유지할 수 있고, 고객에게 신선한 정보를 줄 수 있다.
• 따라서 결론은, 프로세스를 받아들이는 '고객과' 프로세스를 만드는 '서비스 공급자'의 서비스 변화 정도에 대해서 밸런스를 잘 유지할 수 있어야 한다. 그리고 이것을 바꿀 수 있는 요소가 '기술'이 되는 것.
• 전단지 정보만을 단순히 소비자에게 전달하는 현재의 서비스 형태는 그리 매력적이지 않다. 퍼포먼스 측정이 분명하지 않은 점이 투자자들의 발목을 잡을 것. '배달'등의 시스템을 붙이는것이 자영업자들 입장에서 퍼포먼스를 측정하는데 도움이 될 것 같다.

솔직히 마음이 좀 힘들었어. 팀이 갖고 있는 가치관이, 멀리 떨어져서 박수 쳐줄순 있었지만 같이 끌고가서 내것으로 만들기엔 거부감이 있었어. 그래서 멀리 떨어져서 박수쳐주기로 했어. 멀리서보니 박수받을 만한 자격있는 팀이었어. - 프로젝트 종료 후 독백.

이후 팀은 존속하여 프로젝트를 강화하고, 이민혁은 프로젝트 팀을 이탈하여 취직준비를 하고 어쨌든 성공은 했다.

이 프로젝트를 통해 다음을 얻었다.

• Node.js와 Express 프레임워크를 통한 REST API 웹 어플리케이션 서버 개발.
• Git/ Github를 적극활용하여 Develop/Release/Test Branch를 통한 효율적인 코드관리.
• 위의 단위 브랜치들과 Jenkins를 활용한 빌드 및 배포 자동화와 스테이징.
• 애자일과 스크럼 개발 방법론이 무엇인지 알 수 있었다.
  • 스프린트 계획법에서 예상업무 백로그 정립과 소요시간 예측법 학습과 개선
  • 일일 스크럼 회의를 통한 업무 투명성 강화
  • 스프린트 결과 회의와 회고를 수행해서 다음 스프린트에 적극 반영하고 잘못된 내용을 반성한다.
• 고집이 있는 자기자신과 갈등하는 내모습.

팀 구성원이 5명이상이었고, 팀 내에서 적극적으로 스크럼을 도입해보자는 여론, 그리고 팀장의 린 스타트업 방법론에 따른 사업 전개에 따라서 팀 개발방법론으로써 스크럼을 도입했다. 스크럼 책을 통해 스크럼 시스템을 구성하고자 했으나 스크럼 자체가 '철학'에 비해 구현 사례를 타이트하게 적용하는 것을 권하지 않는 편이고, 팀마다 구현사례도 제각각이었기 때문에 고민이 많았지만, 결국 '일단 타이트 하게 적용해보고, 우리 실정에 맞게 변형을 가하자'라는 결론을 내고 스크럼을 도입하였다. 이렇게 된 데에는 '고민만 하느니 일단 해보고 생각하자'라는 실행력 위주의 사고가 영향이 있었고, 이는 꽤 긍정적으로 작용했다. 그리고 '오프라인'에서 만나서 스프린트를 수행한 것도 꽤 긍정적이었는데, 이는 스크럼에서 가장 강조하는 경험적 개발방법론과 자기조직화를 해내는 것이 오프라인에서 제일 효과를 크게 발휘 할 수 있었기 때문. 예를 들면, '오늘 점심 먹었냐'같은 사소한 질문도 오프라인에서 바로바로 나올 수 있고, 이러한 점은 팀원들 간의 '의사소통 진입장벽'을 낮추는데 큰 영향을 발휘 하기 때문이다.

다만, 오프라인 만남에서 의사소통을 많이 진행하기 때문에 실제 개발 진척은 스프린트 시간보다 비 스프린트 시간에 개인적으로 시간을 내면서 더 나아가게되는 경우가 더러 있었고, '개발 집중력'이라는 측면에 대해 고민해야 될 이유가 되기도 했었다. 실제로 개발을 할때 이민혁 같은 경우는 집중력이 발현되는 데 꽤 오랜 시간이 필요한 편인데, 질문이나 호출 등으로 집중력이 깨어져 버리면 이를 회복하는데 오랜시간을 소모하기 때문. 하지만 이후에는 시스템에 적응하면서 집중력이 필요한/필요하지 않은 태스크에 우선순위를 부여해서 효율적으로 업무를 수행하는 연습을 해볼 수 있었다는 점에서 긍정적이었다.

쉽지 않은 시간이었으나 팀과의 협업과 그 협업을 이끌어내는 도구, 그리고 도구를 통해 형성되는 문화를 체감하고 그 문화를 같이 만들어보는 연습을 해보았다는 점에서 긍정적인 경험이었다.

평소 웹개발과 인연이 없었으나, 팀의 주제가 서비스가 됨에 따라서 자연스럽게 웹 서비스를 개발할 기회가 생긴 탓에 웹 백엔드와 연관된 업무를 수행했다. 기실 안드로이드 어플리케이션 개발 경험이 있었으나, 팀원들과 개발 분야가 겹치는 문제가 있었고, 새롭게 배워보고 싶은 마음도 있었던 고로, 생소한 분야였던 백엔드 파트를 담당했다. 팔자에도 없는 웹개발… 인줄 알았더니 이것도 그냥 팔자였다. 처음에 JavaScript에서 제시하는 프로그래밍 패러다임 자체는 굉장히 생소했지만, 높은 생산성과 좋은 라이브러리들의 영향으로 금방 개발을 해낼 수 있었다. 사실 이부분은 이런 환경을 만들기 위해 팀장이 많이 고생한 부분.

별다른 연관성이 없었던 TossLab 스타트업 팀과 만날 기회가 있었는데, 'Jandi'라는 협업용메신저를 활용하는데, 이 서비스에 팀장이 피드백을 꾸준하게 보내면서 우연히 만남을 가질 기회가 생긴것. 서로 얻어갈 것이 많은 만남이었는데, 'Jandi'팀으로서는 개발자입장에서는 메신저 사용자 경험을 직접 대화를 통해 얻을수 있었고, 우리 팀은 선배 개발자의 스타트업 서비스 과정을 얻을 수 있었다. Jandi또한 개발자 3인에서 시작한 작은 스타트업이었는데, 이후 Seed 투자 등을 받으며 지속적으로 성장했고, 현재는 직원 40명 가량 재직중인 회사가 되었다.

팀의 미팅은 4월 말에 이루어졌으며, 안드로이드 및 서버 테크클리닉, Jandi 서비스 사용자 피드백 교환 등을 수행 했다. 이민혁은 팀의 경영및 기획을 담당한 양진호님과 스타트업의 운영및 팀 문화 조성에 대한 이야기를 나누었다.

팀장의 '적극적인'성격이 기회를 만들어 준 격.

팀의 방향성이 이민혁 개인과는 맞지 않다는 생각이 자꾸 들어서 내적갈등을 많이 겪었던 프로젝트. 마나를 많이 썼다고는 하지만 인간적인 갈등은 없었고 팀원들이 Leading에 잘 따라와 주었던 1단계 프로젝트와는 달리, 서로의 성격이 극명하게 달랐던 이번 프로젝트는 마나를 상당히 많이 사용한 편.

이러한 성격은 중간발표 연습 시간에 극명하게 드러났었는데, 대체로 당당함/자신감과 우리는 완성된 사람들입니다라는 어조의 팀장의 발표와는 달리, 이민혁의 발표는 저희는 더 발전할 겁니다, 여기까지 노력해봤습니다라는 약간 겸손한 어조. 팀장은 '형님, 우리는 더 배울게 없는 사람들인거에요'라며 설득을 했지만, 스스로 이에 대해 받아들이지는 못했고, 끝끝내 받아들이지는 못했다.

문제는 이러한 갈등점을 타인과 팀원들에게 잘 이야기 하지 못하고 스스로 감내하려고만 했다는 점. 프로젝트를 수행하는 동안 학교를 전혀 가지 않았던 고로 가장 많이 이야기를 나누었던 학교의 친구들을 만나지 못했고, 동기들은 졸업 후 취직했기 때문에 스스로 고립감을 가장 많이 느꼈던 시기.