반응형
반응형

생성형 AI를 도입한 소프트웨어 개발 작업에 인간 프로그래머와는 근본적으로 다른 실수가 포함된다는 사실은 잘 알려져 있다. 그럼에도 대부분의 기업에서 AI 코딩 실수를 수정하는 계획은 단순히 숙련된 인간 프로그래머를 루프에 투입하는 것에 의존하고 있다. 


숙련된 인간 프로그래머는 인간 프로그래머가 저지르는 실수와 지름길의 종류를 직관적으로 알고 있다. 하지만 소프트웨어가 소프트웨어를 만들 때 발생하는 실수의 종류를 찾아내는 훈련은 별도로 필요하다.

이러한 논의는 이르면 2026년부터 대부분의 개발자가 더 이상 코딩을 하지 않을 것으로 예상한다는 AWS CEO 매트 가먼의 발언으로 더욱 가속화되었다.
 
개발 도구 분야의 많은 업체는 AI 코딩 앱을 관리하기 위해 AI 앱을 사용하면 이 문제를 해결할 수 있다고 주장했다. 2번째 열차 사고의 신호탄이나 마찬가지다. 금융 대기업인 모건 스탠리조차도 AI를 사용해 AI를 관리하는 방법을 고민하고 있다.

현실적으로 안전하고 원격으로 실행 가능한 유일한 접근 방식은 생성형 AI 코딩 오류의 특성을 이해하도록 프로그래밍 관리자를 교육하는 것이다. 사실 AI 코딩 오류의 특성이 매우 다르다는 점을 고려할 때, 인간의 코딩 실수를 발견하는 데 익숙하지 않은 새로운 사람을 AI 코딩 관리자로 교육하는 것이 더 나을 수도 있다.

문제의 일부는 인간의 본성이다. 사람들은 차이를 확대하고 잘못 해석하는 경향이 있다. 관리자는 자신이 절대 하지 않을 실수를 사람이나 AI가 저지르는 것을 보면 그 실수가 코딩 문제에서 관리자보다 열등하다고 생각하는 경향이 있다.

하지만 자율 주행 차량에 비추어 가정해 보자. 통계적으로 자율주행차는 사람이 운전하는 자동차보다 훨씬 더 안전하다. 자동화된 시스템은 피로를 느끼지도 않고, 취하지도 않으며, 고의적으로 난폭해지지도 않는다.

하지만 자율주행차는 완벽하지 않다. 그리고 교통 체증으로 정차한 트럭을 전속력으로 들이받는 등의 실수를 저지르면 인간은 “나라면 저런 멍청한 짓은 절대 하지 않았을 텐데...인공지능을 믿을 수 없어”라고 반문하게 된다. (웨이모 주차 차량 참사는 꼭 봐야 할 동영상이다.)

하지만 자율주행차가 이상한 실수를 한다고 해서 인간 운전자보다 안전하지 않다는 의미는 아니다. 그러나 인간의 본성은 이러한 차이를 조정할 수 없다.

코딩 관리도 마찬가지다. 생성형 AI 코딩 모델은 매우 효율적일 수 있지만, 자칫 잘못하면 엉뚱한 방향으로 흘러갈 수 있다.
 

AI는 미친 외계인 프로그래머

SaaS 기업 쿼리팰(QueryPal) CEO인 데브 내그는 생성형 AI 코딩 작업을 해오면서 많은 기업 IT 경영진이 이 새로운 기술이 얼마나 다른지에 대해 준비가 되어 있지 않다고 느꼈다.

내그는 “마치 다른 행성에서 온 외계인처럼 이상한 실수를 많이 했다. 인간 개발자가 하지 않는 방식으로 코드가 잘못 작동한다. 마치 우리처럼 생각하지 않는 외계 지능처럼 이상한 방향으로 나아간다. AI는 병적으로 시스템을 조작할 방법을 찾아낼 것”이라고 말했다.

올해 ‘AI 보조 프로그래밍’을 포함해 여러 권의 AI 프로그래밍 책을 펴낸 톰 타울리에게 물어보자.

타울리는 “예를 들어 LLM에 코드 작성을 요청할 수 있으며, 때로는 원하는 작업을 수행하기 위해 프레임워크나 가상의 라이브러리 또는 모듈을 구성할 수도 있다”라고 말했다. (타울리는 LLM이 실제로는 새로운 프레임워크를 만드는 것이 아니라 그렇게 하는 척하는 것이라고 설명했다.)

타울리는 “(인간 프로그래머가) 미치지 않는 한, 가상의 라이브러리나 모듈을 만들어서 허공에서 만들어내지는 않을 것”이라고 지적했다.

이런 일이 발생하면 누구든 찾아보면 쉽게 발견할 수 있다. 타울리는 “직접 설치하려고 하면 아무것도 없다는 것을 알 수 있다. 이 경우 IDE와 컴파일러에서 오류가 발생한다"라고 설명했다.

실행 파일의 창의적인 제어를 포함해 애플리케이션 전체 코딩을 주기적으로 환각을 일으키는 시스템에 넘긴다는 생각은 끔찍한 접근 방식인 것 같다.

생성형 AI 코딩의 효율성을 활용하는 훨씬 더 좋은 방법은 프로그래머가 더 많은 작업을 수행할 수 있도록 돕는 도구로 사용하는 것이다. AWS의 가먼이 제안한 것처럼 인간을 배제하는 것은 자살 행위나 다름없다.

만약 생성형 AI 코딩 도구가 마음대로 돌아다니면서 백도어를 만들어 나중에 사람을 귀찮게 하지 않고도 수정할 수 있도록 한다면 공격자들도 사용할 수 있는 백도어를 만들면 어떨까?

기업은 앱, 특히 자체 개발한 앱의 기능을 테스트해 앱이 제대로 작동하는지 확인하는 데 매우 효과적인 경향이 있다. 앱 테스트가 실패하기 쉬운 부분은 앱이 수행해서는 안 되는 작업을 수행할 수 있는지 확인하는 경우이다. 이것이 바로 모의 침투 테스트 사고방식이다.

하지만 생성형 AI 코딩 현실에서는 이러한 펜 테스트 방식이 기본이 되어야 한다. 또한 생성형 AI의 실수라는 엉뚱한 세계에 대해 잘 교육받은 감독자가 이를 관리해야 한다.

기업 IT는 확실히 더 효율적인 코딩 미래를 기대하고 있다. 프로그래머는 앱이 무엇을 해야 하는지, 왜 해야 하는지에 더 집중하고 모든 줄을 힘들게 코딩하는 데 시간을 덜 할애하여 더 전략적인 역할을 맡을 것이다.

하지만 그러한 효율성과 전략적 이득은 막대한 대가를 치러야 한다. AI가 생성한 코드가 올바른 방향으로 나아가도록 하기 위해 더 뛰어나고 다르게 훈련된 인력을 고용해야 하기 때문이다.

 

https://www.itworld.co.kr/topnews/350221

 

AI 코딩 오류, 관리는 인간 프로그래머가 담당해야

생성형 AI를 도입한 소프트웨어 개발 작업에 인간 프로그래머와는 근본적으로 다른 실수가 포함된다는 사실은 잘 알려져 있다. 그럼에도 대부분의 기

www.itworld.co.kr

 

반응형
반응형

소프트웨어 개발이 쉽다고 생각하는 사람은 아무도 없지만, 이렇게나 다양한 방식으로 어려울 수 있다고 누가 생각했을까? 에반스 데이터에 따르면, 전 세계의 소프트웨어 개발자는 약 2,690만 명으로 추산된다. 

최근 AWS의 알리 스피텔이 트위터를 통해 던진 "개발자로서 일하면서 가장 어려운 부분이 무엇인가?"라는 질문에 100명 이상의 개발자가 답했다. 답변은 대부분 몇 가지 핵심 주제에 수렴할 것으로 예상했지만, 실제로는 매우 다양했다. 개발자의 삶을 개선할 방법을 찾고자 하는 기업이라면, 이들 응답을 자세히 살펴볼 가치가 있다. 개발자들의 이야기를 들어보자.

점점 늘어나는 프로젝트 범위
때때로 우리는 개발자를 너무 사랑한다. 우리는 개발자(새로운 킹메이커와 퀸메이커)에게 의존해 혁신을 이루고 혁신을 지속한다. 카일 쉐블린은 "제품과 디자인에 대한 끊임없는 범위 확대의 위협"이 개발자의 삶을 어렵게 만든다고 지적했다. 이는 개발자의 재능에 대한 건강한 믿음에서 비롯된 것이지만, 무분별한 범위 확대는 잔뜩 부풀어 오른 소프트웨어를 낳고 이런 소프트웨어는 유지 관리도 어렵다. 브라이언 심쿠스가 강조한 것처럼 여기에 "비개발자가 설정한 비현실적인 마감일"이 더해지면 이중고를 겪게 된다.

또한 다니엘레 헤벌링이 지적하듯이 개발자는 "실제로 구축해야 하는 것과 기대되는 결과물에 대한 팀 내 의견 불일치"를 싫어한다. 개발자는 항상 "더 나은 솔루션이 있는지 끊임없이 의심"하게 된다. 물론 더 나은 솔루션은 존재하기 마련이다. 다만 뒤늦게 그 해결책에 도달할 뿐이다. 핵심은 자비어 곤잘레스가 주장하듯이 "완벽주의의 무한 루프를 멈출 때"를 파악하는 것이다. 코드는 결코 완벽할 수 없다. 이를 받아들이고 계속 나아가야 한다.
 
학습의 속도
수십 년 동안 코볼에 대한 이해에 안주해 온 모든 개발자는 오늘날 프레임워크의 유동성이라는 현실에 직면해 있다. 브랜던 트래본은 개발자에게 "언어와 프레임워크의 끊임없는 변화를 따라잡는 것"은 심각한 도전이 될 수 있다고 지적했다. "가장 주목받을 수 있다고 생각되는 것을 골라 거기서부터 시작”할 수 있지만, 그것만으로는 충분하지 않다. "물론 새로운 것으로 '전환'할 준비가 되어 있어야 한다." 프레임워크는 개발자가 데이터베이스나 기타 시스템을 제대로 활용하지 못하게 만드는 경우가 많지만, 때로는 개발자가 혁신의 속도를 따라잡을 수 있는 유일한 방법이기도 하다. 그럼에도 불구하고 쉬운 일은 아니다. 프레임워크가 도움이 되긴 하지만 프레임워크도 변화하고, 그 변화가 문제를 일으킨다.

이와 관련된 것은 애플리케이션 자체의 아키텍처이다. 마이클 자크제스키에 따르면, "애플리케이션이 어떻게 발전할지 예상해 최상의 아키텍처를 준비하되, 처음부터 무리하지 말아야 한다." 어려운 일이다. 예를 들어, 개발자는 확장에 대비해야 할 수도 있지만, 미리 비용을 초과할 정도로 과도하게 프로비저닝해서는 안 된다.
 
'더 많이 코딩할 수만 있다면'
루크 프로서는 "코딩하지 않는 모든 것"은 소프트웨어 개발을 어렵게 만든다고 말한다. 일부 조사에 따르면, 개발자는 전체 시간 중 5%만 코드를 작성하고 나머지 70%는 코드를 이해하려고 노력하거나 코드와 관련이 없어 보이는 일을 하는 데 소비한다. 이를 "코딩 프로세스를 시작하기 위해 모든 세부 사항을 파악하려고 노력하는 것"이라고 표현하기도 한다. 또 다른 까다로운 문제가 있는데, 바로 "팀 간 협업, 특히 대기업의 경우"이다. 0과 1에 초점을 맞추고 싶지만 소프트웨어 개발은 궁극적으로 사람이 하는 것이며, 사람은 어렵다.

AI가 소프트웨어 개발에서 인간을 배제할 것이라는 일반적인 두려움은 어떤가? AI가 사람을 대체할 수는 없다. 지금은 물론 앞으로도 없을 것이다. 그러니 "매일 아침 일어나서 내가 여전히 이 일과 이 산업에 관심이 있다고 스스로를 설득해야 하는", "LLM이 우리를 비롯한 모든 실제 가치를 창출하는 사람들을 쓸모없게 만들 것이라고 예측하는 관리자들이 걱정하는" 제시카 리와 나머지 모든 숙련된 소프트웨어 개발자들에게 이 말로 끝을 맺고 싶다. “기계가 소프트웨어 개발의 지루한 작업을 더 많이 맡게 되면서 진정으로 사려 깊고 혁신적인 작업은 여러분과 같은 창의적이고 훌륭한 개발자가 영원히 수행할 것이다.”

 

https://www.itworld.co.kr/news/335871

 

블로그 | 개발자가 싫어하는 것

소프트웨어 개발이 쉽다고 생각하는 사람은 아무도 없지만, 이렇게나 다양한 방식으로 어려울 수 있다고 누가 생각했을까? 에반스 데이터에 따르면,

www.itworld.co.kr

 

반응형
반응형

https://medium.com/@bobofbellevue/can-an-old-programmer-learn-new-tricks-b2826f87faf3

 

Can an Old Programmer Learn New Tricks?

I decided here at the beginning of 2023 to return to the software industry I had worked at for 25 years between 1985 and 2010. That’s a 13…

medium.com

 

저는 1985년부터 2010년까지 25년 동안 일했던 소프트웨어 업계로 돌아가기로 2023년 초에 이곳에서 결정했습니다. 경력 13년 차입니다. 58세에 그렇게 오랜 시간을 보낸 후 업계에 복귀하는 것이 현실적입니까?

소프트웨어 산업 재진입의 걸림돌

두 가지 문제로 인해 이전에 소프트웨어 산업으로의 복귀를 시도하지 못했습니다.

  1. 기술력의 노후화
  2. 잠재적 연령 차별

저는 2010년에 C++, SQL 데이터베이스 기술 및 MFC(Microsoft Foundation Classes)의 Windows 데스크톱 응용 프로그램 개발에 대한 자세한 지식을 가지고 떠났습니다. MFC, C++ 및 데스크톱 응용 프로그램 개발은 2010년까지 이미 노후화된 기술이었습니다. 저는 마지막 회사에 너무 오래 머물렀습니다. 한 번도 성공한 적이 없었고 폐업한 적도 없었습니다. 당시에는 수요가 많은 기술이 없었습니다. 하지만 우리 제품 라인의 작은 웹 기반 섹션에서 C#, HTML 및 CSS를 가르쳐 주었지만 아직 웹 개발에 자신이 없었습니다. 그래서 저는 부동산 업계로 뛰어들었습니다(다른 기사에 대한 긴 이야기입니다).

나이가 많은 구직자를 차별하는 연령 차별에 관해서는 어린 나이에 직접 참여했습니다. 나이가 많은 지원자를 인터뷰할 때 – 아마 40대였을 것입니다 – 저는 이 사람이 이 직업을 원하는 이유는 무엇입니까?, 그의 경력에 ​​무엇이 잘못되었습니까?, 그에게 무슨 문제가 있습니까? 우리는 항상 젊은 지원자를 선택했습니다. 각 팀원은 이전 항목을 독립적으로 배제했습니다.

DevSlopes 및 Epiphany의 발견

2023년 1월 초에 저는 DevSlopes.com 에서 풀 스택 웹 개발자 프로그램에 합류했습니다 . 마케팅 자료를 검토하면서 두 가지 사실을 깨달았습니다.

  1. 대규모 고용주는 더 이상 컴퓨터 과학 학위를 요구하지 않습니다.
  2. 프리랜서, 온라인, 재택근무의 세계에서 아무도 당신의 나이를 알 필요가 없습니다.

1985년에 제 학위는 커뮤니티 칼리지에서 나왔습니다. 데이터 처리 분야에서 AA 학위를 받았습니다. 우리는 은행이나 보험 회사를 위한 COBOL 프로그램을 작성하도록 훈련받았습니다. 오늘날에는 별로 관련이 없습니다. (제쳐두고: COBOL 프로그램의 장황함은 자체 문서화를 만들고 비서가 컴퓨터 프로그램을 작성할 수 있도록 합니다.)

대학 기반 컴퓨터 과학의 실패

대학의 컴퓨터 과학 학과는 변함없이 수학 학과에서 성장했습니다. 단순히 컴퓨터에 처음 관심을 보인 것은 수학 교수였기 때문입니다. 이 프로그램은 이 뜨거운 분야에서 지원자를 걸러내야 했기 때문에 수학과 물리학의 전제 조건에 몰두했습니다. 일부 좁은 상황을 제외하고 수학은 프로그래밍과 관련이 없습니다. 컴퓨터 과학이 영어과에서 성장했다면 세상은 더 나아졌을 것입니다. 좋은 영어 에세이를 구성하는 것은 수학에서 진행되는 것보다 프로그래밍과 훨씬 더 유사합니다.

결과적으로 이러한 컴퓨터 과학 프로그램은 시장에 적응하지 못했고 프로그래머에 대한 강력한 수요를 충족할 만큼 성장하지도 못했습니다. 수학 교수는 비즈니스에 대해 무엇을 알고 있습니까? 고용주들은 우선 H-1B 비자 프로그램을 통해 외국인을 고용하는 것으로 대응했습니다. 현지 시민을 훈련시키는 것보다 훈련된 외국인을 고용하는 것이 훨씬 저렴하고 빠릅니다. 최근 DevSlopes와 같은 대안 온라인 학교는 웹 개발자의 고용 수요를 충족시키기 위해 성장했습니다. 고용주는 최신 경험과 웹 프로젝트 포트폴리오를 선호하도록 고용 관행을 파악하고 변경했습니다.

지금까지의 DevSlopes 결과

이 글을 쓰는 지금 저는 DevSlopes 프로그램에 2주 동안 참여하고 있으며 하루에 4~6시간 작업하고 있습니다. 지금까지 나는 두 가지에 대해 매우 기쁘게 생각합니다.

  1. DevSlopes 자료 및 조직의 품질
  2. 내 오래된 기술 중 일부가 여전히 가지고 있는 관련성

향후 기사에서 DevSlopes에 대한 리뷰를 작성하겠습니다. 프로그램에 매우 만족하며 4~6개월 안에 완료할 것으로 기대한다고 말하는 것으로 충분합니다.

오래된 기술은 새로운 날을 봅니다

여전히 관련성이 있는 내 기술은 - 때때로 놀랍게도 - 다음과 같습니다.

  1. UNIX 운영 체제에서 시작된 VI 편집기. VI의 장점을 이해하려면 VI를 사용해야 합니다. 불행히도, 나는 그것을 배우려고 시도하는 초보자를 권장하지 않습니다. 잘 배우려면 2년 정도 걸립니다. 일단 그 지점을 지나면 마치 자전거를 타는 것과 같습니다. 절대 잊지 못할 것이고 손가락이 저절로 날아갈 것입니다. VI를 사용하면 마우스를 건드리지 않고 파일을 편집할 수 있습니다. 마우스와 키보드 간에 컨텍스트를 지속적으로 전환하지 않아도 됩니다. 여기에는 텍스트 탐색 및 변경과 마우스 기반 편집기에는 없는 복잡한 작업 반복을 위한 매우 풍부한 명령 세트가 있습니다. VI를 다시 사용하게 되어 기쁩니다.
  2. HTML/CSS — 저는 이전 경력에서 이러한 주제를 다루었습니다. 나는 나에게 유리하게 시작할 수 있는 적어도 그들에 대한 독서 지식을 가지고 있었다.
  3. Javascript — 많은 교육 자료가 Javascript와 관련될 것이라는 것을 알 수 있습니다. 나는 과거에 약간의 Javascript를 작성했지만 일반적으로 C++ 및 객체 지향 언어와 관련이 있으므로 다시 익히는 데 문제가 없을 것입니다.
  4. SQL 데이터베이스 — 내 25년 경력은 SQL의 우세 이전에도 항상 데이터베이스와 관련이 있습니다(참고: SQL은 "구조화된 쿼리 언어"를 의미합니다. SQL은 비서가 데이터베이스에서 정보를 검색하는 데 사용할 수 있는 장황한 언어로 설계되었습니다. SQL은 프로그래밍 방식으로 사용하기에는 끔찍한 해킹이지만 업계는 시간이 지남에 따라 효율적이고 사용하기 쉽게 만드는 도구를 완성했습니다.) 데이터베이스 테이블 간의 SQL 구문 및 팩터링 필드와 같은 기술은 여전히 ​​관련이 있습니다. MongoDB라는 제품을 배우게 될 것입니다. 이 제품은 저에게 새로운 제품이지만 여전히 SQL 기반입니다.
  5. 디버깅 및 테스트 — 저는 항상 프로그래머가 자체 테스트를 수행하는 소규모 회사에서 일했습니다. 디버깅은 가능한 가장 효율적인 방법으로 프로그래밍 오류의 범위를 좁히는 프로세스입니다.

프로 디버깅 팁

여기에서 두 가지 프로 디버깅 팁을 알려드리겠습니다.

  1. 귀하의 문제는 원본이 아닙니다. 누군가 전에 같은 문제로 어려움을 겪었습니다. 구글링하세요. 비결은 질문을 표현하는 올바른 방법을 찾는 것입니다. 다른 사람들이 어떻게 요청했을지 생각해 보십시오.
  2. 여러 시간 동안 벽에 머리를 부딪쳤다면 멈추고 휴식을 취하십시오. 해결 방법은 컴퓨터를 종료한 지 5분 후, 점심을 먹는 동안 또는 다음 날 아침 샤워 중에 가장 이상한 순간에 종종 나타납니다.

결론: 오래된 프로그래머를 목장에 내버려두지 마십시오

저는 노년 프로그래머들에게 소프트웨어 산업으로 돌아가도록 격려하고 싶습니다. 여러분 중 더 많을 것으로 예상합니다. 내가 한 것처럼 당신의 기술 중 일부는 관련성이 있다는 것을 알게 될 것입니다. 또한 젊은 근로자에게 부족할 수 있는 직업 윤리, 조직 및 신뢰성에 대한 소프트 스킬이 있습니다. 유연한 일정으로 집에서 일할 수 있는 기회는 내가 업계를 떠날 당시 우리가 가졌던 그 어떤 것보다 뛰어났습니다. 프로그래밍을 위한 저렴한 온라인 교육 프로그램이 전례 없이 급증했습니다.

계속 지켜봐! 나는 DevSlopes를 통해 작업하고 풀 스택 웹 개발자로 자신을 리브랜딩함에 따라 이것이 시리즈의 첫 번째가 될 것으로 기대합니다.

반응형
반응형

https://www.itworld.co.kr/numbers/82001/272637

 

넘버스 Numbers - 2022 프로그래머스 개발자 설문조사 리포트

1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

www.itworld.co.kr

 

https://programmers.co.kr/pages/2022-dev-survey

 

2022 프로그래머스 개발자 설문조사

5362명이 참여한 온라인 설문 조사 결과를 통해 우리나라 개발자들의 솔직한 의견을 확인하세요.

programmers.co.kr

개발자 커리어 플랫폼 프로그래머스 운영사 그렙이 국내 개발자들의 기술 트렌드와 커리어 고민을 엿볼 수 있는 ‘2022 프로그래머스 개발자 설문조사 리포트’를 공개했다고 밝혔다.

프로그래머스 홈페이지에 공개된 리포트는 프로그래머스를 이용하는 개발자 5,362명을 대상으로 2021년 12월 3일부터 31일간 실시된 온라인 설문조사 결과를 바탕으로 발행됐다. 개발자 설문조사 리포트는 우리나라 개발자들의 생각을 공유하는 목적으로 매년 상반기에 발행한다. 이번 리포트에는 근무 지역·형태, 평균 연소득, 자주 사용하는 툴, 배우고 싶은 프로그래밍 언어, 이직과 구직 시 중요한 점, 채용 정보와 개발 트렌드를 얻는 곳 등 총 35문항을 수록했다.
 

ⓒ 그렙
해당 자료에 따르면, 응답한 개발자 49.5%는 회사로 출근한다고 응답했다. 재택근무와 출근을 병행하는 개발자는 38.3%, 재택근무만 하는 개발자가 12.2%로 총 응답자 중 87.8%의 개발자는 회사로 출근한 것으로 나타났다. 가장 많은 개발자가 근무하는 지역은 서울시 강남구(25.3%)로 나타났으며, 네이버, 엔씨소프트 등 IT 기업이 다수 포진돼 있는 경기도 성남시(14.5%)가 2위, 강남구 옆에 위치한 서초구(6%)가 3위를 기록했다.

연소득 관련 질문에서는 설문에 참여한 개발자의 43.5% 만이 4,000만 원 이상을 받는다고 답했다. 개발자 영입 전쟁이 치열해지면서 처우개선과 사이닝 보너스, 스톡 옵션 제공이 연일 화제가 되고 있으나 모든 개발자가 고액의 연봉을 받지는 않는 것으로 나타났다. 

한편, 개발자들이 회사를 선택할 때 가장 중요하게 여기는 것은 연소득/인센티브/스톡옵션 등의 금전적 보상(60.3%)이었으며, 다음으로 동료(55.1%)와 개발 스택/환경(47.7%)을 고려한다고 답했다. 개발자들이 선택한 회사를 선택하는 기준 톱3는 매년 변하지 않는 순위를 유지하고 있다.

개발자들이 가장 자주 사용하는 에디터(최대 2개 선택)는 비주얼 스튜디오 코드(56.3%), 인텔리J(29.6%), 이클립스(17.7%) 순이었다. 비주얼 스튜디오 코드는 2020년 46.5%와 비교해 10% 가까이 사용량이 증가했다. 또한 새롭게 배우고 싶거나 배울 필요성을 느끼는 언어는 코틀린(15.5%), 고(15.3%), 타입스크립트(12.5%) 순이었다. 2020년 1위를 차지한 파이썬의 경우 4위로 하락했는데, 이미 많은 개발자들이 Python에 익숙해졌기 때문인 것으로 분석했다.

또한 매일 밤샘 근무를 하는 개발자 이미지와 달리 34.7% 개발자는 야근을 하지 않는 것으로 나타났다. 매일 또는 거의 매일 높은 강도로 야근하는 개발자는 13%로 응답자 중 가장 적은 비중을 차지했다.

그렙 이확영 대표는 “해외에도 다양한 개발자 설문조사 리포트가 발행되지만 국내와 근무환경이 다르기 때문에 우리 주변의 개발자들의 생각을 보여주지는 못하는 아쉬움이 있었다”면서 “프로그래머스는 설문조사 리포트를 통해 많은 개발자들이 궁금증을 해소하고 공감대를 얻기를 바라는 마음으로 매년 상반기 설문조사 리포트를 발행하고 있다”라고 말했다.

반응형
반응형

Online Typing Practice for Programmers

https://www.speedcoder.net/

 

Typing Practice for Programmers | SpeedCoder

 

www.speedcoder.net

반응형
반응형
프로그래밍에서 인지 편향

http://www.mimul.com/pebble/default/2018/01/05/1515145860439.html?utm_medium=social&utm_source=gaerae.com&utm_campaign=%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%8A%A4%EB%9F%BD%EB%8B%A4

개발자로서써, 우리는 생산성을 방해하는 다양한 문제에 대해 잘 알고 있다. 하지만, 우리는 큰 관점에서 생각하는 것을 놓치는 경우가 종종 있다.

어떤 것은 인지하기 힘든 미세한 것일수도, 어떤건 큰 영향을 주는 것일수도, 여러분이 잘 처리 할 수 있는 것일수도, 잘 못할 수도 있는 것들이 존재한다. 이러한 모든 요소가 하나로 결합되어 일종의 내부 피드백 루프를 형성하여 생산성 저하, 버그 및 큰 좌절로 이어질 수 있다.

이들 한, 두가지의 영향을 최소화 할 수 있다면 그 주기(나쁜 사이클)를 깨고 나머지 것들을 무력화시킬수도 있다. 여기에서는 프로그래밍할 때 여러분들이 알아야 할 5가지 인지 편향에 대해 이야기해 본다.


과도한 가치 폄하(Hyperbolic Discounting)

나중의 더 큰 보수 대신에 지금 당장의 이익을 우선시 하는 것.

여러분중에 테스트 코드 작성을 연기 한 적이 있나요? Vim 사용중에, 화살표 키를 사용하여 커서를 이동시킨적이 있나요? 축하해요. 여러분은 과도한 가치 폄하를 보여준 것이에요. 당장의 이득에 눈이 멀어 화살표 키를 사용한다는 것은 올바른 구문을 찾기 위해서 정확한 라인으로 이동하는 과정에는 큰 고통(긴 시간)을 초래한다. 당장 익숙하지 않는 HJKL을 익힌다면 원하는 곳으로 빨리 갈 수 있어 미래의 이익은 훨씬 높아진다. 결과적으로, 당신은 많은 시간을 절약하게 된다.

이케아 효과 (IKEA Effect)

문제에 대한 자신의 해결책은 과대 평가하는 반면, 다른 솔루션을 과소 평가하는 것.

이케아 효과는 소비자가 직접 조립해서 만든 제품을 훨씬 고 평가(더 많은 가치를 줄 것이라는)하는 경향이 있는데, 이것 또한 인지 편향이다. 우리는 문제에 대한 자신의 해결책을 과대 평가하는 경향이 있고, 반면에 다른 해결책은 과소 평가하는 경향이 있다. 만약, 당신이 멋지고 독창적인 도구가 아닌 그저 그런 사내 도구를 사용하여 회사에 일한 적이 있다면, 내가 무슨 말을 하고 싶은 것인지 알 것이다. 

어설픈 최적화 (Premature Optimization)

필요한 것을 이해하기도 전에 최적화하는 것.

자명하다. 엔진을 고치지 않고 낡은 자동차를 빨리 달라게 하는데에 공기 역학적 스포일러 날개를 추가하는 것은 전혀 도움이 되지 않는다. 가장 좋은 예로 실험에 목표를 둔 코드에 성능적으로 완벽한 코드를 작성하는 것이다. 

계획 오류 (Planning Fallacy)

작업을 완료하는 데 필요한 시간을 낙관적으로 예상하는 것

계획 오류(Planning Fallacy)는 대부분의 사람에 관련된 이야기다. 그것이 우리든, 프로젝트 매니저든, 제품을 사용하는 고객이든 실제로 언제 작업이 끝날지에 대해 낙관적인 경향이 있다. 이것은 아래 격언이 잘 설명해 준다 : 코드의 첫 90%가 개발 시간의 첫 90%를 차지하고, 코드의 나머지 10%가 또 다른 90%의 개발 시간을 차지한다. 즉, 총 180%를 소요하게 되는 의미로, 당초 예상한 기간보다 훨씬 초과하는 경향을 표현한 것이다. (90 대 90의 법칙) 

최신 편향(Recency Bias)

과거에 일어난 일보다 최근의 사건에 높은 가치를 두는 것. 최신 경험을 더 가치있다고 생각하는 것.

최신 편향(Recency Bias)은 문제를 해결해야 할 때 자주 마주치곤 한다. 우리는 비슷한 문제를 해결했기 때문에 그 해결책을 사용하자. 명심하자. 동일한 디자인 패턴을 반복해서 사용하는 자신을 발견하지 않았냐? 그렇다면, 당신은 같은 시각으로 다른 문제를 들여다보고 있는지도 모른다. 우리는 바이어스(편견)를 완전히 제거할 수는 없다. 그러나, 편견이 우리에게 어떻게 영향을 미치고 있는지를 앎으로써 그것이 야기하는 문제를 완화시킬 수는 있다. 


...
반응형

+ Recent posts