🐻 221124 Today I Learned 🐻

오늘 한 줄 요약 : 더 이상 미룰 수 없다 딥러닝

(잡담?인가?…. til이 너무 짧아서… 느낀점 겸… 생각의 흐름 따라 과정…? 작성…)

---

1. 담당이 아니어도 강의를 들으려고 했지만 우선순위가 밀려 결국 딥러닝 강의를 아예 못 들었다.
2. 하지만 drf와의 연동 문제로 도움을 요청하셔서 딥러닝 파트에 살짝 발을 담ㄱ
3. 군 줄 알았는데 생각보다 딥하게 들어가 버려서 정신 차리고 보니 화면공유 켜놓고 코드를 뚝딱이고 있었다. (딥러닝이라기보단 딥러닝과 장고 연동은 맞긴 한데, 조언 정도인 줄 알았는데 그게 아니었단 느낌)
4. 처음에는 막연히 목표만 물었고 해당 목적을 수행하기 위한 코드만 기계적으로 작성하다가 뭔가 중간부터 이상함을 느껴서 정확히 무슨 데이터를 뽑아야 하는 건지, 자세한 설명은 아니더라도 이 코드가 어떤 목적으로 실행되는 건지, 딥러닝이 제대로 돌아가고 있는건지 등등 세세하게 파고들기 시작했다.
5. 이 과정에서 소통의 오류도 많았고, 모두가 딥러닝에 대한 이해가 완전하지 않은 상태라 어려움이 많았다.
6. 딥러닝 코드 짜기 전에 딥러닝을 활용하기 위한 이미지 업로드 기능이 필요하대서 그걸 짜고 그 다음 딥러닝부터 같이 하기 시작했는데, 이미지 업로드 기능 구현 시간을 제하고도 일곱 시간 동안이나 코드를 짰지만 결과물은 0.
7. 난 이미 3일 내내 새벽 4시 넘어서 자서 9시에 일어나는 짓을 반복하고 있었기 떄문에, 그리고 다른 두 분도 힘들어 보여서 그 날은 거기에서 스탑. 한 분께 리소스 수집을 부탁드렸고 다른 한 분께는 다음날 튜터님께 질문 드리기를 부탁드리고 퇴근했다.
8. 다음날이 되어 다시 초기화된 코드를 가지고 코딩 시작
9. 클래스가 아닌 디파인 함수로 구현해볼까도 생각햅 봤고, 로직상 데이터베이스에 사진이 먼저 들어가고, 사진이 변환된 다음 데이터 베이스에 들어가는 형태라 post 방식으로 사진 업로드 후 put 방식으로 수정도 생각해 봤다.
10. 하지만 한 번에 처리하고 싶은 마음에 한 번에 처리하길 시도.
11. 서두가 결론보다 길어졌는데, 본론만 짧게 말하자면 성공했다. 근데 .save()가 사실상 생성과 수정 둘 다 상황에 따라 구분해서 하는 애라서, 무늬만 post방식이고 사실상 post → put 두 번 하는 거나 다름 없달까…
12. 그래도 요청을 한 번만 하니까 이게 더 낫나…? 아님 너무 지저분한 코드라면 나중에 리팩토링을 위해서라도 post방식, put방식으로 해야 하나? 아님 방식을 구분하되 한 번 요청할 때 두 번 다 돌 수 있는 방법이 있나?
13. 궁금한 게 많았지만 TIL 정리도 해야하고(메모만 해두고 프젝 때는 쓰질 못하겠다 에휴…), 에러 해결하면서 발견한 공부 자료들도 잔뜩 밀렸다. 팀장이라 배포 준비도 해야 하고…
14. 더욱이 주말에 생일이다. 그래도 생일엔 쉬게 해 줘…. 딥러닝 예상 시간이 화요일 마감이었던지라 주말에 놀아도 될만큼 빡세게 해두었는데, 딥러닝 때문에 다 밀렸다 뎬댱!
15. 여튼 그래도 전혀 기반 지식이 없는 코드를 이해하는 경험 나쁘지 않았다. 일하다보면 항상 내가 다 아는 것만 만나게 되진 않을테니까. 좀 극단적인 케이스를 만났다고 치자…
16. 오류를 만나면서 파이썬의 오브젝트와 쿼리셋에 관한 것도 개념이 좀 잡혔다. 맨날 []로 가져올지 .로 가져올지 헷갈렸는데 그것도 좀 정리됐고.
17. 지금까지 방식 하나에 시리얼라이저를 한 개만 써와서 막연히 그런 줄 알았는데, 막상 쓸 상황이 되니 평소에 한 개만 서야 돼!라고 생각했던 것과 달리 급하니까 이론상 안 될 이유가 없는데…? 싶어서 썼는데 돼서 신기하기도 하고, 알아보기도 전에 무의식 중에 결론 내리는 걸 좀 방지해야겠다 싶더라. 무의식 중인데 어케 컨트롤하지
18. drf 공식문서 시리얼라이저 부분 완전 극 초반만 읽었는데(프젝 끝나면 꼭 읽어야겠다… 계속 시간이 없어서 미루고 미루다보니 아직도 못 읽고있다…), save가 데이터 존재 여부에 따라 create도 하고 update도 할 줄 안다는 걸 거기서 알았다. 한 5~10분 읽은 거 같은데 이번 프로젝트에 잘 써먹었다.
19. 역시 공식문서는 중요하다. 프젝 끝나면 진짜 꼭 읽을 거다.
20. save할 땐 데이터베이스의 테이블의 필드명으로 들어가고, request에 데이터를 담을 때 key값의 이름은 모델링의 필드명 기준으로 들어가는 모양이다. 데이터 넣을 때랑 뽑아오는 걸 자세히 봐보니 그랬다.
21. 왜 자세히 봤냐면… painter, painting, picture, paint, pinter_id, painting_id 등 변수가 너무 혼란스러웠다… 변수명 짓는 게 왜 중요한지도 깨닫고 간다.
22. 기능 구현 자체에 좋게 말하면 몰입, 나쁘기 말하면 매몰될 수밖에 없는 상황이었던지라 공부할 자료 링크만 잔뜩 저장해두고 트러블 슈팅을 거의 못 했는데, 공부하다보면 상기될 것 같다 프젝 끝나고나서.
23. 아 기능 하나에만 매몰되어 있다보면 당연한 사실을 놓친다는 것도 깨달았다.
24. db 저장까지 하고 response가 원하는대로 안 나와서 계속 그걸 고치고 있었는데, 고치자니 방식이 더러울 거 같고 안 고치자니 그러면 아 될 거 같아 고치고 있었는데 생각해보니 db에만 쌓으면 어차피 get으로 들고 올 건데 문제가 무엇…? response 뽑아먹으려고 한 줄짜리를 기이일게도 늘려놨는데 튜터님이 그냥 한 줄만 쓰면 되지 않나요? 라고 해서, 그게 너무 기초적인 거라 너무 부끄러웠다.

그래서 결론적으로 알게 된 것들

---

• 아직 트러블 슈팅은 못했고, 정리도 아직 못 해서 더 있을 수도 있긴 한데, 일단 요약하면 아래의 것들을 알게 됐다. 개수가 적어서 뭐 없어 보이는데 저 중 한가지 개념에 와닿기 위해서 꽤 많은 에러를 해결해야만 했다.

1. model instance랑 model object는 사실상 같은 애다.
2. 예에에에ㅔㅔㅔ전에 공부하고 잊고 살던 클래스의 super().의 쓰임을 다시 상기했다.
3. 프론트 쪽에서는 css로 이미지 경로 바꾸는 거나 이미지 슬라이딩 기능 등 짜잘하게 알게 됐다. fetch 써서 버튼에 기능 연동하는 것도 저번 프로젝트랑 달리 금방 끝냈고. (근데 딥러닝과 연관된 기능을 여태 내내 못해서, 그니까 주요 기능을 거의 다 못해서 그런 것도 있다.. 생일에 코딩 확정)
4. 객체지향의 특징인 캡슐화나 추상화 등을 찾아봤는데, 처음 들었을 때는 이해가 되지 않던 것이 여러 프로젝트를 거치며 계속 사용해오다 다시 찾아서 읽어보니 예전보단 이해가 잘 됐다. 나중에 보면 또 더 이해가 잘 되길 바라본다.
5. save할 땐 데이터베이스의 테이블의 필드명으로 들어가고, request에 데이터를 담을 때 key값의 이름은 모델링의 필드명 기준으로 들어가는 모양이다. 데이터 넣을 때랑 뽑아오는 걸 자세히 봐보니 그랬다.
6. 시리얼라이저는 많아도 상관 없다.
7. 왜 안 된다고 생각했는지 의문이지만, 하나의 클래스 안에서 시리얼라이저 여러 개 써도 된다.