[목표]
아마존 내용을 정리합니다.
담당자 선정(기능별은 하겠지만, 신경 분산체계를 위함이다.)
일정 관리.
할일을 선정합니다.
활동 시간대 정하기.
팀노션 정리하기.
알고리즘 구현 생각하기.
와이어프레임 그리기.
UX/UI 개선.
PPT 작성. (아키텍처, 기술적 챌린지)
13:00 ~ 14:00
여태 잠을 못잔것과 어제 5시에 자서 그런지 알람 소리를 못듣고 자버렸다….
급하게 학습장으로 와서 토스트를 먹으면서 어떤걸 하고 추가적인 AWS 권한을 부여했다.
14:00 ~ 17:30
와이어 프레임을 작성 중입니다.
팀원분들과 함께 어떻게 알고리즘을 구현해야할지 고민을 했습니다. 결론적으로 어떻게 할지 몰라서 코치님께 여쭤보고, 나는 어떤식으로 구현할지(실수 기준 가중치) 알아보기로 했습니다.
또한 와이어프레임을 구현하기 전에 플로우 차트를 그려보며 웹사이트의 페이지들이 뭐가 있는지 구상해보기로 했습니다.
와이어 프레임
메인페이지 같은 경우는 각자 생각을 구현하기로 했고, 담당 페이지를 정했습니다.
Welcome: 태용
Login/ Register: 진혁
Main, PR 분석, 커밋 선택 / 분석 페이지: 공용
마이페이지: 권호
시니어 페이지: 명석
히스토리 조회(DB): 윤호
오늘 PPT 구성을 해야합니다.
17:30 ~ 18:20
담당자 선정, 커피챗 신청, 활동시간 지정
담당자 선정
업무 분담의 효율성과 전체 흐름과 정리 담당자를 정하는데에 있습니다. 팀장이 전체 흐름을 관리할 경우 각 진행사항에 대해서 한명씩 이야기를 해야하고 인프라, 벡엔드, 프론트엔드, QA, 이슈 관리, DB를 모두 관리하면 효율성 저하가 될 수 있어 도입하였습니다. 그러나 모든 개발은 기능별로 종합적으로 합니다.(풀스택)
- 회의 기록(녹음): 회의 기록과 같은 경우에는 로테이션을 돌면서 담당합니다.
- Backend: 권호
- Frontend, QA, Issue: 명석
- DB: 진혁
- Infra(배포 및 CI/CD): 윤호
팀 활동 시간 선정
전체 평균을 따져서 10:30 ~ 24:00 을 팀 활동 시간으로 지정했습니다.
커피챗 내용 선정
코치님 질문 내용(슈퍼바이저의 PR의 과정이 어떻게 진행되는지?, 얼마나 많은 PR을 검토하는지, 불편한 사항은 무엇인지?, 깃 커밋 메시지의 형식이 어떻게 되는지? 등 팀원별로 준비.
18:20 ~ 18:50
식사 후 휴식
19:00 ~ 22:30
피그마로 와이어 프레임을 본격적으로 그려보았습니다.
22:30 ~ 23:00
문제사항 발생
현업에서 PR을 할때에는 이미 주니어 개발자가 트러블 슈팅에 대해서 문서화를 해서 보낸다. 그러면 Jira에서는 해당 이슈에 대한 티켓을 발급하여 커밋 내역과 연동한다.
슈퍼바이저는 해당 문서와 매핑된 커밋 내역과 함께 작동되는지 확인하고 조언과 피드백을 준다. 만약에, 올바르지 않는 내용은 이그젝트한다.
근데 우리는 일정한 문서화와 자주실수하는 부분을 가중치와 코드 분석을 통해서 사용자에게 알려주기 때문에 다른 문제 아닌가?
기존의 슈퍼바이저가 지속적으로 관찰해야하는 것을 DB로 인해 쉽게 알 수 있기 때문에 성향이 조금 다르다고 생각한다.
문제는 협업에서 일해보지 않았기 때문에 트러블슈팅하는 과정에 대해 잘 몰랐던것이 문제이다. 왜냐하면, 트러블슈팅의 처리방식이 우리와 다르다.
23:00 ~ 00:30
밖에 나갔다 왔다.
기존의 프로젝트를 진행하면서 본인이 많이 실수하거나 모르는 것을 알려줌. 이미 사용자화 DB를 통해서 잘 틀리는 알고리즘 문제를 백준처럼 추천한다.
커밋로그에서 가죠오기.
생초짜나 프로젝트를 처음 접하는 초급개발자에게 코드 실수에 대한 피드백을 알려준다. 예시를 들어 논리적 오류나 오탈자에 대한 자료를 시각적(그래픽을 보여주는 것도 하나의 기술적 챌린지이다)으로 보여준다. 그룹으로 운영하면서.
자기가 실수를 한 것에 대해서 문서화를 보면서 서로 알 수 있게끔 마이크로 이야기하면서 서로의 피드백을 하면서 실시간으로 채팅이나 노트를 작성할 수 있도록 한다.
솔직히 초급 개발자들이 훨씬 많다. 우리의 서비스를 통해 초급개발자가 방향성을 찾고 쉽게 할 수 있다.
기능의 확장성을 통해서 깊이보다 기능의 확장이 있으니 스프링을 사용할 명분이 생겼다.
00:30 ~ 05:13
오늘의 문제해결 사항들
이동석 코치님의 조언
이동석 코치님이 우리의 아이디어를 보고 기존의 Jira와 비교하여 왜필요한가? 요즘 커서랑 GPT 쓰면 의미없는 서비스 아닌가? 어차피 주니어 개발자로 부터 PR을 받을 때, 이슈가 진행된 시점부터 기록을 시작하고 모두 요약해서 슈퍼바이저에게 주기때문에 해당 서비스가 필요 없다고 하신다.
팀의 멘붕
이동석 코치님의 피드백 후에 팀에 멘붕이 찾아 왔다. 2일간 재밌고 필요한 서비스라고 생각되어서 데모도 만들고 기획도하고 오늘은 와이어프레임도 그리며 순조롭게 시작했다고 생각했다. 생각치 못한 피드백에 다시금 프로젝트의 방향성에 대해서 생각해보았고, 더 이상 일이 손에 잡히지 않아 각자만의 방법(산책, 전화, 방황) 등으로 리프레쉬를 하고자 하였다. 나 같은 경우 두명의 팀원과 함께 산책을 나섰다.
리프레쉬를 위한 산책
분위기 전환을 위해 권호형, 명석이 형이랑 산책을 나섰다. 시내에 있는 편의점을 갔다오며 프로젝트 방향성에 대한 진지한 고민을 해보았다. 나는 개인적으로 엎고 싶진 않지만, 코치님의 피드백에 따르면 엎는게 맞는거 같고… 내면으로 두 생각이 싸웠다. 명석이형과 권호형은 엎는게 맞다고 보는것 같다. 이미 있는 서비스이고, 현업에서 쓰이지 못하면 의미가 없을터였다. PR을 할 때 쓸 수 있어야하는데, 가중치 알고리즘 + LLM + DB 로 인한 코드 트러블 추적 그리고 정해진 형식으로 문서화 해준다는거? 빼고는 이점이 없었다. 문서화 조차도 Ai가 해주니 말다했다. 알고리즘에 대한 확신도 없었다. 권호형이 알고리즘 권위자인데, 어제부터 안될 것 같다고 하셨다. 난 아직 기획한다고 본격적으로 확인하지 않아서 문제였다. 세븐일레븐에서 프루팁스라는 젤리를 사고 정글 캠퍼스로 돌아왔다. 1시간 30분정도 고민을 하며 산책한 것 같다.
프로젝트를 개선할 방법을 탐색하다.
정글로 돌아와서 프로젝트를 개선하기 위해 인터넷 검색과 GPT에게 물어보면서 새로운 아이디어가 있는가? 어떻게 하면 기존의 아이디어를 살리면서 진행할 수 있을까에 대해 고민을 했습니다. 명석이 형이 의견을 냈는데, 백준처럼 잦은 실수에 대해서 사용자에게 문제를 추천하는건 어떻냐는 거였다. 그러나 옆에 조의 교육 의도와 비슷해서 폐기 되었다. 그것 외에 실시간으로 채팅이나, 음성 시스템, 화상 시스템 등에 대해 고민을 해봤지만 저번 기수에서 했던 Code sync와 같은 프로젝트와 비슷해서 보류되었다. 이 과정에서 수많은 이야기와 새로운 아이디어가 오갔다.
주제를 엎을지 고민하다.
전체적인 의견이 엎는 것이 좋을 것 같다는 의견 같아서 팀장으로써 브레인 스토밍을 유도하기 위해 지금 당장 생각나는 3가지 단어를 작성하는게 어떤지 이야기 해봤다. 그러나 내가 넘겨 짚은것이 있었다. 엎지 않고 최대한 지금의 프로젝트를 유지하자는 윤호 형이 있었다. 나도 유지를 하고 싶어하는 쪽이었고, 다들 어느정도 해당 아이디어의 의도에 대해서는 동감하고 있는듯했다. 기술의 범위를 넓이고 시나리오를 짜서 각자의 목표에 맞는 기술을 접목해서 취업을 할때 도움이되는게 어떻곘냐는 진혁이 형의 말이 있었다. 그외에 명언이 있었는데 기억이 안난다… 팀 전체의 어느정도의 멘탈이 회복되는 듯 하다.
승산 가능성을 보다.
마음을 바로잡고, 기술의 범위를 넓이고 알고리즘을 증명할 수 있는지 확인해보고자 명석이 형이 인터넷을 검색하다가 우리의 아이디어가 어느정도 실현 가능하다는 것을 증명하는 블로그를 확인했다. 바로 크래프톤 정글 2기의 블로그였고, 우리와 정말 비슷하게 각자의 리포지트리 커밋을 분석하여 코드 유형과 성향을 정리하여 채용관리자에게 제공하는 서비스였다. 해당 서비스는 Ai를 우선 사용하고, 파싱을 통한 알고리즘으로 반복적으로 나오는 단어들을 캐치해 정보화를 해줬다. 어느정도의 우리 프로젝트의 실현 가능성을 확인할 수 있었고, 권호형도 이제 어느정도 가닥이 잡히는 것 같았다. 이에 진혁이 형이 충분히 가능하고, 알고리즘을 구현해보고 싶었다라고 말하였고 책임지고 구현하겠다는 신임에 찬 말을 하였다. 순식간에 분위기가 좋아졌고, 다시금 활력이 생겨 기술의 범위를 넓이는 아이디어와 시나리오만 다시 짜고 전체적인 흐름은 유지키로 했다. 그리고 우리를 괴롭히던 회사에서 사용할 거라는 상황을 배제하고 원래 의도였던 주니어나 프로젝트를 처음 시작하거나 코딩을 처음해보는 초급 개발자를 대상으로 기획을 하기로 했다. 개발자는 시니어보다는 주니어나 처음 접해본 사람이 많으니 트러블 슈팅도 어떻게 하는지 잘 모를 수도 있고, 코딩하느라 쓸 시간이 애매해진다. 우리조차도 트러블슈팅 문서를 잘 작성하지 않아서 나중에 기억에 남지않는 경우가 많다… 충분히 사용가능성 있다고 생각된다.
웹서비스 기술들
아이디어와 시나리오를 생각해보기위해 웹서비스 기술들을 찾아보았다.
| 기능 | 대표 기술 |
|---|---|
| 실시간 채팅 | WebSocket, WebRTC |
| 화상회의 | WebRTC, MediaDevices API |
| 실시간 알림 | Push API, Notification API |
| 뉴스 피드 자동 갱신 | SSE, WebSocket |
| 오프라인 웹앱 | Service Worker, IndexedDB |
| 사용자 인증 | JWT, OAuth, WebAuthn |
| 위치 기반 기능 | Geolocation API |
| P2P 파일 전송 | WebRTC, Blob |
| 3D/게임 UI | WebGL, Canvas |
| 사용자 음성 명령 | SpeechRecognition API |
