오른쪽 두뇌로 코딩하기

AI 시대를 살아갈 개발자 되기

오른쪽 두뇌로 그림 그리기,

1968년, 생물학자 '로저 스페리'는 인간 두뇌 기능에 대한 논문을 썼습니다. 인간의 두뇌(좌뇌, 우뇌)가 다른 방식의 사고를 한다는 내용이었죠.

1970년대 말, 학교에서 미술 지도를 맡은 '베티 에드워즈'는 아무리 가르쳐도 그림 실력이 늘지 않았던 학생들 때문에 좌절감에 빠져 있었습니다. 어떻게 가르쳐야 할지 고민하다 보니, 그림 그리는 스스로를 관찰하게 되었는데요. '말하면서 동시에 그림을 그릴 수 없다'는 사실을 깨달았습니다. 그래서, '로저 스페리'의 논문을 떠올린 거죠.

그렇게 새로운 그림 그리기 교수법을 개발했고, <오른쪽 두뇌로 그림 그리기> 책으로 남겼습니다.

베티 에드워즈는 그림 그리기에 '우뇌'를 사용할 것을 이야기했기 때문에, 좌뇌와 우뇌의 차이점을 인식하고 이를 자기 분야에 접목시키려는 사람들에게 주목받는 책이 되었는데요. 그들 중에 '앤디 헌트'도 있었습니다. 앤디 헌트는 소프트웨어 개발자였고, '실용주의 소프트웨어 개발' 사상가였습니다. 2001년 애자일 선언에도 참여했죠.

2008년, 앤디 헌트는 <실용주의 사고와 학습>이란 책을 쓰는데요. <오른쪽 두뇌로 그림 그리기>에서 말하는 좌뇌, 우뇌 사용법을 프로그래밍 분야에 연결합니다.

그리고, 2021년, <프로그래머의 뇌>라는 책을 쓴 펠리너 헤르만스는 본인이 <실용주의 사고와 학습>의 영향을 받았다고 설명했습니다.

지식 노동은 '뇌'로 하는 것이므로, 지식 노동자라면 스스로의 뇌를 어떻게 사용하는 게 효율적인지 이해해야 합니다. 베티 에드워즈가 '말하면서 동시에 그림을 그릴 수 없다'는 걸 깨달았던 것처럼 우리도 우리 스스로의 지식 노동 방법에 대해 고민하고 개선할 방법을 찾아야 합니다.

코딩하는 뇌,

앤디 헌트는 "짝 프로그래밍"이라는 코딩 방식(실천법)을 쓸 때 "한 사람은 L모드로, 한 사람은 R모드로 일하라"라고 했습니다. 아시다시피, "짝 프로그래밍"은 두 사람의 개발자가 함께 코딩하는 작업 방식입니다. 이때 한 사람은 "드라이버"라는 역할로 키보드를 다루며 코드를 작성하고, 다른 사람은 "내비게이터" 역할로 코드의 전반적인 구조와 방향을 찾아줍니다.

'L모드'와 'R모드'는 <오른쪽 두뇌로 그림 그리기>에 나오는 용어인데요. 두뇌에 대한 연구가 지속되면서 학자들은 좌뇌와 우뇌의 차이라기보다 두뇌가 두 개의 작동 방식을 가지고 있다는 쪽으로 이론을 수정해 왔거든요. 그래서 베티 에드워즈도 좌뇌, 우뇌 대신 L모드와 R모드로 용어를 변경한 것이죠.

로버트 C 마틴은 짝프로그래밍이 혼자 코딩할 때보다 좋은 결과를 낸다는 걸, <소프트웨어 장인 정신 이야기>에서 설명하고 있습니다. 작성한 코드의 분량은 15%쯤 줄었지만, 그만큼 간결하고 버그가 줄어든 코드를 작성했다고 합니다. 유지보수하기 좋은 코드가 되었다는 말이고, 이는 짝 프로그래밍 하는 충분한 이유가 됩니다.

짝 프로그래밍이 긍정적으로 동작하는 원인은 우리 뇌의 작동 방식 차이에 있는 것 같습니다. 혼자서 코딩을 할 때는 주로 L모드로 사고하지만, 짝 프로그래밍을 할 때는 한 사람이 R모드로 사고하고 있기 때문에 코드를 작성하는 논리가 엉뚱한 방향으로 가는 걸 막아주고 전체 그림에서 필요한 알고리즘을 선택할 수 있거든요.

마치 두 사람이 자동차를 타고 험한 산길을 가고 있는 상황과 같습니다. 운전을 하는 사람은 지도를 볼 수 없습니다. 그럼 옆에 앉은 사람이 지도를 보며 길을 알려줘야 어두운 낭떠러지로 떨어지는 일이 없을 것입니다.

물론, 코딩은 절체절명의 시간 속에서 하는 건 아닙니다.

그래서, L모드로 코드를 작성하다가 R모드로 코드 전반을 확인하는 과정을 거칠 수 있다면 짝프로그래밍을 하지 않아도 혼자서도 좋은 코드를 작성할 수 있을 겁니다.

그러나, 경험적으로 그게 생각보다 어렵다는 걸 알고 있습니다. 어느 순간 푹 빠져서 작성하다 보면, 산꼭대기 벼랑 끝에 가있거든요.

착각의 선점,

<생각에 관한 생각>이라는 책에서 대니얼 카너먼은 '시스템 2는 자신을 영웅이라 믿는 조연에 해당할 것이다.'라고 말했습니다. 여기서 시스템 2는 L모드를 의미합니다. 그리고 시스템 1은 R모드를 의미하죠.

무대 중앙에 서서 자기 이야기를 하는 어릿광대를 떠올려보시기 바랍니다. 무대를 비워줘야 주인공인 무희가 나와서 춤을 출 텐데, 무대를 비워줄 생각이 없습니다. 자기가 무희보다 더 아름답게 무대를 꾸미고 있다고 생각하기 때문입니다.

코드를 작성하는 L모드는 자기 논리에 심취해서 그 논리가 정확히 맞아떨어지고 있다는 착각에 빠지게 됩니다. 그래서 정신 차리고 보면 벼랑 끝에 서게 되는 것입니다.

때문에,

뿔테 안경 쓴 어릿광대를 무대에서 끌어내릴 방법을 찾아야 합니다.

1800년대 말에 활동했던 프랑스 수학자 푸앵카레는 이런 활동에 적극적이었던 것으로 보입니다. <생각의 탄생>의 저자들은 푸앵카레가 생각하는 방법을 논리와 직관으로 나누고 직관적인 사고를 사용하기 위해 노력했던 것을 알려줍니다. <직관의 두 얼굴>의 저자들은 푸앵카레가 "증명은 논리에 의해, 발견은 직관에 의해 이루어진다"라고 말했다고 하는데요.

이는 짝 프로그래밍에서 드라이버는 L모드로 내비게이터는 R모드로 사고해야 한다는 앤디 헌트의 말과 상통합니다. 왜냐면 L모드의 특징이 '논리'이고 R모드의 특징이 '직관'이기 때문입니다. 다시 말해 L모드는 논리적 사고를 R모드는 직관적 사고를 하는 작동방식입니다.

푸앵카레는 직관적 사고를 하는 동안 본인이 문제를 해결하는 능력이 생긴다는 것을 알았습니다. 또한 직관적 사고가 작동하는 환경이 '걷는 동안'이라는 걸 깨달았던 것 같습니다. 때문에 풀리지 않는 문제를 해결하기 위해서 자주 산책에 나갔다고 합니다.

창조적인 사고를 위해 걷는 사람들은 의외로 많았습니다. <걷기, 두 발로 사유하는 철학>이라는 책을 보면 철학자들이 걸으면서 본인의 사상을 발전시켰던 걸 설명하고 있거든요. 특히 니체 같은 경우에는 "산책을 통해 얻은 생각만이 가치가 있다"라는 말을 남기기도 했는데요. (이 말은 <딥워크>라는 책에 나옵니다.) 니체는 정신병원에 입원할 정도로 심한 두통을 앓고 있었는데 산책을 하는 동안엔 두통에서 자유로울 수 있었기에 니체 사상의 대부분이 걷는 동안 탄생했다고 합니다.

에디슨을 비롯한 많은 사람들은 '잠'을 사용하기도 했습니다. 에디슨은 아이디어가 떠오르지 않으면 볼베어링을 들고 잠을 청했다고 하는데요. 잠이 드는 순간 볼베이링을 손에서 놓치기 때문에 바로 깨어나서 새로운 아이디어로 작업을 진행할 수 있었다고 합니다. 전구에 들어갈 필라멘트 재료를 수백 가지 실험했다는 에디슨, 그 노력도 가상하지만 수백 가지를 찾아낸 창의성이 정말 놀라운 것 아닌가 싶은데요. 결국 그건 '잠'에서 온 것입니다.

아인슈타인도 '일반 상대성 이론'을 자다가 깨달았습니다. 바그너는 산책 중에 쓰러져 잠들었다가 악상을 떠올렸다고 하고요. (<마스터리의 법칙>)

이 역시 잠에 들며 논리적 사고가 셧다운 되는 순간 직관적 사고가 작동한 결과가 아닐까 싶네요.

아르키메데스가 '유레카'라고 소리 질렀다는 이야기는 목욕탕에 들어가는 순간 벌어진 이야기였습니다. 아인슈타인은 "왜 나는 샤워 도중에 최고의 아이디어가 떠오를까?"라는 말을 했다고 하고 <테스트 주도 개발>이라는 책에서는 코딩을 더 이어갈 아이디어가 없을 때 해결 방법이 떠오를 때까지 샤워하는 '샤워 방법론'이란 방법을 쓰는 개발자들 이야기가 나오기도 합니다.

'논리적 사고'라는 타이틀을 가진 어릿광대를 우리 머릿속 생각의 무대에서 강제로 끌어내릴 때 지적인 노동은 놀라울 만큼 효율적으로 변하는 것 같습니다. 그래서 푸앵카레는 매일 4시간만 일하면서 58세까지 살았지만, 어마어마하게 많은 분야에서 독보적인 업적을 남겼고, 에디슨은 발명왕이라는 별명을 얻었으며 아인슈타인은 인류의 역사를 바꾸었습니다.

이와 같이, 천재들이 '직관적 사고'의 도움을 얻었다면 우리 같은 평범한 사람들은 더욱더 자기 지식 노동에서 직관적 사고를 잘 사용하는 방법을 연습해야 하지 않을까 싶습니다.

행동 양식

강제로 L모드 사고를 셧다운 하고 R모드가 동작하도록 하는 방법들에 대해 이야기해보았습니다. 하지만 이런 방법들만 있는 건 아닙니다. 특히 산책, 잠자기, 샤워 같은 방법은 사무실 업무 환경에서 하기엔 좀 애매하지요.

베티 에드워즈는 행동양식을 바꾸는 방식으로 L모드로 사물을 보던 사람들이 R모드로 사물을 보고 그리도록 훈련시켰습니다. 6일 남짓 훈련받은 사람들은 놀라울 정도로 그림 실력이 늘었죠.

물론, 소프트웨어 개발 분야에서도 행동 양식을 바꿔 효율을 높이는 방법들이 있습니다.

UML (표준화된 모델 언어)

절차적인 코드만을 작성하던 70년대를 지나 80년대에 들어서면서 객체지향 프로그래밍이 주요 패러다임으로 자리 잡기 시작했습니다. 객체지향 프로그래밍 필요했던 가장 근본적인 원인은 프로그램이 GUI(그래픽 사용자 인터페이스)를 필요했기 때문입니다. 그리고 사람들은 객체지향을 그림으로 그리는 표준을 만들기 시작했는데요. 그게 UML입니다. UML은 소프트웨어 분야에서는 거의 표준과 같은 대접을 받았습니다.

하지만, 요즘은 UML의 인기가 예전 같지 못한 것 같습니다.

다양한 이유가 있겠지만, 제 생각에 UML을 많이 쓰지 않게 된 원인은 우리에게 UML이 필요했던 목적과는 다른 방향으로 쓰게 되었기 때문입니다.

앞에서 짝프로그래밍을 이야기하며 언급했지만, 소프트웨어 구조에 대한 고민은 주로 R모드로 하게 됩니다. 혼자 고민한다면 복도를 서성이면서, 산책을 하면서 하겠지만, 여러 사람이 함께 고민한다면 의사소통 방법이 필요합니다. 이때, 머릿속에 상상한 모듈 구조를 '말'로 설명하면 그 상상했던 구조가 뿌옇게 사라져 가는 걸 경험하게 됩니다.

언어를 사용하려면 L모드로 전환해야 하기 때문에 우리는 R모드로 고민했던 결과를 언어로 표현하기 힘듭니다. R모드는 비언어적인 작동방식이기 때문에 R모드에서 상상한 구조는 비언어적인 방식으로 의사소통해야 합니다. 그래서 R모드가 작동하는 동안은 그림을 그려서 소통하는 걸 선호하게 됩니다. 그래서 UML 같은 표준이 필요했던 것입니다. 서로 아는 기호가 있다면 그 기호로 더 원활한 의사소통이 가능하니까요.

UML로 소통하는 걸 상상해 보겠습니다. 여러 사람이 화이트보드 앞에 서있습니다. 마커로 대충대충 UML기호들을 그리면서 다음과 같은 이야기를 나누는 거죠.

"이거 이렇게 되면, 여기, 여기서 이벤트가 발생해서 이쪽으로 넘어가게 되죠",

"그럼 이 모듈은?",

"아 그건 이거 다음에 다른 이벤트가 발생하면서 시작해요 "

생각하는 구조를 말로 설명하지 않아도 되므로 R모드에서 고민했던 것들을 논의의 선상에 끌어낼 수 있습니다.

또한 UML은 R모드가 동작하는 과정에서 우리 스스로에게 도움을 줄 수도 있습니다. 너무 복잡한 구조는 혼자서 그려보면서 생각을 발전시키는 게 유리하거든요. 사무실에서 생각에 빠졌다면 이면지에 하면 되고, 식당에 와서까지 그 고민이 그치지 않았다면 냅킨에 그려보면서 R모드가 작동하는 걸 도울 수 있습니다.

그러나,

UML은 그렇게 사용되기보다는 설계 문서를 쓰는데 더 많이 사용되어 왔습니다. 문서에서 UML은 '빛 좋은 개살구'입니다. 그려 놓으면 뭔가 있어 보이는데, L모드로 그린 UML은 너무 복잡하게 변합니다. 그럼 그걸 꼼꼼하게 읽는 것만으로도 너무 힘들죠. 소통도 어려울뿐더러, 들이는 노력에 비해 효율적이지도 못합니다. 그러니 안 쓰게 되는 거죠.

포스트잇

애자일 개발 방식에서 '스크럼'이나, '익스트림 프로그래밍'은 '포스트잇'을 '정말' 선호합니다. '스크럼 보드'는 포스트잇을 사용해서 '사용자 스토리'를 표시하고 일정의 진행상황을 표시하는데요. 매일 아침 데일리 스크럼이라는 스탠드업 회의를 하면서 조금씩 수정해 갑니다.

화이트보드나 벽에 선을 그어 두고 그 위에 포스트잇을 붙여 두기 때문에, 관리자들은 따로 회의를 소집하지 않더라도 업무가 어떻게 진행되고 있는지 바로 파악할 수 있습니다. 관리자들도 R모드로 프로젝트에 대한 직관적 판단을 해야 하기 때문에, 한눈에 알아볼 수 있는 어떤 구조가 만들어지는 게 유리합니다. 회의를 30분에서 한 시간 하며 차곡차곡 이해하고 머릿속에 그림을 그린다음 R모드로 넘길 일이 0.5초 안에 해결되는 것입니다. 그럼 팀원들과 관리자 모두에게 크게 이득이 되지요. 게다가 지식 노동자들의 '시간'에 돈을 지불하는 회사 입장에서는 큰 낭비를 줄일 수 있는 방법입니다.

스크럼에서는 번다운, 번업 등 다양한 차트들을 손으로 그려서 붙여두게 합니다. 그로 인해 팀의 공간에 들어온 그 어떤 사람이라도 팀의 프로젝트 상황을 정확하게 파악할 수 있게 해 줍니다.

칸반 보드도 결국 같은 역할을 합니다. 포스트잇으로 작업자의 업무가 원활하게 이루어지고 있는지 한눈에 알아보게 해 줍니다. 스토리 맵도 역시 포스트잇을 사용하는데요. 사용자가 필요한 것과 팀이 제공할 수 있는 것 사이를 한 번에 이해할 수 있는 그림을 만들어 줍니다.

오른쪽 두뇌로 코딩하기

최근, AI 분야에 최대 화두는 AI로 코딩하기 인 것 같습니다. 하루가 다르게 놀라운 기능을 가진 AI 코딩 도구들이 생겨나고 개발자들은 이제 일을 잃게 될 거라고 설레발을 치는 사람들도 많습니다. 심지어, 거대 IT기업들이 수백, 수천 명씩 감원했다는 소식은 이런 분위기를 더욱 고조시켜가고 있습니다.

하지만, AI는 개발자를 대체할 수 없습니다.

현재 코딩을 하는 AI는 LLM(거대 언어 모델)이 기초가 되어서 구축됐습니다. 즉, L모드의 결과물들을 세세하게 나눠서 그 사이 연관성을 저장( 기계학습 ) 한 결과입니다. 그렇다면 AI가 하는 일은 L모드로 하는 일이 주를 이루게 될 겁니다. 그러나 소프트웨어 개발은 L모드로만 하는 게 아닙니다. R모드로 구조와 방향을 잡아야 합니다.

<디자인 오브 디자인>에서 "설계자들은 대부분 우뇌형이고 시공감각을 지향하는 사람들이다"라는 말을 남긴 프레드릭 브룩스는 <맨먼스 미신 20주년 판>에서 소프웨어 개발 작업은 '본질적 작업(essential task)'과 부차적 작업(accidental task)'으로 나눌 수 있다고 했습니다. 여기서 본질적 작업은 소프트웨어 구조를 만들고 복잡도를 낮추는 작업이며 부차적인 작업은 본질적 작업을 기반으로 소프트웨어를 구현하는 작업입니다. 소프트웨어 개발의 성패는 '본질적 작업'에 달려 있지만, 사람들은 눈에 띄는 부차적 작업을 더 잘하는 쪽으로 도구를 발전시켜 왔습니다.

그래서, 브룩스는 "은총알은 없다"라는 말로 이 현상을 정리합니다. 부차적 작업을 잘하는 어떤 도구가 나와도 본질적 작업을 극단적으로 잘할 수 있도록 상황을 바꾸지 않는 한 소프트웨어 개발은 복잡하고 어려운 일이 될 것입니다.

다시 한번 말씀드리지만, AI는 부차적 작업의 결과를 학습했습니다. 즉, 본질적 작업으로부터는 그만큼 멀리 떨어져 있다는 말이 됩니다. 따라서, 코딩을 돕는 AI가 발전한다면, 부차적 작업을 돕는 일을 먼저 시작하다가 인간이 부차적 작업은 신경 쓰지 않고 본질적 작업을 할 수 있는 정도까지 발전해 갈 것입니다.

때문에, 미래를 걱정하는 개발자라면, '본질적 작업'을 더 잘할 수 있도록 스스로를 업그레이드 해가야 합니다. R모드로 코딩하는 과정은 '본질적 작업'과 맞닿아 있습니다. 짝프로그래밍을 할 때 내비게이터가 하던 일이 바로 소프트웨어 개발의 본질적 작업이었습니다. 구조를 보고 갈 방향을 정하고, 더 나은 알고리즘을 선택하는 것 말입니다.

한동안 AI로 코딩하는 이야기는 세상을 떠들썩하게 할 겁니다. 역사적으로 '개발자들 대체하는 계획'은 회사들에게 너무 구미 당기는 일이었으니까요. 수십 년 전 베이식 언어를 만들던 사람들도 그걸 기대했고, C언어가 세상을 점령하는 걸 보면서, 기계어를 쓰지 않아도 되니 이제 개발자는 필요 없을 거라 했습니다. 객체지향이 세상을 들었다 놨던 그 시기에도 그림을 그려서 코딩할 수 있게 되면 개발자들은 필요 없을 거라 했고, 비주얼 베이식과 같은 4세대 언어들에 대해서도 그런 기대를 했습니다. 하지만, 기술이 발전하는 만큼 사용자들의 요구는 더 복잡해져 갔고, 개발자의 수를 줄일 수는 없었습니다. 그 와중에 다음 세대를 준비한 개발자들은 계속해서 살아남았지요.

AI의 발전은 개발도구의 발전으로 이뤄질지는 모르지만, 그만큼 더 복잡한 소프트웨어를 가능하게 할 것이고, 결국 더 복잡한 AI 소프트웨어를 개발하기 위해 더 많은 개발자들이 필요하게 될 겁니다.

다만, 이제 우리는 '오른쪽 두뇌로 코딩하는 방법'을 익혀서 미래를 준비해야 합니다.