□ 개발ㆍ프로그래밍
3. 최호성(널널한개발자) - 경력이 늘수록 CS이론이 중요해지는 이유
- 국비교육을 받을 때 강사를 잘 만나야 한다.
- SI업체를 나쁘다고만 생각하지 않는다.
- 사례 #1. 비전공 자바 개발자로 국비 수료와 SI업체를 거쳐 기술성이 중요한 유명한 업체로 이직하였으나 스스로 물경력(5년)이라 생각하고 방황하고 있다. 한 가지에 집중하지 않아 깊이가 없고 기획서와 UI만 기계적으로 개발해 웹 성능, 운영환경 등에 대한 기반 지식이 부족하다. 이론에 깊이가 없고 개발일정을 따라가기만 급급하며 주먹구구식이다. 웹 개발은 쉬워서 금방할 수 있다는 주변 인식이 있어 압박감을 느낀다. 이슈 처리 속도가 늦고 트러블 슈팅 시 원인을 찾기 쉽지 않다.
- 불이 나면 불을 끄는 것이 먼저다 그 후 원인을 찾아야 한다.
- 이제라도 CS 공부를 해야 한다.
- 사례 #2. 취업 준비기간 코딩테스트, CS, 각종 프레임워크 공부를 하다가 다시 CS로 돌아가는 등 갈피를 잡지 못하는 학습을 진행한다. 공부를 했지만 성과는 체감하기 어렵고 방향을 잡을 수 없다.
- 공부는 한번에 끝나지 않는다.
- 이해는 결과적인 현상이고 그것에 도달하기 위해서는 일정 수준의 암기가 필요하다.
- 경력이 5년 쌓인 시점에서 결혼과 자녀가 있다면 공부하는 것이 쉽지 않다.
- 기본기에 충실하면 새로운 프레임워크가 놀랍지 않고, 상대적으로 환경전환이 매우 수월하다. 그렇지 않다면 새로운 프레임워크를 다시 학습하고, 현상을 암기하고, 환경전환이 다소 어려워진다.
- 기본기는 컴퓨터 구조, 운영체제, 프로그래밍 언어, 자료구조, 알고리즘, 컴파일러이다.
- 데이터베이스는 운영체제와 대등한 수준의 기본기이다. 백엔드에서 가장 괴롭히는 공부는 데이터베이스이다. IT 시스템에서 근간이 되므로 이것이 흔들리면 프론트와는 비교가 되지 않는 후폭풍이 온다.
- 컴파일러를 한 번 만들어보기를 권하지만 시간이 부족하다.
- 커널의 구성요소는 유저 모드 애플리케이션이 접근하지 못하게 막아 놓았다. 대신 추상화된 인터페이스를 제공해 접근한다. 운영체제가 제공하는 모든 접근통제는 파일로 제한되고 그 파일에 대한 접근 허용이 권한으로 이어진다. 그러므로 파일 입출력이 중요하다. 소켓의 본질은 파일이므로 송수신과 입출력은 같다.
- 동기화와 교착상태가 데이터베이스와 만난다면 어려움에 빠진다. DBA에 의존하더라도 개발자가 어느 정도 할 줄 알아야 한다. 여기에서 캐시메모리 등 컴퓨터 구조에 대한 이해가 필요하다.
- CS공부를 하지 않으면 결국 개발자로 살아가는 동안 후회한다. 분야에 따른 차등을 인정하더라도 최소한의 지식은 필수다.
- 나는 어떤 이유로 개발자가 되려고 하는지 스스로에게 질문해야 한다.
- 앞으로 얼마나 오랫동안 개발자로 살아갈 것인가.
- 다양한 분야에 대해 알아가고 자기 분야에 대한 독보적인 전문성을 확보해야 한다.
- AI시대에 신입과 경력의 차이를 두지 않을 가능성이 있다. 인공지능을 두려워 하지말고 먼저 선점할 고민이 필요하다.
5. 유인동 - 멀티패러다임 프로그래밍 언어의 시대: 객체지향과 함수형을 섞어야 할 때!
- 함수형, 객체지향, 절차지향 패러다임을 제공하는 멀티패러다임 언어를 효율적으로 사용해야 한다.
6. 조영호 - 객체지향은 여전히 유용한가?
- 절차지향과 객체지향의 비교를 통하여 객체지향을 살펴본다.
- 절차지향은 데이터가 바뀔 때 결합도가 높은 외부 기능도 변경해야 하지만, 객체지향은 캡슐화를 통해 동일한 클래스 내 데이터와 기능을 하나로 합쳐 놓아 내부 로직만 변경하면 된다.
- 절차지향은 기능을 확장할 때 데이터와 함께 그 데이터와 결합도가 높은 외부 기능을 고려하는, 비용이 큰 리팩토링이 필요하다.
- 객체지향은 인터페이스를 통해 기존 코드를 수정하지 않고 비슷한 기능을 확장하는 국소적인 리팩토링을 한다. 인터페이스는 일관성이 있는 개발을 가능하게 한다.
- 인터페이스를 확장해야 하는 경우 다양한 구현 클래스도 모두 수정해야 하는 부담이 생긴다. 객체지향은 타입을 확장하는 경우 유리하지만, 새로운 기능을 타입에 추가할 때 전체적인 수정이 불가피하다.
- 절차지향은 새로운 기능을 추가하기가 쉽고 데이터 처리에 적합하다.
- 절차지향은 포맷 변경을 위한 데이터 변환, 데이터 중심, 데이터 노출, 기능 추가에 유리하다. 객체지향은 규칙에 기반한 상태 변경, 행동 중심, 데이터 캡슐화, 타입 확장에 유리하다.
- 레이어는 프리젠테이션, 서비스, 도메인, 퍼시스턴스로 구분한다.
- 도메인 레이어는 시스템의 상태 변경을 담당한다. 객체지향이 유리하다.
- 프리젠테이션 레이어는 데이터 변환을 담당한다. 절차지향이 유리하다.
- 서비스 레이어는 애플리케이션 플로우를 처리한다. 절차지향이 유리하다.
- 퍼시스턴스 레이어는 데이터 변환을 담당한다. 절차지향이 유리하다.
- 현재 어플리케이션을 만들 때 객체지향보다 절차지향을 더 많이 사용한다.
- 무엇이 더 좋은가. 아니다. 질문을 바꾸어야 한다. 객체지향은 언제 유용한가.
- 하나의 패러다임으로 프로그램을 구현할 수 없다. 우리는 다양한 기술을 다양한 컨텍스트에 맞게 가공하고 활용한다. 개인의 기본 가정과 현재 마주한 컨텍스트를 고려해야 한다. 코드의 목적과 변경의 방향성에 따라 언제 어떤 기술을 사용할지 결정해야 한다.
□ 프로덕트 디자인
□ 발표
7. 한기용(UpZen) - 개발자로 긴 커리어를 가지고 싶다면?
- 호기심이 없는 석사 공부는 잘못된 선택이다. 몸으로 부딪쳐 배우는 공부보다 효율적인 것은 없다.
- 빨린 판단하고 해보고 나하고 맞는지 판단하는 것이 좋다.
- 대기업이 내 커리어를 완성시켜주지 않는다. 본인 커리어는 본인이 만들어가고 그것을 찾아가는 것이 중요하다.
- 단기적으로 오르고 내림이 있지만 장기적으로 오르고 있으면 충분하다.
- 삼성을 다닐 때 조바심과 불안감이 앞서고, 기술지향적으로 살았으며 기술을 알아야 직성이 풀렸다. 안식년을 가지는 동안 스스로 내 인생을 살지 못하고 남의 인생을 산 것을 자각했다. 내가 원하는 일을 위해 대기업은 선택지에서 제외하였다. 대기업은 결정이 느리고 정치적일 수 있으므로 나의 발전속도도 느릴 수 있다.
- 나이가 많다는 생각은 하지 않는다. 생각보다 시간은 많다. 결정하는 시점의 논리는 단순하다. 후회를 최소화하고 해보지 않은 것을 해본다.
- 미국에서 한 할머니가 도서관 사서로 일하다가 65세에 은퇴를 했는데 그 뒤에도 그렇게 시간이 많은 줄 몰랐다는 이야기를 한다. 50대 중반이라면 너무나 젊은 나이이므로 대학을 졸업했다는 생각으로 살라고 조언한다. 그 할머니는 아이를 가지지 않은 것을 후회했다.
- 실패 또는 잘 되지 않은 것을 오히려 많이 배웠다고 생각하기를 바란다. 선택은 순서의 문제이다. 길게 보고 잘 될 것을 믿되, 하루하루 열심히 사는 것이 중요하다. 매일매일 내가 잘하고 있는지 자문하지 않기를 바란다. 꾸준히 하면 된다.
- 내가 원하는 것이 무엇인지 고민한다. 때로는 환경 탓을 하고 나에게 맞는 환경을 찾아간다.
- 무슨 일이든 호기심을 가지면 의사소통에 도움이 된다.
- 주변에 서포터를 많이 만들고 서포터가 된다.
- 이 시대의 전문성은 변화를 두려워 하지 않는 것이다.
- 감사하는 마음을 갖는다.
- 평정심과 꾸준함으로 커리어의 의미있는 발전, 다시말해 복리 활동을 이룬다.
- 불완전한 나를 있는 그대로 받아들이고 회고한다.
- 의사소통능력을 포함한 기본기가 중요하다.
- 동일한 문제를 반복하지 않는 코칭이 가능한 사람이 된다.
- 기술지향보다 결과지향을 추구한다. 맡은 일을 하면서 그에 필요한 기술을 익혀야 한다. 반짝이는 기술을 쫓지 않는다.
- 업무 완료 시간을 추정하는 연습이 필요하다. 모든 문제를 완벽히 풀겠다는 생각은 버려야 한다.
- 서비스 사고 대처 능력을 기른다.
□ PMㆍPO
□ 발표
□ 발표
5. 김지호(아임웹) - 혹시 당신은 데이터를 모르는 백엔드 개발자 인가요?
- 백엔드 엔지이너 & 데이터 엔지니어이다. 문제 해결을 위해 필요하다면 모든 것을 할 수 있다고 생각한다.
- 데이터를 관리하는 관점을 제시한다.
- 백엔드 엔지니어는 행을 잘 읽고 쓰는 것이 중요하다. 데이터 엔지니어는 열을 잘 읽고 쓰는 것이 중요하다. 열 단위 관점은 데이터 분석 비용의 감소, 그리고 확장성과 생산성의 증가를 이끈다.
- 행 단위로 처리할 때
json과 array의 처리가 간편하다. 그러나 수억 행의 json과 array를 모두 확인해야 하는 열 단위 분석 상황이 발생했을 때 많은 비용이 든다. 앞으로 이 데이터가 분석에 쓰일 것인지 고민할 필요가 있다.
- 열에 대한 코멘트가 없거나 문서화되지 않으면 새로운 상황에 새로운 열을 생성하여 일을 대응하므로 생산성을 떨어진다.
- 왜 이렇게 설계되었는지 맥락이 공유되어야 한다. 데이터 카탈로그를 활용한다.
- 대용량 트래픽 vs. 대용량 데이터
- 테이블 하나가 수십 억 행을 가진다. 분산처리가 필수적이다.
- DB는 데이터 관리의 전부가 아니다.
- RDBMS는 대용량 쿼리를 할 때 문제가 많이 발생한다. Live Production에 무거운 분석 쿼리를 적용하는 것은 부적절하다.
- 저장했다고 데이터가 아니다. 데이터 무결성을 고려해야 한다. 무결성은 유효성, 일관성, 정확성으로 판단한다.
- 유효성은 정의된 범위에서 데이터가 발생하는 것이다. 유료 서비스 A의 만료일 연장을 위한 여러가지 경로가 있었고, 만료일을 통해 활성 기간을 알아내는데 실패했다. 데이터를 기능적으로만 고려한 결과이다.
- 정상적인 결제를 통해 만료일 연장
- 프로모션 적용 또는 컴플레인 대응을 위해 만료일을 임의 연장
- 환불요청 등 운영이슈 처리를 위해 만료일 변경
- 특정 대상에 대해 Admin에서 연장
- 다수의 대상에 대해 엑셀 업로드를 통해 일괄 연장
- 유저 유형에 따른 결제 및 연장 로직이 상이
- 정확성은 데이터가 실제값을 정확하게 나타내는 것이다. 데이터가 필요한지 불필요한지 판단하기 어렵다. 탈퇴한 회원의 정보를 분석하고 싶어도 데이터가 없으면 분석이 어렵다. 그러니 데이터는 모두 저장한다.
- 일관성은 하나의 열에 하나의 맥락이 들어있는 것이다. 주문상태와 배송상태의 변경일을
Completed_at으로 통합하여 기록하면 혼란스럽다.
- 좋은 서비스를 만들기 위해 데이터에 대해 잘 알아야 한다.
□ 딥다이브
□ 클로징
