너무 생산적이지 않아도 괜찮아요!

Jonathan: 안녕하세요, Exercism 팟캐스트에 오신 것을 환영해요. 제 이름은 Jonathan이고, 오늘 여러분을 모시게 되어 영광이에요. 그리고 Go와 JavaScript 트랙의 메인테이너 중 한 명인 Franziska가 함께해 주셨어요. Franziska가 Exercism의 일원으로 함께해 주시는 건 정말 영광스러운 일이고, 벌써 여러 해째 참여해 오셨어요. 혹시 Exercism을 오래 해 오셨다면 Franziska를 만나 보셨을지도 몰라요. 학습 코호트에서든, Go와 JavaScript 트랙에서든요. 그럼 Franziska, 오늘 따뜻하게 환영해요. 함께해 주셔서 정말 감사해요. 바로 여쭤볼게요. 어떻게 지금의 자리까지 오시게 됐어요?

Franziska: 네, 안녕하세요. 저는 Franziska예요. 인터넷에서는 June, 또는 June Dev라고 해요. 지금은 독일 프랑크푸르트 근처, 도시 경계를 조금 벗어난 작은 교외 지역에 살고 있어요. 그리고 최근에 Atlassian에서 새 일을 시작했어요. Atlassian은 Trello, Jira, Confluence처럼 사람들이 좋아하거나 싫어하는 여러 도구를 만든 회사예요. 거기서 제가 하는 일은 프로덕트 매니저들의 업무를 돕는 새 도구를 개발하는 거예요. Jira는 개발자에 초점이 맞춰져 있어서, 프로덕트 매니저가 해야 하는 일, 예를 들어 우선순위를 정하는 것 같은 일에는 잘 맞지 않거든요. 그래서 그들을 위해 특별히 뭔가를 만들고 있어요. 저는 Go 언어를 좋아해요. 정말 마음에 들어요. 그리고 backend는 Go로 만들어져 있어요. 그래서 채용 공고를 봤을 때, '오, 이런 걸 한다니 멋지다' 싶었어요. 지원해서 합격했고요. 아직 30일 정도밖에 안 됐지만, 좋은 경험이었어요. 어릴 때부터 저는 IT 쪽과 자연과학, SF에 관심이 많았어요. 열렬한 Star Trek 팬이었고, 그런 것들을 좋아했죠. 학교에서 수학과 물리 쪽을 잘한다는 걸 알게 됐어요. 그 당시 많은 사람이 컴퓨터 과학을 공부했고, 늘 우리에게 남들이 하는 걸 공부하지 말라고 했어요. 그러면 나중에 그런 사람이 너무 많아질 거라고요. 그래서 '그럼 컴퓨터 과학은 하지 말아야겠다, 그런 사람이 너무 많아질 테니까'라고 생각했어요. 아무튼 '비슷한 걸 해 보자' 하고 물리학을 공부하게 됐어요. 학교에서 물리를 정말 좋아했거든요. 컴퓨터 과학은 부전공 같은 개념이었어요. 그래서 몇 과목은 들었지만 다른 사람들만큼은 아니었어요. 그리고 나서 '평생 뭘 하고 살아야 하지?' 하는 지점에 오게 되는 거예요. 좋아하는 일을 하면서 어떻게 돈을 벌까, 하는 문제요. 그리고 제가 전공에서 했던 것 중에 프로그래밍이 사실 가장 마음에 들었던 부분이고, 또 잘한다는 걸 깨달았어요. 그걸 더 하고 싶었어요. 그리고 밥벌이도 되는 일이고요. 그래서 '당시에 정통 컴퓨터 과학 학위 없이 이 분야에서 어떻게 일자리를 구할 수 있을까'를 고민했어요. 또 하나는, 그때는 C 개발자나 Java 개발자처럼 옛날 방식의 은행 backend 코드를 어딘가에서 쓰는 사람이 되고 싶지 않았어요. 그래서 '현대적인 것, 인터넷, 웹을 어떻게 배울까'를 생각했어요. 그걸 위한 뭔가를 만들고 싶었거든요. 그러다 친구가 웹 개발 부트캠프라는 게 있다고 알려 줬어요. 3개월 동안 어딘가에 가면 새롭고 멋진 걸 가르쳐 준다는 거예요. 그래서 그걸 해 보기로 했어요. 그러면 거기서부터 일자리를 찾는 데 더 나은 발판이 생길 거라고요. 그런데 그 당시 독일에는 그런 게 하나도 없었어요. 대학에 몇 년씩 다니거나, 아니면 약간 일하면서 공부도 같이 할 수 있는 곳이 있긴 했지만 그것도 몇 년씩 이어지는 큰 교육 과정이었어요. 부트캠프 쪽은 스타트업 액셀러레이터 같은 것뿐이었고요. 코드도 조금 배우지만 경영이나 경제 같은 것도 배우는 곳이었죠. 그래서 저한테는 맞지 않았어요. 그래서 좀 둘러보다가 런던에 제가 배우고 싶은 과목을 가르치는 좋은 곳이 있다는 걸 발견했어요.

Jonathan: 바로 그런 곳이죠.

Franziska: 네, 바로 그곳에서 새로운 게 벌어지고 있죠. 정확해요, 정확해요. 최신의 멋진 것들이 벌어지는 곳이요. 그래서 이 부트캠프를 찾아서 다녀왔어요. 정말 정말 좋은 경험이었어요. backend는 Node.js로 했어요. 그러고 나서 프랑크푸르트로 돌아와서 Node 개발자로 일자리를 구했어요. 회사도 괜찮았고 기술도 정말 좋아서 모든 걸 아주 빠르게 익혔고, 정말 재미있었어요. 하지만 팀 운이 좀 안 좋았어요. 자존심이 강하고 마초적인 팀원들이 많았거든요. 그래서 회의를 하면 목소리가 가장 큰 사람이 논쟁에서 이기는 분위기였어요. 정말 함께 일하고 싶지 않은 팀이었죠.

Jonathan: 프로그래밍을 하겠다고 나선 사람들이, 그러니까 주변부라고 할 수 있는 팀이라는 측면에서 늘 뜻밖의 문제나 어려움을 겪는 건 꽤 흔한 패턴인 것 같아요. 꽤 흔한 일인 것 같아요. 죄송해요.

Franziska: 네, 정말 그래요. 처음에는 기술적인 부분을 과대평가하게 돼요. '이 일은 내가 하고 싶은 기술을 정확히 다루니까 괜찮을 거야'라고 생각하죠. 그런데 사실 팀이라는 부분이 내가 하는 구체적인 기술보다 거의 더 중요해요. 그래서 2년 뒤에, 친구가 프랑크푸르트에 있는 다른 회사의 CTO였는데, 자기네도 기술을 바꾸고 새로 뭔가를 만들고 싶다고 했어요. 그런데 Node.js는 하고 싶지 않고 Go로 가고 싶다고 했어요. 이런저런 이유로 그렇게 정했다고요. 그리고 저한테 함께 하라고 했어요. 물론 Go를 배워야 한다고요. 그래서 초반에 이걸 배우는 데 시간을 좀 써도 괜찮다면 하겠다고 했어요. 언어를 좀 살펴봤는데 다 좋아 보였어요. 그래서 회사를 옮겼어요. 새 직장의 팀은 정말 좋았어요. 거기서는 CEO와 논쟁을 해도 내 논리가 더 낫다면 그걸 알아봐 주고 사람들이 반응해 줬어요. 함께 일하기 정말 좋았고 사람들도 정말 흥미로웠어요. 그래서 5년 동안 그곳에 있었어요. 성장하는 서비스도 많이 만들고, 다른 개발자들이 Go에 적응하도록 돕는 문서와 개념 정리를 많이 쓰기도 했고, frontend 쪽 일도 좀 했어요. 그런데 5년이 지나면 새로운 도전이 하고 싶어지죠. 그리고 새 일자리를 찾게 만든 또 다른 이유는 코로나 상황이었어요. 어차피 재택근무를 하고 있었고, 아마 일주일에 한 번 정도만 사무실에 갔어요. 그래서 '완전 원격 근무 일자리가 많이 있으니, 더 크고 멋진 회사에서 정말 멋진 일을 할 수 있지 않을까'라고 생각했어요. 어차피 집에서 일한다면, 더 크고 멋진 회사에서 일해도 되잖아요. 그래서 그때 일하던 중에 Atlassian의 이 일자리를 찾게 됐어요.

Jonathan: 그러니까 제 질문은, 팬데믹이 '프랑크푸르트와 프랑크푸르트의 스타트업 생태계만 있는 게 아니구나' 하는 생각을 하게 만들었는지였어요. 그리고 프랑크푸르트의 스타트업 생태계는 어떤 공간인지도 여쭤보려고 했고요.

Franziska: 네, 코로나 얘기부터 하자면, 코로나가 저에게 열어 준 건 완전 원격 근무라는 개념이었어요. 예전에는 항상 사무실에 가는 걸 좋아했어요. 사람들을 직접 만나는 것도 좋았고, 하루를 그렇게 구성하는 것도요. 그런데 주로 완전 원격으로 2년을 보내고 나니 괜찮다는 걸 알게 됐어요. 잘 해낼 수 있어요. 딸이 있어서 어차피 밖에 계속 나가야 하고요. 그래서 지금은 하루에 충분한 구조가 있어요. 그건 팬데믹이 보여 준 거고, 그래서 다른 곳을 알아볼 생각을 하게 됐어요. 프랑크푸르트 쪽은 IT와 스타트업 관련 일이 많이 있긴 해요. 그런데 예상하시겠지만 은행 쪽에 초점이 많이 맞춰져 있어서 핀테크가 많아요. 그리고 그건 제가 특별히 좋아하는 주제는 아니에요. 예전에 핀테크에서 일한 적은 있지만, 열정을 가진 주제는 아니었어요. 그래서 늘 좀 그랬어요. 게다가 Go 개발자도 별로 없고요. 프랑크푸르트에, 또는 프랑크푸르트 생태계에 저를 특별히 붙잡아 둘 만한 건 없었어요.

Jonathan: 아, 네. 그럼 프랑크푸르트가 특히 집중하는 특정 언어가 있다고 보시나요? 핀테크라고 하셨으니, 그걸 뒷받침하는 언어가 있을 텐데, 그쪽에 더 초점이 맞춰져 있나요? 그러면 프랑크푸르트에서 Go 개발자로서 좀 희귀한 편이라고 느끼시나요? 아니면 늘고 있나요? 어떻게 보이세요?

Franziska: 네, 지금 늘고 있는지 아닌지는 판단하기 어려워요. 코로나 때문에 밋업 같은 게 별로 없었거든요. 그래서 지금 밋업에 사람이 더 많이 오는지 아닌지는 알기 어려워요. 아무튼 Java 쪽 같은 데서는 훨씬 활발한 것 같아요. 정확히 어떤지는 좀 판단하기 어렵지만, 예를 들어 JavaScript는 보통 커뮤니티를 모으는 게 그렇게 어렵지 않아요. 누구나 어딘가에 frontend 코드가 조금씩은 있으니까요. 그래서 보통 frontend 쪽이 backend보다 더 활발했어요.

Jonathan: 그러면, 처음 코딩을 시작하고 부트캠프에 갔을 때 frontend도 접하셨을 텐데, 지금은 backend에 더 집중하고 계시잖아요. backend가 frontend보다 좋은 이유가 뭐예요? 아니면 제가 그냥 짐작한 건가요?

Franziska: 아니요, 확실해요. 부트캠프에서 backend 쪽이 더 맞다는 걸 알게 됐어요. 거기엔 여러 이유가 있어요. 우선 저는 디자이너 타입이 아니에요. frontend를 하면 보통 직접 판단을 내려야 하죠. 이건 어떻게 보여야 할까, 여기서 뭘 할 수 있을까, CSS를 좀 써 볼까, 같은 거요. 그런 판단을 내리는 게 저한테는 정말 어려워요. 물론 실제 업무에서는 디자인이 나오긴 하죠. 그래도 저는 눈썰미가 별로 없어요. 그리고 그런 감각이 있고 잘 해내는 frontend 개발자들은 일을 더 효과적으로 해요. 그래서 '이건 나한테 맞지 않는다'고 생각한 게 하나였어요. 또 하나는, 요즘 frontend 쪽이 정말 엄청 복잡하다는 거예요. 흔히 쓰이는 프레임워크들이 대부분 정말 어려워요. 어떤 면에서는 지금의 backend가 오히려 좀 더 쉬워요. backend는 화면을 보면서 '이게 결과물이다' 하고 볼 수 없으니까 시각화하기가 더 어렵죠. 하지만 관련된 기술의 복잡도만 보면, 지금은 frontend 쪽보다 오히려 더 쉽다고 느껴요. 그래서 저는 언젠가 커리어에서 다시 frontend도 하고 싶어요. 그런데 더 나은 프레임워크가 나오기를 기다리고 있어요. 지금의 혼란이 좀 가라앉고 더 나은 게 나오면, 그때 다시 frontend 개발자가 되려고요.

Jonathan: 그 프레임워크가 나오면 Franziska가 결정할 때까지 저도 기다렸다가 합류할게요. JavaScript 위에 세워진 프레임워크들을 보면, 저는 모든 면에서 초보거든요. 지금 Go를 배우려고 하는데 재미있어요. 그런데 개념과 머릿속 모형만 봐도 완전히 새로운 세계예요. 그래서 여쭤보고 싶은데, 처음 프로그래밍을 시작해 JavaScript를 배웠을 때와 나중에 Go를 배웠을 때 그 간극을 어떻게 메우셨어요? 마치 JavaScript에서 Go로 넘어가는 게 아주 순조로웠던 것처럼 들리거든요. 실제로는 어땠어요? 전환을 위해 뭘 하셨어요?

Franziska: 네, 좋은 질문이에요. 여기서 중요한 건 JavaScript가 제 유일한 언어는 아니었다는 거예요. 대학에서 여러 언어를 깊이 파지는 않았지만 C도 배웠고, Java도 배웠고, C++도 배웠고, MATLAB 같은 것도 배웠어요. 그런 난해한 언어들도 좀 배웠고요. 그래서 저한테 Java는 이미 다섯 번째쯤 언어였고, Go는 여섯 번째였어요. 예를 들어 Go에서는 포인터니 뭐니 하는 얘기를 듣게 되는데, JavaScript만 해 왔다면 완전히 새로운 개념이었을 거예요. 이게 대체 뭔지 배워야 했겠죠. 그런데 다른 언어들을 배경으로 갖고 있었기 때문에 C와 C++에서 이미 알고 있었어요. 그래서 대학에서 예전에 배운 걸 많이 활용할 수 있었고, 그래서 정말 쉽게 익힐 수 있었어요. 그리고 Go에 도움이 된 또 하나는, 꽤 최소한의 언어라는 점이에요. 키워드도 많지 않고, 만들 수 있는 구조도 많지 않아요. 그래서 꽤 빨리 훑을 수 있어요. 저는 보통 공식 투어를 보라고 해요. 웹사이트에 가서든, 뭐든요. 그러면 2주, 3주면 다 볼 수 있어요. 그리고 탄탄하게 이해하게 되죠. JavaScript라면 불가능해요. 기본을 탄탄히 이해하는 데만 훨씬 오래 걸리고, 그다음엔 배울 게 훨씬 많아요. 그래서 제가 배운 언어가 최소한의 언어였던 것도 전환이 쉬웠던 데 도움이 많이 됐어요.

Jonathan: 네. 그럼 지금은 Atlassian에서 일하고 계시고, 기술과 제품이 겹치는 부분에 대해서도 조금 말씀해 주셨는데요. 핀테크는 별로 흥미를 못 느끼신다고 하셨잖아요. 제품 영역, 그리고 기술과 제품 사이의 접점이 정말 좋아하시는 분야인가요? 아니면 기술 분야에서 특별히 열정을 느끼시는 게 뭔가요? 아주 큰 질문인 건 알지만, 조금만 말씀해 주시겠어요?

Franziska: 네, 제가 관심 있는 분야나 주제는 여러 가지예요. 지금 일하는 곳만이 아니라요. 예를 들어 소비자 제품 쪽에 멋진 일을 하는 회사들을 좋아해요. HelloFresh 같은 곳이 멋진 일을 많이 하고, 기술과 관련된 멋진 일도 하죠. 또 교육 분야도 있어요. Exercism 같은 곳이요. 그리고 또 하나는 개발자 도구, 또는 일반적인 팀을 위한 도구 쪽이에요. 그래서 여러 영역이 있는데, 이번 일은 사람들을 돕는 데 정말 의미가 있다고 생각한 것 중 하나였어요. 특히 프로덕트 관리와 관련해서는 Jeremy와, 제 지난 회사의 CEO에게도 이 새 일에 대해 이야기했는데, 둘 다 똑같은 말을 했어요. Exercism의 창립자인 Jeremy도 그랬고요. 제 지난 회사 CEO도 '내 프로덕트 관리 능력에 답답해서 이 일을 고른 거냐'고 하더라고요. 그만큼 프로덕트 관리, 그리고 그걸 더 낫게 만드는 일은 제가 늘 열정을 가져 온 주제예요. 왜냐하면 개발자는 세상에서 가장 훌륭한 코드를 쓸 수 있어요. 하지만 잘못된 걸 만들고 있다면, 잘못된 걸 짓고 있다면, 그건 다 헛수고잖아요. 프로덕트 매니저가 무엇을 만들어야 하는지 제대로 파악하지 못하면, 시장을 잘 분석하지 못하고 우선순위도 잘 못 정하면, 여러분이 만든 걸 아무도 쓰지 않을 수도 있어요. 저도 예전 직장에서 그런 걸 겪었어요. 좋은 우선순위 결정 과정이 없어서 세상에 나오지도 못한 것들을 많이 만들었거든요. 그래서 프로덕트 관리라는 영역을 전반적으로 개선하면 전 세계 개발자들의 삶도 훨씬 나아진다고 생각해요. 그러면 올바른 걸 만들고 진짜 가치를 창출할 수 있으니까요. 쓰레기통으로 갈거나 사용자에게 영영 보이지 않을 걸 만드는 대신에요.

Jonathan: 네, 정말 흥미로워요. 왜냐하면 Franziska가 짚으신 건, 우리가 흔히 '기술을 잘하면 뒤에서 묻혀서 일하고 사람들 앞에 나서지 않는다'는 사고방식을 가져 왔다는 점인 것 같아요. 그게 바로 전형적인 고정관념이죠. 그런데 지난 몇 년간 기술과 비즈니스가 겹치는 부분이 점점 커진 것 같아요. 저는 늘 애자일이라는 개념에 대해 생각해 왔어요. 애자일 개념은 사실 비즈니스적인 사고방식, 그러니까 기술 팀에 부과된 사고방식인 것 같아요. 솔직히 말하면 그렇게 느껴져요. 도움이 되긴 하지만, 제가 애자일 환경이 제때 성과를 내는 걸 본 적은 없는 것 같아요. 아마 제가 잘못 관리되는 걸 봐서일 수도 있지만요. 그래도 개발자들이 비즈니스 쪽에 더 관여하고 싶어 하는 겹침이 커지고 있는 것 같아요. 정말 흥미롭고, 실제로 좋은 일이라고 생각해요. 그러면 전체적으로 더 나은 결정을 내리게 되니까요.

Franziska: 네, 어떤 개발자는 더 관여하고 싶어 하지만, 어떤 사람은 관여하고 싶지 않아 해요. 그래도 어쨌든 더 관여해야 하죠. 프로덕트 관리가 앉아서 모든 걸 잘게 쪼개서 벽 너머로 넘겨 주면, 개발자가 그걸 만들고, 그럼 끝, 하는 식으로는 안 돌아가요. 그게 표준 모델이던 예전에도 잘 돌아간 적이 없어요. 요즘엔 더 주목받고 있지만, 개발자와 디자이너, 개발자와 프로덕트 매니저 사이에 더 많은 대화가 오가는 게 늘 옳았어요. 그리고 지원 팀이나 유지보수를 맡은 사람 등 더 하류에 있는 사람들과도 가까이 일하고 함께 최선의 해법을 찾아낼수록 함께 만들어 낼 수 있는 가치가 커져요. 그건 항상 사실이었어요. 예를 들어 지금 작업하는 기능을 보면, 프로덕트 관리 쪽에서 이 새 기능의 첫 번째 버전에 뭐가 들어가면 좋을지 아이디어가 많아요. 그런데 그들 스스로는 판단할 수 없어요. 이걸 추가하면 하루가 더 걸리는 건지, 아니면 전체 범위가 터져서 3개월이 더 걸리는 건지요. 그들에게는 판단이 불가능하죠. 그래서 첫 번째 버전을 잘 묶는 유일한 방법은 서로 이야기하는 거예요. '이건 추가하기 쉬운 것', '이건 어려운 것' 하고요. 그러면서 좋은 범위를 찾아가요. Atlassian에서 좋은 점은 저희 프로덕트 매니저도 같은 관점을 갖고 있다는 거예요. 그는 늘 범위는 양방향이라고 말해요. '내겐 아이디어가 좀 있지만, 뭐가 가장 합리적인지 너희도 의견을 줘야 한다'고요. 그래서 함께 뭔가를 만들어 가요. 채용 과정을 거칠 때도, 다른 팀과 소통하는 이런 주제에 지금 굉장히 초점이 맞춰져 있는 걸 봤어요. 많은 사람이 '다른 팀과 어떻게 일했나요?'라고 물어요. 그리고 대화만 나눠 봐도, 자기 생각을 얼마나 잘 표현하는지 판단해요. 다른 팀이 뭘 하는지 신경 쓰고 관여하는 게 정말 중요하니까요. 그래야만 주어진 시간을 최대한 활용할 수 있어요.

Jonathan: 그런 의미에서 훨씬 통합된 접근처럼 느껴져요. 그러면 또 다른 생각이 떠오르는데, 흔히

Franziska: 아, 넘어가기 전에요. 방금 애자일이라는 자극적인 단어를 꺼내셨잖아요. 그냥 넘어갈 수 없네요. 절 자극하려고 일부러 그러신 건지는 모르겠지만요. 애자일에 관해서는, 이 모든 게 시작된 기본 아이디어, 그러니까 '사람이 프로세스보다 중요하다' 같은 오래전에 나온 기본 개념들은 여전히 충분히 의미가 있다고 생각해요. 그 주변에 온갖 마법 같은 게 붙었을 뿐이죠. 그런데 컨설턴트들이 와서 거대한 프레임워크를 잔뜩 만들어 팔았고, 스크럼 마스터니 뭐니 하는 게 생겼어요. 그리고 제 경험상, 말씀하신 대로 그런 것들이 별로 도움이 안 돼요. 예를 들어 제품과 개발자가 소통을 잘 못하면, 그 위에 구조만 얹는다고 해서 제대로 해결되지도 않고요. 그래서 저도 표준적인 스크럼이나 애자일 관행을 별로 좋아하지 않고, 그게 어디서든 잘 돌아가는 걸 본 적이 없어요.

Jonathan: 흥미로운 게, LinkedIn에서 프로덕트 오너나 프로덕트 매니저 일자리를 찾아보면 온통 스크럼, 애자일이에요. 어디를 봐도 그렇죠. 그런데 제가 본 가장 알찬 개발 팀은 칸반을 쓰던 팀이었어요. 특정 기한 안에 반드시 뭔가를 내야 한다는 압박은 없지만 품질은 나오고, 책임을 개인에게 되돌려서 스스로 책임을 지게 하는 방식이었죠. 겪어 보니 정말 흥미로웠어요. 젊은 팀들이 애자일에 매달렸다가 '안 통한다'며 좌절하고, 결국 칸반에 도착해서 꾸준히 조금씩 해 나가면 일이 굴러가거든요. 그런데 비즈니스로서 제품을 만드는 것과 다른 사람을 위해 제품을 만드는 것도 흥미로운 차이인 것 같아요. 예전 일이 사내 제품이었는지는 모르겠지만, Atlassian에서는 사실 자사 제품을 만드시잖아요.

Franziska: 네, 저는 항상 자사 제품을 만들었어요. 에이전시에서 일한 적은 없어요.

Jonathan: 네. 에이전시 일은 악몽이죠. 개발 시간을 한 시간 단위로 따지고, '이 버튼 하나에 왜 400달러가 드나요?' 하는 식이니까요. 그런데 그건 여러분이 그 버튼을 여기서 저기로 옮겨 달라고 한 거고, 그건 backend 전체를 다시 짜는 일이었던 거죠. 그래서 여쭤보고 싶은 게 있어요. 여러 팟캐스트와 라이브 스트림에서 많은 분께 물어본 질문인데요, 바로 목숨을 걸 만한 주제, 다시 말해 기술에 관한 의견 중에서 평생 지키고 싶은 것 말이에요. 꼭 이 의견을 가져야 한다는 건 아니고, 여러분에게 정말 중요하고 기술 분야 전체에 퍼졌으면 하는 가치나 의견이 뭔지 궁금해요. 꽤 넓은 질문이지만, 기술에서 정말 강하게 지키고 싶은 게 하나 있나요?

Franziska: 좀 더 가벼운 걸로 하실 줄 알았어요. 저는 그냥 가볍고 인기 없는 의견으로 가고 싶은데, 그것도 괜찮을까요?

Jonathan: 네, 물론이죠.

Franziska: 네. 저는 목숨을 걸 만큼 큰 주제는 별로 없어요. 그래도 하나 강하게 느끼는 건, 많은 사람이 개인 개발 환경을 최적화하라고 권한다는 거예요. 그런데 그건 대체로 과대평가됐다고 생각해요. 사람들은 'Vim을 배워야 한다, 그러면 다시는 마우스에 손을 뻗지 않게 된다'고 하죠. 정말 대단하다고요. 그래서 업계에 갓 들어온 사람들이 그걸 믿어요. 그리고 1년을 온갖 마법 같은 단축키를 익히는 데 써요. 그런데 결국 1년에 하루쯤 아끼는 정도예요. 그러니 그 1년의 고생이 보람이 없었던 거죠. 이런 게 정말 많아요. 터미널에서 쓸 alias를 전부 닷파일에 설정해 두라고 하고, 온갖 단축키를 알아야 한다고 하죠. 그런 걸 배우는 데 시간을 엄청 쏟지만, 아끼는 건 얼마 안 돼요. 여기서 벌어지는 일은, 사람들이 자기 일에서 타이핑에 쓰는 시간을 과대평가한다는 거예요. 앞서 말했듯이 일의 많은 부분은 소통이고, 실제로는 생각하는 일이에요. 하루 중 실제로 뭔가를 타이핑하는, 코드나 명령어를 입력하는 시간은 일부일 뿐이에요. 그런데 많은 사람이 하루의 아주 작은 부분을 최적화하는 데 매달려요. 제 생각엔, 그게 취미라면 하세요. 아니면 거기서 비슷한 가치를 얻는다면요. SRE, 그러니까 사이트 신뢰성 엔지니어처럼 서버에 접속해서 작업하는 사람이라면 Vim을 아는 게 의미가 있을 수 있어요. 그래픽 인터페이스를 열 수 없으니까요. 하지만 필요 없다면 걱정하지 마세요. 편한 걸 쓰면 돼요. 예를 들어 단축키 같은 건, 대부분의 그래픽 인터페이스가 클릭할 항목 옆에 단축키를 보여 줘요. 그래서 하루에 다섯 번쯤 클릭하는 거라면, 아니 5분마다 클릭한다면 기억할 만하겠죠. 계속 누르는 단축키라면요. 하지만 아니라면 그래픽 인터페이스에서 편하게 하던 일을 하세요. 그리고 그 시간을 실제 프로그래밍 실력을 키우는 데 쓰세요. 연습 문제를 풀거나, 새로운 언어를 배우거나, 뭐든요. 저는 새 개발자들에게 늘 이런 말을 하려고 해요. 옛날식 편집기를 써야 한다거나 생산성을 최적화해야 한다고 말하는 사람들에게 겁먹지 말라고요.

Jonathan: 웃긴 게, 사람들의 열정이 자연스럽게 섞여 들어가는 경우가 많아요. 이해는 가요. '내 인생을 최적화했으니 정말 신난다' 하는 거죠. 그런데 곰곰이 생각해 보면 항상 최선은 아니에요. 제가 배울 때 겪은 것도 그랬어요. 사람들이 주는 추천이 너무 많거든요. YouTube에서 '코딩 배우는 법'을 검색하면, 어떤 사람은 GitHub 설정하는 법부터 시작하고, 어떤 사람은 터미널 이해하는 법부터 시작해요. 로컬에서 작업하려면 뭘 받아야 하는지, 온라인 에디터는 어쩌고 하는 식이고요. Franziska의 조언이 정말 좋은 것 같아요. 그냥 꽤 단순하게 유지하는 거요. 그럼 생각하는 데 시간을 더 쓰려면, 문제를 어떻게 곱씹으세요? 직장이든 일반적으로든, 하루에 어떻게 하세요? 시간을 따로 떼어 두나요? 과정이 어떤가요?

Franziska: 제가 좋아하는 방식 하나는, 실제로 풀어야 할 때보다 미리 그 문제를 좀 받아 두고, 일주일쯤 머릿속 한켠에 담아 두는 거예요. 그러면 샤워할 때도 조금씩 생각하게 되고, 잠들기 전에도 조금씩 생각하게 되고, 머릿속에서 이리저리 굴려 보게 돼요. 그러면 보통 몇 가지 출발점이 잡혀요. 거기서부터, 특히 업무라면, 몇 가지를 적어 내려가기 시작해요. 뭔가를 적는 건 정말 도움이 되거든요. 머릿속을 정리하고, 예를 들어 '고객에게 정확히 뭐가 필요한지 몰라서 아직 프로덕트 매니저와 이야기해야 하는 지점'을 찾아내게 해 줘요. 이미 아는 것과 그것을 어떻게 풀지, 그리고 보통은 제법 큰 미해결 질문 목록을 적어요. 팀의 다른 사람에게 물어볼 것, 스스로 알아내야 할 것 같은 거요. 그러면 정말 정리가 잘 돼요. 그다음 아주 높은 수준의 개념에서 구체적인 프로그래밍 작업으로 쪼개요. API는 어떻게 생겼을까, 이걸 위해 어떤 데이터를 저장해야 할까, 스토리에서 데이터로, 다시 데이터에서 어떻게 돌아오고, 그 과정에서 어떤 로직이 있어야 할까, 하는 식이에요. 상황에 따라 달라요. 앞선 사고 과정에서 풀어야 할 문제를 이미 많이 찾아낸 경우도 있지만, 코딩을 시작하면서 예상하지 못한 새 문제를 발견하고는 다시 물러나서 곱씹고, 그다음 실제 코드로 돌아오기도 해요. 그럴 수도 있어요. 하지만 보통은 먼저 이걸 좀 곱씹어 보고, 몇 가지 문제를 미리 풀어 두는 게 저에게 큰 도움이 돼요. 그러면 코드가 순조롭게 나오거나, 아니면 문제를 더 발견하고 되돌아가기도 하죠. 그것도 괜찮아요.

Jonathan: 네, 좋아요. 제 머릿속에는 전업 프로그래머라면 아침부터 밤까지 컴퓨터 앞에 앉아서 계속 조금씩 해 나가는 거라는 생각이 자주 있어요. 그런데 문제를 깊이 생각하는 능력, 그리고 Exercism이 강조하려는 것이기도 한데, 문제를 잘 생각하고 맥락을 전부 파악한 다음에 코딩은 그 과정을 그대로 표현한 것이라는 걸 깨닫고 있어요. Jeremy도 같은 말을 할 거예요. 그는 많은 걸 머릿속으로 생각하고 나서 코드는 꽤 짧게 쓰는 편이라고요.

Franziska: 네, 맞아요. 흔한 팁이 하나 더 있는데, 주석에 이 코드가 뭘 해야 하는지 먼저 써 보라는 거예요. '먼저 이걸 하고, 이게 결과고, 그다음 저걸 한다' 하고 적은 다음에, 그 각각에 해당하는 코드를 채워 넣는 거죠. 그것도 정말 도움이 돼요.

Jonathan: 재미있는 게, 말씀하신 걸 저도 꼭 해 봐야겠어요. 프로그래밍을 해야 할 때, 특히 Go 같은 걸 배울 때요. 제가 하려던 연습 문제 중 하나는 키보드로 입력을 받아 저장하고, 그러고 나서 '추측 횟수가 이만큼입니다' 같은 걸 반환하는 거였어요. 그런데 그 문제를 잘게 쪼개서 생각하는 과정 자체가 저는 아주 낯설었어요. 그래서 문제를 단계별로 생각하는 법을 배우는 게 정말 흥미로웠어요. 좋은 팁이네요, 꼭 써 먹을게요.

Franziska: 그건 Exercism에서도 많은 사람이 겪는 일이에요. 많은 사람이 언어와 문법을 이해하는 건 그렇게 어려워하지 않아요. 그런데 이 일반적인 문제를 어떻게 풀지 하는 전체적인 부분에서 어려움을 겪어요. 그래서 저희도 이 주제에 관한 문서를 좀 제공하려고 했어요. '프로그래머처럼 생각하는 법을 배우는 데 좋은 자료는 이것'이라고요. 앞으로 더 잘할 수 있는 방법이 있을지도 모르겠어요.

Jonathan: 네, 맞아요. 그러면 흥미로운 질문이 하나 떠올라요. 다른 분들과 이야기할 때마다 늘 흥미로웠던 건데, 프로그래밍이 '딱' 하고 이해되는 순간이 언제였는지예요. 그런 느낌을 겪은 적이 있는지 모르겠어요. 개념과 이론을 배우고 교과서를 넘겼는데, 어느 날 아침에 일어나 보니 '아, 이제 다 이해가 된다' 하는 순간이요. 저는 뭘 배울 때 자주 그런 경험을 했어요. Franziska에게는 언제였어요? 그런 순간이 있었나요, 아니면 서서히 이해하게 되셨나요?

Franziska: 네, 이걸 좀 생각해 봤는데, '딱' 하는 순간은 있었어요. 그런데 처음부터 말할게요. 처음엔 안 왔어요, 그렇게 해도 괜찮죠. 제가 십 대였을 때, 게임이 몇 개 들어 있는 장난감 노트북이 있었어요. BASIC으로 프로그래밍할 수 있는 기능도 있었고요. 그때 할아버지가 오셨는데, 예전에 천공 카드로 프로그래밍을 하시던 분이었어요. 늘 기술에 관심이 많으셨고요. '거기서 프로그래밍을 할 수 있다니 멋지구나' 하시면서, 프로그래밍이 멋진 거라는 걸 보여 주고 싶어 하셨어요. 그리고 누구나 하는 것처럼 시작하셨어요. print, Hello world라고 입력하니 Hello world가 나왔어요. 저는 '저도 Hello world 정도는 칠 수 있는데, 이게 뭐 하는 거예요?' 싶었죠. 할아버지는 '아니야, 네가 시키는 대로 하는 거란다' 하셨고요. 그리고 1 더하기 2는, 하고 입력하니 3이 나왔어요. 저는 '내 계산기도 그 정도는 하는데, 뭘 보여 주시려는 거예요?' 싶었어요. 이해를 못 했어요. 그러다 나중에 학교에서 컴퓨터 과학 같은 수업을 들었는데, 거기서 Turbo Pascal을 썼어요. 화면에 뭔가를 그리는 작은 거북이가 있는 플러그인 같은 게 있었어요. 거기서 멋진 연습 문제를 줬는데, 어떤 수식을 입력하면 정말 정교하고 복잡한 프랙탈을 그려 줬어요. 나뭇잎처럼 보이는 것들이요. 거북이에게 뭘 그릴지 알려 주는 짧은 수식만 입력하면 그런 게 나왔어요. 그게 바로 제가 '딱' 이해한 순간이었어요. 아주 단순한 지시를 주는 것만으로, 제가 혼자서는 절대 못 만들 복잡한 걸 만들어 낸다는 걸 깨달았으니까요. 저 혼자서는 그렇게 많은 것을 그려 낼 수 없으니까요. 그래서 '아, 이건 나보다 더 많은 걸 할 수 있구나' 싶었어요. 그전에는 할아버지가 해 주신 설명이나 보여 주신 걸로는 안 됐어요. 그런데 이 그래픽적인 걸 보고, 이 복잡한 걸 컴퓨터가 하게 만드는 데 필요한 지시가 얼마나 적은지를 보고 나서 이해가 됐어요.

Jonathan: 좋아요. 저도 얼마 전에 메서드에서 그런 경험이 있었어요. '메서드가 도대체 뭐지?' 싶었는데, 이게 잘 이해가 안 됐어요. 화학에서도 마찬가지였어요. 2년 동안 배웠는데, 어느 날 갑자기 주기율표가 완전히 이해됐어요. 그때 열여섯 살이었어요. '세상에, 이렇게 쉬운 거였어? 2년 동안 이걸 왜 이해 못 했지?' 싶더라고요. 그랬더니 시험은 아주 쉬웠어요. 답이 다 주기율표 안에 있고, 작은 계산만 하면 된다는 걸 알았으니까요. 머릿속에서 모든 게 맞춰졌어요. 그 '딱' 하는 순간에 대해 여러 사람과 이야기하는 것도 흥미로웠어요. Exercism의 unison 트랙에서 아실 수도 있는 Rebecca에게 물어봤어요. 그녀는 영문학을 전공했거든요. '영문학에서 프로그래밍으로 어떻게 오셨어요? 머릿속에서 개념을 잡을 때 어떤 방식을 쓰셨어요?' 하고요. 그녀는 자기가 쓰는 프로그램을 이야기, 주인공이 있는 서사로 상상했고, 함수는 등장인물 같은 거라고 했어요. '와, 정말 흥미롭다. 그런 식으로는 한 번도 생각 못 해 봤다' 싶었어요.

Franziska: 네. 그런데 그건 아까 주석 얘기로 다시 이어지죠. 먼저 이야기를 쓰고, 그다음에 코드를 쓰는 거잖아요.

Jonathan: 그 얘기를 해 주셔서 정말 좋아요. 주석으로 이야기를 쓰고 있다는 걸 깨닫는 게요. 저도 꼭 그렇게 해 봐야겠어요.

Franziska: 이 주제에 하나만 더 얹자면, 사람들이 프로그래밍을 잘하는 게 뭘로 결정되는지에 관한 연구도 있었어요. 그런데 언어 능력, 그러니까 어휘력 같은 게 거기에 큰 몫을 한다는 걸 발견했어요. 예를 들어 이름 짓기는 프로그래밍에서 항상 어렵다고 하잖아요. 다루는 대상이 뭔지 잘 설명하는 좋은 단어를 잘 떠올리는 사람은 코드가 훨씬 나아져요. 그래서 사실 수학이나 분석적인 것만의 문제가 아니에요. 단어를 다루는 능력도 큰 부분을 차지하는데, 처음에는 잘 예상하지 못하는 부분이죠.

Jonathan: 네, 결국 언어인 셈이네요. 흥미로운 생각이에요. Franziska는 독일 사람이니 독일어가 모국어잖아요. 그런데 지금 Atlassian에서는 영어로 개발하시나요? 예전에도 영어로 하셨나요? 안타깝게도 모든 게 영어로 되어 있으니까요. Franziska는 영어를 정말 잘하시지만, 영어는 학교에서 배우셨나요? 그럼 프로그래밍은 전부 독일어였나요? 아니면 그 경험을 통해 어떻게 다 배우셨어요?

Franziska: 네, 우선 운이 좋았던 건 프로그래밍에 관한 것 대부분이 영어였고, 주석도 다 영어였다는 거예요. 항상 최고 수준의 영어는 아니지만, 그래도 괜찮아요. 저는 영어를 배울 때 학교에서는 영어를 잘 못했어요. 그런데 대학에서 운 좋게 영국에서 교환 학생으로 1년을 보낼 수 있었어요. 그래서 정말 그 언어 속에서 생활하게 됐고, 그 뒤로 영어가 훨씬 좋아졌어요. 그 전에는 정말 형편없었는데요. 그렇게 1년 동안 언어를 제대로 배운 게 나중에 독일 출신이 아닌 동료들과 소통하는 데도 도움이 됐어요. 그리고 그건 확실히 하나의 요인이에요. 영어가 모국어가 아니면, 사물에 딱 맞는 이름을 두고 싸우기가 더 어려워지죠. 이름 짓기는 코드 한 줄 한 줄마다 하는 일이잖아요. 항상 뭔가에 뭔가를 대입하면서, 코드가 명확해지도록 그 이름을 최대한 잘 지어야 하니까요.

Jonathan: 네, 영어가 모국어가 아닌 사람에게는 그게 그렇게 쉽게 느껴지지 않아요. 그리고 이건 앞으로 바뀔 거라고 생각해요. 얼마 전에 인도가 현재 세계에서 가장 빠르게 성장하는 IT 분야라는 기사를 봤거든요. 영어를 계속 쓸지, 현지 언어를 쓸지는 모르겠지만, 인도에는 그게 많다고 들었어요. 그런 걸 생각해 보는 게 흥미롭네요. 거의 한 시간이 다 됐어요. 정말 즐거웠어요. Franziska에게 마지막 질문이 하나 있어요. 이건 추천을 하나 해 주시는 시간이에요. Exercism 커뮤니티에 한 가지 추천을 해 주신다면요? 먹어 볼 음식이든, 산책을 하라는 것이든, 뭐든 좋아요. 이번 주 Exercism 커뮤니티에 해 주실 추천은 뭔가요?

Franziska: 네, 아까 인기 없는 의견에서 얘기한 생산성 주제로 다시 돌아갈게요. 제 추천은, 휴식을 취하라는 거예요. 늘 보고 싶었던 Netflix 프로그램을 몰아 보든, 뭐든요. 사람들은 하루 종일 생산적으로 있으려고 너무 집중해요. 그건 뇌에 좋지 않아요. 그렇게까지 최적화하는 건 뇌에 좋지 않아요. 일을 잘하고 창의적으로 되려면, 뇌에는 휴식이 필요하고, 휴식 중에 뭔가가 일어나거든요. 그러니 소파에 앉아서 가볍게 뭔가를 보는 게 좋아요. 뇌가 뒤에서 제 할 일을 하도록 시간을 주는 좋은 방법이에요. 휴식을 취하고 시간을 내는 건 과소평가돼 있다고 생각해요. 그래서 제 추천은, 휴식을 취하고 그냥 쉬는 데 죄책감을 갖지 말라는 거예요.

Jonathan: 좋아요. 정말 마음에 들어요. 여러분, 이걸 들으면서 Franziska가 이번 주에 전하는 추천, 조언을 기억해 두세요. 그럼 Franziska, 시간 내 주셔서 정말 감사해요. Exercism에 쏟아 주신 모든 것, 그리고 생각과 커뮤니티와의 교류에도 감사해요. Franziska가 Exercism에 정말 많이 참여해서 개선하고 돕고 계신 걸 알아요. 정말 감사하게 생각해요. 그래서 감사하다는 말씀을 드리고 싶어요. 오늘 아침 시간을 내 주셔서 감사해요. 나가서 축하하거나 재미있는 걸 하실 수도 있는 공휴일인데, 이 자리에 시간을 내 주셔서 정말 감사해요. 녹음은 멈췄는데 통화에 계속 붙어 있었어요. 그냥 정말 감사하다는 말씀을 드리고 싶었어요. 남은 하루도 정말 멋지게 보내세요. 좋아요.

Franziska: 불러 주셔서 감사해요.