SOPT, 특히 앱잼을 진행하면서 협업이 왜 좋은지 참 여러번 깨닫는 것 같다. 첫번째 깨달음은 서버와 클라이언트의 분리였다. 클라이언트에서 프론트만 담당하고 서버에서 api를 만들고 서로 통신하며 서비스를 구성하는 것이 나에게는 신선했다. 나는 이렇게 두 개를 나누지않고 한번에(?) 하는 것이 좀 더 익숙했기 때문이다. 하지만 이 방식이 참 좋다고 느꼈다. 두번째 깨달음은 세상에 참 실력좋고 경험많고 머리좋은 사람이 많다는 것이었다. 물론 원래 머리로도 이건 알고 있었다. 하지만 앱잼을 진행하며 더 크게 느끼는 것 같다. 가장 크게 느꼈던 두가지 사례가 있다. 첫번 째는 하나의 문제에 대해서 나는 A라는 방안을 내었고 이것이 최선이라고 생각했다. 하지만 다른 팀원이 B라는 방안을 내었는데 이야기를 들어보니 너무나 합리적이었다. 내가 낸 A는 유저가 적은 수정을 원할 경우 데이터베이스에 write하는 소요를 좀 줄일 수 있다. 그렇기에 난 원래 기획의도와 디자인과 조금 다르더라도 A라는 방안이 효과적이라고 생각했다. 하지만 다른 팀원이 낸 B의 근거는 확실했다. 내 A는 사실 write의 소요를 조금 줄일지 몰라도 수정사항이 많을 수록 클라이언트와 서버의 여러번의 통신이 필요했다. 그것을 고려해봤을때 B는 기획의도와 디자인을 유지하면서도 A에 비해 크게 부족함이 없는(오히려 더 나은?) 좋은 방안이였다. 듣고 그 방안을 이해했을때 정말 뭔가 큰 영감을 받은 것 같았고 기분이 좋았다. 이게 협업하며 함께 성장한다는 것인가 싶었다. 두번째 사례는 EC2사용에 대한 팁을 들었을 때이다. 사실 나는 AWS에 대한 사용법을 SOPT를 진행하며 거의 처음 배웠다. 그래서 EC2에 대한 활용이 어색해서 그런지 나는 EC2의 인스턴스 하나에는 하나의 서비스! 라는 생각을 가지고 있었다. 근데 오늘 같이 개발하는 팀원이 그냥 포트만 다르게 열어놓으면 하나의 인스턴스에 하나 이상의 서비스를 올릴 수 있다는 것을 말해주었다. 이때도 정말 큰 걸 배운 것 같았고 기분이 좋았다. 앱잼은 서비스를 만들어내는 것 외에도 참 많은 것을 배울 수 있는 좋은 프로그램인 것 같다는 생각을 했다.
물론 다들 그러겠지만 데이터베이스를 설계할 때는 참 많은 고민을 해야하는 것 같다. 각 테이블의 컬럼, 자료형, 속성, 테이블사이의 관계등 참 복잡하다. 그리고 이것을 잘못짜놓으면 api구현 때 문제가 생길 수 있으서 대충할 수도 없다. 물론 깔끔하게 잘 짜놓으면 너무 뿌듯하고 구현할 때 편하지만, 만드는 서비스가 클수록 데이터베이스 설계 난이도가 상당히 올라가는 것 같다. 이번에도 나름 최선을 다해서 데이터베이스를 설계하고 구현했지만 솔직히 문제가 없을 것이라 다짐할 수가 없다.(껄껄껄...) 물론 최대한 많은 경우의 수와 우리가 구현해야할 부분들을 고려하여 만들었지만 내가 놓친 부분이 있을 수 있기에... 하지만 어차피 만들면서 문제가 생길 때마다 바로바로 수정할 생각이기에 괜찮을 것 같긴하다. 별 문제가 안생기기를 바란다...ㅎ.ㅎ