저는 종종 스스로를 '가짜'라고 생각하곤 합니다. 특히 가짜 개발자라는 생각을 자주 합니다. 지금까지의 성취가 운이고, 주위 사람들을 속이고 있다고 느끼는 거죠.

유퀴즈에 나온 빌리 아일리시의 인터뷰를 보며 마음을 다잡았습니다.

"재밌는 건요, 전부 갑자기 일어난 것처럼 보이지만 사실 그렇지 않다는 거예요."

"한순간의 점프라고 생각하는 사람들도 있겠지만, 제게는 서서히 진행된 것처럼 느껴졌어요."

"저는 모든 사이즈의 공연장에서 차근차근 공연을 해왔고, 지금에 도달하기까지 필요한 모든 일을 다 했어요."

"남들이 봤을 때 오? 어느 날 갑자기?! 그런데 그건 아니었던 얘기죠."

지금의 우리는 하루아침에 이루어진 것이 아닙니다. 매일 조금씩, 한 계단씩 올라왔기에 지금의 우리가 있는 것입니다. 누군가에겐 갑작스러워 보일지 몰라도, 각자는 그 과정을 잘 알고 있죠.

3년 전, 5년 전의 자신과 비교해 보세요. 눈에 띄는 변화는 없었을지 몰라도, 분명 성장해 왔습니다. 아직 개선할 점이 있다는 것은 우리가 계속 발전하고 있다는 증거일지 모릅니다.

우리는 '가짜'가 아닙니다. 매일 '진짜' 삶을 살아내는 중입니다.

저는 종종 스스로를 '가짜'라고 생각하곤 합니다. 특히 가짜 개발자라는 생각을 자주 합니다. 지금까지의 성취가 운이고, 주위 사람들을 속이고 있다고 느끼는 거죠. 유퀴즈에 나온 빌리 아일리시의 인터뷰를 보며 마음을 다잡았습니다. "재밌는 건요, 전부 갑자기 일어난 것처럼 보이지만 사실 그렇지 않다는 거예요." "한순간의 점프라고 생각하는 사람들도 있겠지만, 제게는 서서히 진행된 것처럼 느껴졌어요." "저는 모든 사이즈의 공연장에서 차근차근 공연을 해왔고, 지금에 도달하기까지 필요한 모든 일을 다 했어요." "남들이 봤을 때 오? 어느 날 갑자기?! 그런데 그건 아니었던 얘기죠." 지금의 우리는 하루아침에 이루어진 것이 아닙니다. 매일 조금씩, 한 계단씩 올라왔기에 지금의 우리가 있는 것입니다. 누군가에겐 갑작스러워 보일지 몰라도, 각자는 그 과정을 잘 알고 있죠. 3년 전, 5년 전의 자신과 비교해 보세요. 눈에 띄는 변화는 없었을지 몰라도, 분명 성장해 왔습니다. 아직 개선할 점이 있다는 것은 우리가 계속 발전하고 있다는 증거일지 모릅니다. 우리는 '가짜'가 아닙니다. 매일 '진짜' 삶을 살아내는 중입니다.

자신을 가짜라고 생각하는 사람에게

맞아요~ 3년 5개월 전 저는 학점 1.9 로 졸업한 쓰레기 대학생이었는데 어느새 UI디자이너&퍼블리셔로서 동료들이 잘하고 있다 열심히 한다 열정있다 해주는 거 보고 정말 많이 성장했다 느낍니다 ㅎㅎ

김진중 저자 도서 포함 3만원 이상 구매 시, 리딩 트래커 증정 (포인트 차감, 한정수량)

월간 개발자 2024년 7월호

예스24 월간 개발자에 선정되었습니다..?! 😳 가.. 가문의 영광.. 🫢🥹

제가 쓴 책들과 함께 저의 추천도서들을 소개하고 있습니다. 커피쿠폰 등 이벤트도 진행하고 있으니 한 번 살펴봐주세요. 🤗 과분한 관심에 늘 감사드립니다. 🙇🏻

추천도서 보러가기 👉 https://event.yes24.com/template?eventNo=249297

예스24 월간 개발자에 선정되었습니다..?! 😳 가.. 가문의 영광.. 🫢🥹 제가 쓴 책들과 함께 저의 추천도서들을 소개하고 있습니다. 커피쿠폰 등 이벤트도 진행하고 있으니 한 번 살펴봐주세요. 🤗 과분한 관심에 늘 감사드립니다. 🙇🏻 추천도서 보러가기 👉 https://event.yes24.com/template?eventNo=249297

예스24

One of my udemy students asked a question about the difference between Postgres and MySQL. The answer turned out too long I thought I'll make it into a post. In a nutshell, the main difference...

Postgres vs MySQL

간단히 말해, 두 데이터베이스의 주요한 차이점은 기본 인덱스와 보조 인덱스를 구현하고, 데이터를 저장하고 업데이트하는 방법으로 요약됩니다. 이에 대해 더 살펴보겠습니다. 

MySQL
기본 인덱스에서 값은 모든 속성을 포함한 전체 행 객체입니다. 그래서 기본 인덱스를 클러스터형 인덱스(clustered indexes) 또는 인덱스-조직형 테이블(index-organized table)이라고 부르는 경우가 많습니다. 즉, 기본 인덱스는 테이블입니다.
 
기본 인덱스에서 키를 조회하면 키가 존재하는 페이지와 해당 키의 값(즉, 전체 행)을 찾을 수 있어 추가 열을 가져오기 위한 추가 I/O가 필요하지 않습니다.
 
보조 인덱스에서는 키가 인덱싱된 열(들)이고 값은 실제 행이 위치한 곳을 가리키는 포인터입니다. 보조 인덱스 리프 페이지의 값은 주로 기본 키입니다.
 
MySQL에서는 모든 테이블에 기본 인덱스가 있어야 하며, 모든 추가 보조 인덱스는 기본 키를 가리킵니다. MySQL 테이블에 기본 키를 생성하지 않으면 시스템이 이를 생성합니다

PostgreSQL
PostgreSQL에서는 기본 인덱스가 없으며, 모든 인덱스는 보조 인덱스이고 시스템이 관리하는 데이터 페이지의 튜플 ID를 가리킵니다. 힙에 로드된 테이블 데이터는 기본 인덱스 리프 페이지와 달리 정렬되지 않습니다. 따라서 행을 1-100까지 삽입하고 모든 행이 동일한 페이지에 있을 때, 나중에 120번 행을 업데이트하면 이 20개의 행이 다른 페이지로 이동해 순서가 뒤바뀔 수 있습니다. 반면 클러스터형 기본 인덱스에서는 키의 순서를 만족하는 페이지로 삽입해야 합니다. 그래서 PostgreSQL 테이블은 "힙 조직형 테이블(heap organized tables)"로 자주 불립니다.
 
PostgreSQL에서는 업데이트와 삭제가 실제로 삽입입니다. 모든 업데이트나 삭제는 새로운 튜플 ID를 생성하고, MVCC(Multi-Version Concurrency Control) 이유로 기존 튜플 ID는 유지됩니다.

Processes vs Threads
MySQL은 스레드를 사용합니다. 이는 여러 이유로 효율적일 수 있습니다:
 * 경량성: 스레드는 프로세스보다 가벼워서 시스템 자원을 덜 사용합니다.
 * 메모리 공유: 스레드는 부모 프로세스의 가상 메모리 주소를 공유하므로 메모리 사용 효율성이 높습니다.
 * 컨텍스트 스위칭: 스레드 간의 컨텍스트 스위칭은 TLB(Translation Look-aside Buffer)를 무효화하지 않기 때문에 상대적으로 빠릅니다. 이는 메모리 매핑이 동일하기 때문에 메모리 접근이 더 효율적입니다.
PostgreSQL은 프로세스를 사용합니다. 이는 스레드 기반 접근 방식과 비교하여 다음과 같은 장단점이 있습니다:
 * 독립성: 각 프로세스는 독립된 가상 메모리를 가지므로 하나의 프로세스가 크래시하더라도 다른 프로세스에 영향을 미치지 않습니다.
 * PCB vs. TCB: 프로세스 제어 블록(PCB)이 스레드 제어 블록(TCB)보다 크지만, 이는 프로세스가 독립된 자원과 환경을 가지고 있기 때문입니다.

Summary
각 데이터베이스 시스템의 장단점을 이해하고, 여러분의 사용 사례와 쿼리에 맞는 시스템을 선택하는 것이 중요합니다. MySQL의 스레드 기반 접근 방식은 가벼운 메모리 사용과 빠른 컨텍스트 스위칭을 제공하는 반면, PostgreSQL의 프로세스 기반 접근 방식은 더 높은 독립성과 안정성을 제공합니다. 따라서 어떤 데이터베이스가 더 적합한지는 사용자의 특정 요구 사항과 환경에 따라 달라질 수 있습니다.
 
결론적으로, 어떤 데이터베이스 시스템이 더 좋다고 단정 지을 수는 없습니다. 각각의 데이터베이스 시스템이 제공하는 기능과 성능을 이해하고, 여러분의 필요에 가장 적합한 것을 선택하는 것이 중요합니다.

번역: [https://ducktopia.tistory.com/128]
원문:

간단히 말해, 두 데이터베이스의 주요한 차이점은 기본 인덱스와 보조 인덱스를 구현하고, 데이터를 저장하고 업데이트하는 방법으로 요약됩니다. 이에 대해 더 살펴보겠습니다.&nbsp; MySQL기본 인덱스에서 값은 모든 속성을 포함한 전체 행 객체입니다. 그래서 기본 인덱스를 클러스터형 인덱스(clustered indexes) 또는 인덱스-조직형 테이블(index-organized table)이라고 부르는 경우가 많습니다. 즉, 기본 인덱스는 테이블입니다.&nbsp;기본 인덱스에서 키를 조회하면 키가 존재하는 페이지와 해당 키의 값(즉, 전체 행)을 찾을 수 있어 추가 열을 가져오기 위한 추가 I/O가 필요하지 않습니다.&nbsp;보조 인덱스에서는 키가 인덱싱된 열(들)이고 값은 실제 행이 위치한 곳을 가리키는 포인터입니다. 보조 인덱스 리프 페이지의 값은 주로 기본 키입니다.&nbsp;MySQL에서는 모든 테이블에 기본 인덱스가 있어야 하며, 모든 추가 보조 인덱스는 기본 키를 가리킵니다. MySQL 테이블에 기본 키를 생성하지 않으면 시스템이 이를 생성합니다 PostgreSQLPostgreSQL에서는 기본 인덱스가 없으며, 모든 인덱스는 보조 인덱스이고 시스템이 관리하는 데이터 페이지의 튜플 ID를 가리킵니다. 힙에 로드된 테이블 데이터는 기본 인덱스 리프 페이지와 달리 정렬되지 않습니다. 따라서 행을 1-100까지 삽입하고 모든 행이 동일한 페이지에 있을 때, 나중에 120번 행을 업데이트하면 이 20개의 행이 다른 페이지로 이동해 순서가 뒤바뀔 수 있습니다. 반면 클러스터형 기본 인덱스에서는 키의 순서를 만족하는 페이지로 삽입해야 합니다. 그래서 PostgreSQL 테이블은 "힙 조직형 테이블(heap organized tables)"로 자주 불립니다.&nbsp;PostgreSQL에서는 업데이트와 삭제가 실제로 삽입입니다. 모든 업데이트나 삭제는 새로운 튜플 ID를 생성하고, MVCC(Multi-Version Concurrency Control) 이유로 기존 튜플 ID는 유지됩니다. Processes vs ThreadsMySQL은 스레드를 사용합니다. 이는 여러 이유로 효율적일 수 있습니다:<ul ><li>경량성: 스레드는 프로세스보다 가벼워서 시스템 자원을 덜 사용합니다.</li><li>메모리 공유: 스레드는 부모 프로세스의 가상 메모리 주소를 공유하므로 메모리 사용 효율성이 높습니다.</li><li>컨텍스트 스위칭: 스레드 간의 컨텍스트 스위칭은 TLB(Translation Look-aside Buffer)를 무효화하지 않기 때문에 상대적으로 빠릅니다. 이는 메모리 매핑이 동일하기 때문에 메모리 접근이 더 효율적입니다.</li></ul>PostgreSQL은 프로세스를 사용합니다. 이는 스레드 기반 접근 방식과 비교하여 다음과 같은 장단점이 있습니다:<ul ><li>독립성: 각 프로세스는 독립된 가상 메모리를 가지므로 하나의 프로세스가 크래시하더라도 다른 프로세스에 영향을 미치지 않습니다.</li><li>PCB vs. TCB: 프로세스 제어 블록(PCB)이 스레드 제어 블록(TCB)보다 크지만, 이는 프로세스가 독립된 자원과 환경을 가지고 있기 때문입니다.</li></ul> Summary각 데이터베이스 시스템의 장단점을 이해하고, 여러분의 사용 사례와 쿼리에 맞는 시스템을 선택하는 것이 중요합니다. MySQL의 스레드 기반 접근 방식은 가벼운 메모리 사용과 빠른 컨텍스트 스위칭을 제공하는 반면, PostgreSQL의 프로세스 기반 접근 방식은 더 높은 독립성과 안정성을 제공합니다. 따라서 어떤 데이터베이스가 더 적합한지는 사용자의 특정 요구 사항과 환경에 따라 달라질 수 있습니다.&nbsp;결론적으로, 어떤 데이터베이스 시스템이 더 좋다고 단정 지을 수는 없습니다. 각각의 데이터베이스 시스템이 제공하는 기능과 성능을 이해하고, 여러분의 필요에 가장 적합한 것을 선택하는 것이 중요합니다. 번역: [https://ducktopia.tistory.com/128]원문:

Medium

🕊️[Medium] Postgres vs MySQL

6월 26일-27일 이틀간 샌프란시스코에서 열린 디자인 컨퍼런스 Config2024에 다녀왔습니다! 이번 컨퍼런스에서 AI를 활용한 새로운 기능과 피그마 슬라이드 서비스를 공개했는데요, 저희가 현지의 뜨거운 반응과 핵심 기능을 요약하여 영상에 담았습니다. 자세한 내용을 확인해보세요-! 초대해주신 피그마 팀에게 감사드립니다 :-) 혁신의 중심지 실리콘밸리의 이야기가 더 궁금하다면?

전 세계 디자이너들 난리난 피그마 컨퍼런스 요약 | Config2024

피그마 컨퍼런스인 Config 2024를 통해 새로운 기능을 대거 선보였습니다. 제품에 AI를 제대로 녹이는 방법을 보여준 것 같네요.

https://youtu.be/aduVMrS-v4o?feature=shared

피그마 컨퍼런스인 Config 2024를 통해 새로운 기능을 대거 선보였습니다. 제품에 AI를 제대로 녹이는 방법을 보여준 것 같네요. https://youtu.be/aduVMrS-v4o?feature=shared

YouTube

피그마: AI는 이렇게 쓰는 겁니다

Wow, Figma’s Config 2024 looks incredible! I’m particularly excited about how they’re integrating AI into their products. It seems like it could really streamline the design process and boost creativity. Did anyone else catch the part about the new features? Which one are you most excited to try out?
https://youtu.be/aduVMrS-v4o?feature=shared https://hillclimb-racing.com

AWS Summit Seoul 2024 On-Demand

올해도 어김없이 개발자들은 흥미진진해할 이야기로 가득차있는 AWS summit 2024 자료가 올라왔습니다. 오늘 퇴근길은 이 자료들로 신날것 같네요!

https://kr-resources.awscloud.com/aws-summit-seoul-2024-on-demand

올해도 어김없이 개발자들은 흥미진진해할 이야기로 가득차있는 AWS summit 2024 자료가 올라왔습니다. 오늘 퇴근길은 이 자료들로 신날것 같네요! https://kr-resources.awscloud.com/aws-summit-seoul-2024-on-demand

Awscloud

AWS summit 2024 영상

CSS 사용자 정의 속성(CSS custom properties)라고도 알려진 CSS 변수(CSS variables)에 대해서 알아보겠습니다.

CSS 변수 (CSS 사용자 정의 속성)

CSS 변수는 예전에는 Sass나, LESS, Stylus와 같은 CSS 전처리기(CSS preprocessor)를 통해서 접할 수 있었던 기능이었습니다. 하지만 최근에는 CSS 스펙 자체에 CSS 변수 개념이 추가되어 이제 CSS 전처리기 없이도 부담없이 CSS 변수를 사용할 수 있게 되었는데요.

이번 영상에서는 CSS 사용자 정의 속성(CSS custom properties)라고도 알려진 CSS 변수(CSS variables)를 어떻게 사용하는지 다양한 실습을 통해서 알아보겠습니다.

• CSS 변수 정의
• CSS 변수 접근
• CSS 변수 기본값
• CSS 변수 상속
• CSS 전역 변수
• 주의 사항

📺 동영상: https://youtu.be/ogvuKmplOcU
📝 포스팅: https://www.daleseo.com/css-variables/
🧑‍💻 실습 코드: https://codepen.io/daleseo/pen/xxqjjwv

CSS의 선택자와 결합자에 대해서는 아래 게시물에서 자세히 다루고 있으니 참고 바랍니다.
📕 CSS 기본 선택자 (selector): https://careerly.co.kr/comments/106255
📗 CSS 결합자(combinator)로 선택자 조합하기: https://careerly.co.kr/comments/107107

CSS 변수는 예전에는 Sass나, LESS, Stylus와 같은 CSS 전처리기(CSS preprocessor)를 통해서 접할 수 있었던 기능이었습니다. 하지만 최근에는 CSS 스펙 자체에 CSS 변수 개념이 추가되어 이제 CSS 전처리기 없이도 부담없이 CSS 변수를 사용할 수 있게 되었는데요. 이번 영상에서는 CSS 사용자 정의 속성(CSS custom properties)라고도 알려진 CSS 변수(CSS variables)를 어떻게 사용하는지 다양한 실습을 통해서 알아보겠습니다. • CSS 변수 정의• CSS 변수 접근• CSS 변수 기본값• CSS 변수 상속• CSS 전역 변수• 주의 사항 📺 동영상: https://youtu.be/ogvuKmplOcU📝 포스팅: https://www.daleseo.com/css-variables/🧑‍💻 실습 코드: https://codepen.io/daleseo/pen/xxqjjwv CSS의 선택자와 결합자에 대해서는 아래 게시물에서 자세히 다루고 있으니 참고 바랍니다.📕 CSS 기본 선택자 (selector): https://careerly.co.kr/comments/106255📗 CSS 결합자(combinator)로 선택자 조합하기: https://careerly.co.kr/comments/107107

Top 1% 개발자로 거듭나는 성공 처방전

데브필 DevPill

시간은 유한하고 누구에게나 동일하게 주어집니다. 그러한 시간을 어떻게 쓰냐에 따라 삶의 방향이나 가치가 달라지죠. 개발을 처음 시작했을 땐 개발 그 자체에 대해 재밌고 호기심에 빨간 망토 앞 황소처럼 열심히 달려들었던 것 같습니다. 그러면서 어느 정도 연차가 쌓이고 이런저런 생각들이 많아지다 보니 커리어에 대한, 경력관리에 대한 고민들이 커지기도 합니다. 그럴 때면 다른 개발자분들의 이야기를 들으며 인사이트를 찾아보려 노력하는 것 같은데요. 이번에 공유드릴 글은 25년간 실리콘밸리에서 엔지니어로 활동한 분의 개발자 회고록입니다. 주요 내용은 다음과 같습니다.

- 마인드 셋과 생산성: 긍정적인 마인드 셋과 효율적인 작업 습관을 유지하는 것이 중요합니다.
- 학습: 지속적인 학습과 자기 계발이 필수적입니다.
- 커리어 계획: 목표를 설정하고 계획적으로 경력을 쌓아야 합니다.
- 공개 노출: 자신을 알리고 네트워크를 확장하는 것이 필요합니다.
- 일과 삶의 균형: 건강한 워라밸을 유지하세요.
- 멘토링과 네트워킹: 멘토와의 관계 및 네트워킹이 중요합니다.

어쩌면 뻔한 내용이다 생각할 수 있겠지만 이 글을 읽는 여러분들의 과거와 현재, 그리고 미래를 돌아보며 인사이트를 얻어보는 것도 좋은 기회가 될 것이라 생각합니다.

마지막 문구가 여러 가지 생각을 하게 하네요.

"가장 중요한 것은 더 잘할 수 있었던 것에 대해 좌절하지 않고, 대신 앞으로 어떻게 개선할 수 있을지에 초점을 맞추는 것입니다."

https://maily.so/devpill/posts/341f8fc4

시간은 유한하고 누구에게나 동일하게 주어집니다. 그러한 시간을 어떻게 쓰냐에 따라 삶의 방향이나 가치가 달라지죠. 개발을 처음 시작했을 땐 개발 그 자체에 대해 재밌고 호기심에 빨간 망토 앞 황소처럼 열심히 달려들었던 것 같습니다. 그러면서 어느 정도 연차가 쌓이고 이런저런 생각들이 많아지다 보니 커리어에 대한, 경력관리에 대한 고민들이 커지기도 합니다. 그럴 때면 다른 개발자분들의 이야기를 들으며 인사이트를 찾아보려 노력하는 것 같은데요. 이번에 공유드릴 글은 25년간 실리콘밸리에서 엔지니어로 활동한 분의 개발자 회고록입니다. 주요 내용은 다음과 같습니다. - 마인드 셋과&nbsp;생산성:&nbsp;긍정적인&nbsp;마인드 셋과&nbsp;효율적인&nbsp;작업&nbsp;습관을&nbsp;유지하는&nbsp;것이&nbsp;중요합니다.- 학습:&nbsp;지속적인&nbsp;학습과&nbsp;자기 계발이&nbsp;필수적입니다.- 커리어 계획: 목표를 설정하고 계획적으로 경력을 쌓아야 합니다.- 공개 노출: 자신을 알리고 네트워크를 확장하는 것이 필요합니다.- 일과 삶의 균형: 건강한 워라밸을 유지하세요.- 멘토링과 네트워킹: 멘토와의 관계 및 네트워킹이 중요합니다. 어쩌면 뻔한 내용이다 생각할 수 있겠지만 이 글을 읽는 여러분들의 과거와 현재, 그리고 미래를 돌아보며 인사이트를 얻어보는 것도 좋은 기회가 될 것이라 생각합니다. 마지막 문구가 여러 가지 생각을 하게 하네요. "가장 중요한 것은 더 잘할 수 있었던 것에 대해 좌절하지 않고, 대신 앞으로 어떻게 개선할 수 있을지에 초점을 맞추는 것입니다." https://maily.so/devpill/posts/341f8fc4﻿

inspireX

내가 18살로 돌아간다면 꼭 하고 싶은 10가지

The App-less, Freeform Interface era is coming.

The App-less, Freeform Interface era is coming.

문제 정의하기는 데이터 분석의 첫 단계로, 해결하고자 하는 문제나 목적을 정의하는 과정입니다. 문제를 정의할 때 아래의 체크리스트(Checklist)들을 통해 더 좋은 데이터 분석을 만들 수 있습니다.

1️⃣ 5W 1H:
WHO, WHAT, WHEN, WHERE, WHY and HOW로 문제(Problem)를 정의할수 있나요?

❓ WHO 누가 문제를 제기하였나요?
❓ WHAT 무엇이 문제인가요?
❓ WHEN 언제 문제가 발생하였나요?
❓ WHERE 어디에서 문제가 발생하였나요?
❓ WHY 왜 이 문제를 해결해야 하나요?
❓ HOW 어떻게 문제를 해결할 것인가요?

2️⃣ 문제(Problem) 해결을 위한 요구 사항(Requirement)가 명확한가요?
문제의 핵심 요구 사항(Requirement)을 2-3줄로 요약(Summary)할수 있나요?

❓ 문제를 해결하였을 때의 혜택(Benefit)은 무엇인가요?
❓ 해결했을 때 어떤 결과들(In-scope)이 발생하나요?
❓ 해결되지 않는 결과들(Out of Scope)은 어떤 것인가요?

3️⃣ 이 문제를 잘 알고 있는 사람들(Stakeholders)의 리스트를 작성할 수 있나요?

❓Subject Matter Expert (SME) 주제 전문가
❓ Stakeholder 문제 관련자
❓ Client 고객

4️⃣ 문제의 긴급도(Urgency)는 어느 정도인가요?

❓매우 급함
❓약간 급함
❓급하지 않음

5️⃣ 데이터 분석으로 주어진 문제(Problem)를 해결 할수 있나요?

❓분류 (Classification) - 주어진 데이터를 미리 정의된 카테고리로 분할하는 데이터 분석 방법입니다.
❓예측 (Prediction) - 주어진 데이터와 과거 패턴을 기반으로 미래의 결과나 동향을 예측하는 데이터 분석 방법입니다.
❓추천 (Recommendation) - 추천은 사용자의 과거 행동과 선호도를 기반으로, 해당 사용자에게 관련된 아이템이나 서비스를 제안하는 데이터 분석 방법입니다.
❓이상치 발견 (Identification) - 이상치 발견은 데이터 분석에서 주어진 데이터 집합에서 통계적으로 특이한 값을 찾아내는 과정입니다.
❓그룹화 (Segmentation) - 주어진 데이터를 특정 기준에 따라 그룹으로 나누는 데이터 분석 방법입니다.
❓기타 (Etc)

문제를 잘 정의하면, 분석에 대한 시작이 더욱 쉬워집니다.

#데이터리차드 #문제정의 #데이터분석 #프로세스

문제 정의하기는 데이터 분석의 첫 단계로, 해결하고자 하는 문제나 목적을 정의하는 과정입니다. 문제를 정의할 때 아래의 체크리스트(Checklist)들을 통해 더 좋은 데이터 분석을 만들 수 있습니다. 1️⃣ 5W 1H: WHO, WHAT, WHEN, WHERE, WHY and HOW로 문제(Problem)를 정의할수 있나요? ❓ WHO 누가 문제를 제기하였나요? ❓ WHAT 무엇이 문제인가요? ❓ WHEN 언제 문제가 발생하였나요? ❓ WHERE 어디에서 문제가 발생하였나요? ❓ WHY 왜 이 문제를 해결해야 하나요? ❓ HOW 어떻게 문제를 해결할 것인가요? 2️⃣ 문제(Problem) 해결을 위한 요구 사항(Requirement)가 명확한가요? 문제의 핵심 요구 사항(Requirement)을 2-3줄로 요약(Summary)할수 있나요? ❓ 문제를 해결하였을 때의 혜택(Benefit)은 무엇인가요? ❓ 해결했을 때 어떤 결과들(In-scope)이 발생하나요? ❓ 해결되지 않는 결과들(Out of Scope)은 어떤 것인가요? 3️⃣ 이 문제를 잘 알고 있는 사람들(Stakeholders)의 리스트를 작성할 수 있나요? ❓Subject Matter Expert (SME) 주제 전문가 ❓ Stakeholder 문제 관련자 ❓ Client 고객 4️⃣ 문제의 긴급도(Urgency)는 어느 정도인가요? ❓매우 급함 ❓약간 급함 ❓급하지 않음 5️⃣ 데이터 분석으로 주어진 문제(Problem)를 해결 할수 있나요? ❓분류 (Classification) - 주어진 데이터를 미리 정의된 카테고리로 분할하는 데이터 분석 방법입니다. ❓예측 (Prediction) - 주어진 데이터와 과거 패턴을 기반으로 미래의 결과나 동향을 예측하는 데이터 분석 방법입니다. ❓추천 (Recommendation) - 추천은 사용자의 과거 행동과 선호도를 기반으로, 해당 사용자에게 관련된 아이템이나 서비스를 제안하는 데이터 분석 방법입니다. ❓이상치 발견 (Identification) - 이상치 발견은 데이터 분석에서 주어진 데이터 집합에서 통계적으로 특이한 값을 찾아내는 과정입니다. ❓그룹화 (Segmentation) - 주어진 데이터를 특정 기준에 따라 그룹으로 나누는 데이터 분석 방법입니다. ❓기타 (Etc) 문제를 잘 정의하면, 분석에 대한 시작이 더욱 쉬워집니다. #데이터리차드 #문제정의 #데이터분석 #프로세스

데이터 분석 프로젝트에서 문제 정의하는 5️⃣ 단계

모범적인 코드는 무엇일까? 프로그래머로 일을 하다보면 개발자들끼리 모범적인 코드에 대해 논쟁 하게 되는 경우가 더러 있습니다. '어떤 구조가 더 좋다.' 혹은 '이건 실제로 내가 해본 경험이 있다'등의 다양한 이유로 시작해서 누군가가 내 코드가 더 좋은 코드라고 주장을 한다거나, 당신이 작성한 코드가 모범적이지 않다고 하는 경우, 혹은 서로의 구조를 주장하다가 기분이 상하는 경우도 있습니다.

더 나은 코드를 작성하기 위한 가이드북 《읽기 쉬운 코드》

✅ 모범적인 코드는 무엇일까?
프로그래머로 일을 하다보면 개발자들끼리 모범적인 코드에 대해 논쟁 하게 되는 경우가 더러 있습니다.

‘어떤 구조가 더 좋다.’ 혹은 ‘이건 실제로 내가 해본 경험이 있다‘등의 다양한 이유로 시작해서 누군가가 내 코드가 더 좋은 코드라고 주장을 한다거나, 당신이 작성한 코드가 모범적이지 않다고 하는 경우, 혹은 서로의 구조를 주장하다가 기분이 상하는 경우도 있습니다.

그래서 많은 코드리뷰 책이나 개발 문화 관련 책에서 “
비자아적 프로그래밍
(감정을 배제하고)을 해라”, “
지속 가능하게 코드
를 짜라"등의 이야기를 하곤 합니다.

허나, 실제로 경험해보면 우리가 사람인 이상, 이런 가이드는 유니콘을 찾아 떠나는 것처럼 실질적인 도움이 되지 않습니다. (실제로 비자아적 프로그래밍을 문화로 만들어보려고 했으나 3개월만에 포기했습니다. 다들 너무 많이 상처를 받았거든요.)

그렇다면 모범적인 코드는 무엇일까요?
이번에 제가 길벗으로 부터 지원 받은 “읽기 쉬운 코드"라는 책에서 모범적인 코드에 대한 힌트를 얻을 수 있었습니다. 바로 인간이 읽기 쉬운 코드 =
모범적인 코드
입니다.

“읽기 쉬운 코드"와 더불어 리팩토링의 저자 마틴 파울러가 하는 핵심은 이렇습니다.

“컴퓨터가 인식 가능한 코드는 바보라도 작성할 수 있지만, 인간이 이해할 수 있는 코드는 실력 있는 프로그래머만 작성할 수 있다.”

✅ 읽기 쉬운 코드
오늘 소개시켜 드릴 읽기 쉬운 코드 는 책 전반에 걸쳐, 어떻게 하면 인간이 읽기 쉬우면서 내 머리에 적합한 코드를 작성하는 가에 대한 팁들로 가득차 있습니다. 교양과 같은 책인 줄 알았는데, 확실하게 이야기드리면 “실용서"에 가깝습니다. 이 정도까지 디테일해도 되나? 싶은 느낌이 많이 들었던 책은 간만이였습니다.

제가 주로 다루는 C#을 기반으로 책이 작성되어 있어서, 저 같은 경우엔 책을 읽으면서 현재 본업에서 몇가지는 적용도 해보게 되었습니다. 특히,
9장 팀워크
는 엔지니어링 리드나 팀장을 맡고 계시다면 꼭 추천해드리는 챕터 중 하나입니다. 지속적인 통합(CI)라던가 작고 많이 커밋하기, 그리고 코드의 공동 소유 개념과 코드 리뷰등 정말 알찬 팁들이 가득했습니다.

✅ 책은 모범적 코드에 대한 답을 알려주는가?
책은 전반에 걸쳐 “모범적 코드란 무엇이다!“를 제시하기 보다는 모범적인 코드로 나아가는 방법 경험에 기반해서 제시하고, 읽는 이로 하여금 답을 찾게 해줍니다. 그래서 책의 저자도 그렇고, 추천서를 쓴 마틴도 그렇고, 모든 것의 전제는
소프트 웨어는 어렵다
에서 시작합니다.

그래서 섣불리 모범을 제시하기 보단, 기동성과 더 나은 코드 를 작성하기 위한 실용적인 방법이라던가, 어떻게 코드를 내 머릿속에서 정리하고, 팀에게 잘 전파하는지 등과 같은 코드를 “읽기 쉬운 방향"으로 보내는 방법들에 대해 경험적으로 풀어 나가고 있습니다.

대표적인 예를 들면 테스트를 작성하는 방법이나 테스트 코드를 위해 관심사 분리의 개념에 대한 팁을 이야기하면서 동시에 테스트가 너무나 많아져서 생기는 퇴행에 대해서도 다루는게 이 책의 핵심입니다.

그래서 재밌게도 마틴이 쓴 책 추천서를 보면 이런 내용이 나옵니다.

책을 읽으면서 동의하지 않는 부분을 찾아 내는 것이 얼마나 재밌을지 생각 했습니다. 그리고 정확히 그런일이 발생했습니다. (중략) 하지만 이건 중요하지 않습니다. 요점은 소프트웨어가 어렵다는 것이고, 지난 70년 동안 소프트웨어를 조금이라도 쉽게 만들 수 있는 방법을 찾기 위해 노력해왔다는 것입니다.

저도 이 책을 보면서 “이렇게 까지 해야하나?” 싶은 동의하지 않는 내용도 있었고, “와 이건 실용적이다"라는 것들도 있었습니다. 허나 천천히 음미해보면 전체적인 구성이나 내용들이 실용적인 내용으로 가득차 있고, 간만에 성장한 느낌을 받았습니다.
만약에 여러분이 소프트웨어 개발의 통찰력과, 더 나은 코드를 위한 통찰력을 얻고 싶으시다면 읽어보길 추천드립니다.

✅ 모범적인 코드는 무엇일까?프로그래머로 일을 하다보면 개발자들끼리 모범적인 코드에 대해 논쟁 하게 되는 경우가 더러 있습니다. ‘어떤 구조가 더 좋다.’ 혹은 ‘이건 실제로 내가 해본 경험이 있다‘등의 다양한 이유로 시작해서 누군가가 내 코드가 더 좋은 코드라고 주장을 한다거나, 당신이 작성한 코드가 모범적이지 않다고 하는 경우, 혹은 서로의 구조를 주장하다가 기분이 상하는 경우도 있습니다. 그래서 많은 코드리뷰 책이나 개발 문화 관련 책에서 “<code >비자아적 프로그래밍</code>(감정을 배제하고)을 해라”, “<code >지속 가능하게 코드</code>를 짜라"등의 이야기를 하곤 합니다. 허나, 실제로 경험해보면 우리가 사람인 이상, 이런 가이드는 유니콘을 찾아 떠나는 것처럼 실질적인 도움이 되지 않습니다. (실제로 비자아적 프로그래밍을 문화로 만들어보려고 했으나 3개월만에 포기했습니다. 다들 너무 많이 상처를 받았거든요.) 그렇다면 모범적인 코드는 무엇일까요?이번에 제가 길벗으로 부터 지원 받은 “읽기 쉬운 코드"라는 책에서 모범적인 코드에 대한 힌트를 얻을 수 있었습니다. 바로 인간이 읽기 쉬운 코드 = <code >모범적인 코드</code> 입니다. “읽기 쉬운 코드"와 더불어 리팩토링의 저자 마틴 파울러가 하는 핵심은 이렇습니다. “컴퓨터가 인식 가능한 코드는 바보라도 작성할 수 있지만, 인간이 이해할 수 있는 코드는 실력 있는 프로그래머만 작성할 수 있다.” ✅ 읽기 쉬운 코드오늘 소개시켜 드릴 읽기 쉬운 코드 는 책 전반에 걸쳐, 어떻게 하면 인간이 읽기 쉬우면서 내 머리에 적합한 코드를 작성하는 가에 대한 팁들로 가득차 있습니다. 교양과 같은 책인 줄 알았는데, 확실하게 이야기드리면 “실용서"에 가깝습니다. 이 정도까지 디테일해도 되나? 싶은 느낌이 많이 들었던 책은 간만이였습니다. 제가 주로 다루는 C#을 기반으로 책이 작성되어 있어서, 저 같은 경우엔 책을 읽으면서 현재 본업에서 몇가지는 적용도 해보게 되었습니다. 특히, <code >9장 팀워크</code>는 엔지니어링 리드나 팀장을 맡고 계시다면 꼭 추천해드리는 챕터 중 하나입니다. 지속적인 통합(CI)라던가 작고 많이 커밋하기, 그리고 코드의 공동 소유 개념과 코드 리뷰등 정말 알찬 팁들이 가득했습니다. ✅ 책은 모범적 코드에 대한 답을 알려주는가?책은 전반에 걸쳐 “모범적 코드란 무엇이다!“를 제시하기 보다는 모범적인 코드로 나아가는 방법 경험에 기반해서 제시하고, 읽는 이로 하여금 답을 찾게 해줍니다. 그래서 책의 저자도 그렇고, 추천서를 쓴 마틴도 그렇고, 모든 것의 전제는 <code >소프트 웨어는 어렵다</code> 에서 시작합니다. 그래서 섣불리 모범을 제시하기 보단, 기동성과 더 나은 코드 를 작성하기 위한 실용적인 방법이라던가, 어떻게 코드를 내 머릿속에서 정리하고, 팀에게 잘 전파하는지 등과 같은 코드를 “읽기 쉬운 방향"으로 보내는 방법들에 대해 경험적으로 풀어 나가고 있습니다. 대표적인 예를 들면 테스트를 작성하는 방법이나 테스트 코드를 위해 관심사 분리의 개념에 대한 팁을 이야기하면서 동시에 테스트가 너무나 많아져서 생기는 퇴행에 대해서도 다루는게 이 책의 핵심입니다. 그래서 재밌게도 마틴이 쓴 책 추천서를 보면 이런 내용이 나옵니다. 책을 읽으면서 동의하지 않는 부분을 찾아 내는 것이 얼마나 재밌을지 생각 했습니다. 그리고 정확히 그런일이 발생했습니다. (중략) 하지만 이건 중요하지 않습니다. 요점은 소프트웨어가 어렵다는 것이고, 지난 70년 동안 소프트웨어를 조금이라도 쉽게 만들 수 있는 방법을 찾기 위해 노력해왔다는 것입니다. 저도 이 책을 보면서 “이렇게 까지 해야하나?” 싶은 동의하지 않는 내용도 있었고, “와 이건 실용적이다"라는 것들도 있었습니다. 허나 천천히 음미해보면 전체적인 구성이나 내용들이 실용적인 내용으로 가득차 있고, 간만에 성장한 느낌을 받았습니다.만약에 여러분이 소프트웨어 개발의 통찰력과, 더 나은 코드를 위한 통찰력을 얻고 싶으시다면 읽어보길 추천드립니다.

소난의 블로그

 1. 기본기 확실히 하기
 2. 학습 능력 키우기
 3. 의사 소통 잘하기
 4. 문제 정의 잘하기
 5. 태스크 완료 시간 추정 잘하기
 6. 운영을 고려한 코드 작성하기
 7. 서비스 사고 대처 능력 키우기
 8. 결과를 내는데 집중하기
 9. 영향력 갖기 (코딩 멍키)

많은 한국 개발자들이 코딩을 중단하고 매니지먼트쪽으로 들어가는 것 굉장히 두려워한다. 사실 모든 사람들이 매니저 역할을 할 필요는 없지만 코딩을 계속한다고 해도 개인기를 부려서 혼자만 인정받으려 하지 말아야 한다. 단순 코딩을 잘 하는 것이 아닌 그 이상이 필요하고 그게 내 경쟁력이 되어야 한다는 점인데 의사소통을 잘 해서 문제 정의를 잘 하고 주어진 업무의 완료 시간 추정 잘하고 내가 만든 코드를 운영 관점에서도 바라봐야 한다. 그냥 혼자 코딩만 잘 한다면 요즘처럼 AI 코딩 생산성 툴이 나오는 세상에서는 대체 1순위가 되기 쉽다.

그럼 영향력이란 무엇일까? 나의 존재로 인해 내 주변 사람들의 역량이 올라가는 것이라 생각한다. 영향력은 꼭 매니저에게만 필요한 것일까? 그와 상관없이 시니어급이라면 꼭 갖추어야할 기술이다. "기술"이라고 지칭한 이유는 타고나는 재능이 아니란 점을 분명히 하고 싶어서다. 즉 처음부터 잘 한다기 보다는 크고 작은 실수/실패를 거쳐서 생겨나는 기술이다.

영향력의 시작은 좋은 평판을 갖는 것이다. 앞서 이야기한 맡은 일의 결과를 만들어내고 맞는 공헌을 하는 사람이 되는 것이 좋은 평판의 한 포인트이고 다른 한 포인트는 팀 플레이어가 되는 것이다. 팀 플레이어라는 관점에서는 긍정적인 태도를 바탕으로 내가 맡은 업무 뿐만 아니라 내 업무 밖의 일도 팀을 위해 하는 그런 모습을 갖는 것이 중요하다. 즉 좋은 평판이란 다시 같이 일하고 싶은 사람이 되는 것이며 이를 통해 생각하지 못했던 기회가 생긴다 ("지인 추천")

좋은 평판 = 맡은 일의 결과를 내기 x 팀 플레이어가 되기

여러분의 커리어 후반기에도 새로운 기회를 매번 내가 찾아서 가야한다면 그게 과연 원하는 길일까? 좋은 평판을 통해 지인 추천의 형태로 기회를 만들어내는 것이 더 자연스럽다고 생각한다.

구체적인 영향력을 갖는 방법은 여러가지가 있다.

 1. 주변 사람들을 잘 도와준다. 주니어들을 잘 코칭해준다. 주니어들의 일을 대신 해주라는 이야기가 아니다. 누가 새로 들어와서 헤매는 것 같으면 도움이 되는 조언해주고 막힌 부분을 뚫어준다.
 2. 미팅을 리딩하거나 할때 다양한 사람들이 자기의 의견을 쉽게 표현할 수 있는 환경을 만들고 의견을 내지 못하고 자기검열하는 사람들 찝어서 말을 시켜본다.
 3. 리더나 리드로써 다른 팀원이 해야할 일을 본인이 습관적으로 하고 있는지 고민해보고 일을 넘기는 노력을 한다. 지난 회에 이야기했던 것처럼 나의 역할에 맞는 공헌/임팩트를 내는 것이 중요하다.
 4. 사람들이나 팀간의 충돌이 있을 때 해결하는데 초점을 맞추고 원칙을 만들어 다음에 비슷한 문제가 생겼을 때 방안으로 바라볼 수 있게 만든다.
 5. 아쉬운 행동을 하는 사람을 바라보는 관점은 호기심이 되어야 하며 항상 선의를 가지고 행동해야 한다.

9번에 걸쳐 긴 커리어를 행복하게 이어갈 수 있는 개발자의 마인드셋에 대해 이야기해보았다. 요약하면 수능준비처럼 몇년 공부해서 되는 것이 아니고 오랜 시간에 걸쳐 실수와 고민을 통해 만들어지는 것이란 점을 꼭 기억했으면 좋겠다. 다음에는 조금더 기술적인 측면에서 이야기를 해보고자 한다.

<ol ><li>기본기 확실히 하기</li><li>학습 능력 키우기</li><li>의사 소통 잘하기</li><li>문제 정의 잘하기</li><li>태스크 완료 시간 추정 잘하기</li><li>운영을 고려한 코드 작성하기</li><li>서비스 사고 대처 능력 키우기</li><li>결과를 내는데 집중하기</li><li>영향력 갖기 <s>(코딩 멍키)</s></li></ol> 많은 한국 개발자들이 코딩을 중단하고 매니지먼트쪽으로 들어가는 것 굉장히 두려워한다. 사실 모든 사람들이 매니저 역할을 할 필요는 없지만 코딩을 계속한다고 해도 개인기를 부려서 혼자만 인정받으려 하지 말아야 한다. 단순 코딩을 잘 하는 것이 아닌 그 이상이 필요하고 그게 내 경쟁력이 되어야 한다는 점인데 의사소통을 잘 해서 문제 정의를 잘 하고 주어진 업무의 완료 시간 추정 잘하고 내가 만든 코드를 운영 관점에서도 바라봐야 한다. 그냥 혼자 코딩만 잘 한다면 요즘처럼 AI 코딩 생산성 툴이 나오는 세상에서는 대체 1순위가 되기 쉽다. 그럼 영향력이란 무엇일까? 나의 존재로 인해 내 주변 사람들의 역량이 올라가는 것이라 생각한다. 영향력은 꼭 매니저에게만 필요한 것일까? 그와 상관없이 시니어급이라면 꼭 갖추어야할 기술이다. "기술"이라고 지칭한 이유는 타고나는 재능이 아니란 점을 분명히 하고 싶어서다. 즉 처음부터 잘 한다기 보다는 크고 작은 실수/실패를 거쳐서 생겨나는 기술이다. 영향력의 시작은 좋은 평판을 갖는 것이다. 앞서 이야기한 맡은 일의 결과를 만들어내고 맞는 공헌을 하는 사람이 되는 것이 좋은 평판의 한 포인트이고 다른 한 포인트는 팀 플레이어가 되는 것이다. 팀 플레이어라는 관점에서는 긍정적인 태도를 바탕으로 내가 맡은 업무 뿐만 아니라 내 업무 밖의 일도 팀을 위해 하는 그런 모습을 갖는 것이 중요하다. 즉 좋은 평판이란 다시 같이 일하고 싶은 사람이 되는 것이며 이를 통해 생각하지 못했던 기회가 생긴다 ("지인 추천") 좋은 평판 = 맡은 일의 결과를 내기 x 팀 플레이어가 되기 여러분의 커리어 후반기에도 새로운 기회를 매번 내가 찾아서 가야한다면 그게 과연 원하는 길일까? 좋은 평판을 통해 지인 추천의 형태로 기회를 만들어내는 것이 더 자연스럽다고 생각한다. 구체적인 영향력을 갖는 방법은 여러가지가 있다. <ol ><li>주변 사람들을 잘 도와준다. 주니어들을 잘 코칭해준다. 주니어들의 일을 대신 해주라는 이야기가 아니다. 누가 새로 들어와서 헤매는 것 같으면 도움이 되는 조언해주고 막힌 부분을 뚫어준다. </li><li>미팅을 리딩하거나 할때 다양한 사람들이 자기의 의견을 쉽게 표현할 수 있는 환경을 만들고 의견을 내지 못하고 자기검열하는 사람들 찝어서 말을 시켜본다.</li><li>리더나 리드로써 다른 팀원이 해야할 일을 본인이 습관적으로 하고 있는지 고민해보고 일을 넘기는 노력을 한다. 지난 회에 이야기했던 것처럼 나의 역할에 맞는 공헌/임팩트를 내는 것이 중요하다. </li><li>사람들이나 팀간의 충돌이 있을 때 해결하는데 초점을 맞추고 원칙을 만들어 다음에 비슷한 문제가 생겼을 때 방안으로 바라볼 수 있게 만든다.</li><li>아쉬운 행동을 하는 사람을 바라보는 관점은 호기심이 되어야 하며 항상 선의를 가지고 행동해야 한다.</li></ol> 9번에 걸쳐 긴 커리어를 행복하게 이어갈 수 있는 개발자의 마인드셋에 대해 이야기해보았다. 요약하면 수능준비처럼 몇년 공부해서 되는 것이 아니고 오랜 시간에 걸쳐 실수와 고민을 통해 만들어지는 것이란 점을 꼭 기억했으면 좋겠다. 다음에는 조금더 기술적인 측면에서 이야기를 해보고자 한다.

좋은 개발자가 알아야하는 9가지 포인트들 - 9. 영향력 갖기

개발자 채용을 위한 면접을 하다보면 본인이 합류하게 될 회사나 팀이 어떤 기술을 사용하는지에 대해 신경을 쓰는 지원자들이 정말 많은데요. 어떤 프로그래밍 언어로 개발을 하는지부터, 어떤 프레임워크와 라이브러리를 사용하는지, 어떤 데이터베이스와 클라우드 컴퓨팅을 쓰는지 등등.

기술 스택만큼 중요한 비즈니스 도메인

개발자 채용을 위한 면접을 하다보면 본인이 합류하게 될 회사나 팀이 어떤 기술을 사용하는지에 대해 신경을 쓰는 지원자들이 정말 많은데요. 어떤 프로그래밍 언어로 개발을 하는지부터, 어떤 프레임워크와 라이브러리를 사용하는지, 어떤 데이터베이스와 클라우드 컴퓨팅을 쓰는지 등등... 이렇게 꼬리에 꼬리를 잊는 질문이 이어지죠. 제 답변을 들은 후 실망하는 표정을 감추지 못하는 지원자도 보았습니다 😞

그러나 정작 본인이 지원한 회사가 어떤 사업을 하는지에 대한 관심을 갖고 좋은 질문을 하는 개발자들은 상대적으로 드문 것 같아요. 혹시 기술 스택(Tech Stack)만 나랑 잘 맞으면 어떤 비즈니스든지 입사해서 천천히 배울 수 있다고 생각하시는 건가요? 🤨

사실 제가 예전에 그랬거든요... 하하 😂

저도 예전에는 이직하거나 팀을 옮길 때 사용하는 기술을 매우 중요하게 생각했어요. 특히 한국에서 일했을 때는 주구장창 자바와 스프링, 오라클 DB로만 개발하여 이 기술 스택을 벗어나는 회사를 기피했죠. 힘들게 쌓은 지식과 경험을 새로운 업무에서 100% 활용할 수 없을까봐 걱정이 됐고, 앞으로의 경력에 도움이 될지 모를 생소한 기술을 배워야 하는데 부담을 느꼈습니다.

그런데 소프트웨어 개발을 시작한 지 언 16년이 지난 현재의 관점에서 생각해보면, 그 때 제 생각이 참 짧았다는 생각이 들어요. 기껏해야 몇 년 안 되는 경험을, 까짓 것 좀 못 살리면 어떻다고... 그 새로운 기술을 배울 수 있는 좋은 기회들을 그냥 보내 버렸을까요? 깐깐하게 기술 스택을 따지는 것도 중요하겠지만, 이 바닥에서 점점 경력이 쌓이다 보니 자신에게 잘 맞는 비즈니스 도메인을 선택하는 것도 그에 못지 않게 참 중요하다는 생각이 듭니다.

우리 한번 소프트웨어 개발자로서 냉정하게 생각을 해볼까요? 새로운 기술을 배우는 게 힘든가요? 새로운 비즈니스를 배우는 게 힘든가요? 개발 관련된 지식은 온라인에 학습 자료가 풍부하며 심지어 무료도 많은데요. 하지만 특정 비즈니스에 대한 지식은 배우는데 많은 비용이 들거나 체계적인 교육없이 노하우처럼 전수되는 경우도 있죠. 따라서 상대적으로 배우려는 의지와 적극성이 더 필요합니다. 해당 비즈니스 도메인에 흥미가 없다면 배우는 과정 자체가 고통이 될 수도 있고요.

아무래도 첫 직장은 선택하기 보다는 선택 당하는 입장이라서 자신이 원하는 비즈니스 도메인을 고르기가 쉽지 않은데요. 저도 첫 직장에서는 생각치도 못했던 기업용 소프트웨어를 개발하게 되었고, ERP(Enterprise Resource Planning)와 CRM(Customer Relationship Management)과 같은 생전 처음 들어보는 방대한 엔터프라이즈 솔루션에 대해서 공부해야 했습니다. 선배 어깨 넘어로 배우다 보니 답답하기도 했지만, 전문 교육은 업무를 1~2주 빠져야 해서 신청하기가 눈치가 보였죠. 그런데 솔직히... 어떻게 보면 이건 다 핑계입니다. 저는 단지 그 비즈니스 도메인에 큰 매력을 느끼지 못했던 것입니다.

그 이후에 다른 회사들을 다니면서 모바일 앱 스토어나 전자 상거래 플랫폼과 같은 대국민 소프트웨어를 개발했는데요. 아무래도 제가 실생활에서 사용하는 서비스다 보니 비즈니스에 대해서 관심이 많아지더라고요. "아, 내가 주문한 제품이 이런 이런 과정을 거쳐서 결제가 되고, 이런 이런 과정을 거쳐서 배송이 되고, 반품은 이런 이런 과정을 거쳐서 이뤄지는구나!" 자꾸 호기심이 생겨서 사업 담당자를 찾아가서 이것저것 자주 물어보곤 했습니다. 귀찮아 하시면 어떨까 걱정했지만 오히려 정반대였습니다. 비즈니스를 제대로 이해하려고 찾아오는 개발자는 어디서든 환영받으니까요.

현재 저는 캐나다에서 아이를 키우는 중이어서, 여느 학부모처럼 저의 관심사는 교육 쪽으로 옮겨가게 되었습니다. 그런데 저는 줄곧 한국에서 교육을 받아왔기 때문에 캐나다의 교육 시스템에 대해 매우 생소했습니다. 그래서 여러 기회가 있었지만 EdTech(교육 기술) 분야에서 한 번 일해보기로 결심했지요. 몇 년간 이 분야에서 몸 담으면서 캐나다의 공교육 행정이 어떻게 돌아가고, 선생님들이 학교에서 어떻게 학생들을 가르치며, 부모들은 어떤 교육을 기대하고 있는지 배울 수가 있었습니다. 이렇게 제가 일을 하면서 체득한 도메인 지식들은 캐나다에서 육아를 하는데 정말 큰 도움이 되고 있습니다.

최근에는 프로젝트 때문에 캐나다를 포함한 여러 교육 선진국들의 유학 프로세스에 대해서 공부하고 있는데요. 저는 한 번도 해외 유학을 가보지 않아서 이 쪽에 대해서는 완전 문외한이었는데, 이제는 제 주변에 있는 많은 이민자들이 어떤 과정을 거쳐 이 나라에서 공부하고 정착까지 하게 되는지에 대해 이해할 수 있게 되었어요. 이처럼 자신이 평소에 관심이 있는 비즈니스 도메인에서 일하게 되면 단순히 소프트웨어 개발을 넘어, 자연스럽게 해당 비즈니스 도메인에서 전문성을 키울 수 있답니다. 도메인 전문성을 갖춘 소프트웨어 개발자는 귀해서 시장에서 항상 좋은 대우를 받는 건 다들 아실 거에요.

요즘에는 진짜 소프트웨어 개발이 필요하지 않은 분야가 없다고 하죠? 그래서 저는 소프트웨어 개발자는 원하는 비즈니스 도메인을 선택할 수 있는 진짜 얼마 안 되는 축복받은 직업이라고 생각합니다. 앞으로 개발자로 커리어를 쌓아가시면서 어떤 기술을 쓰고 싶으신지 뿐만 아니라, 자신이 어떤 비즈니스에 흥미를 느끼시고 배우고 싶으신지에 대해서도 좀 더 생각해보시면 어떨까요?

여러분은 저보다 좀 더 빨리 기술 스택의 굴레에서 벗어나 좀 더 재미있는 비즈니스 도메인에서 일하실 수 있으셨으면 좋겠습니다! 🙏🚀

개발자 채용을 위한 면접을 하다보면 본인이 합류하게 될 회사나 팀이 어떤 기술을 사용하는지에 대해 신경을 쓰는 지원자들이 정말 많은데요. 어떤 프로그래밍 언어로 개발을 하는지부터, 어떤 프레임워크와 라이브러리를 사용하는지, 어떤 데이터베이스와 클라우드 컴퓨팅을 쓰는지 등등... 이렇게 꼬리에 꼬리를 잊는 질문이 이어지죠. 제 답변을 들은 후 실망하는 표정을 감추지 못하는 지원자도 보았습니다 😞 그러나 정작 본인이 지원한 회사가 어떤 사업을 하는지에 대한 관심을 갖고 좋은 질문을 하는 개발자들은 상대적으로 드문 것 같아요. 혹시 기술 스택(Tech Stack)만 나랑 잘 맞으면 어떤 비즈니스든지 입사해서 천천히 배울 수 있다고 생각하시는 건가요? 🤨 사실 제가 예전에 그랬거든요... 하하 😂 저도 예전에는 이직하거나 팀을 옮길 때 사용하는 기술을 매우 중요하게 생각했어요. 특히 한국에서 일했을 때는 주구장창 자바와 스프링, 오라클 DB로만 개발하여 이 기술 스택을 벗어나는 회사를 기피했죠. 힘들게 쌓은 지식과 경험을 새로운 업무에서 100% 활용할 수 없을까봐 걱정이 됐고, 앞으로의 경력에 도움이 될지 모를 생소한 기술을 배워야 하는데 부담을 느꼈습니다. 그런데 소프트웨어 개발을 시작한 지 언 16년이 지난 현재의 관점에서 생각해보면, 그 때 제 생각이 참 짧았다는 생각이 들어요. 기껏해야 몇 년 안 되는 경험을, 까짓 것 좀 못 살리면 어떻다고... 그 새로운 기술을 배울 수 있는 좋은 기회들을 그냥 보내 버렸을까요? 깐깐하게 기술 스택을 따지는 것도 중요하겠지만, 이 바닥에서 점점 경력이 쌓이다 보니 자신에게 잘 맞는 비즈니스 도메인을 선택하는 것도 그에 못지 않게 참 중요하다는 생각이 듭니다. 우리 한번 소프트웨어 개발자로서 냉정하게 생각을 해볼까요? 새로운 기술을 배우는 게 힘든가요? 새로운 비즈니스를 배우는 게 힘든가요? 개발 관련된 지식은 온라인에 학습 자료가 풍부하며 심지어 무료도 많은데요. 하지만 특정 비즈니스에 대한 지식은 배우는데 많은 비용이 들거나 체계적인 교육없이 노하우처럼 전수되는 경우도 있죠. 따라서 상대적으로 배우려는 의지와 적극성이 더 필요합니다. 해당 비즈니스 도메인에 흥미가 없다면 배우는 과정 자체가 고통이 될 수도 있고요. 아무래도 첫 직장은 선택하기 보다는 선택 당하는 입장이라서 자신이 원하는 비즈니스 도메인을 고르기가 쉽지 않은데요. 저도 첫 직장에서는 생각치도 못했던 기업용 소프트웨어를 개발하게 되었고, ERP(Enterprise Resource Planning)와 CRM(Customer Relationship Management)과 같은 생전 처음 들어보는 방대한 엔터프라이즈 솔루션에 대해서 공부해야 했습니다. 선배 어깨 넘어로 배우다 보니 답답하기도 했지만, 전문 교육은 업무를 1~2주 빠져야 해서 신청하기가 눈치가 보였죠. 그런데 솔직히... 어떻게 보면 이건 다 핑계입니다. 저는 단지 그 비즈니스 도메인에 큰 매력을 느끼지 못했던 것입니다. 그 이후에 다른 회사들을 다니면서 모바일 앱 스토어나 전자 상거래 플랫폼과 같은 대국민 소프트웨어를 개발했는데요. 아무래도 제가 실생활에서 사용하는 서비스다 보니 비즈니스에 대해서 관심이 많아지더라고요. "아, 내가 주문한 제품이 이런 이런 과정을 거쳐서 결제가 되고, 이런 이런 과정을 거쳐서 배송이 되고, 반품은 이런 이런 과정을 거쳐서 이뤄지는구나!" 자꾸 호기심이 생겨서 사업 담당자를 찾아가서 이것저것 자주 물어보곤 했습니다. 귀찮아 하시면 어떨까 걱정했지만 오히려 정반대였습니다. 비즈니스를 제대로 이해하려고 찾아오는 개발자는 어디서든 환영받으니까요. 현재 저는 캐나다에서 아이를 키우는 중이어서, 여느 학부모처럼 저의 관심사는 교육 쪽으로 옮겨가게 되었습니다. 그런데 저는 줄곧 한국에서 교육을 받아왔기 때문에 캐나다의 교육 시스템에 대해 매우 생소했습니다. 그래서 여러 기회가 있었지만 EdTech(교육 기술) 분야에서 한 번 일해보기로 결심했지요. 몇 년간 이 분야에서 몸 담으면서 캐나다의 공교육 행정이 어떻게 돌아가고, 선생님들이 학교에서 어떻게 학생들을 가르치며, 부모들은 어떤 교육을 기대하고 있는지 배울 수가 있었습니다. 이렇게 제가 일을 하면서 체득한 도메인 지식들은 캐나다에서 육아를 하는데 정말 큰 도움이 되고 있습니다. 최근에는 프로젝트 때문에 캐나다를 포함한 여러 교육 선진국들의 유학 프로세스에 대해서 공부하고 있는데요. 저는 한 번도 해외 유학을 가보지 않아서 이 쪽에 대해서는 완전 문외한이었는데, 이제는 제 주변에 있는 많은 이민자들이 어떤 과정을 거쳐 이 나라에서 공부하고 정착까지 하게 되는지에 대해 이해할 수 있게 되었어요. 이처럼 자신이 평소에 관심이 있는 비즈니스 도메인에서 일하게 되면 단순히 소프트웨어 개발을 넘어, 자연스럽게 해당 비즈니스 도메인에서 전문성을 키울 수 있답니다. 도메인 전문성을 갖춘 소프트웨어 개발자는 귀해서 시장에서 항상 좋은 대우를 받는 건 다들 아실 거에요. 요즘에는 진짜 소프트웨어 개발이 필요하지 않은 분야가 없다고 하죠? 그래서 저는 소프트웨어 개발자는 원하는 비즈니스 도메인을 선택할 수 있는 진짜 얼마 안 되는 축복받은 직업이라고 생각합니다. 앞으로 개발자로 커리어를 쌓아가시면서 어떤 기술을 쓰고 싶으신지 뿐만 아니라, 자신이 어떤 비즈니스에 흥미를 느끼시고 배우고 싶으신지에 대해서도 좀 더 생각해보시면 어떨까요? 여러분은 저보다 좀 더 빨리 기술 스택의 굴레에서 벗어나 좀 더 재미있는 비즈니스 도메인에서 일하실 수 있으셨으면 좋겠습니다! 🙏🚀

Linkedin

모닥불 피워두고 같이 도란도란 이야기 나누는 것처럼, 토스 프론트엔드 개발자들은 '모닥불'이라는 시간을 통해 함께 기술적인 문제를 나누고 해결방안을 찾아가는데요. 최근 모닥불 중 가장 뜨거웠던 주제를 소개합니다.

모닥불 | EP.1 토스에서 말하는 "가독성 좋은 코드" 란 무엇일까?

지난 포스트에서 길벗출판사의 '코드 작성 가이드' 책을 통해 가독성 좋은 코드에 대해 소개했었는데요,

토스 프론트엔드 헤드 서진님과 프론트엔드 개발자 유림님, 진우님이 '가독성 좋은 코드'란 무엇인지에 대해 나누는 이야기입니다.

“코드란 비즈니스를 위한 수단이다"
"퀄리티 높은 코드는 동료를 위한 것이다"

영상을 보며 가독성에 대해 한번 더 고민해보세요 :)
 * 09:06: '가독성'의 요소 정의
 * 10:40: AI가 해주지 않을까요?
 * 11:16: 주니어 때를 돌이켜보면…
 * 16:23: 리팩토링하기 가장 좋은 타이밍

https://toss.tech/article/firesidechat_frontend_1

지난 포스트에서 길벗출판사의 '코드 작성 가이드' 책을 통해 가독성 좋은 코드에 대해 소개했었는데요, 토스 프론트엔드 헤드 서진님과 프론트엔드 개발자 유림님, 진우님이 '가독성 좋은 코드'란 무엇인지에 대해 나누는 이야기입니다. “코드란 비즈니스를 위한 수단이다""퀄리티 높은 코드는 동료를 위한 것이다" 영상을 보며 가독성에 대해 한번 더 고민해보세요 :)<ul ><li>09:06:&nbsp;'가독성'의 요소 정의</li><li>10:40:&nbsp;AI가 해주지 않을까요?</li><li>11:16:&nbsp;주니어 때를 돌이켜보면…</li><li>16:23:&nbsp;리팩토링하기 가장 좋은 타이밍</li></ul> https://toss.tech/article/firesidechat_frontend_1

Toss

토스에서 말하는 '가독성 좋은 코드'

발음이 헷갈리는 개발 용어에 대해 손쉽게 발음과 뜻을 검색해보세요.

데브말싸미 | 개발 용어 발음 사전

개발 용어를 읽는 방법이 달라 소통이 어려웠던 적이 있으신가요? 데브말싸미로 개발 용어를 읽는 방법을 확인해보세요!

 * Service: https://dev-malssami.site/home
 * GitHub: https://github.com/Devminjeong-eum

개발 용어를 읽는 방법이 달라 소통이 어려웠던 적이 있으신가요? 데브말싸미로 개발 용어를 읽는 방법을 확인해보세요! <ul ><li>Service: https://dev-malssami.site/home</li><li>GitHub: https://github.com/Devminjeong-eum</li></ul>

데브말싸미

개발 용어 발음 사전

이번 영상의 주인공은 실리콘밸리 인스타그램 수석 엔지니어이자 ChatGPT 유튜브 채널 커리어해커 알렉스(@careerhackeralex)를 운영하고 계시는 안상현님입니다. 실리콘밸리 최전선에 있는 현직자는 ChatGPT를 어떻게 활용하고 있을까요? 더 나아가 AI시대 앞으로 우리의 경쟁력은 무엇이 될지 상현님의 인사이트를 지금 바로 만나보시죠. #챗gpt #인공지능 #코딩 2017년, 1인 크리에이터의 프로젝트로 시작된 EO의 대표 시리즈, [리얼밸리

AI 시대 변화가 두려운 모든 분들에게 | 인스타그램 수석 개발자 알렉스

AI의 발달로 일자리가 없어지지 않느냐는 불안은 여러 직군에서 이야기가 나오고 있습니다. 특히, 저희 개발자들은 더욱더 그렇죠. 사실 개발을 잘 모르는 사람도 AI를 통해 그 어려운 개발도 손쉽게 할 수 있는 세상이 오다 보니 개발을 주 업으로 하고 있는 저희 개발자들 입장에서는 소위 "현타"가 올 정도니까요. 그렇지만 이러한 "위기"를 곧 "기회"로 삼는 분들이 꽤 많으신데요. 이번에 공유드리는 영상은 실리콘밸리 인스타그램 수석 엔지니어가 생각하는 AI 도구 즉, ChatGPT에 대해 어떻게 바라봐야 하는가에 대해 이야기를 하고 있습니다.

이 영상에서는 각자의 자원은 한정되어 있기에 내가 가진 자원으로 최대한의 성과를 내는 것이 중요하다고 이야기를 하고, 그에 ChatGPT는 상식을 깨는 매우 불규칙한 도구였으며, 현 시점에서 가장 강력한 리소스라고 생각한다고 합니다. 그 이유로 ChatGPT의 가장 혁신적인 부분은 생각을 표현하는 궁극적인 매개체인 언어를 모방한다는 점인데요. 시작의 부담과 길을 줄여줄 수 있는 도구가 좋은데, ChatGPT는 생각을 주입하는 방식으로 시작에 도움을 주고 있습니다. 궁극적으로 ChatGPT를 대체, 자동화, 새로운 가치 창출을 위한 리소스로 활용하는 방법에 대한 질문이 늘고 있죠. 도구를 주도함으로써 원하는 결과물을 얻을 수 있고, 그런 도구가 있으면 이전에는 불가능했던 일을 할 수 있다고 합니다.

저 또한 이 영상을 보기 전, 그러니까 ChatGPT가 세상에 본격적으로 나와 개발자들의 일자리가 없어진다는 말을 들을 때면 항상 "오히려 좋아"라는 생각을 했던 것 같습니다. 정통 자바 백엔드 개발자인 저로서 최근에 프론트 개발이라든지, Spark, Scala 등 전혀 경험해 보지 못한 영역에서 개발을 해야 하는 상황인데 이때 ChatGPT의 도움을 받아 개발을 하고 있죠. 여기서 중요한 점은 이러이러한 상황에서 코드를 만들어줘~라고 Q&A 하듯 물어만 보는 것에서 그치지 않고 왜 그러한 코드가 작성되었는지, 문법은 어떻고 어떤 의미를 가지는지 등 세부적으로 물어보며 ChatGPT가 제시하는 문맥 그 자체를 이해하려고 노력하려 합니다. 거의 과외 선생님인 샘이죠. 그렇게 ChatGPT를 활용해서 작성한 코드를 마지막엔 관련 개발에 경험이 풍부한 동료들과 함께 코드 리뷰를 하며 개발을 마무리하는 게 요즘의 일상 같습니다.

여러분들은 ChatGPT, AI를 어떻게 활용하고 계시나요? 단순 구글링 수준으로만 활용하신다면 모든 순간순간마다 AI를 도입하여 복잡하고 반복적인 부분들은 맡겨두고 더 중요한 본질에 대해 고민하는 시간을 할애하는데 집중하는 건 어떨까요? 아무리 AI가 날뛰어도 저희 개발자(사람)가 해야 하는 영역은 분명히 있다고 믿으니까요 ㅎ

https://www.youtube.com/watch?v=_drFaRrJxlQ

AI의 발달로 일자리가 없어지지 않느냐는 불안은 여러 직군에서 이야기가 나오고 있습니다. 특히, 저희 개발자들은 더욱더 그렇죠. 사실 개발을 잘 모르는 사람도 AI를 통해 그 어려운 개발도 손쉽게 할 수 있는 세상이 오다 보니 개발을 주 업으로 하고 있는 저희 개발자들 입장에서는 소위 "현타"가 올 정도니까요. 그렇지만 이러한 "위기"를 곧 "기회"로 삼는 분들이 꽤 많으신데요. 이번에 공유드리는 영상은 실리콘밸리&nbsp;인스타그램&nbsp;수석&nbsp;엔지니어가 생각하는 AI 도구 즉, ChatGPT에 대해 어떻게 바라봐야 하는가에 대해 이야기를 하고 있습니다. 이 영상에서는 각자의 자원은 한정되어 있기에 내가 가진 자원으로 최대한의 성과를 내는 것이 중요하다고 이야기를 하고, 그에 ChatGPT는 상식을 깨는 매우 불규칙한 도구였으며, 현 시점에서 가장 강력한 리소스라고 생각한다고 합니다. 그 이유로 ChatGPT의 가장 혁신적인 부분은 생각을 표현하는 궁극적인 매개체인 언어를 모방한다는 점인데요. 시작의 부담과 길을 줄여줄 수 있는 도구가 좋은데, ChatGPT는 생각을 주입하는 방식으로 시작에 도움을 주고 있습니다. 궁극적으로 ChatGPT를 대체, 자동화, 새로운 가치 창출을 위한 리소스로 활용하는 방법에 대한 질문이 늘고 있죠. 도구를 주도함으로써 원하는 결과물을 얻을 수 있고, 그런 도구가 있으면 이전에는 불가능했던 일을 할 수 있다고 합니다. 저 또한 이 영상을 보기 전, 그러니까 ChatGPT가 세상에 본격적으로 나와 개발자들의 일자리가 없어진다는 말을 들을 때면 항상 "오히려 좋아"라는 생각을 했던 것 같습니다. 정통 자바 백엔드 개발자인 저로서 최근에 프론트 개발이라든지, Spark, Scala 등 전혀 경험해 보지 못한 영역에서 개발을 해야 하는 상황인데 이때 ChatGPT의 도움을 받아 개발을 하고 있죠. 여기서 중요한 점은 이러이러한 상황에서 코드를 만들어줘~라고 Q&amp;A 하듯 물어만 보는 것에서 그치지 않고 왜 그러한 코드가 작성되었는지, 문법은 어떻고 어떤 의미를 가지는지 등 세부적으로 물어보며 ChatGPT가 제시하는 문맥 그 자체를 이해하려고 노력하려 합니다. 거의 과외 선생님인 샘이죠. 그렇게 ChatGPT를 활용해서 작성한 코드를 마지막엔 관련 개발에 경험이 풍부한 동료들과 함께 코드 리뷰를 하며 개발을 마무리하는 게 요즘의 일상 같습니다. 여러분들은 ChatGPT, AI를 어떻게 활용하고 계시나요? 단순 구글링 수준으로만 활용하신다면 모든 순간순간마다 AI를 도입하여 복잡하고 반복적인 부분들은 맡겨두고 더 중요한 본질에 대해 고민하는 시간을 할애하는데 집중하는 건 어떨까요? 아무리 AI가 날뛰어도 저희 개발자(사람)가 해야 하는 영역은 분명히 있다고 믿으니까요 ㅎ https://www.youtube.com/watch?v=_drFaRrJxlQ ﻿

AI 시대 변화가 두려운 모든 분들에게 | 인스타그램 수석 개발자

컴퓨터 전공이 아닌 👉문과👈 학생들의 결과물입니다. 부족한 면이 있지만 재밌게 감상 해 주세요. 악플은 🙅🏻‍♀️🫢🤗 재밌게 보신 결과물이 있다면 재게시나 좋아요도 해 주시면 감사하겠습니다. 🤗

팀플 소개 영상은 댓글에 있습니다.👇

컴퓨터 전공이 아닌 👉문과👈 학생들의 결과물입니다. 부족한 면이 있지만 재밌게 감상 해 주세요. 악플은 🙅🏻‍♀️🫢🤗 재밌게 보신 결과물이 있다면 재게시나 좋아요도 해 주시면 감사하겠습니다. 🤗 팀플 소개 영상은 댓글에 있습니다.👇

📽️ 서울대 웹프로그래밍 수업의 팀 프로젝트 소개

디자인시스템 래핑 후 1년 뒤..

디자인 시스템을 많은 회사에서 고려하지만, 함부로 도전하면 안된다고 생각합니다.
디자인 시스템 자체 개발은 많은 자원을 요구됩니다. 그렇지만 대게 없는 리소스로 일하다가 어떻게 생산성을 끌어올릴까 고민해서 시작하는 경우가 많습니다.

만드는게 문제가 아니라 그 이후에 유지보수 하느라 수많은 커뮤니케이션과 긴급 대응이 발생할 겁니다. 이걸 감당하기 쉽지 않습니다.
사업은 살아있는 생물같아서 강건너나 다른 나라, 혹은 우주로 날아가버리기도 합니다. 그러면 기존 디자인 요소로 따라가지 못하는 요소가 범람하고, 디자인시스템이 무용지물이 되기도 합니다.

글에서 범용적인 디자인 시스템을 래핑해서 커스텀하는 현실적인 조언을 합니다.

만약 누군가 조직 안에서 디자인시스템이란 말을 꺼냈다면, 문제가 디자인 시스템이 없어서 발생했는지 고민해봐야겠습니다.

https://velog.io/@pandati0710/스타트업의-현실적인-디자인시스템-제작-후-1년-뒤

디자인 시스템을 많은 회사에서 고려하지만, 함부로 도전하면 안된다고 생각합니다.디자인 시스템 자체 개발은 많은 자원을 요구됩니다. 그렇지만 대게 없는 리소스로 일하다가 어떻게 생산성을 끌어올릴까 고민해서 시작하는 경우가 많습니다. 만드는게 문제가 아니라 그 이후에 유지보수 하느라 수많은 커뮤니케이션과 긴급 대응이 발생할 겁니다. 이걸 감당하기 쉽지 않습니다.사업은 살아있는 생물같아서 강건너나 다른 나라, 혹은 우주로 날아가버리기도 합니다. 그러면 기존 디자인 요소로 따라가지 못하는 요소가 범람하고, 디자인시스템이 무용지물이 되기도 합니다. 글에서 범용적인 디자인 시스템을 래핑해서 커스텀하는 현실적인 조언을 합니다. 만약 누군가 조직 안에서 디자인시스템이란 말을 꺼냈다면, 문제가 디자인 시스템이 없어서 발생했는지 고민해봐야겠습니다. https://velog.io/@pandati0710/스타트업의-현실적인-디자인시스템-제작-후-1년-뒤

Velog

Documentation - TypeScript 5.5

TypeScript 5.5가 출시되었습니다. 주목해 볼만한 변경점을 정리해 보았습니다.

## 1. Inferred Type Predicates
함수가 반환할 타입을 좀 더 똑똑하게 추리합니다. 덕분에 불필요한 타입 단언 없이 타입을 좁힐 수 있게 되었습니다. 특히
filter
등의 함수에서 유용해보입니다.
type Item = string | number | null;

const items: Item[] = ["a", 1, null, "b", 2, null, "c"];
const nonNullItems = items.filter(item => item !== null);

// 5.5 미만: Item[]
// 5.5 이상: (string | number)
nonNullItems.forEach(item => console.log(item.toString()));
// 5.5 미만: .toString()에서 'item' is possibly 'null' 타입 에러 발생
// 5.5 이상: 오류 없음

## 2. tsconfig에
${configDir}
추가
TypeScript 5.5에 새로운 템플릿 변수
${configDir}
가 생겼습니다. 이 변수는
tsconfig.base.json
을 여러 컨피그에서
extends
로 확장하는 경우에 유용합니다. 특히 모노레포에서 유용할 것으로 보입니다.
{
 "compilerOptions": {
 "typeRoots": [
 "./node_modules/@types"
 "./custom-types"
 ],
 "outDir": "dist"
 }
}

위
tsconfig.base.json
을 아래와 같이 수정하면 어떻게 될까요?
{
 "compilerOptions": {
 "typeRoots": [
 "${configDir}/node_modules/@types"
 "${configDir}/custom-types"
 ],
 "outDir": "${configDir}/dist"
 }
}

이제 프로젝트에서 이 파일을 확장할 때, 경로의 기준이
tsconfig.base.json
파일이 아니라 파생된
tsconfig.json
에 상대적인 경로가 됩니다. 이렇게 하면 프로젝트 간에 컨피그 설정 공유가 더 쉬워집니다.

## 3. 정규식 문법 검사
이제 TypeScript가 정규식에 대해 기본적인 구문 검사를 수행합니다. 정규식은 특히 글자 하나 차이로 실수할 여지가 큰데, 실수 방지에 큰 도움이 될 것 같습니다.
let myRegex = /@robot(\s+(please|immediately)))? do some task/;\
// ~
// 오류!
// Unexpected ')'. Did you mean to escape it with backslash?

## 4. Control Flow Narrowing for Constant Indexed Accesses
이전에는
obj[key]
와 같은 형태로 객체의 속성에 접근할 때, TypeScript가 그 속성의 정확한 타입을 알아내기 어려웠습니다.
TypeScript 5.5에서는
obj
와
key
가 변경되지 않는 경우(즉, 상수로 취급될 수 있는 경우), 타입 체크 이후에 해당 속성의 타입을 더 구체적으로 좁힐 수 있게 되었습니다.
function f1(obj: Record<string, unknown>, key: string) {
 if (typeof obj[key] === "string") {
 // 이제 정상 동작, 이전에는 에러였음
 obj[key].toUpperCase();
 }
}

예제 코드는 객체나 키가 변하지 않으므로
typeof
검사 이후
obj[key]
타입을
string
으로 좁힐 수 있습니다.

## 5. 성능 향상
 * 벤치마크 결과, 빌드 시간이 5~8% 빨라지고 언어 서비스 작업 속도가 10~20% 빨라졌다고 합니다.
 * transpileModule
 API 성능이 2배 이상 빨라졌습니다.
 * TypeScript 패키지 크기가 33% 정도 감소했습니다.

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html

TypeScript 5.5가 출시되었습니다. 주목해 볼만한 변경점을 정리해 보았습니다. ## 1. Inferred Type Predicates함수가 반환할 타입을 좀 더 똑똑하게 추리합니다. 덕분에 불필요한 타입 단언 없이 타입을 좁힐 수 있게 되었습니다. 특히 <code >filter</code> 등의 함수에서 유용해보입니다.<pre ><code class="language-ts">type Item = string | number | null;

const items: Item[] = ["a", 1, null, "b", 2, null, "c"];
const nonNullItems = items.filter(item =&gt; item !== null);

// 5.5 미만: Item[]
// 5.5 이상: (string | number)
nonNullItems.forEach(item =&gt; console.log(item.toString()));
// 5.5 미만: .toString()에서 'item' is possibly 'null' 타입 에러 발생
// 5.5 이상: 오류 없음</code></pre> ## 2. tsconfig에 <code >${configDir}</code> 추가TypeScript 5.5에 새로운 템플릿 변수 <code >${configDir}</code>가 생겼습니다. 이 변수는 <code >tsconfig.base.json</code>을 여러 컨피그에서 <code >extends</code>로 확장하는 경우에 유용합니다. 특히 모노레포에서 유용할 것으로 보입니다.<pre ><code class="language-json">{
 "compilerOptions": {
 "typeRoots": [
 "./node_modules/@types"
 "./custom-types"
 ],
 "outDir": "dist"
 }
}</code></pre>위 <code >tsconfig.base.json</code>을 아래와 같이 수정하면 어떻게 될까요?<pre ><code class="language-json">{
 "compilerOptions": {
 "typeRoots": [
 "${configDir}/node_modules/@types"
 "${configDir}/custom-types"
 ],
 "outDir": "${configDir}/dist"
 }
}</code></pre>이제 프로젝트에서 이 파일을 확장할 때, 경로의 기준이 <code >tsconfig.base.json</code> 파일이 아니라 파생된 <code >tsconfig.json</code>에 상대적인 경로가 됩니다. 이렇게 하면 프로젝트 간에 컨피그 설정 공유가 더 쉬워집니다. ## 3. 정규식 문법 검사이제 TypeScript가 정규식에 대해 기본적인 구문 검사를 수행합니다. 정규식은 특히 글자 하나 차이로 실수할 여지가 큰데, 실수 방지에 큰 도움이 될 것 같습니다.<pre ><code class="language-ts">let myRegex = /@robot(\s+(please|immediately)))? do some task/;\
// ~
// 오류!
// Unexpected ')'. Did you mean to escape it with backslash?</code></pre> ## 4. Control Flow Narrowing for Constant Indexed Accesses이전에는 <code >obj[key]</code>와 같은 형태로 객체의 속성에 접근할 때, TypeScript가 그 속성의 정확한 타입을 알아내기 어려웠습니다.TypeScript 5.5에서는 <code >obj</code>와 <code >key</code>가 변경되지 않는 경우(즉, 상수로 취급될 수 있는 경우), 타입 체크 이후에 해당 속성의 타입을 더 구체적으로 좁힐 수 있게 되었습니다.<pre ><code class="language-ts">function f1(obj: Record&lt;string, unknown&gt;, key: string) {
 if (typeof obj[key] === "string") {
 // 이제 정상 동작, 이전에는 에러였음
 obj[key].toUpperCase();
 }
}</code></pre>예제 코드는 객체나 키가 변하지 않으므로 <code >typeof</code> 검사 이후 <code >obj[key]</code> 타입을 <code >string</code>으로 좁힐 수 있습니다. ## 5. 성능 향상<ul ><li>벤치마크 결과, 빌드 시간이 5~8% 빨라지고 언어 서비스 작업 속도가 10~20% 빨라졌다고 합니다.</li><li><code >transpileModule</code> API 성능이 2배 이상 빨라졌습니다.</li><li>TypeScript 패키지 크기가 33% 정도 감소했습니다.</li></ul> https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html

typescriptlang.org

TypeScript 5.5 릴리즈

✻ 강연 내용 : 'AI 시대' 속에 살고 계신 여러분, AI에 대해 생각하면 두려우십니까? 기대되십니까? 아니면 애써 외면하고 계십니까? AI는 어려운 것이 아니고 절대로 두려워 할 것도 아닙니다. ChatGPT가 나온지 이제 18개월, 우리도 충분히 이 AI시대를 누릴 수 있습니다. 보다 적극적인 AI 사피엔스로 살아갈 수 있는 방법을 여러분께 안내합니다 ✻ [책이벤트] 댓글로 강연의 소감평과 함께 자신의 이야기를 남겨주세요.

[책이벤트] 필수 시청! 당장 내일과 내 일을 위해 정말 중요한 이야기 | 최재붕 'AI 사피엔스'저자 w/ 구범준 PD | #자기계발 #성공 #ai | 세바시나머지45 ep.67

나의 커리어 과정에서 지금의 위치를 가능하게 만들었던 결정적 순간을 물으면 세 가지 중요 기점이 있다.

첫 번째, 디자인을 전공하겠다고 결정한 고등학교 1학년. (내가 뭘 좋아하고 하고 싶은지를 스스로 결정한 게 중요 포인트)
두 번째, 인터랙션 디자이너로 커리어를 결정한 대학교 3학년. (인터넷 초창기에 선발주자가 된 계기)
세 번째, 20대 후반에 미국 이주. (글로벌 기업으로 커리어를 확장할 수 있었던 발판)

놀라운 속도로 발전하고 쏟아져 나오는 AI 기술들을 보고 있자면, 내가 처음 컴퓨터그래픽과 인터넷이라는 기술을 접했던 30년 전이 떠오른다. 30년 전에 인터넷이 조용하게 시작됐지만 현대사회에 없어서는 안 될 기술 기반이 된 것처럼, 지금 역시 AI가 조용히 판도를 바꾸고 있는 시작점이다. 미디어에서 AI 얘기가 쏟아져 나오고 세상의 모든 돈이 블랙홀처럼 AI 기술 투자에 몰리고 있지만, 아직 1년 조금 넘은 지각 변동이다. 새롭게 누구나 진입할 수 있는 기회의 세상이 열렸다는 뜻이다. AI가 주는 기회가 보이는지, 기회를 내 것으로 만들 수 있는지가 관건. 누구에게나 동일하게 기회가 열렸다는 게 장점이고, 그래서 전 세계 사람들과 경쟁해야 한다는 게 단점이기도 하다.

[AI 공부를 지금 해야 하는 이유]

1) 선발 주자와 후발 주자의 차이
무언가 새롭게 시작되는 기술의 변화에서는 선발주자가 우위를 가지게 된다. 대부분의 사람들은 기존에 익숙한 방식, 그리고 자신이 이미 취득한 기술을 지키고 싶어 한다. 당장은 기존 방식으로 돈벌이가 가능하고 새로운 기술은 수요가 적거나 어렵게 느껴지기 쉽다. 하지만 30년 전, 컴퓨터나 인터넷 즉 디지털 전환이 대세가 될 기술이라는 게 보였던 사람들은 일찍 시작해서 선발 주자가 될 수 있었고, 소위 “전문가"라는 칭호를 쉽게 얻는 혜택을 누렸다. 그때는 포토샵을 쓸 줄 안다는 것만으로, 엑셀을 쓸 줄 안다는 것만으로, 웹 코딩을 할 줄 안다는 것만으로 취업이 되던 시절이었다.

기술 전환의 초입은 누가 먼저 시작했느냐 자체로 얻는 혜택이 크다. AI가 바로 그 전환의 초입에 있다. 새로운 기술이 시작될 때는, 그걸 할 줄 안다는 것만으로 대우를 받는다. 써봤다는 것 자체로 할 줄 안다고 인정받는 골든 타임이 바로 지금이다.

2) 전문가와 비전문가의 차이
기존 전문 소프트웨어와 생성형 AI의 차이가 무엇일까. 터치 UI 방식의 기존 소프트웨어는 주어진 기능을 활용한다. 포토샵을 예를 들자면, 새 파일 만드는 메뉴를 눌러서, 보여주는 메뉴에서 캔버스의 크기를 정해주고, 포토샵에서 제공되는 레이어, 채널, 브러시, 필터 등등의 기능들을 조합해서 내가 원하는 걸 만들어 내는 방식이다. 적어도 포토샵을 쓸 줄 안다는 지식의 영역에서는 주어진 기능을 벗어나지 않는 범주이다.

하지만 생성형 AI는? 사용자에게 주어지는 건 명령어 창(프롬프트) 하나이다. 이 흰 도화지 같은 텍스트 필드에 내가 원하는 걸 명령하는 방식이다. 프롬프트를 어떻게 작성하는지에 따라 AI 답변이 달라지기 때문에 프롬프트를 활용하는 능력이 전문가와 비전문가의 실력을 나누게 되고, 똑같은 AI 툴을 사용하더라도 완전히 다른 툴을 사용하는 효과를 만든다. AI 가 지금보다 더 진화해서 더 자연스럽게 인간과 대화를 나눌 수 있게 된다면, 대화를 잘하는 능력이 AI 전문가의 주요 역량이 될 것이다. 아이러니하게도, 말하기와 쓰기 능력이 AI 시대에 더욱 중요해지는 이유이다.

3) 아는 사람과 해본 사람의 차이
늘 강조하지만 해보지 않은 건 아는 게 아니다. AI 관련 책 열 권을 읽는 것보다 직접 프롬프트 한 개를 넣어보는 게 훨씬 좋은 방법이다. 변하는 속도가 워낙 빠르고 어떻게 사용하는지에 따라 다른 결과물을 만들 수 있기 때문에, 정보 업데이트가 빠른 온라인을 활용하는 걸 추천한다. 특히 유튜브에 수많은 AI 기능 따라 하기 영상들이 있는데, 직접 보고 따라 해보는 게 가장 쉽고 좋은 접근 방식이다. 따라 하다 보면 응용 아이디어가 떠오르고, 조금만 다르게 응용해도 완전히 다른 결과물을 얻을 수 있기 때문에 바로 나만의 노하우로 발전시킬 수 있다. 새로운 노하우를 얻었다면 널리 공유하길 권한다. 이제는 아는 걸 나만 알고 있는 게 경쟁력이 아니라, 아는 걸 오픈해서 다른 사람들과 더 크게 키울 줄 아는 게 경쟁력이다.

추가하고 싶은 말,
지금은 AI 기술 초입이기 때문에 일찍 써본 사람이 앞서 나갈 수 있는 골든 타임이지만, 모든 새로운 기술은 평준화 단계를 거치게 되고 그 이후는 결국 사람, 즉 각자의 역량이 중요해진다. 내가 가진 (AI를 부릴 수 있는) 생각 능력, (AI의 아웃풋을 보고) 좋고 나쁨을 선택할 수 있는 판단력 그리고 발전시킬 수 있는 창의력, 나의 취향, 나만의 색깔, 나의 안목 같은 게 결국은 나의 코어 핵심 역량이다. 나의 코어 역량을 키우지 않으면 껍데기 AI 기술자가 된다는 걸 잊지 말 것.

---
세바시 영상 [당장 내일과 내 일을 위해 정말 중요한 이야기 | 최재붕 ‘AI 사피엔스‘저자 w/ 구범준 PD] 영상을 보고 영감을 얻어 씀. 추천 영상.

https://www.youtube.com/watch?v=CKXJTzuLoww

나의 커리어 과정에서 지금의 위치를 가능하게 만들었던 결정적 순간을 물으면 세 가지 중요 기점이 있다.​첫 번째, 디자인을 전공하겠다고 결정한 고등학교 1학년. (내가 뭘 좋아하고 하고 싶은지를 스스로 결정한 게 중요 포인트)두 번째, 인터랙션 디자이너로 커리어를 결정한 대학교 3학년. (인터넷 초창기에 선발주자가 된 계기)세 번째, 20대 후반에 미국 이주. (글로벌 기업으로 커리어를 확장할 수 있었던 발판)​놀라운 속도로 발전하고 쏟아져 나오는 AI 기술들을 보고 있자면, 내가 처음 컴퓨터그래픽과 인터넷이라는 기술을 접했던 30년 전이 떠오른다. 30년 전에 인터넷이 조용하게 시작됐지만 현대사회에 없어서는 안 될 기술 기반이 된 것처럼, 지금 역시 AI가 조용히 판도를 바꾸고 있는 시작점이다. 미디어에서 AI 얘기가 쏟아져 나오고 세상의 모든 돈이 블랙홀처럼 AI 기술 투자에 몰리고 있지만, 아직 1년 조금 넘은 지각 변동이다. 새롭게 누구나 진입할 수 있는 기회의 세상이 열렸다는 뜻이다. AI가 주는 기회가 보이는지, 기회를 내 것으로 만들 수 있는지가 관건. 누구에게나 동일하게 기회가 열렸다는 게 장점이고, 그래서 전 세계 사람들과 경쟁해야 한다는 게 단점이기도 하다.​[AI 공부를 지금 해야 하는 이유]​1) 선발 주자와 후발 주자의 차이무언가 새롭게 시작되는 기술의 변화에서는 선발주자가 우위를 가지게 된다. 대부분의 사람들은 기존에 익숙한 방식, 그리고 자신이 이미 취득한 기술을 지키고 싶어 한다. 당장은 기존 방식으로 돈벌이가 가능하고 새로운 기술은 수요가 적거나 어렵게 느껴지기 쉽다. 하지만 30년 전, 컴퓨터나 인터넷 즉 디지털 전환이 대세가 될 기술이라는 게 보였던 사람들은 일찍 시작해서 선발 주자가 될 수 있었고, 소위 “전문가"라는 칭호를 쉽게 얻는 혜택을 누렸다. 그때는 포토샵을 쓸 줄 안다는 것만으로, 엑셀을 쓸 줄 안다는 것만으로, 웹 코딩을 할 줄 안다는 것만으로 취업이 되던 시절이었다.​기술 전환의 초입은 누가 먼저 시작했느냐 자체로 얻는 혜택이 크다. AI가 바로 그 전환의 초입에 있다. 새로운 기술이 시작될 때는, 그걸 할 줄 안다는 것만으로 대우를 받는다. 써봤다는 것 자체로 할 줄 안다고 인정받는 골든 타임이 바로 지금이다. 2) 전문가와 비전문가의 차이기존 전문 소프트웨어와 생성형 AI의 차이가 무엇일까. 터치 UI 방식의 기존 소프트웨어는 주어진 기능을 활용한다. 포토샵을 예를 들자면, 새 파일 만드는 메뉴를 눌러서, 보여주는 메뉴에서 캔버스의 크기를 정해주고, 포토샵에서 제공되는 레이어, 채널, 브러시, 필터 등등의 기능들을 조합해서 내가 원하는 걸 만들어 내는 방식이다. 적어도 포토샵을 쓸 줄 안다는 지식의 영역에서는 주어진 기능을 벗어나지 않는 범주이다.​하지만 생성형 AI는? 사용자에게 주어지는 건 명령어 창(프롬프트) 하나이다. 이 흰 도화지 같은 텍스트 필드에 내가 원하는 걸 명령하는 방식이다. 프롬프트를 어떻게 작성하는지에 따라 AI 답변이 달라지기 때문에 프롬프트를 활용하는 능력이 전문가와 비전문가의 실력을 나누게 되고, 똑같은 AI 툴을 사용하더라도 완전히 다른 툴을 사용하는 효과를 만든다. AI 가 지금보다 더 진화해서 더 자연스럽게 인간과 대화를 나눌 수 있게 된다면, 대화를 잘하는 능력이 AI 전문가의 주요 역량이 될 것이다. 아이러니하게도, 말하기와 쓰기 능력이 AI 시대에 더욱 중요해지는 이유이다. 3) 아는 사람과 해본 사람의 차이늘 강조하지만 해보지 않은 건 아는 게 아니다. AI 관련 책 열 권을 읽는 것보다 직접 프롬프트 한 개를 넣어보는 게 훨씬 좋은 방법이다. 변하는 속도가 워낙 빠르고 어떻게 사용하는지에 따라 다른 결과물을 만들 수 있기 때문에, 정보 업데이트가 빠른 온라인을 활용하는 걸 추천한다. 특히 유튜브에 수많은 AI 기능 따라 하기 영상들이 있는데, 직접 보고 따라 해보는 게 가장 쉽고 좋은 접근 방식이다. 따라 하다 보면 응용 아이디어가 떠오르고, 조금만 다르게 응용해도 완전히 다른 결과물을 얻을 수 있기 때문에 바로 나만의 노하우로 발전시킬 수 있다. 새로운 노하우를 얻었다면 널리 공유하길 권한다. 이제는 아는 걸 나만 알고 있는 게 경쟁력이 아니라, 아는 걸 오픈해서 다른 사람들과 더 크게 키울 줄 아는 게 경쟁력이다.​추가하고 싶은 말,지금은 AI 기술 초입이기 때문에 일찍 써본 사람이 앞서 나갈 수 있는 골든 타임이지만, 모든 새로운 기술은 평준화 단계를 거치게 되고 그 이후는 결국 사람, 즉 각자의 역량이 중요해진다. 내가 가진 (AI를 부릴 수 있는) 생각 능력, (AI의 아웃풋을 보고) 좋고 나쁨을 선택할 수 있는 판단력 그리고 발전시킬 수 있는 창의력, 나의 취향, 나만의 색깔, 나의 안목 같은 게 결국은 나의 코어 핵심 역량이다. 나의 코어 역량을 키우지 않으면 껍데기 AI 기술자가 된다는 걸 잊지 말 것.​---세바시 영상 [당장 내일과 내 일을 위해 정말 중요한 이야기 | 최재붕 ‘AI 사피엔스‘저자 w/ 구범준 PD] 영상을 보고 영감을 얻어 씀. 추천 영상.​https://www.youtube.com/watch?v=CKXJTzuLoww

AI 공부를 지금 해야 하는 이유

백엔드 엔지니어

권주성

피닉스다트 웹 서버 개발자

김대호

#백엔드 #개발자 #커뮤니케이션

데이터 분석

Technical Lead

1) 자금운용시스템 개발 및 운영 (2014. 02 ~ 2019.09) 
 - 삼성전자 재경팀 자금그룹의 자금 유동성 및 현금흐름 실시간 파악을 위한 거래내역 실시간 관리(SAP RFC 호출을 통해 ERP 데이터 송수신 I/F), 금융 Risk 조기대응을 위한 각종 금융/경제지표(Bloomberg(미국미디어기업)로부터 Daily I/F) 조회를 위한 삼성전자 자금 정보 조회 시스템
- 자금운용시스템-중국공상은행 전문 인터페이스 개발 (2015. 04 ~ 2015.07) 
- 시스템 DB(Oracle > PostgreSQL(PPAS)) 전환 (2016. 09 ~ 2017.01)
- 시스템 on-premise > PaaS 전환 (2018. 08 ~ 2018.12)
2) 공시통합관리시스템 개발 및 운영 (2014. 02 ~ 2019.09) 
 - 삼성전자 표준개발플랫폼(SDP)과 Java, JSP, HTML을 활용하여 공시유발 가능 사건 발생 사전 감지 및 공시대상 여부 판단의 효율화하는 시스템
- 공시통합관리시스템 on-premise > PaaS 전환 (2018. 08 ~ 2018.12)
3) 대규모기업집단공시현황시스템 개발 및 운영 (2016. 03 ~ 2019.09) 
 - .NET, SharePoint 솔루션을 활용하여 삼성그룹 관계사의 대표회사로서 삼성전자가 수행하는 대규모 기업집단현황 공시 작업에 따른 프로세스 및 체계적으로 관리하고 공시 자료의 정확성을 유지하기 위한 시스템
4) ITSM&ITIL 관리 (2015. 03 ~ 2019.09)
- 삼성SDS 전사 ITSM T/F에 소속되어 IT 운영 성과 관리 기획 및 운영
- Global ERP 의 ITSM 운영 업무


선임

1) 통합로그시스템 개발 및 운영 (2019. 09 ~ 2021.06, 2020년 하반기 신규 구축)
 - 전자금융감독규정, 신용정보법 시행령 및 감독규정, 개인정보보호법 및 시행령, 정보통신망법 및 시행령에 의거, 정보처리시스템의 가동 기록과 단말기 접속에 관한 기록 및 정보보안로그, 시스템로그 등을 자동으로 기록하고 보관하는 통합로그시스템
 - 구축 당시보다 늘어난 로그 양에 따라 업무 지원 지연을 줄이고, 디지털 혁신 추진을 통해 기존 활용하지 않던 로그를 분석하여 새로운 인사이트 도출을 위해 데이터 분석이 가능한 통합로그 시스템 신규 구축 (2020년 하반기)
데이터 분석이 가능한 통합로그 시스템 신규 구축 프로젝트 상세 내용
- 데이터 분석 플랫폼 구축 프로젝트 수행 (PM) 및 Growth 전략 수립
- 전사 데이터 분석을 목적으로 한 시스템 설계, 실시간 대시보드 구축 및 관리
- 기존 5년 데이터 마이그레이션 및 분석을 통한 Growth 전략 수립
- 고객 편의성 향상을 위한 고객 로그 데이터 분석, AB테스트를 통한 UX/UI개선
2) 이상금융탐지시스템 개발 및 운영 (2019. 09 ~ 2021.06) 
 - 전자금융거래 시 단말기 정보와 접속 정보, 거래 정보 등을 수집하고 분석해 의심스러운 거래를 실시간으로 탐지한 후 이를 차단하는 시스템
 - 다양하게 변화하는 사기방법을 탐지하기 위해 개인화 데이터를 활용한 시계열 비지도 학습 탐지 기능과 사고를 예측하기 위한 지도 학습 예측 기능 추가 (2020년 상반기)


1) 카카오워크 산업 패키지 기획 (2022.01~2022.06)
- 중대재해처벌법 관련 건설산업 전용 패키지 기획
2) 카카오워크 플랫폼 기획 (2021.12~2022.06)
 - 3rd party solution을 위한 봇 플랫폼 / 마켓플레이스 기획
 - 카카오워크 데이터 분석 및 대시보드 기획/설계/운영
- 서비스 개발 우선순위 선정을 위한 프로세스 수립
3) 카카오워크 에코플랫폼 확장 및 지원 (2021.06~2022.03)
 - 서비스 파트너 앱 기술 지원 및 가이드 도구 작성
 - 확장서비스 내 파트너의 계약 및 서비스 기획
 - 앱(3rd party solution, service) 리서치
4) 사내 기술 교육 진행
- 서비스 기획자를 위한 기초 기술 교육 진행
- 데이터 분석 교육 진행


Product Manager

1) 네이버쇼핑 BI
 - BI 데이터 분석 환경 고도화
 - 네이버쇼핑 KR BI시스템 개발 및 운영
 - 네이버쇼핑 JP(My SmartStore) BI 시스템 개발 및 운영
 - 데이터 분석 (성과관리, CRM, 모델링 등)
2) Commerce Data Platform T/F 
 - 네이버쇼핑 레이크하우스 정책 수립
- ODS > DW > DataMart > Summary 데이터 설계
3) 사내 데이터 교육

Data Analyst

2013 산업경영시스템학회 논문 최우수상

산업공학 학사

이장근

LinkedIn

세상을 탐구하고 고민하며 알아갑니다. 개발, PM, 데이터분석 경험을 바탕으로 많은 이야기를 나누고 싶습니다. 🤔

토스에서 말하는 '가독성 좋은 코드'

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필