Archive for 10월, 2017

더 이상 배우려 하지 않는 개발자 : Expert Beginner의 등장 – Jiwon Yeom – Medium

2017/10/31

더 이상 배우려 하지 않는 개발자 : Expert Beginner의 등장 – Jiwon Yeom – Medium

https://medium.com/@jwyeom63/%EB%8D%94-%EC%9D%B4%EC%83%81-%EB%B0%B0%EC%9A%B0%EB%A0%A4-%ED%95%98%EC%A7%80-%EC%95%8A%EB%8A%94-%EA%B0%9C%EB%B0%9C%EC%9E%90-expert-beginner%EC%9D%98-%EB%93%B1%EC%9E%A5-dd40c40aeedf

Advertisements

The Industry Just Can’t Decide about DevOps Teams

2017/10/31

The Industry Just Can’t Decide about DevOps Teams

https://www.infoq.com/news/2017/10/devops-teams-good-or-bad?utm_source=sumome&utm_medium=twitter&utm_campaign=sumome_share

LASCON 2017 Conference Notes

2017/10/31

—-
LASCON 2017 Conference Notes
// the agile admin

Well, last Thursday and Friday I went to LASCON, our local Austin application security convention! It started back in 2010; here’s the videos from previous years (the 2017 talks were all recorded and should show up there sometime soon. Some years I get a lot out of LASCON and some I don’t, this one was a good one and I took lots and lots of notes! Here they are in mildly-edited format for your edification. Here’s the full schedule, obviously I could only go to a subset of all the great content myself. They pack in about 500 people to the Norris Conference Center in Austin.

Day 1 Keynote

The opening keynote was Chris Nickerson, CEO of LARES, on pen testing inspired thoughts. Things I took away from his talk:

  • We need more mentorships/internships to get the skills we need, assuming someone else is going to prep them for us (school?) is risible
  • Automate and simplify to scale and enable lower skill folks to do the job – if you need all security geniuses to do anything that’s your fault
  • There’s a lack of non made up measurements – most of the threat severities etc. are in the end pure judgement calls only loosely based on objective measures
  • Testing – how do we know it’s working?
  • How do all the tools fit together? Only ops knows… 2017-10-26 09.43.34.jpg
  • Use an attack inventory and continually test your systems
  • Red team automation plus blue team analytics gives you telemetry
  • Awareness of ego:2017-10-26 09.49.18.jpg

Security for DevOps

2017-10-26 10.19.27

Then the first track talk I went to was on Security for DevOps, by Shannon Lietz, DevSecOps Leader at Intuit. She’s a leader in this space and I’ve seen her before at many DevOps conferences.

Interesting items from the talk:

  • Give security defects to your devs, but characterize adversary interest so they can prioritize.
  • Reduce waste in providing info to devs.
  • 70-80% of bad guys return in 7 days – but 20% wait 30d till your logs roll

She likes to use the killchain metaphor for intrusion and the MITRE severity definitions.2017-10-26 10.24.58

But convert those into “letter grades” for normal people to understand! Learn development-ese to communicate with devs, don’t make them learn your lingo.2017-10-26 10.36.15
Read the Google Beyondcorp white papers for newfangled security model:
1. zoning and containment
2. Asset management
3. Authentication/authorization
4. Encryption

Vendors please get to one tool per phase, it’s just too much.

2017-10-26 10.48.52.jpg
Other things to read up on…

Startup Security: Making Everyone Happy

2017-10-26 11.14.29By Mike McCabe and Brian Henderson of Stratum Security (stratumsecurity.com, github.com/stratumsecurity), this was a great talk that reminded me of Paul Hammond’s seminal Infrastructure for Startups talk from Velocity. So you are getting started and don’t have a lot of spare time or money – what is highest leverage to ensure product security?

They are building security SaaS products (sold one off already, now making XFIL) and doing security consulting. If we get hacked no one wants our product.

The usual startup challenges – small group of devs, short timelines, new tech, AWS, secrets.

Solutions:

  • Build security in and automate it
  • Make use of available tools, linters, SCA tools, fuzzing
  • Continuous testing
  • AWS hardening
  • Alerting
  • Not covering host security, office security, incident response here
    2017-10-26 11.24.12

They use AWS, codeship, docker (benefits – dev like in prod, run tools local, test local). JavaScript, golang, no more rust (too bleeding edge). Lack of security tooling for the new stuff.

Need to not slow down CI, so they want tooling that will advise and not block the build. The highest leverage areas are:

  • Linting – better than nothing. ESLint with detect-unsafe-regex and detect-child-process. Breaks build. High false positives, have to tweak your rules. Want a better FOSS tool.
  • Fuzzing – gofuzz based on AFL fuzz, sends random data at function, use on custom network protocols
  • Source code analysis – HP Gas
  • Automated dynamic testing – Burp/ZIP
  • Dependency checking. Dependencies should be somewhat researched – stats, sec issues (open/closed and how their process works)
  • Pull requests – let people learn from each other

Continuous integration – they use codeship pro and docker
Infrastructure is easy to own – many third party items, many services to secure

AWS Tips:

  • Separate environments into AWS accounts
  • Don’t use root creds ever
  • Alert on root access and failed logins with cloudwatch. [Ed. Or AlienVault!]
  • All users should use MFA
  • Rigorous password policy
  • Use groups and roles (not direct policy assignment to user)
  • Leverage policy conditions to limit console access to a single IP/range so you know you’re coming in via VPN
  • Bastion host – alert on access in Slack
  • Duo on SSH via PAM plugin
  • Must be on VPN
  • Use plenty of security groups
  • AWS alering on failed logins, root account usage, send to slack

See also Ken Johnson’s AWS Survival Guide

Logging – centralize logs, splunk/aws splunk plugin (send both direct and to Cloudwatch for redundancy), use AWS splunk plugin.

Building the infrastructure – use a curated base image, organize security groups, infra as code, manage secrets (with IAM when you can). Base image using packer. Strip down and then add splunk, cloudwatch, ossec, duo, etc. and public keys. All custom images build off base.

Security groups – consistent naming. Don’t forget to config the default sec group even if you don’t intend to use it.

Wish we had used Terraform or some other infrastructure as code setup.

Managing secrets – don’t put them in plain test in github, docker, ami, s3. Put them into KMS, Lambda, parameter store, vault. They do lambda + KMS + ECS. The Lambda pulls encrypted secrets out of s3, pushes out container tasks to ecs with secrets. See also “The Right Way To Manage Secrets With AWS” from the Segment blog about using the new Parameter Store for that.2017-10-26 11.42.38
Next steps:

  • more alerting esp. from the apps (failed logins, priv escalation)
  • terraform
  • custom sca (static analysis)
  • automate and scale fuzzing maybe with spot instances

Security is hard but doesn’t have to be expensive – use what’s available, start from least privilege, iterate and review!

Serverless Security

2017-10-26 13.54.30

By fellow Agile Admin, James Wickett of Signal Sciences. Part one is introducing serverless and why it’s good, and then it segues to securing serverless apps halfway in.

Serverless enables functions as a service with less messing with infrastructure.

What is serverless? Adrian Cockroft – “if your PaaS can start instances in 20ms that run for half a second, it’s serverless.” AWS Lambda start time is 343 ms to start and 84 ms on subsequent hits, not quite the 20ms Cockroft touts but eh. Also read https://martinfowler.com/articles/serverless.html and then stop arguing about the name for God’s sake. What’s wrong with you people. [James is too polite to come out and say that last part but I’m not.]

Not good for large local disk space, long running jobs, big IO, super super latency sensitive. Serverless frameworks include serverless, apex, go sparta, kappa. A framework really helps. You get an elastic, fast API running at very low cost. But IAM is complicated.

So how to keep it secure?

  • Externalize stuff out of the app/infra levels – do TLS in API gateway not the app, routing in API gateway not the app.
  • There’s stack element proliferation – tends to be “lambda+s3+kinesis+auth0+s3+…”
  • Good talk on bad IAM roles – “Gone in 60 seconds: Intrusion and Exfiltration in Serverless Architectures” – https://www.youtube.com/watch?v=YZ058hmLuv0
  • good security pipeline hygeine
  • security testing in CI w/gauntlt
  • DoS challenges including attack detection…
  • github/wickett/lambhack is a vulnerable lambda+api gateway stack like webgoat. you can use it to poke around with command execution in lambda… including making a temp file that persists across invocations
  • need to monitor longer run times, higher error rate occurrences, data ingestion (size), log actions of lambdas
  • For defense: vandium (sqli wrapper), content security policies

And then I was drafted to be in the speed debates! Less said about that the better, but I got some free gin out of it.

Architecting for Security in the Cloud
2017-10-27 10.18.40

By Josh Sokol, Security Spanker for National Instruments! He did a great job at explaining the basics. I didn’t write it all down because as an 3l33t Cloud Guru a lot wasn’t new to me but it was very instructive in reminding me to go back to super basics when talking to people. “Did you know you can use ssh with a public/private key and not just a password?” I had forgotten people don’t know that, but people don’t know that and it’s super important to teach those simple things!

  • Code in private GitHub repo
  • Automation tool to check updates and deploy
  • Use a bastion to ssh in
  • Good db passwords
  • Wrap everything in security groups
  • Use vpcs
  • Understand your attack surfaces – console, github, public ports
  • Analyze attack vectors from these (plus insiders)
  • Background checks for employees
  • Use IAM, MFA, password policies
  • Audit changes
  • The apps are the big one
  • Https, properly configured
  • Use an IPS/WAF
  • Keys not just passwords for SSH
  • Encrypt data before storing in db

Digital Security For Nonprofits

2017-10-27 10.58.21

2017-10-27 11.00.23

Dr. Kelley Misata was an MBA in marketing and then got cyber stalked. This led to her getting an InfoSec Ph.D from Spaf at Purdue! Was communications director for Tor, now runs the org that manages Suricata.

Her thesis was on the gap of security in nonprofits, esp. violence victims, human trafficking. And in this talk, she shares her findings.

Non-profits are being targeted for same reasons as for-profits as well as ideology, with int’l attackers. They take money and cards and everything like other companies.
63% of nonprofits suffered a data breach in a 2016 self report survey. Enterprises vet the heck out of their suppliers… But hand over data to nonprofits that may not have much infosec at all.

ISO 27000, Cobit 5… normal people don’t understand that crap. NIST guidance is more consumable – “watered down” to the infosec elite but maps back to the more complex guidelines.

She sent out surveys to 500 nonprofits expecting the normal rate of return but got 222 replies back… That’s an extremely high response rate indicating high level of interest.
Nonprofits tend to have folks with fewer tech skills, and they more urgent needs than cyber security like “this person needs a bed tonight.” They also don’t speak techie language – when she sent out a followup a common question was “What does “inventory” mean?”

90% of nonprofits use Facebook and 53% use Twitter. They tend to have old systems. Nonprofit environments are different because what they do is based on trust. They get physical security but don’t know tech.

2017-10-27 11.21.16.jpgThey are not sure where to go for help, and don’t have much budget. Many just use PayPal, not a more general secure platform, for funds collection. And many outsource – “If we hand it off to someone it must be secure!”

The scary but true message for nonprofits is that it’s not if but when you will have a breach. Have a plan. Cybersecurity insurance passes the buck.

You can’t be effective if you can’t message effectively to your audience. She uses “tinkerer” not hacker for white hats, because you can complain all you want about “hacker not cracker blah blah” but sorry, Hollywood forms people’s views, and normal people don’t want a “hacker” touching their stuff period.

Even PGP encrypting emails, which is very high value for most nonprofits, is ridiculously complicated for norms.

What to do to improve security of nonprofits? Use an assessment tool in an engaging way. Help them prioritize.
She is starting a nonprofit, Sightline Security for this purpose. Check it out! This was a great talk and inspires me to keep working to bring security to everyone not just the elite/rich – we’re not really safe until all the services we use are secure.

2017-10-27 11.42.09.jpg

Malware Clustering
2017-10-27 13.03.01

By Srini (Srivathsan Srinivasagopalan), a data scientist from my team at AlienVault!

Clustering malware into groups helps you characterize how families of it work, both in general and as they develop over time.

To cluster, you need to know what behavior you want to cluster on, it’s too computationally challenging to tell the computers “You know… group this stuff similarly.”

You make signatures to match samples on that behavior. Analyzed malware (like by cuckoo) generally gives you static and dynamic sections of behavior you can use as inputs. There’s various approaches, which he sums up. If you’re not into math you should probably stop reading here so as to not hurt yourself.

To hash using shingling – concatenate a token sequence and hash them.2017-10-27 13.12.07.jpg
Jaccard similarity is computationally challenging.
Min-hashing2017-10-27 13.28.39
Locality sensitive hash based clustering

Hybrid approach: corpus vectorization

2017-10-27 13.37.16
Next…Opscode clustering! Not covered here.

TL;DR, there’s a lot of data to be scienced around security data, and it takes time and experimentation to find algorithms that are useful.

Cloud Ops Master Class

2017-10-27 14.00.48By @mosburn and @nathanwallace
Trying to manage 80 teams and 20k instances in 1 account – eek! Limits even AWS didn’t know about.
They split accounts, went to bakery model. Workload isolation.
They wrote tooling to verify versions across accounts. It sucked.
Ride the rockets – leverage the speed of cloud services.
Change how the team works to scale – teach, don’t do to avoid bottlenecking. App team self serves. Cloud team teaches.

2017-10-27 14.29.04.jpgPolicies: Simple rules. Must vs should. Always exceptions.
The option requirement must be value in scope.
Learn by doing. Guardrails – detect and correct.
2017-10-27 14.29.10Change control boards are evil – use policy not approval.
Sharing is the devil.
Abstracting removes value – use tools natively.

  • Patterns at scale
  • Common language and models
  • Automate and repeat patterns
  • Avoid custom central services
  • Accelerate don’t constrain
  • Slice up example repos
  • Visibility
  • Audit trail
  • Git style diff of infra changes
  • Automate extremely – tickets and l1-2 go away
  • All ops automated, all alerts go to apps so things get fixed fast

He’s created Turbot to do software defined ops – https://turbot.com/features/

  • Cross account visibility
  • Make a thing in the console… then it applies all the policies. Use native tools, don’t wrap.
  • Use resource groups for rolling out policies
  • Keep execution mostly out of the loop

2017-10-27 14.22.32.jpg

And that was my LASCON 2017! Always a good show, and it’s clear that the DevOps mentality is now the cutting edge in security.

—-

Read in my feedly

나의 iPhone에서 보냄

31 October, 2017 16:57

2017/10/31

—-
Ms, 오픈소스 코드 검사도구 ‘소나’ 공개
// Bloter.net

마이크로소프트(MS)가 코드 검사도구 ‘소나’를 오픈소스 기술로 공개했다.

소나는 린트 도구로, 소스코드를 스캔하고 잠재적인 오류를 찾아내며 보안, 성능, 접근성 등을 검사해준다. 안토니 몰레다 MS 웹 플랫폼 프로그램 매니저는 공식 블로그를 통해 “웹은 복잡하나 소나로 훨씬 쉽게 코드를 짤 수 있을 것”이라며 “단순히 오류를 알려주는 것 뿐만 아니라 그 이유도 함께 설명해준다”라고 소개했다.

소나 공식 홈페이지를 방문하면 누구나 웹사이트를 검사할 수 있다. 아래처럼 웹사이트 주소를 입력하고 ‘스캔 실행(Run Scan)’ 버튼을 누르면, 경고와 에러 개수를 계산해준다. 그 아래에는 상세 원인과 해결책을 함께 제안한다.

▲소나 테스트 예시(사=소나 홈페이지)

▲소나 테스트 예시(사진=소나 홈페이지)

▲소나 테스트 예시(사진=소나 홈페이지)

MS는 지난 6월 JS커뮤니티에 소나를 기증했으며, 이후 더 많은 사용자들의 피드백과 관심을 받기 위해 이번에 아예 오픈소스 형태로 전환했다. 또한 aXe코어, AMP 검사기, 싱크, SSL 랩스, 클라우디너리 같은 외부 서비스와 소나를 함께 사용할 수 있도록 새로 업데이트했다.

안토니 몰레다 매니저는 “앞으로 소나를 비주얼 스튜디오 코드에 추가할 수 있게 플러그인을 개발하고, 다양한 검사 규칙을 추가할 것”이라고 밝혔다. 소나에서 적용한 분석 기준과 튜토리얼은 공식 홈페이지에서 확인할 수 있다.

—-

Read in my feedly

나의 iPhone에서 보냄

국내 최대 개발자 사이트 대표 “Si문화를 바꾸고 싶다”

2017/10/31

—-
국내 최대 개발자 사이트 대표 “Si문화를 바꾸고 싶다”
// 지디넷코리아 – 전체기사

[지디넷코리아]

“개발자들이 제 대접을 못받는 현재의 시스템통합(SI) 문화를 바꿔보고 싶습니다. 우리나라 SI는 20여년전이나 지금이나 크게 바뀐 게 없습니다. SI 개발자들이 소외받고 기가 죽어 있습니다. SI가 즐겁다는, 그런 문화를 만들어보고 싶습니다”.

국내 최대 개발자 커뮤니티인 오키(OKKY)를 이끌고 있는 노상범 대표가 오래전부터 지니고 있는 꿈이다. 오키 회원수는 5만명이 넘는다. 다양한 개발자들이 이곳에 다양한 사연을 쏟아 놓는다.

노 대표는 개발자는 아니다. 홍익대에서 영어영문학을 전공했다(85학번). 사람만나기 좋아하는 노 대표는 대학 4년때(1997년) 홍익인터넷이라는 회사를 차려 IT와 처음 인연을 맺었다. 당시 우리나라에서 웹에이전시라는 말을 처음 사용했다.

국내 최대 개발자 사이트인 오키를 이끌고 있는 노상범 대표. 기술 분야 HR회사인 e브레인도 운영하고 있다.

오키에는 2013년 5월 합류했다. 오키 대표로 있다 보니 늘 개발자들과 함께 있다. IT최강 미국은 개발자 몸값이 상한가다. 하지만 우리나라는 그렇지 못하다. 개발자들의 현실이 어떤지 노 대표에게 들어봤다.

■국내 최대 개발자 사이트 ‘오키’

=오키(OKKY)에 대해 먼저 설명해달라.

▲오키는 2000년 12월에 처음 만들어졌다. 만 17년됐다. 자바 개발자 커뮤니티로 시작해다. 현재 국내 개발자 커뮤니티 중 가장 크다. 원래 이름은 OKJSP(OK자바서버페이지)였다. JSP를 공부하던 사이트였다. 허광남 개발자가 만들었다.

나는 2013년 5월에 이 곳에 참여, 대표로 활동하고 있다. 법인이 아니고 커뮤니티다. 게시판 형태로 운영하고 있다. 구인 구직과 사는 이야기 부문이 트래픽이 가장 많다. 2015년 2월 사이트를 개편하면서 이름도 OKJSP에서 OKKY로 바꾸었다. OKJSP라는 이름이 너무 길었고, 자바에 치중한 사이트라는 느낌도 덜고 싶었다. 현진건 소설 ‘사랑방 손님과 어머니’에 나오는 어린 여자 주인공 이름이 옥희다. 개발자들이 OKKY를 사랑방과 같다며 옥희와 비슷한 ‘오키’라 불렀다.

자바 뿐만 아니라 모든 개발자 언어를 포함(오케이)한다는 의미도 있다. 현재 회원 수는 5만2000명이다. SI 프리랜서 개발자들이 제일 많다. 회원 중에는 개발자들이 되고 싶은 취준생도 있다.

=개발자 커뮤니티는 국내에 몇 개나 되나

▲한 200개 정도 되는 것 같다. 거의 다 소규모다. 대형 커뮤니티는 데브피아와 PHP스쿨, 오키 등 3개 정도다. 데브피아는 마이크로소프트(MS)의 닷넷 기반(베이스)이고, PHP스쿨은 PHP(Hypertext Preprocessor) 기반이다. 데브피아와 PHP스쿨은 커뮤니티가 아니다. 법인으로 바뀌었다.

비영리 커뮤니티는 오키가 국내에서 규모가 가장 크다. 이들 3개를 빼면 대부분 커뮤니티는 개인이 운영하는 수준이다. 수시로 생겼다 없어져 정확한 숫자를 파악하기 힘들다. 페이스북 등의 영향으로 개발자 사이트들이 많이 없어졌다.

=자바 개발자 커뮤니티 대표인데 SI에 관심이 큰 이유는

▲우리나라에서 자바를 가장 많이 사용하는 곳이 어디인 줄 아나. 바로 공공이다. 물론 서비스 하는 회사들도 많이 쓴다. 하지만 공공에 비할 바가 아니다. 공공 SI쪽이 자바를 많이 사용하다보니 자연스레 공공SI에 관심을 갖게 됐다.

개발자들이 사석에서 오키를 ‘개발자들의 할렘’이라고 부른다. 개발자들이 제대로 된 대우와 처우를 받지 못하고 있다는 것을 역설적으로 표현한 거다. 공공 SI에서 일하는 개발자들이 힘들고 불합리한 일을 많이 당하는데 우리 사이트에 와서 이런 일을 털어 놓는다.

오키가 지난 6월 개발자들을 대상으로 행사를 진행하고 있다.

=우리나라 개발자는 총 몇명이나 되나.

▲정확하지 않다. 여러 곳에서 다양한 숫자를 내놓는다. 어디까지를 개발자로 볼 지도 논란이다. 우리는 30만명 정도로 추정한다. 소프트웨어(SW) 업체 뿐 아니라 제조, 금융, 유통 등 각 산업 분야에도 개발자들이 있어 정확히 파악하는 게 힘들다. 당국이 이를 제대로 조사해줬으면 좋겠다.

내가 정의하는 개발자는 이걸(개발)로 밥을 먹고 사는 사람, 페이(급여)를 받는 사람이다. 코딩이나 설계, 프로젝트 매니저(PM)를 하는 사람들이다. 30만 개발자 중 프리랜서는 2~3만명 정도 되는 것 같다.

개발자를 정확히 추산하기 어려운 이유 중 하나가 통계청에 등록되는게 사람(개발자) 정보가 아니라 기업 정보이기 때문이다. 예를 들어 조선업 프로젝트에 개발자가 많이 들어가지만 사람이 아닌 업체 정보가 등록된다.

=한국소프트웨어산업협회(KOSA, 코사)에도 개발자들이 등록하는데

▲코사에 신고하는 사람들은 프리랜서다. 정규직 개발자들은 신고할 이유가 없다. 삼성에서 일하는 개발자들이 코사에 등록할 이유가 없다. 네이버 등에 일하는 개발자들에게 코사 이야기를 하면 “코사가 뭐예요?” 할 거다.

코사는 공식적인 프로젝트 경력을 증명해준다. 하지만 증명 방법에 문제가 있다. 전수 조사가 불가능하고, 기업에서 확인을 받기 때문에 신빙성 문제를 야기시킨다.

■개발자는 실력으로 판단하고 실력으로 검증해야

=논란이 되고 있는 개발자 실력을 검증하는 방법은 있나

▲있다. 개발자는 실력으로 판단하고 실력으로 검증해야 한다. 그런데 코사는 이런 능력이 없다. 그래서 경력으로 판단한다.너 어디 있었니? 전에 이거 해봤니? 이런 걸 물어보고 판단한다. 문제가 있다. 인터뷰와 코딩 테스트를 보면 개발자 실력을 알 수 있다. 삼성과 네이버, 구글 등은 좋은 실력자를 많이 갖고 있다. 뽑는 노하우와 방법이 있다. 이걸 준용해도 된다.

문제는 공공 SI에는 이게 없다는 거다. 개발자 숫자도 당국이 정확히 파악해 줬으면 좋겠다. 각 산업에 근무하는 개발자들도 많아 전수 조사가 불가능하지만 방법이 없는 것도 아니다. 통계학자나 경제학자들을 동원하면 개발자들을 조사하는 어떤 툴(방법)을 만들 수 있지 않을까 한다.

=통계청의 개발자 직군에도 문제가 있다던데…

▲그렇다. 정부가 정해 놓은 직군이 옛날 방식이다. 통계청 사이트에 가보면 직군을 나열해 놓은 게 있다. 4대 보험 등 여기서 만든 직군을 민간이 갖다 쓴다. 그런데 이게 너무 옛날 방식이다. 이곳부터 바꿔야 한다.

=오래전부터 오키를 통해 하고 싶은 게 있다던데

▲우리나라 SI문화와 업계를 바꿔보고 싶다. SI업계가 20년전이나 지금이나 똑 같다. SI 개발자들이 일하고 싶은 곳이 아니다. SI 개발은 중요하다. 프로젝트 품질을 좌우한다. 사용자들에게 가치(밸류)도 준다. 그런데 이런 SI를 재미있어하는 개발자들이 거의 없다. 5% 정도 밖에 안되는 것 같다.

어느 정도 실력 있는 선수들, 이들은 얼마든지 충분히 대접을 받을 수 있는데도 “나는 약자”고 “피해자”라는 생각이 강하다. 당당함이 부족하다. 물론 그렇게 만든 환경이 문제지만 개발자들이 너무 피해의식에 절어 있는 것도 문제다. 이걸 바꿔보고 싶다. “SI가 너무 즐겁다. 이거 돈 된다. 사람 대접 받는다” 같은 말이 나오게 하고 싶다.

그러기 위해서는 발주자와 SW기업, 개발자 모두가 개발자와 SW에 대한 인식이 바뀌어야 한다. 망가진 SI 개발 생태계도 복원해야 한다. 민간도 재하도급을 금지해야 한다. 개발자를 프로젝트에 연결해주는 ‘개발자 보도방’ 문제도 여전하다. 예전보다 나아졌지만 여전히 개선해야 할 점이 많다. ‘보도방’ 존재 자체가 문제 있는 건 아니다.

개발자에게 돌아갈 돈을 떼어먹는 전문성 없는 보도방들이 문제다.

재하도급이 금지되면 이 문제가 어느 정도 걸러질 것이다. 제도와 함께 비즈니스적으로도 문화가 바뀌어야 한다. 그래야 “SI가 즐겁다”는 문화가 정착될 수 있다. 카카오뱅크 같은 회사가 많이 나와야 한다.

=카카오뱅크는 어떤 면에서 바람직하나

▲카카오뱅크는 개발자를 도구로 여기지 않는다. 회사의 서비스를 좌지우지하는 핵심인력으로 본다. 카카오뱅크 서비스가 오픈하자 마자 성공한 건 이런 문화가 있기 때문이다.

하지만 카카오뱅크와 경쟁하는 은행들은 아직 그렇지 않다. 서비스 품질에 차이가 나는 이유다. 몇 년전이지만 충격적인 사례를 접한 적이 있다. 서울시 행사에서도 발표했다. 개발자가 어느 병원에 일하러 갔는데 어느 공간을 내 준 줄 아나. 분향소였다. 세상에 분향소에 자리를 주고 개발하라는 곳이 어디 있나. 개발자들이 이렇게 대접받으니 좋은 인력이 오겠나. 아직도 이런 곳이 일부 있다고 생각한다.

=개발 비용을 단순히 머릿수로 계산하는, 헤드카운트를 없애야 한다는 말이 많다.

▲헤드카운트 문화는 정말 없어져야 한다. 개발자를 돼지고기 구분하듯이 중급 하나, 고급 둘 이렇게 구분해 돈을 주는 건 아니라고 본다. 돈이 문제가 아니라 품위 문제다. 이런 취급을 받으니 개발자들이 열을 받는다. 여기에 프로젝트에 따라 월화수목금금금과 야근이 불가피하다. 이러니 프로젝트 결과물이 좋을 리 없다. 공공기관 프로젝트 결과물이 엉성한 이유이기도 하다.

오키가 2014년 2월 개최한 제1회 자바스크립트 컨퍼런스.

■헤드카운트 폐지하고 ‘맨아워’제 도입해야

=헤드카운트를 폐지하면 대안이 있나

▲개발자 임금을 월로 계산하는 ‘맨먼스(Man Month)’를 없애야 한다. 대신 시간당 임금을 주는 ‘맨아워(Man Hour)’제를 도입해야 한다. 맨먼스로 하다보니 토요일에도 출근하는 일이 생긴다. 무엇보다 ‘맨아워’로 하면 발주처가 예산을 짤 때 처음부터 디테일하게 짠다.

외국에서는 프로그램 아웃소싱하는 개발자들이 전부 “나는 시간당 얼마를 받는다”고 말한다. 시간당 단가를 책정하는 것이다. 미국에서 맨먼스를 쓴다는 걸 들어본 적이 없다. 그런데 과기정통부는 이 문제가 노동부 관할이라며 신경을 크게 안쓴다.

작년인가 언제 당국이 미국의 공공 프로젝트 수행 실태를 조사해 발표한 적이 있다. 정말 미국은 부럽게 하고 있더라. 우리도 이렇게 해야 한다. 코사가 매년 평균 임금 발표하는 것도 못하게 해야 한다.

=영어영문학을 전공했는데 IT분야에서 일하고 있다

▲대학 4학년때(97년 7월) 인터넷 가능성을 보고 홍익인터넷이라는 회사를 세웠다. 웹에이전시라는 말도 내가 처음으로 우리나라에서 사용했다. 인터넷 붐을 타고 2000년에 1000만 달러 투자도 받았다. 직원도 한때 160명이나 됐다. 닷컴 버블이 꺼지면서 홍익인터넷이 어려워졌다. 이후 한때 포커 선수로 활동하는 등 여러 경험을 했다. 개발자 이력은 없다. 사람을 좋아하고 체질상 문과가 적성에 맞는다. 86년도에 가족이 미국으로 이민을 가 몇 년간 산 적이 있는데 그때 보험대리점 등 별걸 다 해봤다.

=개발자 역사에서 ‘잃어버린 12년’이 있었다는 건 무슨 말인가

▲2000년 초반부터 약 10여년간 우리나라에서 컴퓨터공학과(컴공과) 인기가 낮았다. 내가 대학 다닐 때인 80년대만 하더라도 공부를 제일 잘하는 사람들이 전자공학과에 갔다. 그런데 2000년초반부터 10여년간은 컴공과 인기가 하위권이었다. 이렇게 인기가 떨어진 건 세계적으로 우리나라 밖에 없다. 당시 컴공과를 전공한 학생들이 상대적으로 실력이 떨어졌다.

.

=마지막으로 개발자들에게 해주고 싶은 말은

▲개발자들도 이제 인식을 바뀌었으면 한다. 개발자들은 대부분 ‘개발’에만 관심이 있다. SW 정책 등에는 관심이 없다. 자기네와 직접 연관이 있는데 말이다. 개발 행사 이외에는 잘 모이지 않는다. 비 개발 행사에서 개발자가 1000명 모이면 대단한 사건이다. 우리가 오는 12월에 ‘오키콘’이라는 개발자 컨퍼런스를 하는 것도 그런 이유다. 기술 말고 협업. 생산성, 커뮤니케이션 이런 걸 다룬다

▶ IT 세상을 바꾸는 힘 <지디넷코리아>,
▶ IT뉴스는 <지디넷코리아>, 게임트렌드는 <뉴스앤게임>
▶ 스마트폰으로 읽는 실시간 IT뉴스 <모바일지디넷>
[저작권자ⓒ메가뉴스 & ZDNet & CNET. 무단전재 및 재배포 금지]
—-

Read in my feedly

나의 iPhone에서 보냄

가을 산책 가볼까요? 덕수궁 돌담길 주변 맛집 7곳

2017/10/31

—-
가을 산책 가볼까요? 덕수궁 돌담길 주변 맛집 7곳
// ㅍㅍㅅㅅ

짧아서 더 소중한 가을, 다들 알차게 보내고 계시나요? 가을 나들이 장소를 고민 중인 분들께 덕수궁 돌담길을 추천해볼까 해요. 매년 장관인 이곳의 단풍도 좋지만 올해는 제한되었던 덕수궁 뒤편의 100m가 개방되어 특별히 더 의미 있거든요! 그럼, 산책 후 들르면 좋을 덕수궁 주변 맛집 7곳을 소개할게요. 림벅 서울 중구 태평로2가 365 시작은 정동길 초입에서 거부할 수 없는 […]
—-

Read in my feedly

나의 iPhone에서 보냄

테스트메일

2017/10/31

—-
[B급 프로그래머] 10월 4주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)
// 컴퓨터 vs 책

DNEn5k6UQAU2_08.jpg
(오늘의 짤방: 그냥 먹고 살기도 이렇게 어려운데. via @gaddongyi)

  1. 개발/관리도구
  2. 고성능 서버/데이터베이스

(보너스: that’s 279 thousand cores. via @RDOcommunity) cerncloud.jpg
EOB
—-

Read in my feedly

나의 iPhone에서 보냄

Why (and How) Spinnaker and Kubernetes Work Together Seamlessly

2017/10/28

Why (and How) Spinnaker and Kubernetes Work Together Seamlessly

http://blog.armory.io/why-spinnaker-and-kubernetes-work-together-seamlessly/

kenzanlabs/spinikube: Run Spinnaker on Kubernetes locally

2017/10/28

kenzanlabs/spinikube: Run Spinnaker on Kubernetes locally

https://github.com/kenzanlabs/spinikube

창의력은 아이디어를 많이 만드는 능력이 아닙니다.

2017/10/28

창의력은 아이디어를 많이 만드는 능력이 아닙니다.

https://brunch.co.kr/@typhoonk83/56