ft_irc VS webserv

사람들이 웬만해서는 다들 webserv를 하는 분위기길래 사실 홍대병이 있던 나는 왜 다들 irc를 안 할까 싶어서 하고자 했던 것도 있다. 결론부터 말하자면 irc든, webserv든 소켓 통신을 배운다는 것은 같았다. 난이도도 깊게 파고들면 파고들수록 irc와 webserv는 비슷비슷했다. 실제로 얼마 안 걸리겠지 싶었는데, 점점 할수록 이거 만만히 볼 과제가 아니었구나 싶었다.

다른 점이 있다면 기능적인 것 정도. irc는 채팅 서버고 webserv는 웹 서버니까 그에 대한 기능과 rfc 문서를 읽는 양이 달랐던 것 같다. irc는 기본적인 내용이랑 추가로 서브젝트에서 구현하라는 기능 + 기타 (PING 이라든가…)만 읽어도 충분했다.

튜토리얼

irc를 하신 분들로부터 얘기를 들어보니 에코 서버를 만들어보면 감 잡는 데 도움이 된다고 해서, c++98로 작성된 에코 서버 예제를 따라 해보며 감을 잡았다.

추가로 집현전에서 윤성우의 열혈 TCP/IP 소켓 프로그래밍(2010)(개정판 2판) 로 기본적인 서버의 동작을 익힐 수 있었다. 사실 이 책 보면 ft_irc의 서버 동작은 다 만들 수 있다.

팀 결성

역시나 랜덤으로 구했다. 42peer 채널을 통해 팀원 구함을 올렸고, 초반 2주차는 둘이 진행하다가 이후 세 명이서 진행했다.

협업

먼저 들어오신 분을 A라 하고 그 뒤에 오신 분을 B라고 하겠다. A님과는 협업 방식이나 성격 등을 알 수 있는 대화를 진행했고, 덕분에 팀의 방향성을 맞춰가는 데 도움이 되었다.
그런데 B님과는 그런 대화 없이 갑작스럽게 바로 코드 작업에 들어가서 온라인에 익숙한 나와 A님과는 다르게 조금 어려워하시는 모습을 볼 수 있었다.

새로 팀원 더 구한 게 너무 기뻤는지 그때도 어떤 방식으로 같이 협업하는 게 좋은지 등을 여쭤봤어야했는데, 이 부분을 건너뛴 게 아쉬웠다.

우리 팀은 주 1회 오프라인 미팅을 갖고, 나머지는 온라인으로 진행했었다. 온라인이 주가 되려면 반드시 이뤄져야 하는 게 바로 소통(연락)이었다.
DM으로 뭔가를 물어보거나 하면 거의 바로바로 답을 해야 원활하게 온라인 작업이 이뤄질 수 있었다. 그리고 github를 통해서도 서로의 작업 상황을 볼 수 있었다.

작업 환경의 차이

나는 m1 맥을, B님은 리눅스를, C님은 인텔 맥을 사용하여 세 명이 각자 다른 환경에서 작업을 했었다. 그러다보니 내가 IDE를 켰을 때에는 warning이 나왔는데 다른 곳에서는 나오지 않는다든가, 또는 내 쪽에선 문제가 없었는데 다른 곳에서는 컴파일이 안 된다든가 하는 일이 발생했다. 이때 든 생각이 “이래서 도커를 사용하는구나.” 였다. 동시에 파이썬의 가상환경도 생각이 났다. 아마 그 다음 마지막 팀과제인 트센에서는 도커를 사용하지 않을까 싶다.

ft_irc를 하며 배운 점

소켓 통신의 원리

뭐 TCP/IP에서의 hand shaking이나 이런 건 학교에서 이론상으로만 들어봤지 실제로 구현해 본 적이 없었는데 이번에 irssi와 내 irc 서버가 통신하면서 PING PONG을 통해 연결을 확인한다는 걸 직접 구현해보니 조금 더 와닿았다.

표준의 존재 이유; RFC

“제발! 좀! 표준 좀 지켜줘!”를 뼈저리게 느낀 과제였다. IRC와 관련된 RFC 문서로는 1459, 2812가 있는데, irssi에서 몇몇 명령어는 이 표준을 잘 따르지 않는 것들이 있었다. 그래서 netcat으로는 잘 되는데, 왜 irssi는 안 되지 했던 것들이 바로 그 이유였던 것이다. 이건 tcpflow를 통해 서버와 클라이언트 간 주고 받는 메시지를 확인하면 알 수 있는 문제였다. 진짜 표준이 괜히 존재하는 게 아니다…

댓글남기기