Offcanvas

������������������������������������

'리팩터링, 린트, 프로필...' 완료된 코드를 추가 개선하는 16가지 팁

작성한 코드가 모든 테스트에서 정상으로 나왔다. 지속적 통합 파이프라인도 끝까지 실행됐다. 기능 목록의 모든 체크박스를 확인했고, 벽에 붙여 둔 포스트잇 메모는 모두 완료 구역으로 이동됐다. 휴...   이쯤 되면 코드가 완성되었음을 선언하고 휴가를 떠나고 싶은 마음이 굴뚝같다. 그럴 만한 자격이 있다. 한동안 코드가 작업을 수행하도록 두면 된다. 애초에 그렇게 하려고 만들지 않았던가? 벽 너머로 던져 거기서 실행되도록 하면 그걸로 우리 일은 끝이다.   그러나 현실에 만족하는 시대는 끝났다. 요즘은 끝난다는 개념이 없다. 버그를 없앤, 기능하는 프로그램을 전달했다고 해서 쉬어도 된다는 뜻은 아니다. 그 시점에도 코드를 개선하기 위해 할 수 있는 일이 십여 가지는 있기 때문이다. 다음 팀을 위해 코드를 잘 정비하는 모범적 개발자로서 해야 할 일도 있고, 새로운 여정의 시작이라 할 만한 것도 있다.   잠깐의 휴식과 재충전 후에 돌아와서 해야 할 16가지 일을 살펴보자.   린트 린트(lint) 또는 린터(linter)라고 하는 이 툴은 일종의 코드 리뷰 로봇으로, 수백, 수천 가지의 의미 체계 규칙을 적용한다. 공백 문자의 수를 하나하나 세고 공백을 너무 많이 또는 너무 적게 사용한 개발자를 질책하는 강박적 잔소리꾼이 만든 규칙도 있고, 나중에 보안 결함으로 이어질 수 있는 모호한 의미 체계 패턴을 지적하는 깐깐한 사람들이 만든 규칙도 있다. 프로그래밍 팀이라면 이미 선택해둔 린터 모음이 있을 테니, 이제 그 린터를 실행할 시간이다.   프로필 돈 커누스는 전에 “너무 이른 최적화는 만악의 근원”이라고 말한 적이 있다. 코드에서 가끔씩만 실행될 부분을 개선하느라 시간을 허비하는 것은 어리석은 일이기 때문이다. 이제 코딩을 끝냈으니, 프로파일러를 실행해서 포화가 집중되는 지점을 찾을 시간이다. 많은 경우 코드의 10%가 90%의 시간 동안 실행된다. 때로는 조밀한 내부 루프가 사이클의 99%를 흡수하는 경우도 있다. ...

코드 서버리스 리팩터링 린트

2020.03.05

작성한 코드가 모든 테스트에서 정상으로 나왔다. 지속적 통합 파이프라인도 끝까지 실행됐다. 기능 목록의 모든 체크박스를 확인했고, 벽에 붙여 둔 포스트잇 메모는 모두 완료 구역으로 이동됐다. 휴...   이쯤 되면 코드가 완성되었음을 선언하고 휴가를 떠나고 싶은 마음이 굴뚝같다. 그럴 만한 자격이 있다. 한동안 코드가 작업을 수행하도록 두면 된다. 애초에 그렇게 하려고 만들지 않았던가? 벽 너머로 던져 거기서 실행되도록 하면 그걸로 우리 일은 끝이다.   그러나 현실에 만족하는 시대는 끝났다. 요즘은 끝난다는 개념이 없다. 버그를 없앤, 기능하는 프로그램을 전달했다고 해서 쉬어도 된다는 뜻은 아니다. 그 시점에도 코드를 개선하기 위해 할 수 있는 일이 십여 가지는 있기 때문이다. 다음 팀을 위해 코드를 잘 정비하는 모범적 개발자로서 해야 할 일도 있고, 새로운 여정의 시작이라 할 만한 것도 있다.   잠깐의 휴식과 재충전 후에 돌아와서 해야 할 16가지 일을 살펴보자.   린트 린트(lint) 또는 린터(linter)라고 하는 이 툴은 일종의 코드 리뷰 로봇으로, 수백, 수천 가지의 의미 체계 규칙을 적용한다. 공백 문자의 수를 하나하나 세고 공백을 너무 많이 또는 너무 적게 사용한 개발자를 질책하는 강박적 잔소리꾼이 만든 규칙도 있고, 나중에 보안 결함으로 이어질 수 있는 모호한 의미 체계 패턴을 지적하는 깐깐한 사람들이 만든 규칙도 있다. 프로그래밍 팀이라면 이미 선택해둔 린터 모음이 있을 테니, 이제 그 린터를 실행할 시간이다.   프로필 돈 커누스는 전에 “너무 이른 최적화는 만악의 근원”이라고 말한 적이 있다. 코드에서 가끔씩만 실행될 부분을 개선하느라 시간을 허비하는 것은 어리석은 일이기 때문이다. 이제 코딩을 끝냈으니, 프로파일러를 실행해서 포화가 집중되는 지점을 찾을 시간이다. 많은 경우 코드의 10%가 90%의 시간 동안 실행된다. 때로는 조밀한 내부 루프가 사이클의 99%를 흡수하는 경우도 있다. ...

2020.03.05

블로그 | 엔터프라이즈 데이터베이스를 클라우드로 옮기기

데이터베이스는 자동차와 비슷하다. 모두가 뒤돌아볼 만한 빈티지 자동차를 몰고 다닌다고 생각해 보자. 아마도 처음 이 자동차가 만들어진 1970년대와 비교해 유지 비용이 20배는 더 들 것이다. 물론 새로운 자동차도 있을 것이다. 이 자동차는 엄청나게 매력적이지는 않지만, 30년 된 자동차보다는 더 빠르고 주행거리도 길고 최신 기술도 적용되어 있다.   많은 데이터 세트가 클라우드로 재배치되고 있다. 그리고 이제는 이렇게 워크로드와 데이터를 이전하는 것으로 비용을 물어야 하는 데이터베이스는 적절한 옵션을 고려해야 한다. 첫 번째 옵션은 자체 엔터프라이즈 데이터베이스 라이선스를 퍼블릭 클라우드 서비스 업체로 옮기는 것이다. 이른바 BYOL(Bring Your Own License)이다. 가장 저항이 적은 방안으로, 기업이 해야 할 것은 A 데이터베이스의 데이터를 다른 플랫폼에서 호스팅하는 A 데이터베이스로 옮기는 것뿐이다. 단지 새 플랫폼이 퍼블릭 클라우드일 뿐이다. 가장 간단한 방법이지만, 가장 저렴하지는 않다. 매년 라이선스비를 지불해야 하지만, 이 데이터베이스에는 클라우드 네이티브 데이터베이스가 제공하는 기능이나 성능을 제공하지 않을 것이다.  기업의 요구사항에 따라 다르겠지만, 일반적으로 클라우드 네이티브 데이터베이스는 클라우드에 데이터를 재배치하는 더 나은 방법으로 평가된다. 단점이라면, 데이터를 새로운 네이티브 스토리지 모델에 맞춰 재구성해야 한다는 것. 물론 이 데이터베이스에 액세스하는 애플리케이션도 수정해야 한다. 물론 필자라면 어떤 식으로든 클라우드 네이티브 서비스를 이용할 수 있도록 애플리케이션을 리팩터링하는 것이다. 새 클라우드 네이티브 데이터베이스에 맞춰 리팩터링해야 할지도 모른다. 이 방식은 일부 기업에는 너무 높은 진입 장벽이 될 수 있지만, 최종적으로 더 성능이 좋고 더 많은 기능을 제공하고 사용하는 데 드는 비용도 더 저렴한, 그리고 무엇보다도 기업의 특별한 사용례에 맞춰 구축한 애플리케이션과 데이터베이스를...

라이선스 데이터베이스 마이그레이션 네이티브 리팩터링

2019.08.16

데이터베이스는 자동차와 비슷하다. 모두가 뒤돌아볼 만한 빈티지 자동차를 몰고 다닌다고 생각해 보자. 아마도 처음 이 자동차가 만들어진 1970년대와 비교해 유지 비용이 20배는 더 들 것이다. 물론 새로운 자동차도 있을 것이다. 이 자동차는 엄청나게 매력적이지는 않지만, 30년 된 자동차보다는 더 빠르고 주행거리도 길고 최신 기술도 적용되어 있다.   많은 데이터 세트가 클라우드로 재배치되고 있다. 그리고 이제는 이렇게 워크로드와 데이터를 이전하는 것으로 비용을 물어야 하는 데이터베이스는 적절한 옵션을 고려해야 한다. 첫 번째 옵션은 자체 엔터프라이즈 데이터베이스 라이선스를 퍼블릭 클라우드 서비스 업체로 옮기는 것이다. 이른바 BYOL(Bring Your Own License)이다. 가장 저항이 적은 방안으로, 기업이 해야 할 것은 A 데이터베이스의 데이터를 다른 플랫폼에서 호스팅하는 A 데이터베이스로 옮기는 것뿐이다. 단지 새 플랫폼이 퍼블릭 클라우드일 뿐이다. 가장 간단한 방법이지만, 가장 저렴하지는 않다. 매년 라이선스비를 지불해야 하지만, 이 데이터베이스에는 클라우드 네이티브 데이터베이스가 제공하는 기능이나 성능을 제공하지 않을 것이다.  기업의 요구사항에 따라 다르겠지만, 일반적으로 클라우드 네이티브 데이터베이스는 클라우드에 데이터를 재배치하는 더 나은 방법으로 평가된다. 단점이라면, 데이터를 새로운 네이티브 스토리지 모델에 맞춰 재구성해야 한다는 것. 물론 이 데이터베이스에 액세스하는 애플리케이션도 수정해야 한다. 물론 필자라면 어떤 식으로든 클라우드 네이티브 서비스를 이용할 수 있도록 애플리케이션을 리팩터링하는 것이다. 새 클라우드 네이티브 데이터베이스에 맞춰 리팩터링해야 할지도 모른다. 이 방식은 일부 기업에는 너무 높은 진입 장벽이 될 수 있지만, 최종적으로 더 성능이 좋고 더 많은 기능을 제공하고 사용하는 데 드는 비용도 더 저렴한, 그리고 무엇보다도 기업의 특별한 사용례에 맞춰 구축한 애플리케이션과 데이터베이스를...

2019.08.16

블로그 | 클라우드 애플리케이션이 느린 이유는 클라우드 때문이 아니다

아침 7시. 사무실에 일찍 도착했다. 이렇게 이른 시간에는 아무도 회사가 사용하는 퍼블릭 클라우드에 액세스하지 않을 것이란 생각에서다. 이제 재고 애플리케이션은 수정 작업을 원활하게 수행할 것이란 기대를 가졌다. 하지만 이른 아침, 겨우 몇 명의 사용자가 클라우드에 있는데도, 성능은 여전히 엉망진창이다. 이때 즉각적인 반응은 클라우드 서비스 업체를 욕하는 것이다. 물론 서비스 업체는 애플리케이션과 데이터를 호스팅하기 때문에 어떤 성능 문제에 대한 책임도 져야 한다. 그렇지 않은가? 사실은 그렇지 않다. 필자가 본 성능 문제 중 열에 아홉은 클라우드 인프라에 문제가 있기보다는 애플리케이션 설계나 기술 선택의 문제였다. 이것만 생각하자. 퍼블릭 클라우드에서 용량은 그냥 추가하면 된다. 용량은 필요할 때 필요한 만큼 확장할 수 있다. 하지만 느린 재고 관리 애플리케이션 문제라면, 용량을 추가하는 식으로는 문제를 해결할 수 없다. 이제 필자가 수도 없이 이야기한 규칙을 다시 생각해 보자. “엉성한 온프레미스 애플리케이션을 퍼블릭 클라우드로 이전하면, 엉성한 퍼블릭 클라우드 애플리케이션이 된다.” 퍼블릭 클라우드로 이전하면서 흔히 일어나는 일이다. 애플리케이션을 퍼블릭 클라우드로 보내기 전에 애플리케이션 설계나 데이터베이스나 미드웨어 사용, 또는 다른 기반 기술을 점검하지 않는 것이다. 현실은 이런 애플리케이션이 단지 성능이 엉망인 것에 그치지 않는다. 제대로 설계되지 않은 애플리케이션을 처리하기 위해 퍼블릭 클라우드가 씨름을 하면서 클라우드 요금이 50~60% 더 나오기 십상이다. 일반적으로 비효율적인 I/O, 인터랙션이 너무 많은 애플리케이션, 최적화하지 않은 데이터베이스 쿼리 등이 문제의 원인인 경우가 많으며, 이외에도 잘못될 수 있는 것은 너무나 많다. 이 문제의 해법은 대부분 기업 IT 부서가 듣고 싶지 않은 이야기다. 애플리케이션을 리팩터링하는 것이다. 여기에는 애플리케이션 설계 조정과 애플리케...

마이그레이션 설계 리팩터링

2017.07.25

아침 7시. 사무실에 일찍 도착했다. 이렇게 이른 시간에는 아무도 회사가 사용하는 퍼블릭 클라우드에 액세스하지 않을 것이란 생각에서다. 이제 재고 애플리케이션은 수정 작업을 원활하게 수행할 것이란 기대를 가졌다. 하지만 이른 아침, 겨우 몇 명의 사용자가 클라우드에 있는데도, 성능은 여전히 엉망진창이다. 이때 즉각적인 반응은 클라우드 서비스 업체를 욕하는 것이다. 물론 서비스 업체는 애플리케이션과 데이터를 호스팅하기 때문에 어떤 성능 문제에 대한 책임도 져야 한다. 그렇지 않은가? 사실은 그렇지 않다. 필자가 본 성능 문제 중 열에 아홉은 클라우드 인프라에 문제가 있기보다는 애플리케이션 설계나 기술 선택의 문제였다. 이것만 생각하자. 퍼블릭 클라우드에서 용량은 그냥 추가하면 된다. 용량은 필요할 때 필요한 만큼 확장할 수 있다. 하지만 느린 재고 관리 애플리케이션 문제라면, 용량을 추가하는 식으로는 문제를 해결할 수 없다. 이제 필자가 수도 없이 이야기한 규칙을 다시 생각해 보자. “엉성한 온프레미스 애플리케이션을 퍼블릭 클라우드로 이전하면, 엉성한 퍼블릭 클라우드 애플리케이션이 된다.” 퍼블릭 클라우드로 이전하면서 흔히 일어나는 일이다. 애플리케이션을 퍼블릭 클라우드로 보내기 전에 애플리케이션 설계나 데이터베이스나 미드웨어 사용, 또는 다른 기반 기술을 점검하지 않는 것이다. 현실은 이런 애플리케이션이 단지 성능이 엉망인 것에 그치지 않는다. 제대로 설계되지 않은 애플리케이션을 처리하기 위해 퍼블릭 클라우드가 씨름을 하면서 클라우드 요금이 50~60% 더 나오기 십상이다. 일반적으로 비효율적인 I/O, 인터랙션이 너무 많은 애플리케이션, 최적화하지 않은 데이터베이스 쿼리 등이 문제의 원인인 경우가 많으며, 이외에도 잘못될 수 있는 것은 너무나 많다. 이 문제의 해법은 대부분 기업 IT 부서가 듣고 싶지 않은 이야기다. 애플리케이션을 리팩터링하는 것이다. 여기에는 애플리케이션 설계 조정과 애플리케...

2017.07.25

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.6