레벨 3 회고

예전에 작성했으나 업로드를 못했어서 올립니다. 🥲

---

레벨3이 끝났다.

프로젝트였는데 걱정도, 기대도 많이 했는데 무사히 잘 끝난거 같다.

우선, 레벨2 때 KPT 회고나 프로젝트를 위한 마음가짐은 크게 도움이 되지 않았다. 프로젝트를 해보지도 않았을 뿐더러, 팀을 만나기 전 단순히 내 마음가짐 및 Try 때문이라고 생각한다.

이번 회고 내용은 프로젝트를 하며 수행한 경험과 느낀점들에 대해서 작성할 거 같다.

총 시간 중 개발 시간이 40~50% ..?

물론, 나도 개발이나 삽질을 되게 좋아하지만 실제로 개발을 한 시간은 전체의 50%도 되지 않은거 같다.

오히려,

• 팀 전체가 같이 기획 회의
• 회의에 따른 기능 프로세스 고도화 및 역활 분담
• 기능을 맡은 프론트엔드 팀원과 와이어프레임 통한 싱크 공유
• 데모데이 발표 준비 & 우테코에서 프로젝트 관련 가르키는 강의
• 서버를 EC2 에 띄우거나, 배포 프로세스와 같은 인프라 등 처음에 되게 스트레스를 많이 받았다.

큰 틀만 잡고, 나머지는 기능 구현 하는 사람들이 알아서 하자.

우리팀의 그라운드 룰 회의를 1시간 넘기지 말자 가 있었으나 월요일 일과를 시작하려는데 회의가 1시간만에 끝나지 않았는데 뭐 어떻게 그만할 수 있는가. 그래서, 소제목과 같은 의견이 나왔다.

사실, 이게 정답인지는 모르겠는데 나는 해당 접근이 더 효율적이다를 느낀거 같다. 모든걸 다 같이 정하려고 하니 모두가 대화를 참여하는거 자체가 어렵기도 하고 ( 7명만 되도, 회의실 안이 꽤나 시끄러워진다. ) 모두의 의견이 똑같을 수가 없다. 이때, 반대 의견이나 다른 의견들을 모두 수용하거나 설득하려고 하면 할 수록 더 시간이 늘어나고, 어려워진다.

특히, 구현을 하기 전까지는 모르거나 알 수 없는 부분들도 미리 지레 예측하거나 겁먹어서 이를 기반으로 얘기할 때도 있었다. 우리, 전문적인 실력이 있고 시니어 개발자들이라면 모르겠는데 아직 파릇파릇 성장해나가는 주니어 개발자들이 내가 알기로 어떻고, 이거는 이래서 안되지 않나? 와 같은 말은 회의에서 의미가 없다.

그래서, 큰 기능 랭킹 기능, 리뷰어 -> 리뷰이 에 대한 매칭 기능 같이 큰 기능에서 플로우만 얘기하고 같이 작업하는 사람이랑 같이 에러 처리 & 플로우 시 요청 / 응답 등을 논의 했다.

굴러가는 챗바퀴

우리는 2주마다 데모데이를 진행했다. 이는, 솔직히 한번도 경험해보지 못한 경험이였다. 예전에 진행했던 졸업작품 프로젝트에서는 방학전 한번, 개학하고 9월에 한번 총 2번 밖에 검사를 하지 않았다. 그래서, 그냥 내가 개발을 하고 싶은대로 했고 뚜렷한 목표 없이 큰 틀을 향해서만 나아갔다.

그러다 보니 일정량의 속도가 나오지 않았었다. 어떤 주는 매일 밤 늦게까지 코드를 작성하기도, 어떤 주는 거의 하루 정도 밖에 개발을 하지 않는 경험이 있었다.

반면에, 우테코 내 프로젝트는 뚜렷한 MVP 를 설정하게 해주고, 팀원들 전체도 정해진 MVP 를 향해 업무를 수행해야 하는 굴러가는 챗바퀴 같았다. 이 부분에서도 좀 스트레스를 받았었다.

내가 개발을 더 하고 싶거나, 기능을 더 추가 하고 싶은데도 데모데이와 데모데이때 요구하는 다른 사항(인프라 구축,로깅,문서화 등) 때문에 멈춰야 했기 떄문이다. 지금 회고를 하며 생각하는 점으로는 이게 당연한 수순이지 않을까 싶다.

회사에서는 오히려 더 절박하게, 많은 사항들을 수행하면서 데모데이처럼 MVP 를 완수해내야 하지 않을까. 좀 더 이 챗 바퀴를 효과적으로 굴러가는 방법을 레벨4에서 생각해봐야 겠다.

만능 개발자

프로젝트는 단순히 자바-스프링으로 개발을 하는게 아니라 많은 부분을 우리가 관여하게 만들었다. 기능 기획, 기초 디자인 같은 비개발적인 요소부터 서버 배포&인스턴스,DB 관리 같은 데브옵스(?) 적인 요소들 까지. 그리고, 기능을 나눠서 프론트엔드와 같이 협업을 해서 내가 프론트엔드의 기초적인 요소와 흐름까지도 알았다.

이때, 이 크게 3자기 요소들도 하면서 느낀점으론 다 서버 개발자의 역량을 향상시키는데 도움되 된다는 것이였다.

기획과 디자인

도메인 지식과 기획에 대한 지식을 모르고, 개발하는 건 의미가 없다.

흥미도 떨어질 뿐더러, 잘못된 방향으로 개발이 될수도 있기 때문이다. ( TDD 를 지키며 작성했는데, 애초에 로직이 잘못되거나 다 엎어야 한다면? ) 이 부분은 솔직히 어둡게 생각하면 한 없이 어두워질거 같다. ( 기획을 같이 얘기해도 기획자나 PM 이 변경하거나 엎을수도 있을거니까 ) 그럼에도, 기획을 개발자가 참여함에 불가능을 사전에 막거나, 더 나은 방향으로 향할수 있기 때문이다.

기획자가 A.1 을 원했는데 이게 시간 및 서버 부하를 가중시킨다면 A.2 로 개발자가 이끌어내는것도 충분히 타협시키는게 개발자의 역량이지 않을까…?

서버 배포 & 인프라 관리

대기업에 취업한다 하더라도, 내가 완벽하게 서버 배포나 인프라 쪽에서 분리가 될 수 있을까?

그리고, 분리가 되더라도 자바-스프링만 한 개발자는 우물 안의 개구리가 아닐까 생각한다. MSA 적인 요소가 되면 될수록, 서버 개발자가 해야할 일은 늘어날 거라고 생각한다. ( 작은 프로젝트 단위이므로, 서버 개발자가 충분히 담당할 수 있는 크기가 될 것이므로 )

밑에서도 얘기하겠지만 하나도 모르는 것과 조금은 아는 것은 정말 어마어마하게 큰 차이 일 것이다. ( 물론, 모든 걸 자세히 아는게 베스트 🙂 ) 생각해보면, 이미 우리는 데브옵스적인 요소들에 밀집되어 있다. CI 를 하는 워크플로우, JPA 를 사용할 때 연결하는 DB 주소, CORS 를 열때 허용하는 주소 등등 이런 걸 데브옵스에 모든걸 맡길 수는 없을거다.

프론트엔드의 기능 협업

3차 데모데이에 요구사항 중 기능 하나를 프론트엔드와 협업 이라는 요구사항이 있었다.

솔라와 브리가 이미 정답은 말해줬지만

프론트엔드와 협업을 하라고 한 이유는 백엔드 개발자라면, 자신이 맡은 기능이 프론트부터 백엔드 까지 어떤 흐름으로 진행된다를 자신있게 말할 수 있어야 한다고 생각해요.

시간과 여건이 된다면 프론트엔드와 기능이 정해진 후 서로의 프로세스가 어떻게 진행 될 지 알게되는건 매우 좋은거 같다.

직접적으로, 어떻게 요청 & 응답을 보내서 패킷 크기와 응답 시간등도 서로 유추할 수 있고 C.S 적인 요소들도 더 알아갈 수 있었다.

열정과 합의 그리고 대화

프로젝트 중 의견 다툼(?) 까진 아니고, 불만에 대한 얘기를 프로젝트 팀원들에게 꺼냈다. ( 다시 한번, 잘 받아준 팀원들 에게 감사를 🙏🙏 ) 자세한 내용은 레벨3 글쓰기에서 작성했다. ( 프로젝트에 대한 열정이 안느껴진다는 내용이였다. )

열정과 합의

프로젝트에 대한 열정이나 개발에 대한 열정은 누구도 강요할 수 없는 것이다. 3차 데모데이때 내가 스트레스를 받았는 만큼, 내가 4차 데모데이 때 예비군을 갔을때 스트레스를 받았을 수도 있을 거 같다. ( 애쉬, 뽀로로 땡큐 ☺️ )

열정이 120% 라고 하더라도, 그 열정이 계속 이어질지 모를 뿐더러 열정이 계속 이어지는게 더 재앙일 수 있다. ( 나는 100%라고 생각하는데 누가 열정이 안 느껴진다고 계속 강요하면…? )

열정은 구체적이고 명확하게 눈에 보이는 부분으로 정하고, 이를 할 수 있을지 / 없을지 그 중 어려움이 없는지 합의 를 하는게 좋은거 같다고 느꼈다.

그렇기에, 나는 열정을 조금 더 다른쪽에 투자하기로 했다. ( 물론, 지금은 개발적인 요소이나 비개발적인 요소로도 투자하도록 노력해야지.. ) 기능 구현 중 나오는 C.S 적인 요소에 관심을 가지고 있다. ETag 라던가, User-Agent 라던가, Webhook 이라던가. 프로젝트에 완벽하게 벗어나지 않고, 도움이나 지식 전파는 할 수 있되, 남한테 강요할 수 있게 나아간다.

대화

결국 대화를 해야 함을 느꼈다. 불만이든, 만족이든 대화를 하지 않으면 상대방은 인지를 하지 못한다. 추가로, 이런 불편함이나 말하기 어려운 요소들도 꺼낼 수 있는게 좋은 유대관계를 만드는 것도 중요할 것이다.

액션플랜을 좀 더 생각해봐야겠다.

레벨4 때 나아가야 할 방향

레벨 4때는 어떻게 나아가야 할까

수치적으로, 좀 더 깊게

이제 기초적인 구축은 끝났다. 현재는, 단순한 기능 구현과 팀원들과 프로젝트를 하는게 의의였고 핵심이였다면

• 왜 문제라고 정의했는지 ( 수치적 - 웹 요청 중 발생하는 시간, DB에서 처리되는 쿼리 시간, 비즈니스적 - 고객이 불편함을 느낀다, 있으면 좋다고 생각할 거 같다 )
• 이런 문제를 해결하기 위해 기존에 존재하는 패턴이나 라이브러리가 있는지
• 어떻게 해결했는지

에 좀더 초점을 맞춰 나갈것이다.

이미, 우리 프로젝트에는 문제점들이 봉착해있다. 똑같은 시간에 같은 신청을 할 때 동시성 문제(물론, 과연 그런 사람들이 있을까? 싶긴 하다.) 외부 API 를 의존하며, 의존하지 않아도 큰 값을 DB에서 불러오고 그를 기반으로, 작업을 해야 한다.( 트랜잭션이 과도하게 길어질 문제 )

기록을 남기며

프로젝트를 하며, 아쉬웠던 건 남기려고 노력은 했지만 완벽하게 기록으로 남기진 못했던 거 같다. 특히, 바쁠때는 기록을 위한 단순한 스티커 메모라도 작성을 하는 습관을 들여나갈 거 같다.

단순, 기억에 의존하는 것과 스티커 메모들을 기반으로 기록을 시작하는게 꽤나 차이가 큰걸 느꼈다. 이때 나는 원래 옵시디언에 여러 노트를 (특히 미완성된걸) 추가하는걸 싫어해서 안남겼는데 스티커 메모에

2024.08.28 Transactional Outbox Pattern

DB 트랜잭션과 메시지를 묶어서 브로커에게 전달하는 패턴?
이를 통해, 외부 로직과 DB로직간 트랜잭션을 의도적으로 분리할 수 있는거 같다.

까지라도 남기려고 노력해야겠다.

전문적으로 말을 하자

이건, 사실 우테코를 들어오기 전부터 문제였다. 머리속에 있는 지식들을 전문적으로, 상대방이 알아듣기 쉽게 전달하는게 참 어렵다.

우테코 활동을 하며, 페어나 가볍게 대화를 하는건 편하고 자신있게 내 의견을 드러냈는데 테코톡, 데모데이, 다 같이 참여하는 활동 등에서 아직 한없이 부족했다. ( 특히, 4차 데모데이 때는 내가 발표하려 했는데, 기능적으로 미완성이 되어있으니까 너무 불안해짐을 느꼈다. - 무빈씨 미안해 )

이를 해결하기 위해선 스스로도, 외적으로도 노력을 해야 할 거 같다.

스스로 나아가기

기존에는 머리속에서 생각하고, 노트에 기록하는데 내가 생각한걸 그림으로 그리거나 정리하는 실력도 키워야 할 거 같다. ( 해당 부분은 내가 ERD 나 플로우를 자신있게 못그리는 것도 해결하기 위함이다. ) 추가로, 너무 정리를 하는식 + 보여주는 느낌을 위해서 내 사담이나 이해하기 위한 부연 설명들을 생략할때가 있는데 이를 더 잘 정돈해서 포함을 시켜야 겠다.

외적으로 노력하기

면접 스터디가 될지는 모르겠는데 내가 깨달은 지식이나, 작성한 블로그 내용에 대해서 발표를 할 수 있는 기회를 가지도록 해봐야겠다. ( 레벨1 사람들, 레벨2 사람들, 프로젝트 사람들 등등 )

정말, 이제는 시도해봐야 할 때 인거 같다.

마무리

기존의 레벨1,2 처럼 KPT 가 아닌 느낀점들에 대해 남겼는데 개발 학습만을 위해 나아가는 레벨3가 아니라고 생각해서 느낀점, 개선점, 방향성을 위주로 남겼다. 앞으로 레벨4,레벨5까지도 화이팅

---

지나고나서 보니 기록과 수치적으로는 노력했는데 전문적인 말은 아직도 안됐네요 😢