2021-04-16-TIL

게시 2021/04/16 수정 2026/10/07 작성자 August

조회 8 분 읽는 시간

2026-10-07 docs(posts): separate the sections of every post with a thematic break +12 −0
2026-10-06 docs(til): turn the bookmark-only tils into notes (part 3) +50 −37
2021-04-16 처음 게시

프로젝트 데모 활동이 있는 날입니다. 데모는 가볍게 어떤 것을 의도해서 어떤 것을 만들었는지 공유해주세요. 덧붙여서 팀활동을 하면서 기술적인 도전, 힘들었지만 극복했던 에피소드, 가장 잘한 일이 무엇인지 팀 활동에서 자랑거리 1-2개를 소개해주세요.

발표 대본

안녕하세요? team08의 발표를 맡게 된 august입니다. 우선 간단한 설명 후 데모를 하도록 하겠습니다.

시나리오

각 card의 action(add, remove, move, update)에 대해서 수행한 후, 히스토리 목록을 보여준다.
웹 페이지 상에서 실제 데이터가 같다는 것을 /api/histories와 /api/cards를 통해 확인한다.

프런트엔드 회고

어려웠던 점:

조별과제이므로, BE가 완성된 기능을 구현하였는데, FE에서 사용을 못하는 경우가 두려워 빠르게 구현해야 했음. 때문에, 좋은 설계 구조와 확장성, 재사용성을 충분히 갖춘 method를 구현하는 데 소홀했다.
충분한 학습을 진행하기 어려웠던 점.
codeConvention을 어느 정도까지 deep하게 정해야 하는지

좋았던 점:

FE, BE가 협의가 필요했던 api 및 data의 설계를 Issue화하여 서로 충분한 이해와 명확한 설계 목표를 가질 수 있었던 점.
gather나 project 협업 방식을 BE에서 전해 받았는데 선진 문물을 받은 느낌

백엔드에서 어려웠던 점

boolean 타입을 받는 문제 -> 쿼리문을 직접 작성하여 해결
aws 서버와 로컬의 MySQL 환경 불일치로 인한 각종 문제들(upper case 등)

boolean 문제에 쓴 쿼리는 다음과 같다. 원래 인라인 코드로 적었는데 쿼리 안의 백틱과 겹쳐 마크다운이 깨져서 코드 블록으로 옮겼다.

  
@Query("SELECT CID, CARDID, TITLE, CONTENT, `DATE`, POS, COLUMNID, AUTHOR, IF(`CARD`.ISAPP, 'true', 'false') as ISAPP from `CARD` WHERE CARDID=:cardId;")

MySQL에는 별도의 boolean 타입이 없다. MySQL 문서에 따르면 BOOL과 BOOLEAN은 TINYINT로 매핑되고, 테이블을 만들면 tinyint(1) 컬럼이 된다. 그래서 컬럼 값은 0과 1로 돌아오고, 문자열 'true'/'false'를 기대하는 쪽과 맞추려고 IF()로 변환한 것이다.

upper case 문제는 테이블 이름의 대소문자 구분이 운영체제에 따라 다르기 때문에 생긴다. lower_case_table_names의 기본값이 Unix 계열은 0(대소문자 구분), Windows는 1, macOS는 2라서 로컬 macOS에서 되던 쿼리가 Linux 서버에서는 테이블을 찾지 못할 수 있다. MySQL 문서는 이식성을 위해 DB와 테이블 이름을 항상 소문자로 만들고 참조하라고 권하며, 이 값은 서버를 초기화할 때만 설정할 수 있다.

기능 명세

하나의 VC로 3개의 column을 컨트롤함.
각 column의 + 버튼을 눌러 등록 modal을 띄울 수 있고, 이를 통해 셀의 title과 content를 넣어 새로운 card를 등록할 수 있음.
card를 슬라이드하여 제거할 수 있음.
드래그 앤 드롭을 사용하여 이동 가능함.
최신 순 정렬을 구현하기 위해, position이라는 변수가 cardData에 존재. 이를 기준으로 카드를 정렬함. 각 카드들은 추가될 경우 맨 위에 생성됨, 이는 최신 순 정렬에 속한 기능. 두 기능을 통하여 최신 순으로 정렬하며, 사용자가 원하는 대로 이동한 결과를 저장함. 이는, trello에서 사용된 알고리즘을 참조하여 구현된 내용임.
우측 상단의 3line 버튼을 눌러 히스토리를 확인할 수 있음. 히스토리를 transition하는 방법은 여러 방법 중 mainView 위에 HistoryView를 만들어 animation을 부여함. 버튼을 누를 때마다 DB에서 history data를 가져와 확인. 사용자 사진과 name은 제외. 얼마 전에 실행된 내용인지 확인 가능.
context 메뉴의 기능은 위의 기능들을 종합하여 실행됨.

데모 시나리오

공팔이는 해야 할 일, 하고 있는 일, 완료한 일을 구분하여 관리하고 싶다.
‘공부하기’라는 카드를 해야 할 일(ToDo) 목록에 추가한다.
‘운동하기’라는 카드를 해야 할 일(ToDo) 목록에 추가한다.
공부를 하기로 결정하고 ‘공부하기’를 Doing으로 이동한다.
공부를 할 시간이 부족해서 ‘운동하기’를 포기하기로 결정해서 삭제를 했다.
‘요리하기’, ‘밥먹긔’를 하면 추가된 순서가 최신 순으로 유지되는 것을 볼 수 있다.
오늘 한 일들을 보기 위해 히스토리 목록을 보면 잘 반영이 되어있다.
‘밥먹긔’를 잘못 입력하여 ‘밥먹기’로 카드 수정을 한다.
Doing에 있던 ‘공부하기’를 완료하여 꾹 눌러서 완료한 일로 이동시킨다. 나머지도 모두 완료했다. 오늘 하루 끝.

마치며

아무쪼록 싸우지 않고 잘 마무리되어서 다행이다. 어제 마지막으로 성공적인 연동을 마치고 최종 테스트를 성공했을 때의 희열은 한 편의 드라마 같았습니다. 마치 인터스텔라의 도킹 장면처럼.. 이 맛에 개발하고 협업하는구나 했습니다. 발표자료를 준비하면서 회고를 할 수 있어서 좋았다.

참고한 자료외부 출처 2

외부 출처

Identifier Case SensitivityMySQL 8.0 Reference Manual
Using Data Types from Other Database EnginesMySQL 8.0 Reference Manual

TIL, 2021-TIL

TIL