Java가 느리고 무겁다는 말도 이제 다 옛날 말이긴 하다. Java 생태계가 좋아진 것도 있긴 하지만, 그보다 Java/Spring은 가만히 있었는데 걍 다른 애들이 무거워짐..(…)

Java가 느리고 무겁다는 말도 이제 다 옛날 말이긴 하다. Java 생태계가 좋아진 것도 있긴 하지만, 그보다 Java/Spring은 가만히 있었는데 걍 다른 애들이 무거워짐..(…)

가만보면 프레임워크들은 무게로 나이를 먹어가는거 같네요

2021년에 63.5세로 약 40년간의 프로그래머 생활을 마치고 은퇴함능력이 떨어져서가 아니라 1년간 고민 끝에 더 이상 하고 싶지 않다는 것을 깨달음모든 사람은 언젠가는 평생 해왔던 일을 더 이상 할 수 없게 되는 시점에 도달함은퇴뿐만 아니라 그 이전에도 언제든 일어날 수 있음선택한 기술이 사라져서 쓸모없게 되거나, 단순히 코딩에 지치거나, 직업으로서의

떠날 때를 아는 방법 | GeekNews

언제까지 개발자(혹은 지금의 직업)를 할 것인가에 대한 글입니다. 필자는 40년 동안 개발하다 은퇴했는데 그 과정에서 겪은 경험을 이야기 하고 있네요. 아래 Hacker News 의견도 같이 보면 좋을 것 같고요.
꼭 "무조건 은퇴하세요" 가 아닌 "직업"에 대한 고민을 늘 하며 살아가야 하는 건 아닐까 하는 생각을 하게 해주는 글이네요.

특히 개발자로 살아가는 저로서는 많은 생각을 하게 된 글인데요. 어떤 개발자로 살아갈 것인가에 대한 생각도 함께 고민하면서 읽어봐도 좋을 것 같습니다. 기술 분야는 빠르게 변화하므로, 자신의 흥미와 성장 가능성을 유지할 수 있는지 자주 평가해 보는 것도 좋을 것 같더라고요. 만약 그 열정이 식어가거나 더 이상 성장할 수 없다고 느껴진다면, 새로운 도전이나 경로를 고려하는 것이 현명할 수 있습니다. 끊임없는 자기 성찰과 솔직함이 성공적인 경력의 핵심이라 생각이 듭니다.
﻿
https://news.hada.io/topic?id=15851

언제까지&nbsp;개발자(혹은&nbsp;지금의&nbsp;직업)를&nbsp;할 것인가에&nbsp;대한&nbsp;글입니다. 필자는&nbsp;40년 동안&nbsp;개발하다&nbsp;은퇴했는데&nbsp;그&nbsp;과정에서&nbsp;겪은&nbsp;경험을&nbsp;이야기&nbsp;하고&nbsp;있네요.&nbsp;아래&nbsp;Hacker&nbsp;News&nbsp;의견도&nbsp;같이&nbsp;보면&nbsp;좋을&nbsp;것&nbsp;같고요.꼭&nbsp;"무조건&nbsp;은퇴하세요"&nbsp;가&nbsp;아닌&nbsp;"직업"에&nbsp;대한&nbsp;고민을&nbsp;늘&nbsp;하며&nbsp;살아가야&nbsp;하는 건&nbsp;아닐까&nbsp;하는&nbsp;생각을&nbsp;하게&nbsp;해주는&nbsp;글이네요. 특히 개발자로 살아가는 저로서는 많은 생각을 하게 된 글인데요. 어떤 개발자로 살아갈 것인가에 대한 생각도 함께 고민하면서 읽어봐도 좋을 것 같습니다. 기술 분야는 빠르게 변화하므로, 자신의 흥미와 성장 가능성을 유지할 수 있는지 자주 평가해 보는 것도 좋을 것 같더라고요. 만약 그 열정이 식어가거나 더 이상 성장할 수 없다고 느껴진다면, 새로운 도전이나 경로를 고려하는 것이 현명할 수 있습니다. 끊임없는 자기 성찰과 솔직함이 성공적인 경력의 핵심이라 생각이 듭니다.﻿https://news.hada.io/topic?id=15851

GeekNews

떠날 때를 아는 방법

타입스크립트의 타입 시스템은 타입에 대해 동작하는 순수 함수형 언어로 생각할 수 있습니다. 그런데 타입에 대해 동작한다는 것은 어떤 의미일까요?

(번역) 타입스크립트에 대한 다른 접근법

오늘은 라인플러스의 황세현님이 번역해주신 글입니다.

타입스크립트에는 집합의 교집합 연산에 해당하는 인터섹션 (&) 타입이 있습니다.
{ x: number }
타입과
{ y: number }
타입이 있다고 가정할 때 두 타입의 인터섹션 결과는
{ x: number, y: number }
타입이 됩니다. 단순히 생각했을 때, 두 타입은 공통된 항목이 없는 것 같은데 왜 인터섹션 결과는 다르게 나올까요? 이 글에서는 타입스크립트의 타입을 해당 타입에 할당할 수 있는 항목의 집합 관점으로 해석하며 그 이유를 설명하고 있습니다. 인터섹션 외에 다른 기본 타입들도 잘 풀어서 설명하고 있으니, 타입스크립트에 대해 더 깊게 이해하고 싶으신 분들은 읽어보시길 추천해 드립니다. 🤓

글 링크 : https://velog.io/@sehyunny/a-diff-way-to-think-about-ts

오늘은 라인플러스의 황세현님이 번역해주신 글입니다. 타입스크립트에는 집합의 교집합 연산에 해당하는 인터섹션 (&amp;) 타입이 있습니다. <code >{ x: number }</code> 타입과 <code >{ y: number } </code>타입이 있다고 가정할 때 두 타입의 인터섹션 결과는<code > { x: number, y: number } </code>타입이 됩니다. 단순히 생각했을 때, 두 타입은 공통된 항목이 없는 것 같은데 왜 인터섹션 결과는 다르게 나올까요? 이 글에서는 타입스크립트의 타입을 해당 타입에 할당할 수 있는 항목의 집합 관점으로 해석하며 그 이유를 설명하고 있습니다. 인터섹션 외에 다른 기본 타입들도 잘 풀어서 설명하고 있으니, 타입스크립트에 대해 더 깊게 이해하고 싶으신 분들은 읽어보시길 추천해 드립니다. 🤓 글 링크 : https://velog.io/@sehyunny/a-diff-way-to-think-about-ts

Velog

타입스크립트에 대한 다른 접근법

Today we are excited to announce the availability of TypeScript 5.6 Beta. To get started using the beta, you can get it through NuGet, or through npm with the following command: npm install -D typescript@beta Here's a quick list of what's new in TypeScrip

Announcing TypeScript 5.6 Beta - TypeScript

타입스크립트 5.6 베타가 지난 7월 26일에 출시 되었습니다. 역시 이번에도 생산성을 높이고 코드의 안정성을 강화하는 여러 중요한 기능이 포함되어 있는데요.

 1. Nullish 및 Truthy 체크 제한
    * 조건문에서의 타입 안정성을 개선했습니다. 이제 컴파일러는 항상 truthy나 nullish로 평가되는 표현식에 대해 이전과는 달리 경고를 표시합니다.
    * if문 안에 정규식을 사용하면
      if(/0x[0-9a-f]/)
      이제 오류로 간주합니다. 이전에는 정규식 객체가 존재하기만 하면 무조건 true로 처리 되었지만, 이제는 정규식 패턴과 일치하는지 정확한 검사가 필요합니다. 따라서 더 명시적이고 정확한 코드 작성을 강제합니다.
 2. Iterator 헬퍼 메서드 도입
    * 이터러블은 제너레이터와 같은 반복 가능한 객체입니다. 그런데 이 객체는 배열에서 사용하던 map, filter, reduce같은 메서드를 사용하지 못했는데요.
    * ECMAScript에 이런 불편함을 해소하는 제안이 제출되어서, 이제 배열에서 사용하던 편리한 메서드들(map, filter)를 이터러블 에서도 사용할 수 있게 되었습니다. 따라서 여러 종류의 데이터를 비슷한 방식으로 다룰 수 있게 되었습니다.
    * 제너레이터 뿐 아니라, 다른 이터러블 객체들(Map, Set)에도 적용 가능합니다.
function* positiveIntegers() {
    let i = 1;
    while (true) {
        yield i;
        i++;
    }
}

const evenNumbers = positiveIntegers().map(x => x * 2);

 3. 엄격한 내장 Iterator 체크
    * Iterator는 next()메서드를 호출하여 순차적으로 값을 반환하는 객체입니다. 문제는 Iterator의 반환 타입이 any로 설정되어 있었는데요.
    * BuiltinIterator
      라는 새로운 타입을 도입해서, Iterator타입을 더 정확하게 표현합니다.
    * 따라서
      Iterator
      사용시 발생할 수 있는 런타임 오류를 컴파일 시점에 잡아 낼 수 있게 되었습니다.

향후계획
타입스크립트 5.6의 기능 추가가 완료되었고, 앞으로 버그수정, 기존 기능의 안정화에 집중하고 있습니다. 약 한달 후에 릴리스 후보(RC)버전이 공개될 예정이며, 이후 곧바로 정식 버전이 출시될 것으로 예상됩니다. 보다 자세한 내용은 공식 홈페이지와 릴리즈 노트를 참고하시기 바랍니다.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-beta/

타입스크립트 5.6 베타가 지난 7월 26일에 출시 되었습니다. 역시 이번에도 생산성을 높이고 코드의 안정성을 강화하는 여러 중요한 기능이 포함되어 있는데요. <ol ><li>Nullish 및 Truthy 체크 제한<ul ><li>조건문에서의 타입 안정성을 개선했습니다. 이제 컴파일러는 항상 truthy나 nullish로 평가되는 표현식에 대해 이전과는 달리 경고를 표시합니다.</li><li>if문 안에 정규식을 사용하면 <code >if(/0x[0-9a-f]/)</code> 이제 오류로 간주합니다. 이전에는 정규식 객체가 존재하기만 하면 무조건 true로 처리 되었지만, 이제는 정규식 패턴과 일치하는지 정확한 검사가 필요합니다. 따라서 더 명시적이고 정확한 코드 작성을 강제합니다.</li></ul></li><li>Iterator 헬퍼 메서드 도입<ul ><li>이터러블은 제너레이터와 같은 반복 가능한 객체입니다. 그런데 이 객체는 배열에서 사용하던 map, filter, reduce같은 메서드를 사용하지 못했는데요.</li><li>ECMAScript에 이런 불편함을 해소하는 제안이 제출되어서, 이제 배열에서 사용하던 편리한 메서드들(map, filter)를 이터러블 에서도 사용할 수 있게 되었습니다. 따라서 여러 종류의 데이터를 비슷한 방식으로 다룰 수 있게 되었습니다. </li><li>제너레이터 뿐 아니라, 다른 이터러블 객체들(Map, Set)에도 적용 가능합니다.</li></ul></li></ol><pre ><code>function* positiveIntegers() {
 let i = 1;
 while (true) {
 yield i;
 i++;
 }
}

const evenNumbers = positiveIntegers().map(x =&gt; x * 2);</code></pre><ol start="3"><li>엄격한 내장 Iterator 체크<ul ><li>Iterator는 next()메서드를 호출하여 순차적으로 값을 반환하는 객체입니다. 문제는 Iterator의 반환 타입이 any로 설정되어 있었는데요. </li><li><code >BuiltinIterator</code>라는 새로운 타입을 도입해서, Iterator타입을 더 정확하게 표현합니다.</li><li>따라서 <code >Iterator</code> 사용시 발생할 수 있는 런타임 오류를 컴파일 시점에 잡아 낼 수 있게 되었습니다.</li></ul></li></ol> 향후계획타입스크립트 5.6의 기능 추가가 완료되었고, 앞으로 버그수정, 기존 기능의 안정화에 집중하고 있습니다. 약 한달 후에 릴리스 후보(RC)버전이 공개될 예정이며, 이후 곧바로 정식 버전이 출시될 것으로 예상됩니다. 보다 자세한 내용은 공식 홈페이지와 릴리즈 노트를 참고하시기 바랍니다. https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-beta/

TypeScript

타입스크립트 5.6 베타 출시: 새로운 기능과 개선사항 소개

GitHub Staff Engineer Sarah Vessels discusses her philosophy of code review, what separates good code review from bad, her strategy for finding and reviewing code, and how to get the most from reviews of her own code.

How to review code effectively: A GitHub staff engineer's philosophy

GitHub의 스태프 엔지니어가 자신의 업무 중 가장 중요한 일 중 하나가 코드 리뷰고 수년동안 코드리뷰를 해오면서 쌓은 경험을 정리한 글입니다.

GitHub에서는 PR에서 라벨을 많이 쓰는지 Slack에서도 /github subscribe your/repo pulls +label:"your-team-label" 명령어를 통해서 리뷰가 필요한 PR의 알림 설정을 한다고 합니다. 갠적으로는 회사에서는 라벨을 많이 쓰진 않아서(규칙이 많으면 관리가 어려운 느낌) 저는 이렇게 쓰고 있지 않은데 조직이 커지면 꽤 괜찮은 방법이라고 생각합니다.

그 외에도 GitHub의 검색 기능과 Owner를 사용해서 너무 많은 알림이 오지 않도록 관리하고 알림이 왔을때 검토를 빨리 해야겠다는 느낌을 줄 수 있게 관리하고 있다고 합니다.

코드 리뷰 자체에 대한 상세한 안내도 되어 있는데 가능한한 구체적으로 설명하고 개선을 요구하는 리뷰로 작성하는 것을 권장하며 리뷰를 받았을 때 뭘 해야할지 확실히 알수 있게 한다는 점이 좋았습니다. 코드 리뷰에서 질문을 하는 것을 아주 좋아하고 때로는 긍정적인 평가를 남기는 것도 협업에 큰도움이 된다고 합니다. 일에 집중하다보면 동료끼리 이런 점을 놓치기 쉬운데 칭찬댓글 하나씩 남기는건 꽤 좋다고 생각합니다.

병합이 너무 병목이 되지 않도록 승인하고 있고 Request changes는 강압적으로 보일 수 있어서 거의 사용하지 않는다고 합니다. 제가 있는 팀에서도 명확히 한다는 의미로 Request changes를 꽤 쓰다가 일부 사람에게는 이러한 요청이 부정적인 느낌으로 다가와서 논의후에 사용하지 않기로 했었기 때문에 이부분도 공감이 되었습니다.

https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/

GitHub의 스태프 엔지니어가 자신의 업무 중 가장 중요한 일 중 하나가 코드 리뷰고 수년동안 코드리뷰를 해오면서 쌓은 경험을 정리한 글입니다. GitHub에서는 PR에서 라벨을 많이 쓰는지 Slack에서도 /github subscribe your/repo pulls +label:"your-team-label" 명령어를 통해서 리뷰가 필요한 PR의 알림 설정을 한다고 합니다. 갠적으로는 회사에서는 라벨을 많이 쓰진 않아서(규칙이 많으면 관리가 어려운 느낌) 저는 이렇게 쓰고 있지 않은데 조직이 커지면 꽤 괜찮은 방법이라고 생각합니다. 그 외에도 GitHub의 검색 기능과 Owner를 사용해서 너무 많은 알림이 오지 않도록 관리하고 알림이 왔을때 검토를 빨리 해야겠다는 느낌을 줄 수 있게 관리하고 있다고 합니다. 코드 리뷰 자체에 대한 상세한 안내도 되어 있는데 가능한한 구체적으로 설명하고 개선을 요구하는 리뷰로 작성하는 것을 권장하며 리뷰를 받았을 때 뭘 해야할지 확실히 알수 있게 한다는 점이 좋았습니다. 코드 리뷰에서 질문을 하는 것을 아주 좋아하고 때로는 긍정적인 평가를 남기는 것도 협업에 큰도움이 된다고 합니다. 일에 집중하다보면 동료끼리 이런 점을 놓치기 쉬운데 칭찬댓글 하나씩 남기는건 꽤 좋다고 생각합니다. 병합이 너무 병목이 되지 않도록 승인하고 있고 Request changes는 강압적으로 보일 수 있어서 거의 사용하지 않는다고 합니다. 제가 있는 팀에서도 명확히 한다는 의미로 Request changes를 꽤 쓰다가 일부 사람에게는 이러한 요청이 부정적인 느낌으로 다가와서 논의후에 사용하지 않기로 했었기 때문에 이부분도 공감이 되었습니다. https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/

The GitHub Blog

미국 반도체 기업 인텔이 당장 내달 계획돼 있던 연례 개발자 대회 '인텔 이노베이션 2024′를 취소하기로 했다. 지난 1일 시장 전망치를 하회하는 실적을 발표한 뒤 주가가 곤두박질치자 연례 최대 행사까지 취소하기로 했다. 8일 인텔은 "신중하게 검토한 끝에 우리는 9월 열릴 예정이었던 '인텔 이노베이션 2024′ 행사를 2025년까지 연기하기로 결정했다"

개발자 대회 취소... 인텔 '끝모를 추락'

컴퓨터 광고 뒤에 인텔 인사이드 라는 말이 따라오던 때가 있었죠.
프로세서 = 인텔
감히 이렇게 생각하고 살았습니다.

프로그래머로 업을 이어가면서 조립 PC를 다룰 일이 없어서 점차 인텔과 멀어져서 살았는데요. 최근 기사를 보니 인텔이 실적저조로 개발자 대회까지 취소하는 지경에 이르렀다고 하네요.

세월이 흘러가는걸 저만 놓치고 있었나보네요.

https://v.daum.net/v/20240812013709200

컴퓨터 광고 뒤에 인텔 인사이드 라는 말이 따라오던 때가 있었죠.프로세서 = 인텔감히 이렇게 생각하고 살았습니다. 프로그래머로 업을 이어가면서 조립 PC를 다룰 일이 없어서 점차 인텔과 멀어져서 살았는데요. 최근 기사를 보니 인텔이 실적저조로 개발자 대회까지 취소하는 지경에 이르렀다고 하네요. 세월이 흘러가는걸 저만 놓치고 있었나보네요. https://v.daum.net/v/20240812013709200

다음 - 조선일보

화무십일홍

노션 API로 내용을 긁어 워드프레스로 넣는 작업을 하고 있습니다.
처음엔 WP Sync for Notion 플러그인을 사용하려고 했는데 무료 버전에선 데이터베이스 읽기가 안 돼 의미가 없었습니다. 노션 디비는 글목록 개념이거든요.
유료는 1년 150달러인데 월결제가 없는 듯하고요.
그래서 그냥 만드는 중입니다.
돈 아니면 시간이네요.

노션 API로 내용을 긁어 워드프레스로 넣는 작업을 하고 있습니다. 처음엔 WP Sync for Notion 플러그인을 사용하려고 했는데 무료 버전에선 데이터베이스 읽기가 안 돼 의미가 없었습니다. 노션 디비는 글목록 개념이거든요. 유료는 1년 150달러인데 월결제가 없는 듯하고요. 그래서 그냥 만드는 중입니다.돈 아니면 시간이네요.

10년쯤 전의 이야기입니다. 2012년 2월쯤이었나.
네이버의 이해진 의장님이 이런 말씀을 하신 적이 있습니다.

"여러분들 네이버란 간판 떼고 나가서 아무 서비스나 한번 만들어보세요.
몇 명이나 써줄 것 같아요? 10명이나 다운 받아줄까요?
지금 네이버란 간판이 여러분들이 만드는 서비스를 지켜주고 있다는 걸 깨닫게 될 거예요.
못 믿겠으면 나가서 한 번 해보세요. 그게 여러분들 진짜 실력이에요."

가슴이 두근두근 뛰고 약간의 반항심도 들었던 것 같습니다. 저 말이 진짜일까?
아니, 난 잘할 수 있을 것 같은데.
이 이야기는 제 가슴에 꽂혀 오랜 시간이 지나도록 잊히지 않았습니다.

---

회사 다닐 때 이런 생각을 가끔씩 했던 것 같습니다.
내가 회사 다니면서 연봉 1억을 받는다면 사실 내가 회사에 가져다준 가치는 그 이상이야. 적어도 1억 5천은 되겠지. 회사는 내게서 5천만 원을 수수료처럼 떼 가고 있는 거야. 그렇다면 내가 회사를 그만두고 혼자 일한다면 1억 5천 이상을 벌 수 있는 사내가 되겠군.

그리고 이런 생각은 이해진 의장님의 이야기와는 반대였고 저는 정말 궁금했습니다.
내가 나만의 서비스를 만든다면 결과가 어떨까? 내 실력은 진짜일까 가짜일까.
남이 만든 회사가 아니라 내가 창조해낸 제품으로 단 돈 만원이라도 벌어보고 싶다. 딱 만원만 벌고 실패해도 좋으니 내 진짜 실력이라는 걸 테스트해보고 싶어.

---

어릴 때 스포츠 선수들이 연봉 때문에 재계약을 안 하고 싸우는 것을 보면 이상했습니다.
돈을 저렇게 많이 받는데 그깟 몇 프로 더 받으려고 저렇게 싸워가면서 뻐팅긴다고?
이런 질문을 어른들에게 하면 어김없이 이런 대답이 돌아왔습니다.
"스포츠 선수들은 연봉을 실력으로 생각하는 거야. 자기 실력을 인정받고 싶은 거지."

이제는 조금 이해할 수 있을 것 같습니다.
이 세상에서 진실을 테스트할 수 있는 것 중 돈 만한 게 없다는 걸 깨닫게 되었거든요.
내 음식이 맛있다 맛없다 하는 말은 별로 중요하지 않습니다. 손님들이 지갑을 열어 기꺼이 지불해주는 돈이 진실인 것입니다.

이런 관점으로 바라보면 본인의 연봉이 곧 그 업에서의 실력이라고 말할 수 있습니다.

---

저는 결국 궁금증을 풀어냈습니다.

1. 이해진 의장님이 한 말은 사실이었습니다.
제가 만든 앱은 하루에 1명도 설치하지 않은 날들이 많았습니다. 너무 우울해서 독한 술로 슬픈 패배감을 달래곤 했습니다. 마음이 어찌나 쓰린지 맥주 같은 술로는 달래지지 않더군요.

2. 회사에서 수수료를 떼어간다는 제 생각은 옳았습니다.
회사에서 연봉 1억을 받는다면 회사를 그만두면 같은 노력으로 그 이상을 벌 잠재력을 가지고 있습니다.
사람들이 많이 오해하는 부분은 '같은 노력' 부분인 것 같습니다.
적어도 회사에서 하는 만큼은 일해야 하는데 덜 노력하고 더 벌려고 하니 쉽지가 않습니다.

3. 이 잠재력은 쉽게 발현되지 않습니다.
최소한 1년. 통상 3년 정도는 해봐야 결과가 나옵니다. 10년이 걸릴 수도 있습니다.
사람들은 충분한 잠재력을 가지고 있지만 결과가 나오기 전에 포기합니다.
하지만 이 날 이해진 의장님은 또 한 가지 말씀을 해주셨습니다.
"성공은요, 실패하고 실패하다가 더 물러설 곳 없는 마지막 한 걸음에 나오는 거예요."

이 말은 제가 포기하지 않을 수 있게 도와줬습니다.

4. 저는 실력이 있는 사람이었습니다.
이걸 알게 된 것이 가장 큰 소득입니다.
4년의 노력 끝에 드디어 회사 다닐 때의 연봉을 넘어섰습니다.
더 이상 제 자신에 대해 의심하지 않게 된 것이 너무너무 기쁩니다.
저는 스스로의 힘으로 세상에 가치를 만들어 낼 수 있고 돈을 벌 수 있는 존재라는 것을 깨닫게 되니 그제야 평안을 얻게 되었달까요? 더 이상 다른 사람들이 부럽지 않게 되었습니다.

본인이 진짜 얼마짜리 사람인지 알고 싶나요?
회사를 그만두고 혼자서 도전해보는 것만큼 좋은 방법도 없는 것 같습니다.
어쩌면 회사는 자신의 온전한 가치를 드러낼 수 없게 상한선을 막고 있는 존재 아닐까 하는 생각을 합니다.
이 울타리를 깨고 나와야만 자신을 테스트해볼 수 있습니다.
외롭고 고된 길이지만 도전할만한 가치가 있습니다.
이 길은 자기가 누구인지 찾아가는 과정이고 그 열매는 너무 달콤하거든요.
이제야 저는 저를 찾았습니다.

10년쯤 전의 이야기입니다. 2012년 2월쯤이었나.네이버의 이해진 의장님이 이런 말씀을 하신 적이 있습니다. "여러분들 네이버란 간판 떼고 나가서 아무&nbsp;서비스나 한번 만들어보세요.몇 명이나 써줄 것 같아요? 10명이나 다운 받아줄까요?지금 네이버란 간판이 여러분들이 만드는 서비스를 지켜주고 있다는 걸 깨닫게 될 거예요.못 믿겠으면 나가서 한 번 해보세요. 그게 여러분들 진짜 실력이에요." 가슴이 두근두근 뛰고 약간의&nbsp;반항심도 들었던 것 같습니다. 저 말이 진짜일까?아니, 난 잘할 수 있을 것 같은데.이 이야기는 제 가슴에 꽂혀 오랜 시간이 지나도록 잊히지 않았습니다. --- 회사 다닐 때 이런 생각을 가끔씩 했던 것 같습니다.내가 회사 다니면서 연봉 1억을 받는다면 사실 내가 회사에 가져다준 가치는 그 이상이야. 적어도 1억 5천은 되겠지. 회사는 내게서 5천만 원을 수수료처럼 떼 가고 있는 거야. 그렇다면 내가 회사를 그만두고 혼자 일한다면 1억 5천 이상을&nbsp;벌 수 있는 사내가 되겠군. 그리고 이런 생각은 이해진 의장님의 이야기와는 반대였고&nbsp;저는 정말 궁금했습니다.내가 나만의 서비스를 만든다면 결과가 어떨까? 내 실력은 진짜일까 가짜일까.남이 만든 회사가 아니라 내가 창조해낸 제품으로 단 돈 만원이라도 벌어보고 싶다. 딱 만원만 벌고 실패해도 좋으니 내 진짜 실력이라는 걸&nbsp;테스트해보고 싶어. --- 어릴 때 스포츠 선수들이 연봉 때문에 재계약을 안 하고 싸우는 것을 보면 이상했습니다.돈을 저렇게 많이 받는데 그깟 몇 프로 더 받으려고 저렇게 싸워가면서 뻐팅긴다고?이런 질문을 어른들에게 하면&nbsp;어김없이 이런 대답이 돌아왔습니다."스포츠 선수들은 연봉을 실력으로 생각하는 거야. 자기&nbsp;실력을 인정받고 싶은 거지." 이제는 조금 이해할 수 있을 것 같습니다.이 세상에서 진실을 테스트할 수 있는 것 중&nbsp;돈 만한 게 없다는 걸 깨닫게 되었거든요.내 음식이 맛있다 맛없다 하는 말은 별로 중요하지 않습니다. 손님들이 지갑을 열어 기꺼이 지불해주는 돈이 진실인 것입니다. 이런 관점으로 바라보면 본인의 연봉이 곧 그 업에서의 실력이라고 말할 수 있습니다. --- 저는 결국 궁금증을 풀어냈습니다. 1. 이해진 의장님이 한 말은 사실이었습니다.제가 만든 앱은 하루에 1명도 설치하지 않은 날들이 많았습니다. 너무 우울해서 독한 술로 슬픈 패배감을 달래곤 했습니다. 마음이 어찌나 쓰린지 맥주 같은 술로는 달래지지 않더군요. 2. 회사에서 수수료를 떼어간다는 제 생각은 옳았습니다.회사에서 연봉 1억을 받는다면 회사를 그만두면 같은 노력으로 그 이상을 벌 잠재력을 가지고 있습니다.사람들이 많이 오해하는 부분은 '같은 노력' 부분인 것 같습니다.적어도 회사에서 하는 만큼은 일해야 하는데 덜 노력하고 더 벌려고 하니 쉽지가 않습니다. 3. 이 잠재력은 쉽게 발현되지 않습니다.최소한 1년. 통상 3년 정도는 해봐야 결과가 나옵니다. 10년이 걸릴 수도 있습니다.사람들은 충분한 잠재력을 가지고 있지만 결과가 나오기 전에 포기합니다.하지만 이 날 이해진 의장님은 또 한 가지 말씀을 해주셨습니다."성공은요, 실패하고 실패하다가 더 물러설 곳 없는 마지막 한 걸음에 나오는 거예요." 이 말은 제가 포기하지 않을 수 있게 도와줬습니다. 4. 저는 실력이 있는 사람이었습니다.이걸 알게 된 것이 가장 큰 소득입니다.4년의 노력 끝에 드디어 회사 다닐 때의 연봉을 넘어섰습니다.더 이상 제 자신에 대해 의심하지 않게 된 것이 너무너무 기쁩니다.저는 스스로의 힘으로 세상에 가치를 만들어 낼 수 있고 돈을 벌 수 있는 존재라는 것을 깨닫게 되니 그제야 평안을 얻게 되었달까요? 더 이상 다른 사람들이 부럽지 않게 되었습니다. 본인이 진짜 얼마짜리 사람인지 알고 싶나요?회사를 그만두고 혼자서 도전해보는 것만큼 좋은 방법도 없는 것 같습니다.어쩌면 회사는 자신의 온전한 가치를 드러낼 수 없게 상한선을 막고 있는 존재 아닐까 하는 생각을 합니다.이 울타리를 깨고 나와야만 자신을 테스트해볼 수 있습니다.외롭고 고된 길이지만 도전할만한 가치가 있습니다.이 길은 자기가 누구인지&nbsp;찾아가는 과정이고 그 열매는 너무 달콤하거든요.이제야 저는 저를 찾았습니다.

나는 얼마짜리 사람인가?

많은 공감과 위로가 되는 글이네요. 저도 회사를 나와서 이용자가 하루에 몇명 안되는 서비스를 개발 운영하고 있는데, 참 위로가 많이 되네요.
본인을 찾게 되기까지 4년의 시간에 축하를 보내고, 앞으로 더욱 번창하실 개발자님의 미래를 응원 합니다.
댓글 쓰다 다시 글쓴이를 보니 예전에 본 글 주인이시네요. 글쓴이님 글 보고 용기를 내서 창업했습니다~ 좋은 글 감사합니다.

켄트 벡의 'Tidy First?'는 Test-Driven Development (TDD)의 창시자로 유명한 그가 코드 정리에 대한 시각을 제시하는 저서입니다. 이 책은 개발 전 코드 '정리(Tidy)'를 먼저 해야할지? 에 대한 개념을 경제학적 관점에서 최적 시점과 방법론을 제시하는데요.

본 저서는 코드 정리에 대한 실용적 지침도 제공하지만 흥미로운 부분은 이론적 접근입니다. 벡은 경제 이론과 시간 가치의 개념을 소프트웨어 개발에 적용하여, 코드 정리의 경제학을 설명합니다.

경제학에서 '돈의 시간 가치' 이론은 현재의 자금이 미래의 동일 금액보다 더 가치 있다는 개념을 설명합니다. 이는 인플레이션과 현재 자금의 투자 가능성 때문인데요. 벡은 이 개념을 소프트웨어 개발에 적용하여, '수익 창출(돈 벌기)'을 새로운 기능 개발에, '비용 지출(돈 쓰기)'을 코드 정리 및 리팩토링에 비유합니다.

이러한 맥락에서 돈의 시간 가치는 '코드 정리를 먼저 하기 보다는 나중에 하는 것을 권장합니다' 그러나 이는 절대적 규칙이 아닌, 상황에 따른 전략적 선택의 문제로 봅니다. 돈을 번 후에 그 돈을 적절하게 관리하지 않으면, 결국 미래의 비용이 더 커질 수 있기 때문입니다. 개발 과정에서 '새 기능 개발 vs. 코드 정리'의 선택은 프로젝트의 현 상태와 장기 계획에 따라 달라져야 한다고 주장합니다.

단기적으로는 새 기능 개발이 더 가치 있어 보일 수 있으나, 장기적으로는 코드 정리가 더 큰 가치를 창출할 수 있습니다. 따라서 벡은 상황에 따른 유연한 접근을 권장합니다. 때로는 새 기능 개발이, 때로는 코드 정리가 우선순위가 될 수 있습니다. 따라서 이 책은 기능 개발 전 코드 정리가 필요한 시점과 그렇지 않은 시점을 구분하는 방법도 제시합니다.

개발자들에게 기능 개발(단기적 이익)과 리팩토링(장기적 가치) 시기는 늘 고민되는 포인트인데요. 이러한 균형을 어떻게 가져가야할지 궁금하신 분들에게 이 책을 추천합니다.

본 저서는 간결하고 함축적인 내용으로 구성되어 있어 빠른 시간 내에 내용을 파악할 수 있습니다. 따라서 가급적 근처 도서관이나 전자도서관을 통해 보셔도 좋을것 같습니다.

켄트 벡의 'Tidy First?'는 Test-Driven Development (TDD)의 창시자로 유명한 그가 코드 정리에 대한 시각을 제시하는 저서입니다. 이 책은 개발 전 코드 '정리(Tidy)'를 먼저 해야할지? 에 대한 개념을 경제학적 관점에서 최적 시점과 방법론을 제시하는데요. 본 저서는 코드 정리에 대한 실용적 지침도 제공하지만 흥미로운 부분은 이론적 접근입니다. 벡은 경제 이론과 시간 가치의 개념을 소프트웨어 개발에 적용하여, 코드 정리의 경제학을 설명합니다. 경제학에서 '돈의 시간 가치' 이론은 현재의 자금이 미래의 동일 금액보다 더 가치 있다는 개념을 설명합니다. 이는 인플레이션과 현재 자금의 투자 가능성 때문인데요. 벡은 이 개념을 소프트웨어 개발에 적용하여, '수익 창출(돈 벌기)'을 새로운 기능 개발에, '비용 지출(돈 쓰기)'을 코드 정리 및 리팩토링에 비유합니다. 이러한 맥락에서 돈의 시간 가치는 '코드 정리를 먼저 하기 보다는 나중에 하는 것을 권장합니다' 그러나 이는 절대적 규칙이 아닌, 상황에 따른 전략적 선택의 문제로 봅니다. 돈을 번 후에 그 돈을 적절하게 관리하지 않으면, 결국 미래의 비용이 더 커질 수 있기 때문입니다. 개발 과정에서 '새 기능 개발 vs. 코드 정리'의 선택은 프로젝트의 현 상태와 장기 계획에 따라 달라져야 한다고 주장합니다. 단기적으로는 새 기능 개발이 더 가치 있어 보일 수 있으나, 장기적으로는 코드 정리가 더 큰 가치를 창출할 수 있습니다. 따라서 벡은 상황에 따른 유연한 접근을 권장합니다. 때로는 새 기능 개발이, 때로는 코드 정리가 우선순위가 될 수 있습니다. 따라서 이 책은 기능 개발 전 코드 정리가 필요한 시점과 그렇지 않은 시점을 구분하는 방법도 제시합니다. 개발자들에게 기능 개발(단기적 이익)과 리팩토링(장기적 가치) 시기는 늘 고민되는 포인트인데요. 이러한 균형을 어떻게 가져가야할지 궁금하신 분들에게 이 책을 추천합니다. 본 저서는 간결하고 함축적인 내용으로 구성되어 있어 빠른 시간 내에 내용을 파악할 수 있습니다. 따라서 가급적 근처 도서관이나 전자도서관을 통해 보셔도 좋을것 같습니다.

"Tidy First?: 켄트 벡의 코드 정리 경제학

AHA 프로그래밍 원칙은 "성급한 추상화를 피하라(Avoid Hasty Abstraction)"를 의미합니다. 이 원칙이 유지보수 가능한 테스트 작성에 어떻게 적용되는지에 대해 제 나름의 의견이 있습니다. 제가 실제로 본 대부분의 테스트에서는 추상화 스펙트럼의 양극단에 있었습니다. ANA(Absolutely No Abstraction, 추상화하지 않음)...

(번역) AHA 테스팅 💡

오늘 소개해드릴 글은 네이버의 최지우님이 번역해주신 글입니다.

이전에 발행되었던 Eunbin Kim 님의DRY - 잘못된 추상화의 일반적인 원인글을 흥미롭게 읽어보셨나요? 오늘 소개해드릴 글의 저자인 Kent C.Dodds도 비슷하게 "성급한 추상화를 피하고 나쁜 추상화보다는 반복이 낫다"라는 점을 강조해왔습니다.

그렇다면, 추상화는 언제, 어떤 기준으로, 그리고 어떤 효과를 위해 진행할 수 있을까요?
이번 글에서는 테스트 코드를 중심으로, 추상화되지 않은 코드에서 시작해 점진적으로 추상화를 진행하며 어떤 효과를 얻을 수 있는지 설명합니다. 이 글을 통해 추상화를 해야 할 시점과 기준, 그리고 신중한 추상화의 중요성을 함께 알아보시기 바랍니다. 🙂

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

오늘 소개해드릴 글은 네이버의 최지우님이 번역해주신 글입니다. 이전에 발행되었던 Eunbin Kim 님의DRY - 잘못된 추상화의 일반적인 원인글을 흥미롭게 읽어보셨나요? 오늘 소개해드릴 글의 저자인 Kent C.Dodds도 비슷하게 "성급한 추상화를 피하고 나쁜 추상화보다는 반복이 낫다"라는 점을 강조해왔습니다. 그렇다면, 추상화는 언제, 어떤 기준으로, 그리고 어떤 효과를 위해 진행할 수 있을까요?이번 글에서는 테스트 코드를 중심으로, 추상화되지 않은 코드에서 시작해 점진적으로 추상화를 진행하며 어떤 효과를 얻을 수 있는지 설명합니다. 이 글을 통해 추상화를 해야 할 시점과 기준, 그리고 신중한 추상화의 중요성을 함께 알아보시기 바랍니다. 🙂 글 링크: https://bit.ly/3M19WGR

Medium

AHA 테스팅 💡

개발 업무를 하다 보면, 해당 프로그래밍 언어에 익숙해져야 하는 건 물론이지만,

그 전에 영어에 익숙해져야 하는 게 기본이겠죠?

저는 학창시절에 영어를 그렇게 열심히 공부하지 않아서, 고생을 많이 한 편인데,
이 고생은 경력이 쌓일 수록 '영어로 커뮤니케이션이 필요한 때' 가 많아져서 더 어려움을 겪게 되는 것 같아요.

길벗에서 '개발자가 영어도 잘해야 하나요?' 란 책을 마침 보내주셔서 읽어보았는데,
업무에서 부족한 영어실력으로 어려움을 겪고 있거나, 조금 더 영어에 익숙해졌으면 하는 소망을 가지고 있는 분들이 있다면 도움이 많이 될 책인 것 같아요.

책 크기도 얇고 작아서, 출퇴근 길에 조금씩 읽기에도 좋을 듯 해요.

책은 크게
1. 개발자 영어 학습을 위한 기초 준비
 2. 소프트웨어 개발 단계별 실무 영어
 3. 소프트웨어 개발 분야별 실무 영어
 4. 개발자 비즈니스 실전 영어
 5. 미국 대학원(CS) 진학을 위한 영어
 6. 해외 개발자 취업을 위한 영어
 7. 개발자를 위한 영어 사전
챕터로 이루어져 있는데요.

제가 책에서 가장 좋았던 부분은,
 * 간혹 레딧등 해외 기술 커뮤니티나 GitHub PR 에서 사용되는 약어들(FYI, BTW, YAGNI...) 에 대한 설명
 * AWS 등 Service Provider에 영문으로 Support Case를 쓸 때 참고할 수 있는 현재 문제되는 (장애상황, 특정 이슈로 개발이 지연되는)상황을 설명하기 위한 표현
 * 회의나, 업무 요청에서 정중하게 상대방의 양해를 구하며, 요청을 할 수 있는 표현
 * 실전 예제로 설명된 영어권 IT 기업의 기술인터뷰에서 사용할 수 있는 간결한 문법들
 * 고객에게 이메일 보내는 법 등

업무를 하면서 누구나 한번쯤 영어의 어려움으로 부딪혔을 법한 예제들과 표현으로 책이 쓰여져있다는 부분이었어요.

특히 3장 개발분야별 영어에서는 프론트엔드, 백엔드, DB, 모바일 어플리케이션 개발 등에서 동료와 커뮤니케이션을 위해 사용할 수 있는 표현들이 예제로 나열되어 있어서 영어로 PR 리뷰를 진행하는 오픈소스에 참여하거나, 해외 동료들과 프로젝트를 함께하는 분들에게도 도움이 될 것 같아요.

생각해보면 한국어로도 명사는 계속 바뀌지만, 업무를 하다보면 반복되는 표현들이 있고, 한국에서 쭉 개발을 하다, 해외로 떠나 개발을 계속 하시는 저자 분이 그런 가려운 부분을 잘 긁어주셨다는 생각이 들어요.

물론 책 한권으로 비즈니스 영어를 전부 마스터 할 수는 없겠지만, 어디서 부터 '개발자를 위한 영어공부' 를 시작해야 할지 감을잡지 못해 고민이거나, 매일 조금씩 업무에서 사용할법한 영어 표현들을 공부하고자 마음먹은 분들이 있다면 '개발자가 영어도 잘해야 하나요?' 로 시작해보면 어떨까 하고 생각했어요.

저는 8월부터 휴직 중에 있는데, 이 기간동안 영어공부도 해야지! 하고 마음먹고 있다가 마침 좋은 책을 보내주셔서 쉬는 틈틈이 읽어보고 있어요. 프로그래밍 언어만큼이나, 더 공부하고 익숙해질수록 나의 가능성을 넓혀주는 영어공부, 미루지말고 지금부터 꾸준히 시작해보면 어떨까요?

개발 업무를 하다 보면, 해당 프로그래밍 언어에 익숙해져야 하는 건 물론이지만, 그 전에 영어에 익숙해져야 하는 게 기본이겠죠? 저는 학창시절에 영어를 그렇게 열심히 공부하지 않아서, 고생을 많이 한 편인데,이 고생은 경력이 쌓일 수록 '영어로 커뮤니케이션이 필요한 때' 가 많아져서 더 어려움을 겪게 되는 것 같아요. 길벗에서 '개발자가 영어도 잘해야 하나요?' 란 책을 마침 보내주셔서 읽어보았는데,업무에서 부족한 영어실력으로 어려움을 겪고 있거나, 조금 더 영어에 익숙해졌으면 하는 소망을 가지고 있는 분들이 있다면 도움이 많이 될 책인 것 같아요. 책 크기도 얇고 작아서, 출퇴근 길에 조금씩 읽기에도 좋을 듯 해요. 책은 크게1. 개발자 영어 학습을 위한 기초 준비<ol start="2"><li>소프트웨어 개발 단계별 실무 영어</li><li>소프트웨어 개발 분야별 실무 영어</li><li>개발자 비즈니스 실전 영어</li><li>미국 대학원(CS) 진학을 위한 영어</li><li>해외 개발자 취업을 위한 영어</li><li>개발자를 위한 영어 사전</li></ol>챕터로 이루어져 있는데요. 제가 책에서 가장 좋았던 부분은,<ul ><li>간혹 레딧등 해외 기술 커뮤니티나 GitHub PR 에서 사용되는 약어들(FYI, BTW, YAGNI...) 에 대한 설명</li><li>AWS 등 Service Provider에 영문으로 Support Case를 쓸 때 참고할 수 있는 현재 문제되는 (장애상황, 특정 이슈로 개발이 지연되는)상황을 설명하기 위한 표현</li><li>회의나, 업무 요청에서 정중하게 상대방의 양해를 구하며, 요청을 할 수 있는 표현</li><li>실전 예제로 설명된 영어권 IT 기업의 기술인터뷰에서 사용할 수 있는 간결한 문법들</li><li>고객에게 이메일 보내는 법 등</li></ul> 업무를 하면서 누구나 한번쯤 영어의 어려움으로 부딪혔을 법한 예제들과 표현으로 책이 쓰여져있다는 부분이었어요. 특히 3장 개발분야별 영어에서는 프론트엔드, 백엔드, DB, 모바일 어플리케이션 개발 등에서 동료와 커뮤니케이션을 위해 사용할 수 있는 표현들이 예제로 나열되어 있어서 영어로 PR 리뷰를 진행하는 오픈소스에 참여하거나, 해외 동료들과 프로젝트를 함께하는 분들에게도 도움이 될 것 같아요. 생각해보면 한국어로도 명사는 계속 바뀌지만, 업무를 하다보면 반복되는 표현들이 있고, 한국에서 쭉 개발을 하다, 해외로 떠나 개발을 계속 하시는 저자 분이 그런 가려운 부분을 잘 긁어주셨다는 생각이 들어요. 물론 책 한권으로 비즈니스 영어를 전부 마스터 할 수는 없겠지만, 어디서 부터 '개발자를 위한 영어공부' 를 시작해야 할지 감을잡지 못해 고민이거나, 매일 조금씩 업무에서 사용할법한 영어 표현들을 공부하고자 마음먹은 분들이 있다면 '개발자가 영어도 잘해야 하나요?' 로 시작해보면 어떨까 하고 생각했어요. 저는 8월부터 휴직 중에 있는데, 이 기간동안 영어공부도 해야지! 하고 마음먹고 있다가 마침 좋은 책을 보내주셔서 쉬는 틈틈이 읽어보고 있어요. 프로그래밍 언어만큼이나, 더 공부하고 익숙해질수록 나의 가능성을 넓혀주는 영어공부, 미루지말고 지금부터 꾸준히 시작해보면 어떨까요?

'개발자가 영어도 잘해야 하나요?' 를 읽고...

소프트웨어 개발시 설계부터 잘해야한다는 말을 나는 반대한다.

어설프게 설계부터 먼저하면 나중에 고통 받는 일이 더 많아진다. 처음부터 완성되어 있는 설계가 어딨나. 많은 메이저 소프트웨어들이 처음 설계 보면 겁나 구리고, 그래서 하위 호환을 무시하고 완전히 새로운 패러다임으로 넘어가는 것이 비일비재하다.

분야에 따라 다를 수 있지만, 보통 소프트웨어 설계는 구현에서 따라오는 것으로 단계적으로 진행되는 것이지, 설계부터 시작하는 건 패망의 지름길이다.

더군다나 코딩 속도가 빨라지고 자동화되는 AI 시대에 오히려 설계는 구현 다음이 될 수 밖에 없다. 왜냐하면 구현을 오늘 당장 해 볼 수 있기 때문에 구현을 먼저하고 이를 토대로 설계하는 것이 훨씬 나은 선택이다. 실험적 설계라고 한다.

설계가 가장 중요하고 설계부터 시작해야한다는 건 컨설팅 업체에게나 유리한 맥락이다.

소프트웨어 개발시 설계부터 잘해야한다는 말을 나는 반대한다. 어설프게 설계부터 먼저하면 나중에 고통 받는 일이 더 많아진다. 처음부터 완성되어 있는 설계가 어딨나. 많은 메이저 소프트웨어들이 처음 설계 보면 겁나 구리고, 그래서 하위 호환을 무시하고 완전히 새로운 패러다임으로 넘어가는 것이 비일비재하다. 분야에 따라 다를 수 있지만, 보통 소프트웨어 설계는 구현에서 따라오는 것으로 단계적으로 진행되는 것이지, 설계부터 시작하는 건 패망의 지름길이다. 더군다나 코딩 속도가 빨라지고 자동화되는 AI 시대에 오히려 설계는 구현 다음이 될 수 밖에 없다. 왜냐하면 구현을 오늘 당장 해 볼 수 있기 때문에 구현을 먼저하고 이를 토대로 설계하는 것이 훨씬 나은 선택이다. 실험적 설계라고 한다. 설계가 가장 중요하고 설계부터 시작해야한다는 건 컨설팅 업체에게나 유리한 맥락이다.

소프트웨어 개발시 설계부터 잘해야한다는 말을 나는 반대한다.

어

누구나 축구할 때 공격을 하고 싶어 합니다. 제일 재밌으니까. 모든 스포트라이트를 받으니까. 골을 넣는 것만큼 짜릿한 게 없으니까.

레거시 처리 개발자

카카오에 처음 입사했을 때 무슨 일을 하고 싶냐고 물어봐서 카톡 서버를 하겠다고 했습니다.
가장 핵심 서비스니까.
가장 중요한 일을 해서 내가 스포트라이트를 다 받아야지.

어려운 일 투성이라 적응하는 데 시간이 걸렸습니다.
6개월 정도 잠 못 자고 고생한 후에야 맘이 좀 편안해졌던 기억이 납니다.

핵심적인 팀에서 일하고 있는 건 분명했는데…
실제로 하고 있는 일은 짜친 일 투성이였습니다.

서버 교체하기.
어드민 만들기.
스팸 찾아내서 처리하기.
카톡 더보기에 배너 달아주기.
이런 Api 만들어 줄 수 있냐는 상담해 주기.
그리고 끝이 없는 고객 문의와 장애 처리.

아, 이런 일하려고 지원한 게 아니었는데.
이래서 신기능 개발은 언제 해?

찾아오는 사람들은 항상 많았습니다.
어떤 날은 두세 팀이 동시에 찾아와서 줄 세워 놓고 얘기하기도 했습니다.

뭔가 핵심적인 일을 하는 것 같긴 한데…
왜 이렇게 짜친 느낌이 들지?
신규 기능을 만들기 보다 서비스를 지키기 위해 더 많은 힘을 쏟았습니다.
이거 공격수가 아니라 완전히 수비수잖아?

이렇게 몇 년 하다가 공격수를 하겠다고 말했습니다.
나도 신규 서비스 만들고 싶다구!
그리고 카카오 플레이스를 만들었습니다.
대차게 말아 먹었습니다.
풀타임 출전, 0골.

수비수를 한다는 것이 얼마나 가치 있는 일이고 중요한지는 나중에 알게 되었습니다.
든든한 수비수들이 있어서 공격도 마음껏 할 수 있는 거라는걸.
공격수가 대차게 말아 먹어도 그들 덕분에 지지 않을 수 있다는 걸.

중요한 일을 하고 싶다는 마음이야 당연한 것이지만…
공격수가 가장 중요한 것이라는 생각은 잘못된 것이었습니다.

축구에서처럼 서비스 회사에서도 서비스를 만들어 나가는 사람들과 지켜 내는 사람들이 있습니다.
레거시를 지켜내는 사람들은 좀처럼 스포트라이트를 받지 못합니다. 백업하는 존재로 인식될 뿐.
최근에 김민재라는 국가대표 수비수를 보며 자란 아이들은 축구할 때 수비수를 하고 싶다는 말을 한답니다.
지켜내는 사람들이 지금보다 나은 대우를 받고 멋진 모습을 보여 주면 새로 들어온 사람들도 레거시를 다루는 일을 기꺼이 하려 하지 않을까?

요즘에 축구할 땐 수비수를 합니다.
수비가 중요한 것뿐만이 아니라 심지어는 재미까지 있다는 것도 알게 되었습니다.
다시 회사에 가면 이제는 수비수를 잘 즐길 수 있을 것 같습니다.
가치 있고 중요한 일을 하는 거니까. 그런 마음으로 잘 생각해 보면 이 일도 참 재밌거든.

https://jeho.page/essay/2024/08/08/defense-fun.html

카카오에 처음 입사했을 때 무슨 일을 하고 싶냐고 물어봐서 카톡 서버를 하겠다고 했습니다. 가장 핵심 서비스니까. 가장 중요한 일을 해서 내가 스포트라이트를 다 받아야지. 어려운 일 투성이라 적응하는 데 시간이 걸렸습니다. 6개월 정도 잠 못 자고 고생한 후에야 맘이 좀 편안해졌던 기억이 납니다. 핵심적인 팀에서 일하고 있는 건 분명했는데… 실제로 하고 있는 일은 짜친 일 투성이였습니다. 서버 교체하기. 어드민 만들기. 스팸 찾아내서 처리하기. 카톡 더보기에 배너 달아주기. 이런 Api 만들어 줄 수 있냐는 상담해 주기. 그리고 끝이 없는 고객 문의와 장애 처리. 아, 이런 일하려고 지원한 게 아니었는데. 이래서 신기능 개발은 언제 해? 찾아오는 사람들은 항상 많았습니다. 어떤 날은 두세 팀이 동시에 찾아와서 줄 세워 놓고 얘기하기도 했습니다. 뭔가 핵심적인 일을 하는 것 같긴 한데… 왜 이렇게 짜친 느낌이 들지? 신규 기능을 만들기 보다 서비스를 지키기 위해 더 많은 힘을 쏟았습니다. 이거 공격수가 아니라 완전히 수비수잖아? 이렇게 몇 년 하다가 공격수를 하겠다고 말했습니다. 나도 신규 서비스 만들고 싶다구! 그리고 카카오 플레이스를 만들었습니다. 대차게 말아 먹었습니다. 풀타임 출전, 0골. 수비수를 한다는 것이 얼마나 가치 있는 일이고 중요한지는 나중에 알게 되었습니다. 든든한 수비수들이 있어서 공격도 마음껏 할 수 있는 거라는걸. 공격수가 대차게 말아 먹어도 그들 덕분에 지지 않을 수 있다는 걸. 중요한 일을 하고 싶다는 마음이야 당연한 것이지만… 공격수가 가장 중요한 것이라는 생각은 잘못된 것이었습니다. 축구에서처럼 서비스 회사에서도 서비스를 만들어 나가는 사람들과 지켜 내는 사람들이 있습니다. 레거시를 지켜내는 사람들은 좀처럼 스포트라이트를 받지 못합니다. 백업하는 존재로 인식될 뿐. 최근에 김민재라는 국가대표 수비수를 보며 자란 아이들은 축구할 때 수비수를 하고 싶다는 말을 한답니다. 지켜내는 사람들이 지금보다 나은 대우를 받고 멋진 모습을 보여 주면 새로 들어온 사람들도 레거시를 다루는 일을 기꺼이 하려 하지 않을까? 요즘에 축구할 땐 수비수를 합니다. 수비가 중요한 것뿐만이 아니라 심지어는 재미까지 있다는 것도 알게 되었습니다. 다시 회사에 가면 이제는 수비수를 잘 즐길 수 있을 것 같습니다. 가치 있고 중요한 일을 하는 거니까. 그런 마음으로 잘 생각해 보면 이 일도 참 재밌거든. https://jeho.page/essay/2024/08/08/defense-fun.html

K리그 프로그래머

Intense competition among juniors, AI taking over jobs, and ongoing crises - why these shouldn't... Tagged with productivity, beginners, career, ai.

Starting from Scratch in IT in 2024: Things you shouldn't worry about

모두에게 "처음" 이라는 순간이 존재하는데, 그걸 알면서도 마음이 불편한건 어쩔 수 없는 것 같습니다. 이제 개발 분야에 처음 입문하려는 분들에게는 시니어들은 모두 "그땐 그런거야" 라고 하지만, 아무리 그런 조언을 들어도 걱정스러운 것들이 참 많은 것 같습니다. 거기다 유튜브며 트위터며, 오히려 그 걱정을 자극적인 소재로 '이런 것도 잘 모르고, 경험 없는 나는 어쩌지...?' 라는 공포심마저 들게 하는 안타까운 상황들도 종종 보이곤 합니다.

여기 10년을 일하며 느낀 미리 걱정 안했어도 되는 4가지에 정리한 글이 있어 공유해봅니다.

 * 경쟁에 대한 두려움 : IT 분야는 경쟁이 치열하지만, 꾸준히 노력하고 자신을 발전시키는 사람에게는 오히려 기회가 더 많이 찾아옵니다! 자신만의 강점을 찾고 집중하세요.
 * AI에 대한 걱정 : AI는 적이 아니라 도구입니다. AI를 활용해 학습과 생산성을 높이고, 더 나은 결과를 만들어낼 수 있습니다.
 * 경제적 불안 : 경제 위기에도 불구하고, 기술이 뛰어난 인재는 항상 수요가 있습니다. 자신의 기술을 끊임없이 업데이트하고 발전시키는 것이 중요합니다.
 * 개인적인 노력과 지속적인 학습 : 성공적인 IT 커리어를 위해서는 끊임없는 학습과 노력이 필요합니다. 새로운 기술과 트렌드를 따라가며 자신을 꾸준히 발전시키세요.
   
   
기술 변화, 경제적 불안, 경쟁은 시간이 지나도 사실 변치 않는 도전 과제인 것 같습니다. 불안함을 고통이 아닌 나를 움직일 수 있는 수단으로 바꾸어 끊임없이 노력하는 자세가 나의 10년 아니 더 긴 시간을 바꿀 수 있는 발판이 되어줄 것입니다.

https://dev.to/vorniches/starting-from-scratch-in-it-in-2024-things-you-shouldnt-worry-about-4p17

모두에게 "처음" 이라는 순간이 존재하는데, 그걸 알면서도 마음이 불편한건 어쩔 수 없는 것 같습니다. 이제 개발 분야에 처음 입문하려는 분들에게는 시니어들은 모두 "그땐 그런거야" 라고 하지만, 아무리 그런 조언을 들어도 걱정스러운 것들이 참 많은 것 같습니다. 거기다 유튜브며 트위터며, 오히려 그 걱정을 자극적인 소재로 '이런 것도 잘 모르고, 경험 없는 나는 어쩌지...?' 라는 공포심마저 들게 하는 안타까운 상황들도 종종 보이곤 합니다. 여기 10년을 일하며 느낀 미리 걱정 안했어도 되는 4가지에 정리한 글이 있어 공유해봅니다. <ul ><li>경쟁에 대한 두려움 : IT 분야는 경쟁이 치열하지만, 꾸준히 노력하고 자신을 발전시키는 사람에게는 오히려 기회가 더 많이 찾아옵니다! 자신만의 강점을 찾고 집중하세요.</li><li>AI에 대한 걱정 : AI는 적이 아니라 도구입니다. AI를 활용해 학습과 생산성을 높이고, 더 나은 결과를 만들어낼 수 있습니다.</li><li>경제적 불안 : 경제 위기에도 불구하고, 기술이 뛰어난 인재는 항상 수요가 있습니다. 자신의 기술을 끊임없이 업데이트하고 발전시키는 것이 중요합니다.</li><li>개인적인 노력과 지속적인 학습 : 성공적인 IT 커리어를 위해서는 끊임없는 학습과 노력이 필요합니다. 새로운 기술과 트렌드를 따라가며 자신을 꾸준히 발전시키세요. </li></ul>기술 변화, 경제적 불안, 경쟁은 시간이 지나도 사실 변치 않는 도전 과제인 것 같습니다. 불안함을 고통이 아닌 나를 움직일 수 있는 수단으로 바꾸어 끊임없이 노력하는 자세가 나의 10년 아니 더 긴 시간을 바꿀 수 있는 발판이 되어줄 것입니다. https://dev.to/vorniches/starting-from-scratch-in-it-in-2024-things-you-shouldnt-worry-about-4p17

DEV Community

처음부터 걱정하지 않았어도 되었던 것들

이걸 확 관둬? 말어? 사직서를 던질지, 한 번 더 참을지 고민하고 있다면 주목. 하버드 경영 대학원이 발표한 퇴사할 때가 되었다는 지표를 준비했다. 아래 내용 중 과반수 이상에 '그렇다'는 답변이 나왔다면 이제 그곳을 떠나도 좋다.➊ 일이 나를 성장시키지 않는다운동선수들은 때때로 운동

하버드 석학이 알려주는, 회사 그만둘지 버틸지 구별하는 방법 5

1. 지금 회사에서 하는 일이 더 이상 내 성장에 도움이 되지 않는다고 느낄 때

2. 일에 대한 열망이 사라지고, 회사에서 더 이룰 것이 없다고 느낄 때

3. 몰입이 안 되고 회사에서 일을 하기 너무나 싫을 때

4. 가치관과 생각이 맞지 않아 회사에서 자꾸 나쁜 사람이 될 때

5. 신체적으로나 정신적으로 망가졌을 때

1. 지금 회사에서 하는 일이 더 이상 내 성장에 도움이 되지 않는다고 느낄 때 2. 일에 대한 열망이 사라지고, 회사에서 더 이룰 것이 없다고 느낄 때 3. 몰입이 안 되고 회사에서 일을 하기 너무나 싫을 때 4. 가치관과 생각이 맞지 않아 회사에서 자꾸 나쁜 사람이 될 때 5. 신체적으로나 정신적으로 망가졌을 때

GQ korea

하버드 석학이 알려주는 퇴사 타이밍

Alexander Isora 👽 on X: "I stopped writing code entirely in 2024.

I only copy-paste code generated by AI ✌️🤓

How do I do that? 10 hints:

Hint 1: if you have a creative task such as code architecture, you want to use so called chain of thoughts. You add "Think step-by-step" to your prompt and enjoy a https://t.co/cVTTGBKFWs" / X

https://x.com/alexanderisorax/status/1819671375759487270

원문 작성자는 2024년 코드 작성을 멈추고 생성AI가 제공하는 코드만 복붙했다고 하네요.

그러면서 10가지 팁을 남겼습니다. 그중 5번 팁이 인상깊었습니다.

작업을 사람에게 설명하는것처럼 프롬프트를 작성하는데 시간을 보내라고 하네요.

조금더 이 작업을 쉽게하려면 생성AI가 도구가 아니라 공동작업자로 생각해야겠네요.

Hint 5: Use clear and specific prompts. The more precise and detailed your request, the better the AI can understand and generate the code you need. Include details about the desired functionality: input/output type, error handling, UI behaviour etc. Spend time on writing a good prompt like if you were spending time explaining your task to a human.

https://x.com/alexanderisorax/status/1819671375759487270 원문 작성자는 2024년 코드 작성을 멈추고 생성AI가 제공하는 코드만 복붙했다고 하네요. 그러면서 10가지 팁을 남겼습니다. 그중 5번 팁이 인상깊었습니다. 작업을 사람에게 설명하는것처럼 프롬프트를 작성하는데 시간을 보내라고 하네요. 조금더 이 작업을 쉽게하려면 생성AI가 도구가 아니라 공동작업자로 생각해야겠네요. Hint 5: Use clear and specific prompts. The more precise and detailed your request, the better the AI can understand and generate the code you need. Include details about the desired functionality: input/output type, error handling, UI behaviour etc. Spend time on writing a good prompt like if you were spending time explaining your task to a human.

X (formerly Twitter)

복붙 엔지니어의 등장

바로 좋은 태도입니다.

사전에 따르면 태도란 어떤 일이나 상황 따위를 대하는 마음가짐.
또는 그 마음가짐이 드러난 자세를 의미합니다.

모르는 문제나 상황에도 주눅이 들지 않는 마음가짐.
자신의 문제를 함께 해결해 줄 수 있는 사람을 찾아 나서는 자세.

연차가 많아도 자기 생각이 늘 정답은 아니란 걸 아는 마음가짐.
모르는 건 솔직하게 물어보는 자세.

모른다고 말해도 사람들이 자신을 이해해 줄 거라고 믿는 마음가짐.
아는 척하지 않고 아는 것만을 말하고, 모르는 사람을 무시하지 않는 자세.

상황과 사람을 탓하지 않는 마음가짐.
할 수 있는 일을, 하던 대로 꾸준히 해내는 자세.

좋은 태도를 가진 사람이 뛰어난 실력을 갖춘 사람보다 낫습니다.
아니, 어쩌면 좋은 태도가 뛰어난 실력을 만드는 것일지도 모릅니다.

바로 좋은 태도입니다. 사전에 따르면 태도란 어떤 일이나 상황 따위를 대하는 마음가짐.또는 그 마음가짐이 드러난 자세를 의미합니다. 모르는 문제나 상황에도 주눅이 들지 않는 마음가짐.자신의 문제를 함께 해결해 줄 수 있는 사람을 찾아 나서는 자세. 연차가 많아도 자기 생각이 늘 정답은 아니란 걸 아는 마음가짐.모르는 건 솔직하게 물어보는 자세. 모른다고 말해도 사람들이 자신을 이해해 줄 거라고 믿는 마음가짐.아는 척하지 않고 아는 것만을 말하고, 모르는 사람을 무시하지 않는 자세. 상황과 사람을 탓하지 않는 마음가짐.할 수 있는 일을, 하던 대로 꾸준히 해내는 자세. 좋은 태도를 가진 사람이 뛰어난 실력을 갖춘 사람보다 낫습니다.아니, 어쩌면 좋은 태도가 뛰어난 실력을 만드는 것일지도 모릅니다.

실력보다 중요한 것

최근 LLM의 환각현상(Hallucination)을 줄이기 위한 대안으로 최근 떠오르는 방법론 중 하나는 "Abstention"입니다. 단어의 뜻은 "기권, 자제"인데요, 우리 말로는 "답변 포기"정도가 될 것 같습니다.

즉, LLM이 스스로가 불확실한 정보에 대해서는 답변을 거부할 수 있도록 하는 방법에 대한 연구인데요, 요즘 관련 연구가 많이 나오는 것 같습니다. 관심 있으신 분들은 시작하기 좋은 논문 3편을 아래에 소개해두었으니 간단하게 살펴보셔도 좋을 것 같습니다.

The Art of Refusal: A Survey of Abstention in Large Language Models
 * LLM의 답변 포기(Abstention) 방법에 대한 Survey Paper
 * 아래 세가지 관점을 기준으로 기존 연구를 분석합니다.
   * (1) The Query: 질문 자체의 모호성으로 답변 회피가 필요한 경우
   * (2) The Model: 모델 지식의 부족으로 답변 회피가 필요한 경우
   * (3) Human Values: 윤리적/사회적 가치 등의 이유로 답변 회피가 필요한 경우
 * https://arxiv.org/pdf/2407.18418

The Art of Saying No: Contextual Noncompliance in Language Models
 * 답변하지 않아도 되는(Noncompliance) 질문 유형을 세분화하고 관련 데이터셋을 제공
 * "(1) The Query" 유형에 해당하는 방법론과 데이터를 소개합니다.
 * AllenAI, University of Washington, Microsoft Research 등 굵직한 기관들이 참여한 논문이네요.
 * https://www.arxiv.org/pdf/2407.12043

R-Tuning: Instructing Large Language Models to Say ‘I Don’t Know’
 * Instruction Tuning 단계에서 모델이 Parametric Knowledge 를 벗어나는 질문에 대해서는 답변하지 않도록 하기 위해 1) 무엇을 모르는 지를 파악하고 2) 모르는 것에 대해서는 답변하지 않도록 학습하는 방법 제시
 * "(2) The Model" 유형에 해당하는 방법론을 제시합니다.
 * 최근 NAACL 2024에서 Outstanding Paper awards를 수상했어요.
 * https://aclanthology.org/2024.naacl-long.394/

최근 LLM의 환각현상(Hallucination)을 줄이기 위한 대안으로 최근 떠오르는 방법론 중 하나는 "Abstention"입니다. 단어의 뜻은 "기권, 자제"인데요, 우리 말로는 "답변 포기"정도가 될 것 같습니다. 즉, LLM이 스스로가 불확실한 정보에 대해서는 답변을 거부할 수 있도록 하는 방법에 대한 연구인데요, 요즘 관련 연구가 많이 나오는 것 같습니다. 관심 있으신 분들은 시작하기 좋은 논문 3편을 아래에 소개해두었으니 간단하게 살펴보셔도 좋을 것 같습니다. The Art of Refusal: A Survey of Abstention in Large Language Models<ul ><li>LLM의 답변 포기(Abstention) 방법에 대한 Survey Paper</li><li>아래 세가지 관점을 기준으로 기존 연구를 분석합니다.<ul ><li>(1) The Query: 질문 자체의 모호성으로 답변 회피가 필요한 경우</li><li>(2) The Model: 모델 지식의 부족으로 답변 회피가 필요한 경우</li><li>(3) Human Values: 윤리적/사회적 가치 등의 이유로 답변 회피가 필요한 경우</li></ul></li><li>https://arxiv.org/pdf/2407.18418</li></ul> The Art of Saying No: Contextual Noncompliance in Language Models<ul ><li>답변하지 않아도 되는(Noncompliance) 질문 유형을 세분화하고 관련 데이터셋을 제공</li><li>"(1) The Query" 유형에 해당하는 방법론과 데이터를 소개합니다.</li><li>AllenAI, University of Washington, Microsoft Research 등 굵직한 기관들이 참여한 논문이네요.</li><li>https://www.arxiv.org/pdf/2407.12043</li></ul> R-Tuning: Instructing Large Language Models to Say ‘I Don’t Know’<ul ><li>Instruction Tuning 단계에서 모델이 Parametric Knowledge 를 벗어나는 질문에 대해서는 답변하지 않도록 하기 위해 1) 무엇을 모르는 지를 파악하고 2) 모르는 것에 대해서는 답변하지 않도록 학습하는 방법 제시</li><li>"(2) The Model" 유형에 해당하는 방법론을 제시합니다.</li><li>최근 NAACL 2024에서 Outstanding Paper awards를 수상했어요.</li><li>https://aclanthology.org/2024.naacl-long.394/</li></ul>

🤐 LLM 분야의 떠오르는 화두: Abstention (기권)

VSCode에서 커서를 키보드로 자유자재로 제어하시려면 꼭 알고 계셔야 하는 필수 단축키를 정리해드리겠습니다. - 관련 포스팅: https://www.daleseo.com/vscode-cursor/ 목차: 0:00 소개 0:44 영역 선택하기 2:32 단어 단위로 점프 5:54 줄 맨 앞/뒤로 바로 이동 8:19 페이지 단위로 스크롤 12:28 파일 맨 위/아래로 바로 이동 14:02 정리 #vscode #단축키 #코드편집기#커서 #키보드

VSCode 오직 키보드로 커서 제어하기

VSCode에서 효과적으로 코드 편집을 하려면 무엇보다 마우스 커서(cursor)를 원하는 위치로 빠르게 이동하고 원하는 영역을 빠르게 선택하는 것이 매우 중요한데요. 양손으로 키보드로 타이핑을 하다가 커서를 옮기거나 드래그를 하기 위해서 잠깐 잠깐 한 손을 마우스나 트랙패트로 옮기는 것이 은근히 개발 생산성을 떨어뜨릴 수 있기 때문입니다.

이번 영상에서는 VSCode에서 커서를 키보드로 자유자재로 제어하시려면 꼭 알고 계셔야 하는 필수 단축키를 정리해드리겠습니다.

📺 동영상: https://youtu.be/N2R1tCKT0a8

VSCode에서 효과적으로 코드 편집을 하려면 무엇보다 마우스 커서(cursor)를 원하는 위치로 빠르게 이동하고 원하는 영역을 빠르게 선택하는 것이 매우 중요한데요. 양손으로 키보드로 타이핑을 하다가 커서를 옮기거나 드래그를 하기 위해서 잠깐 잠깐 한 손을 마우스나 트랙패트로 옮기는 것이 은근히 개발 생산성을 떨어뜨릴 수 있기 때문입니다. 이번 영상에서는 VSCode에서 커서를 키보드로 자유자재로 제어하시려면 꼭 알고 계셔야 하는 필수 단축키를 정리해드리겠습니다. 📺 동영상: https://youtu.be/N2R1tCKT0a8

YouTube

코드를 작성하며 반복을 줄이는 것은 기본적인 작업입니다. 하지만 이 글에서는 반복을 줄이기 위해 시도한 방법이 불러올 수 있는 잘못된 추상화의 예시를 설명하고 있습니다. 흔히 겪을 수 있는 사례를 예로 들고 있으니 스스로의 경험을 되돌아보며 읽어보시기 좋은 글입니다:)

[번역] DRY - 잘못된 추상화의 일반적인 원인

오늘 소개해드릴 글은 라인플러스의 김은빈님이 번역해주신 글입니다.

코드를 작성하며 반복을 줄이는 것은 기본적인 작업입니다. 이를 보통 DRY (Don’t Repeat Yourself) 라고 하는데요, 이 글에서는 이런 DRY를 위해 시도한 방법이 불러올 수 있는 잘못된 추상화의 예시를 설명하고 있습니다. DRY를 위해 작업하다가 어떻게 코드가 잘못 추상화되어 변경하기 어려운 코드가 되어가는지 술술 읽히는 글입니다.

개인적으로 이 글에서 들고있는 사례가 쉽게 겪을 수 있는 사례이기도 하고 저 또한 겪어봤던 일이어서 더욱 공감하며 읽을 수 있었습니다. 스스로의 경험을 되돌아보며 읽어보시면 좋을 것 같습니다:)

> 글 링크: https://velog.io/@eunbinn/dry-the-common-source-of-bad-abstractions

오늘 소개해드릴 글은 라인플러스의 김은빈님이 번역해주신 글입니다. 코드를 작성하며 반복을 줄이는 것은 기본적인 작업입니다. 이를 보통 DRY (Don’t Repeat Yourself) 라고 하는데요, 이 글에서는 이런 DRY를 위해 시도한 방법이 불러올 수 있는 잘못된 추상화의 예시를 설명하고 있습니다. DRY를 위해 작업하다가 어떻게 코드가 잘못 추상화되어 변경하기 어려운 코드가 되어가는지 술술 읽히는 글입니다. 개인적으로 이 글에서 들고있는 사례가 쉽게 겪을 수 있는 사례이기도 하고 저 또한 겪어봤던 일이어서 더욱 공감하며 읽을 수 있었습니다. 스스로의 경험을 되돌아보며 읽어보시면 좋을 것 같습니다:) &gt; 글 링크: https://velog.io/@eunbinn/dry-the-common-source-of-bad-abstractions

DRY - 잘못된 추상화의 일반적인 원인

Modern day UX research methods answer a wide range of questions. To help you know when to use which user research method, each of 20 methods is mapped across 3 dimensions and over time within a typical product-development process.

A Guide to Using User-Experience Research Methods

[UX방법론 선정, 세계적인 UX멘토 닐슨노먼그룹이 떠먹여 드립니다🥄]

✏️ "시작이 반이다" 라는 기억도 안 나는 어린 시절부터 듣던 말이 있습니다. 돌이켜 생각해보니 그만큼 시작의 첫 걸음을 신중하게 계획하여 내딛어야 한다는 말로 들립니다. UX리서처에게 있어선 문제 정의와 함께 어떤 UX방법론을 사용할지 정하는게 프로젝트의 첫 걸음이 되겠죠. 

✏️ 알맞은 UX방법론 선택을 도울 닐슨노먼그룹의 글을 소개합니다. 비슷비슷하게 느껴지는 방법론들 속에서 머리가 아팠다면 이 글을 참고해보시는게 어떨까요?

Nielsen Norman Group

Co-Founder, Coxwave

김주원

AI-Native 제품을 분석하고 개선하기 위한 Product-Analytics Tool을 만들고 있습니다.

User Researcher @CATCH

조민하

현재…
🔎취업포털 리서치 업무 담당
⛳UX리서치 공부중
과거…
📚철학/소비자광고심리학 전공
✏대입 논술 첨삭 조교
#UX리서처 #사용자조사 #정량적조사 #정성적조사 #인터뷰어 #조사통계분석 #콘텐츠기획 #팀플레이어 #끊임없이배우기

산학과제 학생연구책임자(Student Principal Investigator)

인턴

대리

기계항공공학 학사

산업공학과 삶향상기술연구실 석사과정

윤서연

Linked-In

기계공학을 전공하고 인간공학을 공부하는 리서처👩🏻‍💻
기계를 통해 사람을 돕고자 하며, 삶을 향상시키는 기술을 좋아합니다.
인간공학, UX, HRI🤖에 대한 이야기를 나눕니다. 
#끊임없이배우기 #문제를해결하는 #UX리서처

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필