Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
Assignment 6 - TIL (2022. 5. 19.)
by pksl
#pragmatic
2년 전
929

오늘의 TIL 3줄 요약

  1. 가정문을 테스트 코드 이외의 영역에서도 활용해보자.

  2. 리소스의 관리야 두말할 것 없이 중요하고, 리소스의 균형잡기에 대해서도 계속 생각하자.

  3. 예측할 수 없는 미래, 신중하게 작은 단계들을 차근차근 밟아나가며 진행하자.

TIL (Today I Learned) 날짜

2022-05-19

오늘 읽은 범위

  • 4장. 실용주의 편집증 (p.145 ~ p.180)

책갈피

  • 실용주의 프로그래머는 자기 자신 역시 믿지 않는다. (p.146)

  • 상식과 정직만큼 사람을 놀라게 하는 건 없다. - Ralph Waldo Emerson (p.147)

  • 문제를 찾고 원인을 밝히기 위해서는 사고가 난 지점에서 일찍 멈추는 것이 유리하다. (p.155)

  • ‘있을 수 없는 일’이 발생했을 때 우리는 그 사실을 알아야 한다. (p.159)

  • 실용주의 프로그래머는 만약 오류가 발생했다면 정말로 뭔가 나쁜 일이 생긴 것이라고 자신에게 이야기한다. (p.159)

  • ‘하지만 물론 그런 일은 절대 일어나지 않을 거야.’ 라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라. (p.162 ~ p.163)

  • 프로그램을 출시할 때 단정 기능을 꺼 버리는 것은 줄타기 곡예를 하면서 연습으로 한 번 건너 봤다고 그물 없이 건너는 것과 비슷하다. 극적인 가치야 있겠지만 생명 보험을 들기는 어렵다. (p.165)

  • 자신이 시작한 것은 자신이 끝내라. (p.167)

  • 언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. ‘너무 큰' 단계나 작업은 하지 않게 될 것이다. (p.178)

오늘 읽은 소감

우리는 프로그래밍을 하면서 데이터를 가공하거나 계산하고 출력하며 저장한다. 그 과정에서 중간중간 데이터의 값을 꼼꼼하게 검증(Validation)하지 않을 경우, 문제가 발생했을 때 그냥 단순하게 Exception만 뱉어낸다면 그나마 다행이지만, 잘못된 데이터가 스토리지에 그대로 입력되어버리거나, 그로 인해 해킹되거나 한다면 정말 세상이 미워질 것만 같다. 그런 불상사를 막기 위해 늘 우리는 안전장치(검증 코드)를 열심히 작성하곤 한다.

예시가 상당히 비약됐지만, [Topic 23. 계약에 의한 설계]의 DBC라는 용어는 책을 통해 처음 접해봤는데 내용을 찬찬히 뜯어보니, 이처럼 엄격한 ‘검증’을 ‘계약’으로 포장한 일반적인 프로그래밍 방식이라고 이해했다.

하지만 책에도 잘 설명되어있듯이 DBC 프로그래밍 방식은 굉장히 많은 고민과 생각을 갖게 만드는지라 무척 피곤하다. 보다 엄격하게 데이터가 관리되어야 할 영역과 그렇지 않은 영역을 잘 구분해서 취사선택해 설계하는 게 올바른 방법이지 않을까 생각한다.

<수정>

다른분들이 작성해주신 TIL들을 읽다 보니 DBC에 관해서 완전히 헛다리 짚었다는 걸 알았다.

처음에 [Topic 23. 계약에 의한 설계]에 적혀있던 선행 조건, 후행 조건, 클래스 불변식에 대해 대충 읽고는, 예시 코드 두 개만 덜렁 보고 ‘대충 저런 거구나~’ 하고 DBC는 ‘방법론’으로 넘겨짚었는데, 다시 알아보니 위의 세 조건은 DBC라는 구현체가 성립되기 위한 ‘계약’의 필요충분조건들이었다.

이러면 완전 처음 접하는 것이므로 다른 언어들의 DBC 구현체들을 각각 찾아보고 어떻게 적용했는지 한번 확인해봐야겠다. ( + 꼼꼼히 읽자)

</수정>

입사 초기에는 DB에 관한 지식이 겨우 CRUD 레벨의 기초여서, 새로이 추가했던 기능의 쿼리(SQL문)를 충분히 최적화하지 않고 배포를 진행했던 일이 있다. 당연히 피크 타임에 사용자가 몰리니 서비스가 피를 토하기 시작했다.

앱을 켜두고 페이지를 전환하는데 30초 이상씩 걸리고, 식은땀이 벌벌 떨리고 손발이 줄줄 샜었다. 지금 와서 생각해보면 원인을 잘 모를 때는 바로 이전에 추가한 기능부터 롤백해봤으면 됐는데, 그냥 에러 고쳐보겠다고 계속 앞으로 나아가기만 하면서 문제를 며칠간 질질 끌다 쿼리를 개선하면서 겨우 해결했었다. 그 과정에서 핏기가 가신 얼굴로 몇 차례 서버 재부팅과 DB 재부팅을 했던 씁쓸한 기억이 [Topic 24. 죽은 프로그램은 거짓말을 하지 않는다]‘망치지 말고 멈춰라’를 읽으면서 떠올랐다. 아, 서버 재부팅, DB 재부팅의 효과는 거의 없었다.

마침 DB에 관련된 이슈를 꺼냈으니.. DB 부하는 애초에 발생시키지 않는 게 최선이지만, 발생한다면 DB 부하가 관련된 이슈는 3장 TIL에서 적어본 Sentry 같은 오류 모니터링 서비스나, 일반적인 에러 로그로는 확인하기 어렵다. 그냥 DB 커넥션 에러 정도로만 뜨고, 원인은 DB에서 찾아야 하기 때문이다. 하지만 부하가 이미 걸려있는 상황이면 DB에 접근하기도 사실상 어렵다. 따라서 성능에 관해 모니터링을 설정해두는 게 중요하다.

만약 AWS같은 클라우드 서비스를 이용 중이라면 사실 서비스 내에서 제공하는 모니터링 서비스(ex. AWS CloudWatch)만으로도 충분하지만, 조금 더 나아가 NewRelic같은 퍼포먼스 모니터링 서비스도 함께 도입해보는 것도 좋다고 생각한다. 간단한 설정만으로도 해당 서비스에 접근한 사용자들이 요청에 접근한 시간, 코드가 수행된 시간, DB가 수행된 시간, 캐싱 시스템이 수행된 시간, 응답을 전달하는데 걸린 시간 등에 대한 평균값을 지표로 보여주며, 가장 처리가 오래 걸린 페이지 순위, 가장 접근이 많았던 페이지 순위 등 여러 가지 데이터를 볼 수 있기도 하다. (Sentry와 마찬가지로 소규모 트래픽은 무료로 이용할 수 있다)

갑자기 딴길로 샜다..

ㅋㅋㅋㅋ [Topic 25. 단정적 프로그래밍]의 서론부터 읽으면서 많이 웃었다. 머리로는 잘 아는척하면서 매사 적당 적당하게 ‘저건 저렇게 될 리가 없어.’ 하고 넘어가기 부지기수였다. 오늘도 이렇게 자기반성의 시간을 가진다.

오픈소스들 이외의 소스를 본 경험이 거의 없다시피 해서, 이렇게 assert 가 테스트 코드 이외에도 사용되는 경우를 처음 봐서 신기했다. 특히 위의 책갈피에도 걸어놨듯이 ‘단정 기능을 켜 둬라’에서 적어준 예시와 내용 하나하나가 굉장히 설득력 있게 다가왔다. 당장 현재 프로젝트에서 데이터 처리 코드 중 적용해볼 만한 곳이 있나 검토해볼 가치가 있을 것 같다.

[Topic 26. 리소스 사용의 균형]에서 아주 중요한 것을 다뤄줬다. 프로세스를 넘어 로그 파일, 데이터베이스.. 모든 활용되는 데이터가 전부 리소스이며, 이들 전부를 균형을 잡아가며 관리하는 건 엄청난 에너지를 소모하는 일이다. 그리고 대부분 리소스는 코드에 비해서 문제가 발생했을 때 추적하기 어려운 부분이 있다. 4장 중에서 개인적으로 가장 두고두고 읽어볼 토픽이라 생각한다.

가만히 앉아서 생각해보니 확장성을 고려한다고 설계한 것들이, 그냥 넓은 공터로 남아있는 케이스가 많았다는 걸 깨닫곤 한다. 하지만 그렇다고 미래를 아예 대비하지 않으면 자신이 갈려 나가거나, 다음 사람에 넘기는 폭탄 돌리기가 되어버린다.

미래를 대비하는 가장 효과적인 방법은 2장에서 다룬 것처럼 ETC 원칙을 잘 지키는 것이라고 [Topic 27. 헤드라이트를 앞서가지 말라]에서 다시 한번 짚어주었다. 책갈피에도 써두었지만 다시 한번 강조하고 싶은 문단이 있어 타이핑해본다.

언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. ‘너무 큰' 단계나 작업은 하지 않게 될 것이다. (p.178)

오늘 읽은 다른사람의 TIL

  • 못읽었던 3장 TIL