오늘자 방송: https://www.youtube.com/watch?v=kCfRKWXFiYU&list=PLdntWJk2tJPKvRB0mSqC5tyKUv7HFtcqg

1. CTO 둘이 풀어드리는 주간 뉴스 2024.9.19방송
좋은 리팩토링 vs 나쁜 리팩토링

2. 참고자료
• <컴퓨터 vs 책> 블로그
http://jhrogue.blogspot.com/
• 유튜브 채널 OKdevTV > 재미있는 개발 이야기 리스트
https://www.youtube.com/playlist?list=PLdntWJk2tJPKvRB0mSqC5tyKUv7HFtcqg
• 슬라이드 셰어
https://www.slideshare.net/jrogue/presentations
• 채널 박재호(초급 개발자를 위한...) https://www.youtube.com/@채널박재호
OKdevTV

3. 오늘의 짤방
OKdevTV
Considering a specialized vector
database for your RAG app?
via
@avthars

4. ① (개발) 좋은 리팩토링 vs 나쁜 리팩토링
② (보안) 도커, CLI 접근을 위한 SSO 시행(비밀번호 X)
③ (개발) 회사 내부용 CLI 만들기
④ (오늘의 논쟁) 대형 데이터베이스에 대한 과대 광고를 믿지 마세요
⑤ (도구) 현대적인 유닉스 도구 목록
⑥ (팁) 사라진(?) 모든 커밋을 그래프로 표시하려면?
⑦ (아키텍처) 아마존 S3 안정성 확보를 위한 우수 관례
⑧ (우리가 몰랐던 사실) 왜 argv[0]을 사용하나요?
⑨ (HR) 유능해 보이는 무능한 직원을 골라내야 한다
오늘 소개할 내용
OKdevTV

5. • https://news.hada.io/topic?id=16575
• 좋은 리팩토링 vs 나쁜 리팩토링(1)
• 새로운 라이브러리를 도입하거나 완전히 다른 코딩 스타일을 채택하면 유지보수에 악영향을 줄 수 있음 → 더 관용적이고 읽
기 쉬운 코드로 개선하되, 완전히 새로운 패러다임이나 외부 종속성을 도입하지 않는 편이 좋음
• 기존 코드를 이해하지 않은 채 불필요한 새로운 추상화를 과도하게 추가하면 문제가 됨 → 로직을 작고 재사용 가능한 함수로
분리하되, 불필요한 복잡성은 도입하지 않는 편이 좋음
• 코드베이스의 한 부분만 완전히 다르게 작동하도록 업데이트하면 혼란과 좌절을 일으킴 → 새로운 패턴을 도입해야 한다면,
먼저 팀의 동의를 구하는 것이 좋음
• 코드를 배우면서 동시에 리팩토링하는 것은 좋지 않은 생각 → 버그를 만들고, 성능을 저하시키며, 기능을 제거할 수 있음
• 비즈니스에 대한 이해 없이 기술 선택을 하는 것은 재앙이 될 수 있음 → SEO에 크게 의존하는 전자상거래 사이트의 경우, 클
라이언트 측 렌더링은 나쁜 선택이 될 수 있음
• 유연성을 희생하면서까지 코드를 "깔끔하게" 만들기 위해 통합하는 것은 좋지 않음 → 추상화할 때는 항상 제공하는 사용 사례
를 고려해야 함
OKdevTV
(개발) 좋은 리팩토링 vs 나쁜 리팩토링(1)
1

6. • https://news.hada.io/topic?id=16575
• 좋은 리팩토링 vs 나쁜 리팩토링(2)
• 코드 리팩토링은 올바른 방법으로 수행해야 함
• 기존 코드와 일관성을 유지해야 함
• 코드 이해 후 리팩토링을 수행하고, 추상화는 신중하게 선택해야 함
• 성공적인 리팩토링을 위한 팁:
• 점진적으로 진행: 전면적인 재작성보다는 작고 관리 가능한 변경을 수행
• 중요한 리팩토링이나 새로운 추상화를 도입하기 전에 코드를 깊이 이해해야 함
• 기존 코드 스타일과 일치: 유지 보수를 위해 일관성이 핵심
• 너무 많은 새로운 추상화 도입 자제: 복잡성이 정말로 필요한 경우가 아니라면 단순하게 유지해야 함
• 특히 팀의 동의 없이 매우 다른 프로그래밍 스타일의 새로운 라이브러리 추가는 자제해야 함
• 리팩토링 전에 테스트를 작성하고 진행하면서 테스트를 업데이트해야 함
• 동료들이 이러한 원칙을 준수하도록 서로 책임감을 보여야 함
OKdevTV
(개발) 좋은 리팩토링 vs 나쁜 리팩토링(2)
1

7. • https://thenewstack.io/docker-joins-movement-to-dump-passwords-for-security/
• 2024년 9월 16일부터 Docker는 CLI 액세스를 위한 싱글 사인온(SSO)을 시행할 예정
• SSO가 시행되면 비밀번호 사용을 중단하고 개인 액세스 토큰(PAT)으로 전환
• SSO 적용은 2022년 비즈니스 구독부터 처음 도입 → 조직이 ID 공급자를 통해 인증을 의무화함
• 보안을 강화할 뿐만 아니라 비밀번호가 여러 개 존재하는 번거로움을 없애 사용자 경험을 간소화함
• 도커는 이제 데스크탑, 허브, 스카우트, 빌드 클라우드를 포함한 서비스 전반에 걸쳐 통합된 보안 인증 프
로세스를 운영함
• 패스키와 제로 트러스터 보안 모델은 업계에서 광범위하게 채택이 진행 중임
• 패스키: FIDO 얼라이언스에서 개발(애플, 구글, 마이크로소프트가 지원)
• 제로 트러스터: 위협이 내부 또는 외부에서 발생할 수 있다고 가정하고, 모든 접근 요청에 대해 엄격한 확인을 요구 → 비밀번호
를 제거해 자원과 데이터에 대한 보호를 강화함
• 참고: 깃헙은 개발자의 95%가 2FA를 채택
OKdevTV
(보안) 도커, CLI 접근을 위한 SSO 시행(비밀번호 X)
2

8. OKdevTV
(개발) 회사 내부용 CLI 만들기
3
• https://news.hada.io/topic?id=16589
• 조직 전반에 걸쳐 유용한 도구 설치, 상용구 코드 생성, 복잡한 명령 실행을 위한 스크립트가 존재함
• 즉 조직 내부용 CLI가 필요한 경우에 자체적으로 만들 필요가 있음
• 쉽게 만드는 방법은?
• 예: just(프로젝트에 밀접한 명령을 저장하고 수행하기 위한 도구) → make와 유사한 구문으로 justfile을 만들면 자동으로 실행
해줌
• 다른 예 1: 루비의 Thor(아주 간단하게 CLI 애플리케이션을 만들게 도와줌)
• 다른 예 2: 파이썬의 Typer(애노테이션을 활용해 CLI 애플리케이션을 만들게 도와줌)
• 팁: 자바 스프링 개발자들은 스프링 셸을 사용하면 된다
• https://github.com/spring-projects/spring-shell

9. OKdevTV
(오늘의 논쟁) 대형 데이터베이스에 대한 과대 광고를 믿지 마세요
4
• https://www.datanami.com/2024/07/08/dont-believe-the-big-database-hype-stonebraker-
warns/
• 빅 데이터의 필요성은 모든 발명의 어머니
• 맵리듀스와 NoSQL에서 벡터 데이터베이스에 이르기까지 다양한 유형의 제품과 서비스가 등장
• 스톤브레이커
• 반세기 동안 데이터베이스 설계에 매진한 회사: PostgreSQL과 VoltDB 개발에 기여함
• 데이터베이스 지향 운영체제(DBOS) 개념을 주창함
• 돌직구 평가
• 맵리듀스: 사망 ㅠㅠ
• 도큐먼트 데이터베이스(몽고DB, 카우치베이스): 관계형 데이터베이스가 수평 확장과 JSON을 지원함에 따라 충돌이 불가피
• 컬럼 데이터베이스(빅테이블, 카산드라, Hbase): 구글 덕분에 간신히 생명을 유지
• 검색 엔진: 관계형 데이터베이스와 분리되어 독자적으로 존재함
• 벡터 데이터베이스(파인콘, 밀버스, 위비에이트): 기본적으로 도큐먼트 데이터베이스이며, ANN과 같은 색인 기법을 지원하는데
langchain/llamaindex와 연동이 편리하긴 하지만, RDBMS가 거의 모든 기능을 갖추고 따라오므로 생존 가능성은 높지 않음
• 그래프 데이터베이스: 틈새 시장을 공략 중이지만, RDBMS를 포기할만한 충분한 시나리오가 관건임

10. • https://notes.billmill.org/computer_usage/cli_tips_and_tools/modern_unix_tool_list.html
• 기본 데비안 설치에서 찾을 수 있는 도구를 무엇으로 대체할까?
• atuin: 명령 기록을 sqlite 데이터베이스에 보관
• concurrently: 프로그램을 병렬로 실행하고 출력을 보기 좋게 확인(예: 웹 서버와 데이터베이스를 실행하고 두 가지 출력을 함
께 보려면?)
• delta: 훨씬 더 나은 git diff 출력
• doggo: 더 나은 dig
• dust: du와 비슷하지만 더 빠르고 좋은 출력 제공
• duf: 현대적인 감각의 df
• erdtree: 개선된 tree
• jless: json 문서를 대화형으로 접고 펼칠 수 있음
• ripgrep: 개선된 grep
OKdevTV
(도구) 현대적인 유닉스 도구 목록
5

11. • https://x.com/simnalamburt/status/1832013909794103798
• 커밋이 있으면 고아가 되더라도 찾을 수 있다(단 오래되어 가베지 컬렉션이 일어나면 T_T)
OKdevTV
(팁) 사라진(?) 모든 커밋을 그래프로 표시하려면?
6
# git all
# It shows *all* git commit references in a graph format, including dangling
# or unreachable commits (e.g., popped stashes, etc.).
all = "!_() { git log --oneline --graph --reflog $(git fsck --unreachable | perl -ne 'print "$1n" if /^w+
commit ([0-9a-f]+)$/'); }; _"

12. • https://awstip.com/amazon-s3-reliability-best-practices-checklist-a6ae1c645cfe
• 아마존 S3 안정성을 개선하는 다양한 방법
• 버전 관리 활성화: 한 객체의 여러 버전을 한 버킷에 보관
• 지역 간 복제: 여러 리전 사이에 객체를 자동으로 복제
• S3 전송 가속화: 클라우드프론트의 엣지 로케이션을 사용해 데이터 전송을 가속화
• S3 객체 잠금 사용: 일정 시간 또는 무기한 동안 객체 삭제나 덮어쓰지는 상황을 방지
• 비용 최적화를 위한 인텔리전트 계층화 사용: 객체 수명 주기 정책 구성
• 장기 저장을 위한 S3 Glacier: 데이터 백업과 비용 절감을 위한 Glacier 활용
• 서버 측 암호화(SSE) 구현: 관리형 키나 고객 제공 키를 사용해 미사용 데이터를 자동으로 암호화
• 삭제 시 MFA 구성: 객체 삭제 시 다단계 인증 요구
• 생명 주기 관리를 위한 객체 태그 활용: 특정 속성을 기반으로 데이터 분류와 관리
• S3 이벤트 알림 활용: 특정 버킷 이벤트에 따라 워크플로우와 경고를 트리거
• 정기적인 접근 로그 감사: 무단 접근을 감시하기 위해 접근 로그를 확인
• 클라우드트레일로 객체 수준의 로깅 활용: S3 버킷에 대한 API 호출을 확인
• S3용 접근 분석기: 교차 계정 접근을 허용하는 버킷 정책을 식별하고 알림을 제공
OKdevTV
(아키텍처) 아마존 S3 안정성 확보를 위한 우수 관례
7

13. • https://news.hada.io/topic?id=16605
• 프로세스의 명령줄 첫 번째 인자인 argv[0]가 프로세스의 이름을 나타내도록 예약된 관습의 문제점
• 보안 소프트웨어를 속일 수 있음 → argv[0]을 공백으로 설정하여 certutil을 시작하면 윈도우 디펜더는 이를 차단하지 않음
• 사람을 속일 수 있음 → argv[0]을 curl에서 curl localhost | grep으로 변경할 경우 착각을 일으킴
• 악명 높은 RLO(오른쪽-왼쪽 재정렬) 문자를 사용하여 argv[0]을 조작함 → argv[0]에 RLO를 삽입하면 ping
moc.elgoog.some-evil-website.com을 ping moc.etisbew-live-emos.google.com처럼 보이게 할 수 있음
• argv[0]은 명령줄의 맨 처음에 위치하기 때문에, argv[0]에 충분한 문자를 채워 넣으면 다른 모든 인자를 명령줄 끝으로 밀
어낼 수 있음
• 결론
• argv[0]는 과거의 유물로, 현대 소프트웨어 설계 원칙에 어긋남
• 대부분의 프로그램은 argv[0]를 무시하지만, 이는 보안 문제를 일으킬 수 있음
• 보안 전문가들은 argv[0]의 악용을 탐지하고 방어 소프트웨어는 이를 더 잘 처리해야 함
OKdevTV
(우리가 몰랐던 사실) 왜 argv[0]을 사용하나요?
8

14. • https://x.com/bbarkmang1/status/1834555170417770517
OKdevTV
(HR) 유능해 보이는 무능한 직원을 골라내야 한다
9