BEYOND SW캠프 16기_3주차 회고

J·2025년 6월 8일

BE16_주간회고

목록 보기
2/2
post-thumbnail

#1. 우리 진짜 잘 할 수 있겠지?

부트캠프를 시작하고 처음으로 주어진 프로젝트를 시작하게 되었다.
이름하여 "DB프로젝트". 팀 단위 작업은 학교 다닐 땐 많이 해 본 적이 없고, 하게 되더라도 각자의 파트가 너무나도 명확했던 터라
그다지 어려움 없이 진행 했던 기억이 있다.

#2. what is git?

이게 기술적 한계에 부딪히는 순간인건지, 거의 군장검사를 당하듯 '야 너 화면공유 켜봐'를 당했다.
웬걸, 나는 완전히 다른 폴더에서 작업을 하고 있었고, 이를 잘못 push라도 하게 된다면 정말 끔찍한 일이 벌어질 것이 자명했다.

아예 처음부터 새로운 폴더를 만들고 git checkout -b feat/jinn 새로운 branch를 생성해서 작업을 진행했어야 했다.
뭐 내가 잘하면 얼마나 잘한다고 작업량이 많지도, 잘하지도 않았지만 그럼에도 이를 잘못 push 할 경우 열심히 작업한 다른 팀원들의 것이 망가지는 건 기정 사실이었다.

내가 정말 무서웠던 건, 이 git을 몰라서가 아니었다. 나로 인해 다른 팀원들의 작업물이 망가질 경우가 가장 무서웠다. 그럼에도 고마웠던 건 조원 중 git을 정말 잘 다루는 친구가 있었는데 이 친구가 거의 매질을 하듯 알려줬다. 그렇게 알려주고 미안해 하는 모습이 어찌나 고맙던지, 나는 잘 배웠고, 그 친구도 다시 복습하는 기회가 되었길 바란다. 아무튼 정말 고맙다! 내 꼭 git 연습해서 자유자재로 써보도록 하마. 내 다짐이자 자존심을 걸고 약속해본다.

#3. 정말 실전

이론으로 강사님 수업을 듣는 것은 그때만큼은 나의 것 같았다. 당연히 수년째 강의를 하고 계신 프로께서 강의를 하시니 나 같은 '노베이스'도 충분히 이해를 시켜주시는 것 같았다. 하지만, 현실은 정반대라는 것. 주제를 '직접' 선정하여, 요구사항 명세서, ERD 논리, 물리 설계부터 시작하는 것은 완전히 별개의 문제였다. 내가 정말로 답답했던 건 요구사항에서 일을 벌렸는데 이를 ERD 물리 설계에 제대로 녹여내지 못한다는 것이었다. 또한, 요구사항 명세서에 적었던 내용들이 굉장히 '꿈'이었다는 사실도 깨닫게 되었다. 우리의 주제는 크게 '전세 사기 예방'이었는데, 전세사기 예방을 어떤 것을 기준으로 잡는지가 관건이었다. 우리는 그 기준을 '매물의 경매 빈도'로 잡았었다. 경매가 이루어진 매물은 크게 두 가지로 나눌 수 있는데, 첫 번째는 소유주의 단순 경매, 두 번째로는 소유주의 현금 조달이 부족하기 때문에 발생하는 경매였다. 우리가 '전세사기'를 당하는 것은 후자의 경우에 가깝기 때문에 이들 api가 존재할 것이라고 가정하고 요구사항 명세서를 작성했고, 우리가 지향하고자 하는 바도 단순한 '공익 실현 정보 전달'이었다. 정말 예상치도 못했다, 이 정보를 700원이라는 재화를 주고 바꿔야 한다는 사실을.

결국 우리는 위기에 봉착했다. '야 이거 결제를 시켜서 우리가 먹는 것도 아니고... 정보 전달을 위한 것인데 사용자에게 결제 책임을 전가해도 되지 않냐?', '아니다, 우리는 공익 서비스인데 결제를 유도하는 순간 서비스의 성격이 무너진다.' 와 같이 갑론을박이 펼쳐졌다.
결국 우리는 원점으로 돌아와 '주제 선정을 다시 하기 (이는 곧 전부 완성한 요구사항 명세서, ERD설계를 전부 다시 해야 함을 의미한다.)', '기존 서비스를 유지하되, 정보제공이라는 폐쇄적인 성격에서 확장성을 가진 커뮤니티성 서비스로 바꾸기'로 재정비를 하였다. 무려 이 고민을 하게된 것은 프로젝트 마무리가 이틀 남고, ERD 설계를 마무리 한 지 1시간이 지난 뒤였다. 결국 우리는 시간적 한계를 인정하고, 정보 전달 성격을 조금 더 확장하여 사기를 당한 피해자들과 이를 잘 아는 전문가들과 매칭해주는 서비스를 추가하여 '커뮤니티' 성격으로 확장하였다.

이 결과가 과연 어땠을까? 과연 한가닥 하던 성격들이 어디 가지 않는지, ERD 설계부터 '이게 fk가 맞냐', '이 entity가 들어가도 되냐' 등 굉장히 지엽적인 문제 (필자만 이렇게 생각하는 것이지, 프로젝트를 거의 완성한 지금, 사실은 굉장히 중요한 문제라고 생각한다.) 로 열띤 토론을 펼쳤다. 결국은 다 같이 완성하긴 했으나, 이를 해결하기 위하여 정말 많은 시간과 스트레스를 받았음은 자명하다.

차치하고, 집요한 팀원들 덕분에 마무리는 잘 되었다. 나는 아직 많이 부족함을 다시 깨닫게 되었다. 막상 프로젝트를 시작하면 잘 할 수 있을 거란 자신감은 역시는 역시였다. 얼마나 더 잘 아는지, 이 주장에 대해 근거를 어떻게 세워야 할 지 스스로 많은 고민을 했었던 좋은 양분이라고 생각한다.

#4. 문서화의 중요성

내가 이를 시작하기 전 먼저 시작한 형님께서는 항상 하시는 말씀이 '문서화의 중요성'이었다. 나는 음 뭐 알겠어 정도로만 넘겼지만, 막상 프로젝트를 진행해보니 문서화를 제대로 해놓지 않으면 어디서 문제가 생겨도 이를 알 길이 없더라. 예를 들면 create procedure를 했을 때, in (1)(2)(3)을 하다가 오류 발생 혹은 엔터티 성격의 변환에 따라 in (1)(2)를 해야할 때가 있는데, 이를 앞서서 말한 문서화를 제대로 해놓지 않으면 어디서부터 막혔는 지 너무 막막해져 버린다. 결국 다시 새로이 create procedure를 하는 일이 생겨버리고, 이는 작업 시간의 비효율을 가져다주었다. 사람이 얼마나 간사한가, 시간이 늘어지면 사람의 당찬 기세마저도 점점 늘어지게 마련이다. 이를 방지하기 위해선 꼭 'DeadLine' 설정이 중요한 것 같은데... 내가 문서화를 제대로 해놓지 않으면 결국 작업 시간은 늘어나고, 우리가 가고자 했던 방향성 자체를 잃어버리게 될 때가 온다. '엎친데 덮친격'이라고 했던가, 단순히 기록하지 않았다는 이유만으로 이 프로젝트 퀄리티가 굉장히 낮아질 수 있다는 사실을 인지하게 되었다. 물론 이미 프로젝트를 다수 경험한 팀원들 덕분에 못하는 내가 뭐라고 더 열심히 하지 않을 순 없었지만, 그럼에도 아마 다들 공감을 하고 있었을 것이다.

그 뒤에 log_list에 관련하여 Trigger를 만들었는데, 1st Trigger, 2nd Trigger ... nth Trigger를 vscode에 정리해두었다. 앞서 만든 procedure를 기록하지 못했던 내 자신이 너무 후회스러워 한 번만 속는셈치고 해봤는데, 결과는 '!대성공!', 나는 문서화에 대해 확신과 중요성을 깨닫게 되는 순간이었다. 귀찮아도 꼭 내가 썼던 코드는 저장하는 습관을 들여야겠다.

#5. 이번 주 학습 결과

이번주는 3주차인데, 내가 무엇을 공부했나 돌이켜보면 굉장히 후회스럽다. 뭔가 나사가 하나 빠진 듯한 학습이 굉장히 많았던 것 같다. 다만 크다면 크고, 작다면 작다고 할 수 있는 알고리즘 공부. 나는 이 공부가 그나마 기억에 남는다. queue 인터페이스를 공부하며 java에 관해 조금 알게 된 것 같았다. 누구는 인터페이스 하나 공부한 것 갖고 고작? 얼마나? 라고 질문할 수 있으나, 이를 통해 메서드의 개념에 대해 조금 더 구체화 하게 되었고, inner class, 그리고 내가 이 알고리즘 공부를 하며 가장 의문을 많이 가졌던 BufferedReader에 이해도가 조금 높아지게 되었다.

왜 쓰는지, 어떻게 사용하는지 조차 감을 잡지를 못했는데, Queue 인터페이스가 나에겐 낫이었다. 낫 놓고 기역자도 모른다고 하던가, 기역은 BufferedReader였다는 사실이다. 비유가 올바른가는 모르겠으나...

이후 프로그래머스에서 주관하는 pcce 시험을 등쌀 떠밀리듯 보게 되었는데 생각 외로 쉬워서 놀랐다. 물론 점수를 잘 받았은 것은 아니지만... 조금만 공부하면 금방 master level에 도달할 수 있다는 자신감을 갖게 되었다. 조상님들 틀린 말 하나 없다. "백문이 불여일견" 그냥 말로만 코테코테 백 번 듣느니, 한 번 시험을 쳐봐야 내 기준이 생기는구나.

기준 얘기가 나와서 말인데, 이 개발 공부에 있어서는 본인의 기준이 가장 중요한 것 같다. 이 기준을 갖고 하는 것과 기준을 갖지 않고 하는 것은 굉장히 큰 차이가 있을 것 같다. 자신의 코드에 대해 근거를 탄탄히 하려면 본인만의 기준이 굉장히 중요하지 않나 하는 생각을 했다.

#6. 마무리하며

내일 발표인데, 이거 잘 할 수 있을까? 나도 굉장히 열심히 참여를 하긴 했으나, 실력이 부족한 나머지 구현을 많이 접하지 못했다. 그럼에도 발표를 맡겨준데는 이유가 있지 않을까. 한 번 나도 내일은 소피스트에 빙의하여 현란한 궤변을 늘어놓을 수 있기를 기대해본다. 아 물론 근거가 아주 없는 궤변은 아닐 것이다. 나도 고민은 굉장히 많이 하였고, 이 프로젝트 서비스의 기능 제안은 많이 했던 것 같다. 많이 없어지긴 했으나...

프로젝트, 괜히 하는 건 아니다. 필요 없는 건 단 하나도 없었던 것 같고, 이번 주는 이론적인 강의보단 실전과의 싸움이지 않았나. 또 마무리 할 때 몸살이 굉장히 심하게 걸렸는데, 와 이걸 버티면서 한다고? 극한의 극한을 보는 느낌을 받았다. MASTERNSLAVES야~ 부족한 나지만 같이 팀해줘서 고마워~
어떤 부분을 공부해야 할 지도 스스로 기준이 세워지는 순간이 되기도 했다. 아무튼 이번 주도 다시 힘차게 달려보자고 다짐하며 마무리 해본다.

profile
glycogen

0개의 댓글