기술 능력이 엔지니어에게 가장 중요한 항목이 아닌 이유

일반적으로 엔지니어라고 하면 테크 스킬이 가장 중요한 것이라고 생각을 한다. 물론 엔지니어가 되기 위해서는 기술적 지식이 당연히 필요하고 기술 숙련도에 중점을 둘 가능성이 매우 높다. 하지만 효과적으로 의사소통을 하는 능력은 간과되는 경향이 있다. 엔지니어에게 커뮤니케이션 기술이 필요한 이유는 무엇일까? 우리가 진행하는 과제들은 개인이 혼자서 해결할 수 있는 것이 매우 적다. 기술 지식을 가진 사람들로 구성된 사람들 혹은 팀 간의 협업이 필요하다. 어떤 과제를 하기 위해서는 기술 베이스의 사람도 있지만 기획, 비즈니스 등 다양한 배경을 가진 사람들이 모여서 협업을 하기에 의사소통을 잘하면 더 효율적으로 진...

더보기

모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까?

모놀리식과 마이크로서비스 아키텍처중 어떤 아키텍처를 선택해야 하는지에 대해서 요즘IT에 기고했다. 아래는 기고한 글 일부이다. 애플리케이션의 아키텍처 스타일(모놀리식 vs 마이크로서비스)에 대한 선택은 트렌드나 경쟁사의 특징을 따르기보다, 애플리케이션의 목표와 비즈니스 요구 사항에 따라 달라진다. (생략) 모놀리식 애플리케이션은 소프트웨어 개발을 위한 기본 접근 방식이다. 그렇다면 마이크로서비스가 대세가 된 현재 모놀리식 접근 방식을 버려야 할까? 만약 모놀리식 애플리케이션에서 마이크로서비스로 전환하면 어떤 이점이 있을까? 마이크로서비스로 애플리케이션을 만들면 비즈니스의 이점은 무엇일까? 이번 글에서는 모놀리...

더보기

좋은 팀 구성 및 개발 문화 조성의 중요성

GS리테일에 입사 후 팀빌딩과 개발 문화를 구축한 경험에 대해서 요즘IT 매거진에 기고했다. 본 글은 요즘IT 매거진에 기고한 글의 일부를 가져왔다. <출처: https://unsplash.com/photos/Zyx1bK9mqmA> 함께 할 동료가 모였으니 이제 실제 업무를 진행할 차례다. 개발팀은 잘 작동하는 소프트웨어를 구축하는 것부터 기술 변화의 빠른 속도를 따라가는 것과 같은 문제를 해결해야 하는 경우가 많다. 가장 좋은 방법의 하나는 매력적이고 창의적인 팀을 구성하는 것이다. 어떻게 매력적이고 창의적인 팀을 구성할 수 있을까? 답은 간단했다. “즐기게 놔두는 것이다.” (생략) ...

더보기

Moduler Monolithic 아키텍처

프로젝트를 준비하면서 아키텍처에 대한 고민이 많다. 마이크로서비스 아키텍처로 프로젝트를 하였지만, 현 상황에서는 마이크로서비스 아키텍처가 어울리지 않을 수 있다는 판단을 했고 이유는 아래와 같다. B2C라고 볼 순 있지만 사용자 수가 정해져 있다. 트래픽이 증가하는 시간이 정해져 있다. 리소스 비용을 절약해야 함 (비용 감축을 위해서 트래픽이 몰리는 시간대외에는 인스턴스를 축소할 계획 있음) 데이터베이스가 통합되어 있음 (미니서비스로 고려가 가능) 각 서비스마다 다른 기술을 사용하진 않을 것 같음 레거시가 존재하기에 리팩토링이 우선되어야 함 (이 부분이 가장 중요!) 또한, 아래 사항...

더보기

소프트웨어 아키텍트의 역할

처음 IT 분야에서 일을 시작했을 때 소프트웨어 설계자라는 직책이 나의 관심을 끌었었다. 소프트웨어 혹은 애플리케이션 아키텍트라는 이름이 아름답고 우아하게 보였다. 그리고 아키텍트가 되기로 마음먹었었다. 아키텍트가 되기 위해서는 코딩, 아키텍처, 패턴, 커뮤니케이션 스킬 등 다양한 주제를 깊이 있게 공부하고 경험해야 했다. 나에게 아키텍트가 된다는 것은 훌륭한 개발자가 되고 아키텍처에 대해서 최대한 아는 것을 의미했기 때문이다. 우리는 일반적으로 수석 개발자나 우수한 개발자가 자신은 아키텍트라고 말하는 것을 본다. “Role of the Software Architect”에서 Simon Brown은 소프트웨어...

더보기

애플리케이션 현대화로 가는 길

오늘은 왜 애플리케이션을 현대화 해야 하는지 얘기하려 한다. 오래된 기술 어느 회사나 오래된 기술로 만들어진 시스템을 가지고 있을 것이다. 이것과 관련해서 흔히들 “잘 작동하면 만지지 마세요.”라고 얘기한다. 변경 사항이 없을 경우에는 맞는 말이다. 잘 동작되고 있는데 굳이 변경할 필요는 없기 때문이다. 하지만, 문제가 발생하거나 변경을 해야 할 경우에는 어떻게 해야 할까? 오래된 기술을 알고 있는 사람을 고용하기는 매우 어려울 것이다. 10~20년전에 이 코드를 작성한 사람들은 아마 은퇴를 했을 것이고, 젊은 개발자들은 이 기술을 배우고 싶어하지 않을 것이다. 억지로 하라고 하면 이탈로 이어질 것이고, 좋은 개...

더보기

레거시 시스템 구조개선 고민

하나의 거대한 모놀리스로 되어 있는 오래된 시스템을 구조 개선을 하기 위해 분석중이다. 분석을 시작하기 전에는 마이크로서비스에 대한 언급이 많았다. 마이크로서비스는 훌륭한 방법이긴 하다. 모듈식이며 확장 가능하고 내결함성도 좋다. 이름만 들어도 익히 알고 있는 유명한 곳에서 이 모델을 사용하여 큰 성공을 거두었기에 마이크로서비스로 아키텍처를 잡는 것이 훌륭하게 보일 수 있다. 그러나 마이크로서비스로 성공한 대부분의 기업은 처음부터 마이크로서비스로 시작하진 않았다. 트위터나 에어비앤비 같은 경우는 마이크로서비스로 전환을 했지만, 현재 복잡성과 대면을 하고 있다. 마이크로서비스를 사용해서 성공한 회사도 최선의 방법...

더보기

기술 부채의 유형과 관리 방법

기술 부채란? 기술 부채는 Ward Cunningham이 1992년도에 만든 표현이다. 오늘날 기술 부채 및 코드 부채는 개발 팀이 애플리케이션을 개발 시 빠른 코드를 작성하는 것을 선택할 때 발생한다. (일정에 쫓겨서 개발) 신속한 코드 전달은 프로젝트 완료일을 맞추는데 도움이 되고 이에 대한 기술 부채를 감내한다고 했을 때, 비지니스 관점에서는 문제가 없어 보일 순 있지만, 향후 부정적인 결과를 초래할 수 도 있다. 기술 부채를 발생시키기로 결정했다면 부정적인 결과가 생기는걸 고려해야 한다. 기술 부채는 처리하기가 복잡하고 특정 지표와 연결되어 있지 않다. 기술 부채를 해결하는데 필요한 정확한 자원을 추정하는...

더보기