📝4회차 회고록ㅣBEYOND SW캠프
🖥️ 4회차 학습 (25.10.13 ~ 25.10.17)
연휴 이후 리눅스 사용 방법과 master-slave Replication Server 에 대하여 배웠고, 목요일(16일)에는 첫 번째 프로젝트 발표가 있었다. 첫 째 미니 프로젝트는 주제선정, 요구사항 분석, DB설계 및 DB 테이블 구현까지 진행 후 프로젝트에 대한 발표 및 문서 제출로 이루어졌다.
프로젝트 이후 10월 17일에는 JAVA 첫 수업을 시작했으며, JAVA 개발 환경 및 기본 문법에 대하여 수업을 들었다. 4회차 회고록은 다른 배운 내용보다 첫 번째 미니 프로젝트 회고 중심으로 작성하겠다.
KNPT 회고에 앞서, 진행한 프로젝트에 대한 간단한 소개를 하고 시작하겠다.
| 프로젝트 명 | PlayCe |
|---|---|
| 팀명 | Player |
| 시작일 | 2025년 10월 1일 |
| 종료일 | 2025년 10월 16일 |
| 참여자 | 김*진, 김*경, 유*연, 이형욱 |
프로젝트 Github 링크는 여기 를 클릭하면 된다.
👍 KEEP
1. 마일스톤 설정 🎯
프로젝트를 시작하기 전에 팀원들과 목표 제출물과 마일스톤, 즉 각 단계에 대한 체크포인트를 최대한 잡으려고 노력했다. 팀원들과 같은 장소에서 같이 작업할 수록 해결문제에 대해 서로 다른 시점과 이해로 작업 시간이 길어지고 아이디어가 고갈되는 현상이 반복되었었는데 이 흐름을 잡은 이후 회의가 짧고 명확해졌다. 물론 프로젝트 스케일이 마일스톤을 설정하고 분담을 했어야 할 만큼 큰 프로젝트 였냐 하면 아니었던 것이 맞는 것 같다. 다른 팀들의 이야기를 들어보니, 오히려 다같이 모여 있을 때 제심합력으로 뜻을 모아 빠르고 폭발적인 협력으로 순식간에 필요한 작업을 끝내고 추석 연휴를 마음 껏 누렸다고 한다. 정말 부러웠다. 하지만 각 팀에 주어진 팀원들과 상황은 모두 다른 법, 아무래도 나의 팀에 주어진 상황과 팀원 간의 케미를 보아 가장 안정적인 방법을 선택했던 것 같고, 후회는 없다. 나름 초중반 까지는 잘 먹혔다.
2. 회의방식 🚩
가능한 한 회의는 짧게, 작업은 개인적으로, 분담은 확실하게 하려고 노력했다. 회의의 논점을 흐리는 논의는 과감히 끊고, 결정→기록→과제배분으로 이끄려 노력했다. 하지만 팀장도 아니면서 팀원들에게 일방적인 모습이 있었던 것 같지만 그럼에도 잘 따라주고 또 적극적으로 의견을 내준 팀원들이 참 고맙다. 때때로 뜻대로 되지 않는 상황에 대해서 유연하게 대처하는 것 또한 배웠다. 좌우지간, 회의에서 내가 느끼기에 중요한 것은 빠른 논의 사항 해결과 해야할 일 분배라고 여기기 때문에 앞으로도 팀 프로젝트 뿐 아니라 여타 다른 회의 상황에서 효율적인 회의를 위해서는 팀장이든 팀원이든 앞으로도 안건에 대해 충분히 생각하고 준비해 와야 겠다.
3. 역할 분배 ☮️
프로젝트 초기에는 기능별 역할 분배를 진행했다. 초반부에 역할 분배 없이 함께 작업을 하려다 보니 비효율적인 구도가 나와 분배를 하기로 결정했다. 시간이 지나 팀원들도 어느정도 프로젝트에 대한 윤곽이 잡혀서 한 사람이 한 파트의 메인 작업 하나 서브 작업 하나씩을 맡도록 하여 여러 가지를 놓치지 않고 가져갈 수 있도록 최선을 다했다. 특히 책임소재를 확실하게 하여 각 맡은 작업에 대한 책임자를 지정해서 다음 회의 때 책임자 주도 하에 진행하도록 했다. 역할 분배는 정한 시점부터 후반부 전까지 효율적이었으나, 발표 전과 당일 날 정도 되자 앞 뒤 가릴 것이 없어서 서로가 할 수 있는 부분은 전부 서로 커버하려 했던 것 같다.
4. 의견마찰 ⚖️
동일한 목표를 가지고 있더라도 서로 다른 시점에서 다른 방법을 생각한다면 결국 마찰이 생기기 마련이다. 의견이 과열될 때 정답은 하나가 아니라 처리 방식의 선택임을 상기시키며 합의 지점을 만들었다. 물론 나 또한 팀원과 회의 중 의견 마찰을 빚었을 때, 다른 팀원이 개입하여 중안점을 찾아주었던 고마운 기억이 있다.
5. 연휴 중 미팅 🌕
연휴에도 온/오프라인으로 모여 회의하고 ERD를 통합했다. 사실 ERD를 추석연휴 전에 전부 마무리했다면 프로젝트 일정이 더 당겨졌을 것 같아 더 빨리 못했다는 아쉬움이 남지만 당시에는 여유롭고도 남을 거라고 생각했었다. 온라인 회의를 통해 계속해서 다음 계획과 목표를 수립하고 다음 단계로 넘어가려고 노력했다. 물론 다 생각처럼 되진 않았다.
✏️ NEW
1. 분담 📝
회의에서 디테일을 다루면 모두 지치는 것 같다고 느꼈다. 결정만 하고 디테일은 각자 문서·이슈로 넘기는 분리가 효율적이라 여겼다. 하지만 어떤 부분은 팀원 간의 도움이 필요했다. 회의로 안건을 결정하고 작업은 분담하는 것이 효율적이기는 하나, 도움이 필요한 부분을 옆에서 알려주고 도와주는 것을 간과했던 것이, 나중에 스노우 볼이 되어 불필요한 작업을 반복적으로 하게 되었던 점이 기억에 남는다.
2. 회의 전 준비 ✏️
요구사항 명세서와 ERD 통합에 관한 이야기를 하던 도중 내가 준비한 파트가 미흡하다는 것을 느꼈다. 회의를 하기 전 내 파트를 잘 해와야 효율적이고 의미있는 회의를 할 수 있음을 느꼈다.
3. Github 🌵
팀원들과 함께 Github로 파일을 관리하도록 결정했다. 사실 Github를 실제 프로젝트에 사용하는 것은 이번이 처음이었다. 매번 학교 수업 때 과제 제출용으로만 사용하다가 실제 이용하는 건 처음이고 모르는 것이 많아서 긴장이 되었다.
Repository fork
그렇게 크지 않은 프로젝트인데fork를 사용했었다. 내가 제안했었고, 이 때문에PR을 날리고 레파지토리 주인장이PR을 받지 않는 다면 작업이 지연되는 사태가 발생했다. 이후 강사님의 조언으로 이만한 스케일의 프로젝트에서는fork를 쓸 정도가 아니라는 것을 배웠다. 이 이후로Branch를 사용했다.pull,push
브랜치feature/branch1를main과 별개로 운용 중인 상황이라고 하자.feature/branch1에서 작업을 한다면,push하기 이전에 다음 순서가 필수적으로 따라온다.git pull origin main
main에서 변경 사항이 생겼을 수도 있기 때문에 반드시 메인에서 땡겨와야 한다.git push origin feature/branch1
이제 업데이트도 됐으니, 브랜치에서 작업한 것들을 원격 브랜치로 날려준다.- 메인으로
PRand 머지
메인으로 날린PR이 머지된다. - 메인으로 머지된 이후 다시
git pull origin main을 한다.
메인 브랜치가 변경됐으니, 로컬에도 업데이트를 시켜주어야 하는 것이다. - 마지막으로 다시 한 번
git push origin feature/branch1을 한다.
로컬에 생긴 변경점을 다시feature/branch1에push한다. 마지막 부분을 안해서 충돌이 정말 많이 났던 것 같다. 메인이 PR을 받게 되면, 이를 변경점으로 인식하여 로컬도 업데이트를 해주고, 비록 메인과 서브 브랜치가 업데이트 상황이 동일하다고 할지라도, 다시 한번 동기화를 시켜주지 않으면 나중에 충돌이 난다.
4. 요구사항 명세서 작성 시 팁 ✔️
주제를 선정하고 나면, 주제에 대한 UML 과 사용자 요구사항 명세서를 가장 먼저 작성하게 된다. 요구사항 명세서를 작성하기 이전에, 기능이 흘러가는 플로우에 대해서 UML 로 풀어내는 것이 먼저일 것이다. UML을 통해 나온 실체 엔티티와 액션 엔티티를 구분하여, 실체 엔티티에서 사용자 플로우가 어떻게 흘러가는지 파악한 후, 액션 엔티티를 통해 시스템의 흐름을 파악한다면 어떤 요구사항 명세가 필요하고, 어떠한 테이블과 컬럼이 필요한지 점차 알 수 있게 될 것이다.
실체엔티티와 액션 엔티티의 차이점은 아래와 같다.
| 구분 | 실체 엔티티(Entity) | 액션 엔티티(Action) |
|---|---|---|
| 성격 | 데이터나 상태, 핵심 정보 (What) | 행위, 기능, 로직 (What to do) |
| 유지 | 영구적, 지속적 | 일시적, 처리 과정 |
| 예시 | 회원, 상품 | 상품 주문 처리, 회원 등록 |
| UML 모델링 | 엔티티 클래스 | 경계 클래스, 제어 클래스 |
- 실체 엔티티를 통하여 핵심적인 유저 케이스의 흐름과 테이블 종류를 파악하고, 이후 액션 엔티티를 찾아내어 어떠 기능들이 필요한지 파악할 수 있다. 이러한 실체/액션 엔티티 정보들을 통해 기능들이 세분화되고, 각 기능마다 어떤 역할을 하는지 정리할 수 있다.
- 명세서를 작성할 때는 가능한 한 기능을 자세하고 세분화하여 작성한다. 특히 ERD와 테이블, 그리고 컬럼까지 어떻게 사용할지 미리 계획하며 요구사항 명세서를 작성하면 DB설계와 DDL, DML 작성까지 유익을 볼 수 있을 것이다.
💡 PROBLEM
1. 요구사항 명세서 📄
NEW 파트에서 요구사항 명세서에 대해 배운 것을 적을 수 있었다는 것은, 쉽지 않은 과정을 겪었기 때문이다. PlayCe 프로젝트는 요구사항 명세서를 시작하는 것부터 매우 난관이었다. 주제는 결정했지만 UML을 작성하지 않고 빈 스프레드 시트에다가 어떤 기능을 넣어야 하는지 어디서부터 시작해야하는지 네 명이 한꺼번에 달려들어도 생각이 좀처럼 좁혀지지 않았고 모두가 골머리를 썩혔다.
어디서부터 해야할지는 아무도 감을 잡지 못했고, 아이디어를 얻기 위해 시트에다가 생각나는 대로 적어보고 화이트보드에다가 브레인 스토밍이라도 하려고 했지만 별 의미가 없었다. 다들 기운이 빠진채로 앉아있다가 지나가시는 강사님을 붙잡고 도움을 받게 되었다.
강사님께서는 실체 엔티티를 먼저 생각하여 전체적인 흐름과 필요한 기능, 그리고 이에 파생되는 것들을 생각해보고, 액션 엔티티를 생각해 보라, 그러면 어떤 기능을 사용해야 하고 어떤 테이블을 써야 할지 감이 올 거라고 말씀하셨다. 이에 우리 팀은 아래 사진과 같이 생각을 내어 기능을 정리한다.
물론 깔끔하게 잘 정리해놓지는 못했지만, 이 사진이 우리 팀의 출발선이었다. 하지만 결론부터 말하자면 몇 번씩 요구사항이 수정될 운명이었다. 심지어 예약 서비스 플랫폼에서 가장 중요한 기능을 잊고 나중에 생각이 나서 추후에 추가하기 까지 한다. 당장 문서를 작성하지 않으면 불안하여 부족한대로 기능을 분담하여 각자 집에서 작성해 오기로 하고 점검하기로 했지만, 사실 나는 내 부분 말고는 집중이 안되어 팀원들 것들을 잘 봐 주지 못하였다. 그래도 나름 문서가 정리되어 간다는 것에 안도감을 느꼈다.
2. 내가 맡은 ERD 📔
완벽한 테이블은 없다. 하지만 더 나은 테이블은 항상 존재하는 것 같다. 내가 맡았던 post, recruit, qna 기능은 결론적으로 서로 겹치는 것이 거의 없다. 하지만 이를 처음 설계할 때, BOARD 테이블 하나로 이 세 기능을 묶는 치명적인 실수를 저질렀다.
위 사진과 같이 게시판 관리로 묶어서 세 기능을 모두 다루려다 보니 보면 볼수록 중복되는 부분은 많지만 기능적으로는 전부 따로 노는 최악의 상황이 발생한 것이다. 게시물, 모집글, Q&A가 모두 작성일자와 제목이나 내용등은 공유 하지만, 처음 설계할 때 게시물과 Q&A, 그리고 모집글의 기능적 차이를 자세하게 명세하지 않아서 생긴 문제였다. 결국 아래와 같이 수정하게 되었다.
이렇게 각 기능의 명세를 정확히 한 후 소량의 중복되는 부분을 허용하고 기능대로 테이블을 나눔으로써 논리적으로도 접근성으로도 ERD를 개선시킬 수 있었다.
ERD를 리팩토링할 당시, 나만 완료점을 찍으면 DDL 을 작성할 타이밍이라 팀원들에게 "우리 게시물/Q&A/모집글 테이블이 잘못됐어요. 갈아 엎어야할 것 같아요." 라고 말하기가 정말 어려웠다. 하지만 이를 바꾸지 않으면 나중 가서 더 큰 문제가 스노우 볼처럼 커져 돌아올 것 같아서 떨어지지 않는 입을 떼어 말했다. 물론 그러고 나서 반나절 만에 작업을 금방 끝냈다. 오히려 테이블을 나누니 기능이 더욱 명확해지고, 직관적으로 이해하기 쉬운 형태가 되어 거시적으로 효율적인 작업이었다고 본다.
3. 예약 테이블과 결제 테이블 💸
발표 하루 전, 예약 테이블의 구조가 대폭 변경되었고, 결제 테이블이 추가되었다. 전체 요구사항 검토와 ERD설계도를 리뷰할 때 자세히 살펴보지 않고 넘겨 짚고 지나간 나의 실수에 대한 당연한 결과였다.
발표 하루 전날 DML 을 작성하면서 발생한 문제로 인하여 자세히 살펴본 결과, 몇 가지 해서는 안되는 실수 몇가지를 팀원들과 발견했다.
1. "조회" 를 테이블로 구현하자고 결정한 것.
2. "결제" 요구사항을 아예 빼먹은 것.
회의 초반 당시, 예약 기능에 따라 예약한 내역(시설 정보와 가격 등)을 조회가능해야 한다는 이야기를 나누었다. 이에 따라 조회를 예약 기능에 잘 적용하자는 결론이 나왔고, 각 팀원들이 생각했던 "조회" 기능은 제각기 달랐었지만, 그 누구도 발표 전날까지 캐치하지 못했었다. 이 과정 속에서 "결제" 기능의 부재를 발견하여 팀원들에게 추가하자는 설득도 하였다. 소통의 부재와 점검을 꼼꼼하게 하지 못한 결과로 우리 팀은 요구사항 명세서 수정, UML 수정, ERD 수정, DDL, DML 수정까지 전부 다시 했다. 공사는 성공적으로 잘 마쳤다. 아래 사진은 결과 문서로 제출한 예약/결제 테이블이다.
4. Github 충돌로 인해 소요된 아까운 시간들 ⏳
타 팀원들과 식사를 하며 간단한 프로젝트 회고를 하던 도중, 프로젝트 관리를 Git으로 하지 않아 시간을 많이 아꼈다는 리뷰를 들었다. 프로젝트 스케일이 작고 기간도 길지 않으니 공유 프로그램을 사용하고, 굳이 Git 브랜치나 fork를 사용하지 않고 단순히 한명이 업데이트하는 방식인 저장소 역할로 사용했다는 것이다.
우리 팀이 Git을 얼마나 열심히 사용했는지 아래 사진을 보면 알 수 있다.
물론 이 방식을 채택했기 때문에 이제 더이상 깃허브에 대한 두려움이 없다. 현업 수준의 복잡성까지는 물론 경험조차 해보지 못하여 얼마나 더 복잡한 문제가 더 있을지 모르지만 캠프 기간 동안은 Git으로 두려워 했던 예전의 모습은 더이상 나오지 않을 것이라는 자신감도 생겼다. Git 문제가 생길 때마다 친절하게 알려준 (진)Git Master 팀원에게 진심으로 고맙다.
🪛 TRY
프로젝트는 나름 성공적으로 끝났고, 많은 것을 배울 수 있는 시간이라서 성취감도 느꼈다. 앞으로 시도해볼 것은 공부던, 프로젝트던 기록을 계속 남기는 것이다. 이 회고도 프로젝트를 진행하면서 기록을 남기지 않았더라면 나오지 않았을 것이다. 물론 기록해야겠다 생각하고 적어놓지 않아서 까먹고 지나간 부분도 존재한다. 하지만 시간이 지나고 이 시간을 돌아볼 유일한 방법은 결국 부족하더라도 이 글 밖에는 없을 것이다. 어쩌면 함께한 팀원들도 이 글을 통해 어느 정도 회고할 수 있지 않을까?
또 계속 지켜나갈 것은 앞으로 있을 프로젝트를 위해 꾸준하고 충분한 공부를 하는 것이다. 다른 팀원들의 결과물을 보고 정말 깜짝 놀랐다. 구경도 못해본 기능들을 사용하고 엄청난 작업량에 퀄리티 있는 프로젝트를 결과로 낸 것을 보고 아직도 정말 갈 길이 멀었다는 생각이 들었다. 주어진 것들에 안주하고 적당히 하는 것이 아니라 계속해서 달리고 달려야 평균은 하겠다라는 마음가짐으로 앞으로 임해야겠다.
긴 글을 읽어준 것에 대한 감사와 함께 회고록을 마무리 하겠다.
