http가 처음에는 socket을 content-length 만큼만 받은 뒤 커넥션을 끊는 형태로 구현되었다고 한다. 원시 Http 객체를 만들고 있었던 것 같다. InetAddress 외에 InetSocketAddress 객체도 있었다. 재사용하기 편해보인다. IP로 호스트를 찾는 것은 잘 되지 않았는데, 로컬 세팅을 참조하기 때문인 것 같다. 간단한 해결 방법으로 hosts를 수정해주는 것이 있었는데, DNS 서버를 좀 더 공부해봐야겠다.
URL 객체는 프로토콜만 분리해주고 포트는 따로 명시해줘야 한다. 어제 자동으로 매핑해준다 들어서 확인해보니, 포트를 지정해주지는 않았다. http, https, file, and jar 를 기본으로 지원하고, 이외는 따로 핸들러를 만들어야 한다고 한다. 그냥 파싱 용으로 사용하는 것도 괜찮을 것 같다. 단, 프로토콜이 반드시 존재해야 한다.
ip를 byte로 바꿀때 표현이 이상한 것 같아 byte를 찾아봤다. 바이트는 8비트로 이루어져있기때문에 0-255까지 표현이 돼야하는데, signed로 동작하는 것 같았다. 따라서 128 이상은 음수로 표현한다. 2의 보수처럼 표현하지는 않고, -128부터 이어져 255는 -1이 된다. 범위를 넘어가면 쉬프트되어 출력된다. 예를 들어 256은 10000000이므로 0으로 출력된다. 따라서 int나 long으로 바꿔주기 위해서는 ((int) x) & 0xff 와 같은 연산을 해야한다. Byte 의 파싱 메소드에 저렇게 구현되어있다.
내일 너목들 회의를 위해 토스를 살짝 분석했다. 고객 가치를 의사결정 제 1 원칙으로 둔다고 하는데, 고객의 경험을 최대로 하고, 고객의 이익을 극대화 하는 식으로 비즈니스를 수행한다는 것이다. 이를 Customer(client) Centric이라고 한다. 토스가 성공하기 이전에도 많은 서비스를 시도했었는데, 실패요인을 회사의 입장에서 회사가 원하는 아이템을 선정하여 개발했던 것으로 분석했다고 한다. 이후 고객과 직접 대면하며 아이템 설계를 했다고 하는데, 100개 중 성공한 하나가 간편송금이었다고 한다. 이런 이유로 금융이 불편한 순간 페이지를 만들었다고 한다. 예전에 불편한 금융을 바꾼다는 슬로건을 본 기억이 나는데 그 것과 겹쳐 보이는 것 같았다. 프로세스는 크게 어려워보이는게 없다고 느껴졌는데, 프런트 입장에서는 어떻게 생각했을지 궁금하다.