1.
레거시를 파악하고
변경해나가기:
우선순위와 고려 사항들
CTO들이 풀어주는 주간 뉴스 2021.4.10
OKdevTV

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

3.
오늘의 짤방
OKdevTV

4.
제가 개인적인 사정으로 인해
4월 17일부터 5월 10일까지 5주 동안
주간 뉴스 방송을 쉽니다. 큰 문제는 아니며 일 때문에 그러니까 걱
정하지 마시고… 더 좋은 소식을 들고 찾아 뵙겠습니다.
공지사항 한 가지
OKdevTV

5.
① 호텔에서 찾아낸 미스테리한 UDP 스트림
② 승자의 경기와 패자의 경기
③ 레거시를 파악하고 변경해나가기: 우선순위와 고려 사항들
④ 웹에서 접근성 높은 색상을 고르려면?
⑤ 마이크로소프트 OpenJDK 빌드
⑥ 미국 대법원, 구글의 자바 API 사용을 공정 사용으로 판결
오늘의 소개할 내용
OKdevTV

6.
• https://www.gkbrk.com/2016/05/hotel-music/
• 호텔에 묶고 있다가 wireshark를 연 개발자 이야기(그런데 호텔에서 wireshark를 왜 열었지? T_T)
• 포트 2046에서 엄청난 UDP 트래픽 발생
• TV 스트림으로 보기에는 비디오 패킷 길이가 너무 짧음
• 멀티캐스트 패킷
• 파이썬으로 간단한 분석 스크립트 작성
• 첫 15바이트가 동일
• MPEG 압축 오디오 데이터로 보이는 LAME3.91UUUUUUU 시그니처를 발견
• 저장해서 file 유틸리티로 확인해보니 mp3가 아닌 data라고만 나옴
• 다시 파이썬 프로그램을 작성해 바이트를 건너뛰며 어떤 형식인지 판단
• 패킷에서 8바이트를 건너뛴 지점에서 MPEG 오디오 데이터 시작을 발견
• 스트림으로 저장해서 재생 → 음악이었음
• 어디서 음악이 들려올까?
• 방도 아니고 스마트 TV도 아님
• 복도를 걷다가 찾아냄: 엘리베이터 음악.
OKdevTV
(개발) 호텔에서 찾아낸 미스테리한 UDP 스트림
1

7.
• https://thehosk.medium.com/software-development-is-a-losers-game-fc68bb30d7eb
• 위대한 코드는 당신을 구원할 수 없지만, 나쁜 코드는 당신을 죽일 수 있다!
• 개발자들이 힘들어하는 이유는 경기의 규칙을 모르기 때문
• 프로 테니스는 승자의 경기(즉, 승자의 활동에 의해 결정), 아마추어 테니스는 패자의 경기(즉, 패자의 활동에 의해 결정)
• 소프트웨어 개발 게임
• 소프트웨어 개발자의 80%는 아마추어이고, 20%는 프로
• 아마추어 개발자는 표준, 단위 테스트, 빌드 수정, 코드 검토, 코드 분석과 같은 활동을 싫어함
• 대다수 개발자들은 코드 작성을 과소평가하며 작동하는 소프트웨어를 만드는 능력을 과대 평가함
• 그렇다면?
• 대다수 개발자들이 아마추어라면, 패자의 경기로 접근해서 실수를 줄이는 데 집중
• 아마추어 개발자의 목표는 코드 작성 자체! 나머지 활동은 모두 속도를 줄인다
• 하지만 코드를 빠르게 작성하려면, 품질에 초점을 맞추고 버그를 줄여야 한다. 즉 코드를 빠르게만 작성해서는 안 된다
• 개발 팀 관점에서
• 버그, 오류, 실수 비용은 단독 개발보다 점점 더 커지는 경향이 있다
• 우리와 같은 사람들이 매우 똑똑해 지려고 노력하는 대신 지속적으로 어리석지 않게 노력함으로써 얼마나 많은 장기적 이점을
얻었는지를 알면 놀랄 겁니다." — 찰리 멍거
OKdevTV
(개발) 승자의 경기와 패자의 경기
2

8.
• https://thehosk.medium.com/software-development-is-a-losers-game-fc68bb30d7eb
• 거꾸로 하자
• 거꾸로 작동하는 코드를 빠르게 작성하는 것이 아니라 품질이 낮은 코드와 버그를 피하는 데 시간을 소비하는 것을 목표로 삼는
다.
• 아마추어 개발자는 코드를 빠르게 작성하는 것이 양산/서비스 코드를 만드는 가장 빠른 방법이라고 생각한다. 하지만 엄청나게
복잡한 프로젝트에서는 코드에 한 줄 한 줄이 추가 될 때마다 복잡성이 증가하고 개발을 더 어렵게 만드는 코드 기반을 만든다.
빠르게 코드를 작성하는 방식은 한두 명의 개발자가 작업하는 소규모 프로젝트에서만 작동한다.
• 버그 비용 줄이기
• 개발 과정에서 버그를 나중에 발견할수록 비용이 커진다. 버그 파악과 수정이 어려운 경우에 특히 버그 감지 기법을 고안해서
게임을 이겨야 한다
• 특히, 대부분의 개발 팀이 프로가 아닌 아마추어라고 가정할 경우 우리는 버그 감소에 초점을 맞춰야 한다
• 개발의 성공은 코드를 처음에 올바르게 작성하는 것이 아니라 여러 가지 실패 방법을 피하는 것이다
• "전문가는 점수를 얻고 아마추어는 점수를 잃는다."
OKdevTV
(개발) 승자의 경기와 패자의 경기
2

9.
OKdevTV
(개발) 레거시를 파악하고 변경해나가기: 우선순위와 고려 사항들
3
• https://kadensungbincho.tistory.com/72
• 문서화가 잘 되어 있지 않고, 단기간에 계약이 끝나 자세한 인수인계를 받기 어려운 서비스에 대해, 특히
30개 저장소로 분산된 코드를 효율적으로 파악하는 방법은 무엇일까?
• 기술 부채와 관련해 ‘시간’이라는 측면을 신중하게 고려해야 한다
• 시간이 지남에 따라 이자는 복리로 붙는다
• 팀은 무엇에 가장 큰 이자를 지불하고 있는가?
• 코드에서 메타 데이터 파악하기
• git history로 소스코드이 메타 데이터 확인하기: 형상 관리 시스템은 소스 코드의 정적인 측면에 시간 축을 부여 → 변경이 언제
발생했고, 누가 발생시켰는지 포함 → 따라서 특정 시점에 특정 부분에 대한 변경을 누구에게 확인해야 할지를 파악할 수 있음
• 저장소 이름, 브랜치 명, 총 커밋 수, 총 참여자 수, 마지막 커밋 일시를 토대로 가장 빠르게 수정되거나 활성화된 부분을 파악

10.
OKdevTV
(개발) 레거시를 파악하고 변경해나가기: 우선순위와 고려 사항들
3
• https://kadensungbincho.tistory.com/72
• 코드에서 메타 데이터 파악하기(계속됨)
• 개발의 초기 시점에 생성된 파일이 오래 남아 (비교적 안정적일지는 모르겠지만) “높은 이자율”을 발생시킴
• git log로 초기에 개발되거나 초기에 자주 변경된 파일을 특정해서 파악
• 소스 코드의 메타 데이터 파악하기
• 소스 코드의 총 라인 수는 복잡도를 유추할 수 있는 가장 간단하면서도 중요한 지표
• 정적분석기인 소나큐브를 활용
• 변경 범위를 결정하고 단계별로 나눠서 분석하기
• 코드의 나이: 같이 변경해야 하는 파일들은 동시기의 변경 로그에 포함됨 → 변경 범위 결정에 중요한 단서
• 인터페이스: 넓은 범위에서부터 좁혀가면서 인터페이스 지점을 우선적으로 파악한 다음에 이들을 연결
• 테스트가 존재하지 않던 레거시에 테스트 더하기
• 변경 이전의 최소한의 안전 장치 마련: 코드 바이스
• 구분되지 않던 복잡한 덩어리를 뜯어서 표시하기 위한 울타리를 생성

11.
OKdevTV
(팁) 웹에서 접근성 높은 색상을 고르려면?
4
• https://learnui.design/tools/accessible-color-generator.html
• Accessible color generator
• 웹 디자인, 개발할 때 사용하려는 색상이 WCAG 명도 대비 요구 수준(4.5:1)에 도달하는지 간단하게 체크하고 충분하지 않은
경우 적절한 대비를 가진 유사 색상을 추천 via @naradesign

12.
• https://devblogs.microsoft.com/java/announcing-preview-of-microsoft-build-of-openjdk/
• 마이크로소프트가 OpenJDK 빌드 미리보기 발표
• MacOS X, 리눅스, 윈도우의 x64 서버/데스크톱 환경에서 OpenJDK 11.0.10 + 9를 기반으로 한 Java 11 용 바이너
리 공개
• https://www.microsoft.com/openjdk
• Java 11 용 TCK(Java Technology Compatibility Kit)를 통과
• 최소 2024 년까지 Java 11을 지원
• 라이선스: GPLv2 + CE (Classpath Exception)가 포함된 General Public License 2.0
• 조만간 컨테이너 이미지도 공개 예정
• 목표: Azure 관리 서비스 전반에서 Java 11의 기본 배포로 자리잡게 만듦
OKdevTV
(뉴스) 마이크로소프트 OpenJDK 빌드
5

13.
• https://www.infoq.com/news/2021/04/java-api-fair-use/
• 2020년 10월에 심리 시작 2021년 4월 5일 결정
• 시작
• 구글은 안드로이드에 자바 API의 하위 집합을 사용, OpenJDK에서 코드 자체를 복사하지 않았지만, 오라클은 API 정
의가 저작권에 보호된다고 주장
• 2010년 8월 13일 하급 법원에서 case 시작 → 2012년 5월 31일 API에 저작권이 없다고 판결
• 오라클은 전체 API가 더 큰 저작물로 결합되어 저작권이 있다고 주장하면서 공정 사용 건으로 다시 재소
• 2016년 5월 9일 지방 법원에서 case 시작 → 2016년 5월 26일 공정 사용이 적용된다고 판결
• 오라클은 항소 → 2018년 3월 27일에 구글의 API 사용이 공정하지 않다는 판결이 내려짐
• 구글이 다시 항소 → 2020년 3월 24일 case 시작
• 최종 결론
• 자료에는 저작권이 있다고 가정 → 하지만 공정한 사용
• API 자체에 저작권이 있는지는 아직은 판단을 보류 → 하지만 API 자체에 저작권이 있더라도 해당 API를 재구현하는 것은 공정 사용이며 저작권 침해가
아님
• 새롭고 혁신적인 프로그램 개발을 위해 구글의 자바 SE API 복제는 법에 정해진 원칙에 맞춰 공정 사용으로 판단됨
OKdevTV
(뉴스) 미국 대법원, 구글의 자바 API 사용을 공정 사용으로 판결
6