C언어로 API 서버 개발, 생각보다 나쁘지 않아요

지난 이음 API 개선에 관한 포스팅 <아파치 모듈로 개발된 API 서버, 이음 베이론을 소개합니다> 를 기억하시나요? 이 포스팅이 올라온 후 이음 개발팀 블로그에는 독자 여러분들의 뜨거운 관심(?)이 빗발쳤습니다. (그리고 아직까지 이 정도의 뜨거운 관심을 받은 포스트는 아직 나오지 않고 있습니다…) C언어로 API를 개발한다는 이야기에 흥미롭다는 반응도 있었지만 아무래도 걱정어린 시선이 많았습니다.

사실 말하자면 저도 루비, 파이썬을 비롯한 고급 언어들의 팬입니다. 그동안은 PHP나 Java (Spring) 같은 옛날 언어로 개발을 해왔지만, 처음 루비 온 레일즈를 접하고 그 깔끔함에 반해서 아직도 뭔가를 개발할 일이 있으면 최대한 레일즈를 쓰고 있구요. 과거 Spring을 쓰면서 직접 설정해줘야 했던 수많은 잡일들을 떠올리면서 ‘그동안 나는 뭘 한걸까…’ 하는 기분을 느꼈습니다. 그렇게 레일즈와 즐거운 시간을 보내던 중, 담당 프로젝트가 변경되면서 저는 C언어로 API 서버를 개발해야 하는 운명에 처하게 되었습니다.

으아니

이게 무슨 소리요! 내가… 내가 C 개발이라니!

처음에는 너무 막막했습니다. 레일즈를 써보신 분은 알겠지만, 기타 잡다한 부분은 프레임웍이 다 해주기 때문에 로직만을 작성하는 데에 익숙해져 있었거든요. 그런 저에게는 모든 것을 직접 해야만 하는 C언어 개발은 조금 불편하긴 했지만 결론적으로, 써보니까 생각보다 나쁘지 않았습니다. 다른 분들이 생각하시는 것처럼 유지보수 헬게이트도 아니구요. 무엇보다 성능이 모든 것을 용서합니다. 아무튼 자세한 이야기는 차차 해보기로 할게요.

Apache Portable Runtime

C 언어를 서버로 개발한다! 라고 하면 사람들은 포트 여는 것부터 response writing까지 모두 로우 레벨에서 처리해야 할 거라고 생각하지만, 다행히 그 정도까지는 아니었습니다. 이음의 API 서버 개발은 APR (Apache Portable Runtime) 이라는 큰 프레임웍 위에서 돌아가고 있습니다. 엄밀히 말하자면 프레임웍이라기보다는, 웹 서버인 아파치와 이음의 비지니스 로직을 연결해주는 라이브러리라고 할 수 있겠네요. 여튼 APR 덕분에, C 프로그래밍은 생각만큼 괴롭지 않습니다. APR의 홈페이지 메인을 보면 아래와 같이 이야기하고 있습니다.

“The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations” – APR 프로젝트의 목적은 플랫폼 의존적인 구현에 대한 예측 가능하고 일관적인 인터페이스를 제공하는 소프트웨어 라이브러리를 만드는 것이다.

즉, 사용하는 하드웨어와 OS에 상관 없이 상위 레벨의 구현에만 신경쓸 수 있도록 만든 라이브러리가 바로 APR이라는 의미입니다. (자바의 “Write once, run everywhere” 의 향기를 느낀 건 저 뿐일까요?) 그래서 APR을 사용하면 네트워크 관련 low level operation (HTTP 헤더를 파싱한다던지, 파라미터를 읽어서 저장한다든지) 에 대해서는 신경쓰지 않아도 됩니다. 프로그래밍에 필요한 기초 자료 구조 (list, hash table) 도 라이브러리에 포함되어 있습니다.

무엇보다 매력적인 것은 APR의 메모리 풀 관련 기능입니다. 이 메모리 풀 라이브러리는 C 언어 개발에서 아주 골치아픈 메모리 할당 / 해제 문제를 해결해줍니다. 구체적으로 이야기하자면, APR을 사용하여 메모리를 할당 (apr_pcalloc 함수를 사용) 받으면, 클라이언트에 response를 보내줄 때 자동으로 풀에 할당된 메모리들을 해제해준다는 것입니다. 멋지지 않나요? 아무튼, APR의 은총 덕분에 상당히 많은 부분들을 라이브러리에 의존하면서 개발할 수 있습니다.

정적 타입의 강점

런타임에 변수의 타입을 결정하는 동적 타이핑 기반의 언어인 루비나 파이썬과는 달리, C는 컴파일 타임에 타입을 체크합니다. 타입이 맞지 않으면 오류를 내면서 컴파일조차 잘 되지 않습니다. 이 부분이 스크립트 언어를 주로 사용하던 프로그래머들에게는 불편할 수 있습니다. 하지만 저는 타입 안전성을 컴파일 타임에 확인할 수 있다는 점은, 프로그램의 안정성에 매우 큰 부분을 차지한다고 생각합니다. (물론 C 언어가 타입 안전성을 완벽히 보장하는 언어인지 묻는다면 물론 아닙니다. 하지만 컴파일 타임에 타입 체크가 불가능한 언어에 비해서는 분명한 강점을 가지고 있다고 생각합니다.) 타입 안전한 언어에서는 컴파일 타임에서 에러가 나지 않으면 로직에 문제가 있지 않은 이상은 잘 작동하죠. 버그는 있을 수 있지만 프로그램이 죽는 일은 없습니다. 또한 성능도 뛰어납니다.

compiling

그만큼 컴파일에 시간이 걸리긴 하죠. (물론 짤방정도는 아님)

Performance, Performance, Performance

APR을 사용하여 개발한 API 서버의 성능은 그야말로 압도적입니다. 기계어로 컴파일 되니까요.

Screenshot at Jan 21 16-36-24

더 이상의 자세한 설명은 생략한다

 

물론, 당연하지만, C 개발이 장점만 있지는 않습니다.

 

 

Reinventing the wheel

회사의 모 님이 저에게 물었습니다. “C 언어로 API 개발하는 거 어떤가요?” 저는 대답했더랬죠. “바퀴를 재발명하고 있는 것 같아요.” 그렇습니다. C 언어에는 그 흔한 ORM조차 없습니다. C 언어 자체가 객체지향적인 특성이 거의 없는 절차 지향적 언어이기 때문에, ORM을 만들어서 쓴다 해도 영 불편하죠. 덕분에 쿼리를 쓰고, 전송하고, 결과를 확인하고, 데이터 구조에 저장하는 등의 일들을 직접 한땀한땀 해야 합니다. 물론 공통되는 부분은 함수로 만들어서 재사용할 수 있지만, 누군가가 만들어 놓은 라이브러리를 가져다 쓰는 것에 비하면 개발 속도가 느려질 수밖에 없습니다. (그만큼 좀 더 시스템 하층 구조에 대해 깊게 알 수 있다는 장점은 있습니다.) 하다 보면 “꼭 이런 걸 일일이 해줘야 하나..”  란 생각이 들 때도 있습니다. 그리고 이건 개개인의 취향이겠지만, 저는 누군가가 만들어 놓은 소스 코드를 제가 다시 만드는 일이 그렇게 재미있지만은 않더라구요.

car and wheel

좀 이런 느낌…

라이브러리 뿐만 아니라 배포나 디버깅, 에러 리포팅, DB조회 등등 전반적인 개발 환경 역시 덜 자동화되어 있기 때문에 만약 자동화시키고 싶다면 직접 제작하는 수밖에 없습니다. 일례로, 레일즈 어플리케이션을 개발할 때는 모델 클래스를 잘 만들어 두면 데이터베이스 조회를 레일즈 콘솔을 통해 거의 다 할 수 있었으나, C 기반 개발을 할 때는 특정 데이터를 조회하거나 업데이트할 때에는 SQL을 직접 작성하는 수밖에 없습니다. 만약 조인을 해야하는 상황이라면 그 번거로움은 배가 되고 쿼리문이 길어질 수록 중간에 실수를 해서 개발 속도가 느려질 가능성은 커집니다. SQL에 익숙하지 않은 개발자라면 더 심하겠죠. 익숙하지 않은 DBMS를 사용한다면 더더욱 그럴테구요.

생산성

“C 언어는 생산성이 안좋다.” 라는 생각을 많이들 가지고 계신 것 같더군요. 제가 생각하기에, 생산성이라는 것은 몇 가지 측면으로 분류할 수 있을 것 같습니다. (물론 이거 말고도 더 있겠죠?)

  1. 같은 길이의 코드로 얼마나 더 많은 일을 할 수 있는 지
  2. 주어진 스펙을 얼마나 빠르게 개발할 수 있는 지
  3. 유지보수가 얼마나 용이한 지

1에서 당연히 C 언어는 루비에 비해 크게 뒤쳐질 수밖에 없습니다. 언어 자체의 특성도 그렇고, 외부 라이브러리의 사용도 쉽지 않으니까요. 하지만 제가 둘 다 경험해보니, 2의 측면에서 C 언어가 결코 루비에 비해 많이 뒤쳐지지는 않는 것 같습니다. 제가 조금 더 C 언어에 숙련된 프로그래머라면 그 격차는 더 줄어들겠죠? 그 이유는 다음과 같습니다.

  1. C에서는 쓸만한 외부 라이브러리가 많지 않습니다. 하지만 외부 라이브러리를 덜 가져다 쓴다는 말은 그만큼 관련 문서들을 찾아보는 데에 시간이 덜 걸린다는 이야기도 됩니다. 따라서 IDE와 웹브라우저 사이에서의 컨텍스트 스위칭에 시간을 덜 쓸 수 있습니다.
  2. 컴파일 언어라는 특성에서 비롯되는 IDE의 도움이 강력합니다. (자동 완성, 타입 체크, 오류 점검 등)
  3. 컴파일이 되기 때문에, 개발에는 시간이 더 걸릴 수 있지만 테스트와 디버깅에는 시간이 덜 걸립니다.

3의 경우에는 현재 상태에서는 말하기 힘든 부분이 있습니다. 왜냐하면 지금까지 C 언어를 통해 개발된 프로젝트들은 (1) 안정화되어서 커다란 스펙 변경이 없는 경우, (2) 신규 프로젝트라서 스펙이 미리 정해져 있는 경우, 둘 중 하나였기 때문입니다. 추후 애자일한 과정을 통해 잦은 스펙 변경이 있어야 할 때에 C 언어가 얼마나 유지보수가 용이한 지는, 조금 더 지켜보고 말씀드려야 할 것 같습니다. 다만 개인적으로는 코드 양이 더 많기 때문에 유지보수가 더 어렵지 않을까 하는 막연한 추측을 하고 있습니다. 아마 프로젝트 규모가 커질 수록 더하겠죠?

 

결론

 APR을 사용하면 C 언어로 모바일 API를 작성하는 일도 그렇게 어려운 일은 아닙니다. 약간 불편하기는 하지만 프로덕션 레벨에서 쓸 수 없을 정도는 아니고, 그만큼 우월한 성능을 얻을 수 있기 때문에 만약 스펙이 자주 바뀌지 않고 C 언어와 APR 기반 개발에 익숙하다면 시도해볼만 한 가치가 있는 것 같습니다.

지난 번 포스팅에서 많은 분들이 “CPU 사용률을 보면 사실상 CPU가 병목은 아닌 것 같다”고 지적해 주셨습니다. 웹 어플리케이션의 속도가 DB 속도에 의존적인 것은 사실입니다. 하지만 DB 병목보다는 어플리케이션 레벨에서의 불필요한 오버헤드 (정확히 말하자면 Hibernate의 eager loading) 역시 큰 속도 저하의 원인이었습니다. 이를 수정하기 위한 노력을 기울였지만 결국 포기하고 주요한 속도 저하의 원인이었던 ORM을 버리고 서버를 다시 개발하기로 결정하게 된 것입니다. 물론 이게 절대적으로 최선의 선택이었다고는 하기는 힘들지만, 목표한 성과를 이뤘다는 점에서 긍정적이라고 생각합니다.

모든 프로그래밍 언어와 프레임웍은 각자 제 용도에 맞는 쓰임새가 있다고 생각합니다. (너무 모범적인 결론이지만) 이음의 API 서버는 현재로서는 큰 설계의 변화나 스펙의 변화가 없기 때문에 유지 보수가 조금 불편하더라도, 퍼포먼스를 끌어낼 수 있는 C 언어를 사용했죠. 그리고 애초 의도했던 바와 부합하는 효과를 얻었습니다. 특히나 모바일 API 쪽은 HTML 페이지를 렌더링하는 웹 서버와 비교하더라도 많은 기능이 필요하지 않습니다. 만약 웹 서버를 개발하는 일이었다면 string 관련 함수들이 불편한 C를 사용하지 않았을 것입니다. 어떤 언어(프레임웍)을 쓰는 지도 중요하지만 지금 사용하고 있는 도구가 목적에 맞는 지도 중요하지 않을까요?

하지만 무엇보다도 개발자에게 그 도구가 얼마나 손에 익은 도구인지도 중요한 것 같습니다. 아무리 좋은 도구가 있더라도 사용할 줄 모르면 무용지물인 것처럼요. 이음에서는 APR 환경에서 오랜 시간동안 개발을 해왔던 개발자 분이 계셨고 그 분이 첫 삽을 뜬 덕분에 다른 분들이 수월하게 개발을 시작할 수 있었던 것 같습니다. 그리고 개발자들이 대부분 컴퓨터 공학 전공 베이스를 가지고 있었던 덕분에 C 언어를 생소하게 느끼지도 않았구요. 이 글을 읽고 APR 도입을 고려하고 계시다면, 이 점을 다시 고려해보세요 🙂

 About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead ; 프로그래밍 언어의 사용에 관하여: 무딘 도끼를 가지고 연필을 깎는 일은 불가능하다. 무딘 도끼 10개를 가지고 시도한다고 해도 결과는 마찬가지다.  – E. W. Dijkstra

 

TabsSpacesBoth

그래도 한 프로젝트에 여러 언어는 섞어 쓰지마세요. 술 섞어 먹는거랑 똑같습니다. 먹을 때만 행복

 

Screenshot at Jan 21 18-52-44

 

  • Guest

    안녕하세요! 누가 저 읽으라고 쓴 글 같다고 링크를 보내줘서 들어왔습니다.

    이런 과정이었나봅니다.

    1. 와 스프링+하이버네이트가 대세라던데?
    2. 트렌디한 개발자가 된 기분으로 열심히 개발
    3. 이거 lazy가 트랜잭션 벗어나서 자꾸 오류나는데? -> 전부다 eager로 하지 뭐!
    4. 관리불가능한 쿼리를 날려대는 서버 탄생
    5. 나 전에 C로 만든적 있어 차라리 그걸로 하자 (경로 의존성)
    6. 오 그럼 이런 내가 안만든 복잡한거 공부 안해도 되겠군! (NIH 신드롬)

    하이버네이트의 복잡도를 감당하기 어려웠다면 JdbcTemplate나 myBatis로 넘어가는게 상식적인 절차인 것 같긴 합니다만… 뭐 제가 이래라저래라 할 자격이 있는건 아니니까요ㅎ

    Java에서 C로 넘어간 것에 대한 정당화가 필요한데 정적타입이나 IDE 지원 이야기가 나오는 것은 아쉽네요. type safety나 IDE 지원은 C같은게 JVM 언어들을 따라갈 수가 없죠. 말씀하신 것과 달리 사소한 버그때문에 프로그램이 죽어버리는 것이 네이티브 프로그램의 제일 골치아픈 점이죠. 덕분에 메모리덤프와 씨름해야 하는 건 덤이구요.

    외부 라이브러리 문서를 안읽어도 되는 C가 좋다는 말은 마치 ‘포토샵 배우기 힘드니까 그림판쓰자 알고보면 쓸만해’같아요. 그림판으로도 분명 명화를 그릴 수 있긴 합니다.

    • Guest친구

      지금 이래라 저래라 하고 있구요.
      본인이 얼마나 대단한 기술자인지 모르겠지만 글쓴 수준을 보니 알만하네요. 집에 가서 발닦고 자바공부나 더 하시는게 좋을것 같긴 합니다만… 뭐 제가 이래라 저래라 할 자격이 있는건 아니니까요ㅋ

      • MR

        전 첫 댓글다신 분이 한신말에 공감하는 편이에요.

        일단, 빠르게 서비스를 진화시키며 성장해야하는 스타트업의 숙명 속에서 C로 개발하고 있는 팀이라 그 리소스가 정말 부럽습니다. 첫번째 포스팅도 흥미진진하게 읽었어요.

        하지만, 전체적으로 C로 꼭 개발해야되는 시스템상 이유나 개발팀 나름의 철학에 대해 말해준게 아니라, “Java도 좋고 Ruby도 좋아, 하지만 C도 나름 나쁘지 않아”란 느낌이 들어서 조금 아쉬운 점이 있어요. 제목도 글의 흐름도요.

        게다가, 앞서 “바퀴의 재발명”섹션에 이미 C는 생산성은 최악이다라고 말한거나 다름없는거 같은데 뒤에 다시 생산성을 말씀하시네요. 그리고 그 생산성에 대해서 납득하기 매우 어렵구요.

        라이브러리를 안 가져다쓰면 문서읽는 시간이 줄어드니 생산성에 좋다거나(허걱! 거기에 browser간의 스위칭 코스트의 세심한 배려까지), 테스트 시간이 적게 걸린다거나 (test를 execute시키는 시간인가요, testcase를 만드는 시간 포함인가요)..,

        차라리 우리는 적은 리소스로도 최강의 성능을 내는것에 쾌감을 느끼는 개발자들이 모여있는 팀이다! 라고 말하는게 멋있었을듯 하네요.

        • Daehee Han

          시스템 프로그래밍이 아니고서야 ‘C로 꼭 개발해야 하는 이유’가 어디 있을까요? 더 넓게 생각해서 ‘이 언어가 아니면 안되’는 어플리케이션이 얼마나 될까요? 마찬가지로 저희가 선택할 수 있었던 여러 옵션 중에 저희는 APR을 선택했을 뿐입니다. 다들 단점만을 보시는거 같아서 장점에 대해서도 언급해보고 싶었던 거구요.

          C의 생산성이 여타 고수준 언어에 비해 높지 않은 건 맞습니다. 다만 저는 그 차이가 생각하는 만큼 무시무시한 정도는 아니라고 말씀드리고 싶었던거구요. 제가 너무 좋은 점만을 말씀드리다 보니 그렇게 보인것 같아 안타깝네요. 컨텍스트 스위칭 문단은 음. 좀 오해의 소지가 있는 표현인 것 같습니다. 다만 에디터에서 눈을 떼지 않아도 된다는 것이 저에게는 코딩에 몰입하는데에 도움을 주더라구요 🙂

        • guest

          어느 부분에서 “우리는 고수라능”이라는 느낌을 받을 수 있는지 정말 궁금하네요… 다시 한번 읽어봤는데도 느끼지 못했는데 제가 아직 초보라서 그런걸까요..?

          • Guest

            아 이댓글 단 사람인데 댓글에 댓글을 잘못달았네요; 죄송합니다..

        • Yu-heung Jeon

          어째 비꼬는듯 한 글 이네요.. 어떤 일을 하는데 꼭 생산성만,
          어떤 언어만 쓰는건 기술 발전의 큰 페러다임에는 쫌 반대 되는거 같습니다.

          님이 말씀 하신거처럼 이것도 좋고 저것도 좋고 이것도 해보니 좋드라… 라는 글이 왜 문제이고 또 아쉬운것인지??

          세상에 꼭 정답만 있는것이 아니고 개발에서는 더 할 듯 합니다.

          이런 글들이 다른 이들에게는 선택의 폭을 넓혀 줄 수도 있는 거니깐요..

          그리고 스타트업의 특성상 비용절감의 이유로 최저의 리소스로 최강의 성능을 뽑아야 할때가 많습니다.

          기존 JAVA로 4대 쓰던걸 2대로도 충분하다면 2대 만큼의 비용이 절감 되자나요?? 이게 기성 업체는 별거 아닐지 몰라도
          스타트 업에겐 큰 비용 일 수도 있습니다.

          그냥 지나가다가.. 한쪽으로 편향 되는거 같아 끄적여 봅니다.

      • Jong Wook Kim

        원댓글 제가 적었습니다. 아까 다른 아이디로 글을 써버려서 글을 지우고 새로 쓰려고 했는데 글이 익명으로 바뀌어버리네요. 마침 발닦고 왔는데 신경써 주셔서 고맙습니다.

    • Daehee Han

      조그만 아이콘을 만드는데 굳이 포토샵까지 쓸 이유가 있나요? 저도 java정도면 good enough 하다고 생각합니다. 애초에 자바보다 C가 우월하다고 한 적조차 없구요. 성능이 중요한 부분을 새로 작성하는 것이 레거시 코드를 리팩토링 하는 것보다 비용 측면에서 저렴하다고 판단되었을 뿐입니다. API 말고도 다른 프로젝트들이 레거시에 붙어서 돌아가고 있었거든요. 막상 하다 보니 생각만큼 나쁘진 않다는 게 요지구요. (제목에 써있지 않나요?)

      • Jong Wook Kim

        (제일 위에 있는 댓글을 제가 적었는데 실수로 익명이 되었습니다.)

        이음 개발자 블로그에서 단편적인 경험담 이상의 무언가를 기대했던 제가 잘못했나 봅니다. 지금 저한테 쓴소리 하시는 분들도 대체로 이 정도로 만족하시는 것 같습니다. 저는 아니었거든요. 이음 개발자 블로그라면 이음 서비스를 발전시키기 위해 얼마나 진지한 고민을 했는지와 그를 통해 어떠한 결과에 이르기까지의 과정들을 다른 개발자들과 공유하면서 이음이라는 서비스와 기술력을 알려서 가고싶은 회사가 되는 구조를 생각했는데.

        C를 선택했다면서 제시된 이야기들이 해보니 괜찮더라는 경험담 이상의 논점이 없어서, 그걸 짚는 과정에서 이러저러해서 정당화가 되지 못한다고 논증하기 위해 자바를 예로 들어 말한 것인데, 우월하니 지구 최강이니 하면서 종교적이 된건 누가 먼저일까요. 프레임웍이 그렇게 싫어서 새로 짜기로 마음먹었으면, 더욱이 이렇게 논란이 될 게 분명한 C로 짜기로 마음먹었으면 생 JDBC로 짰을 때의 비교는 하긴 했는지, 그런 걸 개발자 블로그에서 기대하는게 정상 아닌가요?

        처음부터 그냥 전직장에서 C로 하던거 계속 하기로 했다고만 적었으면 이렇게 논란이 없었을 겁니다. 변인통제는 고려하지도 않은 그래프와 표를 근거라고 올리고 쿼리 옵티마이제이션이라든지 DB 클러스터링이라든지하는 고민의 흐름도 없이 합리적인 연역에 의해 나온 결론인 것처럼 Write in C~ 라고 하면 읽는 사람은 어리둥절할수밖에요.

        개인적으로도 스타트업에 관심이 많았는데, 어제 여러 경로로 소식을 들으면서 이음 개발자들의 의사전달체계가 얼마나 마비되었는지와 전현직 이음 개발자들이 이 사태를 어떻게 생각하는지도 잘 알게 되어 저에게도 유익한 시간이었습니다. 아마도 이음 경영진들과 이음에 투자를 했거나 고려하고 있는 투자자들에게도 유익했을 것 같습니다.

        • Daehee Han

          네. 단편적인 경험담을 늘어놓는 자리 맞구요. 읽다가 대뜸 본인이 원하는 자료가 안나오니까 대뜸 NIH 신드롬 운운하면서 악담을 퍼붓는 종욱님이 좀 잘못하시고 있는거 같네요. 첨부터 글의 토픽을 잘못 잡고 계시는데 무슨 말이 더 필요할까 싶구요.

          걱정 감사하지만 안타깝게도 이음 개발팀 커뮤니케이션은 잘 이루어지고 있습니다. 다들 새로운 언어나 프레임웍에 대해서 항상 열린 자세를 취하면서 적극적으로 도입하고 있으니 너무 걱정은 마세요.

          • guest

            이음과는 전혀 관련없이 지나가는 사람입니다만,
            김종욱님은 내용도 중요하지만 태도가 중요하다는 것은 전혀 모르시는 분 같군요. 빈정거리거나 비아냥대면 신랄하고 날카로운 혜안을 가진 것으로 착각하시는 것 같네요.
            안그래도 여기저기 널리 퍼진 이 글 덕분에 저희 회사나 제 주변에 알만한 업계 10년차 이상 개발자와 아키텍트들도 저 분 이름을 다들 아셨습니다…
            보아하니 젋고 유능하신 분 같고 자신이 있으시니 실명으로 신랄하게 말씀하시는 것도 좋습니다만… 앞으로 이 업계에서 일을 안하시겠다면 모를까 남의 회사 기술 블로그에 지나친 언사를 반복하시는 게 참 안타깝네요…

          • guest

            업계가 좁다는 거야 업계에 계신 분들이라면 잘 아실 부분이라 생각합니다만,
            개인적으로 느끼기에 이 댓글 역시 다른 지나가는 사람들에게 그렇게 좋은 의도로 읽히지는 않는 것 같습니다.

            ‘젊고’, ’10년차 이상’ 같은 표현을 비롯하여 전반적으로 느껴지는 인생 경험 부족론을 보고 있으면 지나가는 사람님이 Jong Wook Kim님을 (어리다는 이유로) 내려보는 우월감 같은 게 읽혀집니다.

            특히나 ‘~ 여러모로 좋을 게 없을 것이다’ 같은 표현은 너무하잖습니까. 어찌보면 ‘~ 유익한 시간이었습니다. ~ 투자자들에게도 유익했을 것 같습니다.’ 이상으로 과격한 표현이 아닐런지요.
            물론 해당 댓글에서 중립적이지 못한 선공격을 가한 건 Jong Wook Kim 님이며, 해당 댓글을 보고 빈정상하실 수 있단 거야 인지상정입니다. 울컥하셨으니 귀찮음을 무릅쓰고 글까지 쓰시며 질타하셨을 거라 생각합니다만 거의 차이 없는, 어찌보면 더 공격적일 수 있는 의도를 담은 대응은 그리 곱게 비치지만은 않습니다.

            물론 훨씬 더 정제된 표현을 사용하시기야 하셨습니다만 아무리 표현을 절제한다 하더라도 행간에서 느껴지는 진의라는 건 존재하고 그걸 모르실 연배는 아니실 거라 생각합니다. 제가 말씀드리는 부분 역시 모르고 글을 쓰시진 않으셨겠지만 무례를 무릅쓰고 이렇게 글을 올려봅니다.

            그리고 여담입니다만 젊고 유능한 게 참이라는 전제가 있다면 솔직히 말해서 업계에서 일하는 건 문제가 없는 것도 사실 아닐런지요.
            아무리 날카롭고 협업이 힘들더라도 합리로 제어 가능한 선에서 벗어나지 않는다면 어떻게든 같이 일을 못할 것도 아니고
            이 바닥에서 젊고 잘 하는 분은 언제나 부족하지 않습니까.

            이런 평판은 절대 무시할 수 없겠지만 결국 진짜 잘 하는 사람이라면 사소하고 부질없을 수도 있다고 생각됩니다. 물론 그런 타입의 사람이 어떻게 버티고 어디까지 올라갈 수 있는가는 또 별개의 문제이겠습니다만…

            아무튼 이 댓글에서 제가 드리는 말씀은 제 댓글에도 그대로 적용될 이야기이니 제게 다른 분을 나무랄 자격은 없습니다.
            저 역시 빈정상하는 부분이 있어서 귀찮음을 무릅쓰고 글을 올리게 되었으니까 다를 건 없겠지요. 익명에 기대어 실례될 수 있는 답변을 드리게 된 점 양해를 부탁드리며 물러납니다.

          • 지나가는사람

            다른 의견이야 충분히 이해하고 분명 님처럼 기껏 인생경험부족론을 펼치는 거냐고 문제 제기하실 분이 있으리라 알고 있었습니다만,
            한 가지 바로잡을 것은 경험부족론을 말하고자 함이 아니라, 업계에서 이미 자리잡은 사람들에게 굳이 평판이 안 좋아질만한 일을 대놓고 하는 게 플러스 요인은 아님을 말하고자 함이었습니다.
            (10년차 이상 개발자나 직책자들이면 아무래도 면접을 보거나 할만한 위치가 될텐데 혹시라도 면접에서 저 분을 보면 무슨 생각을 하겠냐는 뜻입니다. 다른 일을 하시거나 혼자 사업을 하시거나 하신다면 상관없을 수도 있겠지만요….)

            나이먹으면 감 떨어지는 건 사실인데 뭐하러 연령 우월론을 제기하나요? 당연히 젊은 사람들이 더 잘하겠죠…

            그리고, 굳이 언급하셔서 드리는 말씀입니다만, 저 개인적으로는 엄청나게 잘해도 attitude에 문제 있는 분은 가급적 피합니다. 아무리 혼자서 일할 수 있게 환경조성을 해준다고 해도 결국 팀웍을 저해하다 못해, 팀 자체를 박살내버리곤 하는 경우를 많이 봐서요.. 저보다 잘 아시겠지만 이 바닥 일은 기본적으로 팀웍 아니던가요…?

            마지막으로, 제가 하지도 않은 말을 인용하여 비판하는 것은 삼가주셨으면 합니다. (제가 어디서 여러모로 좋을 게 없을 것이다라고 했을까요?)

          • guest

            제가 저 문구를 봤다고 생각하고 스위치가 눌렸었는데 지금 자세히 다시 읽어보니 전혀 존재하지 않는 문구였군요. 아마 뉘앙스에서 느껴진 걸 실제로 하신 말로 착각해버려서 굉장한 실수를 해버린 거 같습니다. 제겐 저 글이 그런 형태로 읽혔었던 모양입니다. 전 뭐에 발끈했던 것일까요…
            사실이 아닌 부분으로 심기를 불편하게 해드린 점 죄송합니다. 진심으로 사과드립니다. 부주의를 관대하게 용서해주셨으면 좋겠습니다.

          • Jong Wook Kim

            안녕하세요, 두 분의 의견 귀담아 들었습니다. 말씀하신 것처럼 제가 인생 경험이 부족해서, 잘못된 지식을 전파하는 것을 보면 어떻게든 하고 싶은 말은 하고 넘어가야 하는 성격이라 말투가 언짢게 느껴지셨을 것 같습니다. 그 부분에 대해선 죄송하다는 말씀 드립니다. 다만 제 평판을 걱정하기보다는 소신에 가치를 더 두어서 실명으로 댓글을 남긴 것이라 말씀드리고 싶습니다.

            이음소시어스라는 멋진 스타트업을 응원하고 동경하는 개발자로서 이음 개발자 블로그에 당연히 기대하던 것에 못미치는 수준의 글이 이어져서 실망감에 다소 직설적으로 댓글을 달았습니다만 그 정도의 sarcasm도 수용되지 못하는 건 좀 아쉽습니다. Upvotes의 수를 보면 제 기대가 그렇게 허황된 건 아닌 것 같은데 말입니다.

            스스로에게 객관적 평가를 내릴 순 없겠지만, 제가 그렇게 협업을 못한다거나 프로젝트를 깨고 다닌다고 생각하진 않습니다. 옆에서는 이걸 보고 ‘종욱씨 이제 이직하긴 글렀다’며 좋아하고 계십니다 하하하

            문득 이 모든 것의 원인제공자이면서 까마득한 후배 개발자들한테 블로그 쓰고 댓글 달게 하는 전직 네이버 개발자 김호승씨는 어떤 생각을 하고 계실지 궁금해집니다. 혹시 직접 후속글을 쓰신다면 기대하고 있겠습니다.

          • Daehee Han

            종욱님, 처음부터 시종일관 공격적이었던 말투에도 불구하고 최대한 생산적인 토론을 이끌어 내어 보려고 했지만 몇 번이나 기회를 드려도 전혀 응하려 하지 않으시네요. 특히나 이번 댓글은 좀 도가 지나치신 것 같습니다. 알지도 못하는 분에게 누구누구씨는 어쩌고 저쩌고 하는건 상대에 대한 예의가 아니라는 말을 꼭 제가 지적해야드려야 하나요?

            이음 개발팀은 개발자 한 두명의 경험을 근거 삼아 다른 개발자들의 의견을 무시하고 특정 언어나 프레임워크를 채택할 정도로 꽉 막힌 조직이 아닙니다. 현재도 모든 프로젝트들이 실제 개발을 담당하는 실무자들이 기술적인 결정을 담당하고 있고요. 이음에서 C를 쓰는 것은 호승님 한 명의 독단이 아닙니다. 물론 head-start를 호승님이 하시기는 했지요. 하지만 저도 개발을 진행하다 보니 그렇게까지 나쁘다는 생각이 들지 않아서 이 글을 쓴 거고, C로 API 개발을 처음 해 보는 다른 개발자들도 마찬가지 의견이었습니다. 마치 이음 개발자들을 위에서 시키는 대로 행동하는 꼭두각시 마냥 말씀하셔서 굉장히 불쾌하네요.

            종욱님이 이음의 스프링 기반 레거시 코드에서 APR로 넘어간 논리적 추론 과정을 궁금해하고 계신다는 것은 아주 잘 알겠습니다. 하지만 이 글은 그에 관한 글이 아닐 뿐더러 그 기술적인 결정이 내려진 바탕은 아직 외부에 공개할 수 있는 수준으로 잘 정리되지는 않은 것으로 알고 있습니다. 귀한 upvote 해주신 분들의 수많은 기대를 충족시켜드리지 못해 안타깝네요.

            “이런 시도도 있구나”, “생각보다 나쁘지 않구나” 이 정도로 글을 읽어주신 분들이 있었기에 이 글의 목적은 달성되었다고 생각합니다. 위에서 말한 기술적 결정을 내리게 된 배경이 그토록 궁금하시다면, 종욱님이 응원하고 동경하시는 이음소시어스라는 멋진 스타트업 개발팀에 오셔서 이야기 한번 나누시지요. (물론 오프 더 레코드로) 그 전까지는 이 글과 관계 없는 종욱님의 트롤링을 더 듣고 있을 이유가 있을 것 같지 않기 때문에 종욱님의 댓글 쓰기 권한을 제거하였습니다. 좋은 하루 되세요.

            p.s. 찾아오실 생각이 있으시다면 메일 주세요. devteam@i-um.net

          • Jong Wook Kim

            음 마지막 리플로 한대희’님’께서 이렇게 여러모로 기분나빠하실 줄은 예상하지 못했습니다. 제 불찰입니다. 본문에서도 소개되고 댓글로도 네이버의 사례를 소개하시며 참여하였던 이음 개발자 김호승님의 의견을 이음 개발 블로그 애독자로서 궁금해할 수 있을 것 같은데 트롤링이라 평가하시며 차단까지 하시니 면목이 없습니다. 이 블로그의 의도를 저와 유사하게 읽은 사람이 적지 않은데도 글의 성격을 한가지로 규정하여 독자의 시야를 제한하시는 것도 조금 섭섭합니다.

            그럼에도 저를 초대까지 하시며 알려주시려는 그 기술적 배경은 이제 대충 파악된 것 같습니다. 논란이 처음 예상보다 커지면서 이음과 인연이 있던 분들에게 실례가 많았습니다.

          • D

            본문과 댓글 타래에서의 논쟁과는 전혀 별개의 이야기이긴 합니다만
            이 포스팅과 댓글 흐름을 따라가던 도중 이 부분을 읽고 궁금한 점이 생겨 글을 남기게 되었습니다.

            종욱님의 댓글쓰기 권한을 제거하는 건 대희님 개인의 결정이신가요, 아니면 이음소시어스의 결정인가요?
            또한, 종욱님의 권한이 제한되는 건 이 포스팅뿐인가요, 아니면 이 블로그 전체에 해당되나요?
            그 의사 결정과 수행은 이음소시어스의 공식적인 리액션으로 이해해도 되는 건가요?

            개인적으로는 IT 스타트업의 기술 블로그에서 이런 결정이 나왔다는 사실에 대해 정말 깜짝 놀랐습니다;;
            아무리 생각해도 저로서는 논쟁 중인 대상의 댓글쓰기 권한을 제거한다는 결정은 도무지 이해되지 않습니다.

            물론 종욱님의 글투를 볼 때 감정적인 이유로 그런 결정을 내릴 수 있다는 건 충분히 이해할 수 있습니다.

            개인 블로그였다면요.

            그런데 회사의 기술 블로그에서, 그것도 기술적인 접근이 배제되지 않은 의견에 대해
            그런 결정을 내린다는 건 조금 이해하기 어렵습니다.
            물론 종욱님의 글투에 기술 이외의 자극적인 것들이 충분히 실려있는 건 사실입니다만
            그건 이음소시어스측 분의 댓글에도 만만찮게 실려있지 않습니까?
            감정적으로 날카로워진 건 양쪽이 동일한데 한쪽만을 일방적으로 배제하는 케이스는 쉽게 납득이 가지 않습니다.

            물론 이곳은 이음소시어스의 공간인 만큼 객이 주의 결정에 뭐라 논할 순 없을 것입니다.
            그러나 그 의사결정과 행보에 따라 이 공간을 주시하는 (댓글을 달지 않고) 분들이 그 주인에 대해 짚어볼 수 있는 모습은 상당히 많다고 생각합니다.

            개인적으론 긍정적인 댓글에만 사측 분의 댓글이 달리는 빈도가 높고 그렇지 않은 댓글에 대해선
            (제가 보기엔 글에 실린 감정이나 예의와 무관하게) 상대적으로 대응 빈도가 낮다고 느껴집니다.
            물론 인간이 언제나 이성적인 판단을 할 수 없는 거야 인지상정이고;
            대희님의 반응도 개인 대 개인이었다면 십분 공감할 수 있는 터라
            글의 공격성이란 부분에 한해서 대희님에 지지를 보내며 댓글을 따라가고 있었습니다만
            공간의 주인의 권리가 사용된 시점에선 개인 대 개인이 아닌 회사의 견해가 궁금해지기 시작했습니다.
            이쯤 와선 공과 사, 감정과 이성의 간격이 조금 모호해 보이는 것도 사실입니다.
            아무래도 장소가 장소이니까요.

            이 정도의 페이지뷰와 댓글수가 나온다면 그건 그만한 이유가 있어서라고 생각합니다.
            그 이유가 본문일 수도, 떡밥이 될 댓글을 남긴 사람일 수도, 그 댓글에 대한 리액션일 수도 있을 테지요.
            애당초, 어지간히 활성화된 곳이 아닐 때 댓글기능이 달려 있으면
            결국 영양가 없고 조용한 반응이 이어지거나, 뜨거운 감자 하나가 튀어나와서 날카롭게 달아오르거나 둘 중 하나란 걸 대부분 아실 것입니다.

            그런데 이 논의가 받아들일 수 있는 역치에서 벗어난다면 댓글 기능이 과연 쓸모가 있을까요? 어떠한 논의가 어디까지 가능할까요.
            물론 여러 긍정적인 댓글들을 보며 팀원들의 사기를 진작시키는 데에는 큰 도움이 되겠습니다만… 기술블로그로서의 가치에 대해서는 물음표가 던져지는 것도 사실입니다.

            이 의문에 대해 어떠한 견해를 갖고 계신 지에 대한 답변을 들을 수 있기를 희망합니다.

          • Daehee Han

            우선 댓글 권한 제거는 회사의 입장하고는 무관하게 제 개인적인 판단이었음을 알려드립니다. 기술 블로그의 다른 글들도 마찬가지지만, 제가 이 글에서 밝히고 있는 견해는 회사측의 기술적 관점과 다른 부분이 있을 수 있습니다. (그게 글 말미에 작성자를 밝히는 의도이기도 하구요)

            이 글을 쓴 입장으로서 종욱님의 ‘기술적인’ 요지를 충분히 이해하고 있고, 그에 대해 부연 설명 – 지적해주신 부분은 분명 의미있는 토론이 가능한 부분이나, 이 글의 scope에서는 벗어나고 있다. 작성자로서도 명확한 답변을 줄 수 없다. 추후 기회가 되면 다시 다루었으면 좋겠다 – 는 입장을 댓글에서 여러 번 밝혔다고 생각합니다. (부정적인 댓글에 대해서 대응 빈도가 낮은 부분도, 글의 scope – C를 사용해서 API를 개발해 본 개인적인 감상 – 를 처음부터 한정지어 놓았기 때문입니다.) 그럼에도 계속해서 공격적으로 정작 글을 쓴 제가 아닌 다른 팀원분까지 물고 늘어지는 상황까지 갔기에 어쩔 수 없는 조치였다고 생각합니다. 권한 제거는 양쪽 모두 분위기가 가라앉으면 해제할 예정이었습니다. (차단을 한다고 해서 꼭 필요한 댓글을 못 쓰시리라 생각하지도 않았구요.)

            많은 분들이 댓글로 지적해주신 대로 스스로도 기술적인 부분에선 아쉬운 점이 많이 있는 글이라고 생각합니다. (애초에 그렇게 대단한 글을 쓰려는 의도도 없었고요.) 그럼에도 불구하고 작성자의 원래 의도를 파악해주신 분들이 많아서 그나마 다행이라고 생각합니다. 다들 글에서 언급하지 않은 부분까지 많이 궁금해해 주시는 것, 모두 관심의 표현이라고 생각하고 다음엔 더 나은 글로 보답하도록 노력하겠습니다.

          • D

            답변에 감사드립니다.

          • h

            이쯤하면 기술적인 문제가 아니라 인성의 문제입니다.
            C언어로 서버 만들자고 하면 아주 그냥 죄인이군요 ㅋㅋ

            “NIH 신드롬에 크게 빠져 계신데, 이 증후군의 증상 중 하나가 남이 아무리 얘길 해도 자긴 그게 잘못된 걸 모른다는거거든요.” – 이거 정말 명대사입니다.

          • Jong Wook Kim

            이번 논란이 단순한 Java 신봉자와 C 신봉자의 싸움으로 비화되길 바라지 않습니다. 말씀하신대로라면 직장에서 서버 구현에 C언어를 사용하고 있는 저도 대역죄인입니다.

            명대사라고 인용하신 부분은 수차례 반복되는 프레임웍 무용론에 대한 비판 차원에서 한 표현입니다. 물론 그 표현에 대해 있을 수 있는 비판은 처음부터 감수하고 시작한 것이므로 겸허히 받아들이겠습니다.

          • guest

            개인 블로그의 포스팅이었다면 ‘좋은 받아치기로 +1점’ 같은 느낌이었을 텐데, 이 공간에서 이 회사를 대표하실만한 입장으로 쓰시기엔 조금 미묘한 감이 있는 댓글이라고 생각합니다.

    • Daehee Han

      저도 자바 좋아합니다. 하지만 자바도 C 만큼이나 로우레벨 언어라고 생각합니다. 자바의 진가는 프레임웍이랑 같이 쓸 때 발휘되는 것이라고 보았기에 큰 메리트가 없었다고 생각했을 뿐이구요. 이 글이 종교전쟁이 되지 않았으면 좋겠네요~

      • Jong Wook Kim

        NIH 신드롬에 크게 빠져 계신데, 이 증후군의 증상 중 하나가 남이 아무리 얘길 해도 자긴 그게 잘못된 걸 모른다는거거든요.

        아키텍트의 역할은 선택의 연속이고 작은 선택 하나에 있어서도 그것이 다른 대안보다 적절한 선택이라는 근거를 제시할 수 있어야 합니다. 그 부분에서 근거가 부족한 선택을 했다고 사람들이 여러 이유를 들며 지적을 해도 “C로 해서 지금 잘 돌아간다능 C로 짠 우리는 고수라능”하면서 납득가능한 근거 없이 믿음을 유지하는 그쪽이 종교적이 아니면 무엇이겠습니까. 제가 자바 까지 말라고 말이나 했습니까? 엔지니어링 블로그로서 가치가 있는 글이 되려면 저런 engineering decision을 납득할 수 있도록 구성해야죠. 비교대상도 아닌 컴파일러 IDE 얘기로 물 흐리지 말고요.

        지금 잘 돌아간다는 것은 납득가능한 근거가 되지 못해요. 경계해야 할 안좋은 개발 practice들은 다 따라해가며 스프링코드보다 거대한 레거시를 남겼을 따름이죠. 그 와중에 잘 돌아가는 시스템을 만든 건 수고하셨습니다. 이 글의 가치는 딱 여기까지라고 봐요. 수고하셨습니다.

        아무쪼록 C로 짠다고 했을 때 극구 말릴 사람이 회사에 아무도 없었다는 사실이 안타까울 따름입니다.

        PS. 그림판에서 만들만한 16×16 아이콘은 윈도우 98에서나 썼죠. 옆에서 디자이너가 코웃음을 치는 바람에ㅋ

        • 왠지 얘기가 과열된것 같네요

          –사람들이 여러 이유를 들며 지적을 해도 “C로 해서 지금 잘 돌아간다능 C로 짠 우리는 고수라능”하면서 납득가능한 근거 없이 믿음을 유지하는 그쪽–

          이런 말들이 분쟁을 불러 일으키는것 같네요.
          저자가 쓴 글 내용이나, 이 글에 단 댓글 어디서도
          ‘우리는 잘났음. 우리는 고수임’ 이런 느낌이 들지 않는데요.

          Jong Wook Kim 님께서 스스로 유추하신 내용을 글 저자가 쓴것 처럼 확정짓고 말씀을 하시면.. 허허..

          뭔가 C로 개발하면 ‘고수다’라는 개인적 선입관이나 고정관념을 가지고 계신게 아닐지요. 그게 아니라면 왜 갑자기 고수얘기가 나오는지 잘 이해할 수 없네요.

          글 내용에 대한 여러 의견들이 댓글을 통해 오가고 있어서 좋다고 생각했는데,
          개인적으로 느꼈던 부분을 팩트인것처럼 말씀하시니…
          어쨋든, 이런 저런 의견들이 많아서 댓글 보는 재미는 있네요. 잘 봤습니다.

          • d

            직접적으로 ‘우리는 잘났음. 우리는 고수임’ 하고있진 않지만 글을 읽어보면 충분히 그런 뉘앙스가 느껴지는데요?ㅋㅋㅋ
            애초에 사내 공식 블로그에 올라오는 글이라는게 c로 api 짜는걸 자랑이라도 하고싶었던 양 글을 쓰는데 뭔가 글에 논리는 없고 컨텍스트 스위칭같은 소리를 하지 않나 static type이니 type safety니 논점에도 안맞는 개소리를 하고 있어서 가루가 되도록 까이는걸로 보입니다.

          • d-

            음 뭐 사람마다 의견이 다른건 이해합니다만,
            ‘ㅋㅋㅋ’, ‘~하던 양’, ‘~같은 소리’, ‘개소리’ 등등
            상대방을 이렇게 비하하는 어린애 수준의 댓글을 달면
            아무리 논리가 좋아도 설득력이 떨어진다고 생각합니다.

          • Daehee Han

            그럼 C로 API 짜는게 무슨 부끄러운 일이니까 숨어서 짜야 하나요? ㅎㅎ 다양한 선택지중에 하나를 보여드렸을 뿐입니다. 외부문서 참고할게 적어서 흐름이 덜 끊긴다 (이건 C하고는 상관없는 이야기이긴 하네요), 정적 타입 언어라서 컴파일 타임에 타입 에러 잡을 수 있고 IDE의 지원을 받기 수월하다, 이게 왜 개소린가요?

          • 김윤호

            흐름이 덜 끊기는 건 참이어도 그게 좋다고 얘기하려면 더 설명이 있어야한다고 봅니다. 그냥 흐름 좀 끊기더라도 남이 잘 만든 기능 쓰는 게 내가 새로 만드는 것 보다 더 빨리 개발할 수 있다면 흐름 끊어가면서 일 하는게 낫겠지요. 다양한 선택지 중 하나를 보여준 건 좋은데 한 선택지가 다른 선택지에 비해 납득할만한 장점이 없다면 안 보여준 것 보다 못할 수도 있고요.

        • Daehee Han

          제가 C + APR이 단점이라곤 찾아볼 수 없는 지구 최강의 프레임워크라고 이야기 한적이 있나요? 아니면 C 언어가 다른 언어에 비해 우월하다고 이야기했나요? 왜 제가 하지도 않은 말이 자꾸 나오는지 모르겠네요. 모든 프로그래밍 언어가 그렇듯 장점이 있으면 단점도 있지 않겠습니까? 다만 저희는 그 단점이 그렇게까지 결정적이지는 않다고 생각하고 있는 것이지요.

          어째서 이런 engineering decision을 내렸는지에 대해서는 내부 사정이라 저도 자세히 공개할 수 없는 게 아쉽네요. C로 개발한 코드를 직접 보여드릴 수 없는 것도요. 그게 가능했다면 안좋은 개발 practice니 뭐니 실제 코드를 보지도 않고 늘어놓는 허수아비 논증으로 공격받을 일도 없을텐데요. 근거 이야기 하셨는데 그쪽에서도 왜 spring 기반 레거시를 유지하는 것이 나은지에 대한 증거는 전혀 안보입니다. 좀 구체적인 이야기를 해주세요. 새로 개발하는 것보다 ORM을 바꾸는게 더 낫다고 판단하신 이유를 말씀해주셔야 좀 발전적인 이야기가 될거 아닙니까? 구체적인거 하나도 없이 기술 이름만 몇 개 늘어놓고 잘못했다는 소릴 들으니 황당하네요.

          잘 돌아가는 시스템을 만들었습니다. 유지보수하기도 생각만큼 나쁘지 않아요. 제가 의도한것도 딱 거기까지였습니다.

        • guest

          댓글을 올렸는데 왠지 업로드가 안되 다시 작성해봅니다;

          도대체 어딜 봐서 “우린 고수라능”이라는 느낌을 받을 수 있는지 파악이 안되네요. 다시한번 읽어봐도 그런 느낌을 받을 수 있는 곳을 찾기 힘든데.. 제가 아직 초보라서 그런걸까요?

          지금 김정욱님이 하신 말씀 대부분이 불쾌합니다. 자기의 틀에 타인을 맞추려고 하시는데.. 뭐 당연하다 생각합니다. 자기의 판단에 의해 다른 사람을 바라볼 수 밖에 없으니까요.

          하지만 김정욱님이 하신 말씀은 자기의 판단이 마치 진실인것 처럼 말씀을 하시는게 이 글 어디에도 “우린 고수임”이라는 말이 없고 그런 늬앙스 조차 없다 생각합니다. “오히려 우린 이런 도전을 해봤어요. 도전해보면서 이런일이 있었어요!” 라는 늬앙스의 글이라 생각합니다.

          김정욱님은 자기가 정한 프레임안에서 밖을 바라보니 그런 생각을 하시는거라 생각합니다. 그런 생각의 근본 자체가 잘못된건 아니지만 다양성을 인정하고 공유하는게 맞는거 아닐까요?

          특정부분의 전공자라면 다양성을 인정하고 타인의 도전이 격려해주고 그 도전 내에서 잘못된 일이 있다면 바로 잡을 수 있게 해줘야지. 넌 틀렸어^^. 이건 여기까지야. 라고 말하는거 자체가 덜 성숙한 사람을 보입니다.

          기술적으로 김정욱님이 얼마나 대단한진 잘 모르겠지만 이런 식의 댓글은 아니라고 생각합니다.

          아~~무리 사소한 것이라도 의미 없는 도전이란건 없다고 생각합니다. 사회 전체적으로 봤을 땐 그 의미가 적을지 몰라도 그 도전을 해낸 사람들 사이에서는 서로 배우고 깨우친게 많으리라 생각합니다.

          그런 도전에 대고 어디서 얼마나 배우셨는진 모르겠지만 틀 안에 가두고 여기까지 라는 한정을 지어버리시는지 참.. 대단하네요.

          자녀가 있으신 분인지 모르겠지만 나중에 자녀분이 받아쓰기 100점 받아왔을 때 “넌 글씨가 이게 뭐냐 100점이면 다 같은 100점이야? 잘 좀 할 수 없어?” 이렇게 말하실거 같네요;

        • Yu-heung Jeon

          무슨 근거로 그렇게 확정 하시는지 궁금 하네요..

          그냥 글을 읽으면서 적어도 저는 “아 이런 접근 방법도 있구나”
          라는 긍정적인 느낌을 받았습니다.
          님 말씀 처럼 강한 기술적인 적합성 얘기는 없었지만.. 그건
          글쓴님이.. 기술문서나 논문에 내 놓은 글도 아니고 회사 블로그
          글을 그렇게 가차 없이 까는 것은 선배??로서 좋은 모습은 아닌 듯 합니다.

          그리고 포토샵이랑 그림판 얘기는 뭔 비유가 이러신지..

          그리고 얼마나 내공이 높으신지 모르겠지만 비웃고 경멸하는 말투 엄청 그렇네요..

          이런 것이 오히려 더 NIH 신드롬 아니신지??

    • 지나가던 개발자

      Java->C의 정당화는 이 글의 작성자가 해야 될 부분이 아닌듯하네요.
      애초부터 담당하던 프로젝트가 아닌 편입하게 된 상황에 legacy 코드가 C인게 맘에 안든다고 다 갈아엎는게 말이 안되죠.
      이러한 상황에서 legacy 코드와 함께 잘 동작하도록 코딩해서 좋은 성능을 뽑아내는데 성공하고 ‘생각 외로 이렇게 작업하는것도 괜찮았다’는 ‘경험담’인것같네요.
      ‘이거 짱짱맨!’이 아닌거같은데…. 오히려 NIH신드롬에 빠져서 되는데로 붙잡고 까고싶으신건 아닌가 싶어요.

  • Guest

    이 포스팅은 그냥 자기 자랑 처럼 보여지는건 왤까요.? 알맹이는 없고 그냥 C 쓰면 빠르다. 정도의 느낌?

    • 쓰레기단장

      이음같은 큰 서비스에서 대부분 생각조차 안 하고 있는 C로 개발해 보니?
      라는 명제를 던지고

      1.C같은 생산성 안좋은 언어로 만들어도 될까?
      2.과연 얼마나 빨라질까?

      라는 두 가지 질문에 대한 답을 던지고 있어요. 결국 글쓴님은 1,2 전부 긍정적이다 라고 결론 주셨구요.

      결론 하나만으로도 이 글의 가치는 있지 않나 해요. 개발 중인 서버도 아니고 이미 돌고 있는 상용서비스의 기본을 갈아 엎는거 생각보다 쉽지 않습니다. 현업에서는 다른 상용 서비스가 어떻게 했다 라는 사실들이 은근 많은 참고가 됩니다.

  • svaha

    저의 생각에는 글쓴이 본인도 결론 부분에서 모바일 api를 말하면서 잠깐 언급을 했지만 api가 상당히 심플한 구조였기 때문에 생산성 차이가 별로 안 난다는 이야기를 할 수 있었던 것 같네요.

    아마도 아파치와 후레임워크로부터 사용자가 보낸 리퀘스트의 파라메터들을 맵으로 받아와서 db 쿼리를 하고 결과를 json으로 출력해주는 형태였겠죠?

    저도 임베디드 리눅스 기반에서 파이프라이닝을 기반으로 돌아가는 c 모듈들을 꽤 작성해봐서(멀티미디어 기기에서 pcm을 처리하는 모듈들이어서 텍스트 처리 위주의 코드들 보다는 소량 복잡한 애들이었습니다) 궁리궁리 잘해서 로직들을 짜르고 패턴화시키는 일을 잘만하면 c언어를 이용하더라도 원하는 결과를 상당히 빠르게 뽑을 수있다는 것은 경험적으로 알고 있습니다.

    하지만 레일즈랑 비교라뇨… 레일즈는 명령어 하나만 내리면 crud가 한방에 생성되고 ui까지 생성이 됩니다. 스카폴딩이라고 하죠? 글쓴이도 레일즈를 즐겨쓰신다니 잘 알고있을 거라고 생각합니다. 좀 심하게 뻥을 보태면 “모델에 벨리데이션 몇개 걸고 css 몇줄 작성”하는 걸로 개발이 끝나죠.

    저런 html 기반 ui까지 c 언어로 다 출력해주는 상황하고 비교를 해야지 제대로 된 비교가 될거라고 생각합니다.

    물론 그렇게 따지면 생산성은 비교가 안되겠죠… 참고로 저는 레일즈보다 씨에 훨씬 익숙한 사람입니다만 웹기반 어플리케이션을 씨로 작성한다고 하면(도대체 왜?) 레일즈에 근접은 고사하고 한 1/10은 나올까 의문스럽네요.

    사실 저는 글을 읽으면서 APR이라는 후레임워크가 리스트, 해쉬맵 따위의 자료구조도 제공을 하고 apr_pcalloc 같은 녀석도 제공한다길래 “오우 정말? 촘촹?!?” 막 이랬고 중간에 성능관련 표를 보면서도 “역시 let it be! 아니 write in c!” 막 이랬었는데… 그 외에 좀 무리스러운 스토리 전개로 인해 너무 까이는 것 같아서 안타깝기도 하네요.

    어쨌건 자신들의 소중한 경험을 공유해주신 것에 대해서는 정말 감사하게 생각합니다. apr 관련된 내용이나 좀 구글링해보고 써먹을 일이 생기면 한번 시도해보고 그래야겠네요.

    • Daehee Han

      html 까지 고려를 했다면 당연히 C를 쓰지 않았겠죠. 모바일 API였기에 가능한 결정이었다고 생각합니다. 말씀해주신 부분은 미처 고려하지 못했네요 ㅎㅎ 좋은 의견 감사합니다 🙂

  • Guest

    C에서는 쓸만한 외부 라이브러리가 많지 않습니다. 하지만 외부 라이브러리를 덜 가져다 쓴다는 말은 그만큼 관련 문서들을 찾아보는 데에 시간이 덜 걸린다는 이야기도 됩니다. 따라서 IDE와 웹브라우저 사이에서의 컨텍스트 스위칭에 시간을 덜 쓸 수 있습니다.

    부분은 아무리 읽어도 이해가 잘 안되네요….
    라이브러리를 쓰는 것 보다 직접 짜는게 빠르다니 ㄷㄷ

    • Daehee Han

      더 빠른게 아니고, 문서 읽는 시간보다 코딩하는 시간이 더 많아진다는 이야기였습니다.

      • GN

        조금 막연했는데, 납득이 힘든 이유를 알았습니다..
        지금은 당장 말은 맞는 말입니다.
        문서 읽는 시간이 줄어서… 라는 단서는.
        언제까지고 지속되는 조건이 아닙니다.

        다른 언어도 익숙해지면 문서 볼 시간이 줄어 들겠죠.
        그렇다면 결국은 더욱 차이가 생길테구요.

        그리고 이런 설명이 개발팀 블로깅에 적합한가,
        C를 선택하는 이유가 될만한가? 다른 사람들도 이런 방식으로 할만한가?? 라고 생각하니.
        납득이 안됐던 것 같습니다.

        그냥 본인 사정상 당장 C가 가장 익숙했으며, 끝내주는 성능이 나오더라. 정도였으면 완전 납득했을 것 같습니다.

        반대로 이야기 하자면..^^
        글쓴이님의 글에 많은 사람들이 큰 기대를 가지고 있는것 같습니다.
        이번 반응으로 어깨가 무거워지겠어요..!

        • Daehee Han

          네 좋은 포인트인것 같습니다. 그래서 저도 다른 분들에게 권해드리기는 조금 조심스럽네요. 이런 경우도 있더라, 정도로 받아들여주셨으면 좋겠습니다. 감사해요 🙂

          • namo

            코드가 적을 때는 코딩하는 시간이 많지만, 코드가 점점 많아 질 수록 읽어야 할 코드는 점점 많아집니다. 문서 읽는 것보다 자기가 짠 코드에 치일 수 있다는 것이죠.
            잘 추상화되어 있는 라이브러리를 사용한다면 문서 읽는 시간이 아깝지 않을 것 같고, 코딩하는 시간을 줄이고 효율적인 프로그래밍이 되지 않을까 생각해보아 댓글을 남겨봅니다.

  • Taeho Kim

    답이 하나만 있는 것도 아니고 충분히 좋은 결과를 만든 개성 있는 시도에 박수를 보냅니다.

  • nodelay

    의아한 부분도 있는데, 경험을 공유해 주셔서 정말 재미있게 읽었습니다. 감사합니다.

  • Guest

    재밌는 개발 경험담 잘 봤습니다.
    해보지도 않고 잘난 척 + 빈정대면서 까는 게 훌륭한 엔지니어링이라고 생각하는 것보다는
    의미있는 시도라 생각합니다.

  • 지나가던 개발자

    개발에 있어서 답이 하나뿐이라고 생각하지 않는 한에야 공격적인 반응을 보일 필요는 없어보이는데 중간의 어떤분의 “공부나 더하라”는 식의 말버릇은 어디서 배운건지 궁금하네요.
    충분히 의미있는 경험담이라 생각합니다. 예전, 저사양 저전력에서 빠르게 동작하기 위한 Restful Server를 C++로 개발한 적이 있습니다만 APR같은 방법이 있는건 처음 알았네요. ㅎ 좋은 내용 잘 읽고 갑니다.
    참고로 저는 상황에 따라 필요충분한 기술을 적용하여 납득할만한 결과를 내는게 엔지니어라 생각합니다. C로 개발을 진행하신 점에 있어 이후의 유지보수에 문제가 발생하지 않을까 염려되긴 하네요.

    • Daehee Han

      저도 C는 학교 졸업하고 거의 쓰지 않았고, 자바 파이썬 루비 처럼 그나마 조금 소프트한 언어를 다뤄서 “도대체 C를 왜 쓰지?”했는데 막상 해보니 생각만큼 어렵지는 않다는 생각이 들더군요. 사실상 C는 개발자라면 다들 기본정도는 알고 있으니까요.

  • C로 서버짜보고 싶어요

    전 포스팅을 보고 C로 개발해보고 싶다는 공돌이적 마인드가 불타올라 “우리도 간단한 서브 서버 C로 만들어봐요”라고 건의 했다가 엄청 구타 받았었습니다.

    이런 시도를 할 수 있다는거 자체에 이음이라는 회사의 개발 환경이 정말 부럽습니다.
    왜 다들 자기와 생각이 다르다고 비꼬고 공격하는지 모르겠네요.

    충분히 의미 있는 시도 였고 결과도 좋고.
    경험적으로 좋지 않은 결과를 얻었던 일에 대해 다시 하려고 하면 거부반응을 일으키는건 당연합니다만 이렇게 나름 만족할만한 성과를 낸 분들에게 이래라저래라는 아닌거 같습니다.

    모두가 수학을 공부할 때 미적분부터 공부하는 것이 아닌 만큼 다른 사람의 시도를 관대한 마음으로 보고 배울게 있다면 배우는게 맞다고 생각합니다.

    모두 서울로 가는 것을 목표로 누구는 자동차, 누군 걸어서, 누군 비행기를 타고 갈 수 있습니다. 걸어서 서울까지 도착한 분이 오면서 봤던 풍경들에 대해 여행 포스팅을 쓰니 비행기 타고 온 사람이 우린 하늘에서 봤다고 우리가 더 우월하다고 태클 거는거 같네요.. 서로 본게 다르니까 정보를 “교환”해야지 옳고 그름을 따지지 않았으면 좋겟네요. 절대적인 것은 없으니까요.

  • 초보

    본문과 반론들 잘 봤습니다 의견교환은 좋지만 과열되지는 않는것이 좋아보이네요 잘 읽고 갑니다!

  • JJ

    찬반 토론이 많아서 재미있는 포스팅이네요. 글쓴이가 기분 상할 수도 있겠지만,
    혹시 가능하시면, C로 API서버를 만들어서 좋았던 점, C도 나쁘지 않은 이유 말고, API 서버를 C로 만든 과정에 대해서 공유해주시면 좋을거 같아요.

    결정을 내린 과정과, 준비했던 과정, 만들면서 재밌었던 이슈들…
    요런글이 더 흥미진진할거 같아요.

    • Daehee Han

      저도 프로젝트 중간에 투입되어서 히스토리를 완벽하게 설명드리지 못해 이런 오해가 생긴 것 같기도 해요 ^^; 기회가 되면 그런 부분들에 대해서도 다시 이야기 해볼 수 있도록 하겠습니다!

  • 파송송

    저는 재미있게 잘 보았습니다. 뭔가 논쟁이 일어나는듯 한대… 그냥 이런 방법도 있구나 하는 가능성을 보여주신것 뿐이고 그로 인한 성능과 효율은 각자 판단 하시면 되는 부분인듯….

  • kh

    제가 봤을떈 이 글이 좀 난감한게, 사실 C와 APR을 쓰는것 자체야 내부의 복잡한 사정이 있을 수도 있고 여러가지 이유가 있겠지만 이 글에서는 C와 APR이 좋은 이유를 굳이 내새워 가며 기술적 결정에 따른 정당성을 부여하려고 하기 때문인거 같습니다.

    그래서 어떤 분들은 객관적으로 C와 APR의 단점을 지적하시고, 다른 분들은 뭐 이런저런 시도를 해보고 공유할 수도 있지 왜 태클이냐 하는 조금은 다른 관점으로 토론을 하고 계신거 같네요.

    개인적으로도 객관적으로 봤을때 C와 APR이 더 낫다는 이유를 전혀 공감할 수가 없는데,

    C에서는 쓸만한 외부 라이브러리가 많지 않습니다. 하지만 외부 라이브러리를 덜 가져다 쓴다는 말은 그만큼 관련 문서들을 찾아보는 데에 시간이 덜 걸린다는 이야기도 됩니다. 따라서 IDE와 웹브라우저 사이에서의 컨텍스트 스위칭에 시간을 덜 쓸 수 있습니다.
    컴파일 언어라는 특성에서 비롯되는 IDE의 도움이 강력합니다. (자동 완성, 타입 체크, 오류 점검 등)
    컴파일이 되기 때문에, 개발에는 시간이 더 걸릴 수 있지만 테스트와 디버깅에는 시간이 덜 걸립니다.
    1. 외부와 http 로 통신할 일이 있습니다. a) http client 구현. b) libcurl 사용. c) python의 requests나 ruby의 HTTParty 등의 라이브러리 사용. a,b,c중에 지금 a가 제일 낫다고 생각하시는건가요? 제가 써본 로는 b와 c도 생산성 차이가 상당했습니다.

    2. c와 python/ruby를 비교하면 그렇겠지만, c와 java를 비교해서 뭐가 딱히 우위가 있는지 모르겠습니다. visual studio를 내세우고 싶으신거라면, eclipse 말고 intellij도 좀 써보세요.

    3. 테스트와 디버깅에 대체 왜 시간이 덜 걸리는지 모르겠네요. 일단 오류 하나 나면 예쁘장한 backtrace가 아니라 segmentation fault, double free bug 같은것과 싸워야 하는 데다가 디버깅 하려고 한줄 수정하면 컴파일을 다시 해야되는데요.

    회사에서 내부적으로 내린 결정 자체를 비난할 생각은 전혀 없습니다. 나름의 합리적인 이유로 잘 하셨으리라고 믿으니깐요. 근데 이 글처럼 말도 안되어보이는 이유로 C와 APR도 충분히 괜찮다! 라고 외부적으로 굳이 합리화를 시키고 인정받으려고 하진 않으셔도 될거 같습니다.

    • Daehee Han

      개인적으로는, 애초에 APR이 XX보다 나아요라고 할만한 점은 퍼포먼스 말고는 그다지 없었다고 생각하고요. 저같이 C로 개발을 많이 해보지 않은 개발자들이 봤을 때는 API 개발을 C로 한다는 발상 자체가 끔찍할 수 있는데 그 정도는 아니라는 내용의 글이었습니다. 다들 왜인지 저희가 스스로 내린 결정에 대한 정당성을 인정받으려고 쓴 글이라고 생각하시는데 이런 방법도 있다 정도가 본디 의도입니다.

      1. 모든 라이브러리를 바닥부터 개발하자는 이야기는 아닙니다.
      2. 저도 c, java는 큰 차이 안 난다고 봅니다.
      3. segfault는 방어적으로 프로그래밍하면 어느 정도 예방할 수 있는 부분인 것 같고요, double free bug는 memory pool 쓰면 만날 일이 없습니다. 컴파일은 아직까지 그렇게 오래 걸린다고 느껴본적이 없네요. (현재 < 10s 정도입니다)

      • JAVA머신

        C는 저수준의 언어이기에 JAVA와는 비교도 안될 만큼 성능이 우월합니다. 비슷비슷하다구요? ㅎㅎ JAVA와 C로 서비스 비교하면 미들웨어에서 얼마나 많은 차이가 나는데요.. C는 장점보다 단점이 더 많죠.
        다만, 장점1가지가 워낙 월등하니깐… 그렇다고 어셈블러로 개발하자는거는 아닙니다만, 서버단 개발에서는 C만한게 없죠.. 성능이 아주 크게 우월하니깐요. 그래서 구글이나 대규모 서비스에 서버단은 C가 아직도 많습니다. ㅎㅎ

    • 플오그램어

      이클립스 단축키 세팅 제대로만 하면 생산성 최고입니다. 제가 보여드리고 싶군요. 플러그인 설치도 본인이 잘하면 이클립스 안에서 디비 작업까지 다 끝내버리죠.

      • kh

        아, 굳이 이클립스를 비하하려는 의도는 아니였습니다 🙂 다만 제가 1년 전에 썼을때는 속도가 그닥 맘에 들지 않았던 기억이 있네요.. 저는 eclipse, intellij, visual studio 셋다 쓰지 않습니다 🙂

        • 플오그램어

          속도도 어느정도 최적화 가능 하고. 이클립스의 단점은 역시 성능을 많이타서 확실히 저도 SSD + i7 + 32G 메모리 항시 유지합니다. 이렇게하니 그럭저럭 성능도 좋고 하나로 정말 여러 작업들을 할 수 있어서 좋아합니다. C작업을 못한다는것만 빼면 ( 할수있지만 좀 빡치죠 세팅이)

  • 플오그램어

    저도 웹개발과 스마트폰과 보안회사 보안 라이브러리 개발하며 근무한 경험으로는 같은 코드를 짰을때 자바와 c의 성능차이는 크게 났던 기억은 없었네요. 그냥 그회사에서 주로 해온 스타일이 기반이 되었던 것이지요.. 글쓴이님에게 안타까운 부분은 자바는 어떤 프레임웍과 같이 써야 좋다는 시선인데. PLAT한 C나 plat한 자바나 그게 그겁니다. 차라리 자바가 더 빠른 결과를 얻을 수 있으니 좋다고 보고 있지요.
    같은 코드 짰는데 성능이 자바가 더 안좋았다면 그건 코드 최적화를 좀더 해보시기를 추천 하고 싶군요.

    글쓴이님이 자바나 php 는 옛날 언어 라는 말이 특히 php 는 7년전에도 그랬었는데 지금도 벤처기업이나 생산성 선호 하시는 분들은 여전히 선호합니다. 딴것보다 회사에서 신입들 들어오면 문법이 쉬워서 빠르게 일에 투입되니 생산성에선 여전히 최고죠.
    언급하신 ruby on rails나 python django 같은 것도 써보았고 굉장히 끌려 했었지만
    막상해보면 개념을 이해하는 단계부터 구조에 익숙해지는 시간이 길어서 결국엔 비슷비슷 합니다. 차라리 그시간에 php yii 같은 프레임웍을 쓰는것도 나쁘지 않아보이구요.

    그리고 spring 은 생산성은 정말 쥐약인 프레임웍인데 (물론 ejb 보다는 빠르지만)
    그것이랑 비교하니 다른게 빨라보이셨을지도 모르겠네요.

    php 는 옛날 언어가 아닙니다~ 이런 생각하는분들 참 같은 개발자로써 부끄럽습니다. 루비도 나온지 꽤 오래 됐는데 레일즈 뒤엎고 신흥 언어로 부상하는건가요 ㅋㅋ
    페이스북, 트위터, 네이버 요 세 작품들은 최초에 php로 시작되었고 그안에 php 구현된 부분들이 아직도 많습니다~

    왜 댓글들에 악플이 많은지 조금 알것 같군요. 글 속에 은근히 내가 선호하는 언어는 좋고 다른 언어는 별로다 라는 근거없는 냄새가 조금 풍깁니다.

    아이폰 안드로이드 웹 dba 까지 겸하고 있는 입장으로써 C도 참 좋아하지만 글쓴이의 일부 시선들이 보기 불편하게 하는군요.!

    • Jong Wook Kim

      plat -> flat

      • 플오그램어

        흥분해서 썼더니 틀렸군요 -_-+ ;; 감사합니다

    • Guist

      페이스북 -> php 로 시작했으나 php 한계 때문에 코어를 바꿨습니다.
      Twitter -> Rails 로 시작했고, 현재는 Java+Scala 로 바뀌었습니다.
      Naver -> 일부 플랫폼이 php로 되어 있었으나 이제 메인은 Java (Spring + myBatis)이고 극히 일부만 C 확장을 씁니다.

      최근 몇년간을 돌이켜 보면 php가 성공한 프로젝트는 없습니다. 참고하십시오.

      • Hoseung Kim

        네이버는 서비스쪽은 php 에서 자바로 대부분 전환한걸로 알고 있고요
        검색쪽은 C 가 대부분입니다. 물론 2013년 4월 기준이겠네요. 제가 퇴사한 이후에는 어떻게 됐는지 모르니까요.

      • 에르가

        php로 성공해서 더 대규모의 사용자를 수용해야하니까 더 성능좋은 언어로 바꾼거지,
        php가 실패한건 아니죠.

      • 324fdsf

        php가 실패한걸로 보이시나요? ㅎㅎ

  • 플오그램어

    참고로 제 댓글에서 자바가 더 빠른결과를 얻는다는 말은 생산성이더 좋다는 말입니다~

  • 지나가는 개발자

    이 글을 그냥 제목 그대로 나쁘지 않아요 라고 볼수 있다면 괜찮다고 생각합니다만.. 다른분들 말과 같은 분위기도 있고 뭔가 안에서 이미 개발했고 노력을 넣은거에 대해 아까운 마음에 안 좋은 것을 좋다고 표현하는것처럼 밖에 보이지 않네요.

    강점에 있어서 정적타입을 논하셨는데 개발을 다 하셨을때 동적메모리가 매우 적거나 없을 정도로 개발을 하셨다면 버그는 없겠지만 메모리 효율이 엄청 안좋을테고 동적메모리가 있다면 정적타입의 강점? 글쎄요. 적어도 프로그램이 죽을일은 없다는건 말이 안된다고 생각합니다. 물론 계속된 버그픽스로 메모리 관리가 아주 잘된다면 문제가 없겠지만 “타입 안전한 언어에서는 컴파일 타임에서 에러가 나지 않으면 로직에 문제가 있지 않은 이상은 잘 작동하죠. 버그는 있을 수 있지만 프로그램이 죽는 일은 없습니다. 또한 성능도 뛰어납니다.” 라는 부분은 절대로 단박에 해결되지는 않겠죠. 왜 그런말도 있지 않습니까 프로그램에 버그가 없으면 그게 이상한거라고… 차라리 이부분은 메모리 관리를 알아서 해주는 JAVA나 스크립트 언어나 이런쪽이 좋죠. 적어도 정적 타입으로 인해 뭐가 좋다 라는 부분은 아니라고 생각합니다.

    생산성에서의 논점3가지도 말이 안되는거 같습니다. 일단 말마따나 바퀴를 재발명하는게 생산성이 좋은일이 아니란것도 알고 계실테고 C가 괜찮다고 제시한 3가지 이유는 도무지 납득을 할래야 납득할 수 없는 부분인거 같습니다.

    1번 이유는 그냥 농담으로 하신거라고 생각하겠습니다.. 외부 라이브러리 검색할 시간이 안들어서 시간이 준다니요. 하시려는 일은 그 라이브러리를 만드는 일인데요.

    2. 이건 컴파일 언어가 아니라도 요즘 좋은 툴들이 많이 있습니다. 하다못해 기존에 쓰시던 JAVA 베이스면 Intellij같은것도 좋고요.

    3. 이것도 납득이 잘 안되는부분인데 memory에서 이슈가 많이터지는 C의 경우가 디버깅이 쉬운지는 저로써는 납득이 안되네요.

    글을 쓰실때 차라리 성능면을 중점적으로 다루셨다면 괜찮았을지 모르겠지만 생산성을 논하신건 “C도 개발하기 괜찮다.” 라는 글의 주제에 반하는 내용이 아니었을까 싶네요.

    • Unnamed

      지나가다가 조금 덧붙이자면 정적타이핑은 장단점을 둘다 가집니다.

      정적타이핑의 장점이라면 역시 타입세이프한 프로그램을 짤 수 있다는 것입니다. 파이선이나 루비, 자바스크립트 등의 동적타입 언어들의 경우 어떤 변수가 어떤 타입을 가지는지를 런타임에서야 알 수 있습니다. 이는 런타임 에러를 발생시킬 수 있는 충분한 소지가 됩니다. 예를 들어 파이선에서는 a + b와 같은 간단한 수식이라도 런타임 에러가 발생할 수 있습니다. a가 문자열, b가 정수인 경우에서 말이죠. 정적타입 언어에서는 위와 같은 경우를 컴파일타임에 걸러낼 수 있습니다. 물론 동적타입 언어에서도 테스트프레임워크를 사용하거나 개발자가 조금 더 신경쓰기만 하면 저런 문제는 발생하지 않겠지만, 결국 시장에서 조금의 신경은 비용을 의미하니까요.

      정적타이핑의 단점.. 이면서 동적타이핑의 장점이라고 하면 역시 프로토타이핑을 빠르게 할 수 있다는 것입니다. 생각하는 것을 빠르게 코드화하고, 테스트해볼 수 있는 것은 분명한 장점입니다. 특히 서버와 같이 빠른 개발 사이클을 가져야하는 경우에서는 위의 장점을 포기할 수 있을 정도로 큰 이슈가 됩니다.

      보통 스크립트 언어에 익숙한 서버 개발자 들은 위와 같은 문제를 컴파일타임에 체크할 필요성 자체를 느끼지 못하는 경우도 많이 보았습니다. 하지만 정적 타입 언어들로 시스템 프로그래밍을 주로 하던 개발자들은 타입 안정성에 신중한 모습을 보이더군요.

      그렇다고 글 원문을 두둔하고자 하는 의미는 아닙니다. 정적 타이핑의 장점을 취하기 위해서 C를 사용하는 것은 전기를 아끼기 위해서 주판을 사용하는 것과 비슷하죠. Go나 Java 등의 훌륭한 정적 타입 언어도 있습니다.

      그냥 정적 타이핑의 장점에 대해서 덧붙이기 위해서 올려봅니다 🙂

      • Unnamed

        다시 읽어보니 단점 부분이 좀 어색하네요..

        정적 타이핑의 단점을 써야되는데 동적 타이핑의 장점의 관점으로 써버렸군요. 동적 타이핑인 경우 프로토타이핑을 빠르게할 수 있고, 그와 반대인 정적 타이핑의 경우 변수나 함수의 타입에 대해서 항상 신경을 써주어야하기 때문에 그만큼 프로토타이핑에 시간이 오래 걸린다는 의미였습니다.

        • Daehee Han

          좋은 의견 감사합니다. 저도 그 장단점을 많이 느꼈기에 그 부분을 정적 타이핑의 장점으로 넣었었지요. 하지만 많은 기능 수정이 필요한 것이 아닌, 재개발같은 상황이라면 생산성을 약간 포기하더라도 정적 타입 언어로 개발하는 것도 나쁘지 않더라구요 🙂

  • 플오그램어

    아 그리고 갠적으로
    “c로 짠 우리는 고스라능” 하면서 비꼬시는분
    C는 컴공 대학 졸업생들도 다 하는겁니다.
    글쓴이가 쓰지도 않은 글을 들먹이며 ;;
    저건 약간 열등감 같습니다 솔직히
    C 로 짜서 고수라능 이라는걸 연상할정도면

    얼마나 못하길래. -_-; 못하시면 현업 프로그래머면 한달 천천히 해도 금방합니다;
    C랑 C++ 알아야 제대로 짤 수 있는 Objective C 프로그래머들은 초고수 라도 된답니까 ㅋㅋ 요즘 널린게 Objective c 프로그래머인데.;

    회사마다 주로 쓰는 언어가 달라서 제가 몸담았던 보안 업계는 주로 C로 작업을 하는데
    다 고수인가요?? (잠시만 좀 웃을게요)

    진짜 개발쪽 고수는 꾸준한 업계 소식을 접하면서 꾸준히 관심을 가지고 지식을 늘려나가며 원하는 성능과 지향하는 개발내용에 부합하는 개발자들이지
    좀더 복잡한 언어를 사용한다고 고수가 아닙니다. -_-;

    초고수 되기 위해 2진수로 짜야할 기세.

  • powerumc

    트랙백 링크가 없어서 링크 남깁니다.

    http://blog.powerumc.kr/460

    • Daehee Han

      좋은 글 감사합니다 🙂

  • Unnamed

    천천히 글과 댓글을 다시 읽어봤는데 댓글에서 일부 부정적인 분들이 말씀하시는 얘기가 틀린 얘기는 아닌 것 같습니다. 다만 너무 공격적인 말투는 곤란하지 않나.. 싶네요 😀

    글에서 하시고자 하는 말씀은 알 것 같습니다만 기술적으로 설득력이 떨어지는 것이 사실입니다. 라이브러리가 적어서 도움이 된다거나, IDE의 얘기는 거의 설득력이 없는 것 같습니다. 타입 세이프티 관련해서 C가 하이레벨 스크립트 언어들보다 나은 것은 맞습니다만.. 그렇게 따지만 Go나 Java같은 더 좋은 언어도 많습니다. 컴파일도 마찬가지의 이야기입니다.

    글에서 말씀하고 계신 부분 중 공감이 되는 부분은 “레거시 코드가 C라서 뒤집어 엎을 수도 없고.. 어쩔 수 없이 C로 짰는데 그럭저럭 할만은 하더라”라는 부분입니다. 제가 지금까지 했던 프로젝트들 중에서 레거시를 뒤엎을 정도의 인력을 지원해주는 경우는 한번도 본 적이 없습니다.. 슬픈 일이네요. 하지만 이 부분은 기술적인 내용과는 전혀 무관하지 않나요? C로 짰을 때 다른 언어보다 정말 편했던 사례와 거기에 사용했던 기술 등을 설명해주셨으면 글 제목에 부합하는 더 좋은 포스트가 되었을 것 같습니다.

    나중에 혹시라도 프로젝트 중에 끼어들어가게 되었는데 서버 소스가 C로 짜여져있고 절대 바꿀 수 없다는 경우에 한 번 정도는 떠올려봄직한 글입니다. 떠올리기 전에 프로젝트를 관 둘 가능성이 높지만요. 그래도 댓글도 그렇고 본문도 그렇고 다들 재미있는 글이네요. 역시 개발자들은 어느정도 에고가 있는 존재들이고, 이런 류의 가벼운 논쟁을 즐기는 것 같습니다.

    • Daehee Han

      C로 개발하자! 란 결정을 내리게 된 뒷배경에 대해 많이들 궁금하시는데 저는 그 결정에 참여하지 않아서 구체적으로 말씀드리기 힘든 부분이 있습니다 ㅠ_ㅠ 당시 여러 프레임워크들을 벤치마킹했다고 이야기를 들었는데 추후 기회가 된다면 공개해보겠습니다.

      타입 세이프티 관련 이야기는 루비/파이썬 등을 비롯한 스크립트 언어들과 비교한 것이었는데 자꾸 이걸 자바랑 비교로 받아들이시는 분들이 많은 것 같습니다. 저도 자바가 C에 뒤지지 않는다고 봅니다. 오히려 더 뛰어난 부분들도 많죠.

  • C언어가 낡긴 낡았죠. 동적 언어가 요즘 대세라고는 하지만 네이티브 코드를 뱉어주는 컴파일 언어도 신형 스펙의 언어가 몇 종류 나와있습니다. D언어나 Go언어가 좀 유명한 것 같습니다. D언어는 C와 C++에서 불편했던 점을 개선한 면이 강하고 Go언어는 정말 네트워크 서버 프로그래밍을 위해 태어난 언어 같은 느낌이 듭니다. Go가 영향을 받은 언어 중에 Erlang이라는 언어가 있는데 이건 NoSQL DB구현체 중에서 실제로 쓴 곳이 있죠. 얼랭은 전화교환기에 쓸 목적으로 개발된 배경을 갖고 있어 강력한 경량 프로세스 모델을 갖고 있습니다. Go언어도 얼랭을 계승했기 때문에 같은 특징을 공유합니다.

    • Daehee Han

      Go가 네이티브 코드를 결과물로 뱉어주는지는 몰랐네요 ㅎㅎ 흥미로운 정보 감사합니다 🙂 제가 여러 언어를 섞어쓰지 말라고 한 것은, 같은 도메인 객체를 공유하는 시스템 여러개가 다른 언어로 구현되어 있으면 그 객체의 구현을 모두 동일하게 맞춰주어야 하는 피곤한 상황이 생기기 때문이었습니다. 각 컴포넌트의 독립성이 보장되어있는 상황이라면 굳이 언어를 통일해야 할 필요성은 없지요.

  • 저는 ‘한 프로젝트에 여러 언어 섞어쓰지 마세요’라는 문장에는 동의하지 않습니다. 제가 초급 개발자라 그럴 수도 있습니다만 복잡한 JSON데이터를 조작할 때 굳이 자바 객체로 변환해서 처리하기보다는 그냥 NodeJS에 jQuery 모듈 올려서 작업합니다. 텍스트 파일을 파싱해서 DB에 밀어넣는 프로그램은 파이썬으로 개발하고 DB에서 쿼리해 가져오는 프로그램은 자바로, 그리고 DB 디버깅이나 모니터링은 PHP를 사용합니다. 만약 DSL을 개발해야 할 일이 있다면 루비 언어를 고려해볼 것이고 고성능 네트워크 프로그램이 필요하면 Go언어, C의 메인 로직에서 바로 호출할 수 있어야 하지만 C로 개발하기 난감한 모듈은 루아로 개발할 겁니다. 사용 환경이 윈도우즈 OS로 제한될 게 확실하고 UI를 빠르게 개발해야 한다면 C#언어도 고려합니다. 제가 아직 초급 개발자라 한 프로젝트에 여러 언어를 섞어쓰는 것에 대한 리스크를 과소평가하는걸 수도 있습니다만 일단 지금까지는 언어를 섞어써도 큰 혼란은 오지 않았습니다.

  • guest

    종교적 논쟁, 지인 실드 등을 배제한 진짜 여론(?)을 느끼고 싶다면 upvote를 카운트하는 것으로 충분할 거 같습니다.

  • Sukchen Kang

    흥미로운 글 잘 읽었습니다. 혹 module 에서 seg fault 발생 시 어떻게 처리되나요? apache 에서 module 을 child process 로 관리하는지, 혹은 다른 예외 처리 방법이 있는지 궁금합니다.

    • Hoseung Kim

      seg fault 발생한 프로세스는 core dump 를 남기고 죽습니다. 사용자는 500 에러를 받게 되고요. prefork 모델을 사용하고 있기 때문에 아파치 설정에 해둔 프로세스수를 아파치가 유지해주게 되고 서비스 불능 상태가 되지는 않습니다. 말씀하신 대로 module 이 child process 로 관리된다고 볼 수 있겠네요.

      • Sukchen Kang

        처음엔 안정성에 대해 의구심을 가졌는데, 어차피 멀티프로세스 모델이면 장애 시 자식 프로세스만 죽으면 되므로 생각보다 장애와 관련한 큰 문제는 적겠네요. 그리고 C 모듈 관련 기술이 팀에서 늘면 해볼만한게 많은지라, 장기적으로 볼 땐 투자로 봐도 괜찮을 것 같아요. (imagemagick 이나 OpenCV 연동 등을 위해 웹서버 module로 만든 경우도 있죠. 이 경우 성능이 아닌 기존 라이브러리 연동을 위해 하는 경우이고. 물론 독립 프로세스로 만들고 pipe & filter 로 접근하는게 개발 자체 생산성이나 추후 다른 어플리케이션에서 연동하기에 더 편한 방식이긴 하지만요)
        답변 감사합니다.

  • root

    저한테 API서버를 개발하라고 시키면 C를 선택하지는 않을 것 같긴 같지만, API서버가 그렇게 복잡하지 않으면 C로 개발하는 것도 나쁜 선택이 아닐 수도 있을 것 같아요. 본문에 나와 있는 것 처럼 APR의 도움을 많이 받으면 비교적 어렵지 않을 것 같기도 하고, C개발에 익숙하시고 잘하는 분이 있다면 다른 개발팀원들을 리드해 금방 배우게 만들수도 있을테고요. 이음 개발팀이 여러가지 사항들을 고려하면서 이런 기술적 선택을 했으리라고 생각합니다. 이음은 돈도 잘 벌고 있고 그래서 어느 정도는 돈으로 이용해도 문제 없을 것 같은데, 그럼에도 불구하고 성능 효율성의 끝을 위해 노력한 점이 좋아보였습니다.

    다만, 이 블로그 글이 이슈가 되는 이유에 대해서 생각해보면, 글의 논리가 지나치게 말이 안되는 점이 있고, 그래서 결국 이런 기술적 선택을 한 이유에 대해서 설득력있는 설명이 전혀 없기 때문 인 것 같아요. 글쓰신 분이 댓글에서 언급하셨듯이 C는 다른 언어에 비하여 성능말고는 다른 이점이 없을 것 같은데, 간단한 API서버라면 어떤 언어로든 잘짜면 원하는 성능을 낼 수 있을 것 같거든요. 이 글에 나와있는 설명만으로는 기술적으로 납득하기 어려운 이상한 이유로 C언어를 선택한 것 처럼 오해하기 쉬운 것 같아 아쉽습니다.

    • Daehee Han

      이 난리 (?) 의 핵심을 정확히 짚어주신 것 같아요. 가볍게 쓴 글이 이렇게 커다란 논쟁으로 번지게 되어 조금 난감한 감이 있습니다. 의견 감사합니다!

  • kjw

    본글이 부족하다고 해서 막말을 일삼을 필요는 없어보이는데 이상한 분이 한 분 계시군요.

  • ong Wookjy

    처음 오신 분들은 ‘최신’에서 ‘오래된 순’으로 정렬 설정을 바꾸어 보시면 자연스런 흐름으로 읽으실 수 있습니다 🙂

  • Hong Jun Choi

    저번주에 Stack구현할일이있어서 C로 구현해야 할일이있었는데 막상 만들어보니까 잘안되더라구요..;; ㅠㅠ (이중포인터문제였는데 해결) 이런것 생각 안하고 그냥 알아서~ 가비지컬렉터 사용하고 하는 하이레벨 랭귀지들을 사용하는게 아닌가 싶습니다. (생산성) C로도 잘짜고 싶네요 ㅠㅠ 실력이 쪼달려서..

  • Composite

    -_- 좆자바 개발자 댓글 보니 왜 병신같은 좆품질 SI/SM 이 국내에서 양산되고 RIA에 쩔어 사는지 이해가 간다.
    이건 뭐 요즘 왜이렇게 생산성만 좆나게 따지는 개발세상이 온건지 정말..
    C로 printf(“Hello World”) 밖에 안하고 자바만 배운 무식한 것들이 아주 용감해요.
    그러고 가르쳐 들다니 요즘 개발자들이 쳐 돌았구나..

  • H

    아직 배우고 있는 초보라 궁금한게 있는데요.
    다름이 아니라 모바일 API서버라고 하는게 어떤 스타일(?)의 서버 인가요?

    모바일앱과 서버간에 TCP통신을 하는 건가요?
    아니면 REST API 같은걸 말하는 건가요?

    아직 용어에 익숙치 않아 질문글 올립니다.
    “모바일 API서버”라고 검색해서는 원하는 답을 찾을 수가 없네요.

  • 남뉴

    재밌는 포스팅 감사합니다. 전에 어떤 업체에서 PDF로 DLL을 만들지 않고 다 시리얼 통신 규격에 맞게 하시면 되요라는 메일을 받고 충격을 먹은 후, 하나하나씩 C 시리얼 통신 DLL로 적용해서 C#이란 VB.NET에서 사용한 적이 있습니다. 그때 대부분이 왜 굳이 니가 사서 고생하냐 그냥 통신에 맞게 대충 대충 배열 바이트 대치만 잘해도 화면에 결과값만 정확하게 나오면 되지 .. 라고 했던 기억이 오랜만에 새록새록 나네요;
    오히려 이제야 자바,ASP.NET과 모바일은 언제 중급실력으로 향상될려나 ㅎㅎ

  • guest

    글 잘 읽었습니다.
    정말 바보같고초보적인 질문이 있는데요. 이음 같은 경우엔…
    하루 두번 매칭이 이루어지는데 이걸 모든 회원을 루프를 돌려서 배치(batch) 형태로 하는건가요? 이러면 에러가 많을텐데…
    실시간으로 들어갈때 마다 하면 자원이 절약되지 않을까요?

  • guest

    이 글은 뭔가를 주장하기 위한 글이라기 보다는 우리 회사에서는 이렇게 해보았다 정도로 이해하는게 맞을 듯 하네요. ^^

    사람이 신중에 신중을 기하더라도 글로 표현 하면 모든 것들을 논리에 맞게끔 작성할 순 없는 노릇이지요. (말로 표현하는 중간에도 마찬가지입니다.) 최대한 논리의 오류가 적게 이야기 할 뿐이지…완전하게 논리적 오류를 피할 수 없다고는 생각할 수 없네요. 이렇게 글을 작성하고 있는 본인도 마찬가지로 글을 작성하다가 보면 수많은 논리적 오류를 범할지도 모르지요…(이 이야기 가지고 태클 거실 분들이 있을 것 같아 다소 걱정스럽긴 하네요.)

    몇 가지 생각을 두서없이 나열해봅니다.

    1. 설령 부족한 부분이 있는 글이라도 반대로 유지보수 문제는 어떻게 해결 하고 있는지? 기술적으로 좀 더 자세한 설명을 요구하는 등등의 질문과 답변을 통해 좀 더 의미있는 토론으로 발전되는게 아니라, 글 내용의 일부분의 잘잘못을 가리는 토론이라 아쉬움이 남네요.
    (개인적으로 상당히 관심있게 보고 있었는데…스크롤을 조금 내리자…아시겠지요?)

    2. 이유는 모르겠으나, 보통 웹에서 C/C++언어를 사용하는 경우는 극히 드물기 때문에, 웹에서 자주 사용될 법한 라이브러리나, 자동화에 대한 지원이 부족한 부분이 있다고 생각해요. 이런 부분을 타이밍이 맞게 자바가 지원하게 됨으로써 강세를 보이는 부분은 어찌보면 당연하리라 생각되요.

    3. 코드량이 많으면 많을수록 처리 속도가 늦어지거나 메모리 사용량이 많은게 당연한거고, 이를 감당할 수준이 넘어가면, 당연하다는 듯이 서버 댓수를 늘리지요. 하지만, 서버 댓수가 많으면 많을 수록 관리비는 많아집니다.(개발 코드의 양도 마찬가지로 늘어나겠죠.)

    이런 의미에서 기존의 서버와 변경된 서버에서 단 한번의 요청이라도 더 처리할 수 있다면, 접속하는 사용자가 많을수록 서버 유지 비용을 줄일 수 있다고 생각합니다. (그만큼 늘어나는 서버 댓수를 줄일 수 있을테니깐요.)

    이 정도의 요청이 있을 때는 최적화를 시도합니다만, 보통은 점진적으로 진행되지요. 이 블로그의 내용은 그동안 바라보지 않았던, 생각했지만 그닥 선택 하지 않았던, 조금 극단적인 선택을 했었고, 그 결과가 이렇게 나왔다는 정도의 글로 보입니다만…매도하는 정도로 잘못을 저지른 걸로 보이지 않네요.

    4. 유지 보수 측면은 C언어든 자바든 일정 규모가 넘어가면 비슷하리라 생각합니다. 물론 자바 언어가 C언어보다 나중에 나온 언어이기 때문에 C언어에서 자주 발생하는 실수를 보완해줄 수 있는 장치가 마련된 것은 사실입니다.
    하지만 어디까지나 장치입니다.
    그렇기 때문에 자바에서 갖춰진 장치적 지원이 없는 C언어에서는 내부 오류의 발생 가능성, 디버깅에서의 일부 어려움은 당연하지요. 두 언어의 설계 사상, 목적이 다르기 때문이기도 하고, 언어가 개발된 시기적으로도 보면 당연하리라 생각됩니다. (시지적으로 나중에 나왔다는 이야기는 이전의 불편함, 어려움을 개선하려는 시도를 분명 했을테고 그것들이 포함되었을테니깐요.)

    C언어로 작성된 대규모 프로그램들도 아직 잘 관리되는 곳도 많습니다. 대표적으로 리눅스 커널, 이외 GNU 프로젝트 들, UNIX, BSD 등등 이들 프로젝트들은 못해도 코드가 10만 라인을 넘기는 코드들이지만 아직까지 관리가 잘 되고 있지요.

    유지보수라 이야기 해도, 사람이 관리해야하는 항목입니다. 개발 당사자들 끼리 얼마 만큼의 구조를 체계를 잘 지키느냐가 관건이라 생각합니다.

    지나가다가 한자 남기고 갑니다. 위에서도 언급했듯이 제가 말한 내용에도 수많은 오류가 있을테고, 반드시 설명하고 넘어가야 할 부분이 누락된 부분도 있으리라 생각됩니다. 그냥 넓은 아량으로…이해해주시길~

  • Doho Ricky Lee

    본문 내용은 C도 개발하는데 생각만큼 고생스럽지 않아! 라고 결론을 내리는 분위긴데요, 사실 여기서 우리가 생각해 봐야 할 것은 생각보다 쉽다 쉽지않다 보다도, 휴먼 리소스(개발 유지보수 비용)와 시스템 리소스(서버 호스팅 + 장비 비용)의 트레이드 오프 관계인 거 같습니다. 값싸게 개발자를 많이 확보할 수 있을경우 개발만 완료되면 그다음에는 낮은 성능의 서버로도 감당이 가능해서 서버 유지 비용이 줄어들고(여기서 서버 유지 비용이란 인건비를 제외한 호스팅 비용), 개발자 인건비가 비쌀 경우 소수 인원만으로 빠르게 개발이 가능하게 제작한 뒤(인건비 최소화) 서버 비용을 조금 더 부담하는 식으로 진행될 테니까요. 아무래도 인건비가 너무 비싸 개발자 갈아넣기가 불가능한 풍토에서는 후자를 많이 사용할 거 같고, “C할줄 아시는 분 10분 타세요” 가 가능한 풍토에서는 전자도 가능할 거 같습니다. 예를 들어 개발자 한명 사는데 한달에 천만원이 들고 C로 만든 서버 호스팅 비용이 한달에 50만원, 루비로 만든 서버 호스팅 비용이 한달에 200만원이 든다면, 인건비가 비싼 나라의 스타트업 같은 경우에는 아무래도 개발자를 최소화하고 앞으로 나가게 될 서버비용을 더 내는 편이 유리할거 같아요. (특히나 스타트업은 초반비용에 대한 부담이 크니까). 그런데 같은 스타트업이라도 개발자 인건비가 싼 나라에서 하는 경우, (대강 C로 개발 및 유지보수하는데 루비의 3배의 인적 자원이 필요하다고 가정할 때) 개발자 한명 사는데 한달에 200만원밖에 안든다면 개발자 3명 사서 C개발 시키고 한명으로 유지보수 시켜도 1년이면 서버비용 계산해서 1명이 루비로 개발해서 드는 비용과 비교해서 손익분기가 얼추 맞아 떨어지겠네요(정확히 계산은 안했습니다). 이런거 등등 이것저것 생각해서 좋은거 하면 될거 같습니다. 스타트업을 할 때 미국식 방법론만 생각하면 안되는게 이런 이유때문이기도 한 거 같아요(개발자로서 좀 슬프긴 하지만..ㅎ) 인건비 차이도 심하고 이런저런 환경도 달라서..

  • 뜬금없지만 여기서 말하는 API 서버는 무엇을 말하는건가요? 루비 온 레일즈는 제가 알기로 자바의 스프링처럼 자바 SE를 더욱 뛰어나게 만들어주는 프레임워크로 알고있고 이를 통해 웹서비스를 구현하는 것으로 알고있습니다. 근데 API 서버 라는게 정확이 무엇인지 모르겠는데… Web 서비스 구현시 back-end를 말하는건가요??

  • ㅁㄴㅇㄹ

    김종욱 열등감에 병림픽 뛰네 ㅋㅋㅋ

    • ㅁㄴㅇ

      어그로꾼에게 먹이를 주지 맙시다

  • 자바게이는바퀴벌래다

    이러니 자바게이라는 소릴 듣지. 프로젝트 하는데 생산성 운운하는건 능력이 없다고 봐야지. 거기다 타입 어쩌구 저쩌구 하면서 자신의 능력이 막장이라는걸 홍보하는 거지. 자바가 좋은 언어같지? 지나가는 개가 웃는다.. ㅋ

  • 절대 따라하시면 안됩니다

    아주 오래전 글이지만 검색하다가 자꾸 결과에 걸려 혹시나 해서 남깁니다. 이글을 읽고 아파치를 확장해 웹서비스를 만들어도 되는구나 라는 생각을 절대 하시면 안됩니다.
    글쓴 분이 다니셨다는 엔모사에서도 일해봤고 지금도 포털에서 일합니다만 제가 관여하는 어느부분에서도 저런식으로 일하는게 의미있지 않습니다. 만약 고달프더라도 속도가 필요하다 라고 한다면 Go도 있고 php를 컴파일해서 쓸 수도 있습니다. c로 만드는것보다 훨씬 짧은 코드와 편의성을 제 20년 경력을 걸고 보증합니다. 세상에 apr을 확장해서 웹서비스를 쓴단 이야기를 이렇게 자랑스럽게 한다는게 참…