Algorithm In Architecture #1 (Start)

소프트웨어 개발이라는 분야는 오래했다고 잘한다는 것이 보장되는 곳이 아닙니다.

끊임없이 Why 와 How 에 대해서 스스로 질문하고 공부해야 성장하는 분야인 것 같습니다.

 

1. 아키텍트 vs 개발자

 

요즘 들어서 "개발자"라는 직업이 아주 핫합니다.

그런데 IT시장에서 오래 일하신분들이 "개발자" 라는 호칭을 들었을 때 반응이 좀 다릅니다.

 

"언제까지 개발만 할거냐?" 라는 질문을 던지며 전체적인 그림을 그리는 아키텍트가 되어야 한다는 사람들이 많이 있습니다.

이런분들은 개발=코딩의 의미로 바라보는 것 같습니다.

 

그러나 "우리는 아키텍트라는 표현을 사용하지 않아. 전부 다 개발자이지" 라고 이야기하는 분들도 상당히 많습니다.

보통 이런회사의 개발자분들은 아키텍처, 설계, 개발, 테스트를 모두 합쳐서 개발로 인식하여 수행합니다.

 

비율을 정확히 따져보지는 않았지만 두 부류 모두 부르는 명칭만 다를 뿐이지 사실 해야하는 일은 비슷합니다.

 

고객과 시장의 요구사항을 만났을 때, 기술적 관점으로 그것을 재해석하여 소프트웨어로 구현해야 하는 것이 궁극적인 목표입니다.

 

 

- 아키텍처 그림만 PPT로 열심히 그리는 사람은 아키텍트가 아닙니다. 그림은 아무나 그릴 수 있습니다.

- 자기가 만드는 프로그램 하나의 개발에만 집중하는 사람은 좋은 개발자가 아닙니다.

   전체적인 구성요소와 관계를 파악하여 기능적/비기능적 요구사항을 파악하고 이에 따른 제약사항과 구현방안을 설계/개발 할 수있는 사람이 좋은 개발자입니다.

 

2. 기술 vs 기본

 

시장의 많은 개발자들끼리 만났을때 심심치 않게 벌어지는 논쟁입니다.

 

"Spring 3.0에서는 어떠했고, 4.0에와서는 어떤 것이 바뀌었으며 ..."

"그럴때는 Spring 의 PostProcessor를 사용해서 구현하고"

등등 시장에서 사용되는 최신기술들에 관심이 많은 분들입니다.

 

이런 분들의 특징은 여러가지 기술등을 효과적으로 활용하여 원하는 바를 빠르게 만들어냅니다.

이른바 "손이 빠릅니다".

 

"이렇게 하면 시간복잡도, 공간복잡도가 이렇게 되고.."
"O(N^2)을 O(NlogN)으로 줄일 수 있고..

"건별 Data가 몇 byte이니, 초당 건수를 고려하면 메모리를 bytes만큼 사용하고"

 

이런 분들은 뭔가 하나에 꽂히면 파고들어서 최적의 구현을 하는 것이 목표입니다.

계속 들여다보고 최적화 / 효율화를 반복합니다. 

그리고 "흐뭇해 하십니다"

 

결론부터 말씀드리면 둘 다 중요합니다!

 

오픈 소스의 홍수 속에서 너무나도 많은 "바퀴"들이 존재합니다. 바퀴를 다시 만들필요는 없습니다.

망치가 있는데 돌멩이로 못질을 할필요는 없죠.

그런데 핵심이 되는 원리는 비슷합니다.

 

- 내가 사용하는 모듈의 시간복잡도, 공간복잡도가 어떠한지

- 내부에서 어느부분이 동기/비동기 처리가 일어나는지 

- Input 이 100건일때와 100만건일때 속도차이는 어떠한지

 

이러한 내용을 파악하지 않고 바퀴를 가져다 만드는데만 집중하면 밸런스가 안맞습니다.

시스템이 작을때는 문제가 없지만 데이터가 늘어나고 사용자가 늘어날 수록 버티기가 힘들어집니다.

 

이름있는 Tech기업들이 개발자(소프트웨어 인력)을 채용할때 알고리즘 테스트를 하는 것은 다 이유가 있습니다.

새로운 기술이 나왔을때 빨리 습득하고, 논리적 문제해결을 바탕으로 접근하여 그 기술을 사용할줄 아는 사람이 필요합니다.

 

 

현장에서 오래 일하다보면 고객의 요구사항을 만족시키는게 급급하여 기본을 무시하는 사람들을 많이 봅니다.

"알고리즘 같은건 그냥 시간있을때나 공부하는거지"

"그게 뭐가 중요해. 내가 하고 있는 업무랑 연관 없는데"

시스템이 커지고 복잡해지면 반드시 문제가 생깁니다.

 

한편으로는 기술을 무시하는 사람도 많습니다.

"남에 만든거 가져다 쓰는게 뭐 대단하다고"

"내가 만들면 그거보다 잘 만드는데"

바퀴를 만드는 것도 중요하지만 자동차를 만드는 것도 중요합니다. 사용자가 없는 소프트웨어는 죽은 겁니다.

 

이번 카테고리에서는 이 두가지를 섞어서 글을 정리해보려고 합니다.

개발과 알고리즘은 떼려야 뗄 수 없는 관계임을 우리는 이미 알고 있습니다.

이러한 주제를 아키텍처 레벨로 확장시켜서 살펴보려고 합니다.

 

우리가 알고있는 자료구조와 알고리즘들이 아키텍처에서는 어떻게 적용되고 있는지를 자세히 공부한다면

위와 같은 논쟁도 많이 없어지지 않을까 하는 생각입니다.

 

 

ps)

3. Design Pattern & Refactoring

위의 주제와는 약간 다른 주제입니다.

급변하는 요구사항을 어떻게 하면 최소한의 비용으로 빠르고 정확하게 만족시킬 수 있을지에 대한 해결방안으로 보면됩니다.