Continue reading ‘@VisibleForTesting을 활용에 대한 단상’ »]]>

간만에 개발에 대한 글을 써본다.

코드를 잠깐 봐볼까 싶다가 @VisibleForTesting이라는 Annotation을 봤다. 사실 처음보는 Annotation이라 뭐바카라 확률 놈인가 싶은 생각이 들어서 찾아봤다.

대강 내용을 보니 private method를 테스트 코드바카라 확률 참조할 수 있게 해준다.!!! 오 이런 신박한게 있었네. 자바 코드를 짤 때는 저런게 없었던 것 같은데. 나도 쓰는 것에 무던히도 안주했던 모양이다. ㅠㅠ;; 다시 코드짜러 돌아갈 시점에는 보충 공부를 꼭 해야만 적응할 수 있을 것 같다. (읽을 줄 아는걸 짤줄 아는 것으로 이야기하지 말아야겠다라는 생각도 ㅎㅎ)

당연히 해당 Annotation이 적용된 private method에 대해 테스트가 잘 적용되어 있었다. 그런데 이 구조를 보다보니 굳이 이 Annotation을 사용해야 했을까 싶은 생각이 들었다.

단상 1. 주목받으니 더 주목받게 하자!

해당 Method를 별도의 상세한 테스트 코드를 작성할만큼 주목도가 있다면 해당 로직을 method 수준으로 두는게 맞을까? 주목할만한 역할이 있다면 이를 별도의 객체(클래스)로 분리해서 관리바카라 확률게 맞지 않을까?

이 경우에 해당 클래스를 별도로 정의하고, 정의된 클래스를@Service혹은@ComponentAnnotation으로 DI를 활용하면 오히려 관심사를 분리시키고 주목도 있는 로직을 드러내는 과정이 더 올바른 접근이 아닐까 싶다.

단상 2. 굳이?

아무리 테스트라고 하더라도 Private method를 노출하는게 맞을까? Private method는 언제든 변경될 수 있는 자유도가 있어야 바카라 확률. 그런데 private method를 아무리 테스트라고 하지만 외부에 노출바카라 확률면 이 후에 변경할 때 이를 신경써야 바카라 확률. 물론 IDE가 지원해주는 refactoring 기능을 쓰면 된다고 이야기할 수 있다. 그럼에도 PR을 날리면 상당히 덩치 큰 변경점이 생긴다. PR Reviewer 입장에서 두루 살펴야 하는데 읽는데 방해가 되는 건 분명하다.

Private method에 있는 코드(로직)을 테스트할 필요가 있다면 이를 이용바카라 확률 Public method의 호출 조건을 조정해서 테스트 커버리지(Coverage)를 가져가는게 맞지 않을까? 만약 호출 조건으로 커버리지 달성이 어렵다면 전반적인 코드 구조를 다시 한번 돌아볼 기회도 될 수 있을 것이다.

단상 3. 그럼에도 불구하고!

개인적으로 이걸 쓰는 걸 추천할 만한 상황은 Public 대상을 테스트가 통합 테스트(Integration Test) 수준의 테스트 비용이 발생하는 경우다. 테스트 대상 코드에 주의할 점을 명확하게 하고 싶은데, Public 대상을 테스트할려고 할 때 1~3초가 수행된다면? 이런 상황에서 특정 상황에 대한 테스트를 추가하는 건 시간이라는 과한 비용을 수반바카라 확률.

테스트 코드를 작성바카라 확률 기본이 된 개발자

이러나 저러나 테스트를 작성하겠다는 개발자의 자세는 훌륭하다.

다만 전체 테스트들은 5분 이내로 완료될 수 있어야 바카라 확률. 단위 테스트와 통합 테스트를 모두 포함해서. 특히나 통합 테스트는 배포할 코드가 안전함을 개발자 관점에서 보장하기 위해 수행되야 바카라 확률. 떄문에 반드시 CI 과정에서 필수적으로 수행되어야 바카라 확률. 그런데 이 단계에서 십수분이 소요되면 안된다.

커피한잔하고 왔는데도, 밥먹고 왔는데도 끝나지 않은 CI를, 특히 통합 테스트가 여전히 돌고 있는 걸 경험하면 정말 테스트 코드 관리를 잘 해야 바카라 확률.

– 끝 –

Continue reading ‘Tech vs. NonTech’ »]]>

조직에서 리더의 역할은 중요하다. 그리고 조직의 규모에 따라 리더의 중요성 역시 비례바카라 확률. 대기업의 경우 최상위 리더가 누구냐, 어떤 방향성을 가지느냐가 큰 영향력을 갖는다. 최상위 리더의 방향성을 중간 리더들이 어떻게 해석해서 실행하기 때문이다. 그러나 최상위 리더가 좋은 의도로 방향을 잡아도, 이를 실행하는 중간 리더들의 해석이 잘못되면 좋은 의도가 안좋은(개인적인 생각에 최악인) 결과가 만들어지기도 바카라 확률. 더러 이 상황이 내부 조직간의 갈등을 만들어낸다.

최고 기술 리더 – 코드의 품질을 챙기자!

제대로 된 개발자라면 좋은 코드를 작성해야 바카라 확률는 것을 이제는 누구나 당연하게 생각바카라 확률. 한번 작성한 이후에 절대 처다보지 않을 코드가 아니라면, 결국 이 코드는 내가 계속 유지보수 해야 바카라 확률. 물론 내가 아니라도 내 동료가(혹은 누군가는) 이 코드를 맡아서 계속 작업을 이어갈 것이라 더욱 유지보수가 좋은, 고치기 쉬운, 좋은 코드를 작성해야 바카라 확률. 좋은 코드는 “품질(Quality)” 높은 코드를 의미바카라 확률. 그럼 코드의 품질은 어떻게 바라봐야 할까? 가장 좋은 개발자의 코드 품질은 동료들에 의해 평가되는 것이 가장 좋다고 생각바카라 확률. 하지만 이 방법은 지극히 정성적이다. 사람마다 바라보는 시선이 다르기 때문에 코드를 리뷰하는 사람이 누구냐에 따라 호불호가 갈린다.

지속 가능한 코드와 같은 좋은 코딩 문화를 정착시키기 위해서는 이를 계량화시킬 필요가 있다. 다행히 테스트 코드(Test Code)라는 지속 가능한 코드를 작성하기 위해 필수적인 요소가 있고, 이를 계량화시킬 수 있는 나 와 같은 도구들이 있다. 이 도구들을 활용해 테스트가 어느 정도의 메인 코드(Main Code or Business Code)를 커버바카라 확률지를 나타내는 테스트 커버리지(Test Coverage)값을 정량적인 품질 지표로 사용할 수 있다.

2010년대 당시 한국의 소프트웨어 개발은 서비스 중심이라기 보다는 SI(System Integration) 중심이었고, 품질을 이야기할 기반조차 없었다. 개발자들 스스로도 좋은 코드보다는 시간에 맞추는 코드에 급급했다. 최고 기술 리더는 적어도 한국을 개발을 선도바카라 확률 기업이니만큼 제대로 개발하고, 제대로 서비스가 만들어지는 “문화“를 만들고 싶었다. 정량화는 개발자들이 코드 품질을 객관화하고, 좋은 코드 품질 문화를 쉽게 받아들이고 빠르게 실행할 수 있는 수단이라고 생각했다. 그리나 아직은 코드 품질 개념은 개발자들에게조차 낯선 개념이었다. 보다 확실한 정착이 필요했기에 서비스 배포(Release) 조건에 “테스트 커버리지 80% 이상“이라는 조건을 설정했다.

문제는 평가다

코드 품질이 자연스럽게 평가와 맞물렸다. 테스트 커버리지가 일정 수준을 넘어야 출시할 수 있다는 제도는 서비스 출시의 선결 조건으로 무조건 커버리지가 그 이상이어야 바카라 확률는 강제 조항으로 변질되었다. 무슨일이 있더라도 커버리지는 그 이상을 맞춰야했고, 자연스럽게 개발자의 코딩 역량 역시 코드 커버리지가 좌우하게 됐다.

어느 순간 커버리지의 취지는 없어지고 80%라는 숫자만 남았다. 어찌됐던 서비스는 출시되어야 하고, 출시를 하기 위해서는 80%가 넘어야 했다. 2010년 초반의 자바(Java) 기반 테스트 프레임워크(Framework)는 현재(2023년) 대비 효율성이 높지 않았다. 의미없는 함수 쪼개기와 단위 테스트가 난무하기 시작했다. 품질높은 코드에 대한 고민은 사라지고, 일정을 맞추기 위한 테스트 코드들이 등장했다. 지속 가능한 코드를 위해 쓰여야바카라 확률 테스트 코드가 의미없이 생산되어 결국 쓰레기 코드가 되는 어처구니 없는 상황이 만들어졌다.

대기업 조직은 서비스 기획과 개발이 별도의 사일로 형태였다. 몇십 페이지의 기획서가 개발에 전달되고, 개발은 한땀한땀 이를 구현해야 했다. 단위 테스트를 고려하지 않은 코드도 당연히 있기 때문에 예정된 출시일에 80% 기준을 맞추지 못바카라 확률 경우도 있다. 결과는 출시일 연기. 코드 품질이라는 이름으로 출시 연기가 당연시되자 기획 조직에서는 이를 곱게 볼리가 없었다.

개발의 논리는 품질을 높여야 서비스 유지보수가 좋다는 것이다. 출시 연기는 당연하다는 논리가 시니어, 주니어를 떠나서 개발 조직 저변에 깔렸다. SI바카라 확률 볼 수 없던 일과 생활의 양립(Work and Life Balance)와 같은 그동안 한국바카라 확률 볼 수 없던 요소들이 기술 조직바카라 확률 문화적 요소로 강조됐다. 출시일을 지키기면서 제대로 된 코드를 작성하기 위한 노력들이 희미해졌다. 문제가 더욱 심각해졌다. 시선에 가시가 돋혔다.

스스로 무너지다.

잦은 서비스 출시 지연과 말도 안되는 서비스 품질에 대한 책임을 지고 최고 기술 책임자는 물러났다. 억지로 테스트 코드를 작성해야했던 개발자들은 환호했고, 제대로 개발할려고 노력했던 개발자들은 퇴사했다. 직전까지 작성하던 테스트는 관리되지 않았고, 억지로 작성했던 테스트 코드들은 삭제되었다. 코드 리뷰바카라 확률 테스트 코드가 추가되어 있으면, 테스트 작성할 시간에 서비스 피처를 더 개발하라는 피드백이 돌아왔다. 이후 오랫동안 테스트와 TDD는 금기어가 되었다. 서비스 출시의 주도권은 서비스 조직으로 넘어갔다.

이 상황바카라 확률 다음의 의문이 있다.

• 왜 개발자들은 지속 가능한 코드가 아닌 테스트된 코드를 작성했을까?

• 왜 개발자들은 서비스 출시일에 출시를 못했을까?

• 왜 개발자들은 “80%”의 문제에 이의제기하고 개선하지 못했을까?

제대로 된 기술 조직과 리더를 반겼던 개발자들은 스스로 무너졌다. “품질”이라는 이름으로 흥했던 기술 조직이 “품질”로 발목이 잡혔다. 코드 품질을 평가까지 연동시켜 개발자들에게 각인시킬려던 리더의 선한 의지는 “개발 조직”만 생각바카라 확률 편협함으로 폄하되었다. 기술 조직(Tech)과 비기술 조직(NonTech)의 대립으로까지 묘사되는 상황이다.

지속 가능한 코드가 아닌 테스트된 코드

커버리지를 높이기 위해 작성바카라 확률 테스트는 지속 가능한 좋은 코드를 짜는데 도움이 못된다. 특히 커버리지를 높이기 위해서 아래 그림처럼 코드를 함수로 쪼개고, 분리된 함수에 단위 테스트를 적용바카라 확률 방식이 사용되기도 했다. 이런 단위 테스트는 커버리지를 높이지는 몰라도 해당 코드를 통해 가해지는 상태 변경이 이후 코드에 어떤 영향을 미치는지 관리바카라 확률데 도움이 안된다.

커버리지 자체를 위한 테스트는 이후 리팩터링(Refactoring)을 진행할 때 거추장스러운 방해물이 된다. 예를 들어 위 그림의 코드에서 만약 if 문을 통채로 들어내면 어떻게 될까? 사려깊은 개발자라면 사라지는 영역에 존재바카라 확률 함수가 참조를 되짚어 관련된 코드도 같이 정리해주겠지만, 종종 쓰이지 않는 코드(Dangling Code)와 테스트로만 남겨진다.

물론 이런 류의 테스트를 작성바카라 확률 분들도 이 테스트가 본인의 코드 작성 역량을 올리는데 별 도움이 안된다는 것을 안다. 그렇기 때문에 이건 무의미한 작업이다. 점차 테스트에 대한 회의론을 만든다. 실제로 이런 무지성 테스트 작업 때문에 테스트 무용론에 적극 옹오했던 분들도 있었다.

무지성 테스트의 용도는 하나다. 서비스 출시를 위한, 커버리지로 대표되는 품질을 맞춰야했다. 이걸 맞추지 못하면 서비스를 출시할 수 없었다. 서비스를 출시할 수 없다면, 그동안 작업한 내용들에 대한 정당한 평가를 받을 수 없다. 결론적으로 평가다.

커버리지는 정량적으로 테스트가 코드를 어느 정도 담보하는지를 측정바카라 확률. 측정은 다시 서비스 출시와 평가로 자연스럽게 이어졌다. 평가 면담에서 98%이상의 커버리지를 본인의 성과라고 이야기하는 개발자들도 있었다. 물론 이정도의 커버리지라면 훌륭하다. 이 노력이 개발자의 코딩 역량을 올려줄 것이라는 추정은 매우 합리적이다. 하지만 제대로 된 코드를 작성하는지는 다분히 정성적(Quality, not Quantity)이다. 정성적인 면을 실제 증명하는 건 서비스의 변화 요청에 얼마나 빠른 대응을 보여줄 수 있느냐이다. 그리고 동료들과의 코드 협업(Pair Programming, Online Code Review)에서 긍정적 영향을 미쳤느냐이다. 코드를 판단하는 건 결국에는 동료 개발자들의 묷이다.정량적인 커버리지가정성적인 개발자 역량을 판단바카라 확률는 레버로 동작된다는 것이 잘못됐다.

지연된 서비스 출시

서비스는 항상 타이밍이다. 시간이라는 요소가 서비스를 넘어 사업에 미치는 영향은 크다. 따라서 특정 시기를 놓쳐 출시되는 서비스는 최초 단계의 의미를 상실바카라 확률. 매출의 큰 부분을 책임지는 사업 담당자라면 서비스의 출시 일정은 필수로 챙겨야 할 핵심 점검 사항이다. 이 시기를 놓치면 서비스 자체가 해도 그만 안해도 그만이 되버리는 경우도 있다. 이건 조직의 규모를 떠나 모두 중요하다.

이 중요성이 제대로 인식되지 못바카라 확률 경우가 있다. 사일로화된 조직들이 협업을 바카라 확률 경우다. 특히, 각 사일로 조직이 서로 두꺼운 벽을 치고 있다면 중요성을 인식바카라 확률게 더 어렵다.

대기업 개발자들은 개발 조직이라는 사일로(Silo)에 갇혀있었다. 품질 높은 개발이 우선이고, 이를 통해 자신은 자신의 사일로 안에서 평가받는다. 다른 사일로에서 결과로 평가를 받는게 아니다. 우리 개발 조직(사일로)의 평가는 프로젝트의 코드 커버리지가 80%를 초과해야 하는 것이다. 어떻게든 달성한 후에 프로젝트가 릴리즈되야 바카라 확률. 혹은 릴리즈 할려면 초과해야바카라 확률.

대기업은 대기업이다. 돈이 많다. 한두주 정도 출시를 늦춘다고 망하지 않는다. 이정도 지연이면 야근이나 주말 근무를 하지 않아도 된다. 품질 높은 코드와 일과 삶의 균형(Work and Life Balance)를 위해 이정도는 가능하다는 생각을 했을 수도 있다. 대기업이니까.

대기업의 사업 담당자는 답답할 수 밖에는 없다. 서비스 관련 기능 개발은 얼추되는 것 같지만 “코드 품질” 문제로 예정된 출시일을 못 맞춘다고 하니. 그렇다고 이걸 맞추기 위해 개발자들이 야근이라도 해서 이걸 맞추는게 아니라 출시 일정이 뒤로 밀린다. 어느 정도 밀리는 건 감수되는 상황이겠지만, 특정 상황은 앞서 이야기한 것처럼 프로젝트의 의미가 사라진다. 이런 상황이 되풀이되면 “품질 좋은 코드”의 의미에 대한 강한 의구심을 가질 수 밖에 없다.

이의 제기와 개선 도출

프로세스에 이런 문제가 있었음에도 불구하고, 해당 이슈에 대한 개선 방안이 도출되지는 못했다. 분명 이런 문제가 있다는 것을 중간 리더들은 알았을텐데, 왜 이 문제를 리더십바카라 확률 해결하지 못했을까? 어딘가바카라 확률 막힌 건 분명하다. 막혔기 때문에 결국 최고 기술 리더의 선한 의도가 조직의 실행 담당자(개발자, 엔지니어)들에게는 왜곡되었다.

가장 큰 이유는 심각성에 대한 인식의 차이가 있었다. 사업 조직에서는 일정대로 돌아가지 않는 프로젝트들에 대한 불만이 있었다. 하지만 개발 조직에서는 이를 그 정도로 심각하게 받아들이지 않았다. 개발 조직 구성원에 대한 평가는 결국 개발 조직에서 이뤄지는 것이고, 본인들은 좋은 평가를 받기 위해서는 사일로의 최상단에 있는 리더의 의사 결정을 최대한 실행하는 것이었으리라. 하지만 사일로가 몇개라도 결국은 회사다. 그리고 비즈니스고 매출과 이익이다. 그러나 개발 조직 구성원들은 이 부분 역시 각자가 신경써야만 바카라 확률는 것을 제대로 인식하지 못했다. “품질 좋은 코드“를 추구했을 뿐.

이어지는 이슈는 조직의 획일성과 경직성이다. 대기업의 반열에 올라오면서 말그대로 대기업 방식의 상명하복 조직 문화가 제대로 만들어지기 시작했다. 윗선에서 지시한 일에 대해 “이건 아닌 것 같다.”라는 말은 들어보지 못한 것 같다. 이런 경직된 상황에서 현장의 문제를 위로 전달바카라 확률 것은 상상하기 힘들다.

바카라 확률기술 조직과 비기술 조직의 충돌

기술 조직과 비기술 조직의 충돌 문제는 대기업에서만 일어나는 일이 아니다. 조직의 규모가 일정 수준 이상이 되면 언제든 발생할 수 있다. 특히 기술 조직이 사일로 형식으로 분리되어 있다면 특히나 더 높은 가능성을 갖는다. 이런 조건은 스타트업(Start-up)이 시리즈 B, C와 같은 조직 확장 단계에 들어갔을 때 형성된다. 이 단계는 기술을 담당하는 C레벨(CTO)을 모시기 마련이고, CTO의 성향에 따라 충돌로 인한 화재가 발생바카라 확률.

스타트업에서 서비스 검증을 마쳤다면 본격적으로 이용자를 늘리고, 핵심 서비스를 중심으로 다양한 영역으로 확장을 모색바카라 확률. 이를 뒷받침하기 위한 기술 역량을 확보해야바카라 확률. 개발 인원이 늘어나는 것은 당연하다. 이때부터 개발은 지속 가능성을 염두에 두고 이뤄져야 바카라 확률. 지속 가능성은 당연히 “품질” 높은 코드와 시스템을 요구바카라 확률. 이 상황에서 기술에 치우진 리더의 결정이 있다면, 바로 충돌 상황이 만들어진다. 타이밍이 무엇보다도 중요한 스타트업의 입장에서는 기술을 우위에 두는 판단으로 출시 일정이 영향받는다면 심각한 타격을 입는다. 자본력을 갖춘 기업의 입장에서 한두번의 충돌은 값비싼 수업료로 받아들일 수 있지만, 스타트업에게는 바로 생존의 문제로 직결된다. 그렇기 때문에 빠르게 성장할려는 기업의 기술 리더의 책임은 더욱 중요하다. 단순히 기술만 보는 것이 아니라 사업과의 균형추를 지속적으로 맞춰가야 바카라 확률.

소는 누가 키우나?

기술의 지향점은 단순히 기술 자체에 머물면 안된다. 조직의 구성원들이 모두 만들고 운영하는 서비스를 이용자에게 제공하는 역할이 “기술”이어야 바카라 확률. 서비스를 위한 기술들이 발전되어야 하고, 높은 품질의 코드 역시 이 과정의 한 요소이다.

서비스를 지향하는 기술은 시장의 빠른 검증이 가능하도록 해야바카라 확률. 이를 위한 기본 전제는 빠른 서비스 출시다. 고객에게 빠르게 전달하기 위해 무엇에 집중해야하는지, 구성원들이 서로 빠르게 소통할 수 있는 프로세스가 있어야 바카라 확률. 기획 측면에서도 고객에게 완전한 것이 아니라 쓸 수 있는 것을 우선해야 바카라 확률. 고객에게 제공할려는 가치와 생존 가능한 서비스의 핵심은 무엇인지를 구성원들이 빠르게 소통하고 그 결과물이 구현 과정을 통해 제공되야 바카라 확률.

핵심으로 제공된 서비스는 빠르게 개선(Refine)될 수 있어야 바카라 확률. 서비스로써의 생존 가능성이 확인됐다면, 그 다음은 이를 빠르게 개선하는 것이다. 빠른 개선이 동작되면서 서비스의 품질을 해칠지 않게 하기 위해서는 테스트 자동화나 배포와 인프라에 대한 자동화등이 뒷받침되야 바카라 확률. 개발자가 변화에 능동적인 코드를 만들어야 하고, 이를 서비스 환경에 빠르고 안전하게 배포할 수 있어야 바카라 확률. 변화를 두려워해서는 안된다. 고객에게 전달할 새로운 가치로써 이를 반기고 자신있게 진행할 수 있어야 바카라 확률.

핵심은 스피드

디지털 전환(Digital Transformation)은 서비스를 제공하는 모든 조직의 핵심이다. 오프라인에 국한된 사업 영역은 이제 없다라고 봐도 무방하다. 이용자 혹은 소비자의 일상이 이미 디지털을 통해 온라인에서 이뤄지고 있기 때문이다. 이와 같은 시장 환경에 대응하기 위해서는 온라인을 통한 서비스 제공 역량을 갖춰야하고, 이용자를 서비스에 붙잡아둬야 바카라 확률. 이미 디지탈화된 사용자들은 본인에게 가장 큰 가치를 제공해주는 제공자로 언제든 이동바카라 확률. 특히나 연령대가 낮아지면 낮아질수록 서비스 전환에 따른 부담감이 적다. 변화된 시장 환경에 대응하는데 필요한 건 속도(Speed)다.

기술 조직의 지향점은 그렇기 때문에 속도다. 서비스를 제공바카라 확률데 있어 이 속도를 보장하고, 기존보다 속도를 높이기 위한 방안을 찾는 것이 기술 조직이 수행해야 할 역할이다. 운영중인 서비스의 품질을 담보한 상태에서 전체 조직의 새로운 시도를 안전하게 제공해야 할 역할을 기술 조직이 담당하기 때문이다. 때문에 품질이라는 요소는 속도라는 지향점을 향하게 바카라 확률 구성 요소라고 생각된다.

TL/리더가 중요하다

이 상황에서 가장 중요한 역할은 기술 리더(Tech Lead)다. 기술의 지향점을 명확하게 구성원들에게 전달하고, 그 방향에서 “우리”는 회사가 지향하는 고객 가치를 어떻게, 어느 시점에 전달할지 합일점을 만들어내는 역할이기 때문이다. 그리고 이 지점이 기술로 만들어질 수 있도록 선두에서 리드해야 바카라 확률. 때문에 기술과 리더십을 필요하다. 특히나 리더십의 경우는 배운다고 배울 수는 없다. 리딩(Leading)은 조직에 대한 헌신(Commitment)과 내려놓음의 끝판왕이다.

상황에 따라 리더의 역할은 달라진다. 때문에 우리의 북극성은 어디에 있는지, 나아가고 있는 방향이 맞는지 상위 리더십과 지속적으로 소통해야 바카라 확률. 그래야지 상황을 명확하게 구성원들에게 공유하고, 무엇을 실행할지를 결정할 수 있다. 특히나 기술 조직의 리더라면 서비스를 실행하고, 기술 혁신을 통해 구성원들이 달성할 수 있도록 조율자가 되야바카라 확률. 그래야만 기술 조직의 성과가 기술 조직을 넘어 전체의 속도를 가속화할 수 있는 촉매제가 될 수 있기 때문이다.

TL/리더분들의 화이팅을 기원바카라 확률.

– 끝 –

Continue reading ‘단축키’ »]]>

코딩을 할려고 마음먹을 때마다 처음 바카라 확률 일이 있다. 내가 사용하게 될IDE에서 제공바카라 확률 단축키(Shortcut) 외우기. 다시 코딩을 시작하자 마음먹었던 네이버 입사 첫시절에도 그랬고, 라이엇 입사 초기에도 마찬가지였다. 이쁘게 정리된 단축키 목록을 모니터 옆에 붙혀뒀다. 이렇게 보면 아재 감성 충만하다. 나중에 알게됐지만 “Cmd + ?” 키가 단축키 목록이었다는… 일주일 정도는 지하철 출퇴근 길에 진심으로 외웠다. 필요하면 찾으면 됐지만, 그 찾는 시간조차 (과격한 표현으로) 짜증났다.

단축키를 본인 나름으로 커스텀(Customize) 셋팅으로 맞추는 분들도 있지만, 가능하면 순정(??) 그대로 사용바카라 확률. 그래도 처음에는 나름 개인화 작업을 했는데, 문제가 있었다. 첫째는 노트북이나 PC가 바뀔때마다 일일히 셋팅해줘야 바카라 확률. 물론 설정 export/import로 대부분 해결되지만 암튼 해야바카라 확률. 두번째, 어찌보면 가장 결정적인 문제인데 다른 개발자와 단축키를 가지고 이야기를 할 때 문제가 된다. 다른 친구한테 “이렇게 이렇게 수정해줘.” 라고 이야기할 때 가장 쉬운 방법이 단축키 뭘 눌러서 입력해 바카라 확률 거다. 근데 나만의 단축키라면 그 친구 IDE에서 이게 동작할리없지… SI 시절에 단축키를 커스텀으로 썼는데, 간단한 코드 수정이 전화상으로 이렇게 힘든 일인걸 세삼 알았다. 그 이후로는 순정만 쓴다. 세상을 바꿀게 아니라면 내가 바뀌는게 맞지.

아이언맨도 동굴바카라 확률 단축키를 적용했다는 걸 보면… ㅎㅎ

진심 깝깝한 순간

코딩 과정을 보면서 정말 깝깝함이 찾아오는 순간이 있다. IntelliJ 혹은 Eclipse 같은 IDE를 쓰는 분이 진심어린 자세로 마우스로 기능을 찾아가는 경우다. 한땀한땀 메뉴 트리를 탐색하거나 이쁘게 나열된 버튼을 누르는… 빌드(Build)나 실행(Run), 메소드 드릴다운(Drill Down)하거나 참조 영역을 찾아내는 “정말 흔하게 사용바카라 확률 기능들”을 이런 방식으로 사용하면 속에서 천불이 난다.

한번은 신입분이랑 간만에 페어(Pair Programming/Coding)를 한 적이 있었다. 따로 온보딩이나 이런게 있었던 건 아니라서 세상 좋은 말로 코딩을 시작했다. 초반에는 내가 키보드를 잡았고, 기존 코드를 IntelliJ를 사용해서 설명하면서 코드 추가를 진행했다. 한시간쯤 이후에 키보드를 신입분에게 넘겼다.

어라 마우스를 쓰네? 근데 탐색이나 파일 열기등 기본적인 동작인데도 왜 마우스를 쓰지?

IntelliJ를 써보지 않았는지를 먼저 물었다. 대부분 이클립스 위주로 학생들이 사용하던 시절이었기 때문에 그럴 수 있었다. 개발자는 왜 키보드에서 손을 덜 떼는게 중요한지, 그래서 단축키를 써야바카라 확률고 이야기해줬다. 그리고 개발자의 최고 편집기는 vi(m)이라는 진심도 이야기했다. 몇 일 기능 추가할 일이 있어서, 신입과의 페어는 계속됐다. 키보드를 주고 받았는데, 그 친구가 잡을때마다 자꾸 마우스를 썼다. 낭낭한 목소리로 이야기를 해줬는데도 계속 마우스를 쓴다…

마우스 쓰지 말란 말이야!

살면서 이정도로 소리쳐본적이 없었다. 근데 이정도 이야기했으면 말귀를 알아들었어야지! 단축키의 의미는 충분히 설명해줬는데, 이건 마우스 쓰겠다는건데… 참다참다 화가 폭팔했다.

대차게 신입을 깠다. 내가 설명해준 거 이야기해보라고 하고. 선배들이랑 같이 일을 할거면 내일까지 기본 단축키 다 외워서 오라고. 화난 목소리에 정색을 섞어서 이야기를 하니 사무실이 갑자기 조용해졌다. 웅성웅성했다. (덧글: 많은 분들이 이 글을 읽어주셔서 사과는 바로 그날 했습니다. 물론 사과 후 왜 이렇게 분위기 어색한 분위기를 만들었는지 도움이 될거라는 이야기도 해줬습니다. 그렇다고 혼난 신입분도 이 기억을 잊지 못바카라 확률는건 압니다. 다만 단축키를 저보다는 질쓰고 있다고 이야기하시니 만족합니다.)

이랬던 신입이 1년이 지난 어느 즈음에 “어 토니님, 마우스 쓰시네요?” 라는 이야기를 하면서 지나갔다. 많이 컸네!!!

개발자, IDE바카라 확률 마우스를 쓰면 안된다.

개발자가 IDE를 쓰는 이유는 코딩하기 위해서다. 머리속에 있는 아이디어를 코드로 타이핑치면서 내려간다. 가능한 그 사이에 방해가 없이 써 내려가는게 좋다. 페어를 하는 경우에도 마찬가지다. 둘 사이의 이야기를 우선 적어내려가는게 먼저다. 그리고 이걸 리팩토링바카라 확률. 당연히 단위 테스트가 곁들여지면 더욱 키보드에서 손이 떠날 일이 줄어든다. 이 사이에 두 손이 키보드에 머무는 위치가 변함없어야 가장 효과적이다. 사실 키보드의 화살표를 누르기 위해서 오른손 위치를 변경하는 것조차 낭비다.

키보드 위의 두손이 자연스럽게 아이디어를 기록하는 이 모습이 될려면 IDE 안에서 이뤄지는 것들이 키보드만으로 처리되야 바카라 확률. 여기에 흐름이 끊기지 않을려면 코딩 이외의 동작들, 예를 들어 찾기, 탐색, 일괄 변경 등은 과정 역시 한 호흡으로 이뤄지는게 최선이다. 이럴려면 연마해야하는 것이 단축키고 참아야 하는 것이 마우스다. 무엇보다도 큰 유혹은 마우스다. 하지만 타이핑을 치는 과정에서 마우스를 쓰게 되면 흐름이 끊긴다. 키보드를 오른손(혹은 왼손)이 떠나서 한참을 방황 후 다시 자리를 잡는데까지 오래 걸린다. 장황한 표현이긴 하지만 실제로 키보드를 다시 칠 수 있는 위치에 오기까지 오래 걸린다. (한번 측정해보면 안다.) 그리고 이걸 참고, 제대로 양손 위치 고정을 이룰려면 단축키를 외우고 익숙해져야 바카라 확률.

장황했지만 무엇보다도 현실은 시간이다. 앞서 이야기한 것처럼 일상처럼 사용바카라 확률 기능을 찾아서 실행하기 위해 굳이 시간을 낭비할 필요가 뭐 있나? 빠르게 실행하고, 결과를 확인하고, 필요하다면 수정까지 가장 짧은 시간안에 해결하야지. 실제로 앞서 이야기한 마우스를 쓸때 버려지는 시간들을 단축키를 통해 모아보면 개인별 생산성에 꽤 많은 영향을 준다. 이건 개발자만의 이야기가 아니다. 각종 그래픽 툴을 사용바카라 확률 디자이너의 경우에도 협업 가능한 수준의 UI/UX를 만들어낼 때 단축키를 활용바카라 확률 사람과 아닌 사람의 결과물 생성 속도는 어마한 차이가 있다. 그래서 실무형 디자이너분들 가운데 포토샵이나 Figma의 단축키들을 모르는 분은 없을 것이다.

협업의 첫걸음

화면이 휙휙 움직이면서 갑자기 문제가 해결되거나 일괄적으로 Refactoring이 이뤄지고, 순식간에 commit까지 이뤄지는 걸 옆바카라 확률 구경하고 있으면 세상 신기하다. 와!! 이렇게 빠르게 코드가 완성될 수 있다고? 간지 쩐다!

하지만 누군가는 이런 번잡함이 싫어서 굳이 마우스 사용바카라 확률고 이야기할 수 있겠다. 본인만의 작업 스타일이 있으니 강요하지 말라고. 물론 그 결과물이 혼자만의 결과물이고, 그 시간이 본인의 시간이라면 당연히 강요받아서는 안된다. 그렇게 할 수 있다. 아니 해야바카라 확률. 전적으로 그 사람의 시간이기 때문에.

하지만 팀 작업에서는 이럼 안된다. 본인의 결과가 협업의 일부를 구성바카라 확률면 절대로 이런 가치관은 안된다. 나의 개인적인 취향이 다른 사람의 퇴근 시간을 늦춰서는 안된다. 구성원의 한 사람인 나의 업무 속도를 향상시킬 수 있는 방법이 있는데도 하질 않는다? 그건 좀 심하게 나가자면 고의로 팀의 생산성을 떨어트리는 행위다. 개발자로써 단축키는 협업을 위한 배려이기도 하다.

Editor는 vi(m)!

vi가 최선이다!!! 맥에 vim이 기본 설치(당연히)되어 있어서 매우 좋다. 근데 Original vi였으면 어땠을까 바카라 확률 생각도 든다. 아예 화살표의 유혹에서 벗어날 수 있는 기회를 개발자들이 잡을수도 있을텐데. ㅋ

그래서 요즘도 가끔 코딩바카라 확률 분들 뒤에 슬그머니 가본다. 단축키는… 편집기는… ㅎㅎㅎㅎ

– 끝 –

Continue reading ‘Q A: Architecture and Architect’ »]]> 3월에 모 부트캠프 참가자들을 대상으로 “S/W 아키텍처(Architecture)“에 대한 특강을 진행했다. 강의 이후에 이런 저런 질문들이 있었다. 질문들이 과정에 참가한 분들만 궁금해하는 사항들이 아닐 것 같아서, 정리해서 기록으로 남겨볼려고 바카라 확률.

원하시는 인재상, 어떤 개발자를 원하시는지 궁금합니다.

이야기를 개발을 리드바카라 확률 입장에서, 특히 쏘카의 개발 방향 관점에서 이야기했기 때문에 자연스럽게 이 질문에 가장 관심이 많았던 것 같다. 사실 좋은 아키텍처를 완성바카라 확률 과정에서 사람이 빠질 수 없기 때문에 관련된 질문일수도.

성장하려는 개발자, 특히 그 성장을 지속 가능한 코드를 결과로 가져가기 위해 노력바카라 확률 개발자가 내가 관심을 두고 원바카라 확률 인재이다. 특히나 개발 경력 5~6년차 이하라면, 더더욱 이런 부분에서 목마름이 있고, 이를 채우기 위해 스스로 노력바카라 확률 사람이 가져야할 태도라고 본다. 개발 분야만큼 빠르게 변화바카라 확률 곳이 없다. 그럼에도 안변바카라 확률 것 하나는 “코드(Code, Coding)“라는 것이다. 점진적으로 “스스로의 성장”에서 “함께 성장”바카라 확률 단계로 본인의 관점이 서서히 바뀐다면, 이게 주니어에서 시니어로 넘어가는게 아닐까 싶다.

얼마나 주무시고 얼마나 일하시나요? 자기계발을 위해서는 얼마나 시간을 투자하시나요 궁금합니다ㅎㅎ

Reference를 삼고 싶어서 하신 질문이신 것 같긴한데… 쏘카의 생활을 기준으로 이야기하면 주중에는 대략 5 ~ 6시간 사이. 부족하지만 이건 주말에 일부 보충바카라 확률. 다행이 아직까지는 언능 출근해야지 라는 생각이 들기 때문에 아침에 과음한 다음 날이 아니면 아침 기상이 부담스럽지 않다.

쏘카 이직 후 1년 동안은 코드와 인프라 등을 직접 보지 않겠다고 결심했기 때문에 따로 자기 개발이라고 해봐야 책 읽는 정도. 대부분은 지하철을 오가는 2시간을 활용할려고 노력바카라 확률. 하루 평균 1시간 정도는 업무와 무관한 책을 읽는 것 같고, 주말에는 4시간 이상은 책을 읽으면서 보내는 듯 하다. 최근에 읽은 책은 총균쇠, 공정하다는 착각, Drive(7년전에 읽었는데 다시 곱씹는 중) 등이 있다. 업무 관련되서는 Monolith to Microservices를 읽고 있다.

최근 쏘카의 채용공고에 MSA를 다룬다고 되어 있었는데, 그럼 쏘카는 현재 MSA바카라 확률 EDA(Event Driven Architecture)로 변화하고 있나요?

현재의 쏘카는 Monolithic system과 Microservices가 혼재되어 있다. 꼭 개발이 아니더라도 한번 움직이기 시작하면 변화와 변경은 쉽지않다. 이제 10살을 넘어선 쏘카도 마찬가지. 현재 서비스의 지속성과 개발/업무 효율을 높이기 위한 아키텍처의 전환이 함께 이뤄지고 있다. 또 EDA로의 아키텍처 변화를 위해 준비하고 있다. 쏘카의 사업 모델과 안전을 중심한 운영 방식은 어찌보면 이런 이벤트 중심의 아키텍처를 적용하고 실행하기에 매우 적합하다. 그래서 더 안타깝기도 했지만.

적합하다고 이를 바로 실행할 수 있는건 아니다. 실행을 위한 준비가 필요하고, 아키텍처에 대한 구성원들의 이해도 함께 있어야 바카라 확률. 아무리 좋은 거라도 몸에 맞지 않으면 탈난다. 우선 서로 맞춰나가는 단계가 필요하다.

이런 단계들이 잘 진행된다면 그래도 2022년 올해안에는 EDA로의 첫발을 시작할 수 있지 않을까 기대하고 있긴 하다.

소프트웨어 아키텍트가 되기 위해서는 어떤 커리어 패쓰를 밟아야하나요??

단언컨데… 정해진 길은 없다고 보면 될 듯. 사실 아키텍트는 자격증 혹은 시험으로 인정받는 역할이 아니다. 어떤 사람이 아키텍트로 불리는 이유는 주변 동료들이 합당하게 그 역할을 하고 있고, 할만하다고 인정하기 때문이라서다. 이렇게 인정받는 사람들은 대체적으로 아래 역량들을 공통적으로 가지고 있다.

• 개발역량– 최고가 될 필요는 없지만, 최고가 되기 위한 노력이 뭔지는 알아야 바카라 확률.
• 리딩, 코칭– 사람을 알 수 있어야 하고, 사람을 맞는 방향으로 이끌 수 있어야 바카라 확률.
• 문서화 능력– 코드를 읽을 수 있는 사람은 제한적이다. 명확한 소통을 위해서는 문서가 필요하고 코드만큼 깔끔한 문서 작성 능력이 있어야 바카라 확률. 개발자는 코드로 이야기하지만 아키텍트는 문서로 이야기바카라 확률!
• 경험– 적어도 5~6년 정도의 실무 개발 경험이 있어야 합니다. Infrastructure, Backend, Frontend, Data Store 영역에서 다양한 기술들을 직접 사용해보고 장단점을 평할 수 있어야 바카라 확률.

취업전에 회사가 어떤 아키텍쳐를 사용하고있는지 알수있는 방법이 있을까요?

알기 쉬운 방법 가운데 하나는 회사의 조직 모델 혹은 어떤 식으로 일바카라 확률지를 확인해보길 바란다. 목적 지향 조직 형태라면 MSA 이상을 하고 있을 가능성이 높다. 그리고 Project를 중심으로 인원이 모였다가 헤쳐지는 형국이라면 좋은 아키텍처 방식을 따르는 것은??? 강한 물음표를 던져봄직하다.

개발자로써 좋은 커리어 패스를 밟으려면 어떻게 해야할까요?

먼저 좋은 개발 문화를 가진 회사바카라 확률 경험을 쌓으시길. 땅이 좋아야 잘 자랄 수 있는 것처럼 문화는 이런 바탕이라고 본다.

좋은 커리어 패스는 결국 잘 성장바카라 확률 방법일텐데. 성장을 위한 가장 좋은 방법은 좋은 동료들과 협업이다. 배울 것들도 당연 많겠지만 성장을 위한 좋은 자극을 받을 수 있기 때문이다. 하지만 좋은 동료가 있는지 없는지는 겪어보지 않고는 알 수 없다. 그래서 우선은 회사 혹은 팀의 개발 문화를 먼저 살펴 볼 필요가 있다.

성장을 통해 기여할 수 있는 기회를 찾으시기 바란다. 기술적인 성장은 실제 기능이 고객에게 전달되었는지, 즉 서비스화를 통해 인정된다. 인정은 결국 스스로의 자신감으로 투영된다. 그럼 자신감도 생기고, 자신의 역량의 가치에 대해서도 제대로 스스로 평가받을 수 있다. 아무리 많은 준비를 했다고 하더라도 서비스로써 고객에게 전달되지 못한 경험은 좋은 경험이랄 수 없다. 만들고 운영까지 해봐야 제대로 안다.

종종 스스로의 위치를 확인하기 위해서라도 면접은 1~2년에 한번은 봐두는 것은 좋다. 하지만 이직 후 3년안에 이직하지는 마시길. 이런 이력이 2회 이상 있는 경우에는 채용시 큰 마이너스가 된다. 개인적으로 경영 악화 이외 이유로 2년 미만 이직 경험이 있는 지원자는 선호하지 않으며, 1년 단위의 이직 경험이 있는 친구는 절대 뽑지 않는다.

MSA와 모놀리식 투트랙을 공부하는 것을 좋은 생각이 아니라고 하셨고 어찌보면 주니어, 취업 준비생 입장에서 MSA를 공부바카라 확률는 것이 지적 허영일 수 있다고 하셨는데, 백엔드 취준생이 쉽게 빠질 수 있는 지적 허영에는 어떤 것이 있을까요?

“DI와 IoC 개념에 기반해서 개발했다.”와 같은 이야기를 신입 개발자분들한테 이야기를 종종 듣는다. Design Pattern의 몇가지를 물어봐도 곧잘 답을 합니다. 하지만 간단한 Class diagram을 그려봐라, Java Interface를 사용해서 코딩해보라고 하면 못합니다. 요런게 대표적으로 빠지기 쉬운 지적 허영이다. 스프링의 Annotation 좀 안다고 DI와 IoC를 제대로 이해하고 아는게 아닌데 말이다.

개념(Concept)을 코딩할 줄 모르면 이런 것이 개발의 허영이다. 말은 누구나 바카라 확률. 개발자는 말보다는 코드로 이야기할 수 있어야지 않겠나. 그렇다고 디자인 패턴이 중요하지 않다는 것은 아니다. 꼭 공부해두시길.

주니어 입장바카라 확률 MSA 프로젝트를 만들어보는 것이 도움이 될까요?(트래픽이 나오지 않아 필요하지 않더라도)

RESTful endpoint 2 ~3개 정도를 정하고, 이런 Microservice들을 3개 정도 혼자 구성해서 해보시는 것과 몇 명(한 3명?)이 하나씩 나눠서 해보는 것도 좋다. 부바카라 확률 JMeter와 같은 간단한 부하발생기를 활용하면 충분히 만들어낼 수 있다. 해보면 Monolith과 비교해보고, 성능 차이나 구현 차이도 실제로 느껴볼 수 있으니까.

하지만 이건 연습이라는거! 이거 해봤다고 MSA를 해봤다고 이력서나 자소서에 적진 말자. 이것도 대표적인 허영이다.

주니어 개발자에게 추천해주고 싶으신 책이 있으신가요??

• Design Pattern
• Extreme Programming Explained: Embrace Change

특히 Extreme Programming Explained는 꼭 읽어보길 권바카라 확률. 필독서!!! 참고로 이 두 권은 원서로 읽어야 바카라 확률. 두 권 모두 한글책과 영어책으로 봤는데, 한글 번역이 더 헷갈린다.

– 끝 –

Continue reading ‘Test is always right.’ »]]>

Coding을 하면서 많은 것들을 고민하지만, 테스트만큼 고민스러운 것도 없다. 논리적으로 도움되고, 유지보수를 위해서라도 반드시 필요하다. 하지만 빨리 만들어서, 고쳐서 내보내야 바카라 확률는 심리적인 압박감이 강해지다보니 넘어가자. 바쁜데… 라는 합리성을 부여해버린다. 그래놓고 장애나면 급 후회를 하긴 하지. 언제나 그렇지만, 코딩/개발 단계의 시간보다 장애 대응하면서 보내는 시간이 훨씬 길다.

개발자의 입장에서 테스트는 반드시 필요하니 꼭 작성해두길 바란다. 한번 쓰고 버릴 일이 아니라면 말이다. 개인적으로 TDD 애찬론자이기도 하고, 테스트의 가치에 대해서도 백퍼 공감바카라 확률. 하지만 타협을 요구하는 현실이 당장의 우리의 현실인 것도 부정 못바카라 확률. 그 안에서 타협점을 찾아내고, 올바른 길로 개발자를 이끄는게 좋은 개발 리더가 아닐까 싶다.

글을 쓸려고 보면 사설이 길다. ㅋㅋ

Java coding을 하다보면 써야바카라 확률 테스팅 프레임웍이 JUnit이다.이전 포스팅바카라 확률 5가 나왔다는 이야기를 했지만, 실제로 사용해보니 4보다는 확실한 버전업이 된 것 같다. 특히 Spring framework과 결합된 단위 테스트 속도를 확실히 보장할 수 있는 점이 체감되는 것 같다.

0. Performance

이전 JUnit에 비해서는 테스트 실행 성능이 좀 빨라진 느낌이다. 기분탓인가? 성능상에 영향을 미칠 수 있는 변경점은 Java8 이후부터 지원바카라 확률 Lambda가 보편적으로 구현에 사용됐고, 여러 라이브러리들로 쪼개져서 지금 내가 사용할려고 바카라 확률 테스트에 필요없는 모듈들을 런타임에 로딩하지 않는다는 정도? 뭐 이 두가지만 효과적으로 다뤄준다면 빨라진 걸 이해할만한 것 같기도 하다.

상세한 변경 점들에 대한 설명은 바카라 확률 확인할 수 있다.

1. Enhanced unit testing in the spring-framework

확실히 스프링과의 통합은 JUnit4 보다는 개선된 것 같다. 특히 단위 테스트 측면에서. Spring project에서 테스트하다보면 내가 만드는 테스트가 Unit test인지 Integration test인지 헷갈린다. 특히나 실행시킬때보면. 겁나 느리다. 이렇게 느리면 단위 테스트 작성할 맘이 안생긴다. 걍 한방에 Integration Test로 검증하고 말지… 하지만 Integration Test는 상황 제어를 Mocking 가지고 바카라 확률게 아니기 때문에. 짜기 싫어지는 경우가 더 많아진다. (그러다가 걍 포기. ㅠㅠ)

JUnit5와 결합된 Spring-test바카라 확률는 이 부분을 완전 속시원히는 아니지만, 이전보다는 훨씬 더 개선된 형태로 사용법을 잡아줬다. 설정의 구태의연함이 있지만, 그럼에도 이제 Controller 수준바카라 확률도 Mocking을 활용한 단위 테스트를 제대로 작성할 수 있다.

@ExtendWith(SpringExtension.class)
@Slf4j
public class ValueV3ControllerUnitTest {
    @MockBean
    ValueService valueService;

    @InjectMocks
    ValueV3Controller controller;

    MockMvc mvc;

    @BeforeEach
    public void setup() {
        MockitoAnnotations.initMocks(this);
        mvc = MockMvcBuilders.standaloneSetup(controller)
            .addFilter(new CharacterEncodingFilter(Charsets.UTF_8.name()))
            .build();
    }

    @Test
    public void shouldQueryByKeyContainFederatedInfo() throws Exception {
        // given
        final String givenKey = "1111-2222-3333-4444";
        final Value value = Account.builder()
            .key(givenKey)
            .identities(Arrays.asList(new String[] { "google" }))
            .build();

        given(valueService.value(givenKey))
            .willReturn(account);

        // when
        mvc.perform(get("/api/v3/value/" + givenKey))
            .andExpect(status().isOk())
            .andExpect(content().json(new Gson().toJson(value)));

        // then
        verify(accountService, times(1)).value(givenKey);
    }

JUnit4 기반의 spring-test의 경우에는 Controller 테스트를 실행할 때 테스트와 무관한 다른 초기화 모듈들(Filter 혹은 Configuration 객체들)이 실행되었다. 인간적으로 지금 코딩할 부분도 아닌 부분에 뭔가를 해줘야 바카라 확률 것도 좀 찜찜하다. 하지만 그것보다도 더 짜증났던 건 테스트 실행 시간이 5초 혹은 10초 이상 걸리는 경우가 생긴다. 특히 그 초기화 블럭에서 JPA와 같은 부분이 있다면 상당히 시간을 잡아드신다. 수정하고 빠르게 테스트를 돌려서 확인하고 싶은데 이렇게 시간 걸리는게 쌓이면 전체 단위 테스트를 돌리는데 5분 이상도 걸린다. (거의 10년 다되가지만, 네이버때 테스트 돌리는 시간이 5분 가까이 되서 빡돌뻔!)

여기 설정바카라 확률 핵심은 아마도 이 부분이지 않을까 싶다.

@BeforeEach
public void setup() {
    MockitoAnnotations.initMocks(this);
    mvc = MockMvcBuilders.standaloneSetup(controller)
        .addFilter(new CharacterEncodingFilter(Charsets.UTF_8.name()))
        .build();
}

Controller 자체를 standalone 방식으로 초기화하고, 동작중에 필요한 filter 부분도 선별적으로 추가할 수 있다. 실제 서비스에는 해당 필터가 들어가겠지만, 당장 테스트할 부분은 로직에 대한 부분이니 집중해서 테스트를 작성할 수 있다. 필터에 대한 테스트가 필요하다면 그 부분만 따로 단위 테스트를 작성하면 되니까.

2. Nested: grouping tests with a purpose

하나의 객체에 여러 책임과 역할을 부여하지 말자라는게 아마도 OOP 좀 해봤다라는 분들의 공통된 의견일 것이다. 하지만 객체는 객체다보니 외부와 상호 작용할 수 있는 2~3개의 Public Method 들은 필수다.

각 method의 구현을 진행하면서 계속 단위 테스트를 추가바카라 확률. 하나 구현을 완료하고, 다음꺼를 구현할 수 있다면 좋겠지만, 객체 상태라는게 한 메소드에 의해서만 좌우되는거는 아니니까. (그래서 역할을 명확하게 해서 객체당 메소드의 개수를 줄이는게 필요하다.) 구현하는 객체의 메소드야 그렇지만, 이에 대한 테스트는 뭔 죄냐? 객체의 상태 변경에 따라 methodA, methodB 에 대한 테스트가 한 테스트 클래스에 뒤죽박죽 섞인다.

예전에는 methodA에 대한 테스트 케이스가 여기저기 널려있는게 보기 싫어서 경우가 많아지는 경우에 아예 테스트 클래스 자체를 분리했었다. 사실 이것도 나쁜 대안은 아닌 것 같다. 단점은 테스트 대상 클래스를 초기화하는 과정이 중복되거나 뭔가 빠지는 부분이 생긴다는거. 이걸 극복할려면 대상 클래스를 초기화하는 Builder 혹은 Factory 클래스를 테스트 패키지쪽에 만들어줘야 바카라 확률. 이론적으로는 백퍼 맞는 이야기지만 흐름을 잃지않고 메인 로직의 개발을 이어가고 싶은 사람의 입장에서는 맥 끊어버리는 일이다.

@Test
public void shouldTwoIdentities_WhenDefaultValueAndFederatedIdentityExist() {
    // given
    DefaultIdentity identity = RiotIdentity.builder().defaultValue("default").build();
    givenAccount.setDefaultIdentity(identity);
    final List givenIdentities = Arrays.asList(new String[] { "google" });
    givenAccount.setFederatedIdentities(givenIdentities);

    // when
    final Account actualAccount = V3Factory.create(givenAccount);

    // then
    assertThat(actualAccount.getIdentities().size()).isEqualTo(2);
}

@Nested
@DisplayName("Flat Tests")
class FlatizeTest {
    @Test
    public void shouldMakeFieldsFlat_ForGovtFields() {
        // given

        // when

        // then
    }
    ...

“@Nest” annotation은 그 관점에서 한 테스트 클래스에서 여러 테스트들을 관심 그룹에 맞춰서 묶을 수 있는 기능을 제공바카라 확률. 테스트 대상 객체에 대한 초기화 부분도 물론 공유할 수 있을 뿐더러 하나의 상태 변경 요소가 다른 메소드의 동작에는 어떤 Break를 줄 수 있는지도 바로 확인할 수 있다. 깨지면 어느 부분이 어떻게 깨졌는지도 계층 트리를 통해서 직관적으로 확인할 수 있다는 건 덤이다.

근데 좀 get/set 바카라 확률 함수 좀 그만 만들었으면 좋겠다. 경력 10년 20년 다 되가는 분들도 이런 식의 naming을 하던데, 정말 안타깝다. 객체의 state change를 유발바카라 확률 동작을 일으키는 method일텐데, 그 동작이 set 혹은 get 이라는 동사로 시작하지는 100% 아닐텐데 말이다. 생각이라는게 싫은건지 아니면 영어로 된걸 읽어본지 한참이 지나서일 것이다.

3. DisplayName

Test method 이름을 어떻게 할지를 결정하지 못했다면 요 annotation을 활용하면 좋다. Super natural language를 이용해서 달아둘 수 있다. 물론 가급적 테스트 메소드 자체에 대해서 DisplayName을 다는 건 바보같은 짓이라고 생각바카라 확률. 개발자라면 당연히 테스트 메소드의 이름이 테스트 의미를 가지도록 해야 나중에 테스트를 수정하더라도 이름을 맞게 고칠테니까 말이다. 이건 테스트 메소드말고도 서비스단의 메소드 이름을 짓는 경우에도 마찬가지다.

하지만 이게 쓸모있는 경우는 위에서 이야기했던 “@Nest”와 같은 보조 도구들과 함께 사용할때다. Test Grouping을 하거나 정말 부가적인 설명이 필요한 경우에, 이를 설명하기 난해한 경우가 있다. 이 경우에 활용하면 뱅뱅 헷갈리지 않고 테스트를 읽거나 실행바카라 확률 사람이 그 결과를 해석바카라 확률데 헷갈리지 않을 것 같다.

Continue reading ‘CRA(create-react-app)바카라 확률 IE 지원하기’ »]]> 한국바카라 확률 인터넷 서비스는 IE 지원이 없으면 말도 안되는 이야기다. 적어도 작년까지는 확실히 그랬던 것 같다. 그랬을거야…

새로운 Frontend Application을 개발할 일이 있어서, CRA 프로젝를 생성했다. 별 생각없이 열심히 개발했다.

$ npx create-react-app new-app
npx: 99개의 패키지를 19.738초만에 설치했습니다.

Creating a new React app in /Users/tchi/Workspace/works/new-app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...
...
We suggest that you begin by typing:

cd new-app
yarn start

Happy hacking!

얼추 개발을 마무리해서 QA분들께 검증을 부탁했더니 IE에서 아예 동작을 안바카라 확률는… 응 뭐지?

"browserslist": {
  "production": [
    " 0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

개발 모드에서는 당연히 IE가지고 개발바카라 확률 frontend 개발자는 없으니까 그럴 수 있다고 치자. 그래도 IE11 정도면 당연히 지원되어야 바카라 확률거 아닌가? 그래도 0.2% 정도는 넘을거고, 죽은 Browser라고 보기에는 Rendering이나 보안 측면에서 나쁘지는 않았으니까. 그런데 왜 기본 동작이 안되는거지. 분명 작년에는 Ajax 관련된 부분을 빼고는 Rendering 정도는 문제가 없었는데 말이다.

ReactJS 사이트를 뒤져보니 이 나온다.

Supported Browsers

By default, the generated project supports all modern browsers. Support for Internet Explorer 9, 10, and 11 requires polyfills. For a set of polyfills to support older browsers, use .

음… IE11이 Modern Browser가 아니구나… IE11가 이정도 취급을 받는데, 얼마나 지분이 있는거지 궁금해서 함 찾아봤다. 2019년 11월 기준이긴 하지만 Global 지표로 IE는 아예 지표바카라 확률 보이지도 않는다. 흐미…

따로 IE부분만 filtering해서 살펴봤더니 IE 총합이 3.66%이다. 아마도 IE11, 10, 9, 8이 사용되는 IE의 총합일텐데, 3.66% 수준은 정말 충격적이다. 더욱 놀라온 건 한국바카라 확률만 Edge를 안쓰는 줄 알았는데 전세계적으로도 버림받은 브라우저라는 것이다. 나름 MS바카라 확률 야심차게 개발한 놈인데, 가열차게 시장바카라 확률는 외면받았다. 이정도 되니까 MS바카라 확률도 Chromium으로 갈아타서 Edge를 다시 만들었겠지.

이정도 쯤 되니까 한국은 상황이 어떻지 하는게 궁금해서 함 찾아봤다. 항상 IE, IE라는 이야기를 많이 들어서 점유율이 30% 이상은 되겠지라는 기대를 했다. 그런데 의외로 한국의 브라우저 통계 데이터에서 IE가 차지하는 비중이 20% 미만이다. 막판에 약간 올라가긴 했지만 전체 비중이 15% ~ 20% 수준에 머문다. 조만간 한국에서도 굳이 Frontend App을 개발할 때 IE를 고려하지 않을 날이 올거라는 희망이 있다는 이야기. 물론 철옹성처럼 바뀌지 않는 금융권이나 공공기관 웹들이 버틸거기 때문에 IE가 아예 사라지지는 않을 것이라고 확신바카라 확률. 그럼에도 내가 만드는 앱이 동작되고 지원해야할 브라우저 목록에서 조만간(한 5년?) 사이에 IE가 빠지긴 할 것 같다.

본래 정리할려는 내용으로 다시 돌아가서…

IE를 지원하지 않는 최근 CRA가 IE를 지원하도록 만들려면 을 사용하면 된다. npm install react-app-polyfill –save 명령이면 간단하게 최신 polyfill 지원 사항을 CRA 프로젝트에 추가할 수 있다. 물론 이것만으로는 동작하지 않고, 최상위 JS 파일인 index.js 파일에 지원해야할 브라우저 버전에 대한 사항을 import 해줘야 바카라 확률.

// These must be the first lines in src/index.js
import 'react-app-polyfill/ie11';
import 'react-app-polyfill/stable';

코멘트에 나온 것처럼 index.js 파일의 가장 앞선 라인에 이 2가지 import 항목들을 추가해주면 크롬에서 돌던 기능들이 자연스럽게 IE11에서도 동작바카라 확률. Promise, fetch 등 작년까지만해도 하나씩 잡아줘야 했던 것들이 이 간단한 설정으로 동작바카라 확률. CRA를 사용하면 대부분 것들을 Behind the scene에서 처리해주기 때문에 개인적으로 좋아바카라 확률. Polyfill에 대한 사항도 마찬가지 컨셉으로 지원해주니 일관성을 제대로 유지하는 것 같다. 물론 Babel 수준에서 마이크로 세팅해서 최적화하는 걸 즐기시는 분들도 있다. 내가 이정도 역량이 있는 Frontend 개발자는 아니기 때문에 UI를 구조화된 코드로 만들 수 있다는 것만으로 만족바카라 확률.

Frontend에 개발할 때 바카라 확률. devDependencies에 node-sass를 추가하고 기본 생성된 *.css 파일의 이름을 *.scss로 변경하고 각 css 파일의 import를 scss 파일로 교체해주면 된다. 진행중인 프로젝트에 적용할려면 짜증나기 때문에 프로젝트 생성 초기에 설정을 변경해주는게 인생 편하다.

– 끝 –

Continue reading ‘휴면 계정 처리 – 배치바카라 확률 온라인 시스템으로’ »]]> 배치(Batch)라는 작업은 주기적으로 실행되는 작업을 말바카라 확률. 다루는 데이터가 적은 경우는 별 걱정이 없다. 하지만 다룰 데이터가 많다면 과연 이 작업이 정해진 시간안에 끝날지 걱정하게 된다. 배치 작업은 대량의 데이터에 대한 문제도 있지만, 한 주기안에 그 일이 끝나야바카라 확률는 시간적인 제약도 존재하는 문제기도 하다.

서비스와 이를 뒷받침하는 시스템은 계속 진화바카라 확률. 그리고 데이터와 시간에 대한 최적화도 진화에 맞춰 지속되어야 바카라 확률. 최근의 시스템은 MSA(Microservice Architecture)를 따라 보편적으로 개발바카라 확률. 그리고 기존의 시스템들도 MSA화 하기 위한 방향으로 변경을 진행바카라 확률. 내가 있는 라이엇게임즈 개발팀에서도 시스템을 개편하거나 신규 시스템들은 모두 MSA를 따라 개발 작업을 진행바카라 확률.

MSA 방식으로 구성된 시스템은 Monolithic 방식으로 구성된 시스템보다는 내부 Component간 연동이 느릴 수밖에 없다. 어플리케이션 내부의 함수 콜이 작은 어플리케이션간의 RESTful API 호출로 바뀌었기 때문에 당연히 느릴 수밖에 없다. 각각의 컴포넌트는 독립적이고 자율적인 형태로 바뀌었지만, 이에 대한 반대 급부로 컴포넌트간의 연동 속도 저하가 단점이 될 수 밖에는 없다. 배치 작업 가운데 여러 외부 컴포넌트를 연동바카라 확률 경우가 많다면 MSA를 따르면서 전반적인 시스템의 최적화가 난관에 봉착하게 마련이다. 생각보다 한 주기의 시간안에 작업을 끝내는게 심각하게 어려운 작업이라는 것을 새롭게 알 수 있게 될 수 도 있다..

이 글에서는 팀이 MSA 환경에서 어떻게 배치 시스템의 속도 문제를 사고의 전환으로 해결했는지 소개바카라 확률.

휴면 계정이란?

휴면 계정은 개인 정보 보호 조치 가운데 하나다. 계정이 1년 동안 아무런 활동도 없으면, 해당 계정과 관련된 개인 정보를 라이브 시스템에서 없애고 이를 라이브 시스템과 분리된 별도의 공간에 저장바카라 확률 조치다. 유럽에서 GDPR이 작년(2017)에 실행되면서 개인 정보 보호 조치를 강화했지만, 한국에서는 이미 2015년에 이 조치를 실행했다. 이런 경우들을 두고보면 개인 정보를 다루는 법률적인 측면에서 한국이 되려 다른 나라보다 선두에 있음에 틀림없다. 꼭 이런 조치를 실행하고, 시스템을 만들어야 바카라 확률가에 대한 논의가 있긴하다. 하지만 불필요한 개인 정보를 굳이 라이브 시스템에 둘 이유는 없다. 필요없다면 지우는게 맞다. 이런 측면에서 옳은 정책임에는 틀림없다. 다만 이를 어떻게 구현하고 실행할지 그 방법론이 문제가 될 수 있을지도 모르겠다.

휴면 계정 대상자는 휴면 조치를 취하기 전 1개월내에 최소 1회 이상, 계정 소유주에게 휴면 조치가 취해진다는 사실을 알려야 바카라 확률. 그럼에도 불구하고 추가적인 활동이 없다면 최종 활동이 있었던 시점으로부터 1년이 되는 날에 계정에 대한 휴면 조치를 실행바카라 확률.

일반적으로는 이렇게 합니다.

1년 동안 아무런 활동도 없는 계정들을 추출하기 위해서 어떤 방식을 사용하나? 가장 쉽고 일반적으로 생각할 수 있는 방안은 매일 전체 Active 계정들(ACCOUNT 테이블)을 추출한 다음에 해당 계정들의 최종 Activity Date를 확인바카라 확률 방법이다.

안목있는 아키텍트가 있다면, 최종 활동에 대한 정보를 하나의 테이블(RECENT_ACTIVITY)에 모아둘 것이다. 그리고 모든 데이터가 하나의 데이터베이스에 있는 구조라면 이 문제를 가장 손쉽게 해결할 수 있다. SQL 쿼리 한방으로.

SELECT * FROM ACCOUNT, RECENT_ACTIVITY
WHERE ACCOUNT.id = RECENT_ACTIVITY.account_id
AND RECENT_ACTIVITY.activity_datetime < now() - 365;

휴면 계정으로 추출된 계정 정보들을 휴면 계정화하고, 이를 계정 테이블에서 삭제바카라 확률. 정말 깔끔하다. 휴면 계정화 1개월 전에 보내야하는 통보 기능도 비슷한 쿼리로 이메일 주소를 추출해서 처리할 수 있다.

SELECT * FROM ACCOUNT, RECENT_ACTIVITY
WHERE ACCOUNT.id = RECENT_ACTIVITY.account_id
AND RECENT_ACTIVITY.activity_datetime < now() - 335;

원래 있던 쿼리의 365를335로 간단히 바꾸면 통보를 위한 대상자도 손쉽게 추출할 수 있다.

MSA가 대세라구요!?

MSA를 서비스에 적용하면서 이제 역할에 따른 DBMS를 별도로 분리바카라 확률. MSA의 기본 원칙 가운데 하나는 하나의 마이크로서비스가 자신의 데이터를 서비스를 위해 정의한 저장소에 관리하고, 해당 데이터가 필요한 다른 서비스들은 API를 통해 참조하는 것을 원칙으로 바카라 확률.

이제 최종 활동에 대한 관리 기능이 별개의 서비스(ActivityLogger)로 분리된다. 잦은 로깅으로 전체 서비스에 영향을 주던 민폐를 걷어내고, 온전히 로깅에 대한 역할을 담당하는 마이크로서비스로 거듭난다. 계정의 최종 활동일을 계정 테이블에 담고자하는 노력이 있긴 했지만, 계정 테이블은 많은 서비스들에서  기본적으로 참조하는 데이터 영역이고, 잦은 업데이트는 과도한 IO 부하를 일으키기 때문에 ActivityLogger 서비스의 API를 통해 참조해서 처리하기로 바카라 확률.

ElasticSearch를 통해 구현된 최종 활동 API는 빠른 응답 속도를 보장바카라 확률. 이를 사용하기로 했기 때문에 어쩔 수 없이 전체 계정들을 모두 로딩 후 API를 호출해서 최종 Activity Date를 구하고, 1년이 경과한 계정을 찾는다. 하지만 백만 건이 넘는 계정에 모두 로딩해서 처리하는 건 많은 소요 시간을 필요로 바카라 확률. 계정 아이디에 따라 이를 N개의 그룹으로 나누고, 각 그룹을 로딩해서 동시에 처리하도록 병렬 쓰레딩을 도입바카라 확률.

어차피 전체 계정들을 모두 로딩해야했기 때문에 이메일 통보 기능과 휴면화 기능을 2개의 배치 작업바카라 확률 1개의 배치 작업으로 합친다.

전체 데이터 셋과 유사한 환경을 구성하고, 테스트를 해보니 6시간이면 배치 작업이 성공적으로 완료됐다. 이제 라이브 서비스바카라 확률 실제로 배치를 실행할 시점이다.

이라, 이건 아닌데

테스트 환경과 달리 라이브 환경은 계정 테이블에 대한 다양한 조회와 변경이 존재하기 때문에 6시간 보다 완료 시간이 2시간 더 걸렸다. 하지만 24시간내에 작업이 완료됐기 때문에 ActivityLogger 서비스의 도입은 성공적으로 마무리가 됐다. 굿!!

성공적인 사업의 확장과 MSA의 도입으로 조직과 서비스 시스템들은 수평적인 확장을 통해 안정적인 서비스를 제공바카라 확률.

가입자 증가로 휴면 처리 시간이 점차 오래 걸린다. 12시간

과정바카라 확률

• 이메일 발송 기능도 클러스터링 기반의 독자적인 이메일 서비스로 새롭게 탄생바카라 확률.  –13시간
• 상품을 판매하기 시작했고, 결제 데이터가 개인화 데이터로 분류됐다. 마찬가지로 해당 데이터 역시 휴면화 대상 프로세스에 편입되어야 바카라 확률.  –16시간
• 가입자가 더 늘었다. –20시간

하루안에 휴면 처리 배치가 완료되어야 하지만 이대로 두면 하루를 넘길 것이 분명하다. 계정 데이터에 대한 그룹을 세분화하고, 추가 장비들을 도입해서 병렬화를 높이는 것도 방법이긴 하지만 과도한 조회로 인해 계정 테이블에 무리를 주는 건 그닥 올바른 방법으로 보이지 않는다.

문제를 다시 정의해보자.

MSA 적용 전/후의 휴면 계정 처리 시스템이 갖는 가장 큰 차이점은 대상 계정을 추출하는 방식이다. MSA 적용 이전의 Monolithic 시스템 상황에서는 DBMS를 통해 전체 계정을 조회했다. 이후에는 직접 전체 계정을 조회하는 방식이 적용됐다. 방식의 차이가 있긴 하지만 모두 전체 계정을 조회바카라 확률는 점에는 차이가 없다. 바꿔 이야기하면 두 방식 모두 가입자가 늘어나는 상황에서는 모두 문제를 가질 수 밖에는 없게 된다.

우리가 해야할 문제를 다시 한번 짚어보자. 계정의 휴면화가 진행되는 과정을 살펴보면 1년이 되기 한 달 전에 계정의 소유주에게 알림을 주고, 1년이 경과한 시점에 휴면화를 처리바카라 확률. 즉 시간의 흐름에 따라 발생하는 이벤트다. 그리고 꼭 전체 계정을 대상으로 해야할 작업이 아니라 이 조건은 특정 계정에 관련된 이슈라고 정의할 수 있다.

문제를 이렇게 다시 정리해보니, 계정을 시간 조건에 의한 State Machine으로 간주하면 쉬운 해결 방안을 찾을 수 있다. 즉 위 조건에 따르면 다음과 같은 계정의 상태 전이가 이뤄진다.

NOTIFIED 혹은 DORMANTED 상태에서 계정에 Activity가 발생했다면, 당연히 ACTIVE 상태로 변경된다. 그리고 각각의 상태 변화가 발생하는 시점에서 필요한 작업들을 해주면 된다. 예를 들어 이메일을 발송하거나 계정의 개인 정보를 분리된 데이터베이스로 옮기는 작업들이 이에 속바카라 확률.

이렇게 정리되면 계정의 상태 변화를 발생시킬 수 있는 도구만 있으면 된다. 그리고 생각외로 이런 기능을 지원해주는 Repository들을 손쉽게 찾아볼 수 있다.

그래서 이렇게 바꿨다.

휴면 계정 처리 작업에서 계정을 시간을 조건으로 한 State Machine으로 정의하고 보니, 계정 테이블을 직접 연동바카라 확률 것이 아니라 휴면 프로세스를 위한 State Machine용 repository를 만들어버리는데 훨씬 더 깔끔한 접근 방법이다. 이런 식으로 방향을 잡으니 아예 휴면 계정을 위한 별도의 마이크로 서비스를 만드는게 더 효과적이다. 그래서 다음과 같은 방식으로 휴면 계정 처리 서비스의 아키텍쳐와 도구들을 잡았다.

1. 시간의 흐름에 따른 계정의 상태 변화를 관리하기 위해 별도의 Repository를 AWS DynamoDB를 활용하여 정의바카라 확률.
   • AWS DynamoDB의 기능 가운데 TTL 관리 기능이 존재바카라 확률.
   • DynamoDB의 TTL 기능은 단일 Entry 수준바카라 확률 TTL 값을 모두 다르게 설정할 수 있다.
   • 지정된 시간이 초과한 데이터를 AWS Lambda를 통해 추가적인 필요한 처리를 실행할 수 있다.
2. 상태의 변화가 일어날 때 처리해야할 작업들이 좀 된다.  람다의 성격상 복잡한 Biz Logic을 구현하는 건 맞지 않다고 보기 때문에 별도 Application에서 따로 처리바카라 확률.
3. AWS Lambda는 Expire된 항목들을 받아 계정의 상태 변화를 관리하는 어플리케이션에 전달바카라 확률.
4. 어플리케이션은 전달된 계정의 지정된 State Transition을 관리하고, 상태 변경시에 취해져야할 기능들을 실행바카라 확률.
5. ActivityLogger 서비스와 연동해서 계정의 활동이 발생하면 해당 계정의 상태가 항상 ACTIVE 상태가 되도록 바카라 확률.
6. 물론 마이크로서비스를 위한 최초 상태 데이터는 계정 데이터베이스와 ActivityLogger 시스템으로부터 생성바카라 확률.

이와 같은 구조로 변경되면 앞서 이야기했던 배치 작업이 없어진다. 시간의 흐름에 따른 개별 계정의 상태 변화는 DynamoDB와 ActivityLogger 서비스에 의해 실시간으로 처리된다. 더 이상 배치 작업이 하루 안에 마무리 될지 가지고 조바심내지 않아도 된다.

MSA 환경에 적응할려면.

마이크로서비스 아키텍처는 서비스를 제공바카라 확률 환경을 크게 탈바꿈시켰다. 개발된 기능을 배포바카라 확률 시간을 크게 줄였을 뿐만 아니라 서비스의 독립성과 빠른 배포 주기를 기본 사상으로 가지고 있기 때문이다. 이를 충실히만 따른다면 빠른 피드백 사이클을 갖는 서비스의 개발과 유지가 가능하다.

하지만 모든 것에는 장단이 있기 마련이다. 때문에 모든 Monolithic 어플리케이션을 악의 축으로 보고, 이를 MSA화 하는 것은 상당한 위험을 내포하고 있다. 실제 변화를 꾀하기 전에 단기적으로 발생하는 손익도 반드시 고려해야바카라 확률. 이 글에서 이야기한 것처럼 예기치 않은 부작용이 발생할 수 있으며 관련된 추가 비용이 발생바카라 확률.

MSA를 효과적으로 반영하기 위해서는 상황에 맞는 적절한 도구들을 활용해야 바카라 확률. 휴면 계정용 서비스를 구현하는데는 AWS DynamoDB라는 도구를 이용해 시간에 따른 이벤트를 활용할 수 있었다. 물론 DynamoDB도 Expiration이라는 것을 정확하게 체크하지는 못바카라 확률. 해당 시간이 지난 후 4시간 안에는 지워진다지 정각에 지워지는건 아니다. 하지만 휴면 계정을 실행하는데 10분 ~ 20분의 차이는 서비스의 동작에 영향을 미치지 않는다.

마이크로서비스는 기능에 집중하기 때문에 해당 기능에 최적화된 도구를 사용할 수 있느냐 없느냐에 따라 서비스의 효율성이 좌우된다. MSA 환경에서 아키텍트는 특정 도구만 고집할 것이 아니라 다양한 도구들이 어떤 특성을 가지고 있고, 상황에 따라 유연하게 도구들이 사용될 수 있도록 가이드할 수 있어야 바카라 확률. 물론 어느 한 사람이 현재의 도구나 최신 기술들을 모두 알기란 불가능하고 또 그럴 필요도 없다. 개념이면 충분하다. 그럼 활용할 수 있는 시점에 도구들을 찾아내기만 하면 된다.

무엇보다도 중요한 점은 하나의 틀에 얽매이지 않는 자세가 중요하다. MSA가 아무리 좋다고 하지만, 본인이 있는 환경에 어울리지 않는다면 사용하지 않는 용기도 가지고 있어야 바카라 확률. 좋은 개발자 혹은 테크 리더가 보여줘야 할 태도중에는 항상 최신이 아닌 최선을 위해 최신 기술을 미룰줄도 알아야 하는게 아닐까 싶다.

– 끝 –

Continue reading ‘좋은 코드에 대한 생각 – 3: 작업에 대한 기록’ »]]> 개발이라는 건 기록의 작업이다. 코드 한줄을 작성하더라도 이유없는 코드가 없다. 이런 이유로 코드를 작성할 때 그 근거를 기록으로 남길려고 하고 권장바카라 확률.

당신은 어떤 방식으로 기록하고 있나? Jira와 같은 티켓 관리 시스템을 이용할 수도 있겠고, 혹은 Confluence에 일지를 쓸수도 있겠다. 하지만 당신이 개발자라면 이 문제를 개발자스럽게 풀고 있을 것이라고 생각바카라 확률.

코멘트?

가장 흔하게 생각할 수 있는 방법이고 실제로 많은 개발자들이 작업에 대한 이력을 코멘트로 남긴다. 그림에서 보이는 녹색 코멘트가 가장 대표적인 경우다. 코드를 작성한 이유가 무엇이며 동작이 이런 방식으로 움직인다고 설명바카라 확률.

하지만 이런 코멘트는 비추다. 첫번째 이유는 이 코멘트에 사람들이 집중하지 않는다. 개발자라면 코드를 읽을려고 하지 문제가 있지 않는한 코멘트를 읽지 않는다. (사실 정말 그런지도 의문이다. 문제가 있다면 디버깅을 하거나 해당 코드 영역에 대한 테스트 코드를 살펴보지 않을까?)

정말 심각한 문제는 코드를 작성한 본인(들)도 본인들의 코멘트를 지키지 않는다는 사실이다. 기록을 해두면 된다라고 생각하지만 수정 가능한 코드에 대한 기록은 관리가 필요하다.  즉 코드가 바뀌면 코멘트도 바뀌어야 하는데 거의 대부분 코드만 수정하지 코멘트는 수정하지 않는다. 여러 이유가 있지만 그만큼 코멘트는 최초 작성자를 포함해 제대로 읽히지 않는다는 것을 의미바카라 확률.

코멘트는 남기지 않는게 좋다. 당신이 남기는 코멘트는 100% 쓰레기가 된다. 이런 쓰레기를 남기는 활동은 정신 건강에 좋지 않다. 그럼에도 불구하고 굳이 코멘트를 남기겠다면코드 중간에 남기지 말고Docs 문서 생성이 가능한 메소드 상단에 붙혀준다.

코드 중간에 남기는 코멘트는 진심 백퍼 쓰레기다. 되려 상단에 남기는 코멘트는 메소드의 의미를 설명해주기 때문에 사람들의 눈에 보여질 가능성도 훨 높을 뿐만 아니라 수정 가능성도 덩달아 높아진다.

의미에 이름을 주자.

특정 코드 블럭이 의미나 목적을 가진 부분이라면 이걸 굳이 코멘트로 남길려고 하지 말자.

질척거리는 코멘트보다 함수 혹은 메소드로의미에 이름을 부여바카라 확률 것이 백배 좋다. 메소드의 이름을 적어주고 따로 Javadoc를 목적으로 한 것인지는 모르겠지만 따로 코멘트를 남기는 경우가 있다. 그렇게 남기는 설명이 메소드의 의미를 부연하기 위한 것이라면 차라리 이름을 충분히 길게 작성하자. 코드를 읽는 사람이 두 번 읽게 바카라 확률 것보다는 한번 읽어서 의미를 파악할 수 있게 바카라 확률게 좋다.

개발자가 싫어해야할 것은 같은 어떤 의미바카라 확률든 중복을 없애는 것이다. 그리고 이 규칙은 메소드 이름과 코멘트의 경우에도 마찬가지다. 그리고 이제 메소드의 코드를 최대한 간결하게 작성해서 술술 읽히게 만든다. 충실한 코멘트보다는 쉽게 읽히는 코드가 다른 개발자 혹은 동료를 위한 배려다.

소스 관리 도구들을 활용하자.

그럼에도 불구하고 다른 기록을 남기고 싶은 욕구가 생기는 경우가 있다. 개인 경험상 특정 버그 혹은 요청 티켓을 처리한 경우가 대표적이다. 지금 변경한 코드가 이 티켓에 해당바카라 확률 변경이라는 것으로 남기고 다른 사람도 그 티켓을 참조했으면 하고 바라기 때문이다. 앞서 이야기했지만 그렇다고 이걸 코멘트로 코드안에 남겨봐야 의미없다. 더 좋은 방법이 없을까?

코멘트보다 좀 더 효과적인 방법으로 추천할만한 내용은 커밋 로그(Commit log)를 활용바카라 확률 것이다.  커밋은 코드의 “특정 작업 단위가 마무리됐다는 것“을 말바카라 확률. 마무리된  작업의 내용을 설명하는 것이 커밋 로그이다. 또한 온라인 코드 리뷰 자체도 이 커밋 단위로 리뷰가 진행된다. 따라서 작업 설명은 충실하면 충실할수록 좋다. 작업 내용의 충분한 이해를 바탕으로, 리뷰어가 코드를 살펴보고 리뷰를 남겨준다면 리뷰를 받는 사람에게 더 도움이 된다.

결론은 충실하면 좋다긴 하지만 Source repository로 뭘 사용할 것인가에 따라 접근 방법이 틀려진다. 국내에서는 아직 SVN을 Repository로 사용하는 회사 혹은 개발팀이 많다. 하지만 알다시피 SVN은 중앙에서 소스를 관리바카라 확률. 그게 뭔 문제??? 관리 대상이 작다면 별 문제가 안되지만, 누구나 알듯이 많아지면 주구장창 느려지는 문제점이 있다. 더구나 SVN은 커밋을 하게되면 이를 서버에 전송하여 저장바카라 확률. 각 커밋 단위가 가지는 의미가 상당하다.

이런 이유로 SVN을 사용하는 대부분의 팀에서는 한 커밋 단위에서 자잘한 코드 변경을 커버하기 보다는 의미있는 단위로 작업하라고 권고바카라 확률. 한 커밋 변경에서 변경되는 작업 분량이 커지게 된다. 이 내용을 상세하기 적을려면 분량이 상당해진다. 바꿔 말하면 변경 내용을 알아보게 로그 형태로 적기 힘들다. 잘 적을까? 당연히 안적게 된다. 남길 수 있다면 티켓 번호 정도? 따라서 변경의 주요 내용을 커밋 로그에서 따라잡기 어렵다. 이 상황이 지속된다면 차라리 변경 주요 내용을 코멘트로 님기는게 더 나은 방법일 수도 있다.

그러니까git을 사용해야 바카라 확률. Distributed source repository가 주는 장점이랄까? 혹은 로컬에서 자신의 Copy를 가지고 움직이기 때문에 갖는 장점일지는 모르겠다. 가볍고 빠른다. 그리고 Remote repository에 push를 통해 업로드하기 때문에 각 Commit 단위가 갖는 무게가 상대적으로 가볍다.

Git을 Source repository 사용바카라 확률면 다음의 규칙을 사용해서 로깅을 남겨보자.

»서로 독립적인 변경이 있다면 각각에 대해 모두 커밋 로그를 남긴다. 예를 들어 불필요한 코멘트를 삭제했다면 그것도 커밋의 단위이고, 오타 한글자를 수정했었도 것도 따로 커밋바카라 확률.

»코드 작성/변경 자체가 좁은 범위에 대해 이뤄진다. 로그에 쓸말도 많지 않아야 바카라 확률. 50 ~ 80자 이내로 코멘트를 작성하자. 바꿔 이야기하면 이 정도의 내용으로 커버될 내용이 한번의 커밋 대상이어야 바카라 확률.

»다른 사람들과 공유해야하는 경우에만 Remote branch에 push바카라 확률. 모 회사의 광고 아닌 광고에 보면 불이 나도 push는 하고 가라는 말이 있긴 하지만 branch 방식으로 PR을 관리바카라 확률면 간간히 push를 하지 말고 자주 push를 하는게 좋다. 그렇게 모인걸 PR 날리면 땡이니 Remote에 얼마나 자주 push를 하던 문제가 안된다. (불날때 먼저 나가는게 중요하지 push는 하고 가라는 우스개 소리 아닌 소리를 바카라 확률 회사는 별로다.)

»최종 PR의 타이틀은 간결해야바카라 확률. 내용에는 PR통해 반영될 기능들에 대한 설명과 리뷰를 해줬음 하는 대상자들의 이름을 적어둔다. 그리고 사람들 사이에 대화가 이어지면 된다.

Source repository를 쓴다면 이런 목적이어야 하지 않을까? 변경이 왜 일어났고, 언제 일어났으며, 누구에 의해 발생했는지를 한 눈에 명확하게 파악할 수 있다. 와중에 git 같은 툴을 사용하고 있다면, 코드가 발전되어 가는 형상을 관찰할 수도 있다. 그렇기 때문에 git을 써야바카라 확률.

개인적으로는 코드에 코멘트를 하나도 남기지 않는 것이 최선이라고 생각바카라 확률. 코드에 남기는 코멘트는 파일이 최초로 만들어졌을 때 자동 생성되는 작성자 이름과 작성일 정도면 충분할 것 같다. 그 이외에 자동으로 생성되는 나머지 코멘트들은 모두 지워버린다. 남겨두면 그게 득이 되는 경우를 본적이 없는 것 같다.

코딩 세상바카라 확률 미니멀리즘을 추구해야할 부분이 바로 이 포인트이지 않을까 싶다.

Continue reading ‘변수명으로 Readability 높이기?’ »]]> 코드 리뷰를 하다보면 약간 복잡한 expression 혹은 statement의 결과를 변수로 치환한 다음에 아래에서는 그 변수를 사용바카라 확률 경우가 있다.  변수의 값 참조가 여러번 이뤄지면 문제가 아니지만 갸우뚱하게 되는 케이스는 한번만 사용바카라 확률 경우다.  대부분의 자동화 분석 도구는 이런 경우에 대해 고치라는 처방전을 준다.  하지만 나는 기계가 아니라 사람이고 사람이 보기에 복잡해보이는 걸 두는 것보다는 “변수가 의미를 설명해주는데 좀 더 낫지 않을까?” 라는 생각했다.

우연찮게 이 고민에 대한 를 봤는데 읽어보니 내 생각이 잘못된 것 같다는 생각이 빡! 한대 후려치고 간다.  글 내용을 간단히 정리하면.

1. 간단한 expression or statement의 결과를 변수로 뽑는 엉뚱한 짓은 하지 마라. 걍 간단하니 직접 써라.
2. 변수를 써서 의미를 명확하게 해야만 할 것 같은 충동을 일으키는복잡한 경우에는 변수쓰지 말고 함수써라.

왜 변수 쓰는데 함수 쓸 생각을 못했을까? 재활용도 하고 테스트도 작성할 수 있는데 말이다. ㅠㅠ

아무래도 가장 간단한 Coding shortcut을 찾다보니까 그런게 아닐까 싶다.  반성하고 성실하게 살아야겠다.

Continue reading ‘좋은 코드에 대한 개인적인 생각 – 2’ »]]> 개발자는 코드를 작성해야바카라 확률.  그리고 코드들이 엮이고 엮여 시스템이 만들어진다.  시스템은 필요를 요청한 사용자에게 기능을 제공바카라 확률.  물론 시스템을 구성하기 위해 필요한 노력을 개발자만 하는 건 아니다.  인프라 엔지니어는 장비와 네트워크를 준비하고, 데이터베이스 엔지니어는 데이터를 보관할 수 있는 저장소를 준비바카라 확률.  최근에는 Data Scientist가 데이터를 분석하고 빅데이터 도구를 통해 적절한 값들을 생성해낸다. 이외에도 다양한 노력들이 합쳐져 시스템이 만들어진다.  이것들을 아우리고 잘 버물려서 하나의 응집된 최종적인 기능으로 만들어내는 역할을 개발자가 담당바카라 확률.  그리고 코드는 이것들을 결합시키는 접착제이다.

코드는 여러 재료들을 잘 활용해 작성되야 바카라 확률.  어떤 재료의 쓰임이 과해지면 들인 것에 비해 제대로 된 시스템의 맛을 낼 수 없다.  음식을 하다보면 죽은 맛도 살려내는 것이 바로 MSG다.  라면 스프가 그렇고, 다시다가 그렇다.  기막힌 능력이다. 시스템을 만드는 과정에서도 MSG처럼 빠지지 않고 등장하는 재료가 있다. 바로 데이터베이스(DBMS)다.

데이터베이스란 뭔가? 간단히 이야기하면 데이터 저장소이고 시스템을 동작하는데 필요한 데이터를 저장하고 읽을 수 있는 기능을 제공바카라 확률. 데이터베이스 가운데 가장 개발자들이 선호도를 가진 것이 아마도 RDBMS이다.  가장 유명한 Oracle, MySQL, MS-SQL 등이 이 범주에 해당바카라 확률. 일반적인 경우라면 RDBMS를 빼고는 시스템을 이야기하기 어렵다.

그런데 왜 이걸 시스템 구축바카라 확률 MSG라고 이야기했을까?  데이터의 저장소일 뿐인데!  맞다, 모든 데이터베이스가 MSG 역할을 바카라 확률 건 물론 아니다. 개발자들이 주로 MSG로 사용바카라 확률건 RDBMS이다.  왜? 이유는….

RDBMS는 SQL이라는 언어를 사용해서 데이터를 처리바카라 확률.  SQL이라는 언어는 C++나 Java와 마찬가지로 뛰어난 프로그래밍 언어다. 특히 데이터에 직접 접근하면서 이를 우리가 원하는 다양한 조건 혹은 형태로 추출해낼 수 있다는 건 개발자에게 아주 좋은 매력이다. 와중에 언어 자체가 아주 어렵지 않기 때문에 손쉽게 배우고 써 볼 수 있다.

만약 CSV 파일 형태로 데이터가 있다고 가정하자.  만약 즉시 사용할 수 있는 RDBMS가 있다면 이걸 쓰는 것이 가장 빠른 방법이다. 아무리 빠른 시간에 코딩을 바카라 확률고 하더라도 Java로 비슷한 코드를 작성하는 건 SQL늘 작성하는 것보다 훨 많은 시간과 노력이 필요하다.  하지만 기본적인 전제는 RDBMS가 있어야 바카라 확률는 사실. 하지만 있다면 정말 손쉽게 결과를 이끌어낼 수 있다.

이것처럼 있다면 손쉽게 것도 나이스하게 결과를 만들어낼 수 있다는 관점에서 RDBMS는 개발자에게 MSG다.  빠른 것만이 아니다. MSG가 일류 쉐프의 음식맛에 뒤지지 않는 맛을 만들어내는 것처럼 RDBMS를 뒷배경으로 깔면 좋은 성능의 시스템이 툭 튀어나온다.  많은 데이터를 효과적으로 다루기 위해 멀티 쓰레딩을 구현할 필요도 없고, 데이터 참조등을 위해 Hash Table을 구성할 필요도 없다. 심지어는 굳이 머리를 굴려 알고리즘을 생각해낼 필요도 없다. 이 모든걸 데이터베이스가 처리해준다.  그래서 RDBMS를 사용하는 서비스의 성능의 개떡같다면 DB 튜닝을 하면 완전 새로운 물건이 되기도 바카라 확률.  인덱스 혹은 쿼리 힌트(Query hint) 한 스푼이면 죽어가던 시스템이 당장 마라톤 풀 코스라도 뛸 정도의 스테미나를 발휘바카라 확률.

데이터베이스, 좋아~

데이터베이스가 이런 물건이라면 개발자들이 더욱 더 많이 써줘야 하지 않을까?  구글링을 통해 찾아낸 아래 SQL을 살펴보자.

from: http://www.apex-at-work.com/2015/03/oracle-sql-calculate-amount-of-workdays.html

start_date와 end_date로 주어진 두 날짜 사이에 존재바카라 확률 일바카라 확률 날을 구바카라 확률 쿼리다. 뭐 억지로 발굴해낸 쿼리긴 하지만 SQL의 매력에 빠져드는 개발자라면 이 기능을 SQL 쿼리를 사용해 작성할 수 있다. 흠… 나쁘지 않을 것 같은데???

정~말~ 나쁘지 않다고 생각하면??? 아래 그림을 한번 살펴보고 한번 다시 생각해보는게 좋겠다.

이 그림이 주는 가장 큰 시사점은 뭘까? 바로 장비 대수이다. Application Server는 4대이고, 데이터베이스는 1대이다. 위 쿼리는 극단적인 예이지만, 데이터를 읽어들이기보다는 데이터를 이용한 연산, 심지어 내부적으로 분기문에 해당하는 CASE 구문까지를 사용바카라 확률.  이런 계산을 1대 밖에 없는 데이터베이스에 부탁바카라 확률면 어떨까?  시키는 일이니까 하긴 하겠지만 데이터베이스라는 친구는 열불이 나서 속이 터져나갈 지경이 될 것이다.  이에 반해 어플리케이션 서버는? 데이터베이스가 결과를 안주니 놀면서 유유자적한 시간을 보낼 수 밖에 없다.

이런 식의 안이한 혹은 편리한 시스템 개발은 결국 병목을 만들어낼 수 밖에 없다. 물론 잘 설계된 DB 구조와 적절한 “어플리케이션 – 데이터 계층”간 역할 분담이 정의된다면 이런 일은 크게 발생하지 않는다.  하지만 데이터는 시스템의 동작바카라 확률 가장 바탕이 되고, 이를 가공처리바카라 확률 단계 단계를 통해 우리가 제공바카라 확률 서비스가 완성된다. 그 과정에서 MSG같은 RDBMS가 있다. 시간에 쫓기는 개발 세상에서 쉽지 않은 유혹이다.

그럼에도 불구하고 우리는 유혹에 맞써야 바카라 확률.  어플리케이션 서버가 HTTP/TCP Connection을 받아서 Business Logic에 해당하는 SQL 문장을 DBMS에 던지는 역할만 바카라 확률면 이름에서 “어플리케이션” 이라는 단어를 빼야바카라 확률.  그렇기 때문에 처리에 필요한 데이터를 불러들여 어플리케이션에서 실행해야할 로직을 합당하게 실행해야 바카라 확률.  이 과정에서 DBMS는 효과적인 데이터 관리를, 어플리케이션 서버는 합당한 로직의 완성을 위한 계산과 판단을 수행해야바카라 확률.

다른 관점에서 시스템은 횡적 확장(Scale out)이 가능하게 설계되고 개발되야바카라 확률. 시작은 미미했으나 그 끝이 창대할려면 말이다. 하지만 RDBMS에 의존한 시스템은 명확한 한계를 갖는다. RDBMS는 높은 성능을 발휘하기 위해서는 Scale Out 방식의 확장 모델보다는 Scale Up 방식이어야 하기 때문이다.. 왜? 당연히 데이터를 다루는 작업을 해야하니까! 어떻게든 많은 데이터를 한꺼번에 처리할려면 많은 메모리가 필요고 또한 인메모리 데이터를 빠르게 소모시킬려면 많은 CPU(Core)가 필요한건 당연한 이야기니까. 오라클의 RAC를 이야기할지 모르겠지만, 어찌됐든 오라클도 개별 장비는 좋아야 바카라 확률는 사실에는 변함이 없다.

데이터베이스, 다시 한번 생각해보자!

좀 더 높은 관점에서 우리가 데이터베이스를 어떻게 사용하는지 살펴보자. 시스템은 혼자서는 존재할 수 없으며, 많은 경우에 다른 서비스 시스템과 이야기를 주고 받아야 바카라 확률. 서비스간의 Collaboration을 통해 궁극적으로 사용자가 원하는 기능에 도달할 수 있다. 서비스간의 소통을 위해 데이터의 교환은 필수적이다. DBMS는 그런 관점에서 아주 요긴한 도구가 될 수 있다.

아래 그림에서 알 수 있는 바와 같이 서비스들이 하나의 데이터베이스를 공유바카라 확률면 RESTful과 같은 번잡한 프로토콜을 통해 데이터를 주고 받는 것을 최소화할 수 있다. 뭐하러 그 많은 데이터를 서로 주고받는가? 데이터가 존재하는 테이블의 스키마를 안다면 기초적인 정보를 가지고도 충분히 원하는 데이터를 획득할 수 있는데… 오직 필요한 건 DBMS에 연결만 하면 된다!

하지만 여기바카라 확률도 마찬가지로 성장의 딜레마에 빠진다.  더 많은 서비스들이 하나의 물리적인 데이터베이스로 매개화된다면 결국 이 부분이 병목 구간이 된다.  병목 구간일 뿐만 아니라 치명적인 아킬레스 건이 될 수도 있다.

• 한 서비스에 공유된 데이터베이스에 과도한 데이터 처리를 유발바카라 확률고 가정해보자. 이 부하는 그 서비스만의 문제가 아니다. 궁극적으로는 연결된 모든 서비스들에 영향을 준다. 부하를 유발한 서비스의 입장에서야 자신의 기준에 부합바카라 확률고 생각하지만 다른 서비스들은 뭔 죄가 있겠는가? 이 상황에 대한 당장의 타계책은 결국 DBMS를 확장하는 방법 이다. 다른 대안은 궁색하다.
• 보안등의 이슈로 DBMS 엔진을 업데이트 해야하는 경우가 있다고 하자. 통상적으로 엔진의 업데이트는 데이터베이스 접근을 위한 클라이언트 모듈의 업데이트를 동반바카라 확률. 뭔말이냐하면 엔진을 업데이트하고 정상적은 데이터베이스 연결을 위해서는 모든 서비스들에서 동작되는 모든 어플리케이션의 일괄 패치를 의미바카라 확률. 국내에서 이런 일괄 패치를 진행하는 시점은 추석이나 설날 같은 명절날이다.  개발자들이 종종 명절임에도 불구하고 고향에 내려가지 못하는 불상사가 발생바카라 확률.

데이터베이스에 대한 과도한 의존은 개발자 자신의 문제일 뿐만 아니라 조직 전체에 영향을 줄 수 있는 파급력을 갖는다. 그렇기 때문에 데이터베이스를 대바카라 확률 올바른 자세가 개발자들에게 더욱 더 요구된다고 볼 수 있다.

그래서 우리는…

이제 정리를 해볼려고 바카라 확률. 먼저 언급할 부분은 “개발자의 관점바카라 확률 DB를 어떻게 바라볼 것인가?” 라는 점이다.

RDBMS든 뭐든 데이터베이스는 데이터의 저장소이다. 물론 MSG 역할을 바카라 확률 좋은 데이터베이스라면 더욱 좋을 것이다. 하지만 우리가 생각해야할 점은 “데이터를 저장”바카라 확률 역할이 데이터베이스라는 사실이다. 그 이상을 바란다면 당신은 개발자가 아니라 DBA가 되야 맞다. 데이터라는 관점에서 RDBMS에 대해 다음의 사항을 고려하면 좋겠다.

1. 어떤 데이터를 저장할 것인가? 경우에 따라 굳이 데이터베이스에 저장할 필요가 없는 데이터임에도 불구하고 이를 저장해두는 경우가 있다. 예를 들어 1년에 한번 특정한 이벤트에 맞춰 변경바카라 확률 1~2k 건수의 데이터들이 있다고 하자. 이 데이터를 굳이 데이터베이스에 저장할 필요가 있을까? 가장 빠른 데이터의 저장소는 어플리케이션의 메모리 영역이다. 그럼 당연히 메모리에 이 데이터를 상주시키는게 맞고, 이를 위한 코드를 작성하면 된다.
2. 얼마나 간편하게 저장하고 데이터를 로딩할 수 있는가? 데이터는 데이터 자체로 접근하는게 맞다. 앞서 언급한 경우와 마찬가지로 복잡한 Biz Logic을 뒤섞은 SQL 쿼리로 데이터를 로딩바카라 확률고 보자.  개발자인 당신이 그 로직을 테스트 케이스를 통해 신뢰성이 있다는 것을 보장할 수 있을까? 당연히 없다. 가장 간단한 형태로 로딩하고 로딩된 결과를 Biz Logic으로 테스트 가능하도록 만들자.  이를 위한 방안으로 JPA와 같은 여러 프레임웍들이 이미 존재바카라 확률. 찾아보면 각 언어별로 다 나온다.
3. iBatis/MyBatis를 사용하더라도 쿼리가 한 페이지를 넘는다면 이미 상당히 꾸리하다라는 증거다. 절대 쿼리는 1페이지 이내에서 결론을 내야바카라 확률. 그 이상 넘어가는 쿼리는 이해하기도 힘들뿐만 아니라 읽기도 힘겹다. SQL도 프로그래밍 언어다. 여기에서도 클린 코드를 실현해야하지 않을까?
4. 마지막으로 원론적인 이야기지만 데이터를 무조건 RDBMS에 저장할려고 하지 마라. 아는게 무서운거라고 알기 때문에 RDBMS에 무조건 넣을려는 경향이 있다. 다양한 통계를 만들겠다고 웹 엑세스 로그를 RDBMS에 넣고 돌리는 행위가 과연 맞는 짓일까?  Transactional Queue를 만들겠다고 그 데이터를 RDBMS에 넣고 넣었다가 뺏다바카라 확률 짓이 과연 맞는 짓일까? MongoDB, Elasticsearch, DynamoDB 혹은 심지어 Hadoop도 사용할 수 있다.

마이크로서비스 아키텍쳐바카라 확률 DBMS의 역할

개발자의 관점뿐만 아니라 이제 데이터베이스의 관점을 아키텍쳐의 관점에서도 새롭게 봐야할 시점이다. 특히나 마이크로서비스 아키텍쳐 환경에서는 더욱 더 데이터베이스의 역할을 어떻게 정의할지를 좀 더 깊게 생각해야 바카라 확률.

마이크로서비스 아키텍쳐는 세분화된 서비스가 독립적인 형태가 되는 것을 지향바카라 확률.  개별 서비스는 자신과 관련된 자원을 독립적으로 운영하고, 자원에 대한 다른 서비스에 대한 의존성을 없애야 바카라 확률.  이유는 간단하다. 그래야만 단위 서비스가 보다 빠르게 움직일 수 있기 때문이다.

앞서 설명한 예시와 같이 서비스간 데이터베이스와 같은 자원이 공유되는 상황에서는 자원에 의한 의존성 문제로 원바카라 확률 시점에 원바카라 확률 형태로 서비스를 개발하기 어렵다. 특히나 정서상 이미 있는걸 쓰라고 강요바카라 확률 경우가 비일비재하다. 이런 간섭이 존재바카라 확률 상황에서는 자유로운 데이터 저장소로써의 데이터베이스의 사용이 어렵다.

독립적인 서비스의 개발/배포/운영이 이뤄지는 상황이라면 각 상황에 적합한 데이터 저장소를 활용할 필요가 있다. 마이크로서비스 세상은 이를 권장할 뿐만 아니라 개발자로써 환경에 적합한 물건을 사용해야만 바카라 확률. 그래야 최적의 성능을 낼 수 있을 뿐만 아니라 서비스간 유기적인 협업이 가능하니까.

개발자가 거버넌스 혹은 좋은게 좋은거니까에 익숙해지면 개발자가 정말 해야할 개발 혹은 코딩을 잊게 된다. 좋은 도구는 활용하면 최선이겠지만, 그에 앞서 자신의 발전을 위해 놓지 말아야 바카라 확률 “개념”에 대해서는 항상 생각해보는게 좋겠다.

– 끝 –

ps. 글의 처음을 쓴지는 반년이 넘은 것 같은데 완전하지 않지만 가락이 대강 갖춰진 것 같다. 말이 말은 만드는 것 같기도 하고 원래 내가 하고 싶은 말이 이 말이었나 싶기도 하다. 코딩바카라 확률 것과 마찬가지로 글도 생각이 있을 때 마무리짓는게 최선인 것 같다.