기술적인 고찰

AWS에 설치한 Oracle

이번 프로젝트에서 다양한 라이브러리와 툴을 사용해보았다. 이전부터 구상하던 것이었지만 팀원 모두가 접근할 수 있도록  AWS에 오라클 데이터베이스를 설치하여 사용하였다. 사실 RDS를 사용하고 싶었지만 기존에 사용하던 오라클 버전을 지원하지 않는다는 문제로 인해서 어쩔 수 없이 AWS에 오라클을 설치하였다.

 

AWS의 OS는 우분투 20.04를 사용하였다. 윈도우를 사용하면 편했겠지만 공부를 위해선 우분투를 택하는게 낫다고 판단하였다. 이전에 메타코딩 aws 강의를 들었던 기억으로 서버 구축이랑 고정 IP 할당하는 것은 쉽게 할 수 있었다. 리눅스 명령어로 오라클 설치하고 포트 포워딩 하는데 온갖 고민거리가 많았지만 반나절 고민하고 구글링하니까 자연스럽게 해결되었다.

 

aws 우분투는 처음에 movaexterm으로 접속하면 ubuntu라는 계정으로 접속해야 한다. 나는 무언가의 권한 에러를 우려해서 처음부터 root 계정을 뚫었다. root 계정 뚫는것도 기본적으로 막혀 있었지만 어찌어찌해서 뚫는데 성공하였다. 그렇게 무사히 오라클 설치를 완료하고 sql developer까지 접속하였다. 고정아이피를 뚫기 전에 인스턴스를 중지시키니까 당연히 IP가 바뀌는 것을 확인하고 고정아이피를 뚫었다. 근데 오라클이 접속이 되지 않아서 이것도 몇시간 고민했는데 그냥 스쳐지나간 검색이 해답을 주었다.

 

"oracle 계정으로 접속하라"는게 답인데 이게 뭔가 고민하는데 알고보니 리눅스 oracle 계정이 따로 있었다는 것이다. 뭔가 다른 방화벽 문제인줄 알았는데 그게 아니니 안도의 한숨을 쉬었다. 누군가 여기선 방화벽 때문에 접속이 안될거란 말이 있어서 더 그랬을 것이다. 

 

AWS 오라클은 뚫어논 것은 사실 프로젝트 시작초였으나 사용한 것은 프로젝트 끝나기 5일전이다. 미리 사용하기엔 DB 테이블 정의 작업이 완전치 못했고 기능정의가 모호하였다. "여기서 바로 테이블 생성하고 쓰기엔 온갖 수정사항이 생길 것이다." 라고 생각했다. 최대한 미루고 미뤘는데 그래도 계속 테이블 수정이 발생되던건 어쩔수 없나보다..

 

AWS DB 덕분에 학원 PC를 따로 파서 굳이 작업을 하지 않아도 되었다. 근데 이게 혼자 작업할 때는 정말 편한거같다. 문제는 여러명이서 동시에 접속해서 작업할 때이다. AWS 인스턴스 가용 메모리가 1GB여서 동시에 많은 쿼리가 오면 뻗어버린다. 내가 하필 그 때 이용자 정보 기능 테스트하느라 480개의 레코드를 새로고침을 하였고 동시에 다른 팀원들도 테스트를 하였나본데 어느 순간 DB가 멈춰버렸다. 처음엔 당황했는데 30분 넘게도 안돌아와서 그냥 인스턴스 중지시키고 다시 틀었다. 근데 똑같이 DB 접속이 안되서 oracle 계정으로 뚫었다. 이렇게 문제는 항상 반복되나 싶었다... 여기서 배운 교훈은 AWS에 설치한 오라클로 팀작업시 테스트는 따로따로.... 하자....는 것...

 

Figma

UI 화면 디자인을 피그마로 하였다. 왜 피그마로 했냐면 원래 파워 포인트로 하다가 갑자기 다른팀에서 피그잼으로 하였다길래 우리도 피그잼으로 하려다가 피그잼은 html 추출이 안된다는 말듣고 피그마로 바꿨다. 피그마는 여러명이서 동시에 접속하여 협업이 가능하고 teleportHQ라는 플러그인으로 디자인한 레이아웃을 html로 추출이 가능하다. 문제 문제는 타히트한 레아이웃이 잡혀야하고 클래스명을 ui 디자인시에 직접 지정해줘야 했다는 것이다. 사실상 초보자는 능숙하기 쓰기 불편하였다. 어떤 친구는 그걸 뽑아서 쓰기도 했는데 html 클래스명이 진짜 보기가 이상할 정도였다. 그리고 구조도 원래 디자인한거와 다른게 많았다. 이렇게까지 써야 하나 싶어서 다시 부트스트랩으로 돌아와서 디자인하였다. 근데 피그마로 디자인 한거라도 있으니 부트스트랩으로 클론코딩하는거마냥 뽑으니 어느정도 디자인의 혈은 뚤렸었다. 디자인이 늘 고민이다. 항상.. 그래도 피그마에 발한번 담근거 다음 프로젝트 모바일 화면 디자인할 때는 써봐야겠다.

 

Erdcloud

2차 때 DB 작업 하는게 매우 답답하였다. 나는 2차 때도 모두가 DB 설계를 해보길 바랬다. 근데 그렇게 되진 못했던거 같다. 그래서 이번엔 모두가 작업하는 상황을 구상했다. erdCloud라는게 있는데 한번 써보자고 했다. 대충 한번 써보고 사용법 알려줘보고 같이 써봤는데 대강 틀 그리는데 4~6시간 걸렸나 싶다. DDL 추출도 되니 바로 이제 DB 끝? 이랬는데 FK제약조건은 왜 안걸려있고 왜 테이블명이랑 컬럼명은 " "들어가서 생성되있는건가...? 그래서 결국 뒷작업하느라 애좀 많이 먹었다는 것... 그래도 이 툴은 정말 좋고 편했다. 화면도 공용이서 쓰기 좋았고 DB 작업 같이한다는게 낭만 아닌가? 그리고 변경사항 바로바로 반영해서 ddl 고치고 하는건 많이 편했다. 

 

Github

나는 git에 대해 완벽하게 안다고 말하지 못한다. 생활코딩 강의랑 메타코딩 git 강의를 보고 배우긴 했는데 실제로 프로젝트에 제대로 적용은 하지 못했다. 이번 프로젝트 때 처음 적용했는데 나도 팀원들에게 알려주면서 많이 배웠다. HEAD가 attach 되는 상황에서의 해결법 등... 작업을 정해진 기준에 따라서 작업만 한다면 문제는 일어나지 않는다. 근데 예를 들면 develop에서 머지 후에 자기 브렌치로 돌아가지 않고 develop에서 작업하고 커밋한다든지 이러면 문제인거다. 아니면 실수로 HEAD 위치를 바꿔버린다던가 한 사람이 삭제한 것도 커밋해버리면 문제인거다. git은 여러 사람중 누가 팀장인지 모른다. 추적된 파일에 대한 삭제 또한 기록한다는 것. 그리고 merge를 너무너무너무 늦게한 사람이라면 그사람 gitignore에 내용 추가가 안되어서 늦게 merge 되버리면 또 갑자기 파일이 추적되는 경우도 있다. 그리고 프로젝트 중간에 어떤 친구가 작업한 파일이 다 날라갔다고 말하는 상황이 있었으나 알고보니 따로 클론한 저장소랑 현재 작업하고 있던 저장소랑 헷갈려서 파일이 날라간줄 알았던것이다... 그래도 그걸 찾았다는게 다행이었다. 못찾았으면 멘탈이... 완전 ...

여러 상황 다 보았지만 그래도 commit과 자기 브랜치에 push는 미리미리 해놓고 로컬에 브랜치를 날려버려 해결하면 아무 문제없다.

추가로 했으면 하는 것 

AWS 배포, 파일 서버필요

사실은 AWS를 처음 인스턴스를 받았을 때부터 웹프로젝트를 배포해야 겠다는 생각은 있었으나... 프로젝트 특성상 이미지 업로드와 로드가 빈번한 상황이 올거를 예상하고 배포까진 못했다. 그리고 파일서버가 하나 필요하다고 생각했다. 파일 업로드 구현시 파일은 빌드된 폴더 안쪽으로 저장된다. 이것을 하나의 파일서버로 올려두면 팀작업시 수월할 것이다. 근데 이게 안되니 파일공유가 안되는 아쉬움이 있었다. 

추가적인 라이브러리 사용

이번 프로젝트에서 못쓴 라이브러리가 몇개 있다. 결제 API나 sumernote는 좀 쓰고 싶었다. 근데 내가 한번 구현하고 프로젝트에 넣어보고 싶었으나 사실 그럴시간이 없었다. 그래도 메일 api나 캘린더 api는 한번 써봤다. 그리고 부트스트랩 템플릿에 딸려있는 테이블 api는 매우 좋았다. 페이징 구현이 따로 필요없는 테이블... 하지만 이거 때문에 오라클 DB가 뻗어버림 하.. 못쓴 라이브러리나 좀더 알아야할 라이브러리는 다음 프로젝트를 기약하자.