30 10월 2025

[사회과학] [박진영의 사회심리학] 지혜는 겸손에서 비롯된다

[사회과학] [박진영의 사회심리학] 지혜는 겸손에서 비롯된다

[박진영의 사회심리학] 지혜는 겸손에서 비롯된다

입력
오픈AI 제공

오픈AI 제공

평소 자신이 무언가를 잘못 알고 있거나 틀릴 가능성을 어느 정도 인식하고 있는 사람이 있는 반면 그렇지 않은 사람이 있다. 예를 들어 다른 사람들은 이따금씩 틀리더라도 자신만은 그렇지 않을 것이고 자신이 옳다고 생각하는 것들은 대체로 다른 상황에서도 다른 사람들에게도 ‘내가 대체로 옳다’고 여기는 자신감이 쓸데없이 과한 사람들이 있다.

이렇게 자신의 지적 한계에 대해 인식하는 특성을 ‘지적 겸손’이라고 부른다. 안타깝게도 연구들에 의하면 이는 꽤 안정적인 특성이라서 지적 겸손도가 높은 사람들은 일반적으로 어떤 현상을 바라볼 때 한 가지 설명(보통 자신의 시각)에만 매몰되어 있기보다 서로 다른 다양한 시각에 열려 있는 편이다.

자신과 의견이 다르다고 해서 누군가를 미워하거나 적대시하는 일도 비교적 적다. 복잡한 현상에 대해 지나친 단순화나 과한 일반화를 좋아하지 않고 복잡하게 얽혀 있는 다양한 층위의 원인들을 파고드는 것을 좋아하는 편이다.

이와 달리 지적 겸손도가 낮은 사람들의 경우 보통 자신의 시각에 지나치게 과한 가중치를 두고 자신의 의견과 비슷한 의견만 골라서 듣는 경향이 있다.

자신과 생각이 다른 사람을 싫어하거나 배척하는 일이 비교적 흔하게 나타나고 문제의 복잡함에 반해 지나치게 ‘간단명료한 설명’을 선호한다. 그러다 보니 지적 겸손도에 따라 좀 더 지혜로운 사람이 될 수 있는지의 여부가 달라지기도 한다.

물론 어느 정도 옳고 그름이 명확한 문제에 대해서는 그나마 지적 겸손도가 낮은 것이 큰 문제가 되지 않을 수 있지만 이런 경우에도 사람들은 지적 겸손도가 낮기보다 높은 사람들의 의견을 더 잘 청취하는 경향이 있다.

예를 들어 과학자들의 경우에도 지적 겸손도가 높을 때(또는 높다고 여겨질 때), 사람들이 더 과학자들이 한 연구 내용을 신뢰한다는 발견들이 있었다. 또 조직 내에서도 리더의 지적 겸손도가 높을 때 그렇지 않을 때에 비해 창의적인 결과물들이 더 많이 나온다는 연구 결과들도 있었다.

비교적 ‘정답’이 존재하는 세계에서도 그렇지만 정답이라는 것이 존재하지 않고 다양한 입장이 상충하는 사회적 문제나 인간관계에서의 갈등 상황에서도 지적 겸손은 중요한 역할을 한다. 조나 코에트키 피츠버그대 연구자의 연구에 의하면, 지적 겸손도가 높은 사람들은 그렇지 않은 사람들에 비해 다양한 ‘갈등’ 상황을 더 잘 해쳐나가는 편이다.

지적 겸손도가 높은 사람들은 그렇지 않은 사람들에 비해 갈등 상황에서

① 긍정적 정보 전달: 다른 사람들이 자신의 입장을 잘 이해할 수 있도록 자신에게 있어 중요한 것들에 대해 솔직하게 이야기
② 긍정적 회피: 사람들이 여러 대안을 더 잘 검토할 수 있도록 문제를 차후 다시 논의하자고 제안
③ 긍정적 개방: 어떤 해결책을 제안하기 전에 상대방에게 있어 가장 중요한 요소들이 무엇인지 살핌
④ 긍정적 연대: 함께 마음을 모아 해결하면 문제를 해결할 수 있을 것이라고 믿는 건설적인 행동을 더 자주 한다고 보고하는 것으로 나타났다.

그런 반면 지적 겸손도가 높은 사람들은 지적 겸손도가 낮은 사람들에 비해

⑤ 부정적 공격: 상대방에게 무례한 태도를 보이거나
⑥ 부정적 회피: 갈등이 불편해서 침묵을 지키거나 대화 주제를 바꾸는 등의 해로운 행동은 덜 하는 편이라고 보고했다.

나아가 역사적으로 첨예한 국가 간, 집단 간 갈등 상황에서도 지적 겸손도가 높은 사람들은 그렇지 않은 사람들에 비해 양쪽의 입장에 좀 더 균등한 관심을 보이고 팔이 안으로 굽기보다 외집단 사람들의 피해 상황과 고통에 대해서도 인지하며 폭력적이기보다 대화를 통한 해결을 선호한다는 발견들이 있었다.

점점 살면서 겪는 대부분의 문제들에서 꼭 ‘한 가지 정답’만 존재하는 경우는 드물 것이라는 생각이 든다. 특히 서로 다른 의견들이 부딪히는 문제에서는 더더욱 그럴 것이다. 그렇기 때문에 내 생각이 반드시 옳거나 특히 내 생각만 옳을 가능성은 아마 매우 적을 것이다.

당연한 이야기인 것 같지만 안타깝게도 우리 모두 이런 지혜를 기본적으로 장착하고 있는 것은 아니어서 내가 반드시 옳다는 생각이 들 때면 나의 지적 겸손도를 따져봐야겠다는 생각이 든다.

※필자소개
박진영. 《나, 지금 이대로 괜찮은 사람》, 《나를 사랑하지 않는 나에게》를 썼다. 삶에 도움이 되는 심리학 연구를 알기 쉽고 공감 가도록 풀어낸 책을 통해 독자와 꾸준히 소통하고 있다. 온라인에서 ‘지뇽뇽’이라는 필명으로 활동하고 있다. 현재 미국 듀크대에서 사회심리학 박사 과정을 밟고 있다.

Loading

26 10월 2025

[기술 에세이] [기술 블로그] 개발은 나이와 함께 익어간다 

[기술 에세이] [기술 블로그] 개발은 나이와 함께 익어간다 

72P by xguru 11일전 | ★ favorite | 댓글 15개

아마존 CTO Werner Vogels 박사의 글

  • 이런 속삭임을 들었음. “이제 그도 나이가 들었는데, 누가 후임이 될까?”
    • 사람들이 진지하게 물음. “은퇴는 언제 하실 건가요?”
    • Amazon에서 거의 25년을 보냈고, 매년이 다르고 놀라웠던 시간들이었지만, 그는 여전히 학계를 떠나 Amazon에 합류하기로 했던 그날만큼 젊은 마음을 가지고 있음
  • 나이가 들어가는 개발자로서 좋은 점은, 이미 많은 문제를 직접 경험해봤다는 것
    • 젊은 개발자들이 오늘 마주하는 어려움들을 이전에도 겪었고, 비록 지금은 겉모습이 조금 달라 보일지라도 본질은 같음
    • 수많은 프로젝트를 거치며 실전 경험을 쌓았고, 실패도 셀 수 없이 많았음
    • 이제 머릿속 절반은 무엇이 현실적으로 작동하는지를 알고 있고, 그중 일부는 위험 신호를 감지하는 감각으로 훈련되어 있음
  • 남은 공간은 창의성을 위한 자리
    • 다양한 신호를 받아들이고, 정신적 모델을 세우며, 새롭고 독창적인 해결책을 찾는 일
    • 이것이야말로 개발자로서의 가장 큰 즐거움
    • 매일 무언가 새로운 것을 만들 수 있는 직업이 얼마나 될까?
    • 나는 이 사실을 결코 당연하게 여기지 않음
  • 나이 든 개발자로서, 당신은 이미 패턴이 반복되는 세상을 여러 번 보았음
    • 세상을 바꿀 것처럼 떠들던 회사들이 결국은 구멍 난 치즈 같은 결과를 내놓는 모습을 수없이 봄
  • 그리고 AI의 시대가 도래했음
    • 지난 15~20년 동안 우리가 사용해온 NLP, 음성인식, 번역, 이미지 인식, 추천 시스템, 사기 탐지 등과 같은 AI가 아님
      • Amazon.com을 지탱해온 기반 기술들이지만, 지금 이야기하는 것은 생성형 AI
      • 나이 든 개발자인 나에게도 이건 정말 흥미로운 변화로 느껴짐
    • 실험 속도가 엄청나게 빨라졌기 때문
      • 건강한 회의감(scepticism)을 가진 숙련된 빌더의 손에 들어가면, 이것은 매우 강력한 도구가 됨
      • 하지만 동시에 도전적이기도 함
      • 다른 기술들처럼 출시 전 교육이나 준비 기간이 없었기 때문
      • 마치 마법이 병에서 갑자기 튀어나오듯 세상에 퍼졌고, 모두가 예상치 못한 탓에 과열된 기대가 폭발함
    • 이 상황은 낯설게 느껴졌음
      • 왜냐하면 지금까지의 소프트웨어는 1년에 한 번 나오는 마이너 버전 업그레이드를 통해 진화했기 때문
      • Windows 3가 3.1이 되기까지 2년이 걸렸고, Mac OS X도 2001년부터 2019년까지 소수점 버전만 업데이트하다가 최근에야 매년 주요 버전이 바뀌기 시작했음
      • 그런데 지금은 매주 모델이 교체되고, 새로운 버전이 나올 때마다 리더보드 순위가 바뀌는 세상이 되었음
  • AWS는 언제나 B2B 기업이었음
    • 우리는 고객들이 자신의 고객을 위해 혁신할 수 있도록 기술의 빌딩 블록(S3, EC2, DynamoDB, Lambda, DSQL 등) 을 제공해왔음
    • 그런데 이 AI 열풍 속에서 갑자기 B2C 기업들과 비교되기 시작했음. 솔직히 답답했음
  • 하지만 경험은 방향을 알려줌
    • 우리는 본질로 돌아갔음
    • 기술(이번에는 모델)에 대한 접근을 대중화하고, 고객 선택권을 보장하며, 프라이버시와 보안을 최우선으로 두었음
    • 또한 안전과 컴플라이언스를 위한 가드레일을 제공하고, 자동 추론(automated reasoning) 을 통해 모델 오류 가능성을 줄였음
    • 이것이 수십 년 동안 반복되는 패턴 속에서 배운 교훈임
      — 무엇이 진짜로 작동하는지를 알고 있다는 것
  • 노련한 개발자는 매주 쏟아지는 새로운 모델 발표와 기능 추가 소식에도 조급해하지 않음
    • 이런 일은 수없이 봤음 = 새로운 기술, 같은 패턴
  • 지난 수십 년 동안 나이든 개발자는 아마 열 개가 넘는 프로그래밍 언어를 배우고, 수많은 오픈소스 라이브러리와 플랫폼을 경험했을 것임
    • 언제나 기술 트렌드를 관찰하고, 논문을 읽고, 새로운 방향을 공부하는 일을 즐겼음
    • 그것이 개발자의 재미였기 때문
    • 그래서 그의 회사가 생성형 AI에 적합한 문제를 다룰 준비가 되었을 때, 그는 이미 준비되어 있었음
    • 또한 Marc Brooker의 훌륭한 글 “LLM-driven development”를 읽었고, 그 조언을 따를 계획임
  • 내가 만나는 거의 모든 고객은 이렇게 물어봄 : “우리는 생성형 AI로 뭘 해야 할까요?”
    • 이 질문에 대한 최고의 답변은 우리의 똑똑한 과학자 Byron Cook의 말임 : “질문에 즉시 답변하지 못해 죄송한데, 왜 이런 질문을 하셨을까요?”
    • 고객의 90%는 생성형 AI가 자사 문제를 해결할 거라 믿어서 묻는 게 아니라, 단지 뒤처질까 봐 불안해서 묻는 것임
      • FOMO(Fear of Missing Out) 때문임
  • 그리고 노련한 개발자는 이럴 때 멈출 줄 앎. 잠시 멈춰서, 신중하게 생각함
    • 그는 젊은 개발자들에게 장단점을 공부하라고 격려하고, 경영진에게는 Jeff Lawson의 《Ask Your Developer》 같은 책을 읽으라고 권함
  • 그 다음엔, 늘 그래왔듯이 고객과 깊이 대화함
    • 그들의 도전 과제를 듣고, 문제를 탐색하고, 아키텍처와 마이그레이션, 도구를 제안함
    • 그리고 때로는 그 해답이 생성형 AI일 수도 있음
  • 하지만 나이 든 개발자로서, 당신은 이미 알고 있음

자, 이제, 만들어보세요!(Now, Go build!)

[출처] https://news.hada.io/topic?id=23667

Loading

18 10월 2025

[사회과학] [박진영의 사회심리학] 불행, 개인 탓만은 아니다

[사회과학] [박진영의 사회심리학] 불행, 개인 탓만은 아니다

[박진영의 사회심리학] 불행, 개인 탓만은 아니다

입력
오픈AI 제공

오픈AI 제공

많은 사람들이 어려움을 겪는 사람들을 보면 안타까움을 느끼면서도 동시에 “왜?”, “어쩌다가?” 같은 질문을 던진다. 집에 불이 나거나 실직을 하는 등 부주의나 실수 같은 개인의 책임이 있을 수도 있는 일에 대해서는 물론이고 큰 병에 걸리는 것처럼 항상 뚜렷한 원인이나 책임이 존재하는 것은 아닌 문제들에 대해서도 나름 원인을 찾아보려고 애쓴다.

물론 나쁜 일에 대해 어떤 원인을 밝히려고 노력하는 것은 유용할 때가 많다. 왜 그런 일이 발생했는지 알아야 자신이나 주변 사람들에게 비슷한 나쁜 일이 발생하는 것을 막을 수 있을 것이고 최소한 자신의 힘으로 나쁜 일을 어느 정도 막을 수 있다는 ‘통제감’을 가지는 것이 가능하다. 문제는 그런 노력이 개인에 대한 지나친 비난과 구조적인 문제를 감추고 지속시키는 결과를 가져올 수 있다는 것이다.

사람들은 삶이 예측 가능하고 자신의 힘으로 통제할 수 있기를 바란다. 조금만 생각해 봐도 세상에는 우리가 계획한 대로 되지 않는 일이 더 많고(예> 불경기, 운) 한 치 앞도 살필 수 없는 것이 삶이지만 노력하고 착하게 살면 나쁜 일이 닥치지 않을 것이라고 믿고 싶어한다. 그 대표적인 예가 세상은 대체로 공정하다는 믿음(Belief in a Just World)이다.

이 믿음 덕분에 그렇지 않은 사례들이 즐비함에도 내가 하는 행동들이 무의미하지 않다는 의미감과 잘될 거라는 희망을 가지고 살아가는 것이 가능하다. 하지만 그와 동시에 착하고 열심히 살아온 사람들에게 나쁜 일이 닥치는 불편한 사실을 외면하게 되기도 한다. 재난 뉴스에 “그러게 거기 왜 갔냐”는 댓글들이 달리고 무고한 피해자에게 “걔도 뭔가 잘못을 했을 거다”라는 추측과 2차 가해가 따라붙는다.

자신의 통제감과 희망을 유지하기 위해서 사회 구조적인 문제가 숨어 있는 문제들, 예를 들어 ‘가난’에 대해서도 빈부격차나 높은 물가와 실업률, 낮은 임금 같은 문제들을 전부 ‘게으름’ 같은 개인 내적 문제로 환원시키기도 한다.

대부분의 문제들이 개인 내적·외적 요소들이 얼키고설켜 만들어지고 겉으로 보이는 것보다 훨씬 복잡한 이면을 가지고 있음에도 이것들을 너무 단순하게 축소시켜 버린다. 그러다 보니 진짜 해결해야 할 문제를 놓치고 괜한 사람들만 비난하는 것으로 문제 해결을 종결시키고 만다.

최근 연구들에 의하면 ‘내가 노력하면 된다’는 믿음은 동기부여에 도움이 된다는 이점이 있지만 특히 ‘남들도 대체로 자신에게 걸맞은 결과를 얻는다’는 믿음은 가난한 사람에 대해 게으르거나 능력이 부족하다는 낙인을 찍는 것이나 이미 차별받고 있는 사람들을 더 차별하고 처벌하려는 행동과 관련을 보인다.

나의 상황과 타인의 상황이 전혀 다를 수 있고 내가 노력하면 할 수 있는 일이 누군가에게는 전혀 다른 차원의 문제일 수 있다. 하지만 이렇게 삶의 문제들을 입체적으로 다각도에서 분석하는 데에는 많은 훈련이 필요하다.

어쩌면 생각보다 해결 방법은 단순할지도 모른다. 삶은 한 치 앞도 예측하기 힘들고 많은 문제들이 개인 내적·외적 요소들에 걸쳐 복잡하게 꼬여 있으며 세상에는 내가 모르는 차원의 문제들도 존재함을 인정하면 적어도 타인의 삶을 쉽게 판단하는 행동은 삼가게 되지 않을까?

연구들에 의하면 ‘지혜로운’ 사람들의 경우 이와 같이 인간의 삶은 다층적이고 다면적임을 아는 편이다. 이 세상에 단순하고 간단한 문제란 없음을 기억해야겠다.

※필자소개
박진영. 《나, 지금 이대로 괜찮은 사람》, 《나를 사랑하지 않는 나에게》를 썼다. 삶에 도움이 되는 심리학 연구를 알기 쉽고 공감 가도록 풀어낸 책을 통해 독자와 꾸준히 소통하고 있다. 온라인에서 ‘지뇽뇽’이라는 필명으로 활동하고 있다. 현재 미국 듀크대에서 사회심리학 박사 과정을 밟고 있다.

Loading

16 10월 2025

[一日30分 인생승리의 학습법] 명령형 vs 선언형 프로그래밍

[一日30分 인생승리의 학습법] 명령형 vs 선언형 프로그래밍

명령형 프로그래밍은 절차적 프로그래밍이라고도 하는데,

최근에 우테코 미션을 하다가 요런 말을 들은 적이 있다.

 

전반적으로, 너무 절차적 프로그래밍으로 코드를 작성하는 경향이 있습니다.
좀 더 선언적으로 기능을 구현할 수 있게 사고 전환을 해보시면 나중에 큰 도움이 될 거예요.

 

처음에는 무슨 말인지 정확히 감이 잡히질 않아서 여기저기 찾아보다가

ui.dev라는 사이트에서 Tyler McGinnis라는 분이 작성한 글을 보고 조금씩 이해가 되기 시작했다.

그래서 기분이 좋아져서 번역이나 해봐야겠다 싶었다.


나는 언젠가 분명 ‘명령적(Imperative) 프로그래밍 vs 선언적(Declarative) 프로그래밍’에 대해 들어본 적이 있다.

저게 무엇을 의미하는지를 당연히 검색해봤지만, 그 때마다 요런 정의 정도만 접해볼 수 있었다.

 

명령형(절차적) 프로그래밍은 당신이 어떤 일을 어떻게 할 것인가에 관한 것이고,
선언적 프로그래밍은 당신이 무엇을 할 것인가에 관한 것입니다.

 

만약 내가 명령형과 선언형의 차이를 이미 알고 있었더라면 이 정의가 명확하게 다가왔겠지만 나는 그렇지 않았다.

사실 나 뿐만 아니라 많은 사람들이 이 주제에 대해 어려움을 느끼는데,

아마 직관적으로는 무슨 말인지 알지만, 누군가에게 설명할 만큼 명확하지는 않기 때문일 것이다.

 

많은 개발자들이 여기기에 가장 효과적인 방법은 비유와 실제 코드를 조합해서 설명해주는 것이었다고 하니,

해당 방법으로 ‘명령형 vs 선언적 프로그래밍’이라는 주제를 다뤄보도록 하자.


우선, 위에서 언급했던 저 ‘어떻게, 무엇을’에 관한 정의는

사실 ‘명령형 vs 선언형’의 핵심을 담고있다고 봐도 무방하다.

이를 이해하기 위해, 프로그래밍의 관점에서 잠깐 벗어나 현실에서의 예시를 들어보도록 하자.

 

■ Red Lobster

당신은 회사에서 너무 오랜 시간 자바스크립트를 다루느라 피곤해졌습니다.

그리고 이를 달래기 위해 퇴근 후에 아내와 함께 ‘Red Lobster’ 식당에 근사한 데이트를 하러 갔습니다.

당신은 Red Lobster에 도착했고, 프론트 데스크에 가서 다음과 같이 말했습니다.

  • 명령형 접근(HOW): “저기 Gone Fishin’ 이라고 적힌 표지판 아래에 있는 테이블이 비어있네요.
    우리는 저기로 걸어가서 저 테이블에 앉도록 하겠습니다.”
  • 선언형 접근(WHAT): “2명 자리 주세요.”

 

명령형 방식은 내가 실제로 자리에 어떻게 앉을지에 관심이 있다. 

이를 위해 나는 내가 어떻게 테이블을 잡아서 자리에 앉을지에 관해, 필요한 단계들을 하나하나 나열해야 한다.

반면, 선언형 방식은 오로지 내가 무엇을 원하는지에 관심이 있다. 여기서 말한 ‘두 명을 위한 테이블’ 처럼.

 

■ Wal-Mart

친구가 당신의 집에 집들이를 오기 위해 Wal-Mart에서 선물을 샀습니다.

현재 친구는 Wal-Mart 바로 옆에 있으며, 당신의 집에 어떻게 도달해야 하는지를 전화로 물어봅니다.

이에 관한 명령형 대답과 선언형 대답을 모두 생각해보세요.

  • 명령형 접근(HOW): “주차장 북쪽 출구로 나와서 좌회전을 해. 12번가 출구에 도착할 때까지
    I-15 북쪽 도로를 타고 와야 해. 거기서 IKEA에 가는 것처럼 출구에서 우회전을 해. 그리고 거기서
    직진하다가 첫 번째 신호등에서 우회전을 해. 그 다음에 나오는 신호등을 통과한 후에 좌회전을 하면 돼.
    우리 집은 #298 이야.”
  • 선언형 접근(WHAT): “우리 집 주소는 298 West Immutable Alley, Eden, Utah 84310 이야.”

 

추가로 한 가지 비유를 더 하자면, 수동 스틱 자동차와 오토 스틱 자동차를 예로 들 수 있다.

친구가 ‘우리 집에 어떻게 도착하는가’ 와는 별개로, 친구가 어떤 차를 운전하느냐에 관한 이야기이다.

수동 스틱(1종)은 명령형 방식이고 오토 스틱(2종)은 선언적 방식이다.

만약 당신이라면 어떤 차를 운전하겠는가?


실제 코드로 예시를 들기 전에, “자리에 앉는 방법은 누가 알지?”,

“주소는 아는데, 집에 가는 방법은 누가 알지?”와 같은 의문이 생길 수 있을거라 생각한다.

이에 대한 대답은, 선언적 방식의 접근을 위해서는 명령형 방식으로

‘어떻게 접근하는가’에 관한 내용이 먼저 추상화 되어있어야 한다 라는 것.

  • Red Lobster 직원에게 사용했던 선언형 접근(“2명 자리 주세요.”)에는, Red Lobster 직원이
    ‘테이블에 어떻게 앉는가’에 관한 모든 명령형(절차적) 단계들을 알고 있다는 가정이 뒷받침되어 있다.
  • 친구에게 우리 집의 주소를 알려주는 것도, 친구가 ‘우리 집에 어떻게 도착할 수 있는가’에 관한 명령적 절차들을
    모두 알고있는 일종의 GPS 같은 것을 가지고 있다는 것을 전제로 한다.
  • 오토 스틱(2종) 자동차는 변속 기어에 대해 일종의 추상화 계층(Layer)을 가지고 있다.

 

위의 내용들을 다음의 문장으로 다시 한 번 정리할 수 있다.

 

많은 선언적(Declarative) 접근 방식들의 기반에는 일종의 ‘명령적(Imperative) 추상화’가 존재한다.


이제, 여러가지 비유로 떡칠된 예시들을 졸업하고 현실 세계의 코드 예시를 살펴볼 차례이다.

그 전에, ‘선언적 프로그래밍 언어’와 ‘명령적 프로그래밍 언어’에는 어떤 것들이 있는지 간단히 살펴보자.

  • 명령적 언어: C, C++, Java
  • 선언적 언어: SQL, HTML
  • (Can be) Mix: Javascript, C#, Python

우선, 대표적인 선언형 언어인 SQL과 HTML의 코드를 살펴보자.

SELECT * FROM Users WHERE Country='Mexico';
<article>
  <header>
    <h1>Declarative Programming</h1>
    <p>Sprinkle Declarative in your verbiage to sound smart</p>
  </header>
</article>

이 두 가지 예시 모두 문법만 알고 있다면, 어떤 일이 일어나고 있는지 명확히 알 수 있다.

이 둘은 모두 선언형 프로그래밍이며, 어떤 일을 어떻게 수행하는가 보다는 무엇을 수행하는가에 관심이 있다.

즉, 우리가 무엇을 얻고자 하는가에 관해서만 묘사하고 있고, 그것을 어떻게 얻는가에 관해서는 알려주지 않는다.

 

SQL 예시에서는 멕시코에 거주하는 모든 유저들을 선택하는 ‘방법에 대한 구현’은 우리에게서 추상화되어있다.

HTML 예시에서는 ‘웹 브라우저가 어떻게 article 엘리먼트를 파싱해서 화면에 보여주는가’는 고려하지 않는다.

우리의 WHAT은 오직 ‘멕시코 유저들‘과 웹사이트의 ‘header와 paragraph‘이다.

 

지금까지는 충분히 알아먹을 수 있을 것 같다.

이제, 조금 더 실전적인 자바스크립트 예제로 들어가보자.


■ 기술 면접

당신은 현재 기술 면접을 보는 중이고, 나는 해당 기술 면접의 interviewer입니다.

콘솔창을 열고, 제가 묻는 질문에 해당하는 답을 작성해보세요.

 

1. 숫자 배열을 받아서, 해당 배열의 모든 원소들을 두 배 시킨
새로운 배열을 리턴하는 ‘double’이라는 이름의 함수를 작성하세요.

ex) double([1, 2, 3]) // [2, 4, 6]

 

2. 숫자 배열을 받아서, 해당 배열의 모든 원소들을 더한 값을 리턴하는 ‘add’라는 함수를 작성하세요.

ex) add([1, 2, 3]) // 6

 

3. jQuery나 Vanilla Javascript를 이용해서, btn이라는 id를 가진 엘리먼트에 이벤트 리스너를 달아보세요.

해당 버튼을 클릭했을 때 highlight라는 class를 toggle(add or remove)해야 하고,

엘리먼트의 현재 상태에 따라 버튼의 텍스트를 ‘Add Highlight’와 ‘Remove Highlight’로 바꿔야 합니다.

 

이 문제들에 대해, 가장 흔히들 작성하는 ‘명령적’ 코드들을 먼저 살펴보자.

function double (arr) {
  let results = []
  for (let i = 0; i < arr.length; i++){
    results.push(arr[i] * 2)
  }
  return results
}

function add (arr) {
  let result = 0
  for (let i = 0; i < arr.length; i++){
    result += arr[i]
  }
  return result
}

$("#btn").click(function() {
  $(this).toggleClass("highlight")
  $(this).text() === 'Add Highlight'
    ? $(this).text('Remove Highlight')
    : $(this).text('Add Highlight')
})

 

무엇이 이 코드들을 명령적으로 만드는지 알기 위해서는, 이 세 가지 코드들에서 공통점을 뽑아내야 한다.

 

1. 가장 명백한 공통점은 이들이 어떤 일을 어떻게 처리하는지에 관해 묘사하고 있다는 것.

각각의 예시에서, 우리는 명시적으로 배열을 반복하거나(for 문),

우리가 원하는 기능을 수행하기 위한 단계들을 명시적으로 나열하고 있다.

 

2. 각각의 예시에서 우리는 ‘상태(state)의 일부’를 변경하고 있다. 
(상태: 메모리에 저장되어 있는 것들에 대한 정보. 변수와 비슷하다고 생각하면 됨)

처음 두 예시에서는 ‘results’라는 변수를 만들어 그것을 계속해서 수정하고 있다.

세 번째 예시에서는 아무런 변수도 없지만, 여전히 DOM 자체에 state가 존재하고 있다.

그리고 해당 코드는 DOM의 state를 수정하고있다.

 

3. 약간 주관적이지만, 위의 코드들은 가독성이 떨어진다.

위의 코드들을 한 번 슥 훑어보고 어떤 일이 일어나고 있는지 바로 알아채기는 쉽지 않을 것이다.

우리의 뇌는 코드가 존재하는 맥락을 고려해가며, 해당 코드들을 인터프리터처럼 차근차근 살펴봐야 한다.


이런 똥쓰레기같은 코드들은 이제 그만 보고, 이제 선언적 예시들을 살펴보자.

선언적 예시들의 목적은 위에서 봤던 예시들의 문제점들을 모두 해결하는 것이다.

그러기 위해서 이 코드들은 무엇이 일어나는지에 관해 묘사해야 하고,

state를 변경해선 안되며한 눈에 파악할 수 있어야 한다(가독성이 좋아야 한다).

function double (arr) {
  return arr.map((item) => item * 2)
}

function add (arr) {
  return arr.reduce((prev, current) => prev + current, 0)
}

<Btn
  onToggleHighlight={this.handleToggleHighlight}
  highlight={this.state.highlight}>
    {this.state.buttonText}
</Btn>

처음 두 예제에서, 자바스크립트의 내장 함수인 map과 reduce를 활용한 레버리징에 주목하자.

이는 이 글 내내 반복해서 언급했던,

가장 효율적인 선언적 프로그래밍 방법은 명령적으로 작성된 코드를 추상화하는 것이다

라는 것에 관한 내용이다.

 

해당 예제들은 우리가 어떻게 처리할지보다, 무엇을 원하는지를 설명한다.

(우리는 map과 reduce가 어떻게 구현되어있는지는 전혀 알지도 못하고, 관심도 없다)

우리는 아무런 state도 변경하지 않는다. 모든 변경들은 map과 reduce 내부에 추상화되어있다.

그리고 당신이 map과 reduce에 익숙하다는 가정 하에, 훨씬 더 가독성이 좋다.

 

이제, 마지막 예제를 살펴보자.

여기서는 약간의 편법으로 리액트를 사용했다.

그러나 중요한 것은 명령형의 세 가지 문제점들이 모두 해결이 되었다는 것.

리액트의 진정한 강점은 이러한 선언적인 방식으로 UI를 작성할 수 있다는 것이다.

우리의 Btn 컴포넌트를 보면, 해당 UI가 어떤 식으로 보일지를 빠르게 알아챌 수 있다.

또 다른 강점은 state가 DOM에 존재하는 대신, 우리가 만든 리액트 컴포넌트 자체에 존재한다는 것.

 

선언적 프로그래밍의 또 다른, 덜 알려진 장점 중의 하나는

우리의 프로그램이 context-independent 해질 수 있다는 것이다.

(전체적인 맥락, 상황에 좀 더 독립적이다)

 

선언적 코드들은 최종적인 목표가 무엇인지에 대해서만 관심이 있지,

해당 목표를 이루기 위한 세부적인 단계들(해당 목표에 의존적인 과정들)에는 관심이 없다는 것.

그래서 동일한 코드들이 다른 프로그램에 쓰이더라도 정상적으로 동작할 수 있게 된다.

 

당장 위의 세 예시만 보더라도, 저 함수들이나 컴포넌트는

우리가 만들고자 하는 어떤 프로그램에 갖다붙여도 정상적으로 동작한다.

저들은 현재 어떤 프로그램에 속해있는가 하는 것에 전혀 구애받지 않는다.

명령형 코드들은 그렇지 못한 경우가 많은데, 그 이유는 대부분의 경우

명령형 코드들이 현재 상태의 컨텍스트에 의존적이기 때문이다.

(그래서 다른 곳에서 재사용하기가 어렵다)


이 글의 저자는, 선언적 프로그래밍에서 더 나아가 함수형 프로그래밍까지 다뤄보라고 권유하고 있다.

map, reduce, filter를 사용해보면서 차근차근 시작하라고 하는데, 함수형 프로그래밍에 관해서도

조만간 한 번 알아보는 시간을 가지면 좋을 듯.

 

개인적으로 가장 와닿았던 부분은, 선언적 프로그래밍은 절차적 구현을 추상화함으로써 이루어진다는 것.

선언적 프로그래밍을 어떻게 해야 하는가에 대해 좀 더 감을 잡을 수 있게 해준 내용인 듯.

리뷰어분들께서 말씀하시는 ‘재사용성’이나 ‘순수 함수’에 관한 것들이 약간 일맥상통하는 부분이 아닌가 싶다.

 

최대한 독립적이고 재사용성이 높은 함수들을 구현하여, 해당 함수들의 조합으로 프로그래밍을 구성하면

전체 코드의 유지보수가 쉬워지고 가독성도 훨씬 높아지겠지. 그게 말처럼 쉽겠냐마는..


아래는 저자가 웹을 돌아다니며 발견한 선언적 프로그래밍의 또 다른 정의들.

 

Declarative programming is “the act of programming in languages that conform to the mental model of the developer rather than the operational model of the machine.”

 

선언적 프로그래밍은 “기계의 동작을 모델로 하는 것이 아닌, 개발자의 두뇌(정신, 생각)를 모델로 본딴 언어를 가지고 프로그래밍 하는 것” 이다.

 

 

Declarative Programming is programming with declarations, i.e., declarative sentences.

 

선언적 프로그래밍은 선언(선언적 문장, 선언문)들을 사용해서 프로그래밍하는 것이다.

?

 

 

The declarative property is where there can exist only one possible set of statements that can express each specific modular semantic. The imperative property is the dual, where semantics are inconsistent under composition and/or can be expressed with variations of sets of statements.

 

선언적 속성이란, 특정 모듈을 설명하는 문장 집합이 단 하나만 존재할 수 있다는 것을 의미한다. 명령적 속성은 이중적이고, 이는 의미들의 구성에 일관성이 없고 여러 가지 문장 집합들로 표현될 수 있다는 것을 의미한다.

 

 

Declarative languages contrast with imperative languages which specify explicit manipulation of the computer’s internal state; or procedural languages which specify an explicit sequence of steps to follow.

 

선언적 언어는 컴퓨터의 내부 상태를 명시적으로 조작하는 명령형 언어, 또는 밟아야 하는 일련의 절차들을 명시적으로 지정하는 절차적 언어와 반대된다.

 

 

In computer science, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow.

 

CS에서 선언적 언어는 제어 흐름을 설명하지 않고, 계산 로직을 표현하는 패러다임(개념)이다.

 

 

I draw the line between declarative and non-declarative at whether you can trace the code as it runs. Regex is 100% declarative, as it’s untraceable while the pattern is being executed.

 

나는 코드의 실행을 추적할 수 있는지 여부에 따라 선언형과 비선언형을 구분한다.

정규표현식(Regex)은 패턴이 실행되는 동안 그것을 전혀 추적할 수 없기 때문에 100% 선언적이라고 할 수 있다.

+ Zereight’s Blog에서 본 인상적인 설명

명령형 프로그래밍은 문제를 어떻게 해결해야하는지 컴퓨터에게 명시적으로 명령을 내리는 방법을 의미하고,

선언형 프로그래밍은 무엇을 해결할 것인지에 보다 집중하여 어떻게 문제를 해결하는지에 대해서는

컴퓨터에게 위임하는 방법이다.

 

처음 프로그래밍이라는 개념이 등장했을 떄부터, 지금까지도 컴퓨터에게 명시적으로 명령을 내리는 방법인

명령형 프로그래밍을 주로 사용했지만, 함수형 프로그래밍은 문제를 해결하는 방법에 더 집중하고

사소한 작업은 컴퓨터에게 넘겨버리는 선언형 프로그래밍의 일종이다.

 

즉, 컴퓨터에게 사소한 작업들을 위임해버리는 패러다임의 특성 상

선언형 프로그래밍에는 필연적으로 높은 수준의 추상화라는 키워드가 붙는다.

추상화 수준이 낮다면 저 사소한 작업들을 개발자가 일일이 다 컨트롤해야한다는 의미이기 때문이다.

[출처] https://iborymagic.tistory.com/73

Loading

12 10월 2025

[사회과학] [박진영의 사회심리학] 달콤한 디저트도 가끔 먹어야 맛있다

[사회과학] [박진영의 사회심리학] 달콤한 디저트도 가끔 먹어야 맛있다

[박진영의 사회심리학] 달콤한 디저트도 가끔 먹어야 맛있다

입력
오픈AI 제공

오픈AI 제공

늘 자신에 대해 불만이 많고 자신은 부족함 투성이라고 하는 지인이 있었다. 세상에 완벽한 사람은 없으니까 부족함은 당연히 있겠지만 중요한 것은 그에 못지 않게 멋진 점도 엄청 많은데 그것들을 다 제쳐두고 자신에게 없는 부족한 것들만 바라보며 우울감에 빠져드는 편이었다.

도대체 왜 그러는 건지 곰곰이 생각해 보니 개인 내적인 문제들도 있겠지만 한국에서 소위 정상적인 삶을 살고 있고 그 중에서도 한참 성취도가 높은 사람들 사이에만 둘러싸여 있는 것이 한 몫 하는 것 같다는 생각이 들었다.

언젠가부터 자신의 불만과 불안을 이야기할 때 항상 ‘다른 사람들은’, ‘직장 동료 누구는’ 무엇 무엇을 가지고 있는데 자신은 그렇지 못하다는 식이었다.

사회적 동물인 우리는 기본적으로 타인과의 비교를 통해서 자신이 어느 정도 성취하고 있는지 다른 사람들이 볼 때 쓸모 있는 사람인지를 가늠한다. 예를 들어 모두가 10 정도를 하고 있는 사회에서 나 혼자 6을 하고 있다면 좀 더 분발해야겠다고 볼 수 있을 것이고 반대로 15를 하고 있다면 이미 잘 하고 있다고 볼 수 있겠다.

문제는 비교가 ‘의미 없는’ 문제에 대해서 ‘지나칠’ 정도로 비교를 하는 경우가 많다는 것이다. 예를 들어 나의 수학 능력에 대해 파악하고 싶다면 주변 사람들에 비해 나의 수학 점수가 어느 정도인지 아는 것이 조금 도움이 될 수 있겠지만 내 내면세계의 풍부함, 생각의 깊이, 오늘 나는 행복했는지 같이 객관적인 기준보다 주관적인 판단의 영역에 있는 문제들은 비교가 유용한 정보를 가져다 주지 못한다.

또 도움이 되는 비교라고 해도 정도껏, 딱 1절까지만 해야 하는데(성취도가 좀 부족한 것 같으니 열심히 해야겠다고 생각하기), 계속해서 온갖 것에 대해 비교하며 나는 왜 이렇게 남들에 비해 부족한지 나는 쓸모 없는 인간인 게 아닐지 등등 그다지 도움이 되지 않는 생각으로 빠져들고 우울감과 무력감에 허우적 거리는 경우가 적지 않다.

이렇게 많은 사람들이 숨쉬듯이 비교를(불필요한 영역에서+지나치게) 하다 보니 웬만하면 비교하지 말라는 조언들을 듣게 된다.

하지만 주변에 성취도가 너무 높은 사람들만 잔뜩 알고 있거나 이런 사람들에게만 주의를 기울이다 보면 비교의 늪에 빠지지 않는 것이 보다 어려운 일이 된다.

물론 이런 상황에서도 알아두어야 할 것은 우리가 타인에게서 무언가를 부러워할 때면 보통 겉으로 보이는 한 두 가지 반짝이는 면에만 꽂혀 있을 때가 많다는 것이다. 그 삶의 이면에 어떤 모습이 있는지는 보통 신경 쓰지 않을 때가 많다.

타인의 삶을 바라볼 때에는 피상적인 정보를 전체로 일반화 해서 부러워하면서 자신의 삶을 불만족스러워 할 때에는 좋은 부분도 많지만 싫은 부분도 많기 때문에 나쁘다고 결론짓는다. 하지만 내가 그러하듯 내가 부러워 하는 삶을 살아가는 당사자들도 자신의 삶에 대해 생각할 때에는 머리가 복잡하다는 점을 기억하자.

“누구한테 어떤 좋은 일이 있었다더라” 하는 소문들도 쉽게 부럽다는 생각을 불러일으키곤 하지만 살아가면서 겪는 특별히 좋은 일이란 보통 아주 가끔 나타난다는 사실을 기억하자. 삶은 긴 일상들이 연속되는 ‘시간’이고 매일 특별함으로 가득한 날을 살아가는 사람은 드물다.

설령 늘 좋은 일이 생긴다 해도 인간은 좋은 일이든 나쁜 일이든 금방 적응하는 ‘적응’의 동물이다. 처음에는 아주 좋아 보였던 것도 막상 가지고 나면 처음의 기쁨은 금새 없어지고 다시 평범하고 당연한 무엇이 되기 마련이다. 감정은 어떤 종류이건 시간이 지나면서 점차 사그라드는 성질을 가지고 있기 때문이다.

그러다 보니 (생존에 크게 위협받는 상황에 처해있지 않다는 전제 하에) 어떤 몇 가지 거대한 이벤트로 ‘그 후로 영원히 행복하게 살았답니다’ 같은 행복을 얻는 것은 쉽지 않다. 너무 좋을 것 같은 일도 대략 두 달을 넘기지 못하고 우리의 감정 상태는 ‘일상’으로 돌아오고 만다.

이러한 점 때문에 행복으로 가는 길에 대해 이야기할 때 즐거움의 크기를 계속해서 늘리기보다 기준점을 낮추는 것이 더 중요하다고 보는 시각도 있다.

예를 들어 매일매일 달콤한 디저트를 먹기보다 가끔씩 먹는 것이 더 먹는 즐거움을 오래도록 느끼게 해줄 수 있다는 것이다. 또는 매일매일 생일파티를 하는 것보다 일년에 한 번 하는 것이 더 생일파티의 즐거움을 오래도록 즐길 수 있게 해주지 않을까.

누군가는 생일 파티를 매일 하는 것처럼 보여도 적어도 행복에 있어서는 크게 부러워할 필요 없다는 사실을 기억해보자.

※필자소개
박진영. 《나, 지금 이대로 괜찮은 사람》, 《나를 사랑하지 않는 나에게》를 썼다. 삶에 도움이 되는 심리학 연구를 알기 쉽고 공감 가도록 풀어낸 책을 통해 독자와 꾸준히 소통하고 있다. 온라인에서 ‘지뇽뇽’이라는 필명으로 활동하고 있다. 현재 미국 듀크대에서 사회심리학 박사 과정을 밟고 있다.

Loading

12 10월 2025

▲ “튜토리얼 지옥”을 대체한 “바이브 코딩 지옥”의 등장

13P by GN⁺ 16시간전 | ★ favorite | 댓글 2개
  • 최근 코딩 교육 환경에서 “튜토리얼 지옥” 대신 “바이브 코딩 지옥” 이 새로운 문제로 대두됨
  • 튜토리얼 지옥이 “튜토리얼 없이는 아무것도 만들지 못하는” 상태였다면, 바이브 코딩 지옥은 “AI 없이는 코딩할 수 없고, AI가 생성한 코드가 어떻게 작동하는지 이해하지 못하는” 상태를 의미
  • AI 도구의 과도한 사용이 학습 동기를 저하시키며, AI 리터러시가 낮은 사람일수록 AI를 더 많이 사용하는 역설적 상황이 발생하고 있음
  • AI 도구는 적절하게 활용하면 학습 보조에 큰 도움이 될 수 있으나, 무작정 ‘답만 얻기’식 사용은 건설적 이해 형성에 방해가 됨
  • 학습 과정에서 직접 고민하고 스스로 해결하려는 노력이 핵심, 튜토리얼·AI 보조 없이 문제 해결 경험을 쌓는 자세가 중요함

문제의 배경: 튜토리얼 지옥에서 바이브 코딩 지옥으로

  • 2019년 당시 코딩 교육의 주요 문제는 “튜토리얼 지옥” 이었음
    • 튜토리얼을 따라하는 데는 성공하지만 혼자서는 아무것도 만들지 못함
    • 실제 프로그래밍보다 프로그래밍 관련 동영상 시청에 더 많은 시간을 소비하며, 핵심 개념은 이해하지 못함
    • 결과적으로 피상적 지식만 쌓고, 내부 작동 원리는 이해하지 못해서 현실에서는 코드를 스스로 쓰지 못하는 상태
  • Boot.dev는 이를 해결하기 위해 세 가지에 집중함
    • 심층 커리큘럼: 전통 대학 외부에서도 CS 기초를 배울 필요성 강조
    • 실습 중심 방식: 모든 개념 학습과 함께 코드를 직접 작성
    • 비디오보다 리치 텍스트 강화: 비디오는 수동적 소비에 그칠 위험성 있음
  • 2019년에는 수백만 조회수를 기록하던 긴 YouTube 강의들이 현재는 5만 조회수도 달성하기 어려움
    • FreeCodeCamp, Traversy Media, Web Dev Simplified 등의 채널이 이러한 추세를 보임
  • 그러나 “learn to code”에 대한 Google Trends 데이터는 여전히 높은 관심도를 유지하고 있음
  • Boot.dev에 매일 약 1,300명의 신규 사용자가 등록하며, 최근 18개월간 튜토리얼 지옥에 대한 불만은 줄었지만 새로운 형태의 어려움이 나타남

바이브 코딩 지옥의 정의

  • 튜토리얼 지옥의 특징
    • “튜토리얼 없이는 아무것도 만들 수 없다”
    • “문서를 이해하지 못하니 동영상이 필요하다”
    • “간단한 작업에도 복잡한 프레임워크가 필요하다”
  • 바이브 코딩 지옥의 특징
    • “Cursor의 도움 없이는 아무것도 할 수 없다”
    • “멋진 타워 디펜스 게임을 만들었어요. 여기 링크에요 http://localhost:3000″;
    • “이미지 lazy-load를 위해 Claude가 6,379줄을 추가한 이유를 모르겠어요”
  • 현재 자기주도 학습자들은 많은 것을 만들고 있지만, 소프트웨어 작동 방식에 대한 멘탈 모델을 발전시키지 못하는 프로젝트를 구축
  • AI의 환각(hallucination)과 싸우고, 테스트 통과에만 집중하는 봇과 씨름하며 실제 문제 해결보다는 AI가 생성한 코드를 맹목적으로 신뢰

AI 코딩의 미래와 현실

  • 나는 단기적으로 AI가 개발자를 완전히 대체하지는 않을 것이라는 데 긍정적 입장
    • “AI가 일자리를 빼앗을 때까지 6개월”이라는 말이 나온 지 3년이 지났지만 여전히 개발자를 고용하고 있음
  • GPT-5가 출시되었지만 GPT-4 대비 점진적 개선에 그쳤으며, AGI가 곧 도래하지 않을 것임을 보여주는 증거로 해석됨
  • 매일 AI 도구를 사용하지만 실제로 생산성이 얼마나 향상되는지 확신하지 못함
    • AI가 더 생산적이게 만드는지, 아니면 더 게으르게 만드는지 불분명
  • 2025년 연구 결과: 개발자들은 AI가 20-25% 생산성을 높인다고 가정했지만, 실제로는 19% 느려짐
    • 7조 달러 투자 대비 실망스러운 결과

AI와 학습동기 저하의 위험성

  • AI 활용 문화가 학습자의 동기 부여에 부정적일 수 있음
  • AI 열풍(버블?)에서 가장 우려되는 점은 “왜 배워야 하나? AI가 다 알잖아”라는 태도를 가진 세대가 등장한다는 것
  • AI가 실제로 모든 화이트칼라 직업을 대체하지 못한다면, 주식 시장 버블뿐 아니라 교육받은 인력의 가뭄도 겪게 될 것
  • 기술적 배경이 없는 투자자들은 “AI가 이미 코딩의 전부를 대체했다”고 오해하고, 시니어 개발자들은 여전히 AI 도구를 일상 업무에 통합할 유용한 방법을 찾지 못함
  • AI 리터러시가 낮은 사람일수록 AI를 더 많이 사용하는 경향이 있어 우려됨
    • 궁극적인 ‘Dunning-Kruger(더닝-크루거)’ 함정으로 작용 – 지식이 부족한 사람이 오히려 자신이 잘 안다고 착각하는 현상
    • 학습자들이 “AI가 이미 알고 있으니” 자기계발이 무의미하다고 결론 내림

AI는 학습에 유익한가?

  • 여전히 코딩 배우기에 대한 사회적 관심도 높음
  • AI가 학습에 유익할 수도 있지만, 두 가지 구조적 문제가 존재함
  • 첫 번째: 아첨(sycophant) 문제

    • AI 챗봇은 질문자 의견에 과도하게 동조하는 경향이 있음
    • “ROAS(광고수익률)에 대해” 채팅해보면, 같은 데이터를 놓고 질문 방향에 따라 정반대 결론을 내며, 모두 전문가적 어조로 확신 있게 답함
    • 이는 학습자에게 검증, 비판적 사고, 오류 지적을 경험할 기회를 박탈함
      • 전문가에게 묻는 이유는 우리가 틀렸을 때 알려주기 위함
      • IRC 채팅이나 Stack Overflow는 이를 잘 수행했음(아마도 너무 잘)
      • LLM(대형언어모델) 챗봇은 기존 학습자의 근본적 오해를 바로잡지 못하는 경향이 강함
      • 현재 학생들은 LLM과 편안한 대화를 나누며 필요한 것이 아닌 듣고 싶은 것을 듣게 됨
  • 두 번째 문제: 학습자는 실질적 ‘의견’을 원함

    • AI는 지나치게 균형 잡힌 입장을 제시함
      • “어떤 사람들은 X라고 생각하고 어떤 사람들은 Y라고 생각한다”
      • 학습자가 어느 쪽에 동의할지 결정하기 더 어려워짐
    • “자본주의자 역할” 또는 “마르크스주의 혁명가 역할”을 하도록 프롬프트했지만 만족스러운 결과를 얻지 못함
    • 학습자는 실제 경험에서 나온 의견과 논평을 듣고 싶어함
      • DHH가 Turbo에서 TypeScript를 제거한 이유
      • Anders Hejlsberg가 TypeScript가 JavaScript 개발자에게 해결해주는 것
      • 각 저자의 편견과 맥락이 명확히 드러나는 실제 의견을 통해 미묘한 멘탈 모델이 형성됨
    • LLM 특유의 중립적·조심스러운 답변은 실제 지식 내면화에 방해가 됨

AI가 학습에 진짜 도움 되는 경우

  • AI는 올바르게 사용하면 학습을 위한 놀라운 도구
  • 코딩을 배우기에 이보다 쉬운 시대는 없었음
  • Boot.dev의 Boots(AI 교육 보조 도구) 사례
    • 학생들이 인스트럭터 솔루션(이상적인 정답)을 보는 것보다 AI 튜터(Boots)와 채팅하는 것을 거의 4배 더 많이 사용
    • Boots는 일반 챗봇과 달리 다음 방식으로 학습에 도움 줌
      • 답을 직접 알려주지 않도록 사전 프롬프팅
      • 소크라테스식 방법을 사용하여 학생이 문제에 대해 더 깊이 생각하도록 유도
      • 강사의 솔루션에 접근할 수 있어 정답에 대한 환각 가능성이 훨씬 낮음
      • 즐거운 캐릭터성 부여(마법사 곰)

바이브 코딩 지옥 탈출법

  • 결론적으로, 튜토리얼 지옥이든 바이브 지옥이든, ‘남에게 맡기지 말고 스스로 해보는 경험’ 이 매우 중요함
    • 튜토리얼 지옥: 비디오 끄고 직접 코드 작성 경험 쌓기
    • 바이브 지옥: 코파일럿 등 AI 자동완성 꺼두고, 스스로 문제 해결 경험 쌓기
  • 피해야 할 것:
    • 에디터 내 AI 자동완성
    • 에이전트 모드 및 AI 자동화 도구로 프로젝트 처리
  • 활용할 수 있는 것:
    • 질문에 답하고, 개념을 설명하고, 예제를 제공하는 챗봇
    • 소크라테스식 방법으로 질문하도록 유도하는 시스템 프롬프트를 통해 깊은 사고 촉진
    • 주장을 할 때 출처를 인용하고 문서에 링크하도록 요청하는 시스템 프롬프트로 정보 신뢰성 확보

핵심 원칙

  • 학습은 반드시 불편해야 함
    • 튜토리얼 지옥은 다른 사람이 코딩하는 것을 보면서 불편함을 피할 수 있게 해줌
    • 바이브 코딩 지옥은 AI가 코드를 작성하게 하면서 불편함을 피할 수 있게 해줌
  • 진짜 학습은 막히고, 좌절하고, 가장 중요하게는 문제 해결을 강제당할 때 일어남
    • 이것이 인간의 신경망이 재배선되는 방식
  • “학습은 어려워야 한다”는 개념을 지나치게 확대하면 형편없는 교육 설계의 변명이 될 수 있음
    • 저자는 이를 옹호하지 않음
    • 개념이 최선의 방식으로 설명되더라도, 학생은 여전히 그것과 씨름하고 새로운 맥락에서 스스로 사용해야 진정으로 이해할 수 있음
  • 진짜 학습 은 직접 막히고, 좌절하고, 자신의 힘으로 돌파하는 과정에서 완성됨

[출처] https://news.hada.io/topic?id=23590

Loading

9 10월 2025

[사회과학] [알아봅시다] [박진영의 사회심리학] ‘자기 과몰입’ 불행의 원인

[사회과학] [알아봅시다] [박진영의 사회심리학] ‘자기 과몰입’ 불행의 원인

[박진영의 사회심리학] ‘자기 과몰입’ 불행의 원인

입력
오픈 AI 제공

오픈 AI 제공

많은 연구들이 자아에 지나치게 몰입하는 저주, ‘자신에 대한 생각’ 외에 더 중요할 수 있는 것들(예를 들어 눈앞에 있는 상대가 하는 이야기를 귀담아듣기, 다른 사람들의 삶과 사회적으로 일어나고 있는 일들에 대해서도 관심 갖기)이 잘 되지 않고 오직 자기 자신에게만 몰두하는 자기 과몰입(self-preoccupation)이 불행의 주원인이 된다는 것을 보여주었다.

아무 일 없이 가만히 있다가도 ‘과연 내 삶은 내가 원하는 대로 돌아가고 있는지’ 같은 생각을 시작하면 얼마든지 갑자기 내 인생은 망한 것 같다는 파괴적인 결론을 내리며 깊은 우울감에 빠질 수 있는 것이 사람이다. 실제로 지나친 자기 집중, 자기 자신에 대한 생각은 우울증과 깊은 관련을 보인다.

자기 몰입에는 다음과 같은 것들이 포함된다. 모든 일을 자신의 관점에서만 바라보고 해석하는 자기중심성(egocentrism), 다른 사람들보다 자신의 안녕을 중시하는 이기심(egoism), 타인의 시선을 지나치게 신경 쓰며 남들이 원하는 삶을 살아가는 타율성(heteronomy) 등이 흔히 나타난다.

이에 반해 마크 리어리 듀크대 심리학자 등의 연구자들은 저(低) 자기 몰입(hypo-egoic) 상태가 우리 삶 속에 불필요한 불행을 줄여주고 마음의 평화를 가져다줄 것이라고 본다.

구체적으로는 과거나 미래보다 현재의 상황에 더 집중하고, 자신의 생각이나 감정에 대해 지나치게 들여다보지 않으며, 자기 자신을 바라볼 때 추상적이고 과장된 방식이 아니라 구체적인 수준에서 바라보고(예를 들어 나는 성공한 인간인가? 같은 추상적인 질문보다 오늘 하루 즐거웠나?라고 묻기) 다른 사람의 평가를 덜 신경 쓰는 것을 말한다.

이런 저(低) 자기 몰입 상태는 자기 과몰입 상태에 비해 나나 내 집단의 생각만 옳다고 믿는 좁은 관점에서 벗어나 좀 더 넓은 세상을 바라볼 수 있게 돕고 기존의 자아상이 위협을 받는 어려운 상황에서 좀 더 적응적으로 대처할 수 있게 돕는다.

● 자기 자비, 수용, 그리고 회복탄력성

자기 과몰입 상태의 가장 큰 문제 중 하나는 ‘경직된 자아관’이다. 이상적인 삶, 이상적인 나의 모습은 적어도 얼마를 벌어야 하고 어떤 배경들을 가져야 하며 어떤 사람들과 어울려야 한다는 등 촘촘하고 세세한, 때로는 상당히 비현실적인 자아관을 강하게 밀고 있기 때문에 작은 실패에도 금방 부러지고 만다.

‘○○하지 않으면 살 필요가 없어’ 같은 생각이 마치 벗어날 수 없는 함정처럼 촘촘한 그물을 짜고 있는 것이다.

때문에 작은 일에도 나라는 사람 전체가 쉽게 꺾이는 듯한 일반화된 좌절을 느끼게 된다. 그러다 보니 자아관이 경직되어 있을수록 자신의 실패를 잘 인정하지 못하고 ‘내 잘못이 아니고 다른 사람들 탓’이라는 식으로 문제를 회피해 버리는 현상도 나타난다.

여기에 자기 자비(self-compassion)가 한 가지 대안이 될 수 있다. 자기 자비란 어디까지나 인간일 뿐인 자신의 한계를 인정하고(예를 들어 물론 슬프지만 인간인 내가 실수하고 일을 망치는 건 당연한 일), 힘들어하는 친구를 대하듯 자신에게도 따뜻하고 친절한 태도를 보이는 것을 말한다.

힘들어하고 있는 상황 자체를 곧 내가 부족한 인간이라는 뜻으로 해석하는 성급함에서 한 발 물러나 좀 더 넓은 상황을 바라보며 인간일 뿐인 내가 힘들어하는 것은 당연한 일이고 나뿐만 아니라 많은 사람들이 다양한 어려움들을 가지고 있음을 힘들다는 것은 내가 멍청하고 아무 노력도 하지 않았다는 것을 반증하는 것이 아니라 다만 내가 인간이라는 것을 뜻할 뿐임을 바라볼 줄 아는 것이다.

많은 연구들이 특히 경직된 사회적 기준을 내면화해서 경직된 자기 기준을 가지고 있는 사람들에게 자기 자비가 불필요한 괴로움을 줄여주고 보다 쉽게 마음의 평화를 가지도록 돕는다는 것을 보여주었다.

내가 힘든 것이 인간으로서 겪는 매우 자연스러운 일이라면 우리가 해야 할 일은 가뜩이나 힘든데 더 윽박지르고 더 벼랑 끝으로 내모는 것보다는 위로와 친절, 내가 나를 어떻게 도울 수 있을지 생각하는 것이다.

자기 과몰입에서 한 발 물러서서 자기 비판적인 생각을 “진짜 나의 본질”로 여기지 않고 단순히 어려움의 신호로 받아들이는 것. 기억해 보자.

※필자소개
박진영. 《나, 지금 이대로 괜찮은 사람》, 《나를 사랑하지 않는 나에게》를 썼다. 삶에 도움이 되는 심리학 연구를 알기 쉽고 공감 가도록 풀어낸 책을 통해 독자와 꾸준히 소통하고 있다. 온라인에서 ‘지뇽뇽’이라는 필명으로 활동하고 있다. 현재 미국 듀크대에서 사회심리학 박사 과정을 밟고 있다.

Loading

9 10월 2025

[一日30分 인생승리의 학습법] ▲ 2025년 가장 인기 있는 프로그래밍 언어 (spectrum.ieee.org)

[一日30分 인생승리의 학습법] ▲ 2025년 가장 인기 있는 프로그래밍 언어 (spectrum.ieee.org)

  • Python > Java > C++ > SQL > C# > JavaScript > TypeScript > C > Shell > Go > R > PHP > Kotlin > Rust > Dart > Swift
  • IEEE Spectrum 조사 결과 Python이 올해도 1위를 차지, JavaScript는 3위에서 6위로 떨어짐
  • 이 변화는 웹 개발에 많이 쓰이는 JavaScript가 AI 기반 코딩(예: vibe coding)으로 대체되는 흐름과 연관된 것으로 분석됨
  • 전통적으로 사용되던 Stack Exchange 질문 수, GitHub 활동 같은 지표는 AI 도입 이후 급감하여, 언어 인기 측정의 기존 방법이 흔들리는 상황
  • AI 코드 생성이 보편화되면서 언어의 문법·구조 차이 중요성이 줄고, 특정 언어에 집착하지 않는 흐름이 뚜렷해짐
  • 이는 새로운 언어 등장과 생태계 확산을 막고, 결국 프로그래밍 언어 인기도의 개념 자체가 사라질 가능성을 보여줌

개요

  • IEEE Spectrum이 2025년 주요 프로그래밍 언어와 트렌드를 종합적으로 분석한 결과를 발표
  • 이 순위는 취업 시장, 오픈소스 생태계, 학계 및 업계 활용도 등 다양한 관점을 반영
  • 주요 언어별 특징, 성장 배경, 그리고 기술 분야별로 특화된 언어에 대한 정보도 함께 제공

올해의 언어 순위

  • 2025년 Spectrum 기본 순위에서 Python이 1위 유지, JavaScript는 6위로 하락함
  • Jobs 순위에서도 Python이 1위로 올라섰고, SQL은 여전히 채용 시장에서 강력한 경쟁력을 보유함
  • 전체 언어 관련 Stack Exchange 질문 수는 2024년 대비 22% 수준으로 감소했음

순위 산정 기준

  • 인기도: 다양한 온라인 포럼, 소프트웨어 저장소, 구인 구직 데이터, 검색 트렌드 등을 활용해 산정함
  • 현업 활용도: 기업 채용 공고와 오픈소스 프로젝트 참여도를 기준으로 실제 시장에서 많이 쓰이는 언어를 분석함
  • 분야별 분석: AI, 임베디드, 웹, 모바일 등 기술 세부 분야에서 두드러진 언어 선정 기준을 반영함
  • 인기도 측정을 위해 Google 검색량, Stack Exchange 질문, GitHub 활동, 논문 언급 등 다양한 지표를 활용했음
  • 하지만 개발자들이 LLM(ChatGPT, Claude 등)과의 대화로 문제를 해결하면서 공개된 데이터 신호가 줄어듦
  • AI 도구(Cursor 등) 덕분에 질문 자체가 줄어 기존 지표의 유효성이 약화됨

AI와 언어의 경계 희미화

  • 숙련된 개발자부터 초보자까지 AI에 의존하면서 언어의 문법, 제어 구조에 대한 신경이 줄어듦
  • AI는 충분한 학습 데이터만 있으면 어떤 언어로도 코드 생성이 가능함
  • 이에 따라 언어 선택은 하드웨어의 CPU 명령어 차이처럼 부차적인 요소로 전락할 수 있음
  • 향후 언어 인기도 논쟁은 철도 궤간 비교 수준의 비주류 화제로 밀려날 수 있음

새로운 언어의 등장이 더욱 어려워 질 것

  • 과거에는 책, 데모, 샘플 코드만으로도 언어 생태계가 퍼질 수 있었음 (예: The C Programming Language)
  • 그러나 AI는 대량의 학습 데이터를 요구하기 때문에 신생 언어는 지원이 불리함
  • 실제로 덜 사용되는 언어에서 AI가 더 나쁜 결과를 내는 현상이 보고됨
  • 이는 새로운 언어가 임계 질량을 확보하기 어려운 환경을 만들 수 있음

프로그래밍의 미래

  • 현대 언어는 본질적으로 데이터 처리 추상화와 개발자 오류 방지 두 가지 역할을 수행함
  • 그러나 AI 발전은 언어 구조보다 프롬프트 → 중간 언어 → 실행이라는 새로운 흐름을 가능케 함
  • 이 경우 소스 코드를 유지·수정하기보다 프롬프트를 조정해 재생성하는 방식이 자리잡을 수 있음
  • 미래 프로그래머의 역할은 언어 문법보다는 아키텍처 설계, 알고리듬 선택, 시스템 통합 능력에 집중될 전망임

결론과 전망

  • 프로그래밍은 1950년대 컴파일러 등장 이후 최대 변혁기를 맞이하고 있음
  • AI 거품이 일부 꺼지더라도 코드 작성을 돕는 LLM 활용은 지속될 가능성이 높음
  • 따라서 2026년 이후에는 “인기 언어”라는 개념 자체가 의미를 잃을 수 있으며, 인기도를 측정하는 새로운 지표가 필요함

[출처] https://news.hada.io/topic?id=23330

Loading

27 9월 2025

[사회과학] [박진영의 사회심리학] ‘속 시끄러운’ 자아 비워야 진정한 나를 찾는다

[사회과학] [박진영의 사회심리학] ‘속 시끄러운’ 자아 비워야 진정한 나를 찾는다

[박진영의 사회심리학] ‘속 시끄러운’ 자아 비워야 진정한 나를 찾는다

입력
오픈AI 제공

오픈AI 제공

내가 좋아하는 선생님 한 분이 예전에 이런 이야기를 한 적이 있다. 비가 심하게 내리는 날 창밖에서 홀딱 젖은 새를 보고는 안됐다는 생각이 들었는데 이내 부러움을 느꼈다고 한다.

물론 춥고 축축한 게 싫겠지만 새는 “아 정말 오늘 날씨 왜 이래. 춥고 축축해서 짜증나. 마음대로 되는 게 하나도 없어. 살기 싫다!” 같은 피곤하고 파괴적인 자기 대화(self-talk)를 하지 않을 것이기 때문에 결국 인간이 더 괴로운 것 같다는 얘기였다.

‘자아의 저주(The curse of the self)’라는 말처럼 인간은 (어쩌면 필요 이상으로) 시시각각 평가적이고 말이 많은 자아를 가진 탓에 이미 존재하는 삶의 괴로움에 더해 자아가 만들어낸 괴로움까지 추가로 지고 살아간다.

개미들도 부지런히 일하느라 힘들겠지만 자신이 다른 개미들보다 뒤쳐지고 있는 것 같다는 불안함, 인플루언서 개미가 되고 싶은데 그렇지 못한 현실에서 오는 자괴감, 자신에게 많은 것을 기대하고 있는 부모님에 대한 미안함과 실망시키고 싶지 않다는 생각 등 ‘자기 자신에 대한 생각’ 때문에 가만히 잘 있다가도 불안감이 엄습하고 눈물이 날 것 같은 일은 잘 겪지 않을 것이다.

이렇게 남들과 다른 ‘나’에 대해 생각하고 머리부터 발 끝까지 ‘나’를 구성하는 요소들을 하나 하나 세세히 평가하고 시공간을 넘나드며 과거의 자신과 미래의 자신에 대해 생각하는 정신적 기능을 ‘자아’라고 부른다.

이렇게 자기 자신을 모니터링하고 자아 성찰, 미래에 대한 계획 세우기 등이 가능해진 덕분에 장기적 목표 달성 같은 것이 가능해졌다. 하지만 안타깝게도 여기에는 많은 부작용이 따른다.

물도 지나치게 많이 먹으면 해로울 수 있는 것처럼 뭐든지 지나치게 하는 것은 좋지 않다. 자아도 마찬가지다. 안타깝게도 우리는 그러지 않아도 될 때에도 자기 자신에 대한 생각과 평가에 지나치게 사로잡혀 있는 편이다.

그러다 보니 ‘자신에 대한 생각’ 외에 더 중요할 수 있는 것들, 예를 들어 눈 앞에 있는 상대가 하는 이야기를 귀 담아 듣기, 다른 사람들의 삶과 사회적으로 일어나고 있는 일들에 대해서도 관심 갖기 같은 것이 잘 되지 않고 오직 자기 자신에게만 몰두하는 현상(self-preoccupation)이 나타난다.

또 세상 모든 일을 내 관점에서만 바라보고 해석하는 자기중심성(egocentrism), 다른 사람들보다 나의 안녕을 중시하는 이기심(egoism), 타인의 시선을 지나치게 신경쓰다가 자신이 원하는 삶보다 남들이 원하는 삶을 살아가는 타율성(heteronomy) 등이 흔히 나타난다.

이렇게 자기 자신에게 과한 주의를 기울이고 내가 생각하는 나의 모습, 내가 생각하는 내 모습에 불과한 것에 심하게 집착하는 상태를 ‘과도한 자기 몰입(hyper-egoic states)’이라고 부른다.

이미 많은 종교와 철학적 가르침들이 자아에 과도하게 집착하지 말고 한 발짝 떨어져 있을 것을 강조해왔다. 대표적으로 불교에서는 이상적인 자아상에 대한 집착이 갈망, 분노, 질투의 근원이라고 보고 명상 등을 통해 자기 대화를 잠재우는 법을 가르쳐왔다.

신기하게도 과학적 발견들도 이와 비슷한 결과를 보여주고 있다. 인간으로서 갖는 본질적인 부족함들을 받아들이고 자기 자신과 타인에게 너그러운 마음을 품어보는 자기자비(self-compassion), 자신의 지식과 자아를 분리해서 자신이 틀릴 가능성이 있음을 받아들이고 그래도 괜찮다고 할 줄 아는 지적 겸손(intellectual humility), 힘들 때 ‘나만’, ‘내가 제일’ 고통받고 있는 것 같다는 좁은 생각에서 벗어나 인생은 원래 어느 정도 고통을 내포하고 있고 사람들은 다 각자의 짐을 지고 살아간다는 점을 생각할 줄 아는, 고통의 보편성에 대한 믿음 등이 행복과 정신 건강, 평정심, 회복탄력성, 이타심과 자비로운 마음과 긴밀하게 연결되어 있다는 연구들이 있었다.

하지만 이러한 사실들을 알더라도 우리의 자아는 여전히 말이 많고 대체로 안 좋거나 편향되어 있는 말을 쏟아낸다. 그래봤자 내 머리 속에 떠다니는 말들일 뿐이지만 깨어 있는 동안 계속해서 듣게 되기 때문인지 많은 사람들이 이를 ‘진실’로 여기고 우울이나 불안에 빠져든다.

자아만큼 나의 약점을 속속들이 알고 전문적으로 가스라이팅을 하는 게 또 있을까. 안타깝게도 자아는 우리의 가장 친한 친구인 동시에 가장 무서운 적인 셈이다.

그래서 더더욱 자아가 하는 말을 적당히 걸러 듣고 관심을 다른 데로 돌리는 시도가 필요하다. 명상이든 운동이든 맛있는 거 먹기, 영화 보기, 또는 친구와의 진솔한 대화가 되었건 내 자아로부터 한 발짝 떨어지게끔 도와주는 활동이 있다면 정기적으로 해보도록 하자.

바로 어제만 해도 내 자신이 한 없이 초라해 보이고 내가 할 수 있는 건 아무 것도 없는 것 같이 느껴졌지만 꿀잠을 자고 나니 왜 그렇게까지 자신을 나쁘게 생각했는지 알 수 없었던 적이 있을 것이다. 자아로부터 해방되는 시간들을 가져보도록 하자.

※필자소개
박진영. 《나, 지금 이대로 괜찮은 사람》, 《나를 사랑하지 않는 나에게》를 썼다. 삶에 도움이 되는 심리학 연구를 알기 쉽고 공감 가도록 풀어낸 책을 통해 독자와 꾸준히 소통하고 있다. 온라인에서 ‘지뇽뇽’이라는 필명으로 활동하고 있다. 현재 미국 듀크대에서 사회심리학 박사 과정을 밟고 있다.

Loading

23 9월 2025

[Java 일반] Public static void main(String[] args)는 죽었다 | GeekNews

[Java 일반] Public static void main(String[] args)는 죽었다 | GeekNews

  • 이제 Java의 첫 번째 프로그램은 더 이상 public static void main(String[] args) 로 시작하지 않고, 단순화된 void main() 문법으로 작성 가능해짐
  • 새로운 문법에서는 IO.readln과 IO.println 같은 간단한 호출만으로 입출력을 처리할 수 있어 코드가 훨씬 직관적으로 바뀜
  • 기존의 new Scanner(System.in)System.out.println 같은 장황한 구문은 불필요해짐
  • 그동안의 불편함이 “마침내 끝남”, 이제 Java의 기본 구조가 가벼워지면서 입문 장벽이 낮아지고 학습 친화성이 크게 향상될 것

  • 전통적으로 Java는 프로그램 시작을 위해 public static void main(String[] args) 라는 긴 선언을 요구했음
  • 그러나 2025년 9월 16일 기준, Java의 가장 첫 번째 예제로 여겨지던 main 함수의 복잡한 선언문이 새로운 간단한 형태로 대체됨
  • 기존 방식:
    public class Main {  
        public static void main(String[] args) {  
            Scanner scanner = new Scanner(System.in);  
            System.out.print("What is your name? ");  
            String name = scanner.nextLine();  
            System.out.println("Hello, " + name);  
        }  
    }  
    
  • 새로운 방식:
    void main() {  
        var name = IO.readln("What is your name? ");  
        IO.println("Hello, " + name);  
    }  
    
  • 초보자에게는 불필요하게 장황하고, “주술적 주문”처럼 외워야만 했던 구문이라는 비판을 받아왔음
  • 기존 선언문의 번거로움과 난해함을 해소하고, 간결한 문법 도입으로 코드 가독성이 높아졌으며, Java 입문의 진입 장벽이 크게 낮아짐
    • 더 이상 Scanner, System.out.println 등 복잡한 객체 생성과 호출을 기본 예제로 쓰지 않음

Good Fucking Riddance = “드디어 없어져서 속 시원하다. 잘 가라”

[출처] https://news.hada.io/topic?id=23138&utm_source=weekly&utm_medium=email&utm_campaign=202538

Loading