As an engineering manager I’ve had the privilege of promoting engineers on my team and offering people their first role in tech. It’s one…

From Hired!… to Fired! Avoid these 2 Developer Career Death Traps

이번 글에서는 사람들이 해고되는 가장 흔한 두 가지 이유와 이를 피하는 방법에 대해 살펴보겠습니다.

1단계: 목표를 명확히 설정하기
개발자가 해고되는 가장 일반적인 이유는 기대치 불일치 때문입니다.
 * 90일 계획 없음
 * 매니저 피드백 없음
 * 본인은 잘하고 있다고 생각하지만 팀원들은 답답해함
 * 그리고 갑작스러운 해고 통보
본인에게는 '갑자기'일지 모르지만, 팀원들에게는 그렇지 않습니다.
대부분의 매니저는 일부러 피드백을 주지 않는 것이 아닙니다. 사람들은 본능적으로 갈등을 피하려 합니다.

그러므로 첫 출근 날부터 팀 리드나 매니저와 실질적인 목표를 설정하는 것이 중요합니다.
특히, 첫 1~2개월 동안 성공의 기준을 정리해야 합니다. 만약 매니저가 명확한 계획을 제공하지 않는다면, 스스로 계획을 세워 공유해야 합니다.

예를 들어, 주니어 개발자라면 다음과 같이 설정할 수 있습니다.
 * 1~30일
   * 로컬 환경에서 모든 레포지토리를 실행
   * 코드 리뷰 및 배포 프로세스 이해
   * 적어도 2개의 작은 기능을 프로덕션에 배포
 * 30~60일
   * 온콜(On-call) 로테이션 참여
   * 주요 장애 대응 프로세스 학습
   * 소프트웨어 개발 라이프사이클 이해
   * 작은 버그를 혼자 해결
 * 60~90일
   * 중급 난이도의 기능 개발 및 배포
   * 기술적 논의에 기여
이렇게 하면 '눈치 게임'을 할 필요 없이, 본인의 성장 수준을 명확히 파악할 수 있습니다.

2단계: 본인의 성과를 알리기
일부 조직에서는 매니저가 모든 엔지니어와 직접 소통하지 않습니다.
그 결과, 관리자는 본인을 잘못된 기준으로 평가할 수 있습니다.
예를 들어, 코드 라인 수나 버그 수정 개수 같은 무의미한 지표로 평가받을 수도 있습니다.

그렇다면 어떻게 해야 할까요?

👉 본인의 성과를 자연스럽게 알리는 방법을 배워야 합니다. "자랑"하지 말고, "교육"해야 합니다.
 * 중요한 문제를 해결했나요?
   → 해결 방법을 문서화하고, 간단한 발표를 통해 공유하기
 * 새로운 기능을 출시했나요?
   → 다음 회의에서 직접 데모를 진행하기
마지막으로, 본인이 한 모든 중요한 작업을 기록해 두는 것이 중요합니다.

이렇게 하면 연말 평가 때 본인의 가치를 쉽게 증명할 수 있습니다. 이제 당신은 "그 사람 누구였더라?"가 아니라 "그 팀에서 중요한 엔지니어"로 기억될 것입니다.

당신의 성공을 바랍니다
이 글을 읽고 있다면, 아마 개발자로서 커리어를 시작한 지 얼마 되지 않았을 것입니다.

저는 수많은 실수를 했지만, 다행히도 해고당하지 않았습니다. 하지만 이번에 다룬 두 가지 교훈을 배우기까지 4년이 걸렸습니다.

제 목표는 단순히 해고를 피하는 것이 아닙니다.

기술적으로 성장하고, 회사 내에서 돋보이며, 만약 해고당하더라도 빠르게 새로운 기회를 잡을 수 있는 개발자가 되는 것입니다.

첫 취업이 끝은 아닙니다. 진짜 중요한 것은 그 이후입니다.

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

이번 글에서는 사람들이 해고되는 가장 흔한 두 가지 이유와 이를 피하는 방법에 대해 살펴보겠습니다. 1단계: 목표를 명확히 설정하기개발자가 해고되는 가장 일반적인 이유는 기대치 불일치 때문입니다.<ul><li>90일 계획 없음</li><li>매니저 피드백 없음</li><li>본인은 잘하고 있다고 생각하지만 팀원들은 답답해함</li><li>그리고 갑작스러운 해고 통보</li></ul>본인에게는 '갑자기'일지 모르지만, 팀원들에게는 그렇지 않습니다.대부분의 매니저는 일부러 피드백을 주지 않는 것이 아닙니다. 사람들은 본능적으로 갈등을 피하려 합니다. 그러므로 첫 출근 날부터 팀 리드나 매니저와 실질적인 목표를 설정하는 것이 중요합니다.특히, 첫 1~2개월 동안 성공의 기준을 정리해야 합니다. 만약 매니저가 명확한 계획을 제공하지 않는다면, 스스로 계획을 세워 공유해야 합니다. 예를 들어, 주니어 개발자라면 다음과 같이 설정할 수 있습니다.<ul><li>1~30일<ul><li>로컬 환경에서 모든 레포지토리를 실행</li><li>코드 리뷰 및 배포 프로세스 이해</li><li>적어도 2개의 작은 기능을 프로덕션에 배포</li></ul></li><li>30~60일<ul><li>온콜(On-call) 로테이션 참여</li><li>주요 장애 대응 프로세스 학습</li><li>소프트웨어 개발 라이프사이클 이해</li><li>작은 버그를 혼자 해결</li></ul></li><li>60~90일<ul><li>중급 난이도의 기능 개발 및 배포</li><li>기술적 논의에 기여</li></ul></li></ul>이렇게 하면 '눈치 게임'을 할 필요 없이, 본인의 성장 수준을 명확히 파악할 수 있습니다. 2단계: 본인의 성과를 알리기일부 조직에서는 매니저가 모든 엔지니어와 직접 소통하지 않습니다. 그 결과, 관리자는 본인을 잘못된 기준으로 평가할 수 있습니다. 예를 들어, 코드 라인 수나 버그 수정 개수 같은 무의미한 지표로 평가받을 수도 있습니다. 그렇다면 어떻게 해야 할까요? 👉 본인의 성과를 자연스럽게 알리는 방법을 배워야 합니다. "자랑"하지 말고, "교육"해야 합니다.<ul><li>중요한 문제를 해결했나요? → 해결 방법을 문서화하고, 간단한 발표를 통해 공유하기</li><li>새로운 기능을 출시했나요? → 다음 회의에서 직접 데모를 진행하기</li></ul>마지막으로, 본인이 한 모든 중요한 작업을 기록해 두는 것이 중요합니다. 이렇게 하면 연말 평가 때 본인의 가치를 쉽게 증명할 수 있습니다. 이제 당신은 "그 사람 누구였더라?"가 아니라 "그 팀에서 중요한 엔지니어"로 기억될 것입니다. 당신의 성공을 바랍니다이 글을 읽고 있다면, 아마 개발자로서 커리어를 시작한 지 얼마 되지 않았을 것입니다. 저는 수많은 실수를 했지만, 다행히도 해고당하지 않았습니다. 하지만 이번에 다룬 두 가지 교훈을 배우기까지 4년이 걸렸습니다. 제 목표는 단순히 해고를 피하는 것이 아닙니다. 기술적으로 성장하고, 회사 내에서 돋보이며, 만약 해고당하더라도 빠르게 새로운 기회를 잡을 수 있는 개발자가 되는 것입니다. 첫 취업이 끝은 아닙니다. 진짜 중요한 것은 그 이후입니다. 번역: [https://ducktopia.tistory.com/m/144]원문:

Medium

[Medium] 개발자로서 살아남기: 해고를 피하는 두 가지 방법

좋은 글 감사합니다.
이번에 이직해서 딱 30일 되었는데 운좋게도 이끌어주시는 사수분을 만나서 잘 적응하는 중입니다.
혼자서 해보고싶어도 뭐부터해야하나 막막했는데 가이드대로 하다보면 가지뻗기처럼 쭉쭉 뻗어나갈 수 있기를 기대하면서 우선은 해봐야겠습니다
감사합니다!

숫자로 보는 책 경매 서비스 회고

Cursor로 한시간 반만에 만든 책 경매 서비스 - Blog by Jason Kang

지난주에 올렸던 책 경매사이트 회고글입니다.

이걸 만들려고 결심한 건, 알라딘 중고서점에 팔려다가 RealMySQL 8.0이 3천원이길래, "이 좋은책을 3천원에 판다는건 말이 안된다" 라는 생각에 시작했어요.

이 글은 “누구나 Cursor를 활용하면 한시간안에 앱을 개발할 수 있다”는 내용은 아닙니다. 저는 플러터에 contribution 이력이 있을 정도로 플러터가 익숙하기 때문에 LLM을 어떻게 활용할지 잘 알아서 빠른 시간내에 개발이 가능했다고 생각합니다.

지난 5일간 전세계 8개국에서 700명 가까이 찾아주신 서비스 회고를 확인해주세요 😂

https://jasonkang14.github.io/llm/building-an-auction-service-to-sell-books-with-cursor

지난주에 올렸던 책 경매사이트 회고글입니다. 이걸 만들려고 결심한 건, 알라딘 중고서점에 팔려다가 RealMySQL 8.0이 3천원이길래, "이 좋은책을 3천원에 판다는건 말이 안된다" 라는 생각에 시작했어요. 이 글은 “누구나 Cursor를 활용하면 한시간안에 앱을 개발할 수 있다”는 내용은 아닙니다. 저는 플러터에 contribution 이력이 있을 정도로 플러터가 익숙하기 때문에 LLM을 어떻게 활용할지 잘 알아서 빠른 시간내에 개발이 가능했다고 생각합니다. 지난 5일간 전세계 8개국에서 700명 가까이 찾아주신 서비스 회고를 확인해주세요 😂 https://jasonkang14.github.io/llm/building-an-auction-service-to-sell-books-with-cursor

jasonkang14.github.io

한시간 반만에 Cursor로 만든 개발서적 경매서비스 후기

그동안 안드로이드를 너무 팽개쳐둔 것 같아서 4년 만에 다시 안드로이드로 돌아왔습니다. 알람 정리를 아직 못해서인지 새벽에 알람 소리에 잠이 깨버리고 말았습니다. 새벽에 알람 소리에 깨긴 오랜만이었습니다.

장애 알림은 서버 개발자의 숙명

그동안 안드로이드를 너무 팽개쳐둔 것 같아서 4년 만에 다시 안드로이드로 돌아왔습니다.
알람 정리를 아직 못해서인지 새벽에 알람 소리에 잠이 깨버리고 말았습니다.
새벽에 알람 소리에 깨긴 오랜만이었습니다.

카톡 서버팀에서 일할 때는 자주 이런 일이 있었습니다.
핸드폰 알람을 무음이나 진동으로 해두지 않고 항상 소리로 해두었습니다.
저만 그랬던 것이 아니라 서버팀 동료들 대부분이 그랬던 것 같습니다.
그래서 사무실에 있을 때 장애가 나면 사방에서 카톡카톡카톡카톡 소리가 들렸습니다.
(다른 회사 사람들이 와서 이 장면을 본다면 기이한 느낌이 들 것 같습니다)

장애 알림은 시도 때도 없이 발생했습니다.
시스템 전체가 다운돼서 사람들에게 알려지는 일은 흔치 않지만…
내부적으로는 계속 문제가 생기고 고쳐나가면서 살고 있는 것입니다.

문제를 곧바로 감지해서 해결하는 사람들을 보면 멋지다고 생각하기도 했습니다.
저도 그런 사람이 되고 싶었습니다. 가장 빨리 발견하고 가장 빨리 해결하는 사람.
하지만 그렇게 하려면 항상 긴장하고 있어야 했습니다.
긴장을 잠시만 풀어버려도 알림을 놓치고 반응이 늦기 일쑤였거든요.
한바탕 휘몰아치고 상황이 끝났는데 장애가 났었는지도 모르고 있었던 경우도 있습니다.
동료들이 다 해결하고 나는 얼간이처럼 띵가띵가 놀고 있었다고?
얼마나 쪽팔리고 미안하겠습니까?

장애는 새벽 시간에도 생기곤 했습니다.
나는 편하게 잠 좀 자고 싶은데. 그렇다고 알림을 꺼놓고 잘 수도 없고.
지금 생각하면 참 고역이었습니다.

알림에 반응이 느린 사람들도 간혹 있었습니다.
이를 답답하게 느끼기도 했습니다만… 이제는 저도 가정을 갖고 아이를 키우면서 이해할 수 있게 됐습니다.
무음 모드라는 것이 얼마나 소중한지 알게 되었거든요.

저도 이제는 핸드폰을 수면 모드로 해놓고 잠이 듭니다.
수면 모드라니… 예전 같으면 이게 말이나 되나 하고 생각했텐데.
편하게 잘 수 있다는 것에 새삼 감사한 마음이 듭니다.

얼마 전 카톡방에서 예전 서버팀 동료들과 대화를 하다가…
반응 속도가 다들 여전히 빠른 걸 보고 혼자 웃었습니다.
(잔잔한 채팅방에 메시지 하나 보내면 곧장 읽음 표시 숫자가 타다다닥 내려갑니다)
내 메시지를 빨리 확인해 주고 반응해 주는 동료들이 있으면 일할 맛이 나긴 합니다.
그런 동료들과 일해서 더 재밌게 일했던 것 같습니다.

https://jeho.page/essay/2025/02/06/failure-notifications-and-server-developer.html

그동안 안드로이드를 너무 팽개쳐둔 것 같아서 4년 만에 다시 안드로이드로 돌아왔습니다. 알람 정리를 아직 못해서인지 새벽에 알람 소리에 잠이 깨버리고 말았습니다. 새벽에 알람 소리에 깨긴 오랜만이었습니다. 카톡 서버팀에서 일할 때는 자주 이런 일이 있었습니다. 핸드폰 알람을 무음이나 진동으로 해두지 않고 항상 소리로 해두었습니다. 저만 그랬던 것이 아니라 서버팀 동료들 대부분이 그랬던 것 같습니다. 그래서 사무실에 있을 때 장애가 나면 사방에서 카톡카톡카톡카톡 소리가 들렸습니다. (다른 회사 사람들이 와서 이 장면을 본다면 기이한 느낌이 들 것 같습니다) 장애 알림은 시도 때도 없이 발생했습니다. 시스템 전체가 다운돼서 사람들에게 알려지는 일은 흔치 않지만… 내부적으로는 계속 문제가 생기고 고쳐나가면서 살고 있는 것입니다. 문제를 곧바로 감지해서 해결하는 사람들을 보면 멋지다고 생각하기도 했습니다. 저도 그런 사람이 되고 싶었습니다. 가장 빨리 발견하고 가장 빨리 해결하는 사람. 하지만 그렇게 하려면 항상 긴장하고 있어야 했습니다. 긴장을 잠시만 풀어버려도 알림을 놓치고 반응이 늦기 일쑤였거든요. 한바탕 휘몰아치고 상황이 끝났는데 장애가 났었는지도 모르고 있었던 경우도 있습니다. 동료들이 다 해결하고 나는 얼간이처럼 띵가띵가 놀고 있었다고? 얼마나 쪽팔리고 미안하겠습니까? 장애는 새벽 시간에도 생기곤 했습니다. 나는 편하게 잠 좀 자고 싶은데. 그렇다고 알림을 꺼놓고 잘 수도 없고. 지금 생각하면 참 고역이었습니다. 알림에 반응이 느린 사람들도 간혹 있었습니다. 이를 답답하게 느끼기도 했습니다만… 이제는 저도 가정을 갖고 아이를 키우면서 이해할 수 있게 됐습니다. 무음 모드라는 것이 얼마나 소중한지 알게 되었거든요. 저도 이제는 핸드폰을 수면 모드로 해놓고 잠이 듭니다. 수면 모드라니… 예전 같으면 이게 말이나 되나 하고 생각했텐데. 편하게 잘 수 있다는 것에 새삼 감사한 마음이 듭니다. 얼마 전 카톡방에서 예전 서버팀 동료들과 대화를 하다가… 반응 속도가 다들 여전히 빠른 걸 보고 혼자 웃었습니다. (잔잔한 채팅방에 메시지 하나 보내면 곧장 읽음 표시 숫자가 타다다닥 내려갑니다) 내 메시지를 빨리 확인해 주고 반응해 주는 동료들이 있으면 일할 맛이 나긴 합니다. 그런 동료들과 일해서 더 재밌게 일했던 것 같습니다. https://jeho.page/essay/2025/02/06/failure-notifications-and-server-developer.html

K리그 프로그래머

장애 알림과 서버 개발자

Availability is critical to the user experience...

5 Strategies for High-Availability Systems

고가용성(high availability, HA)의 사전적 정의는 서버, 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질을 말합니다. 예컨대, 어떤 일이 있어도(IDC가 정전이 나도, 로직이 잘못되어 무한 루프에 빠져도) 운영하는 서비스의 장애를 사용자가 못 느끼도록 하는 상황을 말하는데요. 서비스의 복잡도와 사용자의 규모가 점점 늘어남에 따라 고가용성은 더욱 중요해지는 것 같습니다. 간혹, 기능 개발에만 신경 쓰며 "구현"만 하고 그다음은 생각 안 하는 경우가 있는데 이 글에서 이야기하는 다섯 가지 전략 측면이라도 살펴보면 좋을 것 같아 공유합니다.
1. 로드 밸런싱(Load Balancing, LB)
2. 격리를 통한 데이터 복제(Data Redundancy
3. 장애 조치(Failover)
4. 오토 스케일링(Auto scailing)
5. Rate Limiting(호출 제한)

각자 구현의 방식은 상황이나 환경에 따라 달라질 수는 있겠지만 개념을 숙지하고 있다가 서비스를 출시하거나 운영하는 상황에서 적용해 봐도 좋을 것 같네요.

https://newsletter.systemdesigncodex.com/p/5-strategies-for-high-availability

고가용성(high&nbsp;availability,&nbsp;HA)의 사전적 정의는&nbsp;서버,&nbsp;네트워크,&nbsp;프로그램&nbsp;등의&nbsp;정보&nbsp;시스템이&nbsp;상당히&nbsp;오랜&nbsp;기간&nbsp;동안&nbsp;지속적으로&nbsp;정상&nbsp;운영이&nbsp;가능한&nbsp;성질을&nbsp;말합니다. 예컨대, 어떤 일이 있어도(IDC가 정전이 나도, 로직이 잘못되어 무한 루프에 빠져도) 운영하는 서비스의 장애를 사용자가 못 느끼도록 하는 상황을 말하는데요. 서비스의 복잡도와 사용자의 규모가 점점 늘어남에 따라 고가용성은 더욱 중요해지는 것 같습니다. 간혹, 기능 개발에만 신경 쓰며 "구현"만 하고 그다음은 생각 안 하는 경우가 있는데 이 글에서 이야기하는 다섯 가지 전략 측면이라도 살펴보면 좋을 것 같아 공유합니다.1. 로드 밸런싱(Load Balancing, LB)2. 격리를 통한 데이터 복제(Data Redundancy3. 장애 조치(Failover)4. 오토 스케일링(Auto scailing)5. Rate Limiting(호출 제한) 각자 구현의 방식은 상황이나 환경에 따라 달라질 수는 있겠지만 개념을 숙지하고 있다가 서비스를 출시하거나 운영하는 상황에서 적용해 봐도 좋을 것 같네요. https://newsletter.systemdesigncodex.com/p/5-strategies-for-high-availability﻿

newsletter.systemdesigncodex.com

고가용성 시스템을 위한 5가지 전략

알고리즘 입문자를 위한 달레의 친절한 안내서

Spiral Matrix | 알고달레

코딩 테스트를 준비하시는 분들을 위해서 일주일에 한 번씩 문제 풀이를 해드리고 있습니다. 이번 시간에는 LeetCode의 54번째 문제인 Spiral Matrix를 풀어보겠습니다.

📺 동영상: https://youtu.be/F56WDTUJ1GM
📝 설명/코드: https://www.algodale.com/problems/spiral-matrix/

코딩 테스트를 준비하시는 분들을 위해서 일주일에 한 번씩 문제 풀이를 해드리고 있습니다. 이번 시간에는 LeetCode의 54번째 문제인 Spiral Matrix를 풀어보겠습니다. 📺 동영상: https://youtu.be/F56WDTUJ1GM📝 설명/코드: https://www.algodale.com/problems/spiral-matrix/

알고달레

리트코드 54. Spiral Matrix 파이썬 풀이

[번역] 환경변수에 시크릿 값을 저장하지 않고 사용하는 더 나은 방법

오늘은 두나무의 조영제님이 번역해주신 글입니다.

우리가 자바스크립트로 프론트엔드나 백엔드 작업을 할 때는 환경 변수 관리를 위해 .env 파일을 사용하는 경우가 많습니다. 개발을 시작할 때 대부분 이렇게 관리하는 모습을 보았고, 아무래도 이 글에서 언급하는 것처럼 그렇게 하는 것이 편하기 때문일 것입니다.
이 글은 크게 두 가지를 다루고 있습니다. 첫 번째는 환경 변수에 시크릿 값을 저장하는 것이 왜 위험한지, 다양한 실제 사례를 통해 설명해줍니다. 두 번째는 시크릿 값을 안전하게 사용하는 다양한 방법에 대해 소개합니다. 이 글이 여러분이 운영하는 서비스의 보안 강화에 도움이 되길 바랍니다.

참고로 글 내에는 없지만 도플러 라는 서비스도 개인적으로 좋게 봤습니다!

글 링크: https://bit.ly/3CCk08b

오늘은 두나무의 조영제님이 번역해주신 글입니다. 우리가 자바스크립트로 프론트엔드나 백엔드 작업을 할 때는 환경 변수 관리를 위해 .env 파일을 사용하는 경우가 많습니다. 개발을 시작할 때 대부분 이렇게 관리하는 모습을 보았고, 아무래도 이 글에서 언급하는 것처럼 그렇게 하는 것이 편하기 때문일 것입니다.이 글은 크게 두 가지를 다루고 있습니다. 첫 번째는 환경 변수에 시크릿 값을 저장하는 것이 왜 위험한지, 다양한 실제 사례를 통해 설명해줍니다. 두 번째는 시크릿 값을 안전하게 사용하는 다양한 방법에 대해 소개합니다. 이 글이 여러분이 운영하는 서비스의 보안 강화에 도움이 되길 바랍니다. 참고로 글 내에는 없지만 도플러 라는 서비스도 개인적으로 좋게 봤습니다! 글 링크: https://bit.ly/3CCk08b

App Store

환경변수에 시크릿 값을 저장하지 않고 사용하는 더 나은 방법

국내 최대 콘텐츠 평가 플랫폼 왓챠피디아가 역대 최대MAU인 400만을 돌파했다고 6일 밝혔다. 왓챠피디아는 대규모 데이터베이스와 이용자 친화적 기능을 기반으로 영화, 드라마, 예능 등 대부분의 콘텐츠와 감독, 배우

왓챠피디아, MAU 400만 돌파…"콘텐츠 종합 플랫폼 역할 톡톡"

(OTT왓챠 아님. 콘텐츠 리뷰 서비스 왓챠피디아)
——
왓챠는 지난 1월 운영 중인 콘텐츠 플랫폼인 왓챠피디아의 MAU(월간 활성화 사용자 수)가 400만을 돌파했다. 이는 콘텐츠 관련 플랫폼의 MAU로는 보기 힘든 수치다. 금융, 배달 등 생활 속에 필수 서비스의 MAU와 맞먹는 수준이다.

https://n.news.naver.com/article/015/0005090291?sid=105

(OTT왓챠 아님. 콘텐츠 리뷰 서비스 왓챠피디아)——왓챠는 지난 1월 운영 중인 콘텐츠 플랫폼인 왓챠피디아의 MAU(월간 활성화 사용자 수)가 400만을 돌파했다. 이는 콘텐츠 관련 플랫폼의 MAU로는 보기 힘든 수치다. 금융, 배달 등 생활 속에 필수 서비스의 MAU와 맞먹는 수준이다. https://n.news.naver.com/article/015/0005090291?sid=105

n.news.naver.com

- 회귀 계수(coefficient)
- 절편(intercept)
- 잔차(Residuals)
- 다중공선성(Multicollinearity)
- 이상치(Outliers)
- 잔차 제곱합 (Sum of Squared Errors)

- 회귀 계수(coefficient) - 절편(intercept) - 잔차(Residuals) - 다중공선성(Multicollinearity) - 이상치(Outliers) - 잔차 제곱합 (Sum of Squared Errors)

선형 회귀(Linear Regression)를 이해하는 데 필요한 개념들

우아한형제들 멘토단 꿀팁 모음

Udemy X 우아한형제들 커리어 성장 멘토링

udemy에 올라간 강의 중 우아한형제들 구성원이 만든 강의가 모여있답니다.
테크니컬라이팅, 커뮤니케이션, 매크로, 프로덕트 관리 노하우 등 다양한 강의가 준비되어있으니 살펴보셔요.

덤으로 제 강의도 있어요 🥳

https://meta-bifrost.vercel.app/BBs5sSF0AQP211KN39Pp

udemy에 올라간 강의 중 우아한형제들 구성원이 만든 강의가 모여있답니다.테크니컬라이팅, 커뮤니케이션, 매크로, 프로덕트 관리 노하우 등 다양한 강의가 준비되어있으니 살펴보셔요. 덤으로 제 강의도 있어요 🥳 https://meta-bifrost.vercel.app/BBs5sSF0AQP211KN39Pp

meta-bifrost.vercel.app

강의 완강하면 커피챗☕ 기회가 생겨요!

그는 연차가 낮은 개발자도 스스로 오너라고 생각하고 일하면 좋겠다고 말한다. 본인이 오너로서 일하면 비즈니스(서비스)를 바라보는 뷰가 달라지기 때문이다.

연차와 기술에 갇히지 않는 오너로서의 개발자ㅣ송요창

원티드와 진행한 인터뷰가 발행되었습니다.
제 두서없는 이야기를 효린님이 너무 깔끔하게 정리해주셨어요.

만약 여러분이 효린님과 인터뷰할 기회가 생긴다면! 꼭 해보세요!!!

지금까지 해본 몇 안되는 인터뷰 중 최고의 경험이었습니다!

https://meta-bifrost.vercel.app/mn14kTtSGmaFtwL1yH32

원티드와 진행한 인터뷰가 발행되었습니다.제 두서없는 이야기를 효린님이 너무 깔끔하게 정리해주셨어요. 만약 여러분이 효린님과 인터뷰할 기회가 생긴다면! 꼭 해보세요!!! 지금까지 해본 몇 안되는 인터뷰 중 최고의 경험이었습니다! https://meta-bifrost.vercel.app/mn14kTtSGmaFtwL1yH32

오너로서의 개발자

"백문이 불여일타"라는 말이 있습니다. 백 번 듣는 것보다 한 번 직접 해보는 것이 낫다는 뜻인데요. 개발 공부에서도 실습이 중요하지만, 무작정 코드를 따라 치는 것은 비효율적입니다.단순 타이핑은 기계적인 반복일 뿐, 생각할 시간이 부족합니다. 타이핑을 하면서도 뇌는 적극적으로 학습하지 않아 코드를 이해하는 듯한 착각에 빠지기 쉽습니다. 따라서, 단순 따라 치기에서 벗어나 더 효과적인 학습 방법을 찾아야 하는데요

✅ 효율적인 개발 공부법
1. 요구사항 정리
코드를 작성하기 전에,
 * "이 코드가 해결해야 할 문제는 무엇인가?"
 * "어떤 입력을 받고, 어떤 출력을 만들어야 하는가?"
이런식으로 요구사항을 명확하게 정리하면 불필요한 시행착오를 줄일 수 있습니다.

2. 플로우 차트 & 도식화를 활용
코드의 실행 흐름을 시각적으로 표현하면 이해가 쉬워집니다.
 * 플로우 차트(Flowchart) : 코드의 동작 흐름을 한눈에 파악 가능
 * 시퀀스 다이어그램(Sequence Diagram) : 여러 요소가 어떻게 상호작용하는지 표현
도식화의 가장 큰 장점은 "메타인지" 입니다. 내가 무엇을 알고, 무엇을 모르는지 메타인지가 향상됩니다.

3. 코드 변형 & 리팩토링
 * "이 부분을 다르게 하면 어떤 결과가 나올까?"
 * "이 기능을 다른 방식으로 구현할 수 있을까?"
코드를 직접 수정하고 테스트하면서 학습하면 진짜 실력이 됩니다. 단순 실행에서 벗어나 깊이 있는 학습이 가능합니다.

결론
따라서 요구사항 정리 → 플로우 차트 작성 → 코드 변경 및 & 리팩토링 의 학습법을 추천합니다. 이 과정을 통해 단순 타이핑이 아니라 문제를 해결하는 사고 과정을 활성화 할 수 있습니다. 그리고 메타인지(내가 제대로 이해하고 있는지 점검하는 과정)를 거쳐 장기 기억에 남게 됩니다.
혹시나 무작정 따라 치는 학습법을 하고 계셨다면, 스스로 사고하며 학습하는 방식으로 바꿔 보시기를 추천드립니다 :)

"백문이 불여일타"라는 말이 있습니다. 백 번 듣는 것보다 한 번 직접 해보는 것이 낫다는 뜻인데요. 개발 공부에서도 실습이 중요하지만, 무작정 코드를 따라 치는 것은 비효율적입니다.단순 타이핑은 기계적인 반복일 뿐, 생각할 시간이 부족합니다. 타이핑을 하면서도 뇌는 적극적으로 학습하지 않아 코드를 이해하는 듯한 착각에 빠지기 쉽습니다. 따라서, 단순 따라 치기에서 벗어나 더 효과적인 학습 방법을 찾아야 하는데요 ✅ 효율적인 개발 공부법1. 요구사항 정리코드를 작성하기 전에,<ul ><li>"이 코드가 해결해야 할 문제는 무엇인가?"</li><li>"어떤 입력을 받고, 어떤 출력을 만들어야 하는가?"</li></ul>이런식으로 요구사항을 명확하게 정리하면 불필요한 시행착오를 줄일 수 있습니다. 2. 플로우 차트 &amp; 도식화를 활용코드의 실행 흐름을 시각적으로 표현하면 이해가 쉬워집니다.<ul ><li>플로우 차트(Flowchart) : 코드의 동작 흐름을 한눈에 파악 가능</li><li>시퀀스 다이어그램(Sequence Diagram) : 여러 요소가 어떻게 상호작용하는지 표현</li></ul>도식화의 가장 큰 장점은 "메타인지" 입니다. 내가 무엇을 알고, 무엇을 모르는지 메타인지가 향상됩니다. 3. 코드 변형 &amp; 리팩토링<ul ><li>"이 부분을 다르게 하면 어떤 결과가 나올까?"</li><li>"이 기능을 다른 방식으로 구현할 수 있을까?"</li></ul>코드를 직접 수정하고 테스트하면서 학습하면 진짜 실력이 됩니다. 단순 실행에서 벗어나 깊이 있는 학습이 가능합니다. 결론따라서 요구사항 정리 → 플로우 차트 작성 → 코드 변경 및 &amp; 리팩토링 의 학습법을 추천합니다. 이 과정을 통해 단순 타이핑이 아니라 문제를 해결하는 사고 과정을 활성화 할 수 있습니다. 그리고 메타인지(내가 제대로 이해하고 있는지 점검하는 과정)를 거쳐 장기 기억에 남게 됩니다.혹시나 무작정 따라 치는 학습법을 하고 계셨다면, 스스로 사고하며 학습하는 방식으로 바꿔 보시기를 추천드립니다 :)

개발 공부법: 코드를 무작정 따라 치지 마세요.

JYK 매니지먼트 | 현대의 디지털 제품과 서비스는 작은 아이디어에서 시작해 수백만 사용자에게 사랑받는 모습으로 성장합니다. 이를 가능하게 하는 핵심은 확장성 있는 시스템 설계입니다. 이 강의에서는 소규모에서 대규모 시스템으로 성장할 수 있는 설계 원리와 실천 방안을 배울

확장성 있는 시스템 설계하기 강의 | JYK 매니지먼트 - 인프런

작년 말, 고려대에서 시스템 설계에 대해 특강을 진행했다. 정말 재미있고 유익했으며, 도움이 되었다며 가능한 온라인 강의로 출시를 해줬으면 좋겠다는 피드백을 받았었다. 당시에는 여유가 없어 시도해보겠다고 답하고, 한동안 바빠져서 챙기지 못했다. 얼마 전부터 여유가 나서 자료를 정비하고, AI 서비스의 도움을 받아 제작해서 출시했다.

맨땅에서 시작해 백만 사용자가 이용하는 대규모 서비스를 구축하려면 가용성, 성능, 확장성 등을 고려한 시스템 설계가 필수다. 이 강의는 '#POTD(Photo of the Day)'이라는 가상 프로젝트를 통해 최소 기능 제품에서 시작하여 글로벌 규모로 확장하는 과정에서 발생하는 다양한 문제와 해결책을 구체적으로 다룬다.

작은 규모에서는 놓치기 쉬운 트래픽 분산, 서버 확장, 데이터베이스 복제, 검색 엔진 및 메시지 큐 연동, CDN과 멀티 데이터 센터 활용 등 대규모 서비스 운영 시 직면하는 핵심 문제를 단계별로 살펴본다. 수평 확장 환경에서 애플리케이션 수준의 설계 고민과 함께 캐싱 등 성능 최적화 필수 기술을 배우고, 머신러닝 기반 개인 맞춤 추천 시스템 구현 아이디어도 소개하고 있다.

프로그래밍 언어 및 기본적인 CS 지식을 갖춘 분이라면, 사례 중심의 설명을 통해 확장성 있는 시스템 설계를 처음부터 끝까지 이해하는 좋은 시작점이 될 것이다.

https://inf.run/TczsG

작년 말, 고려대에서 시스템 설계에 대해 특강을 진행했다. 정말 재미있고 유익했으며, 도움이 되었다며 가능한 온라인 강의로 출시를 해줬으면 좋겠다는 피드백을 받았었다. 당시에는 여유가 없어 시도해보겠다고 답하고, 한동안 바빠져서 챙기지 못했다. 얼마 전부터 여유가 나서 자료를 정비하고, AI 서비스의 도움을 받아 제작해서 출시했다. 맨땅에서 시작해 백만 사용자가 이용하는 대규모 서비스를 구축하려면 가용성, 성능, 확장성 등을 고려한 시스템 설계가 필수다. 이 강의는 '#POTD(Photo of the Day)'이라는 가상 프로젝트를 통해 최소 기능 제품에서 시작하여 글로벌 규모로 확장하는 과정에서 발생하는 다양한 문제와 해결책을 구체적으로 다룬다. 작은 규모에서는 놓치기 쉬운 트래픽 분산, 서버 확장, 데이터베이스 복제, 검색 엔진 및 메시지 큐 연동, CDN과 멀티 데이터 센터 활용 등 대규모 서비스 운영 시 직면하는 핵심 문제를 단계별로 살펴본다. 수평 확장 환경에서 애플리케이션 수준의 설계 고민과 함께 캐싱 등 성능 최적화 필수 기술을 배우고, 머신러닝 기반 개인 맞춤 추천 시스템 구현 아이디어도 소개하고 있다. 프로그래밍 언어 및 기본적인 CS 지식을 갖춘 분이라면, 사례 중심의 설명을 통해 확장성 있는 시스템 설계를 처음부터 끝까지 이해하는 좋은 시작점이 될 것이다. https://inf.run/TczsG

인프런

확장성 있는 시스템 설계하기

Claude가 GPT나 Gemini 등에 비해 코딩에 여전히 더 적합하다는 경험담이 많은데요.

제가 지속적으로 써 보고 느낀바도 역시 그렇습니다. 특히 웹 코딩 쪽에서 좀 더 두각을 나타내는 편으로 보이는데, Claude 서비스에 Web App을 만드는 기능을 만들면서 그쪽으로 데이터를 좀 더 집중한게 아닌게 싶습니다.

그러나, 함정이 있습니다.

Claude가 잘 하는 부분은 복잡해보이는 문제도 실제로는 단순한 부분입니다. 간단하게 말하자면, 빈칸을 채우는 것을 잘하는 것이었습니다.

그런데 조금은 생각을 해야하는, 이를테면 메모리 문제나 동시성 처리같은 부분, 혹은 수학적인 알고리즘의 구현 등은 Claude나 4o 같은 일반 생성 모델 보다는 Reasoning 모델들이 더 잘 하는 것을 확인했습니다.

즉, 말 그대로 생각없이 채워넣기 수준의 코딩은 Claude가 더 잘 하는 편이고, 대개 많은 경우가 새로운 문제나 어려운 문제를 푸는 것이 아니라 단순 구현이 많기 때문에 대부분의 경우 Claude가 더 잘 한다고 느끼는 것 입니다.

이를 확인하고나니 폰 노이만이 프로그래밍, 코딩을 지적 능력이 거의 필요하지 않은 사무적인 일이라고 했던 말이 다시금 떠오르더군요.

사실 지금 회사에서 하는 일도, 많은 부분을 이미 생각은 니가 하렴 노가다는 인간이(내가) 할께..수준으로 일을 하고 있기도 합니다.

아무튼, 당장은 AI를 그 필요에 맞게 선택해서 쓰는데에 이 경험이 유용하겠지만, 앞으로 우리가 해야 할 일이 무엇인지 조금 더 진지하게 생각해 볼 필요가 있지 않을까 싶네요.

Claude가 GPT나 Gemini 등에 비해 코딩에 여전히 더 적합하다는 경험담이 많은데요. 제가 지속적으로 써 보고 느낀바도 역시 그렇습니다. 특히 웹 코딩 쪽에서 좀 더 두각을 나타내는 편으로 보이는데, Claude 서비스에 Web App을 만드는 기능을 만들면서 그쪽으로 데이터를 좀 더 집중한게 아닌게 싶습니다. 그러나, 함정이 있습니다. Claude가 잘 하는 부분은 복잡해보이는 문제도 실제로는 단순한 부분입니다. 간단하게 말하자면, 빈칸을 채우는 것을 잘하는 것이었습니다. 그런데 조금은 생각을 해야하는, 이를테면 메모리 문제나 동시성 처리같은 부분, 혹은 수학적인 알고리즘의 구현 등은 Claude나 4o 같은 일반 생성 모델 보다는 Reasoning 모델들이 더 잘 하는 것을 확인했습니다. 즉, 말 그대로 생각없이 채워넣기 수준의 코딩은 Claude가 더 잘 하는 편이고, 대개 많은 경우가 새로운 문제나 어려운 문제를 푸는 것이 아니라 단순 구현이 많기 때문에 대부분의 경우 Claude가 더 잘 한다고 느끼는 것 입니다. 이를 확인하고나니 폰 노이만이 프로그래밍, 코딩을 지적 능력이 거의 필요하지 않은 사무적인 일이라고 했던 말이 다시금 떠오르더군요. 사실 지금 회사에서 하는 일도, 많은 부분을 이미 생각은 니가 하렴 노가다는 인간이(내가) 할께..수준으로 일을 하고 있기도 합니다. 아무튼, 당장은 AI를 그 필요에 맞게 선택해서 쓰는데에 이 경험이 유용하겠지만, 앞으로 우리가 해야 할 일이 무엇인지 조금 더 진지하게 생각해 볼 필요가 있지 않을까 싶네요.

Claude가 GPT나 Gemini 등에 비해 코딩에 여전히 더 

YouTube에서 마음에 드는 동영상과 음악을 감상하고, 직접 만든 콘텐츠를 업로드하여 친구, 가족뿐 아니라 전 세계 사람들과 콘텐츠를 공유할 수 있습니다.

 - YouTube

현재 Nextjs 에서는
Dynamic 렌더링을 할지 혹은 Static 렌더링을 할지에 대해
페이지 단위로만 결정할 수 있단 사실 알고계셨나요??
(자식 컴포넌트 중에서 하나라도 Dynamic 이면
해당 페이지 전체를 Dynamic 으로 간주)

이러한 한계를 갖게된 배경에 대해
렌더링 방식의 발전 역사부터 쭉 살펴보았습니다.

그럼 오늘도 각자의 자리에서 함께 공부하는 모든 분들 화이팅입니다 :)

https://youtu.be/dBRFHwH9imo

현재 Nextjs 에서는Dynamic 렌더링을 할지 혹은 Static 렌더링을 할지에 대해페이지 단위로만 결정할 수 있단 사실 알고계셨나요??(자식 컴포넌트 중에서 하나라도 Dynamic 이면해당 페이지 전체를 Dynamic 으로 간주) 이러한 한계를 갖게된 배경에 대해렌더링 방식의 발전 역사부터 쭉 살펴보았습니다. 그럼 오늘도 각자의 자리에서 함께 공부하는 모든 분들 화이팅입니다 :) https://youtu.be/dBRFHwH9imo

youtu.be

Nextjs 렌더링 방식이 페이지 단위로만 결정된다?!

책 『리액트 훅을 활용한 마이크로 상태 관리』 를 읽고 작성한 서평입니다.

리액트 훅을 활용한 마이크로 상태 관리 - 재그지그의 개발 블로그

- 책 『리액트 훅을 활용한 마이크로 상태 관리』 를 읽고 작성한 서평입니다.

---

올해 첫 책을 읽었습니다. 원래 작년에 읽으려 했지만 미뤄둔 책이라, 이번 설 연휴를 계기로 완독하고 후기를 남겨보려고 합니다.

사실 이 책을 읽게 된 이유는 회사에서 스터디 목적으로 구매한 책이었는데, 정작 바쁘다는 이유로 스터디를 하지는 못했기 때문입니다. 사놓은 책만 덩그러니 남겨져 있어서, 개인적으로 공부하기 위해 읽게 되었습니다.

이 책을 보고 흥미를 느낀 부분은 크게 두 가지였는데요. 첫 번째는 책 제목에서 이야기하는 마이크로 상태 관리 라는 개념이 저에게는 생소하게 느껴져서 그 의미가 궁금했고, 두 번째로는 Zustand와 Jotai처럼 유명한 상태 관리 라이브러리를 깊이 다루는 내용이 포함되어 있다는 점이었습니다. 사실 저는 아직까지 두 라이브러리를 들어보기만 했지 직접 사용해본 경험은 없어서 그 둘의 차이점을 알고 싶었기 때문입니다.

저와 비슷한 고민을 하시는 분들도 계실 것 같아, 이번 포스트에서 이 책의 주요 내용을 소개하고 인상 깊었던 부분을 공유하려고 합니다.

https://wormwlrm.github.io/2025/02/02/Micro-State-Management-with-React-Hooks.html

- 책 『리액트 훅을 활용한 마이크로 상태 관리』 를 읽고 작성한 서평입니다. --- 올해 첫 책을 읽었습니다. 원래 작년에 읽으려 했지만 미뤄둔 책이라, 이번 설 연휴를 계기로 완독하고 후기를 남겨보려고 합니다. 사실 이 책을 읽게 된 이유는 회사에서 스터디 목적으로 구매한 책이었는데, 정작 바쁘다는 이유로 스터디를 하지는 못했기 때문입니다. 사놓은 책만 덩그러니 남겨져 있어서, 개인적으로 공부하기 위해 읽게 되었습니다. 이 책을 보고 흥미를 느낀 부분은 크게 두 가지였는데요. 첫 번째는 책 제목에서 이야기하는&nbsp;마이크로 상태 관리&nbsp;라는 개념이 저에게는 생소하게 느껴져서 그 의미가 궁금했고, 두 번째로는 Zustand와 Jotai처럼 유명한 상태 관리 라이브러리를 깊이 다루는 내용이 포함되어 있다는 점이었습니다. 사실 저는 아직까지 두 라이브러리를 들어보기만 했지 직접 사용해본 경험은 없어서 그 둘의 차이점을 알고 싶었기 때문입니다. 저와 비슷한 고민을 하시는 분들도 계실 것 같아, 이번 포스트에서 이 책의 주요 내용을 소개하고 인상 깊었던 부분을 공유하려고 합니다. https://wormwlrm.github.io/2025/02/02/Micro-State-Management-with-React-Hooks.html

재그지그의 개발 블로그

🎤 리액트 훅을 활용한 마이크로 상태 관리

에이든든님이
이직 과정에서 공고 확인이 불편하여 코파일럿으로 이를 손쉽게 필터링하는 크롬 익스텐션을 만든 이야기입니다

역시 필요는 발명의 어머니네요
https://aydenden.medium.com/%EC%BD%94%ED%8C%8C%EC%9D%BC%EB%9F%BF%EA%B3%BC-%ED%95%A8%EA%BB%98%ED%95%9C-%EC%9D%B4%EC%A7%81-%EA%B3%BC%EC%A0%95-6529e9c753c2

에이든든님이 이직 과정에서 공고 확인이 불편하여 코파일럿으로 이를 손쉽게 필터링하는 크롬 익스텐션을 만든 이야기입니다 역시 필요는 발명의 어머니네요https://aydenden.medium.com/%EC%BD%94%ED%8C%8C%EC%9D%BC%EB%9F%BF%EA%B3%BC-%ED%95%A8%EA%BB%98%ED%95%9C-%EC%9D%B4%EC%A7%81-%EA%B3%BC%EC%A0%95-6529e9c753c2

필요는 발명의 어머니(이직할 때 코파일럿쓴 사례)

원문 : Goodbye SASS 👋, welcome back native CSS thumbnail Sass는 로컬에 설치되는 강력한 전처리기로 자리 잡으며 지난 10년 동안 제 프로젝트의 핵심을 이루었습니다. 이는 확장 가능하고 안정적인 CSS 패키지를 효율적으로 구성할 수 있게 해 주었습니다. 지금도 Sass는 굉장히 강력한 도구라고 생각합니다. 하지만 2024년에 접어들면서 CSS가 급속도로 발전하고 있다는 것은 부인할 수 없는 사실입니다. 한때 Sass에만 존재하던 기능들이 이제는 CSS…

(번역) 잘 가 SASS 👋, 다시 만나 반가워 네이티브 CSS

오늘은 42dot의 유경상님이 번역해주신 글입니다.

Sass는 오랫동안 CSS 전처리기로서 많은 개발자들에게 사랑받아 왔지만, 이 글에서 저자는 CSS의 발전으로 인해 Sass의 필요성이 줄어들고 있다고 말하고 있습니다. 네이티브 CSS에 추가된 변수, 중첩, 컨테이너 쿼리 등 강력한 기능들이 어떻게 Sass의 기능을 대체할 수 있는지 살펴보고, 과연 Sass를 충분히 대체할 수 있을지에 대해 생각해보는 기회가 되시길 바랍니다 :)

> https://ykss.netlify.app/translation/goodbye_sass_welcome_back_native_css/

오늘은 42dot의 유경상님이 번역해주신 글입니다. Sass는 오랫동안 CSS 전처리기로서 많은 개발자들에게 사랑받아 왔지만, 이 글에서 저자는 CSS의 발전으로 인해 Sass의 필요성이 줄어들고 있다고 말하고 있습니다. 네이티브 CSS에 추가된 변수, 중첩, 컨테이너 쿼리 등 강력한 기능들이 어떻게 Sass의 기능을 대체할 수 있는지 살펴보고, 과연 Sass를 충분히 대체할 수 있을지에 대해 생각해보는 기회가 되시길 바랍니다 :) &gt; https://ykss.netlify.app/translation/goodbye_sass_welcome_back_native_css/

ykss.netlify.app

잘 가 SASS 👋, 다시 만나 반가워 네이티브 CSS

타입스크립트로 개발을 할 때에, 네트워크 요청 등 방식을 통해 타입을 알 수 없는 외부 데이터를 가져오게 되는 경우가 있습니다. 이 글에서는 우선 타입스크립트에서 타입을 알 수 없는 데이터를 다루는 가장 흔한 방법들에 대해서 알아보고, Zod라는 라이브러리를 사용해 다른 방식들의 단점을 보완해 데이터를 안전하게 다룰 수 있는 방법에 대해서 소개해드리고자 합니다.

타입스크립트에서 타입을 알 수 없는 외부 데이터 안전하게 처리하기

타입스크립트 프로젝트에서 타입을 알 수 없는 외부 데이터를 처리하는 경험을 통해 알게 된 지식들을 글로 정리해 보았습니다.

이재찬의 개발 블로그

백엔드 개발자

현구막

안녕하세요
#개발자 #백엔드 #소프트웨어엔지니어 #블로거

푸블러 백엔드 개발자

황유진

퍼블리의 그로스 매니저로 커리어를 시작하여, 현재는 멤버십 사업을 총괄하고 있습니다.
합리적이고 해피한 세상을 향해 살아가고 있으며, 책과 교육, 경제에 관심을 가지고 있습니다.
일하는 것을 싫어하지만, 많이 하고 있습니다..

커리어리 Lead Product Manager

김광종

퍼블리 그로스매니저로 커리어를 시작하여, 프로덕트매니저와 사업총괄을 거쳐, 커리어리팀을 리드하였습니다.
합리적이고 해피한 세상을 향해 살아가고 있으며, 책/교육/경제에 관심이 있습니다.
자유로운 삶을 추구하지만, 지금은 일에 매여 있습니다..

컴퓨터공학부

이재찬

백엔드 개발자 이재찬입니다.
#백엔드 #개발자 #Algorithm

타입스크립트에서 타입을 알 수 없는 외부 데이터 안전하게 처리하기

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필