별개의 일...

영어 문법을 잘 알고 아주 긴 글을 쓸 수 있다고 그게 글을 잘쓰는건 아니듯이 프로그래밍을 잘 한다고 절대 좋은 프로그램이 나오지 않음.

수학 물리 전공한 애들은 대부분의 경우 수치를 계산하는 프로그래밍을 많이 하는데 도메인 자체가  지극히 단순해서 연산을 반복 적용하는경우가 많음. 입력으로 주어지는 데이터 자체가 아주 단순해서 프로그래밍으로 옮기기가 쉬움. 수학 이론을 컴터로 계산해서 답만 잘 나오면 땡인 경우가 많음.

하지만 현실 세계로 눈을 돌려보면 수학 물리학처럼 도메인이 단순하지가 않다.

직원만 해도 정규직, 비정규직, 알바, 특수 계약직 등 추상화 해야 할 대상이 불분명하고 그에 따른 회사의 복지, 급여 산정 등 업무 규칙을 시스템에 반영해서 구현하는건 단순히 프로그래밍의 문제가 아니라는거... 정규직원이 제품 구매시 추가로 15% 할인을 적용해준다...와 같은 것을 어떻게 코드로 녹여낼 것인지 등등..

프로그래밍 대회같은데 보면 참가자들이 제출한 코드가 올바른 답을 내기는 하지만 어디 갖다 쓰기에는 거의 불가능한 것들이 대부분임. 물론 시간 제약때문에 하드코딩을 해서 그렇겠지만 실제로 모든 문제를 매번 그런 식으로 해결하는 사람들이 의외로 많음.

아무리 구현 능력이 출중해도 같이 일 못함..

적절한 추상화, 도메인에 내재된 근본적인 문제점을 잘 잡아내서 모델링 하지 않고 일단 돌아가는대로 막 짜다보면 처음에는 개발 속도가 빨라서 관리자들이 좋아하지만 시간이 지나면서 버그를 고치고 기능을 추가하면서 점점 코드가 난잡해지고 나중에는 도저히 기능을 넣는 것도, 버그를 고치는 것도 힘든 경우가 생김.

그러면 그거 접고 신규로 다시 개발 들어감.

회사의 사활을 걸고..ㅎㅎㅎ


그래서 자료구조와 알고리즘, 소프트웨어공학을 배우는거임.

운영체제나 더이터베이스나 결국은 특정한 자료구조와 알고리즘의 집합임.

일례로 지금 보고 있는 기사와 유사한 기사를 추려내는 것이나, 관심 상품과 유사한 상품 추천같은건 논문 검색 시스템의 알고리즘을 그대로 사용하고 있음. 제품의 이름, 종류 등들 벡터로 나타내서 이와 유사한 벡터를 갖는 상품을 찾아냄. 정보검색 분야의 알고리즘들..

물론 요즘은 이런 구현체들이 오픈 소스나 제품으로 나와있으니 굳이 몰라도 가져다 쓰는데 지장이 없을 수도 있음. 그런 사람들은 딱 그정도만 할 수 밖에 없다는거...