mypark

닉네임은 mypark, 본명은 박명현이라고 합니다.

원래 전공은 전자공학과였는데 컴퓨터 하나만으로 뭔가를 만들 수 있는 컴퓨터공학이 매력있게 느껴졌어요. 그래서 대학 졸업 후 진로를 고민하다가 42서울로 오게 되었어요. 컴퓨터에 대해 더 배워보고 싶었습니다.

cjeon

닉네임은 cjeon이고 본명은 전창민이라고 합니다.

어렸을 때부터 프로그래밍에 관심이 있었고 내가 원하고 상상하던 것을 절차에 따라 명확하게 구체화한다는 점에서 매력을 느꼈습니다.

고등학교 때 본격적으로 프로그래밍을 해보려 했는데 학교에서는 어떤 활동을 하든 입시로 연결지어지는게 아쉬웠어요. 이럴거면 학교를 그만두고 해보는게 어떨까 싶어서 고등학교를 자퇴하고 JavaScript와 Python으로 바로 눈에 보이는 프로그램을 만들기 시작했어요.

비트코인 자동거래 프로그램도 만들어보고, 크몽에서 외주도 받아보면서 경험이 쌓이니까 점점 근본적인 것에 대한 호기심이 생기더라고요.

JavaScript랑 Python은 많은 것들이 추상화되어 숨겨져 있는데 사실 그 밑에 엄청나게 많은 과정들이 있는 거잖아요. 그걸 더 파보고 싶어서 로우 레벨에 대해 공부를 하다가 42서울을 알게 되었습니다.

mypark

이너서클 과제 중에서는 ft_transcendence가 가장 인상 깊었어요.

이전에 했던 팀과제들은 기간이 너무 짧거나 서로 코드를 단순히 합치기만 해서 조금 아쉬움이 있었는데, ft_transcendence는 정말 열심히 하는 다섯 분이 딱 모여서 한 달 동안 거의 매일 나오면서 집중했거든요.

jaham님, jeongble님, hyojekim님, yeju님, 저 이렇게 5명이서 팀이었어요. 다들 잘하는데 열심히까지 하시는 분들이라 서로 부족한 부분을 채워주었고, hyojekim님이 github 등 프로젝트 관리에 대해 잘 아셔서 협업에 대해서도 많이 배웠어요..

cjeon

저는 ft_containers랑 irc가 고통스럽기도 했지만 인상 깊었어요.

ft_containers에서 ‘템플릿 메타 프로그래밍’이라고 컴파일러가 프로그램 코드를 생성하는 방식이 있는데, 이전에는 시도해본 적 없던 새로운 방법이었어요.

irc는 ft_containers랑은 다른 방식으로 추상화를 활용할 수 있었던 과제인데요. virtual 키워드와 상속을 활용해서 이벤트를 처리할 수 있도록 만드는 게 도전적이었어요.

추상화라는 게 복잡해보이는 현상을 간결하고 깔끔하게 표현한다는 점에서 재밌더라고요.

mypark

프로그램이 내부적으로 어떻게 돌아가는지가 궁금했어요. 전자공학과를 전공했던 이유도 CPU가 어떻게 돌아가는지 궁금해서였거든요.

학과 공부를 하며 CPU에 대해서는 어느 정도 이해를 했는데, 그러고 나니까 OS가 궁금해지더라고요. 이너써클을 할 때부터 kfs(kernal from scratch) 과제가 있는 걸 보고 아우터 가면 해 봐야겠다 찜해두고 있었어요.

마침 cjeon님이 kfs 팀원을 구하고 있어서 같이 1년 간 kfs를 하게 되었어요.

cjeon

이전부터 더 깊이 파보면 뭐가 있을까 항상 궁금했거든요. 그런데 가장 밑에 있는 게 커널이잖아요. 자연스럽게 kfs를 하게 되었어요.

이너서클을 끝내고 kfs 과제를 하려는데 팀 과제다 보니 1년 동안 같이 하실 분을 구해야 하잖아요. 팀원을 구할 수 있을 지 걱정을 하면서 슬랙에 글을 올렸는데 마침 mypark님이 그 타이밍에 이너서클을 끝내셔서 같이 하겠다고 연락을 주셨어요. 정말 운이 좋았죠 (웃음)

mypark

먼저 신뢰할만한 자료를 모아서 읽어본 다음 대략적으로 어떻게 하면 될 지 감이 잡힐 때쯤에 코드를 작성해보는 편이에요. 그러다가 안되면 안되는 이유를 또 찾아보고. 계속 반복하면서 완성시켜 나가는거죠. kfs 공부할 때는 kernel.org에서 documentation이나 인텔 CPU 문서, OSDev라고 취미로 OS를 짜는 사람들이 만들어놓은 위키 사이트를 주로 봤어요. kernel 개발이라고 하면 양이 방대해보이지만 자세히 보면 기능별로 분리가 되어 있거든요. 의외로 잘 나누어져 있어서 차근차근 기능별로 공부하고 구현하다보면 완성시킬 수 있어요.

cjeon

코드를 직접 짜보면서 부딪히는 걸 좋아하는 스타일이에요. 예를 들어서 kfs의 첫 과제가 부팅을 해서 42라는걸 띄워보라는 거에요. 처음에는 이해가 안가더라도 일단 코드를 짜보는 편이에요. 그러다보면 막히는 부분이 보이게 되고 그 부분들을 검색해보면 이제 멀티부트, 링커스트립트 등 키워드가 생길거에요. 그럼 이제 키워드에 대해 알기 위해서 매뉴얼이나 공식 문서를 읽어보고, 그래도 막히면 리눅스 커널 소스를 뜯어보기도 해요. 리눅스 커널 소스가 매크로도 많이 쓰고 어렵긴 하지만 실제 돌아가는 코드니까 아무튼 정답이거든요. 한 가지 팁은 옛날 버전 리눅스 소스가 조금 더 간단하다는 점이에요. 요즘 커널은 최적화하느라 코드를 꼬아놓은 부분이 있는데 옛 버전은 기능만 깔끔하게 구현되어 있는 부분도 있어서 조금 더 보기 편해요. 그것도 어려우면 XV6라던지 좀 더 쉬운 예제용 OS를 볼 수도 있어요.

mypark

cjeon님이랑 항상 옆자리에 같이 앉아서 코딩을 했어요. 5시 40분쯤에 일어나서 아침 간단하게 먹고 씻고 한 6시 반에서 40분 정도 사이에 지하철 타서 도착하면 7시 반 정도 되거든요. 클러스터 도착하면 밥먹고 다시 집 갈때까지 cjeon님이랑 쭉 코딩했죠.

cjeon

커널이 분량이 크다 보니 과제에서도 해야 하는 부분이 명확하게 나눠지는 부분이 많거든요. 예를 들어 첫 번째 과제에서는 부팅을 하기 위해 헤더를 세팅해주는 부분이랑 부팅을 하고나서 42라는 글자를 찍어주는 부분으로 잘 나뉘어져 있어서 책임을 나누기가 편했어요. 대신 최대한 상대방의 부분도 확실하게 알고 다음으로 넘어갈 수 있게 PR을 올릴 때마다 리뷰를 꼭 해야 넘어갈 수 있게 했어요. 덕분에 제가 짜지 않은 부분도 대략적으로 어떻게 구현하고 작동하는 지 알 수 있었어요. 그리고 리뷰하기 쉽게 커밋은 최대한 작은 단위로 하는 게 좋아요. 과제를 하다보면 3천 줄 짜리 커밋을 서로 던질 때가 있었는데 그 때 조금 힘들더라고요.

mypark

둘 다 성격이 맞춰주는 스타일이라서 크게 싸웠던 적은 없었어요. 협업할 때에는 틀린 걸 틀렸다고 인정할 수 있어야 돼요.

예를 들어서 제가 Pull Request를 올렸는데 틀린 부분이 있을 거 아니에요? 그럼 cjeon님이 여기 왜 이렇게 짜셨냐고 피드백을 주세요. 그러면 그 때 곰곰이 생각을 해본 다음에 cjeon님 말이 맞으면 아 제가 실수했네요, 하고 받아들이면 되는거고, 제가 짠 코드가 맞으면 왜 맞는지 설명을 해요. 서로 이야기를 잘 하면서 맞추어갈 수 있어서 좋았어요.

cjeon

kfs는 둘이서 하는 과제니까 서로 이건 어떻게 구현하면 좋을지 이야기를 나눌 수 있어서 좋았어요. 만약 혼자 했더라면 끔찍했을 것 같아요.

kfs를 끝내니 어떤 문제가 생겼을 때 어딜 확인해야 할 지 조금 알 것 같아요.

예전에는 시스템 콜을 본다는 건 예전에는 상상도 못했겠지만 지금은 직접 보며 문제를 해결할 수 있게 되었어요.

mypark

저도 확실히 어떤 문제를 해결하는 능력 자체가 좋아진 것 같다는 생각이 들어요.

지금은 욕토 리눅스(Yocto Linux)라고 임베디드 리눅스를 보드 위에다가 올릴 수 있도록 하는 프로젝트를 하는 중이에요.

cjeon

네트워크, 컴파일러 쪽을 더 공부해보고 싶어요.

군대 다녀오면 도커(Docker)나 하이퍼바이저(Hypervisor)같은 가상화 기술도 공부해볼까 해요.

mypark

아직은 어떤 일을 해야겠다고 정하진 않았어요. NPU를 만드는 회사에 들어가면 커널이나 컴파일러를 다루는데, 그런 것도 재미있을 것 같아요. 스타트업에 들어가서 처음부터 만들어보는 것도 로망이 있는 것 같아요.

cjeon

아직 깊게 생각해보지는 않았는데 코어한 프로그램들을 다루고 싶어요. 컴파일러, OS, 네트워크, 데이터베이스 등 세심한 작업을 필요로 하는 고성능 소프트웨어를 만드는 일을 하고 싶어요.