TIL 1

AI와 디버깅

AI 써서 못해진 것 같다는 느낌 받음 => 기존에 구현할 때 고민을 많이 안하고 구현하다보니 나중에 디버깅 할 때 골머리를 앓을 때가 많음. => mongodb mocking하는 부분이 처음에 고민을 많이하지 않고 만들다보니 수정할 때 지식이 부족해서 난감함

  • 디버깅을 훨씬 빠르게 하다보니 디버깅 능력이 퇴화됨. 전보다 쌩 디버깅할 때 머리 회전 속도가 많이 느려진듯. 원인 더 고민해봐야함.

디버깅을 훨씬 잘해지는 방법을 모색해봐야할듯. 디버깅에 예측되지 않은 시간이 꽤 많이 소모됨. 디버깅 자체를 프레임워크화를 해서 매우 빠르게 디버깅하는 프로세스를 갖추어야함.

파이썬 버리자고 했는데 번복해야할듯

3달 전에 모든 레포 js로 다 가야한다라고 논쟁했었는데 몇 달만에 python을 쓸 수 밖에 없는 상황에 봉착함. 수십개의 csv를 머징하는 작업은 python으로 하는것이 매우 합리적이어보임. 당시에는 js로 가볍게 가는 방식이었음. 3달 전에는 csv가 많아질거다라는 이야기 자체가 없었음. 그리고 prefect로 모든 걸 다 orchestrate하는 등의 이야기가 많았음.

dagster로 하느게 맞을듯.

당시에는 python메인으로 가고 js를 뭔가 하위 서브프로세스로 돌리는 걸 이야기했는데, 그러면 너무 복잡하고 어려우니, js 서버랑 MQ로 연결하는 것이 현재로서는 더 편해보임. => 아마 이게 더 디버깅이 쉬울 것 같은데 다들 어떤 의견일지 궁금함.


TIL 2

prefect vs dagster?

prefect 말고 dagster 써야할 이유가 있나? prefetch vs dagster 고민해보기

디버거 쓰면 디버깅이 빠르고 다른분들도 훨씬 많이 썼으면 좋겠다는 동료분의 말에 몇 주 동안 무조건 디버거 써서 디버깅 진행하는 것으로 하겠다고 말씀드렸음.

유닛 테스트 vs 통합 테스트

유닛 테스트와 통합 테스트에 대해 1시간 토론함 모두가 동의한 결론:

  • <1>testability
    • 현재 테스트들이 테스팅하는 코드들이 응집도가 낮고 결합도가 높아서 integration test가 깨질 때 고치는 것이 힘듦.
    • 그래서 원래 코드가 더 테스터블하게 수정되어야함
  • <2> 테스트는 더 빨라야함

순재님은 엄청 원칙을 중요시하는데 => 나는 이건 참고용 가이드라인이지 실제로 원칙이 되어서는 안된다고 생각함.

어쩔 수 없이 실무에서는 넘어가는 일이 많아서 원칙을 모두 준수하다가는 사실상 개발이 불가함... 영원한 토론이 이어질 뿐임. 우리가 실력이 부족해서 쓰자마자 부채 비율이 50%가 넘어가는 것 뿐임. 잘해지면 부채 비율이 낮아지는 것...


TIL 4

<1>액셀로 작업 회고

excel screenshot 내가 실제 한 작업을 시간 별로 정리한 액셀
  • 저번주 부터 제대로 리니어에 시간 산정 등을 하기로 개발팀 레벨에서 모두 합의함.

  • 저번주에 처리해낸 티켓이 20시간 밖에 안되어서 너무 충격적이어서 병목을 분석하고자 이번주는 위와 같이 액셀로 모든 시간을 실시간으로 기록하며 일함.

  • 병목을 자세히 분석할 수 있었음.

  • 장기적으로는 줄일 수 있는 회의와 갑자기 치고 들어오는 티켓들이 있었음.

  • 결론적으로는 주황색과 핑크색을 줄일 수 있어보였고, 몇 주 더 위와 같이 액셀로 정리하는 것을 습관화해서 계속해서 개선할 수 있도록 해야할듯.

  • 재미있는 점은 위 표를 다른 분들도 유사하게 느껴서 내가 기록하면 네 명을 기록한 것과 유사한 효용이 었었음.

  • 일별 회고 => unit test, 주별/월별/연도별 회고 integration test 라고 느껴진다. 서로 상호보완적임.


<2>크롤러 원인 파악

excel screenshot 크롤러 원인 파악 액셀
  • 어쩌다보니 연속으로 액셀 스크린샷 두 개를 첨부하게 되었음
  • 크롤러 매우 원인 파악 기똥차게 했음.
  • 4월 2일에 1000개의 샘플을 찾아서 실패하는 것들을 수동으로 DA한 적이 있는데 그때 90%는 성공하고 있었음.
  • 그들의 정확한 원인까지는 세세하게 디버깅해보지 않았는데, 이번에 고도화하면서 위와 같이 진행함.
  • priority를 정하기 위해서 난이도와 임팩트 기준으로 쉽고 임팩트 큼 >> 어렵고 임팩트 큼 >> 쉽고 임팩트 중간 순으로 처리하기로 정함.
  • 매우 체계적으로 분석하여 97%까지 정확도 개선 가능함을 확인했고 이제 실제 실행에 옮겨서 해결할 예정.

<3>라이브러리 까보기 세션?

  • 문득 든 생각인데 주간으로 쓰던 라이브러리 중 하나씩 레포지토리 안에 깊게 까보는 거 한 번씩 하는게 좋을듯 - 파일 구조 어떻게 해놨는지랑 코드 스타일 등 보는게 진짜 클듯 - 조금 메인테이닝 잘되는 애들껄로 보는 게 좋을듯.

TIL 5

  • 오늘 항해 플러스 처음 가봤는데 기대보다 괜찮았음.
  • 내가 이미 알고 있는 내용들도 있고 모르는 내용들도 있는데, 알차게 10주를 보낼 수 있을듯함.
  • 한상진 코치님이 월간으로 존재하는 ts 백엔드 모임 있다고 하셔서 거기 가보려고 생각중임.
    • 자세히보니까 지난 6월 미팅은 토요일에 해서 항해랑 겹칠수도 았울 듯함... ㅠㅠ

TIL 1

AI와 디버깅

AI 써서 못해진 것 같다는 느낌 받음 => 기존에 구현할 때 고민을 많이 안하고 구현하다보니 나중에 디버깅 할 때 골머리를 앓을 때가 많음. => mongodb mocking하는 부분이 처음에 고민을 많이하지 않고 만들다보니 수정할 때 지식이 부족해서 난감함

  • 디버깅을 훨씬 빠르게 하다보니 디버깅 능력이 퇴화됨. 전보다 쌩 디버깅할 때 머리 회전 속도가 많이 느려진듯. 원인 더 고민해봐야함.

디버깅을 훨씬 잘해지는 방법을 모색해봐야할듯. 디버깅에 예측되지 않은 시간이 꽤 많이 소모됨. 디버깅 자체를 프레임워크화를 해서 매우 빠르게 디버깅하는 프로세스를 갖추어야함.

파이썬 버리자고 했는데 번복해야할듯

3달 전에 모든 레포 js로 다 가야한다라고 논쟁했었는데 몇 달만에 python을 쓸 수 밖에 없는 상황에 봉착함. 수십개의 csv를 머징하는 작업은 python으로 하는것이 매우 합리적이어보임. 당시에는 js로 가볍게 가는 방식이었음. 3달 전에는 csv가 많아질거다라는 이야기 자체가 없었음. 그리고 prefect로 모든 걸 다 orchestrate하는 등의 이야기가 많았음.

dagster로 하느게 맞을듯.

당시에는 python메인으로 가고 js를 뭔가 하위 서브프로세스로 돌리는 걸 이야기했는데, 그러면 너무 복잡하고 어려우니, js 서버랑 MQ로 연결하는 것이 현재로서는 더 편해보임. => 아마 이게 더 디버깅이 쉬울 것 같은데 다들 어떤 의견일지 궁금함.


TIL 2

prefect vs dagster?

prefect 말고 dagster 써야할 이유가 있나? prefetch vs dagster 고민해보기

디버거 쓰면 디버깅이 빠르고 다른분들도 훨씬 많이 썼으면 좋겠다는 동료분의 말에 몇 주 동안 무조건 디버거 써서 디버깅 진행하는 것으로 하겠다고 말씀드렸음.

유닛 테스트 vs 통합 테스트

유닛 테스트와 통합 테스트에 대해 1시간 토론함 모두가 동의한 결론:

  • <1>testability
    • 현재 테스트들이 테스팅하는 코드들이 응집도가 낮고 결합도가 높아서 integration test가 깨질 때 고치는 것이 힘듦.
    • 그래서 원래 코드가 더 테스터블하게 수정되어야함
  • <2> 테스트는 더 빨라야함

순재님은 엄청 원칙을 중요시하는데 => 나는 이건 참고용 가이드라인이지 실제로 원칙이 되어서는 안된다고 생각함.

어쩔 수 없이 실무에서는 넘어가는 일이 많아서 원칙을 모두 준수하다가는 사실상 개발이 불가함... 영원한 토론이 이어질 뿐임. 우리가 실력이 부족해서 쓰자마자 부채 비율이 50%가 넘어가는 것 뿐임. 잘해지면 부채 비율이 낮아지는 것...


TIL 4

<1>액셀로 작업 회고

excel screenshot 내가 실제 한 작업을 시간 별로 정리한 액셀
  • 저번주 부터 제대로 리니어에 시간 산정 등을 하기로 개발팀 레벨에서 모두 합의함.

  • 저번주에 처리해낸 티켓이 20시간 밖에 안되어서 너무 충격적이어서 병목을 분석하고자 이번주는 위와 같이 액셀로 모든 시간을 실시간으로 기록하며 일함.

  • 병목을 자세히 분석할 수 있었음.

  • 장기적으로는 줄일 수 있는 회의와 갑자기 치고 들어오는 티켓들이 있었음.

  • 결론적으로는 주황색과 핑크색을 줄일 수 있어보였고, 몇 주 더 위와 같이 액셀로 정리하는 것을 습관화해서 계속해서 개선할 수 있도록 해야할듯.

  • 재미있는 점은 위 표를 다른 분들도 유사하게 느껴서 내가 기록하면 네 명을 기록한 것과 유사한 효용이 었었음.

  • 일별 회고 => unit test, 주별/월별/연도별 회고 integration test 라고 느껴진다. 서로 상호보완적임.


<2>크롤러 원인 파악

excel screenshot 크롤러 원인 파악 액셀
  • 어쩌다보니 연속으로 액셀 스크린샷 두 개를 첨부하게 되었음
  • 크롤러 매우 원인 파악 기똥차게 했음.
  • 4월 2일에 1000개의 샘플을 찾아서 실패하는 것들을 수동으로 DA한 적이 있는데 그때 90%는 성공하고 있었음.
  • 그들의 정확한 원인까지는 세세하게 디버깅해보지 않았는데, 이번에 고도화하면서 위와 같이 진행함.
  • priority를 정하기 위해서 난이도와 임팩트 기준으로 쉽고 임팩트 큼 >> 어렵고 임팩트 큼 >> 쉽고 임팩트 중간 순으로 처리하기로 정함.
  • 매우 체계적으로 분석하여 97%까지 정확도 개선 가능함을 확인했고 이제 실제 실행에 옮겨서 해결할 예정.

<3>라이브러리 까보기 세션?

  • 문득 든 생각인데 주간으로 쓰던 라이브러리 중 하나씩 레포지토리 안에 깊게 까보는 거 한 번씩 하는게 좋을듯 - 파일 구조 어떻게 해놨는지랑 코드 스타일 등 보는게 진짜 클듯 - 조금 메인테이닝 잘되는 애들껄로 보는 게 좋을듯.

TIL 5

  • 오늘 항해 플러스 처음 가봤는데 기대보다 괜찮았음.
  • 내가 이미 알고 있는 내용들도 있고 모르는 내용들도 있는데, 알차게 10주를 보낼 수 있을듯함.
  • 한상진 코치님이 월간으로 존재하는 ts 백엔드 모임 있다고 하셔서 거기 가보려고 생각중임.
    • 자세히보니까 지난 6월 미팅은 토요일에 해서 항해랑 겹칠수도 았울 듯함... ㅠㅠ
Copyright © 2023 Seho Lee All Rights Reserved.
</>
Latest Commit
8b5158e2-447f-5dd0-be50-7e3899276bfa
Seho Lee
2025-07-14T12:34:23Z